[PATCH] match.pd: Fix ICE on BIT_INSERT_EXPR of BIT_FIELD_REF folding [PR113967]
Hi!
The following testcase ICEs, because BIT_FIELD_REF's position is not
multiple of the vector element's bit size and the code uses exact_div
to divide those 2 values.
For BIT_INSERT_EXPR, the tree-cfg.cc verification verifies the position
is a multiple of the inserted bit size when inserting into vectors,
but for BIT_FIELD_REF the position can be arbitrary if within the range.
The following patch fixes that, bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?
2024-02-19 Jakub Jelinek
PR tree-optimization/113967
* match.pd (bit_insert @0 (BIT_FIELD_REF @1 ..) ..): Require
in condition that @rpos is multiple of vector element size.
* gcc.dg/pr113967.c: New test.
--- gcc/match.pd.jj 2024-02-01 09:14:16.541550659 +0100
+++ gcc/match.pd2024-02-17 11:58:19.822913858 +0100
@@ -8586,7 +8586,9 @@ (define_operator_list SYNC_FETCH_AND_AND
|| optimize_vectors_before_lowering_p ())
&& types_match (@0, @1)
&& types_match (TREE_TYPE (TREE_TYPE (@0)), TREE_TYPE (@2))
- && TYPE_VECTOR_SUBPARTS (type).is_constant ())
+ && TYPE_VECTOR_SUBPARTS (type).is_constant ()
+ && multiple_p (wi::to_poly_offset (@rpos),
+wi::to_poly_offset (TYPE_SIZE (TREE_TYPE (type)
(with
{
unsigned HOST_WIDE_INT elsz
--- gcc/testsuite/gcc.dg/pr113967.c.jj 2024-02-17 12:01:06.784623682 +0100
+++ gcc/testsuite/gcc.dg/pr113967.c 2024-02-17 12:00:19.384273862 +0100
@@ -0,0 +1,14 @@
+/* PR tree-optimization/113967 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+typedef unsigned short W __attribute__((vector_size (4 * sizeof (short;
+
+void
+foo (W *p)
+{
+ W x = *p;
+ W y = {};
+ __builtin_memcpy (&y, 1 + (char *) &x, sizeof (short));
+ *p = y;
+}
Jakub
[PATCH] c-family, c++: Fix up handling of types which may have padding in __atomic_{compare_}exchange
On Fri, Feb 16, 2024 at 01:51:54PM +, Jonathan Wakely wrote:
> Ah, although __atomic_compare_exchange only takes pointers, the
> compiler replaces that with a call to __atomic_compare_exchange_n
> which takes the newval by value, which presumably uses an 80-bit FP
> register and so the padding bits become indeterminate again.
The problem is that __atomic_{,compare_}exchange lowering if it has
a supported atomic 1/2/4/8/16 size emits code like:
_3 = *p2;
_4 = VIEW_CONVERT_EXPR (_3);
so if long double or some small struct etc. has some carefully filled
padding bits, those bits can be lost on the assignment. The library call
for __atomic_{,compare_}exchange would actually work because it woiuld
load the value from memory using integral type or memcpy.
E.g. on
void
foo (long double *a, long double *b, long double *c)
{
__atomic_compare_exchange (a, b, c, false, __ATOMIC_RELAXED,
__ATOMIC_RELAXED);
}
we end up with -O0 with:
fldt(%rax)
fstpt -48(%rbp)
movq-48(%rbp), %rax
movq-40(%rbp), %rdx
i.e. load *c from memory into 387 register, store it back to uninitialized
stack slot (the padding bits are now random in there) and then load a
__uint128_t (pair of GPR regs). The problem is that we first load it using
whatever type the pointer points to and then VIEW_CONVERT_EXPR that value:
p2 = build_indirect_ref (loc, p2, RO_UNARY_STAR);
p2 = build1 (VIEW_CONVERT_EXPR, I_type, p2);
The following patch fixes that by creating a MEM_REF instead, with the
I_type type, but with the original pointer type on the second argument for
aliasing purposes, so we actually preserve the padding bits that way.
I've done that for types which may have padding and also for
non-integral/pointer types, because I fear even on floating point types
like double or float which don't have padding bits the copying through
floating point could misbehave in presence of sNaNs or unsupported bit
combinations.
With this patch instead of the above assembly we emit
movq8(%rax), %rdx
movq(%rax), %rax
I had to add support for MEM_REF in pt.cc, though with the assumption
that it has been already originally created with non-dependent
types/operands (which is the case here for the __atomic*exchange lowering).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-19 Jakub Jelinek
gcc/c-family/
* c-common.cc (resolve_overloaded_atomic_exchange): For
non-integral/pointer types or types which may need padding
instead of setting p1 to VIEW_CONVERT_EXPR (*p1), set it to
MEM_REF with p1 and (typeof (p1)) 0 operands and I_type type.
(resolve_overloaded_atomic_compare_exchange): Similarly for p2.
gcc/cp/
* pt.cc (tsubst_expr): Handle MEM_REF.
gcc/testsuite/
* g++.dg/ext/atomic-5.C: New test.
--- gcc/c-family/c-common.cc.jj 2024-02-16 17:33:43.995739790 +0100
+++ gcc/c-family/c-common.cc2024-02-17 11:11:34.029474214 +0100
@@ -7794,8 +7794,23 @@ resolve_overloaded_atomic_exchange (loca
p0 = build1 (VIEW_CONVERT_EXPR, I_type_ptr, p0);
(*params)[0] = p0;
/* Convert new value to required type, and dereference it. */
- p1 = build_indirect_ref (loc, p1, RO_UNARY_STAR);
- p1 = build1 (VIEW_CONVERT_EXPR, I_type, p1);
+ if ((!INTEGRAL_TYPE_P (TREE_TYPE (TREE_TYPE (p1)))
+ && !POINTER_TYPE_P (TREE_TYPE (TREE_TYPE (p1
+ || clear_padding_type_may_have_padding_p (TREE_TYPE (TREE_TYPE (p1
+{
+ /* If *p1 type can have padding or may involve floating point which
+could e.g. be promoted to wider precision and demoted afterwards,
+state of padding bits might not be preserved. */
+ build_indirect_ref (loc, p1, RO_UNARY_STAR);
+ p1 = build2_loc (loc, MEM_REF, I_type,
+ build1 (VIEW_CONVERT_EXPR, I_type_ptr, p1),
+ build_zero_cst (TREE_TYPE (p1)));
+}
+ else
+{
+ p1 = build_indirect_ref (loc, p1, RO_UNARY_STAR);
+ p1 = build1 (VIEW_CONVERT_EXPR, I_type, p1);
+}
(*params)[1] = p1;
/* Move memory model to the 3rd position, and end param list. */
@@ -7874,8 +7889,23 @@ resolve_overloaded_atomic_compare_exchan
(*params)[1] = p1;
/* Convert desired value to required type, and dereference it. */
- p2 = build_indirect_ref (loc, p2, RO_UNARY_STAR);
- p2 = build1 (VIEW_CONVERT_EXPR, I_type, p2);
+ if ((!INTEGRAL_TYPE_P (TREE_TYPE (TREE_TYPE (p2)))
+ && !POINTER_TYPE_P (TREE_TYPE (TREE_TYPE (p2
+ || clear_padding_type_may_have_padding_p (TREE_TYPE (TREE_TYPE (p2
+{
+ /* If *p2 type can have padding or may involve floating point which
+could e.g. be promoted to wider precision and demoted afterwards,
+state of padding bits might not be preserved. */
+ build_indirect_ref (loc, p2, RO_UNARY_STAR);
+ p2 = build2_loc (loc, MEM_REF, I_type,
+ build1 (VIEW_CONVERT_EXPR, I_type_ptr, p2),
+
Re: [PATCH v2] RISC-V: Suppress the vsetvl fusion for conflict successors
Ping this patch which is simple fix on VSETVL PASS.
Ok for trunk ?
juzhe.zh...@rivai.ai
From: Juzhe-Zhong
Date: 2024-02-01 17:02
To: gcc-patches
CC: kito.cheng; kito.cheng; jeffreyalaw; rdapp.gcc; Juzhe-Zhong
Subject: [PATCH v2] RISC-V: Suppress the vsetvl fusion for conflict successors
Update in v2: Add dump information.
This patch fixes the following ineffective vsetvl insertion:
#include "riscv_vector.h"
void f (int32_t * restrict in, int32_t * restrict out, size_t n, size_t cond,
size_t cond2)
{
for (size_t i = 0; i < n; i++)
{
if (i == cond) {
vint8mf8_t v = *(vint8mf8_t*)(in + i + 100);
*(vint8mf8_t*)(out + i + 100) = v;
} else if (i == cond2) {
vfloat32mf2_t v = *(vfloat32mf2_t*)(in + i + 200);
*(vfloat32mf2_t*)(out + i + 200) = v;
} else if (i == (cond2 - 1)) {
vuint16mf2_t v = *(vuint16mf2_t*)(in + i + 300);
*(vuint16mf2_t*)(out + i + 300) = v;
} else {
vint8mf4_t v = *(vint8mf4_t*)(in + i + 400);
*(vint8mf4_t*)(out + i + 400) = v;
}
}
}
Before this patch:
f:
.LFB0:
.cfi_startproc
beq a2,zero,.L12
addia7,a0,400
addia6,a1,400
addia0,a0,1600
addia1,a1,1600
li a5,0
addit6,a4,-1
vsetvli t3,zero,e8,mf8,ta,ma ---> ineffective uplift
.L7:
beq a3,a5,.L15
beq a4,a5,.L16
beq t6,a5,.L17
vsetvli t1,zero,e8,mf4,ta,ma
vle8.v v1,0(a0)
vse8.v v1,0(a1)
vsetvli t3,zero,e8,mf8,ta,ma
.L4:
addia5,a5,1
addia7,a7,4
addia6,a6,4
addia0,a0,4
addia1,a1,4
bne a2,a5,.L7
.L12:
ret
.L15:
vle8.v v1,0(a7)
vse8.v v1,0(a6)
j .L4
.L17:
vsetvli t1,zero,e8,mf4,ta,ma
addit5,a0,-400
addit4,a1,-400
vle16.v v1,0(t5)
vse16.v v1,0(t4)
vsetvli t3,zero,e8,mf8,ta,ma
j .L4
.L16:
addit5,a0,-800
addit4,a1,-800
vle32.v v1,0(t5)
vse32.v v1,0(t4)
j .L4
It's obvious that we are hoisting the e8mf8 vsetvl to the top. It's ineffective
since e8mf8 comes from
low probability block which is if (i == cond).
For this case, we disable such fusion.
After this patch:
f:
beq a2,zero,.L12
addi a7,a0,400
addi a6,a1,400
addi a0,a0,1600
addi a1,a1,1600
li a5,0
addi t6,a4,-1
.L7:
beq a3,a5,.L15
beq a4,a5,.L16
beq t6,a5,.L17
vsetvli t1,zero,e8,mf4,ta,ma
vle8.v v1,0(a0)
vse8.v v1,0(a1)
.L4:
addi a5,a5,1
addi a7,a7,4
addi a6,a6,4
addi a0,a0,4
addi a1,a1,4
bne a2,a5,.L7
.L12:
ret
.L15:
vsetvli t3,zero,e8,mf8,ta,ma
vle8.v v1,0(a7)
vse8.v v1,0(a6)
j .L4
.L17:
addi t5,a0,-400
addi t4,a1,-400
vsetvli t1,zero,e8,mf4,ta,ma
vle16.v v1,0(t5)
vse16.v v1,0(t4)
j .L4
.L16:
addi t5,a0,-800
addi t4,a1,-800
vsetvli t3,zero,e32,mf2,ta,ma
vle32.v v1,0(t5)
vse32.v v1,0(t4)
j .L4
Tested on both RV32/RV64 no regression. Ok for trunk ?
PR target/113696
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (pre_vsetvl::earliest_fuse_vsetvl_info):
Suppress vsetvl fusion.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/pr113696.c: New test.
---
gcc/config/riscv/riscv-vsetvl.cc | 25 ++
.../gcc.target/riscv/rvv/vsetvl/pr113696.c| 26 +++
2 files changed, 51 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/pr113696.c
diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc
index cec862329c5..28b7534d970 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -2959,6 +2959,31 @@ pre_vsetvl::earliest_fuse_vsetvl_info (int iter)
src_block_info.set_empty_info ();
src_block_info.probability
= profile_probability::uninitialized ();
+ /* See PR113696, we should reset immediate dominator to
+ empty since we may uplift ineffective vsetvl which
+ locate at low probability block. */
+ basic_block dom
+ = get_immediate_dominator (CDI_DOMINATORS, eg->src);
+ auto &dom_block_info = get_block_info (dom);
+ if (dom_block_info.has_info ()
+ && !m_dem.compatible_p (
+ dom_block_info.get_exit_info (), curr_info))
+ {
+ dom_block_info.set_empty_info ();
+ dom_block_info.probability
+ = profile_probability::uninitialized ();
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ {
+ fprintf (dump_file,
+" Reset dominator bb %u:",
+dom->index);
+ prev_info.dump (dump_file, "");
+ fprintf (dump_file,
+" due to (same probability or no "
+"compatible reaching):");
+ curr_info.dump (dump_file, "");
+ }
+ }
changed = true;
}
/* Choose the one with higher probability. */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/pr113696.c
b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/pr113696.c
new file mode 10064
Re: [PATCH v1] Internal-fn: Add new internal function SAT_ADDU
On Sat, Feb 17, 2024 at 11:30 AM wrote:
>
> From: Pan Li
>
> This patch would like to add the middle-end presentation for the
> unsigned saturation add. Aka set the result of add to the max
> when overflow. It will take the pattern similar as below.
>
> SAT_ADDU (x, y) => (x + y) | (-(TYPE)((TYPE)(x + y) < x))
>
> Take uint8_t as example, we will have:
>
> * SAT_ADDU (1, 254) => 255.
> * SAT_ADDU (1, 255) => 255.
> * SAT_ADDU (2, 255) => 255.
> * SAT_ADDU (255, 255) => 255.
>
> The patch also implement the SAT_ADDU in the riscv backend as
> the sample. Given below example:
>
> uint64_t sat_add_u64 (uint64_t x, uint64_t y)
> {
> return (x + y) | (- (uint64_t)((uint64_t)(x + y) < x));
> }
>
> Before this patch:
>
> uint64_t sat_add_uint64_t (uint64_t x, uint64_t y)
> {
> long unsigned int _1;
> _Bool _2;
> long unsigned int _3;
> long unsigned int _4;
> uint64_t _7;
> long unsigned int _10;
> __complex__ long unsigned int _11;
>
> ;; basic block 2, loop depth 0
> ;;pred: ENTRY
> _11 = .ADD_OVERFLOW (x_5(D), y_6(D));
> _1 = REALPART_EXPR <_11>;
> _10 = IMAGPART_EXPR <_11>;
> _2 = _10 != 0;
> _3 = (long unsigned int) _2;
> _4 = -_3;
> _7 = _1 | _4;
> return _7;
> ;;succ: EXIT
>
> }
>
> After this patch:
>
> uint64_t sat_add_uint64_t (uint64_t x, uint64_t y)
> {
> uint64_t _7;
>
> ;; basic block 2, loop depth 0
> ;;pred: ENTRY
> _7 = .SAT_ADDU (x_5(D), y_6(D)); [tail call]
> return _7;
> ;;succ: EXIT
>
> }
>
> Then we will have the middle-end representation like .SAT_ADDU after
> this patch.
I'll note that on RTL we already have SS_PLUS/US_PLUS and friends and
the corresponding ssadd/usadd optabs. There's not much documentation
unfortunately besides the use of gen_*_fixed_libfunc usage where the comment
suggests this is used for fixed-point operations. It looks like arm uses
fractional/accumulator modes for this but for example bfin has ssaddsi3.
So the question is whether the fixed-point case can be distinguished from
the integer case based on mode.
There's also FIXED_POINT_TYPE on the GENERIC/GIMPLE side and
no special tree operator codes for them. So compared to what appears
to be the case on RTL we'd need a way to represent saturating integer
operations on GIMPLE.
The natural thing is to use direct optab internal functions (that's what you
basically did, but you added a new optab, IMO without good reason).
More GIMPLE-like would be to let the types involved decide whether
it's signed or unsigned saturation. That's actually what I'd prefer here
and if we don't map 1:1 to optabs then instead use tree codes like
S_PLUS_EXPR (mimicing RTL here).
Any other opinions? Anyone knows more about fixed-point and RTL/modes?
Richard.
> PR target/51492
> PR target/112600
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-protos.h (riscv_expand_saturation_addu):
> New func decl for the SAT_ADDU expand.
> * config/riscv/riscv.cc (riscv_expand_saturation_addu): New func
> impl for the SAT_ADDU expand.
> * config/riscv/riscv.md (sat_addu_3): New pattern to impl
> the standard name SAT_ADDU.
> * doc/md.texi: Add doc for SAT_ADDU.
> * internal-fn.cc (commutative_binary_fn_p): Add type IFN_SAT_ADDU.
> * internal-fn.def (SAT_ADDU): Add SAT_ADDU.
> * match.pd: Add simplify pattern patch for SAT_ADDU.
> * optabs.def (OPTAB_D): Add sat_addu_optab.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/sat_addu-1.c: New test.
> * gcc.target/riscv/sat_addu-2.c: New test.
> * gcc.target/riscv/sat_addu-3.c: New test.
> * gcc.target/riscv/sat_addu-4.c: New test.
> * gcc.target/riscv/sat_addu-run-1.c: New test.
> * gcc.target/riscv/sat_addu-run-2.c: New test.
> * gcc.target/riscv/sat_addu-run-3.c: New test.
> * gcc.target/riscv/sat_addu-run-4.c: New test.
> * gcc.target/riscv/sat_arith.h: New test.
>
> Signed-off-by: Pan Li
> ---
> gcc/config/riscv/riscv-protos.h | 1 +
> gcc/config/riscv/riscv.cc | 46 +
> gcc/config/riscv/riscv.md | 11 +
> gcc/doc/md.texi | 11 +
> gcc/internal-fn.cc| 1 +
> gcc/internal-fn.def | 1 +
> gcc/match.pd | 22 +
> gcc/optabs.def| 2 +
> gcc/testsuite/gcc.target/riscv/sat_addu-1.c | 18 +++
> gcc/testsuite/gcc.target/riscv/sat_addu-2.c | 20
> gcc/testsuite/gcc.target/riscv/sat_addu-3.c | 17 +++
> gcc/testsuite/gcc.target/riscv/sat_addu-4.c | 16 ++
> .../gcc.target/riscv/sat_addu-run-1.c | 42
> .../gcc.target/riscv/sat_addu-run-2.c | 42
> .../gcc.target/riscv/sat_addu-run-3.c | 42
> .../gcc.target/r
Re: [PATCH][_GLIBCXX_DEBUG] Fix std::__niter_base behavior
On 2/17/24 15:14, François Dumont wrote:
Thanks for the link, tested and committed.
I assume this is the cause for the below failure now,
$ cat test.cc
#include
#include
void f(std::vector &v, void const * p) {
std::erase(v, p);
}
$ ~/gcc/inst/bin/g++ -std=c++20 -D_GLIBCXX_DEBUG -fsyntax-only test.cc
In file included from ~/gcc/inst/include/c++/14.0.1/algorithm:60,
from test.cc:1:
~/gcc/inst/include/c++/14.0.1/bits/stl_algobase.h: In instantiation of ‘constexpr _From std::__niter_wrap(_From, _To) [with
_From = __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, __debug::vector, random_access_iterator_tag>; _To =
__gnu_cxx::__normal_iterator > >]’:
~/gcc/inst/include/c++/14.0.1/vector:144:29: required from ‘constexpr typename std::__debug::vector<_Tp,
_Allocator>::size_type std::erase(__debug::vector<_Tp, _Alloc>&, const _Up&) [with _Tp = const
void*; _Alloc = allocator; _Up = const void*; typename __debug::vector<_Tp,
_Allocator>::size_type = long unsigned int]’
144 | __cont.erase(__niter_wrap(__cont.begin(), __removed),
|^~~
test.cc:4:15: required from here
4 | std::erase(v, p);
| ~~^~
~/gcc/inst/include/c++/14.0.1/bits/stl_algobase.h:347:30: error: no match for ‘operator-’
(operand types are ‘__gnu_cxx::__normal_iterator > >’ and ‘const void**’)
347 | { return __from + (__res - std::__niter_base(__from)); }
| ~~~^~~~
In file included from ~/gcc/inst/include/c++/14.0.1/bits/stl_algobase.h:67:
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:1148:7: note: candidate: ‘constexpr
__gnu_cxx::__normal_iterator<_Iterator, _Container> __gnu_cxx::__normal_iterator<_Iterator,
_Container>::operator-(difference_type) const [with _Iterator = const void**; _Container =
std::__cxx1998::vector >; difference_type = long
int]’ (near match)
1148 | operator-(difference_type __n) const _GLIBCXX_NOEXCEPT
| ^~~~
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:1148:7: note: conversion of
argument 1 would be ill-formed:
~/gcc/inst/include/c++/14.0.1/bits/stl_algobase.h:347:49: error: invalid conversion from ‘const
void**’ to ‘__gnu_cxx::__normal_iterator > >::difference_type’ {aka ‘long int’} [-fpermissive]
347 | { return __from + (__res - std::__niter_base(__from)); }
|~^~~~
| |
| const void**
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:618:5: note: candidate: ‘template constexpr decltype ((__y.base() - __x.base())) std::operator-(const
reverse_iterator<_IteratorL>&, const reverse_iterator<_IteratorR>&)’
618 | operator-(const reverse_iterator<_IteratorL>& __x,
| ^~~~
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:618:5: note: template
argument deduction/substitution failed:
~/gcc/inst/include/c++/14.0.1/bits/stl_algobase.h:347:30: note:
‘__gnu_cxx::__normal_iterator > >’ is not derived from ‘const
std::reverse_iterator<_IteratorL>’
347 | { return __from + (__res - std::__niter_base(__from)); }
| ~~~^~~~
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:1789:5: note: candidate: ‘template constexpr decltype ((__x.base() - __y.base())) std::operator-(const
move_iterator<_IteratorL>&, const move_iterator<_IteratorR>&)’
1789 | operator-(const move_iterator<_IteratorL>& __x,
| ^~~~
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:1789:5: note: template
argument deduction/substitution failed:
~/gcc/inst/include/c++/14.0.1/bits/stl_algobase.h:347:30: note:
‘__gnu_cxx::__normal_iterator > >’ is not derived from ‘const
std::move_iterator<_IteratorL>’
347 | { return __from + (__res - std::__niter_base(__from)); }
| ~~~^~~~
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:1312:5: note: candidate: ‘template constexpr decltype ((__lhs.base() - __rhs.base()))
__gnu_cxx::operator-(const __normal_iterator<_IteratorL, _Container>&, const
__normal_iterator<_IteratorR, _Container>&)’
1312 | operator-(const __normal_iterator<_IteratorL, _Container>& __lhs,
| ^~~~
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:1312:5: note: template
argument deduction/substitution failed:
~/gcc/inst/include/c++/14.0.1/bits/stl_algobase.h:347:30: note: mismatched types
‘const __gnu_cxx::__normal_iterator<_IteratorR, _Container>’ and ‘const void**’
347 | { return __from + (__res - std::__niter_base(__from)); }
| ~~~^~~~
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:1325:5: note: candidate: ‘template constexpr typename __gnu_cxx::__normal_iterator<_Iterator, _Container>
[PATCH] Fix testcase for platform without gnu/stubs-x32.h
target maybe_x32 doesn't check if platform has gnu/stubs-x32.h, but
it's included by stdint.h in the testcase.
Adjust testcase: remove stdint.h, use 'typedef long long int64_t'
instead.
Commit as an obvious patch.
gcc/testsuite/ChangeLog:
PR target/113711
* gcc.target/i386/apx-ndd-x32-1.c: Adjust testcase.
---
gcc/testsuite/gcc.target/i386/apx-ndd-x32-1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/apx-ndd-x32-1.c
b/gcc/testsuite/gcc.target/i386/apx-ndd-x32-1.c
index 4280d400458..74197dbc641 100644
--- a/gcc/testsuite/gcc.target/i386/apx-ndd-x32-1.c
+++ b/gcc/testsuite/gcc.target/i386/apx-ndd-x32-1.c
@@ -3,7 +3,7 @@
/* { dg-require-effective-target maybe_x32 } */
/* { dg-options "-mapxf -O2 -mx32" } */
-#include
+typedef long long int64_t;
#define FOO(TYPE, OP_NAME, OP, IMM)\
TYPE \
--
2.31.1
RE: [PATCH V4 4/5] RISC-V: Quick and simple fixes to testcases that break due to reordering
For calling-convention-*.c, LGTM but one nit about change log. Take **Update**
here may make others not easy to learn what you did about the file.
You can say similar to "Rearrange and adjust the asm-checker times" or
likewise. Of course, you can refine the changelog when commit.
> * gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c: update
For the rest part, I think you need to wait for the comments from Juzhe or Kito.
Pan
-Original Message-
From: Edwin Lu
Sent: Thursday, February 15, 2024 9:11 AM
To: gcc-patches@gcc.gnu.org
Cc: gnu-toolch...@rivosinc.com; Edwin Lu
Subject: [PATCH V4 4/5] RISC-V: Quick and simple fixes to testcases that break
due to reordering
The following test cases are easily fixed with small updates to the expected
assembly order. Additionally make calling-convention testcases more robust
PR target/113249
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c: update
* gcc.target/riscv/rvv/autovec/vls/calling-convention-2.c: ditto
* gcc.target/riscv/rvv/autovec/vls/calling-convention-3.c: ditto
* gcc.target/riscv/rvv/autovec/vls/calling-convention-4.c: ditto
* gcc.target/riscv/rvv/autovec/vls/calling-convention-5.c: ditto
* gcc.target/riscv/rvv/autovec/vls/calling-convention-6.c: ditto
* gcc.target/riscv/rvv/autovec/vls/calling-convention-7.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-12.c: reorder assembly
* gcc.target/riscv/rvv/base/binop_vx_constraint-16.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-17.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-19.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-21.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-23.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-25.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-27.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-29.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-31.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-33.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-35.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-4.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-40.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-44.c: ditto
* gcc.target/riscv/rvv/base/binop_vx_constraint-8.c: ditto
* gcc.target/riscv/rvv/base/shift_vx_constraint-1.c: ditto
* gcc.target/riscv/rvv/vsetvl/avl_single-107.c: change expected vsetvl
Signed-off-by: Edwin Lu
---
V1-3:
- Patch did not exist
V4:
- New patch
- improve calling-convention testcases (calling-conventions)
- reorder expected function body assembly (binop/shift_vx_constraint)
- change expected value (avl_single)
---
.../rvv/autovec/vls/calling-convention-1.c| 27 ---
.../rvv/autovec/vls/calling-convention-2.c| 23 ++--
.../rvv/autovec/vls/calling-convention-3.c| 18 -
.../rvv/autovec/vls/calling-convention-4.c| 12 -
.../rvv/autovec/vls/calling-convention-5.c| 22 ++-
.../rvv/autovec/vls/calling-convention-6.c| 17
.../rvv/autovec/vls/calling-convention-7.c| 12 -
.../riscv/rvv/base/binop_vx_constraint-12.c | 4 +--
.../riscv/rvv/base/binop_vx_constraint-16.c | 4 +--
.../riscv/rvv/base/binop_vx_constraint-17.c | 4 +--
.../riscv/rvv/base/binop_vx_constraint-19.c | 4 +--
.../riscv/rvv/base/binop_vx_constraint-21.c | 4 +--
.../riscv/rvv/base/binop_vx_constraint-23.c | 4 +--
.../riscv/rvv/base/binop_vx_constraint-25.c | 4 +--
.../riscv/rvv/base/binop_vx_constraint-27.c | 4 +--
.../riscv/rvv/base/binop_vx_constraint-29.c | 4 +--
.../riscv/rvv/base/binop_vx_constraint-31.c | 4 +--
.../riscv/rvv/base/binop_vx_constraint-33.c | 4 +--
.../riscv/rvv/base/binop_vx_constraint-35.c | 4 +--
.../riscv/rvv/base/binop_vx_constraint-4.c| 4 +--
.../riscv/rvv/base/binop_vx_constraint-40.c | 4 +--
.../riscv/rvv/base/binop_vx_constraint-44.c | 4 +--
.../riscv/rvv/base/binop_vx_constraint-8.c| 4 +--
.../riscv/rvv/base/shift_vx_constraint-1.c| 5 +---
.../riscv/rvv/vsetvl/avl_single-107.c | 2 +-
25 files changed, 140 insertions(+), 62 deletions(-)
diff --git
a/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c
index 41e31c258f8..217885c2d67 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c
@@ -143,12 +143,33 @@ DEF_RET1_ARG9 (v1024qi)
DEF_RET1_ARG9 (v2048qi)
DEF_RET1_ARG9 (v4096qi)
+// RET1_ARG0 tests
/* { dg-final { scan-assembler-times {li\s+a[0-1],\s*0} 9 } } */
+/* { dg-final { scan-assembler-times {
Re: [PATCH] m68k: restore bootstrap
On Sun, 2024-02-18 at 08:42 -0700, Jeff Law wrote: > > On 2/18/24 02:18, Mikael Pettersson wrote: > > m68k fails to bootstrap since -ffold-mem-offsets was introduced, > > in what looks like wrong-code during stage2. > > > > To restore bootstrap this disables -ffold-mem-offsets on m68k. > > It's not ideal, but better than keeping bootstraps broken until > > the root cause is debugged and fixed. > > > > Tested with a bootstrap and regression test run on m68k-linux-gnu. > > > > Ok for master? (I'll need help getting it committed.) > > > > gcc/ > > PR target/113357 > > * config/m68k/m68k.cc (m68k_option_override): Disable > > -ffold-mem-offsets. Fix typo in comment. > Definitely not OK.This needs to be debugged further, just disabling > the pass is not the right solution here. > > It is also worth noting I'm bootstrapping and regression testing the > m68k weekly. > > Jeff, could you please consider sharing your test setup so that others can reproduce it as well? I'd be really better if more people had access to a unified test setup and methodology. Best regards, Oleg Endo
Re: CI for "Option handling: add documentation URLs"
Hi David, On Thu, Jan 04, 2024 at 09:57:09AM -0500, David Malcolm wrote: > I've pushed the .opt.urls patch kit to gcc trunk [1], so hopefully the > CI check you wrote can go live now. And then I was on vacation myself and forgot. I am sorry. So, I did try the regenerate-opt-urls locally, and it did generate the attached diff. Which seems to show we really need this automated. Going over the diff. The -Winfinite-recursion in rust does indeed seem new. As do the -mapx-inline-asm-use-gpr32 and mevex512 for i386. And the avr options -mskip-bug, -mflmap and mrodata-in-ram. The change in common.opt.urls for -Wuse-after-free comes from it being moved from c++ to the c-family. The changes in mips.opt.urls seem to come from commit 46df1369 "doc/invoke: Remove duplicate explicit-relocs entry of MIPS". The changes in c.opt.urls seem mostly reordering. The sorting makes more sense after the diff imho. And must have come from commit 4666cbde5 "Sort warning options in c-family/c.opt". Also the documentation for -Warray-parameter was fixed. So I think the regenerate-opt-urls check does work as intended. So lets automate it, because it looks like nobody regenerated the url.opts after updating the documentation. But we should first apply this diff. Could you double check it is sane/correct? Thanks, Mark
[r14-9028 Regression] FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for errors, line 3350) on Linux/x86_64
On Linux/x86_64,
7f3d900684ad989164114f25eb46a33871c6533d is the first bad commit
commit 7f3d900684ad989164114f25eb46a33871c6533d
Author: Jonathan Wakely
Date: Wed Feb 7 11:31:10 2024 +
libstdc++: Fix FAIL: 26_numerics/random/pr60037-neg.cc [PR113931]
caused
FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for errors, line
3350)
FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-9028/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check
RUNTESTFLAGS="conformance.exp=26_numerics/random/pr60037-neg.cc
--target_board='unix{-m32}'"
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check
RUNTESTFLAGS="conformance.exp=26_numerics/random/pr60037-neg.cc
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check
RUNTESTFLAGS="conformance.exp=26_numerics/random/pr60037-neg.cc
--target_board='unix{-m64}'"
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check
RUNTESTFLAGS="conformance.exp=26_numerics/random/pr60037-neg.cc
--target_board='unix{-m64\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at haochen dot jiang at intel.com.)
(If you met problems with cascadelake related, disabling AVX512F in command
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)
[r14-8925 Regression] FAIL: gcc.dg/torture/pr56689.c -O3 -g (test for excess errors) on Linux/x86_64
On Linux/x86_64,
1e3f78dbb328a2f2db8def241372cb947d9cb7eb is the first bad commit
commit 1e3f78dbb328a2f2db8def241372cb947d9cb7eb
Author: Richard Biener
Date: Mon Feb 12 10:40:42 2024 +0100
tree-optimization/113863 - elide degenerate virtual PHIs when moving ee
stores
caused
FAIL: gcc.c-torture/compile/920723-1.c -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler
error: Segmentation fault)
FAIL: gcc.c-torture/compile/920723-1.c -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess
errors)
FAIL: gcc.c-torture/compile/920723-1.c -O3 -g (internal compiler error:
Segmentation fault)
FAIL: gcc.c-torture/compile/920723-1.c -O3 -g (test for excess errors)
FAIL: gcc.dg/torture/pr56689.c -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions (internal compiler error:
Segmentation fault)
FAIL: gcc.dg/torture/pr56689.c -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions (test for excess errors)
FAIL: gcc.dg/torture/pr56689.c -O3 -g (internal compiler error: Segmentation
fault)
FAIL: gcc.dg/torture/pr56689.c -O3 -g (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-8925/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="compile.exp=gcc.c-torture/compile/920723-1.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="compile.exp=gcc.c-torture/compile/920723-1.c
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg-torture.exp=gcc.dg/torture/pr56689.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg-torture.exp=gcc.dg/torture/pr56689.c
--target_board='unix{-m64\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at haochen dot jiang at intel.com.)
(If you met problems with cascadelake related, disabling AVX512F in command
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)
[r14-8998 Regression] FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for excess errors) on Linux/x86_64
On Linux/x86_64,
c9ce332b557bb95987d038d98ea929cdfd1eae1d is the first bad commit
commit c9ce332b557bb95987d038d98ea929cdfd1eae1d
Author: Jonathan Wakely
Date: Wed Feb 7 11:31:10 2024 +
libstdc++: Use 128-bit arithmetic for std::linear_congruential_engine
[PR87744]
caused
FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for errors, line
271)
FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-8998/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check
RUNTESTFLAGS="conformance.exp=26_numerics/random/pr60037-neg.cc
--target_board='unix{-m32}'"
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check
RUNTESTFLAGS="conformance.exp=26_numerics/random/pr60037-neg.cc
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check
RUNTESTFLAGS="conformance.exp=26_numerics/random/pr60037-neg.cc
--target_board='unix{-m64}'"
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check
RUNTESTFLAGS="conformance.exp=26_numerics/random/pr60037-neg.cc
--target_board='unix{-m64\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at haochen dot jiang at intel.com.)
(If you met problems with cascadelake related, disabling AVX512F in command
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)
[PATCH] libstdc++, Darwin: Handle a linker warning [PR112397].
Tested on i686-darwin9, x86_64-darwin14,17,19,21,23, x86_64-linux,
aarch64-linux-gnu,
OK for trunk?
eventual back-ports?
thanks
Iain
--- 8< ---
Darwin's linker warns when we make a direct branch to code that is
in a weak definition (citing that if a different implementation of
the weak function is chosen by the dynamic linker this would be an
error).
As the analysis in the PR shows, this can happen when we have hot/
cold partitioning and there is an error path that is primarily cold
but makes use of epilogue code in the hot section. In this simple
case, we can easily deduce that the code is in fact safe; however
that is not something we can realistically implement in the linker.
Since the user-replaceable allocators are implemented using weak
definitions, this is a warning that is frequently flagged up in both
the testsuite and end-user code.
The chosen solution here is to suppress the hot/cold partitioning for
these cases (it is unlikely to impact performance much c.f. the
actual allocation).
PR target/112397
libstdc++-v3/ChangeLog:
* configure: Regenerate.
* configure.ac: Detect if we are building for Darwin.
* libsupc++/Makefile.am: If we are building for Darwin, then
suppress hot/cold partitioning for the array allocators.
* libsupc++/Makefile.in: Regenerated.
Signed-off-by: Iain Sandoe
Co-authored-by: Jonathan Wakely
---
libstdc++-v3/configure | 35 +++---
libstdc++-v3/configure.ac | 6 +
libstdc++-v3/libsupc++/Makefile.am | 8 +++
libstdc++-v3/libsupc++/Makefile.in | 6 +
4 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index c68cac4f345..37396bd6ebb 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/configure.ac
@@ -109,6 +109,12 @@ ACX_LT_HOST_FLAGS
AC_SUBST(enable_shared)
AC_SUBST(enable_static)
AM_CONDITIONAL([ENABLE_DARWIN_AT_RPATH], [test x$enable_darwin_at_rpath =
xyes])
+os_is_darwin=no
+case ${host_os} in
+ darwin*) os_is_darwin=yes ;;
+ *) ;;
+esac
+AM_CONDITIONAL([OS_IS_DARWIN], [test x${os_is_darwin} = xyes])
if test "$enable_vtable_verify" = yes; then
predep_objects_CXX="${predep_objects_CXX}
${glibcxx_builddir}/../libgcc/vtv_start.o"
diff --git a/libstdc++-v3/libsupc++/Makefile.am
b/libstdc++-v3/libsupc++/Makefile.am
index d0e1618507e..e151ce7a1fe 100644
--- a/libstdc++-v3/libsupc++/Makefile.am
+++ b/libstdc++-v3/libsupc++/Makefile.am
@@ -132,6 +132,14 @@ atomicity_file =
${glibcxx_srcdir}/$(ATOMICITY_SRCDIR)/atomicity.h
atomicity.cc: ${atomicity_file}
$(LN_S) ${atomicity_file} ./atomicity.cc || true
+if OS_IS_DARWIN
+# See PR 112397
+new_opvnt.lo: new_opvnt.cc
+ $(LTCXXCOMPILE) -fno-reorder-blocks-and-partition -I. -c $<
+new_opvnt.o: new_opvnt.cc
+ $(CXXCOMPILE) -fno-reorder-blocks-and-partition -I. -c $<
+endif
+
# AM_CXXFLAGS needs to be in each subdirectory so that it can be
# modified in a per-library or per-sub-library way. Need to manually
# set this option because CONFIG_CXXFLAGS has to be after
--
2.39.2 (Apple Git-143)
[PATCH] x86-64: Check R_X86_64_CODE_6_GOTTPOFF support
If assembler and linker supports
add %reg1, name@gottpoff(%rip), %reg2
with R_X86_64_CODE_6_GOTTPOFF, we can generate it instead of
mov name@gottpoff(%rip), %reg2
add %reg1, %reg2
gcc/
* configure.ac (HAVE_AS_R_X86_64_CODE_6_GOTTPOFF): Defined as 1
if R_X86_64_CODE_6_GOTTPOFF is supported.
* config.in: Regenerated.
* configure: Likewise.
* config/i386/predicates.md (apx_ndd_add_memory_operand): Allow
UNSPEC_GOTNTPOFF if R_X86_64_CODE_6_GOTTPOFF is supported.
gcc/testsuite/
* gcc.target/i386/apx-ndd-tls-1b.c: New test.
* lib/target-supports.exp
(check_effective_target_code_6_gottpoff_reloc): New.
---
gcc/config.in | 7 +++
gcc/config/i386/predicates.md | 6 +-
gcc/configure | 62 +++
gcc/configure.ac | 37 +++
.../gcc.target/i386/apx-ndd-tls-1b.c | 9 +++
gcc/testsuite/lib/target-supports.exp | 48 ++
6 files changed, 168 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/i386/apx-ndd-tls-1b.c
diff --git a/gcc/config.in b/gcc/config.in
index ce1d073833f..f3de4ba6776 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -737,6 +737,13 @@
#endif
+/* Define 0/1 if your assembler and linker support R_X86_64_CODE_6_GOTTPOFF.
+ */
+#ifndef USED_FOR_TARGET
+#undef HAVE_AS_R_X86_64_CODE_6_GOTTPOFF
+#endif
+
+
/* Define if your assembler supports relocs needed by -fpic. */
#ifndef USED_FOR_TARGET
#undef HAVE_AS_SMALL_PIC_RELOCS
diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index 4c1aedd7e70..391f108c360 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -2299,10 +2299,14 @@ (define_predicate "apx_ndd_memory_operand"
;; Return true if OP is a memory operand which can be used in APX NDD
;; ADD with register source operand. UNSPEC_GOTNTPOFF memory operand
-;; isn't allowed with APX NDD ADD.
+;; is allowed with APX NDD ADD only if R_X86_64_CODE_6_GOTTPOFF works.
(define_predicate "apx_ndd_add_memory_operand"
(match_operand 0 "memory_operand")
{
+ /* OK if "add %reg1, name@gottpoff(%rip), %reg2" is supported. */
+ if (HAVE_AS_R_X86_64_CODE_6_GOTTPOFF)
+return true;
+
op = XEXP (op, 0);
/* Disallow APX NDD ADD with UNSPEC_GOTNTPOFF. */
diff --git a/gcc/configure b/gcc/configure
index 41b978b0380..c59c971862c 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -29834,6 +29834,68 @@ cat >>confdefs.h <<_ACEOF
_ACEOF
+if echo "$ld_ver" | grep GNU > /dev/null; then
+ if $gcc_cv_ld -V 2>/dev/null | grep elf_x86_64_sol2 > /dev/null; then
+ld_ix86_gld_64_opt="-melf_x86_64_sol2"
+ else
+ld_ix86_gld_64_opt="-melf_x86_64"
+ fi
+fi
+conftest_s='
+ .text
+ .globl _start
+ .type _start, @function
+_start:
+ addq%r23,foo@GOTTPOFF(%rip), %r15
+ .section .tdata,"awT",@progbits
+ .type foo, @object
+foo:
+ .quad 0'
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for
R_X86_64_CODE_6_GOTTPOFF reloc" >&5
+$as_echo_n "checking assembler for R_X86_64_CODE_6_GOTTPOFF reloc... " >&6; }
+if ${gcc_cv_as_x86_64_code_6_gottpoff+:} false; then :
+ $as_echo_n "(cached) " >&6
+else
+ gcc_cv_as_x86_64_code_6_gottpoff=no
+ if test x$gcc_cv_as != x; then
+$as_echo "$conftest_s" > conftest.s
+if { ac_try='$gcc_cv_as $gcc_cv_as_flags -o conftest.o conftest.s >&5'
+ { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+ test $ac_status = 0; }; }
+then
+ if test x$gcc_cv_ld != x && test x$gcc_cv_objdump != x \
+ && test x$gcc_cv_readelf != x \
+ && $gcc_cv_readelf --relocs --wide conftest.o 2>&1 \
+ | grep R_X86_64_CODE_6_GOTTPOFF > /dev/null 2>&1 \
+ && $gcc_cv_ld $ld_ix86_gld_64_opt -o conftest conftest.o >
/dev/null 2>&1; then
+ if $gcc_cv_objdump -dw conftest 2>&1 \
+ | grep "add \+\$0xf\+8,%r23,%r15" > /dev/null 2>&1; then
+gcc_cv_as_x86_64_code_6_gottpoff=yes
+ else
+gcc_cv_as_x86_64_code_6_gottpoff=no
+ fi
+fi
+rm -f conftest
+else
+ echo "configure: failed program was" >&5
+ cat conftest.s >&5
+fi
+rm -f conftest.o conftest.s
+ fi
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result:
$gcc_cv_as_x86_64_code_6_gottpoff" >&5
+$as_echo "$gcc_cv_as_x86_64_code_6_gottpoff" >&6; }
+
+
+
+cat >>confdefs.h <<_ACEOF
+#define HAVE_AS_R_X86_64_CODE_6_GOTTPOFF `if test
x"$gcc_cv_as_x86_64_code_6_gottpoff" = xyes; then echo 1; else echo 0; fi`
+_ACEOF
+
+
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for GOTOFF in
data" >&5
$as_echo_n "checking assembler for GOTOFF in data... " >&6; }
if ${gcc_cv
Re: [PATCH] m68k: restore bootstrap
On 2/18/24 02:18, Mikael Pettersson wrote: m68k fails to bootstrap since -ffold-mem-offsets was introduced, in what looks like wrong-code during stage2. To restore bootstrap this disables -ffold-mem-offsets on m68k. It's not ideal, but better than keeping bootstraps broken until the root cause is debugged and fixed. Tested with a bootstrap and regression test run on m68k-linux-gnu. Ok for master? (I'll need help getting it committed.) gcc/ PR target/113357 * config/m68k/m68k.cc (m68k_option_override): Disable -ffold-mem-offsets. Fix typo in comment. Definitely not OK.This needs to be debugged further, just disabling the pass is not the right solution here. It is also worth noting I'm bootstrapping and regression testing the m68k weekly. jeff
[patch,avr,applied] Minor improvements to option and attribute documentation.
Applied this patch.
Johann
--
AVR: Improve documentation for -mmcu=.
gcc/
* doc/invoke.texi (AVR Options) <-mmcu>: Remove "Atmel".
Note on complete device support.
AVR: Add examples for ISR macro to interrupt attribute doc.
gcc/
* doc/extend.texi (AVR Function Attributes): Fuse description
of "signal" and "interrupt" attribute. Link pseudo instruction.
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 2b8ba1949bf..e048404dffe 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -5060,20 +5060,47 @@ without modifying an existing @option{-march=} or @option{-mcpu} option.
These function attributes are supported by the AVR back end:
@table @code
+@cindex @code{signal} function attribute, AVR
@cindex @code{interrupt} function attribute, AVR
-@item interrupt
-Use this attribute to indicate
-that the specified function is an interrupt handler. The compiler generates
+@item signal
+@itemx interrupt
+The function is an interrupt service routine (ISR). The compiler generates
function entry and exit sequences suitable for use in an interrupt handler
-when this attribute is present.
+when one of the attributes is present.
+
+The AVR hardware globally disables interrupts when an interrupt is executed.
+
+@itemize @bullet
+@item ISRs with the @code{signal} attribute do not re-enable interrupts.
+It is save to enable interrupts in a @code{signal} handler.
+This ``save'' only applies to the code
+generated by the compiler and not to the IRQ layout of the
+application which is responsibility of the application.
+
+@item ISRs with the @code{interrupt} attribute re-enable interrupts.
+The first instruction of the routine is a @code{SEI} instruction to
+globally enable interrupts.
+@end itemize
+
+The recommended way to use these attributes is by means of the
+@code{ISR} macro provided by @code{avr/interrupt.h} from
+@w{@uref{https://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html,,AVR-LibC}}:
+@example
+#include
-On the AVR, the hardware globally disables interrupts when an
-interrupt is executed. The first instruction of an interrupt handler
-declared with this attribute is a @code{SEI} instruction to
-re-enable interrupts. See also the @code{signal} function attribute
-that does not insert a @code{SEI} instruction. If both @code{signal} and
-@code{interrupt} are specified for the same function, @code{signal}
-is silently ignored.
+ISR (INT0_vect) // Uses the "signal" attribute.
+@{
+// Code
+@}
+
+ISR (ADC_vect, ISR_NOBLOCK) // Uses the "interrupt" attribute.
+@{
+// Code
+@}
+@end example
+
+When both @code{signal} and @code{interrupt} are specified for the same
+function, then @code{signal} is silently ignored.
@cindex @code{naked} function attribute, AVR
@item naked
@@ -5088,7 +5115,9 @@ depended upon to work reliably and are not supported.
@cindex @code{no_gccisr} function attribute, AVR
@item no_gccisr
-Do not use @code{__gcc_isr} pseudo instructions in a function with
+Do not use the @code{__gcc_isr}
+@uref{https://sourceware.org/binutils/docs/as/AVR-Pseudo-Instructions.html,pseudo instruction}
+in a function with
the @code{interrupt} or @code{signal} attribute aka. interrupt
service routine (ISR).
Use this attribute if the preamble of the ISR prologue should always read
@@ -5141,24 +5170,6 @@ or a frame pointer whereas @code{OS_main} and @code{OS_task} do this
as needed.
@end itemize
-@cindex @code{signal} function attribute, AVR
-@item signal
-Use this attribute on the AVR to indicate that the specified
-function is an interrupt handler. The compiler generates function
-entry and exit sequences suitable for use in an interrupt handler when this
-attribute is present.
-
-See also the @code{interrupt} function attribute.
-
-The AVR hardware globally disables interrupts when an interrupt is executed.
-Interrupt handler functions defined with the @code{signal} attribute
-do not re-enable interrupts. It is save to enable interrupts in a
-@code{signal} handler. This ``save'' only applies to the code
-generated by the compiler and not to the IRQ layout of the
-application which is responsibility of the application.
-
-If both @code{signal} and @code{interrupt} are specified for the same
-function, @code{signal} is silently ignored.
@end table
@node Blackfin Function Attributes
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index d0e67729f56..e18886e0ac7 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -23732,12 +23732,22 @@ These options are defined for AVR implementations:
@table @gcctabopt
@opindex mmcu
@item -mmcu=@var{mcu}
-Specify Atmel AVR instruction set architectures (ISA) or MCU type.
-
-The default for this option is@tie{}@samp{avr2}.
-
-GCC supports the following AVR devices and ISAs:
-
+Specify the AVR instruction set architecture (ISA) or device type.
+The default for this option is@tie{}@code{avr2}.
+
+The following AVR devices and ISAs are supported.
+@emph{Note
[PATCH] m68k: restore bootstrap
m68k fails to bootstrap since -ffold-mem-offsets was introduced, in what looks like wrong-code during stage2. To restore bootstrap this disables -ffold-mem-offsets on m68k. It's not ideal, but better than keeping bootstraps broken until the root cause is debugged and fixed. Tested with a bootstrap and regression test run on m68k-linux-gnu. Ok for master? (I'll need help getting it committed.) gcc/ PR target/113357 * config/m68k/m68k.cc (m68k_option_override): Disable -ffold-mem-offsets. Fix typo in comment. --- gcc/config/m68k/m68k.cc | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/gcc/config/m68k/m68k.cc b/gcc/config/m68k/m68k.cc index b1c9238949f..700f8151286 100644 --- a/gcc/config/m68k/m68k.cc +++ b/gcc/config/m68k/m68k.cc @@ -587,7 +587,7 @@ m68k_option_override (void) : (m68k_cpu_flags & FL_COLDFIRE) != 0 ? FPUTYPE_COLDFIRE : FPUTYPE_68881); - /* Sanity check to ensure that msep-data and mid-sahred-library are not + /* Sanity check to ensure that msep-data and mid-shared-library are not * both specified together. Doing so simply doesn't make sense. */ if (TARGET_SEP_DATA && TARGET_ID_SHARED_LIBRARY) @@ -716,6 +716,9 @@ m68k_option_override (void) else m68k_sched_mac = MAC_NO; } + + /* -ffold-mem-offsets doesn't work for m68k (PR113357). */ + flag_fold_mem_offsets = 0; } /* Implement TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE. */ -- 2.43.0
