Re: [pushed][PATCH v6] LoongArch: Fixed a compilation failure with '%c' in inline assembly [PR107731].
Pushed r13-5319.
在 2023/1/18 下午5:14, Richard Sandiford 写道:
Lulu Cheng writes:
Co-authored-by: Yang Yujie
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_classify_address):
Add precessint for CONST_INT.
(loongarch_print_operand_reloc): Operand modifier 'c' is supported.
(loongarch_print_operand): Increase the processing of '%c'.
* doc/extend.texi: Adds documents for LoongArch operand modifiers.
And port the public operand modifiers information to this document.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/tst-asm-const.c: Moved to...
* gcc.target/loongarch/pr107731.c: ...here.
---
V2 -> v3:
1. Correct a clerical error.
2. Adding document for loongarch operand modifiers.
v3 -> v4:
Copy the description of "%c" "%n" "%a" "%l" from gccint.pdf to gcc.pdf.
v4 -> v5:
Move the operand modifiers description of "%c", "%n", "%a", "%l" to the top of
the
x86Operandmodifiers section.
v5 -> v6:
Adjust the location of the added section in the document.
---
gcc/config/loongarch/loongarch.cc | 14 +
gcc/doc/extend.texi | 51 +--
.../loongarch/{tst-asm-const.c => pr107731.c} | 6 +--
3 files changed, 64 insertions(+), 7 deletions(-)
rename gcc/testsuite/gcc.target/loongarch/{tst-asm-const.c => pr107731.c}
(78%)
diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loongarch/loongarch.cc
index c6b03fcf2f9..cdf190b985e 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -2075,6 +2075,11 @@ loongarch_classify_address (struct
loongarch_address_info *info, rtx x,
return (loongarch_valid_base_register_p (info->reg, mode, strict_p)
&& loongarch_valid_lo_sum_p (info->symbol_type, mode,
info->offset));
+case CONST_INT:
+ /* Small-integer addresses don't occur very often, but they
+are legitimate if $r0 is a valid base register. */
+ info->type = ADDRESS_CONST_INT;
+ return IMM12_OPERAND (INTVAL (x));
default:
return false;
@@ -4933,6 +4938,7 @@ loongarch_print_operand_reloc (FILE *file, rtx op, bool
hi64_part,
'A' Print a _DB suffix if the memory model requires a release.
'b'Print the address of a memory operand, without offset.
+ 'c' Print an integer.
'C'Print the integer branch condition for comparison OP.
'd'Print CONST_INT OP in decimal.
'F'Print the FPU branch condition for comparison OP.
@@ -4979,6 +4985,14 @@ loongarch_print_operand (FILE *file, rtx op, int letter)
fputs ("_db", file);
break;
+case 'c':
+ if (CONST_INT_P (op))
+ fprintf (file, HOST_WIDE_INT_PRINT_DEC, INTVAL (op));
+ else
+ output_operand_lossage ("unsupported operand for code '%c'", letter);
+
+ break;
+
case 'C':
loongarch_print_int_branch_condition (file, code, letter);
break;
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 1103e9936f7..6a5d9faf2f3 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -10402,8 +10402,10 @@ ensures that modifying @var{a} does not affect the
address referenced by
is undefined if @var{a} is modified before using @var{b}.
@code{asm} supports operand modifiers on operands (for example @samp{%k2}
-instead of simply @samp{%2}). Typically these qualifiers are hardware
-dependent. The list of supported modifiers for x86 is found at
+instead of simply @samp{%2}). @ref{GenericOperandmodifiers,
+Generic Operand modifiers} lists the modifiers that are available
+on all targets. Other modifiers are hardware dependent.
+For example, the list of supported modifiers for x86 is found at
@ref{x86Operandmodifiers,x86 Operand modifiers}.
If the C code that follows the @code{asm} makes no use of any of the output
@@ -10671,8 +10673,10 @@ optimizers may discard the @code{asm} statement as
unneeded
(see @ref{Volatile}).
@code{asm} supports operand modifiers on operands (for example @samp{%k2}
-instead of simply @samp{%2}). Typically these qualifiers are hardware
-dependent. The list of supported modifiers for x86 is found at
+instead of simply @samp{%2}). @ref{GenericOperandmodifiers,
+Generic Operand modifiers} lists the modifiers that are available
+on all targets. Other modifiers are hardware dependent.
+For example, the list of supported modifiers for x86 is found at
@ref{x86Operandmodifiers,x86 Operand modifiers}.
In this example using the fictitious @code{combine} instruction, the
@@ -11024,6 +11028,30 @@ lab:
@}
@end example
+@anchor{GenericOperandmodifiers}
+@subsubsection Generic Operand Modifiers
+@noindent
+The following table shows the modifiers supported by all targets and their
effects:
+
+@multitable {Modifier} {Print the opcode suffix for the size of th} {Operand}
I guess this should be {Modifier} {Description} {...} to
[PATCH v4] xtensa: Eliminate unnecessary general-purpose reg-reg moves
Register-register move instructions that can be easily seen as
unnecessary by the human eye may remain in the compiled result.
For example:
/* example */
double test(double a, double b) {
return __builtin_copysign(a, b);
}
test:
add.n a3, a3, a3
extui a5, a5, 31, 1
ssai1
;; be in the same BB
src a7, a5, a3 ;; No '0' in the source constraints
;; The destination replaced is
;; irrelevant to the sources if the
;; destination constraint has '&'
;; No CALL insns in this span
;; Both A3 and A7 are irrelevant to
;; insns in this span
mov.n a3, a7 ;; An unnecessary reg-reg move
;; A7 is not used after this
ret.n
The last two instructions above, excluding the return instruction,
could be done like this:
src a3, a5, a3
This symptom often occurs when handling DI/DFmode values with SImode
instructions. This patch solves the above problem using peephole2
pattern.
gcc/ChangeLog:
* config/xtensa/xtensa.md: New peephole2 pattern that eliminates
the occurrence of general-purpose register used only once and for
transferring intermediate value.
gcc/testsuite/ChangeLog:
* gcc.target/xtensa/elim_GP_regmove.c: New.
---
gcc/config/xtensa/xtensa.md | 49 +++
.../gcc.target/xtensa/elim_GP_regmove.c | 23 +
2 files changed, 72 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/xtensa/elim_GP_regmove.c
diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index dd3fc37353b..1a6154c8ded 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -3048,3 +3048,52 @@ FALLTHRU:;
operands[1] = GEN_INT (imm0);
operands[2] = GEN_INT (imm1);
})
+
+(define_peephole2
+ [(set (match_operand 0 "register_operand")
+ (match_operand 1 "register_operand"))]
+ "GET_MODE_SIZE (GET_MODE (operands[0])) == 4
+ && GET_MODE_SIZE (GET_MODE (operands[1])) == 4
+ && GP_REG_P (REGNO (operands[0])) && GP_REG_P (REGNO (operands[1]))
+ && peep2_reg_dead_p (1, operands[1])"
+ [(const_int 0)]
+{
+ basic_block bb = BLOCK_FOR_INSN (curr_insn);
+ rtx_insn *head = BB_HEAD (bb), *insn;
+ rtx dest = operands[0], src = operands[1], pattern, t_dest;
+ int i;
+ for (insn = PREV_INSN (curr_insn);
+ insn && insn != head;
+ insn = PREV_INSN (insn))
+if (CALL_P (insn))
+ break;
+else if (INSN_P (insn))
+ {
+ if (GET_CODE (pattern = PATTERN (insn)) == SET
+ && REG_P (t_dest = SET_DEST (pattern))
+ && GET_MODE_SIZE (GET_MODE (t_dest)) == 4
+ && REGNO (t_dest) == REGNO (src))
+ {
+ extract_constrain_insn (insn);
+ for (i = 1; i < recog_data.n_operands; ++i)
+ if (strchr (recog_data.constraints[i], '0'))
+ goto ABORT;
+ if (strchr (recog_data.constraints[0], '&'))
+ for (i = 1; i < recog_data.n_operands; ++i)
+ if (reg_overlap_mentioned_p (dest, recog_data.operand[i]))
+ goto ABORT;
+ SET_DEST (pattern) = gen_rtx_REG (GET_MODE (t_dest),
+ REGNO (dest));
+ df_insn_rescan (insn);
+ goto FALLTHRU;
+ }
+ if (reg_overlap_mentioned_p (dest, pattern)
+ || reg_overlap_mentioned_p (src, pattern)
+ || set_of (dest, insn)
+ || set_of (src, insn))
+ break;
+ }
+ABORT:
+ FAIL;
+FALLTHRU:;
+})
diff --git a/gcc/testsuite/gcc.target/xtensa/elim_GP_regmove.c
b/gcc/testsuite/gcc.target/xtensa/elim_GP_regmove.c
new file mode 100644
index 000..2f0d71d12bd
--- /dev/null
+++ b/gcc/testsuite/gcc.target/xtensa/elim_GP_regmove.c
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fpeephole2" } */
+
+/* processed */
+double test0(double a, double b) {
+ return __builtin_copysign(a, b);
+}
+
+/* excluded: the source operands have '0' constraint. */
+int test1(int a, int b) {
+ int c;
+ asm volatile ("" : "=a"(c) : "r"(a), "0"(b));
+ return c;
+}
+
+/* excluded: the destination operand has '&' constraint. */
+int test2(int a) {
+ int b;
+ asm volatile ("" : "=&a"(b) : "r"(a));
+ return b;
+}
+
+/* { dg-final { scan-assembler-times "mov\t|mov.n\t" 2 } } */
--
2.30.2
[PATCH v5] xtensa: Eliminate the use of callee-saved register that saves and restores only once
In the case of the CALL0 ABI, values that must be retained before and
after function calls are placed in the callee-saved registers (A12
through A15) and referenced later. However, it is often the case that
the save and the reference are each only once and a simple register-
register move (with two exceptions; i. the register saved to/restored
from is the stack pointer, ii. the function needs an additional stack
pointer adjustment to grow the stack).
e.g. in the following example, if there are no other occurrences of
register A14:
;; before
; prologue {
...
s32i.n a14, sp, 16
... ;; no frame pointer needed
;; no additional stack growth
; } prologue
...
mov.n a14, a6 ;; A6 is not SP
...
call0 foo
...
mov.n a8, a14 ;; A8 is not SP
...
; epilogue {
...
l32i.n a14, sp, 16
...
; } epilogue
It can be possible like this:
;; after
; prologue {
...
(no save needed)
...
; } prologue
...
s32i.n a6, sp, 16 ;; replaced with A14's slot
...
call0 foo
...
l32i.n a8, sp, 16 ;; through SP
...
; epilogue {
...
(no restoration needed)
...
; } epilogue
This patch adds the abovementioned logic to the function prologue/epilogue
RTL expander code.
gcc/ChangeLog:
* config/xtensa/xtensa.cc (machine_function): Add new member
'eliminated_callee_saved_bmp'.
(xtensa_can_eliminate_callee_saved_reg_p): New function to
determine whether the register can be eliminated or not.
(xtensa_expand_prologue): Add invoking the above function and
elimination the use of callee-saved register by using its stack
slot through the stack pointer (or the frame pointer if needed)
directly.
(xtensa_expand_prologue): Modify to not emit register restoration
insn from its stack slot if the register is already eliminated.
gcc/testsuite/ChangeLog:
* gcc.target/xtensa/elim_callee_saved.c: New.
---
gcc/config/xtensa/xtensa.cc | 130 ++
.../gcc.target/xtensa/elim_callee_saved.c | 32 +
2 files changed, 137 insertions(+), 25 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/xtensa/elim_callee_saved.c
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index 3e2e22d4cbe..a639f019d9c 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -105,6 +105,7 @@ struct GTY(()) machine_function
bool epilogue_done;
bool inhibit_logues_a1_adjusts;
rtx last_logues_a9_content;
+ HOST_WIDE_INT eliminated_callee_saved_bmp;
};
static void xtensa_option_override (void);
@@ -3343,6 +3344,64 @@ xtensa_emit_adjust_stack_ptr (HOST_WIDE_INT offset, int
flags)
cfun->machine->last_logues_a9_content = GEN_INT (offset);
}
+static bool
+xtensa_can_eliminate_callee_saved_reg_p (unsigned int regno,
+rtx_insn **p_insnS,
+rtx_insn **p_insnR)
+{
+ df_ref ref;
+ rtx_insn *insn, *insnS = NULL, *insnR = NULL;
+ rtx pattern;
+
+ if (!df || call_used_or_fixed_reg_p (regno))
+return false;
+
+ for (ref = DF_REG_DEF_CHAIN (regno);
+ ref; ref = DF_REF_NEXT_REG (ref))
+if (DF_REF_CLASS (ref) != DF_REF_REGULAR
+ || DEBUG_INSN_P (insn = DF_REF_INSN (ref)))
+ continue;
+else if (GET_CODE (pattern = PATTERN (insn)) == SET
+&& REG_P (SET_DEST (pattern))
+&& REGNO (SET_DEST (pattern)) == regno
+&& REG_P (SET_SRC (pattern))
+&& REGNO (SET_SRC (pattern)) != A1_REG)
+ {
+ if (insnS)
+ return false;
+ insnS = insn;
+ continue;
+ }
+else
+ return false;
+
+ for (ref = DF_REG_USE_CHAIN (regno);
+ ref; ref = DF_REF_NEXT_REG (ref))
+if (DF_REF_CLASS (ref) != DF_REF_REGULAR
+ || DEBUG_INSN_P (insn = DF_REF_INSN (ref)))
+ continue;
+else if (GET_CODE (pattern = PATTERN (insn)) == SET
+&& REG_P (SET_SRC (pattern))
+&& REGNO (SET_SRC (pattern)) == regno
+&& REG_P (SET_DEST (pattern))
+&& REGNO (SET_DEST (pattern)) != A1_REG)
+ {
+ if (insnR)
+ return false;
+ insnR = insn;
+ continue;
+ }
+else
+ return false;
+
+ if (!insnS || !insnR)
+return false;
+
+ *p_insnS = insnS, *p_insnR = insnR;
+
+ return true;
+}
+
/* minimum frame = reg save area (4 words) plus static chain (1 word)
and the total number of words must be a multiple of 128 bits. */
#define MIN_FRAME_SIZE (8 * UNITS_PER_WORD)
@@ -3382,6 +3441,7 @@ xtensa_expand_prologue (void)
df_ref ref;
bool stack_pointer_needed = frame_pointer_needed
|| crtl->calls_eh_return;
+ bool large_stack_needed;
/* C
[pushed] c++: TARGET_EXPR collapsing [PR107303]
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In r13-2978 I tried to eliminate TARGET_EXPR around TARGET_EXPR by
discarding the outer one, but as in this testcase that breaks if the
TARGET_EXPR_SLOT of the outer one is used elsewhere. But it should always
be safe to strip the inner one; if its slot were reused, there would be a
COMPOUND_EXPR around the TARGET_EXPR.
For 107329, if we're setting *walk_subtrees, we also need to fold
TARGET_EXPR_CLEANUP.
PR c++/107303
PR c++/107329
gcc/cp/ChangeLog:
* cp-gimplify.cc (cp_fold_r) [TARGET_EXPR]: In case of double
TARGET_EXPR, keep the outer one instead of the inner one.
(maybe_replace_decl): New.
gcc/testsuite/ChangeLog:
* g++.dg/ext/builtin-shufflevector-5.C: New test.
* g++.dg/init/new51.C: New test.
---
gcc/cp/cp-gimplify.cc | 31 +--
.../g++.dg/ext/builtin-shufflevector-5.C | 14 +
gcc/testsuite/g++.dg/init/new51.C | 10 ++
3 files changed, 52 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/ext/builtin-shufflevector-5.C
create mode 100644 gcc/testsuite/g++.dg/init/new51.C
diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
index 83ba1285bfd..92cd309e670 100644
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -952,6 +952,28 @@ cp_genericize_target_expr (tree *stmt_p)
gcc_assert (!DECL_INITIAL (slot));
}
+/* Similar to if (target_expr_needs_replace) replace_decl, but TP is the
+ TARGET_EXPR_INITIAL, and this also updates *_SLOT. We need this extra
+ replacement when cp_folding TARGET_EXPR to preserve the invariant that
+ AGGR_INIT_EXPR_SLOT agrees with the enclosing TARGET_EXPR_SLOT. */
+
+bool
+maybe_replace_decl (tree *tp, tree decl, tree replacement)
+{
+ if (!*tp || !VOID_TYPE_P (TREE_TYPE (*tp)))
+return false;
+ tree t = *tp;
+ while (TREE_CODE (t) == COMPOUND_EXPR)
+t = TREE_OPERAND (t, 1);
+ if (TREE_CODE (t) == AGGR_INIT_EXPR)
+replace_decl (&AGGR_INIT_EXPR_SLOT (t), decl, replacement);
+ else if (TREE_CODE (t) == VEC_INIT_EXPR)
+replace_decl (&VEC_INIT_EXPR_SLOT (t), decl, replacement);
+ else
+replace_decl (tp, decl, replacement);
+ return true;
+}
+
/* Genericization context. */
struct cp_genericize_data
@@ -1116,15 +1138,18 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void
*data_)
cp_genericize_target_expr (stmt_p);
/* Folding might replace e.g. a COND_EXPR with a TARGET_EXPR; in
-that case, use it in place of this one. */
+that case, strip it in favor of this one. */
if (tree &init = TARGET_EXPR_INITIAL (stmt))
{
cp_walk_tree (&init, cp_fold_r, data, NULL);
+ cp_walk_tree (&TARGET_EXPR_CLEANUP (stmt), cp_fold_r, data, NULL);
*walk_subtrees = 0;
if (TREE_CODE (init) == TARGET_EXPR)
{
- TARGET_EXPR_ELIDING_P (init) = TARGET_EXPR_ELIDING_P (stmt);
- *stmt_p = init;
+ tree sub = TARGET_EXPR_INITIAL (init);
+ maybe_replace_decl (&sub, TARGET_EXPR_SLOT (init),
+ TARGET_EXPR_SLOT (stmt));
+ init = sub;
}
}
break;
diff --git a/gcc/testsuite/g++.dg/ext/builtin-shufflevector-5.C
b/gcc/testsuite/g++.dg/ext/builtin-shufflevector-5.C
new file mode 100644
index 000..06472b8d86b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/builtin-shufflevector-5.C
@@ -0,0 +1,14 @@
+// PR c++/107303
+// { dg-options "-Wno-psabi" }
+
+typedef __attribute__((__vector_size__ (2))) unsigned short U;
+typedef __attribute__((__vector_size__ (8))) unsigned short V;
+
+U u0, u1, u2;
+V v;
+
+void
+foo (void)
+{
+ u0 *= +__builtin_shufflevector (__builtin_shufflevector (u1, v, 3, 1), u2,
0);
+}
diff --git a/gcc/testsuite/g++.dg/init/new51.C
b/gcc/testsuite/g++.dg/init/new51.C
new file mode 100644
index 000..d8b336476d9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/init/new51.C
@@ -0,0 +1,10 @@
+// PR c++/107329
+
+struct RexxClass {
+ void *operator new(unsigned long, unsigned long, const char *, RexxClass *,
+ RexxClass *);
+ void operator delete(void *, unsigned long, const char *, RexxClass *,
+ RexxClass *);
+ RexxClass();
+};
+void createInstance() { new (sizeof(RexxClass), "", 0, 0) RexxClass; }
base-commit: 4cbc71691e47b1ca6b64feb0af678606705d2f92
--
2.31.1
[pushed] c++: TARGET_EXPR_ELIDING_P and std::move [PR107267]
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
With -ffold-simple-inlines, we turn calls to std::move into the static_cast
equivalent. In this testcase, this exposes the FindResult temporary to copy
elision which is not specified by the standard, through an optimization in
gimplify_modify_expr_rhs. Since the type is not TREE_ADDRESSABLE, this is
not detectable by the user, so we just need to soften the assert.
PR c++/107267
gcc/cp/ChangeLog:
* cp-gimplify.cc (cp_gimplify_init_expr): Allow unexpected elision
of trivial types.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/move2.C: New test.
---
gcc/cp/cp-gimplify.cc | 5 -
gcc/testsuite/g++.dg/cpp0x/move2.C | 14 ++
2 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/move2.C
diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
index 340b4641046..83ba1285bfd 100644
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -250,7 +250,10 @@ cp_gimplify_init_expr (tree *expr_p)
if (TREE_CODE (from) == TARGET_EXPR)
if (tree init = TARGET_EXPR_INITIAL (from))
{
- gcc_checking_assert (TARGET_EXPR_ELIDING_P (from));
+ /* Make sure that we expected to elide this temporary. But also allow
+ gimplify_modify_expr_rhs to elide temporaries of trivial type. */
+ gcc_checking_assert (TARGET_EXPR_ELIDING_P (from)
+|| !TREE_ADDRESSABLE (TREE_TYPE (from)));
if (target_expr_needs_replace (from))
{
/* If this was changed by cp_genericize_target_expr, we need to
diff --git a/gcc/testsuite/g++.dg/cpp0x/move2.C
b/gcc/testsuite/g++.dg/cpp0x/move2.C
new file mode 100644
index 000..b8c8683c4d2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/move2.C
@@ -0,0 +1,14 @@
+// PR c++/107267
+// { dg-do compile { target c++11 } }
+// { dg-additional-options -ffold-simple-inlines }
+
+namespace std {
+ template _Tp &&move(_Tp &&);
+}
+
+struct FindResult {
+ FindResult();
+ int result;
+};
+
+FindResult pop_ret = std::move(FindResult());
base-commit: 72e46b3c7ad5e3d2c69868a510c00707c356106a
--
2.31.1
[PATCH] tree-optimization/108306 - Correctly detect shifts out of range
get_shift_range was incorrectly communicating that it couldn't calculate
a range when the shift value was out of range.
Fix this and always return a range of [0, 0] instead of varying when the
shift value is out of range.
Bootstraps with no regressions on x86_64-pc-linux-gnu. OK for trunk?
Andrew
From 5500762bacffd7b45a0bfa8f89333e955734820f Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Mon, 16 Jan 2023 15:02:51 -0500
Subject: [PATCH 3/3] Correctly detect shifts out of range
get_shift_range was incorrectly communicating that it couldn't calculate
a range when the shift values was always out fo range. Fix this and
alwasy return [0, 0] when the shift value is always out of range.
PR tree-optimization/108306
gcc/
* range-op.cc (operator_lshift::fold_range): Return [0, 0] not
varying for shifts that are always out of void range.
(operator_rshift::fold_range): Return [0, 0] not
varying for shifts that are always out of void range.
gcc/testsuite/
* gcc.dg/pr108306.c: New.
---
gcc/range-op.cc | 4 ++--
gcc/testsuite/gcc.dg/pr108306.c | 29 +
2 files changed, 31 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/pr108306.c
diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index ec75e07bc8a..6e5754e9130 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -2166,7 +2166,7 @@ operator_lshift::fold_range (irange &r, tree type,
if (op2.undefined_p ())
r.set_undefined ();
else
- r.set_varying (type);
+ r.set_zero (type);
return true;
}
@@ -2440,7 +2440,7 @@ operator_rshift::fold_range (irange &r, tree type,
if (op2.undefined_p ())
r.set_undefined ();
else
- r.set_varying (type);
+ r.set_zero (type);
return true;
}
diff --git a/gcc/testsuite/gcc.dg/pr108306.c b/gcc/testsuite/gcc.dg/pr108306.c
new file mode 100644
index 000..1044c646de7
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr108306.c
@@ -0,0 +1,29 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-strict-overflow -fsanitize=shift -Warray-bounds" } */
+
+enum psi_task_count {
+ NR_IOWAIT,
+ NR_PSI_TASK_COUNTS = 4,
+};
+
+unsigned int tasks[NR_PSI_TASK_COUNTS];
+
+static void psi_group_change(unsigned int set)
+{
+ unsigned int t;
+ unsigned int state_mask = 0;
+
+ for (t = 0; set; set &= ~(1 << t), t++)
+ if (set & (1 << t))
+ tasks[t]++;
+}
+
+void psi_task_switch(int sleep)
+{
+ int set = 0;
+
+ if (sleep)
+ set |= (1 << NR_IOWAIT);
+
+ psi_group_change(set);
+}
--
2.39.0
Re: [PATCH 2/4] libbacktrace: detect executable path on windows
On Fri, Jan 20, 2023 at 2:56 AM Björn Schäpers wrote:
>
> From: Björn Schäpers
>
> This is actually needed so that libstdc++'s implementation
> to be able to work on windows.
>
> Tested on x86_64-linux and i686-w64-mingw32.
>
> -- >8 --
>
> * configure.ac: Add a check for windows.h.
> * configure, config.h.in: Regenerate.
> * fileline.c: Add windows_get_executable_path.
> * fileline.c (fileline_initialiez): Add a pass using
> windows_get_executable_path.
>
> +#ifdef HAVE_WINDOWS_H
> +
> +static char *
> +windows_get_executable_path (char *buf, backtrace_error_callback
> error_callback,
> +void *data)
> +{
> + if (GetModuleFileNameA (NULL, buf, MAX_PATH - 1) == 0)
> +{
> + error_callback (data,
> + "could not get the filename of the current executable",
> + (int) GetLastError ());
> + return NULL;
> +}
> + return buf;
> +}
Thanks, but this seems incomplete. The docs for GetModuleFileNameA
say that if the pathname is too long to fit into the buffer it returns
the size of the buffer and sets the error to
ERROR_INSUFFICIENT_BUFFER. It seems to me that in that case we should
allocate a larger buffer and try again. And, in general, it will be
simpler if we always allocate the buffer, as macho_get_executable_path
does. Unfortunately it appears that Windows does not provide a way to
ask for the required length. On Windows it seems that MAX_PATH is not
a true limit, as an extended length path may be up to 32767 bytes.
So probably something like (untested)
static char *
windows_get_executable_path (struct backtrace_state *state,
backtrace_error_callback error_callback,
void *data)
{
uint32_t len;
char *buf;
len = MAX_PATH;
while (1)
{
uint32_t got;
name = (char *) backtrace_alloc (state, len, error_callback, data);
if (name == NULL)
return NULL;
got = GetModuleFileNameA (NULL, name, len);
if (got < len - 1) /* -1 because NULB is not counted */
return name;
backtrace_free (state, name, len, error_callback, data);
if (GetLastError () != ERROR_INSUFFICIENT_BUFFER)
return NULL;
len *= 2;
}
}
Ian
Re: [PATCH] Fortran: fix NULL pointer dereference in gfc_check_dependency [PR108502]
On Mon, Jan 23, 2023 at 10:23:54PM +0100, Harald Anlauf via Fortran wrote: > > the code in the PR demonstrates that dependency checking in the > frontend optimization was not recovering well from invalid code, > leading to a NULL pointer dereference. An easy and really obvious > fix. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. I agree patch looks obvious once the issue is found. Thanks for the patch. -- Steve
Re: [PATCH] Fortran: fix NULL pointer dereference in gfc_check_dependency [PR108502]
Hi Harald, the code in the PR demonstrates that dependency checking in the frontend optimization was not recovering well from invalid code, leading to a NULL pointer dereference. An easy and really obvious fix. Regtested on x86_64-pc-linux-gnu. OK for mainline? Yes indeed (and I would not have minded if you had indeed committed it as obvious and simple). Thanks for the patch! Best regards Thomas
Re: [PATCH] c++: Quash bogus -Wunused-value with new [PR107797]
On 1/23/23 16:28, Marek Polacek wrote:
On Fri, Jan 20, 2023 at 02:37:19PM -0500, Jason Merrill wrote:
On 1/19/23 21:03, Marek Polacek wrote:
We shouldn't emit "right operand of comma operator has no effect"
when that comma operator was created by the compiler for "new int{}".
convert_to_void/COMPOUND_EXPR already checks warning_suppressed_p so
we can just suppress -Wunused-value.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/107797
gcc/cp/ChangeLog:
* cvt.cc (ocp_convert): copy_warning when creating a new
COMPOUND_EXPR.
* init.cc (build_new_1): Suppress -Wunused-value on
compiler-generated COMPOUND_EXPRs.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wunused-value-1.C: New test.
---
gcc/cp/cvt.cc | 6 --
gcc/cp/init.cc | 2 ++
gcc/testsuite/g++.dg/warn/Wunused-value-1.C | 12
3 files changed, 18 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/warn/Wunused-value-1.C
diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc
index f816c474cef..52e96fbe590 100644
--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -3800,6 +3800,8 @@ build_new_1 (vec **placement, tree type,
tree nelts,
if (cookie_expr)
rval = build2 (COMPOUND_EXPR, TREE_TYPE (rval), cookie_expr, rval);
+ suppress_warning (rval, OPT_Wunused_value);
This makes sense, but IIUC since rval is built with no location, this just
sets nowarning_flag?
Correct (I didn't realize this when writing the patch). There's another
suppress_warning on a location-less expr just a few lines above.
if (rval == data_addr && TREE_CODE (alloc_expr) == TARGET_EXPR)
/* If we don't have an initializer or a cookie, strip the TARGET_EXPR
and return the call (which doesn't need to be adjusted). */
diff --git a/gcc/cp/cvt.cc b/gcc/cp/cvt.cc
index 0cbfd8060cb..17827d06a4a 100644
--- a/gcc/cp/cvt.cc
+++ b/gcc/cp/cvt.cc
@@ -711,8 +711,10 @@ ocp_convert (tree type, tree expr, int convtype, int flags,
return error_mark_node;
if (e == TREE_OPERAND (expr, 1))
return expr;
- return build2_loc (EXPR_LOCATION (expr), COMPOUND_EXPR, TREE_TYPE (e),
-TREE_OPERAND (expr, 0), e);
+ e = build2_loc (EXPR_LOCATION (expr), COMPOUND_EXPR, TREE_TYPE (e),
+ TREE_OPERAND (expr, 0), e);
+ copy_warning (e, expr);
And so I don't know what effect this would have; copy_warning doesn't seem
to propagate nowarning_flag, which seems like a bug.
It actually does propagate nowarning_flag: in copy_warning we have
219 /* The no-warning bit might be set even if the map has not been
consulted, or
220 otherwise if there's no entry in the map. */
221 set_no_warning_bit (to, supp);
so 'e' ends up with TREE_NO_WARNING set.
Ah, yes. Pesky overloaded functions.
I would not think we want to build 'rval' in build_new_1 with a location
or use TREE_NO_WARNING directly instead of suppress_warning so I'm leaving
the patch as-is, but please let me know if you disagree.
Agreed, the patch is OK.
Jason
Re: [PATCH] c++: Quash bogus -Wunused-value with new [PR107797]
On Fri, Jan 20, 2023 at 02:37:19PM -0500, Jason Merrill wrote:
> On 1/19/23 21:03, Marek Polacek wrote:
> > We shouldn't emit "right operand of comma operator has no effect"
> > when that comma operator was created by the compiler for "new int{}".
> > convert_to_void/COMPOUND_EXPR already checks warning_suppressed_p so
> > we can just suppress -Wunused-value.
> >
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > PR c++/107797
> >
> > gcc/cp/ChangeLog:
> >
> > * cvt.cc (ocp_convert): copy_warning when creating a new
> > COMPOUND_EXPR.
> > * init.cc (build_new_1): Suppress -Wunused-value on
> > compiler-generated COMPOUND_EXPRs.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/warn/Wunused-value-1.C: New test.
> > ---
> > gcc/cp/cvt.cc | 6 --
> > gcc/cp/init.cc | 2 ++
> > gcc/testsuite/g++.dg/warn/Wunused-value-1.C | 12
> > 3 files changed, 18 insertions(+), 2 deletions(-)
> > create mode 100644 gcc/testsuite/g++.dg/warn/Wunused-value-1.C
> >
> > diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc
> > index f816c474cef..52e96fbe590 100644
> > --- a/gcc/cp/init.cc
> > +++ b/gcc/cp/init.cc
> > @@ -3800,6 +3800,8 @@ build_new_1 (vec **placement, tree type,
> > tree nelts,
> > if (cookie_expr)
> > rval = build2 (COMPOUND_EXPR, TREE_TYPE (rval), cookie_expr, rval);
> > + suppress_warning (rval, OPT_Wunused_value);
>
> This makes sense, but IIUC since rval is built with no location, this just
> sets nowarning_flag?
Correct (I didn't realize this when writing the patch). There's another
suppress_warning on a location-less expr just a few lines above.
> > if (rval == data_addr && TREE_CODE (alloc_expr) == TARGET_EXPR)
> > /* If we don't have an initializer or a cookie, strip the TARGET_EXPR
> > and return the call (which doesn't need to be adjusted). */
> > diff --git a/gcc/cp/cvt.cc b/gcc/cp/cvt.cc
> > index 0cbfd8060cb..17827d06a4a 100644
> > --- a/gcc/cp/cvt.cc
> > +++ b/gcc/cp/cvt.cc
> > @@ -711,8 +711,10 @@ ocp_convert (tree type, tree expr, int convtype, int
> > flags,
> > return error_mark_node;
> >if (e == TREE_OPERAND (expr, 1))
> > return expr;
> > - return build2_loc (EXPR_LOCATION (expr), COMPOUND_EXPR, TREE_TYPE
> > (e),
> > -TREE_OPERAND (expr, 0), e);
> > + e = build2_loc (EXPR_LOCATION (expr), COMPOUND_EXPR, TREE_TYPE (e),
> > + TREE_OPERAND (expr, 0), e);
> > + copy_warning (e, expr);
>
> And so I don't know what effect this would have; copy_warning doesn't seem
> to propagate nowarning_flag, which seems like a bug.
It actually does propagate nowarning_flag: in copy_warning we have
219 /* The no-warning bit might be set even if the map has not been
consulted, or
220 otherwise if there's no entry in the map. */
221 set_no_warning_bit (to, supp);
so 'e' ends up with TREE_NO_WARNING set.
I would not think we want to build 'rval' in build_new_1 with a location
or use TREE_NO_WARNING directly instead of suppress_warning so I'm leaving
the patch as-is, but please let me know if you disagree.
Marek
[PATCH] Fortran: fix NULL pointer dereference in gfc_check_dependency [PR108502]
Dear all,
the code in the PR demonstrates that dependency checking in the
frontend optimization was not recovering well from invalid code,
leading to a NULL pointer dereference. An easy and really obvious
fix.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From d27e1b13ba312411ce271f5122f694ffe6c051e6 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 23 Jan 2023 22:13:44 +0100
Subject: [PATCH] Fortran: fix NULL pointer dereference in gfc_check_dependency
[PR108502]
gcc/fortran/ChangeLog:
PR fortran/108502
* dependency.cc (gfc_check_dependency): Prevent NULL pointer
dereference while recursively checking expressions.
gcc/testsuite/ChangeLog:
PR fortran/108502
* gfortran.dg/pr108502.f90: New test.
---
gcc/fortran/dependency.cc | 5 +
gcc/testsuite/gfortran.dg/pr108502.f90 | 12
2 files changed, 17 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/pr108502.f90
diff --git a/gcc/fortran/dependency.cc b/gcc/fortran/dependency.cc
index 43417a6ec76..9117825ee6e 100644
--- a/gcc/fortran/dependency.cc
+++ b/gcc/fortran/dependency.cc
@@ -1292,6 +1292,11 @@ gfc_check_dependency (gfc_expr *expr1, gfc_expr *expr2, bool identical)
if (expr1->expr_type != EXPR_VARIABLE)
gfc_internal_error ("gfc_check_dependency: expecting an EXPR_VARIABLE");
+ /* Prevent NULL pointer dereference while recursively analyzing invalid
+ expressions. */
+ if (expr2 == NULL)
+return 0;
+
switch (expr2->expr_type)
{
case EXPR_OP:
diff --git a/gcc/testsuite/gfortran.dg/pr108502.f90 b/gcc/testsuite/gfortran.dg/pr108502.f90
new file mode 100644
index 000..45f73849c57
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr108502.f90
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! { dg-options "-O2 -ffrontend-optimize" }
+! PR fortran/108502 - ICE in gfc_check_dependency
+! Contributed by G.Steinmetz
+
+integer function n()
+ integer :: a(1)
+ a = [1] / 0
+end
+program p
+ integer :: b = n() ! { dg-error "must be an intrinsic function" }
+end
--
2.35.3
[pushed] c++: vector of class with bool ctor [PR108195]
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The transformation done by r13-4564 to use the iterator constructor instead
of the initializer-list constructor breaks if the iterator pointers are
themselves treated as elements of an initializer-list, so check for that.
PR c++/108195
gcc/cp/ChangeLog:
* call.cc (build_user_type_conversion_1): Check whether the
iterators also find a list ctor.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-vect2.C: New test.
---
gcc/cp/call.cc | 2 +-
gcc/testsuite/g++.dg/cpp0x/initlist-vect2.C | 16
2 files changed, 17 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-vect2.C
diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index a7de0e8e9a6..5715a7cd1de 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -4581,7 +4581,7 @@ build_user_type_conversion_1 (tree totype, tree expr, int
flags,
if (tree iters = maybe_init_list_as_range (cand->fn, expr))
if (z_candidate *cand2
= build_user_type_conversion_1 (totype, iters, flags, tf_none))
- if (cand2->viable == 1)
+ if (cand2->viable == 1 && !is_list_ctor (cand2->fn))
{
cand = cand2;
expr = iters;
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-vect2.C
b/gcc/testsuite/g++.dg/cpp0x/initlist-vect2.C
new file mode 100644
index 000..eec7d340fd1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-vect2.C
@@ -0,0 +1,16 @@
+// PR c++/108195
+// { dg-do run { target c++11 } }
+
+#include
+
+struct S
+{
+ S(bool) {}
+};
+
+int main()
+{
+ std::vector v = { true, false, true };
+ if (v.size() != 3)
+__builtin_abort ();
+}
base-commit: 4b125d01a5d5e601961419396332b74eea2219bb
--
2.31.1
Re: [PATCH] Fortran: avoid ICE on invalid array subscript triplets [PR108501]
On Mon, Jan 23, 2023 at 09:34:59PM +0100, Harald Anlauf via Fortran wrote: > > we did not check array element triplets for validity strictly enough > (i.e. defensively in the case of invalid code), so we could encounter > non-integer constant expressions that were passed to mpz_get_si. > > The attached obvious patch tries to fix all such potential issues > in get_expr_storage_size. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Yes. Thanks for the patch. -- Steve
[PATCH] Fortran: avoid ICE on invalid array subscript triplets [PR108501]
Dear all,
we did not check array element triplets for validity strictly enough
(i.e. defensively in the case of invalid code), so we could encounter
non-integer constant expressions that were passed to mpz_get_si.
The attached obvious patch tries to fix all such potential issues
in get_expr_storage_size.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 771d793df1622a476e1cf8d05f0a6aee350fa56b Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 23 Jan 2023 21:19:03 +0100
Subject: [PATCH] Fortran: avoid ICE on invalid array subscript triplets
[PR108501]
gcc/fortran/ChangeLog:
PR fortran/108501
* interface.cc (get_expr_storage_size): Check array subscript triplets
that we actually have integer values before trying to extract with
mpz_get_si.
gcc/testsuite/ChangeLog:
PR fortran/108501
* gfortran.dg/pr108501.f90: New test.
---
gcc/fortran/interface.cc | 23 ---
gcc/testsuite/gfortran.dg/pr108501.f90 | 14 ++
2 files changed, 30 insertions(+), 7 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr108501.f90
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index 9593fa83c45..dafe41753b7 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -2910,7 +2910,8 @@ get_expr_storage_size (gfc_expr *e)
if (ref->u.ar.stride[i])
{
- if (ref->u.ar.stride[i]->expr_type == EXPR_CONSTANT)
+ if (ref->u.ar.stride[i]->expr_type == EXPR_CONSTANT
+ && ref->u.ar.stride[i]->ts.type == BT_INTEGER)
stride = mpz_get_si (ref->u.ar.stride[i]->value.integer);
else
return 0;
@@ -2918,26 +2919,30 @@ get_expr_storage_size (gfc_expr *e)
if (ref->u.ar.start[i])
{
- if (ref->u.ar.start[i]->expr_type == EXPR_CONSTANT)
+ if (ref->u.ar.start[i]->expr_type == EXPR_CONSTANT
+ && ref->u.ar.start[i]->ts.type == BT_INTEGER)
start = mpz_get_si (ref->u.ar.start[i]->value.integer);
else
return 0;
}
else if (ref->u.ar.as->lower[i]
- && ref->u.ar.as->lower[i]->expr_type == EXPR_CONSTANT)
+ && ref->u.ar.as->lower[i]->expr_type == EXPR_CONSTANT
+ && ref->u.ar.as->lower[i]->ts.type == BT_INTEGER)
start = mpz_get_si (ref->u.ar.as->lower[i]->value.integer);
else
return 0;
if (ref->u.ar.end[i])
{
- if (ref->u.ar.end[i]->expr_type == EXPR_CONSTANT)
+ if (ref->u.ar.end[i]->expr_type == EXPR_CONSTANT
+ && ref->u.ar.end[i]->ts.type == BT_INTEGER)
end = mpz_get_si (ref->u.ar.end[i]->value.integer);
else
return 0;
}
else if (ref->u.ar.as->upper[i]
- && ref->u.ar.as->upper[i]->expr_type == EXPR_CONSTANT)
+ && ref->u.ar.as->upper[i]->expr_type == EXPR_CONSTANT
+ && ref->u.ar.as->upper[i]->ts.type == BT_INTEGER)
end = mpz_get_si (ref->u.ar.as->upper[i]->value.integer);
else
return 0;
@@ -2978,7 +2983,9 @@ get_expr_storage_size (gfc_expr *e)
|| ref->u.ar.as->upper[i] == NULL
|| ref->u.ar.as->lower[i] == NULL
|| ref->u.ar.as->upper[i]->expr_type != EXPR_CONSTANT
- || ref->u.ar.as->lower[i]->expr_type != EXPR_CONSTANT)
+ || ref->u.ar.as->lower[i]->expr_type != EXPR_CONSTANT
+ || ref->u.ar.as->upper[i]->ts.type != BT_INTEGER
+ || ref->u.ar.as->lower[i]->ts.type != BT_INTEGER)
return 0;
elements
@@ -3000,7 +3007,9 @@ get_expr_storage_size (gfc_expr *e)
{
if (!as->upper[i] || !as->lower[i]
|| as->upper[i]->expr_type != EXPR_CONSTANT
- || as->lower[i]->expr_type != EXPR_CONSTANT)
+ || as->lower[i]->expr_type != EXPR_CONSTANT
+ || as->upper[i]->ts.type != BT_INTEGER
+ || as->lower[i]->ts.type != BT_INTEGER)
return 0;
elements = elements
diff --git a/gcc/testsuite/gfortran.dg/pr108501.f90 b/gcc/testsuite/gfortran.dg/pr108501.f90
new file mode 100644
index 000..09ab8c9f34f
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr108501.f90
@@ -0,0 +1,14 @@
+! { dg-do compile }
+! PR fortran/108501 - ICE in get_expr_storage_size
+! Contributed by G.Steinmetz
+
+program p
+ real, parameter :: n = 2
+ real :: a(1,(n),2) ! { dg-error "must be of INTEGER type" }
+ call s(a(:,:,1))
+end
+subroutine s(x)
+ real :: x(2)
+end
+
+! { dg-prune-output "must have constant shape" }
--
2.35.3
Re: [PATCH 1/4] libbacktrace: change all pc related variables to uintptr_t
Am 20.01.2023 um 23:25 schrieb Ian Lance Taylor: On Fri, Jan 20, 2023 at 2:54 AM Björn Schäpers wrote: From: Björn Schäpers It's the right thing to do, since the PC shouldn't go out of the uintptr_t domain, and in backtrace_pcinfo the pc is uintptr_t. This is a preparation for a following patch. Tested on x86_64-linux and i686-w64-mingw32. Thanks. Committed like so, with some additional tweaks. For future reference, when pinging a patch, please reply to the original patch to maintain the thread. Or at least mention the original patch. It was still on my list, I just hadn't gotten to it. Thanks. Ian Thanks for the commit, and sorry for the repost. Because of a fault of my own I had no copy in my mailbox and thus couldn't reply to the first batch. Regards, Björn.
[pushed] c++: result location and explicit inst [PR108496]
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In r13-4469 we started to build the RESULT_DECL in grokdeclarator, while we
still know the location of the return type. But in this testcase, we hit
that code again when parsing the explicit instantiation, and clobber the
DECL_RESULT that was previously used in parsing the function. So, only set
DECL_RESULT if it isn't already set.
PR c++/108496
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator): Check whether DECL_RESULT is already
set.
gcc/testsuite/ChangeLog:
* g++.dg/template/explicit-instantiation5.C: New test.
---
gcc/cp/decl.cc| 6 +-
.../g++.dg/template/explicit-instantiation5.C | 15 +++
2 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/template/explicit-instantiation5.C
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 75ddf8016b5..d606b31d7a7 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -14776,7 +14776,9 @@ grokdeclarator (const cp_declarator *declarator,
{
/* If we saw a return type, record its location. */
location_t loc = declspecs->locations[ds_type_spec];
- if (loc != UNKNOWN_LOCATION)
+ if (loc == UNKNOWN_LOCATION)
+ /* Build DECL_RESULT in start_preparsed_function. */;
+ else if (!DECL_RESULT (decl))
{
tree restype = TREE_TYPE (TREE_TYPE (decl));
tree resdecl = build_decl (loc, RESULT_DECL, 0, restype);
@@ -14784,6 +14786,8 @@ grokdeclarator (const cp_declarator *declarator,
DECL_IGNORED_P (resdecl) = 1;
DECL_RESULT (decl) = resdecl;
}
+ else if (funcdef_flag)
+ DECL_SOURCE_LOCATION (DECL_RESULT (decl)) = loc;
}
/* Record constancy and volatility on the DECL itself . There's
diff --git a/gcc/testsuite/g++.dg/template/explicit-instantiation5.C
b/gcc/testsuite/g++.dg/template/explicit-instantiation5.C
new file mode 100644
index 000..7bc007c8107
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/explicit-instantiation5.C
@@ -0,0 +1,15 @@
+// PR c++/108496
+
+struct S { long a, b, c; } s;
+
+template
+S foo (S);
+
+template <>
+S
+foo <0, long> (S)
+{
+ return s;
+}
+
+template S foo <0, long> (S);
base-commit: 208c6678c25bd9a11e6c5911a4c123cb6b7f3d6e
--
2.31.1
Re: [PATCH] IBM zSystems: Fix TARGET_D_CPU_VERSIONS
On Mon, Jan 23, 2023 at 02:21:46PM +0100, Iain Buclaw wrote: > Excerpts from Stefan Schulze Frielinghaus via Gcc-patches's message of Januar > 13, 2023 6:54 pm: > > In the context of D the interpretation of S390, S390X, and SystemZ is a > > bit fuzzy. The wording S390X was wrongly deprecated in favour of > > SystemZ by commit > > https://github.com/dlang/dlang.org/commit/3b50a4c3faf01c32234d0ef8be5f82915a61c23f > > Thus, SystemZ is used for 64-bit targets, now, and S390 for 31-bit > > targets. However, in TARGET_D_CPU_VERSIONS depending on TARGET_ZARCH we > > set the CPU version to SystemZ. This is also the case if compiled for > > 31-bit targets leading to the following error: > > > > libphobos/libdruntime/core/sys/posix/sys/stat.d:967:13: error: static > > assert: '96u == 144u' is false > > 967 | static assert(stat_t.sizeof == 144); > > | ^ > > > > So that I follow, there are three possible combinations? > > ESA 31-bit (S390) > ESA 64-bit (what was S390X) > z/Arch 64-bit (SystemZ) There are three combinations: - s390: 32-bit ABI and ESA mode - s390: 32-bit ABI and z/Architecture mode - s390x: 64-bit ABI and z/Architecture mode Note, depending on the CPU mode z/Architecture is supported by the 32- and 64-bit ABI whereas ESA is only supported by the 32-bit ABI. Thus, s390 always refers to the 32-bit ABI but does not fix the instructions set architecture (ESA or z/Architecture). Whereas s390x refers to the 64-bit ABI for which only z/Architecture exists. While nitpicking, typically the target is written in lower case letters, i.e., not S390X but s390x and likewise s390 instead of S390. Hope this clarifies the set of possible combinations. Let me know if anything else is unclear. > > > Thus in order to keep this patch simple I went for keeping SystemZ for > > 64-bit targets and S390, as usual, for 31-bit targets and dropped the > > distinction between ESA and z/Architecture. > > > > Bootstrapped and regtested on IBM zSystems. Ok for mainline? > > > > OK by me. Maybe keep both S390X and SystemZ for TARGET_64BIT? There's > only ever been a binary distinction as far as I'm aware. Sounds good to me. I will come up with an updated patch. Cheers, Stefan
[PATCH] doc/invoke.texi: remove Cygwin options from Windows options
remove remnant of Cygwin options from x86 Windows options summary
in doc/invoke.texi
Cygwin objects, functions, and options details were removed in 2010-10-07
commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=3edeb30d044a4852881c34229e618b34f95b0d9e#patch8
leaving only this remnant
---
gcc/doc/invoke.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 06d77983e30f..38a7a3b1f830 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1454,7 +1454,7 @@ See RS/6000 and PowerPC Options.
-munroll-only-small-loops -mlam=@var{choice}}
@emph{x86 Windows Options}
-@gccoptlist{-mconsole -mcygwin -mno-cygwin -mdll @gol
+@gccoptlist{-mconsole -mdll @gol
-mnop-fun-dllimport -mthread @gol
-municode -mwin32 -mwindows -fno-set-stack-executable}
Re: [PATCH][_GLIBCXX_DEBUG] Remove useless checks
On Mon, 23 Jan 2023 at 18:15, François Dumont wrote: > > On 23/01/23 10:22, Jonathan Wakely wrote: > > On Mon, 23 Jan 2023 at 06:02, François Dumont via Libstdc++ > > wrote: > >> libstdc++: [_GLIBCXX_DEBUG] Remove useless constructor checks > >> > >> Creating a safe iterator from a normal iterator is done within the > >> library where we > >> already know that it is done correctly. The rare situation where a > >> user would use safe > >> iterators for his own purpose is non-Standard code so outside > >> _GLIBCXX_DEBUG scope. For > >> those reasons the __msg_init_singular is useless and can be removed. > >> > >> Additionally in the copy constructor used for post-increment and > >> post-decrement operators > >> the __msg_init_copy_singular check can also be ommitted because of > >> the preliminary > >> __msg_bad_inc and __msg_bad_dec checks. > >> > >> libstdc++-v3/ChangeLog: > >> > >> * include/debug/safe_iterator.h > >> (_Safe_iterator<>::_Unsafe_call): New. > > I don't like the name "unsafe call". Why is it unsafe? As you say > > above, we don't need to check because we know that it's only called in > > a context where it's safe. Can we call it _Unchecked instead of > > _Unsafe_call? That seems like a more accurate description of the > > behaviour. > > > > > >> (_Safe_iterator(const _Safe_iterator&, _Unsafe_call): New. > >> (_Safe_iterator::operator++(int)): Use latter. > >> (_Safe_iterator::operator--(int)): Likewise. > >> (_Safe_iterator(_Iterator, const _Safe_sequence_base*)): > >> Remove !_M_insular() > >> check. > >> * include/debug/safe_local_iterator.h > >> (_Safe_local_iterator<>::_Unsafe_call): > >> New. > >> (_Safe_local_iterator(const _Safe_local_iterator&, > >> _Unsafe_call): New. > >> (_Safe_local_iterator::operator++(int)): Use latter. > >> * src/c++11/debug.cc (_S_debug_messages): Add as comment > >> the _Debug_msg_id > >> entry associated to the array entry. > > These comments are a great idea, thanks. > > > > If you agree with the _Unchecked name, OK to commit with that change. > > > It's unsafe because it's unchecked so _Unchecked is fine for me too :-) But it doesn't need to be checked, because we know it's safe in all the places that it's used. So it's not unsafe :-) In some industries the words "safe" and "unsafe" have special meaning. Calling something "unsafe" when actually it's "safe by construction" will just raise red flags and unnecessary pain if an automated audit scans for the word "unsafe". Some poor person will have to fill out a form to say "it's not unsafe, it's just called that in the code" to be able to use the code. > Committed with the requested change. Great, thanks.
Re: [PATCH][_GLIBCXX_DEBUG] Remove useless checks
On 23/01/23 10:22, Jonathan Wakely wrote: On Mon, 23 Jan 2023 at 06:02, François Dumont via Libstdc++ wrote: libstdc++: [_GLIBCXX_DEBUG] Remove useless constructor checks Creating a safe iterator from a normal iterator is done within the library where we already know that it is done correctly. The rare situation where a user would use safe iterators for his own purpose is non-Standard code so outside _GLIBCXX_DEBUG scope. For those reasons the __msg_init_singular is useless and can be removed. Additionally in the copy constructor used for post-increment and post-decrement operators the __msg_init_copy_singular check can also be ommitted because of the preliminary __msg_bad_inc and __msg_bad_dec checks. libstdc++-v3/ChangeLog: * include/debug/safe_iterator.h (_Safe_iterator<>::_Unsafe_call): New. I don't like the name "unsafe call". Why is it unsafe? As you say above, we don't need to check because we know that it's only called in a context where it's safe. Can we call it _Unchecked instead of _Unsafe_call? That seems like a more accurate description of the behaviour. (_Safe_iterator(const _Safe_iterator&, _Unsafe_call): New. (_Safe_iterator::operator++(int)): Use latter. (_Safe_iterator::operator--(int)): Likewise. (_Safe_iterator(_Iterator, const _Safe_sequence_base*)): Remove !_M_insular() check. * include/debug/safe_local_iterator.h (_Safe_local_iterator<>::_Unsafe_call): New. (_Safe_local_iterator(const _Safe_local_iterator&, _Unsafe_call): New. (_Safe_local_iterator::operator++(int)): Use latter. * src/c++11/debug.cc (_S_debug_messages): Add as comment the _Debug_msg_id entry associated to the array entry. These comments are a great idea, thanks. If you agree with the _Unchecked name, OK to commit with that change. It's unsafe because it's unchecked so _Unchecked is fine for me too :-) Committed with the requested change. Thanks
Re: [PATCH 2/2] tree-optimization/108447 - Add VREL_OTHER for FP unsupported relations.
Sorry should have mention the PR On 1/23/23 12:44, Andrew MacLeod wrote: This patch adds VREL_OTHER to represent another relation we do not understand. It is used to represent the class fo relations arising from floating point that are currently not represented. IN GCC 14 we will determine exactly how to represent them, but for this release, this should prevent us from getting things wrong at least. if intersection produces UNDEFINED and either of the relations feeding it were <, <=, >, or >= then it turns it to VR_OTHER. the prevents false sides of branches from combining to produce UNDEFINED when they end up being a known NAN. Union is adjusted such that < >, or <= >= also produce VREL_OTHER. < > cannot be properly represented, and <= >= was producing VARYING, which is also not correct. Form the testcase: : cmp1_10 = x_8(D) <= y_9(D); cmp2_11 = x_8(D) >= y_9(D); _3 = cmp1_10 & cmp2_11; if (_3 != 0) goto ; [INV] else goto ; [INV] Relational : (x_8(D) == y_9(D)) : // predicted unlikely by early return (on trees) predictor. goto ; [INV] : _4 = ~cmp1_10; _5 = ~cmp2_11; _1 = cmp1_10 | cmp2_11; _6 = ~_1; if (_1 != 0) goto ; [INV] else goto ; [INV] Relational : (x_8(D) unknown fp y_9(D)) : // predicted unlikely by early return (on trees) predictor. The intersection "fix" is represented by the relation between x and y in BB5. Without the patch, ti would be UNDEFINED and we do not want that. The union fix is what prevents us from folding the condition in bb_4. Without it, x<=y union x >=y comes out VARYING, when in fact I believe it represents everything except a NAN. So with this fix, all the unrepresentative relations get lumped into VREL_OTHER so we at least don't get it wrong. For next release we can take the time to figure out exactly how we want to proceed. This is currently in testing on x86_64-pc-linux-gnu, and assuming it bootstraps with no regressions (a combined patch did before splitting it in 2), OK for trunk? OR does it need more tweaking? Andrew
[PATCH 2/2] Add VREL_OTHER for FP unsupported relations.
This patch adds VREL_OTHER to represent another relation we do not
understand. It is used to represent the class fo relations arising from
floating point that are currently not represented. IN GCC 14 we will
determine exactly how to represent them, but for this release, this
should prevent us from getting things wrong at least.
if intersection produces UNDEFINED and either of the relations feeding
it were <, <=, >, or >= then it turns it to VR_OTHER. the prevents
false sides of branches from combining to produce UNDEFINED when they
end up being a known NAN.
Union is adjusted such that < >, or <= >= also produce VREL_OTHER. < >
cannot be properly represented, and <= >= was producing VARYING, which
is also not correct.
Form the testcase:
:
cmp1_10 = x_8(D) <= y_9(D);
cmp2_11 = x_8(D) >= y_9(D);
_3 = cmp1_10 & cmp2_11;
if (_3 != 0)
goto ; [INV]
else
goto ; [INV]
Relational : (x_8(D) == y_9(D))
:
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]
:
_4 = ~cmp1_10;
_5 = ~cmp2_11;
_1 = cmp1_10 | cmp2_11;
_6 = ~_1;
if (_1 != 0)
goto ; [INV]
else
goto ; [INV]
Relational : (x_8(D) unknown fp y_9(D))
:
// predicted unlikely by early return (on trees) predictor.
The intersection "fix" is represented by the relation between x and y in
BB5. Without the patch, ti would be UNDEFINED and we do not want that.
The union fix is what prevents us from folding the condition in bb_4.
Without it, x<=y union x >=y comes out VARYING, when in fact I believe
it represents everything except a NAN.
So with this fix, all the unrepresentative relations get lumped into
VREL_OTHER so we at least don't get it wrong. For next release we can
take the time to figure out exactly how we want to proceed.
This is currently in testing on x86_64-pc-linux-gnu, and assuming it
bootstraps with no regressions (a combined patch did before splitting it
in 2), OK for trunk? OR does it need more tweaking?
Andrew
From 6947cfa03098eee46669ec2902e5f6e33c3cbe9a Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 20 Jan 2023 17:31:26 -0500
Subject: [PATCH 2/2] Add VREL_OTHER for FP unsupported relations.
Add VREL_OTHER to represent floating point relations we do not yet
support.
PR tree-optimization/108447
gcc/
* value-relation.cc (kind_string): Add "unknown fp".
(rr_negate_table): Add entry for VREL_OTHER.
(rr_swap_table): Likewise.
(rr_intersect_table): Likewise.
(rr_union_table): Likewise.
(rr_transitive_table): Likewise.
(relation_to_code): Likewise.
(value_relation::intersect): Handle floating point differences.
(value_relation::union_): Likewise.
* value-relation.h (enum relation_kind_t): Add VREL_OTHER.
gcc/testsuite/
* gcc.dg/pr108447.c: New.
---
gcc/testsuite/gcc.dg/pr108447.c | 33 +
gcc/value-relation.cc | 118 +---
gcc/value-relation.h| 1 +
3 files changed, 113 insertions(+), 39 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/pr108447.c
diff --git a/gcc/testsuite/gcc.dg/pr108447.c b/gcc/testsuite/gcc.dg/pr108447.c
new file mode 100644
index 000..cfbaba6d0aa
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr108447.c
@@ -0,0 +1,33 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+__attribute__((noipa)) int
+foo (float x, float y)
+{
+ _Bool cmp1 = x <= y;
+ _Bool cmp2 = x >= y;
+ if (cmp1 && cmp2)
+return 1;
+ else if (!cmp1 && !cmp2)
+return -1;
+ return 0;
+}
+
+int
+main ()
+{
+ if (foo (0.0f, __builtin_nanf ("")) != -1)
+__builtin_abort ();
+ if (foo (__builtin_nanf (""), -42.0f) != -1)
+__builtin_abort ();
+ if (foo (0.0f, -0.0f) != 1)
+__builtin_abort ();
+ if (foo (42.0f, 42.0f) != 1)
+__builtin_abort ();
+ if (foo (42.0f, -0.0f) != 0)
+__builtin_abort ();
+ if (foo (0.0f, -42.0f) != 0)
+__builtin_abort ();
+ return 0;
+}
+
diff --git a/gcc/value-relation.cc b/gcc/value-relation.cc
index 432828e2b13..299a119827a 100644
--- a/gcc/value-relation.cc
+++ b/gcc/value-relation.cc
@@ -33,8 +33,8 @@ along with GCC; see the file COPYING3. If not see
#include "dominance.h"
static const char *kind_string[VREL_LAST] =
-{ "varying", "undefined", "<", "<=", ">", ">=", "==", "!=", "pe8", "pe16",
- "pe32", "pe64" };
+{ "varying", "undefined", "<", "<=", ">", ">=", "==", "!=", "unknown fp",
+ "pe8", "pe16", "pe32", "pe64" };
// Print a relation_kind REL to file F.
@@ -47,7 +47,7 @@ print_relation (FILE *f, relation_kind rel)
// This table is used to negate the operands. op1 REL op2 -> !(op1 REL op2).
relation_kind rr_negate_table[VREL_LAST] = {
VREL_VARYING, VREL_UNDEFINED, VREL_GE, VREL_GT, VREL_LE, VREL_LT, VREL_NE,
- VREL_EQ };
+ VREL_EQ, VREL_OTHER };
// Negate the relation, as in logical negation.
@@ -60,7 +60,7 @@ relation_negate (relation_kind r)
// This table is used to swap the operands. op1 REL op2 -> op2 REL op1.
re
[PATCH 1/2] Use value_relation class instead of direct calls to intersect/union.
In order to fix 108447, this patch changes the calls to relation_union
and relation_intersection to instead utilize the value_relation class,
and make the calls through that instead.
value_relation manages the operands of a relation, and thus understands
whether this is a floating point relation and can make any adjustments
required to get the proper results. THis patch doesn't do anything
additional, just that isolation so we can track if it introduces
anything speerate from the next change which adds another relation.
Bootstraps on x86_64-pc-linux-gnu with no regressions. OK?
Andrew
From 566421cb3b91272b56b01ff9ad5a243cada38ff7 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Fri, 20 Jan 2023 17:13:08 -0500
Subject: [PATCH 1/2] Use value_relation class instead of direct calls to
intersect/union.
There are subtle differences how union and intersection behave depending
on whetehr the operands are float or integral. Directly calling
relation_union or relation_intersect does not expose the origin of the
operands, but value_relation does have them.
THis patch makes sure calls are through the value relation class.
* gimple-range-fold.cc (fold_using_range::relation_fold_and_or):
Call union and intersect through a value_relation class.
* value-relation.cc (value_relation::intersect): Make parameter
const.
(value_relation::union_): Likewise.
(dom_oracle::set_one_relation): Use value-relation class for
union and intersect.
(path_oracle::register_relation): Likewise.
* value-relation.h (value_relation::intersect): Add const to param.
(value_relation::union_): Likewise.
---
gcc/gimple-range-fold.cc | 17 +
gcc/value-relation.cc| 17 -
gcc/value-relation.h | 4 ++--
3 files changed, 15 insertions(+), 23 deletions(-)
diff --git a/gcc/gimple-range-fold.cc b/gcc/gimple-range-fold.cc
index 91eb6298254..500c482eeec 100644
--- a/gcc/gimple-range-fold.cc
+++ b/gcc/gimple-range-fold.cc
@@ -1039,14 +1039,6 @@ fold_using_range::relation_fold_and_or (irange& lhs_range, gimple *s,
if (!ssa1_dep1 || !ssa1_dep2 || !ssa2_dep1 || !ssa2_dep2)
return;
- // Make sure they are the same dependencies, and detect the order of the
- // relationship.
- bool reverse_op2 = true;
- if (ssa1_dep1 == ssa2_dep1 && ssa1_dep2 == ssa2_dep2)
-reverse_op2 = false;
- else if (ssa1_dep1 != ssa2_dep2 || ssa1_dep2 != ssa2_dep1)
-return;
-
int_range<2> bool_one (boolean_true_node, boolean_true_node);
relation_kind relation1 = handler1.op1_op2_relation (bool_one);
@@ -1054,15 +1046,16 @@ fold_using_range::relation_fold_and_or (irange& lhs_range, gimple *s,
if (relation1 == VREL_VARYING || relation2 == VREL_VARYING)
return;
- if (reverse_op2)
-relation2 = relation_negate (relation2);
+ value_relation vr1 (relation1, ssa1_dep1, ssa1_dep2);
+ value_relation vr2 (relation2, ssa2_dep1, ssa2_dep2);
+ // Only one of the follwoing intersection/unions is performed.
// x && y is false if the relation intersection of the true cases is NULL.
- if (is_and && relation_intersect (relation1, relation2) == VREL_UNDEFINED)
+ if (is_and && vr1.intersect (vr2) && vr1.kind () == VREL_UNDEFINED)
lhs_range = int_range<2> (boolean_false_node, boolean_false_node);
// x || y is true if the union of the true cases is NO-RELATION..
// ie, one or the other being true covers the full range of possibilties.
- else if (!is_and && relation_union (relation1, relation2) == VREL_VARYING)
+ else if (!is_and && vr1.union_ (vr2) && vr1.kind () == VREL_VARYING)
lhs_range = bool_one;
else
return;
diff --git a/gcc/value-relation.cc b/gcc/value-relation.cc
index 6f8a1b7e7d3..432828e2b13 100644
--- a/gcc/value-relation.cc
+++ b/gcc/value-relation.cc
@@ -782,7 +782,7 @@ value_relation::negate ()
// Perform an intersection between 2 relations. *this &&= p.
bool
-value_relation::intersect (value_relation &p)
+value_relation::intersect (const value_relation &p)
{
// Save previous value
relation_kind old = related;
@@ -800,7 +800,7 @@ value_relation::intersect (value_relation &p)
// Perform a union between 2 relations. *this ||= p.
bool
-value_relation::union_ (value_relation &p)
+value_relation::union_ (const value_relation &p)
{
// Save previous value
relation_kind old = related;
@@ -1118,8 +1118,7 @@ dom_oracle::set_one_relation (basic_block bb, relation_kind k, tree op1,
// will be the aggregate of all the previous ones.
curr = find_relation_dom (bb, v1, v2);
if (curr != VREL_VARYING)
- k = relation_intersect (curr, k);
-
+ vr.intersect (value_relation (curr, op1, op2));
bitmap_set_bit (bm, v1);
bitmap_set_bit (bm, v2);
bitmap_set_bit (m_relation_set, v1);
@@ -1127,7 +1126,7 @@ dom_oracle::set_one_relation (basic_block bb, relation_kind k, tree op1,
ptr = (relation_chain *) obstack_alloc (&m_chain_obstack,
sizeof (relation_chain));
- ptr->set_relation (k, op1,
Re: [aarch64] Use wzr/xzr for assigning vector element to 0
Prathamesh Kulkarni writes:
> On Wed, 18 Jan 2023 at 19:59, Richard Sandiford
> wrote:
>>
>> Prathamesh Kulkarni writes:
>> > On Tue, 17 Jan 2023 at 18:29, Richard Sandiford
>> > wrote:
>> >>
>> >> Prathamesh Kulkarni writes:
>> >> > Hi Richard,
>> >> > For the following (contrived) test:
>> >> >
>> >> > void foo(int32x4_t v)
>> >> > {
>> >> > v[3] = 0;
>> >> > return v;
>> >> > }
>> >> >
>> >> > -O2 code-gen:
>> >> > foo:
>> >> > fmovs1, wzr
>> >> > ins v0.s[3], v1.s[0]
>> >> > ret
>> >> >
>> >> > I suppose we can instead emit the following code-gen ?
>> >> > foo:
>> >> > ins v0.s[3], wzr
>> >> > ret
>> >> >
>> >> > combine produces:
>> >> > Failed to match this instruction:
>> >> > (set (reg:V4SI 95 [ v ])
>> >> > (vec_merge:V4SI (const_vector:V4SI [
>> >> > (const_int 0 [0]) repeated x4
>> >> > ])
>> >> > (reg:V4SI 97)
>> >> > (const_int 8 [0x8])))
>> >> >
>> >> > So, I wrote the following pattern to match the above insn:
>> >> > (define_insn "aarch64_simd_vec_set_zero"
>> >> > [(set (match_operand:VALL_F16 0 "register_operand" "=w")
>> >> > (vec_merge:VALL_F16
>> >> > (match_operand:VALL_F16 1 "const_dup0_operand" "w")
>> >> > (match_operand:VALL_F16 3 "register_operand" "0")
>> >> > (match_operand:SI 2 "immediate_operand" "i")))]
>> >> > "TARGET_SIMD"
>> >> > {
>> >> > int elt = ENDIAN_LANE_N (, exact_log2 (INTVAL
>> >> > (operands[2])));
>> >> > operands[2] = GEN_INT ((HOST_WIDE_INT) 1 << elt);
>> >> > return "ins\\t%0.[%p2], wzr";
>> >> > }
>> >> > )
>> >> >
>> >> > which now matches the above insn produced by combine.
>> >> > However, in reload dump, it creates a new insn for assigning
>> >> > register to (const_vector (const_int 0)),
>> >> > which results in:
>> >> > (insn 19 8 13 2 (set (reg:V4SI 33 v1 [99])
>> >> > (const_vector:V4SI [
>> >> > (const_int 0 [0]) repeated x4
>> >> > ])) "wzr-test.c":8:1 1269 {*aarch64_simd_movv4si}
>> >> > (nil))
>> >> > (insn 13 19 14 2 (set (reg/i:V4SI 32 v0)
>> >> > (vec_merge:V4SI (reg:V4SI 33 v1 [99])
>> >> > (reg:V4SI 32 v0 [97])
>> >> > (const_int 8 [0x8]))) "wzr-test.c":8:1 1808
>> >> > {aarch64_simd_vec_set_zerov4si}
>> >> > (nil))
>> >> >
>> >> > and eventually the code-gen:
>> >> > foo:
>> >> > moviv1.4s, 0
>> >> > ins v0.s[3], wzr
>> >> > ret
>> >> >
>> >> > To get rid of redundant assignment of 0 to v1, I tried to split the
>> >> > above pattern
>> >> > as in the attached patch. This works to emit code-gen:
>> >> > foo:
>> >> > ins v0.s[3], wzr
>> >> > ret
>> >> >
>> >> > However, I am not sure if this is the right approach. Could you suggest,
>> >> > if it'd be possible to get rid of UNSPEC_SETZERO in the patch ?
>> >>
>> >> The problem is with the "w" constraint on operand 1, which tells LRA
>> >> to force the zero into an FPR. It should work if you remove the
>> >> constraint.
>> > Ah indeed, sorry about that, changing the constrained works.
>>
>> "i" isn't right though, because that's for scalar integers.
>> There's no need for any constraint here -- the predicate does
>> all of the work.
>>
>> > Does the attached patch look OK after bootstrap+test ?
>> > Since we're in stage-4, shall it be OK to commit now, or queue it for
>> > stage-1 ?
>>
>> It needs tests as well. :-)
>>
>> Also:
>>
>> > Thanks,
>> > Prathamesh
>> >
>> >
>> >>
>> >> Also, I think you'll need to use zr for the zero, so that
>> >> it uses xzr for 64-bit elements.
>> >>
>> >> I think this and the existing patterns ought to test
>> >> exact_log2 (INTVAL (operands[2])) >= 0 in the insn condition,
>> >> since there's no guarantee that RTL optimisations won't form
>> >> vec_merges that have other masks.
>> >>
>> >> Thanks,
>> >> Richard
>> >
>> > [aarch64] Use wzr/xzr for assigning 0 to vector element.
>> >
>> > gcc/ChangeLog:
>> > * config/aaarch64/aarch64-simd.md (aarch64_simd_vec_set_zero):
>> > New pattern.
>> > * config/aarch64/predicates.md (const_dup0_operand): New.
>> >
>> > diff --git a/gcc/config/aarch64/aarch64-simd.md
>> > b/gcc/config/aarch64/aarch64-simd.md
>> > index 104088f67d2..8e54ee4e886 100644
>> > --- a/gcc/config/aarch64/aarch64-simd.md
>> > +++ b/gcc/config/aarch64/aarch64-simd.md
>> > @@ -1083,6 +1083,20 @@
>> >[(set_attr "type" "neon_ins, neon_from_gp,
>> > neon_load1_one_lane")]
>> > )
>> >
>> > +(define_insn "aarch64_simd_vec_set_zero"
>> > + [(set (match_operand:VALL_F16 0 "register_operand" "=w")
>> > + (vec_merge:VALL_F16
>> > + (match_operand:VALL_F16 1 "const_dup0_operand" "i")
>> > + (match_operand:VALL_F16 3 "register_operand" "0")
>> > + (match_operand:SI 2 "immediate_operand" "i")))]
>> > + "TARGET_SIMD && exact_log2 (INTVAL (operands[2])) >= 0"
>> > + {
>> > +int elt = ENDIAN_LANE_N (, exact_log2 (
Re: [PATCH] file-prefix-map: Fix up -f*-prefix-map= [PR108464]
On Fri, Jan 20, 2023 at 04:05:55PM +0100, Jakub Jelinek via Gcc-patches wrote: > I'm attaching 3 so far just compile tested patches. So far successfully bootstrapped/regtested the first and third patches, both on x86_64-linux and i686-linux. Jakub
Re: [PATCH] modula-2: Fix stack size request in initPreemptive [PR108405]
Iain Sandoe writes: > Given that, currently, this value is not configurable per target the > short-term solution is to avoid a bad request. > > Tested on x86_64-darwin21, OK for trunk? > thanks > Iain Hi Iain, yes this is fine. LGTM - thanks regards, Gaius
Re: [PATCH] c++, cgraphbuild: Handle DECL_VALUE_EXPRs in record_reference [PR108474]
On Mon, 23 Jan 2023, Jakub Jelinek wrote:
> On Mon, Jan 23, 2023 at 12:37:59PM +, Richard Biener wrote:
> > Guess it should work. Do we (accidentially?) do anything special
> > to static var initializers in nested functions?
>
> I don't think we touch those, we walk the bodies of functions, I don't
> think we traverse static var DECL_INITIALs.
>
> > Can you think of
> > any other C/C++ construct that would have DECL_VALUE_EXPR in them?
>
> A lot of them, coroutines, FE NRV, anon union vars, lambdas,
> in modules, OpenMP privatized members, structured bindings,
> __FUNCTION__ etc., later VLAs, tree-nested, OpenMP lowering.
>
> But anon union vars and structured bindings are the only ones
> known for which this is actually needed in static initializers.
> I'm afraid no idea about modules case, for OpenMP one needs executable
> code, tried the __FUNCTION__ case and while there is DECL_VALUE_EXPR
> used, the initializer is already replaced by STRING_CST in the FE somewhere,
> VLAs aren't allowed.
>
> BTW, the patch successfully passed bootstrap/regtested on x86_64-linux and
> i686-linux.
So let's try and revert quickly if any odd fallout appears?
Richard.
>
> > > 2023-01-23 Jakub Jelinek
> > >
> > > PR c++/108474
> > > * cgraphbuild.cc: Include gimplify.h.
> > > (record_reference): Replace VAR_DECLs with DECL_HAS_VALUE_EXPR_P with
> > > their corresponding DECL_VALUE_EXPR expressions after unsharing.
> > >
> > > * cp-gimplify.cc (cp_fold_r): Revert 2023-01-19 changes.
> > >
> > > * g++.dg/cpp1z/decomp57.C: New test.
> > > * g++.dg/cpp1z/decomp58.C: New test.
> > >
> > > --- gcc/cgraphbuild.cc.jj 2023-01-02 09:32:34.889104620 +0100
> > > +++ gcc/cgraphbuild.cc2023-01-23 12:10:35.042067571 +0100
> > > @@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.
> > > #include "gimple-walk.h"
> > > #include "ipa-utils.h"
> > > #include "except.h"
> > > +#include "gimplify.h"
> > >
> > > /* Context of record_reference. */
> > > struct record_reference_ctx
> > > @@ -79,6 +80,17 @@ record_reference (tree *tp, int *walk_su
> > >
> > >if (VAR_P (decl))
> > > {
> > > + /* Replace vars with their DECL_VALUE_EXPR if any.
> > > + This is normally done during gimplification, but
> > > + static var initializers are never gimplified. */
> > > + if (DECL_HAS_VALUE_EXPR_P (decl))
> > > + {
> > > + tree *p;
> > > + for (p = tp; *p != decl; p = &TREE_OPERAND (*p, 0))
> > > + ;
> > > + *p = unshare_expr (DECL_VALUE_EXPR (decl));
> > > + return record_reference (tp, walk_subtrees, data);
> > > + }
> > > varpool_node *vnode = varpool_node::get_create (decl);
> > > ctx->varpool_node->create_reference (vnode, IPA_REF_ADDR);
> > > }
> > > --- gcc/cp/cp-gimplify.cc.jj 2023-01-23 11:47:49.889875804 +0100
> > > +++ gcc/cp/cp-gimplify.cc 2023-01-23 11:49:01.227841759 +0100
> > > @@ -1010,16 +1010,6 @@ cp_fold_r (tree *stmt_p, int *walk_subtr
> > > }
> > >break;
> > >
> > > -case VAR_DECL:
> > > - /* In initializers replace anon union artificial VAR_DECLs
> > > - with their DECL_VALUE_EXPRs, as nothing will do it later. */
> > > - if (DECL_ANON_UNION_VAR_P (stmt) && !data->genericize)
> > > - {
> > > - *stmt_p = stmt = unshare_expr (DECL_VALUE_EXPR (stmt));
> > > - break;
> > > - }
> > > - break;
> > > -
> > > default:
> > >break;
> > > }
> > > --- gcc/testsuite/g++.dg/cpp1z/decomp57.C.jj 2023-01-23
> > > 11:48:36.367202107 +0100
> > > +++ gcc/testsuite/g++.dg/cpp1z/decomp57.C 2023-01-23 11:48:36.367202107
> > > +0100
> > > @@ -0,0 +1,27 @@
> > > +// PR c++/108474
> > > +// { dg-do link { target c++17 } }
> > > +
> > > +struct T { int i, j; };
> > > +T h;
> > > +auto [i, j] = h;
> > > +int &r = i;
> > > +int s = i;
> > > +int *t = &i;
> > > +
> > > +void
> > > +foo (int **p, int *q)
> > > +{
> > > + static int &u = i;
> > > + static int v = i;
> > > + static int *w = &i;
> > > + int &x = i;
> > > + int y = i;
> > > + int *z = &i;
> > > + *p = &i;
> > > + *q = i;
> > > +}
> > > +
> > > +int
> > > +main ()
> > > +{
> > > +}
> > > --- gcc/testsuite/g++.dg/cpp1z/decomp58.C.jj 2023-01-23
> > > 11:48:36.367202107 +0100
> > > +++ gcc/testsuite/g++.dg/cpp1z/decomp58.C 2023-01-23 11:48:36.367202107
> > > +0100
> > > @@ -0,0 +1,39 @@
> > > +// PR c++/108474
> > > +// { dg-do link { target c++17 } }
> > > +
> > > +namespace std {
> > > + template struct tuple_size;
> > > + template struct tuple_element;
> > > +}
> > > +
> > > +struct A {
> > > + int i;
> > > + template int& get() { return i; }
> > > +};
> > > +
> > > +template <> struct std::tuple_size { static const int value = 2; };
> > > +template struct std::tuple_element { using type = int; };
> > > +
> > > +struct A a;
> > > +auto [i, j] = a;
> > > +int &r = i;
> > > +int s = i;
> > > +int *t = &i;
> > > +
> > > +void
> > > +foo (int **p, int *q)
> > > +{
> > > + static int &u = i;
>
Re: [PATCH] modula-2, driver, Front end: Revise handling of I and L paths [PR108182].
Iain Sandoe writes: > Tested on x86_64-linux-gnu (with a 32b multilib), powerpc, i686 and > x86_64-darwin. OK for trunk? > thanks, > Iain > > --- 8< --- > > The adds the includes in the FE as done in other GCC languages. > It also revises the library handling to avoid additional -L options > from hiding LIBDIR. > > For the include/import paths as presented to the front end initialisation, > we capture them and then arrange to emit the 'standard library' paths in > the same order as specified for C. > > The specs are tidied up. yes LGTM - apologies for the delay thank you! Gaius
Re: [PATCH] c++, cgraphbuild: Handle DECL_VALUE_EXPRs in record_reference [PR108474]
On Mon, Jan 23, 2023 at 12:37:59PM +, Richard Biener wrote:
> Guess it should work. Do we (accidentially?) do anything special
> to static var initializers in nested functions?
I don't think we touch those, we walk the bodies of functions, I don't
think we traverse static var DECL_INITIALs.
> Can you think of
> any other C/C++ construct that would have DECL_VALUE_EXPR in them?
A lot of them, coroutines, FE NRV, anon union vars, lambdas,
in modules, OpenMP privatized members, structured bindings,
__FUNCTION__ etc., later VLAs, tree-nested, OpenMP lowering.
But anon union vars and structured bindings are the only ones
known for which this is actually needed in static initializers.
I'm afraid no idea about modules case, for OpenMP one needs executable
code, tried the __FUNCTION__ case and while there is DECL_VALUE_EXPR
used, the initializer is already replaced by STRING_CST in the FE somewhere,
VLAs aren't allowed.
BTW, the patch successfully passed bootstrap/regtested on x86_64-linux and
i686-linux.
> > 2023-01-23 Jakub Jelinek
> >
> > PR c++/108474
> > * cgraphbuild.cc: Include gimplify.h.
> > (record_reference): Replace VAR_DECLs with DECL_HAS_VALUE_EXPR_P with
> > their corresponding DECL_VALUE_EXPR expressions after unsharing.
> >
> > * cp-gimplify.cc (cp_fold_r): Revert 2023-01-19 changes.
> >
> > * g++.dg/cpp1z/decomp57.C: New test.
> > * g++.dg/cpp1z/decomp58.C: New test.
> >
> > --- gcc/cgraphbuild.cc.jj 2023-01-02 09:32:34.889104620 +0100
> > +++ gcc/cgraphbuild.cc 2023-01-23 12:10:35.042067571 +0100
> > @@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.
> > #include "gimple-walk.h"
> > #include "ipa-utils.h"
> > #include "except.h"
> > +#include "gimplify.h"
> >
> > /* Context of record_reference. */
> > struct record_reference_ctx
> > @@ -79,6 +80,17 @@ record_reference (tree *tp, int *walk_su
> >
> >if (VAR_P (decl))
> > {
> > + /* Replace vars with their DECL_VALUE_EXPR if any.
> > +This is normally done during gimplification, but
> > +static var initializers are never gimplified. */
> > + if (DECL_HAS_VALUE_EXPR_P (decl))
> > + {
> > + tree *p;
> > + for (p = tp; *p != decl; p = &TREE_OPERAND (*p, 0))
> > + ;
> > + *p = unshare_expr (DECL_VALUE_EXPR (decl));
> > + return record_reference (tp, walk_subtrees, data);
> > + }
> > varpool_node *vnode = varpool_node::get_create (decl);
> > ctx->varpool_node->create_reference (vnode, IPA_REF_ADDR);
> > }
> > --- gcc/cp/cp-gimplify.cc.jj2023-01-23 11:47:49.889875804 +0100
> > +++ gcc/cp/cp-gimplify.cc 2023-01-23 11:49:01.227841759 +0100
> > @@ -1010,16 +1010,6 @@ cp_fold_r (tree *stmt_p, int *walk_subtr
> > }
> >break;
> >
> > -case VAR_DECL:
> > - /* In initializers replace anon union artificial VAR_DECLs
> > -with their DECL_VALUE_EXPRs, as nothing will do it later. */
> > - if (DECL_ANON_UNION_VAR_P (stmt) && !data->genericize)
> > - {
> > - *stmt_p = stmt = unshare_expr (DECL_VALUE_EXPR (stmt));
> > - break;
> > - }
> > - break;
> > -
> > default:
> >break;
> > }
> > --- gcc/testsuite/g++.dg/cpp1z/decomp57.C.jj2023-01-23
> > 11:48:36.367202107 +0100
> > +++ gcc/testsuite/g++.dg/cpp1z/decomp57.C 2023-01-23 11:48:36.367202107
> > +0100
> > @@ -0,0 +1,27 @@
> > +// PR c++/108474
> > +// { dg-do link { target c++17 } }
> > +
> > +struct T { int i, j; };
> > +T h;
> > +auto [i, j] = h;
> > +int &r = i;
> > +int s = i;
> > +int *t = &i;
> > +
> > +void
> > +foo (int **p, int *q)
> > +{
> > + static int &u = i;
> > + static int v = i;
> > + static int *w = &i;
> > + int &x = i;
> > + int y = i;
> > + int *z = &i;
> > + *p = &i;
> > + *q = i;
> > +}
> > +
> > +int
> > +main ()
> > +{
> > +}
> > --- gcc/testsuite/g++.dg/cpp1z/decomp58.C.jj2023-01-23
> > 11:48:36.367202107 +0100
> > +++ gcc/testsuite/g++.dg/cpp1z/decomp58.C 2023-01-23 11:48:36.367202107
> > +0100
> > @@ -0,0 +1,39 @@
> > +// PR c++/108474
> > +// { dg-do link { target c++17 } }
> > +
> > +namespace std {
> > + template struct tuple_size;
> > + template struct tuple_element;
> > +}
> > +
> > +struct A {
> > + int i;
> > + template int& get() { return i; }
> > +};
> > +
> > +template <> struct std::tuple_size { static const int value = 2; };
> > +template struct std::tuple_element { using type = int; };
> > +
> > +struct A a;
> > +auto [i, j] = a;
> > +int &r = i;
> > +int s = i;
> > +int *t = &i;
> > +
> > +void
> > +foo (int **p, int *q)
> > +{
> > + static int &u = i;
> > + static int v = i;
> > + static int *w = &i;
> > + int &x = i;
> > + int y = i;
> > + int *z = &i;
> > + *p = &i;
> > + *q = i;
> > +}
> > +
> > +int
> > +main ()
> > +{
> > +}
Jakub
Re: Ping^3: [PATCH] d: Update __FreeBSD_version values [PR107469]
Excerpts from Lorenzo Salvadore's message of Januar 10, 2023 5:10 pm: > Hello, > > Ping https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605685.html > > I would like to remind that Gerald Pfeifer already volunteered to commit this > patch > when it is approved. However the patch has not been approved yet. > Hi, sorry for belated reply. Yes is fine for now, I'm concerned that it'll just be the same again come FreeBSD 15, 16, 17... There needs to be a better mechanism to determine which FreeBSD version is being compiled for, but that shouldn't block this going in. OK.
[Committed][GCC] arm: Documentation fix for -mbranch-protection option.
Hello,
This patch fixes the documentation for -mbranch-protection command line option.
Committed this patch to trunk as obvious fix.
Regards,
Srinath.
gcc/ChangeLog:
2023-01-23 Srinath Parvathaneni
* doc/invoke.texi (-mbranch-protection): Update documentation.
### Attachment also inlined for ease of reply###
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index
f1c0b52012b8979070c265b7978810afe4601047..06d77983e30fff39886f360920fdfc521d2f69e4
100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -22564,8 +22564,7 @@ The opposite @option{-mno-fdpic} option is useful (and
required) to
build the Linux kernel using the same (@code{arm-*-uclinuxfdpiceabi})
toolchain as the one used to build the userland programs.
-@item
--mbranch-protection=@var{none}|@var{standard}|@var{pac-ret}[+@var{leaf}][+@var{bti}]|@var{bti}[+@var{pac-ret}[+@var{leaf}]]
+@item
-mbranch-protection=@var{none}|@var{standard}|@var{pac-ret}[+@var{leaf}][+@var{bti}]|@var{bti}[+@var{pac-ret}[+@var{leaf}]]
@opindex mbranch-protection
Enable branch protection features (armv8.1-m.main only).
@samp{none} generate code without branch protection or return address
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index
f1c0b52012b8979070c265b7978810afe4601047..06d77983e30fff39886f360920fdfc521d2f69e4
100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -22564,8 +22564,7 @@ The opposite @option{-mno-fdpic} option is useful (and
required) to
build the Linux kernel using the same (@code{arm-*-uclinuxfdpiceabi})
toolchain as the one used to build the userland programs.
-@item
--mbranch-protection=@var{none}|@var{standard}|@var{pac-ret}[+@var{leaf}][+@var{bti}]|@var{bti}[+@var{pac-ret}[+@var{leaf}]]
+@item
-mbranch-protection=@var{none}|@var{standard}|@var{pac-ret}[+@var{leaf}][+@var{bti}]|@var{bti}[+@var{pac-ret}[+@var{leaf}]]
@opindex mbranch-protection
Enable branch protection features (armv8.1-m.main only).
@samp{none} generate code without branch protection or return address
Re: [PATCH] IBM zSystems: Fix TARGET_D_CPU_VERSIONS
Excerpts from Stefan Schulze Frielinghaus via Gcc-patches's message of Januar 13, 2023 6:54 pm: > In the context of D the interpretation of S390, S390X, and SystemZ is a > bit fuzzy. The wording S390X was wrongly deprecated in favour of > SystemZ by commit > https://github.com/dlang/dlang.org/commit/3b50a4c3faf01c32234d0ef8be5f82915a61c23f > Thus, SystemZ is used for 64-bit targets, now, and S390 for 31-bit > targets. However, in TARGET_D_CPU_VERSIONS depending on TARGET_ZARCH we > set the CPU version to SystemZ. This is also the case if compiled for > 31-bit targets leading to the following error: > > libphobos/libdruntime/core/sys/posix/sys/stat.d:967:13: error: static assert: > '96u == 144u' is false > 967 | static assert(stat_t.sizeof == 144); > | ^ > So that I follow, there are three possible combinations? ESA 31-bit (S390) ESA 64-bit (what was S390X) z/Arch 64-bit (SystemZ) > Thus in order to keep this patch simple I went for keeping SystemZ for > 64-bit targets and S390, as usual, for 31-bit targets and dropped the > distinction between ESA and z/Architecture. > > Bootstrapped and regtested on IBM zSystems. Ok for mainline? > OK by me. Maybe keep both S390X and SystemZ for TARGET_64BIT? There's only ever been a binary distinction as far as I'm aware. Iain.
[PATCH] libstdc++: Document P1642 and extensions
libstdc++-v3/ChangeLog: * doc/xml/manual/using.xml: Document newly-freestanding headers and the effect of the -ffreestanding flag. * doc/xml/manual/status_cxx2023.xml: Document P1642R11 as completed. * doc/xml/manual/configure.xml: Document that hosted installs respect __STDC_HOSTED__. * doc/xml/manual/test.xml: Document how to run tests in freestanding mode. --- Afternoon, This patch documents the freestanding changes that are to be included in GCC 13. This revision assumes the changes submitted earlier about building a nearly empty library in freestanding, and simplifies the linking section a bit as a result. Due to -ffreestanding now working on hosted builds of libstdc++, however, it still includes the advice of ``gcc -lsupc++'' for those that are using hosted builds. Thanks in advance, have a great day. libstdc++-v3/doc/xml/manual/configure.xml | 5 +- .../doc/xml/manual/status_cxx2023.xml | 11 libstdc++-v3/doc/xml/manual/test.xml | 14 libstdc++-v3/doc/xml/manual/using.xml | 66 +-- 4 files changed, 88 insertions(+), 8 deletions(-) diff --git a/libstdc++-v3/doc/xml/manual/configure.xml b/libstdc++-v3/doc/xml/manual/configure.xml index 8b3b8cab8c7..7ff07aea886 100644 --- a/libstdc++-v3/doc/xml/manual/configure.xml +++ b/libstdc++-v3/doc/xml/manual/configure.xml @@ -362,7 +362,10 @@ built. The C++ Standard also describes a freestanding environment, in which only a minimal set of headers are provided. This option builds such an - environment. + environment. Note that a hosted library installs headers that still can + be used in non hosted environments, as the library checks for + __STDC_HOSTED__, however, a library configured with + --disable-hosted-libstdcxx will not install unusable headers. diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2023.xml b/libstdc++-v3/doc/xml/manual/status_cxx2023.xml index 365df505f54..f23c64d6a29 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxx2023.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxx2023.xml @@ -566,6 +566,17 @@ or any notes about the implementation. + + Easy [utilities], [ranges], and [iterators] + +http://www.w3.org/1999/xlink"; xlink:href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1642r11.html";> +P1642R11 + + + 13.1 + + + diff --git a/libstdc++-v3/doc/xml/manual/test.xml b/libstdc++-v3/doc/xml/manual/test.xml index 7bc6e339723..964c53d2632 100644 --- a/libstdc++-v3/doc/xml/manual/test.xml +++ b/libstdc++-v3/doc/xml/manual/test.xml @@ -350,6 +350,20 @@ cat 27_io/objects/char/3_xin.in | a.out + + If you wish to run the testsuite in a freestanding configuration, you can + pass the -ffreestanding flag. Doing so will run the tests + that do not require hosted features, and emit a + UNSUPPORTED for those that do. To run tests in the + freestanding configuration, you still need to build for a target you can + run programs on, e.g. x86_64-pc-linux-gnu, as a few tests + still execute the code they build. Here's an example of how to run the + testsuite with libstdc++ in freestanding mode: + +make check-target-libstdc++-v3 RUNTESTFLAGS='--target_board=unix/-ffreestanding' + + + You can run the tests with a compiler and library that have already been installed. Make sure that the compiler (e.g., diff --git a/libstdc++-v3/doc/xml/manual/using.xml b/libstdc++-v3/doc/xml/manual/using.xml index 9c444dd2997..7f011a6d931 100644 --- a/libstdc++-v3/doc/xml/manual/using.xml +++ b/libstdc++-v3/doc/xml/manual/using.xml @@ -132,6 +132,17 @@ + + -ffreestanding + + Limits the library to its freestanding subset. Headers that are + not supported in freestanding will emit a "This header is not available + in freestanding mode" error. + Headers that are in the freestanding subset partially will not expose + functionality that is not part of the freestanding subset. + + + @@ -1523,19 +1534,60 @@ namespace gtk - There exists a library that offers runtime support for - just these headers, and it is called - libsupc++.a. To use it, compile with gcc instead of g++, like so: + + As of GCC 13, libstdc++ implements P1642, which brings in many more + headers, as well a quite a few ones not covered by the paper. + + In general, if a feature does not require traditionally libc-provided + facilities, or dynamic memory allocation, it's enabled in the + freestanding subset. In addition, if only a subset of a header + requires such features, it is partially included. Some examples + include: + + + + + + string_v
Re: [PATCH] testsuite: Fix gcc.dg/vect/vect-bitfield-write-[23].c on SPARC [PR107808]
On Mon, Jan 23, 2023 at 11:44 AM Rainer Orth wrote: > > The gcc.dg/vect/vect-bitfield-write-[23].c tests FAIL on 32 and 64-bit > SPARC: > > FAIL: gcc.dg/vect/vect-bitfield-write-2.c -flto -ffat-lto-objects > scan-tree-dump-times vect "vectorized 1 loops" 1 > FAIL: gcc.dg/vect/vect-bitfield-write-2.c scan-tree-dump-times vect > "vectorized 1 loops" 1 > FAIL: gcc.dg/vect/vect-bitfield-write-3.c -flto -ffat-lto-objects > scan-tree-dump-times vect "vectorized 1 loops" 1 > FAIL: gcc.dg/vect/vect-bitfield-write-3.c scan-tree-dump-times vect > "vectorized 1 loops" 1 > > As discussed in the PR, they require vect_long_long support, but fail > to require that. > > This patch fixes this. > > Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11. > > Ok for trunk? OK. > Rainer > > -- > - > Rainer Orth, Center for Biotechnology, Bielefeld University > > > 2023-01-20 Rainer Orth > > gcc/testsuite: > PR testsuite/107808 > * gcc.dg/vect/vect-bitfield-write-2.c: Require vect_long_long. > * gcc.dg/vect/vect-bitfield-write-3.c: Likewise. >
Re: [PATCH] testsuite: Fix gcc.dg/vect/vect-fmax-1.c etc. on SPARC [PR104756]
On Mon, Jan 23, 2023 at 11:39 AM Rainer Orth wrote: > > The gcc.dg/vect/vect-fmax-?.c etc. tests FAIL on 32 and 64-bit SPARC: > > FAIL: gcc.dg/vect/vect-fmax-1.c -flto -ffat-lto-objects scan-tree-dump vect > "Detected reduction" > FAIL: gcc.dg/vect/vect-fmax-1.c scan-tree-dump vect "Detected reduction" > FAIL: gcc.dg/vect/vect-fmax-2.c -flto -ffat-lto-objects scan-tree-dump vect > "Detected reduction" > FAIL: gcc.dg/vect/vect-fmax-2.c scan-tree-dump vect "Detected reduction" > FAIL: gcc.dg/vect/vect-fmax-3.c -flto -ffat-lto-objects scan-tree-dump vect > "Detected reduction" > FAIL: gcc.dg/vect/vect-fmax-3.c scan-tree-dump vect "Detected reduction" > FAIL: gcc.dg/vect/vect-fmin-1.c -flto -ffat-lto-objects scan-tree-dump vect > "Detected reduction" > FAIL: gcc.dg/vect/vect-fmin-1.c -flto -ffat-lto-objects scan-tree-dump vect > "Detected reduction" > FAIL: gcc.dg/vect/vect-fmin-1.c scan-tree-dump vect "Detected reduction" > FAIL: gcc.dg/vect/vect-fmin-1.c scan-tree-dump vect "Detected reduction" > FAIL: gcc.dg/vect/vect-fmin-2.c -flto -ffat-lto-objects scan-tree-dump vect > "Detected reduction" > FAIL: gcc.dg/vect/vect-fmin-2.c scan-tree-dump vect "Detected reduction" > FAIL: gcc.dg/vect/vect-fmin-3.c -flto -ffat-lto-objects scan-tree-dump vect > "Detected reduction" > FAIL: gcc.dg/vect/vect-fmin-3.c scan-tree-dump vect "Detected reduction" > > As discussed in the PR, they require vect_float support, but the tests > don't declare it. > > This patch fixes this. > > Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11. > > Ok for trunk? OK. > Rainer > > -- > - > Rainer Orth, Center for Biotechnology, Bielefeld University > > > 2023-01-20 Rainer Orth > > gcc/testsuite: > PR testsuite/104756 > * gcc.dg/vect/vect-fmax-1.c: Require vect_float. > * gcc.dg/vect/vect-fmax-2.c: Likewise. > * gcc.dg/vect/vect-fmax-3.c: Likewise. > * gcc.dg/vect/vect-fmin-1.c: Likewise. > * gcc.dg/vect/vect-fmin-2.c: Likewise. > * gcc.dg/vect/vect-fmin-3.c: Likewise. >
Re: [PATCH] c++, cgraphbuild: Handle DECL_VALUE_EXPRs in record_reference [PR108474]
On Mon, 23 Jan 2023, Jakub Jelinek wrote:
> On Mon, Jan 23, 2023 at 09:25:50AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > On Sun, Jan 22, 2023 at 07:19:07PM -0500, Jason Merrill wrote:
> > > > I was just trying to be careful, because unfortunately this spot
> > > > doesn't mean it really is only expanded in static var DECL_INITIAL,
> > > > it can make it into dynamic initializers, and most of DECL_VALUE_EXPRs
> > > > appear only in runtime code, otherwise we'd have much more of these
> > > > issues.
> > >
> > > But it shouldn't be harmful anywhere, right?
> > >
> > > > But if you think it is ok, I'll test tonight a version just with
> > > > if (!data->genericize && DECL_HAS_VALUE_EXPR_P (stmt)
> > >
> > > OK with that change.
> > >
> > > Though, actually, why not instead fix expand_expr_real_1 (and staticp) to
> > > look through DECL_VALUE_EXPR?
> >
> > I'm afraid that is way too late. GIMPLE optimizations don't try to
> > regimplify expressions they take from DECL_INITIAL of static vars, they
> > just unshare them and use them. So, if this is to be done in the generic
> > code, it would need to be done by cgraph around the time when it gimplifies
> > function if there is any such point for variables.
>
> I believe the right spot is record_reference, which is called through
> walk_tree from record_references_in_initializer which is called from
> varpool_node::analyze.
>
> The new tests as well as g++.dg/init/pr53932.C pass with it, will do full
> bootstrap/regtest soon.
>
> What do you think about this?
Guess it should work. Do we (accidentially?) do anything special
to static var initializers in nested functions? Can you think of
any other C/C++ construct that would have DECL_VALUE_EXPR in them?
Richard.
> 2023-01-23 Jakub Jelinek
>
> PR c++/108474
> * cgraphbuild.cc: Include gimplify.h.
> (record_reference): Replace VAR_DECLs with DECL_HAS_VALUE_EXPR_P with
> their corresponding DECL_VALUE_EXPR expressions after unsharing.
>
> * cp-gimplify.cc (cp_fold_r): Revert 2023-01-19 changes.
>
> * g++.dg/cpp1z/decomp57.C: New test.
> * g++.dg/cpp1z/decomp58.C: New test.
>
> --- gcc/cgraphbuild.cc.jj 2023-01-02 09:32:34.889104620 +0100
> +++ gcc/cgraphbuild.cc2023-01-23 12:10:35.042067571 +0100
> @@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.
> #include "gimple-walk.h"
> #include "ipa-utils.h"
> #include "except.h"
> +#include "gimplify.h"
>
> /* Context of record_reference. */
> struct record_reference_ctx
> @@ -79,6 +80,17 @@ record_reference (tree *tp, int *walk_su
>
>if (VAR_P (decl))
> {
> + /* Replace vars with their DECL_VALUE_EXPR if any.
> + This is normally done during gimplification, but
> + static var initializers are never gimplified. */
> + if (DECL_HAS_VALUE_EXPR_P (decl))
> + {
> + tree *p;
> + for (p = tp; *p != decl; p = &TREE_OPERAND (*p, 0))
> + ;
> + *p = unshare_expr (DECL_VALUE_EXPR (decl));
> + return record_reference (tp, walk_subtrees, data);
> + }
> varpool_node *vnode = varpool_node::get_create (decl);
> ctx->varpool_node->create_reference (vnode, IPA_REF_ADDR);
> }
> --- gcc/cp/cp-gimplify.cc.jj 2023-01-23 11:47:49.889875804 +0100
> +++ gcc/cp/cp-gimplify.cc 2023-01-23 11:49:01.227841759 +0100
> @@ -1010,16 +1010,6 @@ cp_fold_r (tree *stmt_p, int *walk_subtr
> }
>break;
>
> -case VAR_DECL:
> - /* In initializers replace anon union artificial VAR_DECLs
> - with their DECL_VALUE_EXPRs, as nothing will do it later. */
> - if (DECL_ANON_UNION_VAR_P (stmt) && !data->genericize)
> - {
> - *stmt_p = stmt = unshare_expr (DECL_VALUE_EXPR (stmt));
> - break;
> - }
> - break;
> -
> default:
>break;
> }
> --- gcc/testsuite/g++.dg/cpp1z/decomp57.C.jj 2023-01-23 11:48:36.367202107
> +0100
> +++ gcc/testsuite/g++.dg/cpp1z/decomp57.C 2023-01-23 11:48:36.367202107
> +0100
> @@ -0,0 +1,27 @@
> +// PR c++/108474
> +// { dg-do link { target c++17 } }
> +
> +struct T { int i, j; };
> +T h;
> +auto [i, j] = h;
> +int &r = i;
> +int s = i;
> +int *t = &i;
> +
> +void
> +foo (int **p, int *q)
> +{
> + static int &u = i;
> + static int v = i;
> + static int *w = &i;
> + int &x = i;
> + int y = i;
> + int *z = &i;
> + *p = &i;
> + *q = i;
> +}
> +
> +int
> +main ()
> +{
> +}
> --- gcc/testsuite/g++.dg/cpp1z/decomp58.C.jj 2023-01-23 11:48:36.367202107
> +0100
> +++ gcc/testsuite/g++.dg/cpp1z/decomp58.C 2023-01-23 11:48:36.367202107
> +0100
> @@ -0,0 +1,39 @@
> +// PR c++/108474
> +// { dg-do link { target c++17 } }
> +
> +namespace std {
> + template struct tuple_size;
> + template struct tuple_element;
> +}
> +
> +struct A {
> + int i;
> + template int& get() { return i; }
> +};
> +
> +template <> struct std::tuple_size { static const int value = 2; };
> +template
[wwwdocs] gcc-6: Consistently lower-case newlib (was: [Patch] install.texi: Bump newlib version for nvptx + gcn)
On Mon, 23 Jan 2023, Tobias Burnus wrote: > In any case, I concur that it would be nice to unify .texi/.xml and > diagnostic > output (twice in config/or1k/elf.opt) - and likewise the wwwdocs pages. : > ->adds this to the to-do list. Let me help a litte and take care of wwwdocs. Pushed. :) Gerald commit 6168a4b67741682ed9168ffdb5cfc6e8bec9557f Author: Gerald Pfeifer Date: Mon Jan 23 12:35:53 2023 +0100 gcc-6: Consistently lower-case newlib diff --git a/htdocs/gcc-6/changes.html b/htdocs/gcc-6/changes.html index a9f033b1..612ea48d 100644 --- a/htdocs/gcc-6/changes.html +++ b/htdocs/gcc-6/changes.html @@ -817,14 +817,14 @@ within strings: RTEMS The RTEMS thread model implementation changed. Mutexes now -use self-contained objects defined in Newlib+use self-contained objects defined in newlib instead of Classic API semaphores. The keys for thread specific data and the once function are directly defined via . -Self-contained condition variables are provided via Newlib +Self-contained condition variables are provided via newlib . The RTEMS thread model also supports C++11 threads. -OpenMP support now uses self-contained objects provided by Newlib +OpenMP support now uses self-contained objects provided by newlib and offers a significantly better performance compared to the POSIX configuration of libgomp. It is possible to configure thread pools for each scheduler instance via the environment
[PATCH 0/15] arm: Enables return address verification and branch target identification on Cortex-M
Hi Richard, thanks for reviewing and approving this series, this is now in. BR Andrea
[PATCH] c++, cgraphbuild: Handle DECL_VALUE_EXPRs in record_reference [PR108474]
On Mon, Jan 23, 2023 at 09:25:50AM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Sun, Jan 22, 2023 at 07:19:07PM -0500, Jason Merrill wrote:
> > > I was just trying to be careful, because unfortunately this spot
> > > doesn't mean it really is only expanded in static var DECL_INITIAL,
> > > it can make it into dynamic initializers, and most of DECL_VALUE_EXPRs
> > > appear only in runtime code, otherwise we'd have much more of these
> > > issues.
> >
> > But it shouldn't be harmful anywhere, right?
> >
> > > But if you think it is ok, I'll test tonight a version just with
> > > if (!data->genericize && DECL_HAS_VALUE_EXPR_P (stmt)
> >
> > OK with that change.
> >
> > Though, actually, why not instead fix expand_expr_real_1 (and staticp) to
> > look through DECL_VALUE_EXPR?
>
> I'm afraid that is way too late. GIMPLE optimizations don't try to
> regimplify expressions they take from DECL_INITIAL of static vars, they
> just unshare them and use them. So, if this is to be done in the generic
> code, it would need to be done by cgraph around the time when it gimplifies
> function if there is any such point for variables.
I believe the right spot is record_reference, which is called through
walk_tree from record_references_in_initializer which is called from
varpool_node::analyze.
The new tests as well as g++.dg/init/pr53932.C pass with it, will do full
bootstrap/regtest soon.
What do you think about this?
2023-01-23 Jakub Jelinek
PR c++/108474
* cgraphbuild.cc: Include gimplify.h.
(record_reference): Replace VAR_DECLs with DECL_HAS_VALUE_EXPR_P with
their corresponding DECL_VALUE_EXPR expressions after unsharing.
* cp-gimplify.cc (cp_fold_r): Revert 2023-01-19 changes.
* g++.dg/cpp1z/decomp57.C: New test.
* g++.dg/cpp1z/decomp58.C: New test.
--- gcc/cgraphbuild.cc.jj 2023-01-02 09:32:34.889104620 +0100
+++ gcc/cgraphbuild.cc 2023-01-23 12:10:35.042067571 +0100
@@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.
#include "gimple-walk.h"
#include "ipa-utils.h"
#include "except.h"
+#include "gimplify.h"
/* Context of record_reference. */
struct record_reference_ctx
@@ -79,6 +80,17 @@ record_reference (tree *tp, int *walk_su
if (VAR_P (decl))
{
+ /* Replace vars with their DECL_VALUE_EXPR if any.
+This is normally done during gimplification, but
+static var initializers are never gimplified. */
+ if (DECL_HAS_VALUE_EXPR_P (decl))
+ {
+ tree *p;
+ for (p = tp; *p != decl; p = &TREE_OPERAND (*p, 0))
+ ;
+ *p = unshare_expr (DECL_VALUE_EXPR (decl));
+ return record_reference (tp, walk_subtrees, data);
+ }
varpool_node *vnode = varpool_node::get_create (decl);
ctx->varpool_node->create_reference (vnode, IPA_REF_ADDR);
}
--- gcc/cp/cp-gimplify.cc.jj2023-01-23 11:47:49.889875804 +0100
+++ gcc/cp/cp-gimplify.cc 2023-01-23 11:49:01.227841759 +0100
@@ -1010,16 +1010,6 @@ cp_fold_r (tree *stmt_p, int *walk_subtr
}
break;
-case VAR_DECL:
- /* In initializers replace anon union artificial VAR_DECLs
-with their DECL_VALUE_EXPRs, as nothing will do it later. */
- if (DECL_ANON_UNION_VAR_P (stmt) && !data->genericize)
- {
- *stmt_p = stmt = unshare_expr (DECL_VALUE_EXPR (stmt));
- break;
- }
- break;
-
default:
break;
}
--- gcc/testsuite/g++.dg/cpp1z/decomp57.C.jj2023-01-23 11:48:36.367202107
+0100
+++ gcc/testsuite/g++.dg/cpp1z/decomp57.C 2023-01-23 11:48:36.367202107
+0100
@@ -0,0 +1,27 @@
+// PR c++/108474
+// { dg-do link { target c++17 } }
+
+struct T { int i, j; };
+T h;
+auto [i, j] = h;
+int &r = i;
+int s = i;
+int *t = &i;
+
+void
+foo (int **p, int *q)
+{
+ static int &u = i;
+ static int v = i;
+ static int *w = &i;
+ int &x = i;
+ int y = i;
+ int *z = &i;
+ *p = &i;
+ *q = i;
+}
+
+int
+main ()
+{
+}
--- gcc/testsuite/g++.dg/cpp1z/decomp58.C.jj2023-01-23 11:48:36.367202107
+0100
+++ gcc/testsuite/g++.dg/cpp1z/decomp58.C 2023-01-23 11:48:36.367202107
+0100
@@ -0,0 +1,39 @@
+// PR c++/108474
+// { dg-do link { target c++17 } }
+
+namespace std {
+ template struct tuple_size;
+ template struct tuple_element;
+}
+
+struct A {
+ int i;
+ template int& get() { return i; }
+};
+
+template <> struct std::tuple_size { static const int value = 2; };
+template struct std::tuple_element { using type = int; };
+
+struct A a;
+auto [i, j] = a;
+int &r = i;
+int s = i;
+int *t = &i;
+
+void
+foo (int **p, int *q)
+{
+ static int &u = i;
+ static int v = i;
+ static int *w = &i;
+ int &x = i;
+ int y = i;
+ int *z = &i;
+ *p = &i;
+ *q = i;
+}
+
+int
+main ()
+{
+}
Jakub
Re: [PATCH 7/9] sparc: Don't add crtfastmath.o for -shared
> Don't add crtfastmath.o for -shared to avoid altering the FP > environment when loading a shared library. > > PR target/55522 > * config/sparc/freebsd.h (ENDFILE_SPEC): Don't add crtfastmath.o > for -shared. > * config/sparc/linux.h (ENDFILE_SPEC): Likewise. > * config/sparc/linux64.h (ENDFILE_SPEC): Likewise. > * config/sparc/sp-elf.h (ENDFILE_SPEC): Likewise. > * config/sparc/sp64-elf.h (ENDFILE_SPEC): Likewise. OK, thanks. -- Eric Botcazou
[PATCH] testsuite: Fix gcc.dg/vect/vect-fmax-1.c etc. on SPARC [PR104756]
The gcc.dg/vect/vect-fmax-?.c etc. tests FAIL on 32 and 64-bit SPARC:
FAIL: gcc.dg/vect/vect-fmax-1.c -flto -ffat-lto-objects scan-tree-dump vect
"Detected reduction"
FAIL: gcc.dg/vect/vect-fmax-1.c scan-tree-dump vect "Detected reduction"
FAIL: gcc.dg/vect/vect-fmax-2.c -flto -ffat-lto-objects scan-tree-dump vect
"Detected reduction"
FAIL: gcc.dg/vect/vect-fmax-2.c scan-tree-dump vect "Detected reduction"
FAIL: gcc.dg/vect/vect-fmax-3.c -flto -ffat-lto-objects scan-tree-dump vect
"Detected reduction"
FAIL: gcc.dg/vect/vect-fmax-3.c scan-tree-dump vect "Detected reduction"
FAIL: gcc.dg/vect/vect-fmin-1.c -flto -ffat-lto-objects scan-tree-dump vect
"Detected reduction"
FAIL: gcc.dg/vect/vect-fmin-1.c -flto -ffat-lto-objects scan-tree-dump vect
"Detected reduction"
FAIL: gcc.dg/vect/vect-fmin-1.c scan-tree-dump vect "Detected reduction"
FAIL: gcc.dg/vect/vect-fmin-1.c scan-tree-dump vect "Detected reduction"
FAIL: gcc.dg/vect/vect-fmin-2.c -flto -ffat-lto-objects scan-tree-dump vect
"Detected reduction"
FAIL: gcc.dg/vect/vect-fmin-2.c scan-tree-dump vect "Detected reduction"
FAIL: gcc.dg/vect/vect-fmin-3.c -flto -ffat-lto-objects scan-tree-dump vect
"Detected reduction"
FAIL: gcc.dg/vect/vect-fmin-3.c scan-tree-dump vect "Detected reduction"
As discussed in the PR, they require vect_float support, but the tests
don't declare it.
This patch fixes this.
Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11.
Ok for trunk?
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
2023-01-20 Rainer Orth
gcc/testsuite:
PR testsuite/104756
* gcc.dg/vect/vect-fmax-1.c: Require vect_float.
* gcc.dg/vect/vect-fmax-2.c: Likewise.
* gcc.dg/vect/vect-fmax-3.c: Likewise.
* gcc.dg/vect/vect-fmin-1.c: Likewise.
* gcc.dg/vect/vect-fmin-2.c: Likewise.
* gcc.dg/vect/vect-fmin-3.c: Likewise.
# HG changeset patch
# Parent 32612dd0fa89c5184649a574bec1c462dd63061a
testsuite: Fix gcc.dg/vect/vect-fmax-1.c etc. on SPARC [PR104756]
diff --git a/gcc/testsuite/gcc.dg/vect/vect-fmax-1.c b/gcc/testsuite/gcc.dg/vect/vect-fmax-1.c
--- a/gcc/testsuite/gcc.dg/vect/vect-fmax-1.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-fmax-1.c
@@ -1,3 +1,5 @@
+/* { dg-require-effective-target vect_float } */
+
#include "tree-vect.h"
#ifndef TYPE
diff --git a/gcc/testsuite/gcc.dg/vect/vect-fmax-2.c b/gcc/testsuite/gcc.dg/vect/vect-fmax-2.c
--- a/gcc/testsuite/gcc.dg/vect/vect-fmax-2.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-fmax-2.c
@@ -1,3 +1,5 @@
+/* { dg-require-effective-target vect_float } */
+
#define TYPE double
#define FN __builtin_fmax
diff --git a/gcc/testsuite/gcc.dg/vect/vect-fmax-3.c b/gcc/testsuite/gcc.dg/vect/vect-fmax-3.c
--- a/gcc/testsuite/gcc.dg/vect/vect-fmax-3.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-fmax-3.c
@@ -1,3 +1,5 @@
+/* { dg-require-effective-target vect_float } */
+
#include "tree-vect.h"
void __attribute__((noipa))
diff --git a/gcc/testsuite/gcc.dg/vect/vect-fmin-1.c b/gcc/testsuite/gcc.dg/vect/vect-fmin-1.c
--- a/gcc/testsuite/gcc.dg/vect/vect-fmin-1.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-fmin-1.c
@@ -1,3 +1,5 @@
+/* { dg-require-effective-target vect_float } */
+
#include "tree-vect.h"
#ifndef TYPE
diff --git a/gcc/testsuite/gcc.dg/vect/vect-fmin-2.c b/gcc/testsuite/gcc.dg/vect/vect-fmin-2.c
--- a/gcc/testsuite/gcc.dg/vect/vect-fmin-2.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-fmin-2.c
@@ -1,3 +1,5 @@
+/* { dg-require-effective-target vect_float } */
+
#ifndef TYPE
#define TYPE double
#define FN __builtin_fmin
diff --git a/gcc/testsuite/gcc.dg/vect/vect-fmin-3.c b/gcc/testsuite/gcc.dg/vect/vect-fmin-3.c
--- a/gcc/testsuite/gcc.dg/vect/vect-fmin-3.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-fmin-3.c
@@ -1,3 +1,5 @@
+/* { dg-require-effective-target vect_float } */
+
#include "tree-vect.h"
void __attribute__((noipa))
[PATCH] testsuite: Fix gcc.dg/vect/vect-bitfield-write-[23].c on SPARC [PR107808]
The gcc.dg/vect/vect-bitfield-write-[23].c tests FAIL on 32 and 64-bit
SPARC:
FAIL: gcc.dg/vect/vect-bitfield-write-2.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/vect-bitfield-write-2.c scan-tree-dump-times vect "vectorized
1 loops" 1
FAIL: gcc.dg/vect/vect-bitfield-write-3.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/vect-bitfield-write-3.c scan-tree-dump-times vect "vectorized
1 loops" 1
As discussed in the PR, they require vect_long_long support, but fail
to require that.
This patch fixes this.
Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11.
Ok for trunk?
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
2023-01-20 Rainer Orth
gcc/testsuite:
PR testsuite/107808
* gcc.dg/vect/vect-bitfield-write-2.c: Require vect_long_long.
* gcc.dg/vect/vect-bitfield-write-3.c: Likewise.
# HG changeset patch
# Parent d221c189db0b3879bb343bc381eca6b730ad3010
testsuite: Fix gcc.dg/vect/vect-bitfield-write-[23].c on SPARC [PR107808]
diff --git a/gcc/testsuite/gcc.dg/vect/vect-bitfield-write-2.c b/gcc/testsuite/gcc.dg/vect/vect-bitfield-write-2.c
--- a/gcc/testsuite/gcc.dg/vect/vect-bitfield-write-2.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-bitfield-write-2.c
@@ -1,4 +1,5 @@
/* { dg-require-effective-target vect_int } */
+/* { dg-require-effective-target vect_long_long } */
#include
#include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/vect-bitfield-write-3.c b/gcc/testsuite/gcc.dg/vect/vect-bitfield-write-3.c
--- a/gcc/testsuite/gcc.dg/vect/vect-bitfield-write-3.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-bitfield-write-3.c
@@ -1,4 +1,5 @@
/* { dg-require-effective-target vect_int } */
+/* { dg-require-effective-target vect_long_long } */
#include
#include "tree-vect.h"
Re: [PATCH] tree-optimization/108482 - remove stray .LOOP_DIST_ALIAS calls
On Mon, Jan 23, 2023 at 10:28:01AM +, Richard Biener wrote: > On Mon, 23 Jan 2023, Jakub Jelinek wrote: > > > On Mon, Jan 23, 2023 at 11:09:43AM +0100, Richard Biener wrote: > > > The following deals with .LOOP_DIST_ALIAS surviving vectorization > > > because any of the loops involved were elided between loop distribution > > > and vectorization. As opposed to .LOOP_VECTORIZED which exists only > > > between if-conversion and vectorization with no intermediate passes > > > this is more difficult to deal with in advance and thus cleaning > > > up after vectorization looks better. There's the unconditional > > > vector lowering pass which looks like a good place for this (for > > > SIMD uid we have pass_simduid_cleanup). > > > > > > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. > > > > > > OK? > > > > I admit I didn't know something like LOOP_DIST_ALIAS even exist until > > today. > > Anyway, I wonder if there is still time to clean up during/after > > veclower21. > > That's what the patch does, but maybe I misunderstood the question. > > > I see fold_loop_internal_call propagates the return value to immediate > > uses and cfg_changed means we'll clean up the cfg, is that enough? > > It's enough to get rid of the internal function call which will ICE > if it reaches RTL expansion. The earliest point to get rid of them > is in the loop vectorizer but for the testcase at hand this requires > a walk of the whole IL where we cut the whole vectorizer pass with > the number-of-loops in function check currently. Ok then. Jakub
Re: git out-of-order commit (was Re: [PATCH] Fortran: Remove unused declaration)
On 1/20/23 18:33, Jason Merrill wrote: > Martin, I wonder about having the hooks reject out-of-order CommitDate > in future? Yes, I would do that. Looking at the last 30K commmits I see just a few violations of the order: UNIXTS hash 1668298622 30d77d49628 1630019619 5889e842ae4 1626967834 3f7a2374d31 1624564915 a0accaa9984 1620660174 0498d2d09a2 1606210175 f72175357d0 1605630503 8895913273b 1604409789 1528f34341b 1601415121 f836f3bc8f7 1593773652 9bc2c2347d5 1588873342 b9250b3cb91 1582563261 9069e9484ce Martin
[PATCH] modula2/108462 - duplicate install of static modula2 target libs
The following addresses the fact that libgm2 installs static libraries into two places, one performed by toolexeclib_LTLIBRARIES = libm2cor.la and one performed as part of the install-data-local rule to a m2/m2cor subdirectory alongside Modula-2 .def and .mod files. This patch opts to keep the copy installed by libtool and removes the extra installs in the install-data-local rules. I've built and installed both with and without --enable-version-specific-runtime-libs and compiled and linked a Modula-2 testcase with the installed compiler with the two multilibs and with and without static successfully. OK for trunk? Thanks, Richard. PR modula2/108462 libgm2/ * libm2cor/Makefile.am: Remove static lib install from install-data-local. * libm2iso/Makefile.am: Likewise. * libm2log/Makefile.am: Likewise. * libm2min/Makefile.am: Likewise. * libm2pim/Makefile.am: Likewise. * libm2cor/Makefile.in: Regenerate. * libm2iso/Makefile.in: Likewise. * libm2log/Makefile.in: Likewise. * libm2min/Makefile.in: Likewise. * libm2pim/Makefile.in: Likewise. --- libgm2/libm2cor/Makefile.am | 5 - libgm2/libm2cor/Makefile.in | 5 - libgm2/libm2iso/Makefile.am | 5 - libgm2/libm2iso/Makefile.in | 5 - libgm2/libm2log/Makefile.am | 5 - libgm2/libm2log/Makefile.in | 5 - libgm2/libm2min/Makefile.am | 5 - libgm2/libm2min/Makefile.in | 5 - libgm2/libm2pim/Makefile.am | 4 libgm2/libm2pim/Makefile.in | 4 10 files changed, 48 deletions(-) diff --git a/libgm2/libm2cor/Makefile.am b/libgm2/libm2cor/Makefile.am index 2cc30847849..2624a7d469f 100644 --- a/libgm2/libm2cor/Makefile.am +++ b/libgm2/libm2cor/Makefile.am @@ -140,11 +140,6 @@ SYSTEM.def: Makefile install-data-local: force mkdir -p $(DESTDIR)$(inst_libdir)/$(M2LIBDIR) - $(INSTALL_DATA) .libs/libm2cor.la $(DESTDIR)$(inst_libdir)/$(M2LIBDIR) - chmod 644 $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)libm2cor.la - $(INSTALL_DATA) .libs/libm2cor.a $(DESTDIR)$(inst_libdir)/$(M2LIBDIR) - chmod 644 $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)libm2cor.a - $(RANLIB) $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)libm2cor.a for i in $(M2DEFS) $(M2MODS) ; do \ if [ -f $$i ] ; then \ $(INSTALL_DATA) $$i '$(DESTDIR)$(inst_libdir)/$(M2LIBDIR)'; \ diff --git a/libgm2/libm2cor/Makefile.in b/libgm2/libm2cor/Makefile.in index 8806d7bccf6..4869e99c64e 100644 --- a/libgm2/libm2cor/Makefile.in +++ b/libgm2/libm2cor/Makefile.in @@ -806,11 +806,6 @@ uninstall-am: uninstall-toolexeclibLTLIBRARIES @BUILD_CORLIB_TRUE@install-data-local: force @BUILD_CORLIB_TRUE@mkdir -p $(DESTDIR)$(inst_libdir)/$(M2LIBDIR) -@BUILD_CORLIB_TRUE@$(INSTALL_DATA) .libs/libm2cor.la $(DESTDIR)$(inst_libdir)/$(M2LIBDIR) -@BUILD_CORLIB_TRUE@chmod 644 $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)libm2cor.la -@BUILD_CORLIB_TRUE@$(INSTALL_DATA) .libs/libm2cor.a $(DESTDIR)$(inst_libdir)/$(M2LIBDIR) -@BUILD_CORLIB_TRUE@chmod 644 $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)libm2cor.a -@BUILD_CORLIB_TRUE@$(RANLIB) $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)libm2cor.a @BUILD_CORLIB_TRUE@for i in $(M2DEFS) $(M2MODS) ; do \ @BUILD_CORLIB_TRUE@ if [ -f $$i ] ; then \ @BUILD_CORLIB_TRUE@ $(INSTALL_DATA) $$i '$(DESTDIR)$(inst_libdir)/$(M2LIBDIR)'; \ diff --git a/libgm2/libm2iso/Makefile.am b/libgm2/libm2iso/Makefile.am index a28cd5ac8aa..b5962d9c72c 100644 --- a/libgm2/libm2iso/Makefile.am +++ b/libgm2/libm2iso/Makefile.am @@ -220,11 +220,6 @@ SYSTEM.def: Makefile install-data-local: force mkdir -p $(DESTDIR)$(inst_libdir)/$(M2LIBDIR) - $(INSTALL_DATA) .libs/libm2iso.la $(DESTDIR)$(inst_libdir)/$(M2LIBDIR) - chmod 644 $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)libm2iso.la - $(INSTALL_DATA) .libs/libm2iso.a $(DESTDIR)$(inst_libdir)/$(M2LIBDIR) - chmod 644 $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)/libm2iso.a - $(RANLIB) $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)/libm2iso.a for i in $(M2DEFS) $(M2MODS) ; do \ if [ -f $$i ] ; then \ $(INSTALL_DATA) $$i '$(DESTDIR)$(inst_libdir)/$(M2LIBDIR)'; \ diff --git a/libgm2/libm2iso/Makefile.in b/libgm2/libm2iso/Makefile.in index 0ca852a6124..cd65d6cad56 100644 --- a/libgm2/libm2iso/Makefile.in +++ b/libgm2/libm2iso/Makefile.in @@ -919,11 +919,6 @@ uninstall-am: uninstall-toolexeclibLTLIBRARIES @BUILD_ISOLIB_TRUE@install-data-local: force @BUILD_ISOLIB_TRUE@mkdir -p $(DESTDIR)$(inst_libdir)/$(M2LIBDIR) -@BUILD_ISOLIB_TRUE@$(INSTALL_DATA) .libs/libm2iso.la $(DESTDIR)$(inst_libdir)/$(M2LIBDIR) -@BUILD_ISOLIB_TRUE@chmod 644 $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)libm2iso.la -@BUILD_ISOLIB_TRUE@$(INSTALL_DATA) .libs/libm2iso.a $(DESTDIR)$(inst_libdir)/$(M2LIBDIR) -@BUILD_ISOLIB_TRUE@chmod 644 $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)/libm2iso.a -@BUILD_ISOLIB_TRUE@$(RANLIB) $(DESTDIR)$(inst_libdir)/$(M2LI
Re: [PATCH] gomp: Various fixes for SVE types [PR101018]
Ping
Richard Sandiford writes:
> Various parts of the omp code checked whether the size of a decl
> was an INTEGER_CST in order to determine whether the decl was
> variable-sized or not. If it was variable-sized, it was expected
> to have a DECL_VALUE_EXPR replacement, as for VLAs.
>
> This patch uses poly_int_tree_p instead, so that variable-length
> SVE vectors are treated like constant-length vectors. This means
> that some structures become poly_int-sized, with some fields at
> poly_int offsets, but we already have code to handle that.
>
> An alternative would have been to handle the data via indirection
> instead. However, that's likely to be more complicated, and it
> would contradict is_variable_sized, which already uses a check
> for TREE_CONSTANT rather than INTEGER_CST.
>
> gimple_add_tmp_var should probably not add a safelen of 1
> for SVE vectors, but that's really a separate thing and might
> be hard to test.
>
> Tested on aarch64-linux-gnu. OK to install?
>
> Richard
>
>
> gcc/
> PR middle-end/101018
> * poly-int.h (can_and_p): New function.
> * fold-const.cc (poly_int_binop): Use it to optimize BIT_AND_EXPRs
> involving POLY_INT_CSTs.
> * expr.cc (get_inner_reference): Fold poly_uint64 size_trees
> into the constant bitsize.
> * gimplify.cc (gimplify_bind_expr): Use poly_int_tree_p instead
> of INTEGER_CST when checking for constant-sized omp data.
> (omp_add_variable): Likewise.
> (omp_notice_variable): Likewise.
> (gimplify_adjust_omp_clauses_1): Likewise.
> (gimplify_adjust_omp_clauses): Likewise.
> * omp-low.cc (scan_sharing_clauses): Likewise.
> (lower_omp_target): Likewise.
>
> gcc/testsuite/
> PR middle-end/101018
> * gcc.target/aarch64/sve/acle/pr101018-1.c: New test.
> * gcc.target/aarch64/sve/acle/pr101018-2.c: Likewise
> ---
> gcc/expr.cc | 4 +--
> gcc/fold-const.cc | 7 +
> gcc/gimplify.cc | 23
> gcc/omp-low.cc| 10 +++
> gcc/poly-int.h| 19 +
> .../aarch64/sve/acle/general/pr101018-1.c | 27 +++
> .../aarch64/sve/acle/general/pr101018-2.c | 23
> 7 files changed, 94 insertions(+), 19 deletions(-)
> create mode 100644
> gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr101018-1.c
> create mode 100644
> gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr101018-2.c
>
> diff --git a/gcc/expr.cc b/gcc/expr.cc
> index d9407432ea5..a304c583d16 100644
> --- a/gcc/expr.cc
> +++ b/gcc/expr.cc
> @@ -7941,10 +7941,10 @@ get_inner_reference (tree exp, poly_int64_pod
> *pbitsize,
>
>if (size_tree != 0)
> {
> - if (! tree_fits_uhwi_p (size_tree))
> + if (! tree_fits_poly_uint64_p (size_tree))
> mode = BLKmode, *pbitsize = -1;
>else
> - *pbitsize = tree_to_uhwi (size_tree);
> + *pbitsize = tree_to_poly_uint64 (size_tree);
> }
>
>*preversep = reverse_storage_order_for_component_p (exp);
> diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
> index b89cac91cae..000600017e2 100644
> --- a/gcc/fold-const.cc
> +++ b/gcc/fold-const.cc
> @@ -1183,6 +1183,13 @@ poly_int_binop (poly_wide_int &res, enum tree_code
> code,
> return false;
>break;
>
> +case BIT_AND_EXPR:
> + if (TREE_CODE (arg2) != INTEGER_CST
> + || !can_and_p (wi::to_poly_wide (arg1), wi::to_wide (arg2),
> + &res))
> + return false;
> + break;
> +
> case BIT_IOR_EXPR:
>if (TREE_CODE (arg2) != INTEGER_CST
> || !can_ior_p (wi::to_poly_wide (arg1), wi::to_wide (arg2),
> diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
> index f06ce3cc77a..096738c8ed4 100644
> --- a/gcc/gimplify.cc
> +++ b/gcc/gimplify.cc
> @@ -7352,7 +7352,7 @@ omp_add_variable (struct gimplify_omp_ctx *ctx, tree
> decl, unsigned int flags)
>/* When adding a variable-sized variable, we have to handle all sorts
> of additional bits of data: the pointer replacement variable, and
> the parameters of the type. */
> - if (DECL_SIZE (decl) && TREE_CODE (DECL_SIZE (decl)) != INTEGER_CST)
> + if (DECL_SIZE (decl) && !poly_int_tree_p (DECL_SIZE (decl)))
> {
>/* Add the pointer replacement variable as PRIVATE if the variable
>replacement is private, else FIRSTPRIVATE since we'll need the
> @@ -8002,7 +8002,8 @@ omp_notice_variable (struct gimplify_omp_ctx *ctx, tree
> decl, bool in_code)
>&& (flags & (GOVD_SEEN | GOVD_LOCAL)) == GOVD_SEEN
>&& DECL_SIZE (decl))
> {
> - if (TREE_CODE (DECL_SIZE (decl)) != INTEGER_CST)
> + tree size;
> + if (!poly_int_tree_p (DECL_SIZE (decl)))
> {
> splay_tree_node n2;
> tree t = DECL_VALUE_EXPR (decl);
> @@ -8013,16 +8014,14 @@ omp_notice_variable (struct gimplify_omp_ctx *c
Re: [PATCH] tree-optimization/108482 - remove stray .LOOP_DIST_ALIAS calls
On Mon, 23 Jan 2023, Jakub Jelinek wrote: > On Mon, Jan 23, 2023 at 11:09:43AM +0100, Richard Biener wrote: > > The following deals with .LOOP_DIST_ALIAS surviving vectorization > > because any of the loops involved were elided between loop distribution > > and vectorization. As opposed to .LOOP_VECTORIZED which exists only > > between if-conversion and vectorization with no intermediate passes > > this is more difficult to deal with in advance and thus cleaning > > up after vectorization looks better. There's the unconditional > > vector lowering pass which looks like a good place for this (for > > SIMD uid we have pass_simduid_cleanup). > > > > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. > > > > OK? > > I admit I didn't know something like LOOP_DIST_ALIAS even exist until > today. > Anyway, I wonder if there is still time to clean up during/after > veclower21. That's what the patch does, but maybe I misunderstood the question. > I see fold_loop_internal_call propagates the return value to immediate > uses and cfg_changed means we'll clean up the cfg, is that enough? It's enough to get rid of the internal function call which will ICE if it reaches RTL expansion. The earliest point to get rid of them is in the loop vectorizer but for the testcase at hand this requires a walk of the whole IL where we cut the whole vectorizer pass with the number-of-loops in function check currently. Richard.
[PATCH] tree-optimization/108482 - remove stray .LOOP_DIST_ALIAS calls
The following deals with .LOOP_DIST_ALIAS surviving vectorization
because any of the loops involved were elided between loop distribution
and vectorization. As opposed to .LOOP_VECTORIZED which exists only
between if-conversion and vectorization with no intermediate passes
this is more difficult to deal with in advance and thus cleaning
up after vectorization looks better. There's the unconditional
vector lowering pass which looks like a good place for this (for
SIMD uid we have pass_simduid_cleanup).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
OK?
Thanks,
Richard.
PR tree-optimization/108482
* tree-vect-generic.cc (expand_vector_operations): Fold remaining
.LOOP_DIST_ALIAS calls.
* gcc.dg/torture/pr108482.c: New testcase.
---
gcc/testsuite/gcc.dg/torture/pr108482.c | 18 ++
gcc/tree-vect-generic.cc| 8
2 files changed, 26 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/torture/pr108482.c
diff --git a/gcc/testsuite/gcc.dg/torture/pr108482.c
b/gcc/testsuite/gcc.dg/torture/pr108482.c
new file mode 100644
index 000..8dc1169a9c5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr108482.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+
+int g_30, g_261, g_263, func_1___trans_tmp_17;
+int **g_120;
+int *g_530;
+void func_1() {
+ int *l_29 = &g_30;
+ *l_29 = 1;
+ g_263 = 0;
+ for (; g_263 <= 1; g_263 += 1) {
+g_530 = 0;
+if (*l_29) {
+ char *l_1694 = (char *)&g_261;
+ *l_1694 &= **g_120;
+} else
+ *l_29 ^= func_1___trans_tmp_17;
+ }
+}
diff --git a/gcc/tree-vect-generic.cc b/gcc/tree-vect-generic.cc
index 2e2d7567293..166a248f4b9 100644
--- a/gcc/tree-vect-generic.cc
+++ b/gcc/tree-vect-generic.cc
@@ -2398,6 +2398,14 @@ expand_vector_operations (void)
if (maybe_clean_eh_stmt (gsi_stmt (gsi))
&& gimple_purge_dead_eh_edges (bb))
cfg_changed = true;
+ /* If a .LOOP_DIST_ALIAS call prevailed loops got elided
+before vectorization got a chance to get at them. Simply
+fold as if loop distribution wasn't performed. */
+ if (gimple_call_internal_p (gsi_stmt (gsi), IFN_LOOP_DIST_ALIAS))
+ {
+ fold_loop_internal_call (gsi_stmt (gsi), boolean_false_node);
+ cfg_changed = true;
+ }
}
}
--
2.35.3
Re: [PATCH] tree-optimization/108482 - remove stray .LOOP_DIST_ALIAS calls
On Mon, Jan 23, 2023 at 11:09:43AM +0100, Richard Biener wrote: > The following deals with .LOOP_DIST_ALIAS surviving vectorization > because any of the loops involved were elided between loop distribution > and vectorization. As opposed to .LOOP_VECTORIZED which exists only > between if-conversion and vectorization with no intermediate passes > this is more difficult to deal with in advance and thus cleaning > up after vectorization looks better. There's the unconditional > vector lowering pass which looks like a good place for this (for > SIMD uid we have pass_simduid_cleanup). > > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. > > OK? I admit I didn't know something like LOOP_DIST_ALIAS even exist until today. Anyway, I wonder if there is still time to clean up during/after veclower21. I see fold_loop_internal_call propagates the return value to immediate uses and cfg_changed means we'll clean up the cfg, is that enough? Jakub
[PATCH] modula2/108144 - fix mistake in previous change
The previous change to avoid a duplicate multi directory
caused the m2/m2{cor,iso,log,min,pim} installs to happen
relative to the main library directory when not using
--enable-version-specific-runtime-libs which doesn't match
the drivers expectation where to find them. The following
fixes the original issue by simply dropping the duplicate
multi directory since the one in the $(inst_libdir) variable
now works.
Tested by building and installing with and without
--enable-version-specific-runtime-libs and compiling and
linking a modula-2 testcase successfully with the installed
compilers.
Pushed - sorry for the breakage.
PR modula2/108144
libgm2/
* libm2cor/Makefile.am: Revert previous change, instead
drop the redundant $(MULTIDIR).
* libm2iso/Makefile.am: Likewise.
* libm2log/Makefile.am: Likewise.
* libm2min/Makefile.am: Likewise.
* libm2pim/Makefile.am: Likewise.
* libm2cor/Makefile.in: Regenerate.
* libm2iso/Makefile.in: Likewise.
* libm2log/Makefile.in: Likewise.
* libm2min/Makefile.in: Likewise.
* libm2pim/Makefile.in: Likewise.
---
libgm2/libm2cor/Makefile.am | 18 +-
libgm2/libm2cor/Makefile.in | 18 +-
libgm2/libm2iso/Makefile.am | 22 +++---
libgm2/libm2iso/Makefile.in | 22 +++---
libgm2/libm2log/Makefile.am | 18 +-
libgm2/libm2log/Makefile.in | 18 +-
libgm2/libm2min/Makefile.am | 18 +-
libgm2/libm2min/Makefile.in | 18 +-
libgm2/libm2pim/Makefile.am | 16
libgm2/libm2pim/Makefile.in | 16
10 files changed, 92 insertions(+), 92 deletions(-)
diff --git a/libgm2/libm2cor/Makefile.am b/libgm2/libm2cor/Makefile.am
index b418fca7dd0..2cc30847849 100644
--- a/libgm2/libm2cor/Makefile.am
+++ b/libgm2/libm2cor/Makefile.am
@@ -139,21 +139,21 @@ SYSTEM.def: Makefile
$(LIBTOOL) --tag=CXX --mode=compile $(CXX) -c -I$(srcdir) $(CXXFLAGS)
$(LIBCFLAGS) $(libm2cor_la_CFLAGS) $< -o $@
install-data-local: force
- mkdir -p $(DESTDIR)$(toolexeclibdir)$(M2LIBDIR)
- $(INSTALL_DATA) .libs/libm2cor.la $(DESTDIR)$(toolexeclibdir)$(M2LIBDIR)
- chmod 644 $(DESTDIR)$(toolexeclibdir)$(M2LIBDIR)libm2cor.la
- $(INSTALL_DATA) .libs/libm2cor.a $(DESTDIR)$(toolexeclibdir)$(M2LIBDIR)
- chmod 644 $(DESTDIR)$(toolexeclibdir)$(M2LIBDIR)libm2cor.a
- $(RANLIB) $(DESTDIR)$(toolexeclibdir)$(M2LIBDIR)libm2cor.a
+ mkdir -p $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)
+ $(INSTALL_DATA) .libs/libm2cor.la $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)
+ chmod 644 $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)libm2cor.la
+ $(INSTALL_DATA) .libs/libm2cor.a $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)
+ chmod 644 $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)libm2cor.a
+ $(RANLIB) $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)libm2cor.a
for i in $(M2DEFS) $(M2MODS) ; do \
if [ -f $$i ] ; then \
- $(INSTALL_DATA) $$i '$(DESTDIR)$(toolexeclibdir)$(M2LIBDIR)'; \
+ $(INSTALL_DATA) $$i '$(DESTDIR)$(inst_libdir)/$(M2LIBDIR)'; \
elif [ -f @srcdir@/../../gcc/m2/gm2-libs-coroutines/$$i ] ; then \
- $(INSTALL_DATA) @srcdir@/../../gcc/m2/gm2-libs-coroutines/$$i
'$(DESTDIR)$(toolexeclibdir)$(M2LIBDIR)'; \
+ $(INSTALL_DATA) @srcdir@/../../gcc/m2/gm2-libs-coroutines/$$i
'$(DESTDIR)$(inst_libdir)/$(M2LIBDIR)'; \
else \
echo "cannot find $$i" ; exit 1 ; \
fi ; \
- chmod 644 $(DESTDIR)$(toolexeclibdir)$(M2LIBDIR)$$i ; \
+ chmod 644 $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)$$i ; \
done
force:
diff --git a/libgm2/libm2cor/Makefile.in b/libgm2/libm2cor/Makefile.in
index c7efdc5dd6b..8806d7bccf6 100644
--- a/libgm2/libm2cor/Makefile.in
+++ b/libgm2/libm2cor/Makefile.in
@@ -805,21 +805,21 @@ uninstall-am: uninstall-toolexeclibLTLIBRARIES
@BUILD_CORLIB_TRUE@$(LIBTOOL) --tag=CXX --mode=compile $(CXX) -c
-I$(srcdir) $(CXXFLAGS) $(LIBCFLAGS) $(libm2cor_la_CFLAGS) $< -o $@
@BUILD_CORLIB_TRUE@install-data-local: force
-@BUILD_CORLIB_TRUE@mkdir -p $(DESTDIR)$(toolexeclibdir)$(M2LIBDIR)
-@BUILD_CORLIB_TRUE@$(INSTALL_DATA) .libs/libm2cor.la
$(DESTDIR)$(toolexeclibdir)$(M2LIBDIR)
-@BUILD_CORLIB_TRUE@chmod 644
$(DESTDIR)$(toolexeclibdir)$(M2LIBDIR)libm2cor.la
-@BUILD_CORLIB_TRUE@$(INSTALL_DATA) .libs/libm2cor.a
$(DESTDIR)$(toolexeclibdir)$(M2LIBDIR)
-@BUILD_CORLIB_TRUE@chmod 644
$(DESTDIR)$(toolexeclibdir)$(M2LIBDIR)libm2cor.a
-@BUILD_CORLIB_TRUE@$(RANLIB)
$(DESTDIR)$(toolexeclibdir)$(M2LIBDIR)libm2cor.a
+@BUILD_CORLIB_TRUE@mkdir -p $(DESTDIR)$(inst_libdir)/$(M2LIBDIR)
+@BUILD_CORLIB_TRUE@$(INSTALL_DATA) .libs/libm2cor.la
$(DESTDIR)$(inst_libdir)/$(M2LIBDIR)
+@BUILD_CORLIB_TRUE@chmod 644
$(DESTDIR)$(inst_libdir)/$(M2LIBDIR)libm2cor.la
+@BUILD_CORLIB_TRUE@$(INSTALL_DATA) .libs/libm2cor.a
Re: [PATCH v2] ipa-cp: Speculatively call specialized functions
On Fri, Jan 13, 2023 at 7:49 PM Martin Jambor wrote: > > Hello, > > sorry for getting to this quite late. I have only had a quick glance at > ipa-cp.cc hunks so far. > Hi Martin, Thanks for taking the time to review these. > On Fri, Dec 16 2022, Manolis Tsamis wrote: > > The IPA CP pass offers a wide range of optimizations, where most of them > > lead to specialized functions that are called from a call site. > > This can lead to multiple specialized function clones, if more than > > one call-site allows such an optimization. > > If not all call-sites can be optimized, the program might end > > up with call-sites to the original function. > > > > This pass assumes that non-optimized call-sites (i.e. call-sites > > that don't call specialized functions) are likely to be called > > with arguments that would allow calling specialized clones. > > Since we cannot guarantee this (for obvious reasons), we can't > > replace the existing calls. However, we can introduce dynamic > > guards that test the arguments for the collected constants > > and calls the specialized function if there is a match. > > > > To demonstrate the effect, let's consider the following program part: > > > > func_1() > > myfunc(1) > > func_2() > > myfunc(2) > > func_i(i) > > myfunc(i) > > > > In this case the transformation would do the following: > > > > func_1() > > myfunc.constprop.1() // myfunc() with arg0 == 1 > > func_2() > > myfunc.constprop.2() // myfunc() with arg0 == 2 > > func_i(i) > > if (i == 1) > > myfunc.constprop.1() // myfunc() with arg0 == 1 > > else if (i == 2) > > myfunc.constprop.2() // myfunc() with arg0 == 2 > > else > > myfunc(i) > > My understanding of the code, however, is that it rather creates > > func_i(i) > if (i == 1) > myfunc.constprop.1_1() // mostly equivalent but separate from > myfunc.constprop.1 > else if (i == 2) > myfunc.constprop.2_1() // mostly equivalent but separate from > myfunc.constprop.2 > else > myfunc(i) > > Which I find difficult to justify. From comments it looked like the > reason is avoiding calling find_more_scalar_values, is that correct? > > I'd like to know more about the cases you are targeting and cases where > adding the additional known scalar constants were an issue. I think it > needs to be tackled differently. > > By the way, as IPA-CP works now (it would be nice but difficult to lift > that limitation), all but up to one constant in known_csts are constants > in all call contexts, so without calling find_more_scalar_values you > should need just one run-time condition per speculative call. So > tracking which constant is which might be better than avoiding > find_more_scalar_values? > First of all what you say about the clones being mostly equivalent but separate is true. I have also noted this in the V2 changes but the description is based on V1 where the clones were indeed shared with ipa-cp. Allow me to provide some context here: The implementation is based on the assumption that the constant arguments from an ipa-cp specialization are likely to appear in non-constant call sites as well, and in that case it is worthwhile to speculatively specialize for these. In the first implementation the speculative guards called the same specialized functions that were created by ipa-cp but this turned out to be an issue for two reasons. The first issue was find_more_scalar_values. Whereas the constant chosen for the ipa-cp clone is a good indicator for the likeliness of a value in the non-constant callsites, the constants added by find_more_scalar_values are usually not. Adding more constants to the specialization is of course an improvement for the call sites that involve these constants, but for speculatively specializing they make things worse by increasing the complexity of the guard and also decreasing the probability the guard will be true (by being more restrictive). This is especially true for pointer constants added by find_more_scalar_values, which are useful for the specialized function but greatly limit the usefulness of the speculative one. The second reason for creating separate clones is that we realized that ipa-cp clones are more than just specializing for a constant. The specialized clones haves a list of known contexts, which from my understanding it is incorrect to call the specialized function from a context not included in these, and a list of aggregate replacements which didn't work well when we tried to use them as speculative specializations. These are the main reasons that although we wanted to avoid excessively clone function we had to create separate clones from ipa-cp's. Additionally it is true that with this approach, as you mention, just one run-time condition per speculative call is needed. The implementation is more general and supports any number of them, but currently only one is used. In case this was not implied by your last sentence there,
Re: [Patch] install.texi: Bump newlib version for nvptx + gcn
On 22.01.23 02:45, Gerald Pfeifer wrote:
Maybe, but the question is what to use? The project's webpage has on the
first page: "patch submissions to Newlib" and "automate the testing of
newlib".
I also dug into the newlib web page and other sources and - while my
personal preference slightly leans towards Newlib - believe newlib is
more established overall.
For the web pages, it's clearer than for our *.texi ones you dug into:
~/src/wwwdocs/htdocs> grep -r newlib . | wc -l
15
~/src/wwwdocs/htdocs> grep -r Newlib . | wc -l
3
You need to be careful with those counts as there is not only 'the [nN]ewlib
library'
but also flags/configure arguments etc:
gcc/doc/install.texi:@item --with-newlib
gcc/doc/install.texi-@item --with-nds32-lib=@var{library}
gcc/doc/install.texi:Currently, the valid @var{library} is @samp{newlib} or
@samp{mculib}.
gcc/doc/install.texi:to nvptx-newlib's @file{newlib} directory to the directory
containing
gcc/doc/install.texi:@option{--enable-newlib-io-long-long} options when
configuring.
gcc/doc/invoke.texi:@samp{--enable-newlib-nano-formatted-io}.
gcc/doc/invoke.texi:@item -mnewlib
gcc/doc/invoke.texi:@opindex mnewlib
(and a few more).
In the libstdc++-v3/doc/xml/, there are two 'newlib' and one 'Newlib'
(plus a bunch of newlib as filename/argument/config option).
Still, I concur that 'newlib' is still used a bit more often than 'Newlib'.
* * *
In any case, I concur that it would be nice to unify .texi/.xml and diagnostic
output (twice in config/or1k/elf.opt) - and likewise the wwwdocs pages.
(That elf.opt file has twice 'newlib' and once 'Newlib'.)
-> adds this to the to-do list.
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
Re: [PATCH][_GLIBCXX_DEBUG] Remove useless checks
On Mon, 23 Jan 2023 at 06:02, François Dumont via Libstdc++ wrote: > > libstdc++: [_GLIBCXX_DEBUG] Remove useless constructor checks > > Creating a safe iterator from a normal iterator is done within the > library where we > already know that it is done correctly. The rare situation where a > user would use safe > iterators for his own purpose is non-Standard code so outside > _GLIBCXX_DEBUG scope. For > those reasons the __msg_init_singular is useless and can be removed. > > Additionally in the copy constructor used for post-increment and > post-decrement operators > the __msg_init_copy_singular check can also be ommitted because of > the preliminary > __msg_bad_inc and __msg_bad_dec checks. > > libstdc++-v3/ChangeLog: > > * include/debug/safe_iterator.h > (_Safe_iterator<>::_Unsafe_call): New. I don't like the name "unsafe call". Why is it unsafe? As you say above, we don't need to check because we know that it's only called in a context where it's safe. Can we call it _Unchecked instead of _Unsafe_call? That seems like a more accurate description of the behaviour. > (_Safe_iterator(const _Safe_iterator&, _Unsafe_call): New. > (_Safe_iterator::operator++(int)): Use latter. > (_Safe_iterator::operator--(int)): Likewise. > (_Safe_iterator(_Iterator, const _Safe_sequence_base*)): > Remove !_M_insular() > check. > * include/debug/safe_local_iterator.h > (_Safe_local_iterator<>::_Unsafe_call): > New. > (_Safe_local_iterator(const _Safe_local_iterator&, > _Unsafe_call): New. > (_Safe_local_iterator::operator++(int)): Use latter. > * src/c++11/debug.cc (_S_debug_messages): Add as comment > the _Debug_msg_id > entry associated to the array entry. These comments are a great idea, thanks. If you agree with the _Unchecked name, OK to commit with that change.
Re: [wwwdocs] gcc-13/changes.html + projects/gomp/: OpenMP update
On Mon, 23 Jan 2023, Tobias Burnus wrote: > Now committed with the suggestions taken into account. Nice - this feels rather clear to me (as a non-expert) now. :-) Thanks, Gerald
Re: [wwwdocs] gcc-13/changes.html + projects/gomp/: OpenMP update
Now committed with the suggestions taken into account. That is: for non-rect loop-nest support, add 'some' / set back to partial. I also changed the already-in-GCC-11 wording as it was a bit unclear to which word/topic the "which" in the original patch referred to - and the "some" made it even worse. 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 commit a18af43b161b6ff4ea6e3aaf08dd72cbacb53a89 Author: Tobias Burnus Date: Mon Jan 23 09:55:18 2023 +0100 OpenMP: Update gcc-13/changes + projects/gomp * htdocs/gcc-13/changes.html: Improve wording; mention nvptx reverse offload; add 'some' to Fortran non-rect-loop support. * htdocs/projects/gomp/index.html: Split clause/directive entry for 'allocate' and mark the clause variant as fully implemented. Set Fortran non-rect-loop support back to partial. --- htdocs/gcc-13/changes.html | 19 +-- htdocs/projects/gomp/index.html | 13 + 2 files changed, 22 insertions(+), 10 deletions(-) diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index ba42170c..6cd5dd64 100644 --- a/htdocs/gcc-13/changes.html +++ b/htdocs/gcc-13/changes.html @@ -59,12 +59,19 @@ a work-in-progress. https://gcc.gnu.org/projects/gomp/";>OpenMP - Reverse offload is now supported and the all clauses to the - requires directive are now accepted. However, the - requires_offload, unified_address - and unified_shared_memory clauses imply the initial - device (= the host) as the only available device. Fortran now - supports non-rectangular loop nests, which were added for C/C++ in GCC 11. + Reverse offload is now supported with nvptx devices. Additionally, the + requires handling has been improved and all clauses are + now accepted. If a requirement cannot be fulfilled for an accessible + device, this device is excluded from the list of available devices. This + may imply that the only device left is the host (the initial device). + In particular, requires_offload is currently unsupported on + AMD GCN devices while unified_address and + unified_shared_memory are unsupported by all non-host + devices. + + + OpenMP 5.0: Fortran now supports some non-rectangular loop nests; for + C/C++, the support was added in GCC 11. The following OpenMP 5.1 features have been added: the diff --git a/htdocs/projects/gomp/index.html b/htdocs/projects/gomp/index.html index 19ff3c7d..17cf1ad9 100644 --- a/htdocs/projects/gomp/index.html +++ b/htdocs/projects/gomp/index.html @@ -372,8 +372,8 @@ than listed, depending on resolved corner cases and optimizations. Non-rectangular loop nests -GCC 11GCC 13 -C/C++Fortran +GCC 11GCC 13 +C/C++ (full)Fortran (partial) Nested-parallel changes to max-active-levels-var ICV @@ -547,9 +547,14 @@ than listed, depending on resolved corner cases and optimizations. -align clause/modifier in allocate directive/clause and allocator directive +align clause in allocate directive +No + + + +align modifier in allocate clause GCC 12 -C/C++ on clause only + thread_limit clause to target construct
Re: [PATCH 5/9] loongarch: Don't add crtfastmath.o for -shared
On Fri, 13 Jan 2023, Richard Biener wrote:
> Don't add crtfastmath.o for -shared to avoid altering the FP
> environment when loading a shared library.
Ping.
> PR target/55522
> * config/loongarch/gnu-user.h (GNU_USER_TARGET_MATHFILE_SPEC):
> Don't add crtfastmath.o for -shared.
> ---
> gcc/config/loongarch/gnu-user.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/loongarch/gnu-user.h b/gcc/config/loongarch/gnu-user.h
> index c5b1afe530d..1dc6add62d4 100644
> --- a/gcc/config/loongarch/gnu-user.h
> +++ b/gcc/config/loongarch/gnu-user.h
> @@ -49,7 +49,7 @@ along with GCC; see the file COPYING3. If not see
> /* Similar to standard Linux, but adding -ffast-math support. */
> #undef GNU_USER_TARGET_MATHFILE_SPEC
> #define GNU_USER_TARGET_MATHFILE_SPEC \
> - "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s}"
> + "%{Ofast|ffast-math|funsafe-math-optimizations:%{!shared:crtfastmath.o%s}}"
>
> #undef LIB_SPEC
> #define LIB_SPEC GNU_USER_TARGET_LIB_SPEC
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)
Re: [PATCH 7/9] sparc: Don't add crtfastmath.o for -shared
On Fri, 13 Jan 2023, Richard Biener wrote:
> Don't add crtfastmath.o for -shared to avoid altering the FP
> environment when loading a shared library.
Ping.
> PR target/55522
> * config/sparc/freebsd.h (ENDFILE_SPEC): Don't add crtfastmath.o
> for -shared.
> * config/sparc/linux.h (ENDFILE_SPEC): Likewise.
> * config/sparc/linux64.h (ENDFILE_SPEC): Likewise.
> * config/sparc/sp-elf.h (ENDFILE_SPEC): Likewise.
> * config/sparc/sp64-elf.h (ENDFILE_SPEC): Likewise.
> ---
> gcc/config/sparc/freebsd.h | 2 +-
> gcc/config/sparc/linux.h| 2 +-
> gcc/config/sparc/linux64.h | 2 +-
> gcc/config/sparc/sp-elf.h | 2 +-
> gcc/config/sparc/sp64-elf.h | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/gcc/config/sparc/freebsd.h b/gcc/config/sparc/freebsd.h
> index 73850a31f58..a5aa3679547 100644
> --- a/gcc/config/sparc/freebsd.h
> +++ b/gcc/config/sparc/freebsd.h
> @@ -127,7 +127,7 @@ along with GCC; see the file COPYING3. If not see
>
> #undef ENDFILE_SPEC
> #define ENDFILE_SPEC \
> - "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} " \
> + "%{Ofast|ffast-math|funsafe-math-optimizations:%{!shared:crtfastmath.o%s}}
> " \
>FBSD_ENDFILE_SPEC
>
> /* We use GNU ld so undefine this so that attribute((init_priority)) works.
> */
> diff --git a/gcc/config/sparc/linux.h b/gcc/config/sparc/linux.h
> index 6a809e9092d..48386884d05 100644
> --- a/gcc/config/sparc/linux.h
> +++ b/gcc/config/sparc/linux.h
> @@ -30,7 +30,7 @@ along with GCC; see the file COPYING3. If not see
> #undef ENDFILE_SPEC
> #define ENDFILE_SPEC \
>GNU_USER_TARGET_ENDFILE_SPEC \
> - "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s}"
> + "%{Ofast|ffast-math|funsafe-math-optimizations:%{!shared:crtfastmath.o%s}}"
>
> /* -mcpu=native handling only makes sense with compiler running on
> a SPARC chip. */
> diff --git a/gcc/config/sparc/linux64.h b/gcc/config/sparc/linux64.h
> index d08a2ef96fe..4132cee4c8c 100644
> --- a/gcc/config/sparc/linux64.h
> +++ b/gcc/config/sparc/linux64.h
> @@ -47,7 +47,7 @@ along with GCC; see the file COPYING3. If not see
> #undef ENDFILE_SPEC
> #define ENDFILE_SPEC \
>GNU_USER_TARGET_ENDFILE_SPEC \
> - "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s}"
> + "%{Ofast|ffast-math|funsafe-math-optimizations:%{!shared:crtfastmath.o%s}}"
>
> /* The default code model. */
> #undef SPARC_DEFAULT_CMODEL
> diff --git a/gcc/config/sparc/sp-elf.h b/gcc/config/sparc/sp-elf.h
> index 53f03b951db..8bd2f54f05d 100644
> --- a/gcc/config/sparc/sp-elf.h
> +++ b/gcc/config/sparc/sp-elf.h
> @@ -32,7 +32,7 @@ along with GCC; see the file COPYING3. If not see
>
> #undef ENDFILE_SPEC
> #define ENDFILE_SPEC \
> - "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
> + "%{Ofast|ffast-math|funsafe-math-optimizations:%{!shared:crtfastmath.o%s}}
> \
> crtend.o%s crtn.o%s"
>
> /* Don't set the target flags, this is done by the linker script */
> diff --git a/gcc/config/sparc/sp64-elf.h b/gcc/config/sparc/sp64-elf.h
> index dc918c6ae24..866db10a343 100644
> --- a/gcc/config/sparc/sp64-elf.h
> +++ b/gcc/config/sparc/sp64-elf.h
> @@ -44,7 +44,7 @@ along with GCC; see the file COPYING3. If not see
>
> #undef ENDFILE_SPEC
> #define ENDFILE_SPEC \
> - "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
> + "%{Ofast|ffast-math|funsafe-math-optimizations:%{!shared:crtfastmath.o%s}}
> \
> crtend.o%s crtn.o%s"
>
> /* Use the default (for now). */
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)
Re: [PATCH 6/9] mips: Don't add crtfastmath.o for -shared
On Fri, 13 Jan 2023, Richard Biener wrote:
> Don't add crtfastmath.o for -shared to avoid altering the FP
> environment when loading a shared library.
Ping.
> PR target/55522
> * config/mips/gnu-user.h (GNU_USER_TARGET_MATHFILE_SPEC):
> Don't add crtfastmath.o for -shared.
> ---
> gcc/config/mips/gnu-user.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/mips/gnu-user.h b/gcc/config/mips/gnu-user.h
> index 9a540b8b53f..a4e5380b589 100644
> --- a/gcc/config/mips/gnu-user.h
> +++ b/gcc/config/mips/gnu-user.h
> @@ -139,7 +139,7 @@ extern const char *host_detect_local_cpu (int argc, const
> char **argv);
> /* Similar to standard Linux, but adding -ffast-math support. */
> #undef GNU_USER_TARGET_MATHFILE_SPEC
> #define GNU_USER_TARGET_MATHFILE_SPEC \
> - "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s}"
> + "%{Ofast|ffast-math|funsafe-math-optimizations:%{!shared:crtfastmath.o%s}}"
> #undef ENDFILE_SPEC
> #define ENDFILE_SPEC \
>GNU_USER_TARGET_MATHFILE_SPEC " " \
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)
Re: [PATCH 2/9] alpha: Don't add crtfastmath.o for -shared
On Fri, 13 Jan 2023, Richard Biener wrote:
> Don't add crtfastmath.o for -shared to avoid altering the FP
> environment when loading a shared library.
Ping.
> PR target/55522
> * config/alpha/linux.h (ENDFILE_SPEC): Don't add
> crtfastmath.o for -shared.
> ---
> gcc/config/alpha/linux.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/alpha/linux.h b/gcc/config/alpha/linux.h
> index 9c3ad5a1097..7d2f0e844f9 100644
> --- a/gcc/config/alpha/linux.h
> +++ b/gcc/config/alpha/linux.h
> @@ -106,7 +106,7 @@ along with GCC; see the file COPYING3. If not see
>
> #undef ENDFILE_SPEC
> #define ENDFILE_SPEC \
> - "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
> + "%{Ofast|ffast-math|funsafe-math-optimizations:%{!shared:crtfastmath.o%s}}
> \
> %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
>
> #define LINK_GCC_C_SEQUENCE_SPEC \
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)
[committed] libgomp.texi: Impl. status - non-rect loop nest only partial
As discussed in the thread
Re: [wwwdocs] gcc-13/changes.html + projects/gomp/: OpenMP update
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610324.html
in https://gcc.gnu.org/PR107424 and the thread starting at
OpenMP/Fortran: Partially fix non-rect loop nests [PR107424]
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610240.html
the Fortrans support is still incomplete.
As suggested in the wwwdocs thread (see link), the implementation status
for Fortran needs to be 'P'.
(Short version of the issue: currently, there are many issues with
non-rectangular loop nests; the nearly ready patches will fix those
for stride == -1 and 1. Ideas exist for other strides, but this may
take a few more days to get resolved.)
Committed as r13-5287-g20552407ae11b61fccb46b3e96a8814e790254e7
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
commit 20552407ae11b61fccb46b3e96a8814e790254e7
Author: Tobias Burnus
Date: Mon Jan 23 09:40:41 2023 +0100
libgomp.texi: Impl. status - non-rect loop nest only partial
libgomp/
* libgomp.texi (OpenMP 5.0): Set non-rectangular
loop nest back to 'P' as Fortran support is incomplete.
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 1267c2304a5..67a05111289 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -195,7 +195,7 @@ The OpenMP 4.5 specification is fully supported.
@tab complete but no non-host devices provides @code{unified_address},
@code{unified_shared_memory} or @code{reverse_offload}
@item @code{teams} construct outside an enclosing target region @tab Y @tab
-@item Non-rectangular loop nests @tab Y @tab
+@item Non-rectangular loop nests @tab P @tab Full support for C/C++, partial for Fortran
@item @code{!=} as relational-op in canonical loop form for C/C++ @tab Y @tab
@item @code{nonmonotonic} as default loop schedule modifier for worksharing-loop
constructs @tab Y @tab
Re: [PATCH] c++: Handle structured bindings like anon unions in initializers [PR108474]
On Sun, Jan 22, 2023 at 07:19:07PM -0500, Jason Merrill wrote: > > I was just trying to be careful, because unfortunately this spot > > doesn't mean it really is only expanded in static var DECL_INITIAL, > > it can make it into dynamic initializers, and most of DECL_VALUE_EXPRs > > appear only in runtime code, otherwise we'd have much more of these issues. > > But it shouldn't be harmful anywhere, right? > > > But if you think it is ok, I'll test tonight a version just with > > if (!data->genericize && DECL_HAS_VALUE_EXPR_P (stmt) > > OK with that change. > > Though, actually, why not instead fix expand_expr_real_1 (and staticp) to > look through DECL_VALUE_EXPR? I'm afraid that is way too late. GIMPLE optimizations don't try to regimplify expressions they take from DECL_INITIAL of static vars, they just unshare them and use them. So, if this is to be done in the generic code, it would need to be done by cgraph around the time when it gimplifies function if there is any such point for variables. Jakub
