[committed] wwwdocs: git: Update the cilkplus entry
Balaji's mail address does not work any more, and since the branch is closed anyway, we can simplify the description. --- htdocs/git.html | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/htdocs/git.html b/htdocs/git.html index 41bbe35b..50fdd56a 100644 --- a/htdocs/git.html +++ b/htdocs/git.html @@ -815,11 +815,9 @@ merged. motion and merging algorithms). It is no longer maintained. cilkplus - This branch is for the development of Cilk Plus language extension - support on GCC and G++ compilers. This branch is maintained by - mailto:balaji.v.i...@intel.com;>Balaji V. Iyer. - Patches to this branch must be prefixed with [cilkplus] wwwdocs: in - the subject. It is also highly encouraged to CC the maintainer. + This branch was for the development of Cilk Plus language extension + support on GCC and G++ compilers. It was maintained by Balaji V. Iyer. + compile-server-branch This branch was aimed at improving compile speed by caching work -- 2.29.2
Re: [committed] wwwdocs: Move cilkplus to Inactive branches
On Mon, 28 Dec 2020, Eric Gallager wrote: >> (cf. https://gcc.gnu.org/about.html and I'm happy to help). > I haven't made a commit to the wwwdocs repo yet, and the last time I > committed to the main gcc sources repo it was before the transition > to git, and I did it from a different computer, and I'm not sure if I > transferred my ssh keys to my new computer properly; I might need some > help with the setup there... it might be faster to just commit the > changes yourself. I'd encourage you to give it a try - working on wwwdocs in the git world is quite easy and convenient (and git in general has been a good move for GCC). :-) Reach out if you need help; for now I'll take care of this change. Gerald
[r11-6752 Regression] FAIL: gfortran.dg/gomp/task-detach-1.f90 -O (test for errors, line 22) on Linux/x86_64
On Linux/x86_64,
a6d22fb21c6f1ad7e8b6b722bfc0e7e11f50cb92 is the first bad commit
commit a6d22fb21c6f1ad7e8b6b722bfc0e7e11f50cb92
Author: Kwok Cheung Yeung
Date: Sat Jan 16 12:58:13 2021 -0800
openmp: Add support for the OpenMP 5.0 task detach clause
caused
FAIL: gfortran.dg/gomp/task-detach-1.f90 -O (test for errors, line 21)
FAIL: gfortran.dg/gomp/task-detach-1.f90 -O (test for errors, line 22)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-6752/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="gomp.exp=gfortran.dg/gomp/task-detach-1.f90
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="gomp.exp=gfortran.dg/gomp/task-detach-1.f90
--target_board='unix{-m32\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
Re: [PATCH] keep scope blocks for all inlined functions (PR 98664)
On 1/15/21 12:44 AM, Richard Biener wrote:
On Thu, Jan 14, 2021 at 8:13 PM Martin Sebor via Gcc-patches
wrote:
One aspect of PR 98465 - Bogus warning stringop-overread for std::string
is the inconsistency between -g and -g0 which turns out to be due to
GCC eliminating apparently unused scope blocks from inlined functions
that aren't explicitly declared inline and artificial. PR 98664 tracks
just this part of PR 98465.
To resolve just the PR 98664 subset the attached change has
the tree-ssa-live.c pass preserve these blocks for all inlined
functions, not just artificial ones. Besides avoiding the interaction
between -g and warnings it also seems to improve the inlining context
by including more inlined call sites. This can be seen in the adjusted
tests. (Its effect on PR 98465 is that the false positive is issued
consistently, regardless of -g. Avoiding the false positive is my
next step.)
Jakub, you raised a concern yesterday in PR 98465 c#13 about the memory
footprint of this change. Can you please comment on whether it's in
line with what you were suggesting?
{
tree ao = BLOCK_ABSTRACT_ORIGIN (block);
- if (TREE_CODE (ao) == FUNCTION_DECL)
- loc = BLOCK_SOURCE_LOCATION (block);
- else if (TREE_CODE (ao) != BLOCK)
- break;
+ if (TREE_CODE (ao) == FUNCTION_DECL)
+loc = BLOCK_SOURCE_LOCATION (block);
+ else if (TREE_CODE (ao) != BLOCK)
+break;
you are replacing tabs with spaces?
@@ -558,16 +558,13 @@ remove_unused_scope_block_p (tree scope, bool
in_ctor_dtor_block)
else if (!flag_auto_profile && debug_info_level == DINFO_LEVEL_NONE
&& !optinfo_wants_inlining_info_p ())
{
- /* Even for -g0 don't prune outer scopes from artificial
- functions, otherwise diagnostics using tree_nonartificial_location
- will not be emitted properly. */
+ /* Even for -g0 don't prune outer scopes from inlined functions,
+ otherwise late diagnostics from such functions will not be
+ emitted or suppressed properly. */
if (inlined_function_outer_scope_p (scope))
{
tree ao = BLOCK_ORIGIN (scope);
- if (ao
- && TREE_CODE (ao) == FUNCTION_DECL
- && DECL_DECLARED_INLINE_P (ao)
- && lookup_attribute ("artificial", DECL_ATTRIBUTES (ao)))
+ if (ao && TREE_CODE (ao) == FUNCTION_DECL)
unused = false;
}
}
so which inlined_function_outer_scope_p are you _not_ marking now?
BLOCK_ORIGIN is never NULL and all inlined scopes should have
an abstract origin - I believe always a FUNCTIN_DECL. Which means
you could have simplified it further?
Quite possibly. I could find no documentation for these macros so
I tried to keep my changes conservative. I did put together some
notes to document what I saw the macros evaluate to in my testing
(below). If/when it's close to accurate I'd like to add them to
tree.h and to the internals manual.
And yes, the main reason for the code above is memory use for
C++ with lots of inlining. I suggest to try the patch on tramp3d
for example (there's about 10 inline instances per emitted
assembly op).
This one:
https://github.com/llvm-mirror/test-suite/tree/master/MultiSource/Benchmarks/tramp3d-v4
?
With the patch, 69,022 more blocks with distinct numbers are kept
than without it. I see some small differences in -fmem-report
and -ftime-report output:
Total: 286 -> 288M 210 -> 211M 3993 -> 4019k
I'm not really sure what to look at so I attach the two reports
for you to judge for yourself.
I also attach an updated patch with the slight simplification you
suggested.
Martin
PS Here are my notes on the macros and the two related functions:
BLOCK: Denotes a lexical scope. Contains BLOCK_VARS of variables
declared in it, BLOCK_SUBBLOCKS of scopes nested in it, and
BLOCK_CHAIN pointing to the next BLOCK. Its BLOCK_SUPERCONTEXT
point to the BLOCK of the enclosing scope. May have
a BLOCK_ABSTRACT_ORIGIN and a BLOCK_SOURCE_LOCATION.
BLOCK_SUPERCONTEXT: The scope of the enclosing block, or FUNCTION_DECL
for the "outermost" function scope. Inlined functions are chained by
this so that given expression E and its TREE_BLOCK(E) B,
BLOCK_SUPERCONTEXT(B) is the scope (BLOCK) in which E has been made
or into which E has been inlined. In the latter case,
BLOCK_ORIGIN(B) evaluates either to the enclosing BLOCK or to
the enclosing function DECL. It's never null.
BLOCK_ABSTRACT_ORIGIN(B) is the FUNCTION_DECL of the function into
which it has been inlined, or null if B is not inlined.
BLOCK_ABSTRACT_ORIGIN: A BLOCK, or FUNCTION_DECL of the function
into which a block has been inlined. In a BLOCK immediately enclosing
an inlined leaf expression points to the outermost BLOCK into which it
has been inlined (thus bypassing all intermediate BLOCK_SUPERCONTEXTs).
BLOCK_FRAGMENT_ORIGIN: ???
BLOCK_FRAGMENT_CHAIN: ???
bool
Re: [PATCH] [WIP] openmp: Add OpenMP 5.0 task detach clause support
On Sat, Jan 16, 2021 at 07:19:51PM +, Kwok Cheung Yeung wrote:
> > I think you don't need this loop, instead you could just check
> > if (bitmap_bit_p (_head, DECL_UID (detach_decl))
> > || bitmap_bit_p (_head, DECL_UID (detach_decl))
> > || bitmap_bit_p (_head, DECL_UID (detach_decl)))
> >
>
> I think the main problem with this is that you cannot then point to the
> location of the offending data-sharing clause. Given a task construct with
> 'detach(x) shared(x)', I would tend to think of the 'shared(x)' as being the
> incorrect part here, and so would want the error to point to it. Unless you
> have any objections, I am inclined to keep this as it is?
Ok. As detach clause is at most one, the loop is acceptable, but we
certainly would want to avoid O(n^2) complexities in number of clauses.
> I've tried this diff:
>
> case OMP_CLAUSE_DETACH:
> - decl = OMP_CLAUSE_DECL (c);
> - goto do_notice;
> + flags = GOVD_FIRSTPRIVATE | GOVD_SEEN;
> + goto do_add;
>
> and just asserted that a suitable firstprivate clause is found in
> finish_taskreg_scan, and it seems to work fine :-).
Yeah, that should DTRT.
>
> > > + #pragma omp task detach (x) detach (y) /* { dg-error "there can be at
> > > most one 'detach' clause in a task construct" } */
> >
> > It would be on a task construct rather than in a task construct, but the
> > common wording for this diagnostics is
> > "too many %qs clauses", "detach"
> > Please use that wording.
>
> Done, though I don't see the point of using a %qs format code with a
> constant string here...
Helping translators.
They already have the "too many %qs clauses" string to translate (and many
have translated it already), the detach word shouldn't be translated, and we
don't want them to translate
"too many % clauses"
"too many % clauses"
"too many % clauses"
...
>
> I have applied your other suggestions, and have retested the gomp.exp and
> libgomp tests. The full testrun started yesterday showed no regressions. If
> you have no further issues then I will commit this later tonight ahead of
> stage4.
LGTM, thanks.
Jakub
Re: [PATCH] [WIP] openmp: Add OpenMP 5.0 task detach clause support
Thanks for the review.
On 16/01/2021 9:25 am, Jakub Jelinek wrote:
On Fri, Jan 15, 2021 at 03:07:56PM +, Kwok Cheung Yeung wrote:
+ {
+ tree detach_decl = OMP_CLAUSE_DECL (*detach_seen);
+
+ for (pc = , c = clauses; c ; c = *pc)
+ {
+ bool remove = false;
+ if ((OMP_CLAUSE_CODE (c) == OMP_CLAUSE_SHARED
+ || OMP_CLAUSE_CODE (c) == OMP_CLAUSE_PRIVATE
+ || OMP_CLAUSE_CODE (c) == OMP_CLAUSE_FIRSTPRIVATE
+ || OMP_CLAUSE_CODE (c) == OMP_CLAUSE_LASTPRIVATE)
+ && OMP_CLAUSE_DECL (c) == detach_decl)
+ {
+ error_at (OMP_CLAUSE_LOCATION (c),
+ "the event handle of a % clause "
+ "should not be in a data-sharing clause");
+ remove = true;
+ }
I think you don't need this loop, instead you could just check
if (bitmap_bit_p (_head, DECL_UID (detach_decl))
|| bitmap_bit_p (_head, DECL_UID (detach_decl))
|| bitmap_bit_p (_head, DECL_UID (detach_decl)))
I think the main problem with this is that you cannot then point to the location
of the offending data-sharing clause. Given a task construct with 'detach(x)
shared(x)', I would tend to think of the 'shared(x)' as being the incorrect part
here, and so would want the error to point to it. Unless you have any
objections, I am inclined to keep this as it is?
@@ -2416,6 +2421,64 @@ finish_taskreg_scan (omp_context *ctx)
TYPE_FIELDS (ctx->srecord_type) = f1;
}
}
+ if (detach_clause)
+ {
+ tree c, field;
+
+ /* Look for a firstprivate clause with the detach event handle. */
+ for (c = gimple_omp_taskreg_clauses (ctx->stmt);
+ c; c = OMP_CLAUSE_CHAIN (c))
+ {
+ if (OMP_CLAUSE_CODE (c) != OMP_CLAUSE_FIRSTPRIVATE)
+ continue;
+ if (maybe_lookup_decl_in_outer_ctx (OMP_CLAUSE_DECL (c), ctx)
+ == OMP_CLAUSE_DECL (detach_clause))
+ break;
+ }
+
+ if (c)
+ field = lookup_field (OMP_CLAUSE_DECL (c), ctx);
+ else
+ {
+ /* The detach event handle is not referenced within the
+task context, so add a temporary field for it here. */
+ field = build_decl (OMP_CLAUSE_LOCATION (detach_clause),
+ FIELD_DECL, NULL_TREE, ptr_type_node);
+ insert_field_into_struct (ctx->record_type, field);
Can't you just force the firstprivate clause during gimplification, so that
it doesn't go away even if not referenced?
That would mean just forcing in | GOVD_SEEN when it is added.
If not, not a big deal, just thought it could be easier.
I've tried this diff:
case OMP_CLAUSE_DETACH:
- decl = OMP_CLAUSE_DECL (c);
- goto do_notice;
+ flags = GOVD_FIRSTPRIVATE | GOVD_SEEN;
+ goto do_add;
and just asserted that a suitable firstprivate clause is found in
finish_taskreg_scan, and it seems to work fine :-).
+ #pragma omp task detach (x) detach (y) /* { dg-error "there can be at most one
'detach' clause in a task construct" } */
It would be on a task construct rather than in a task construct, but the
common wording for this diagnostics is
"too many %qs clauses", "detach"
Please use that wording.
Done, though I don't see the point of using a %qs format code with a constant
string here...
I have applied your other suggestions, and have retested the gomp.exp and
libgomp tests. The full testrun started yesterday showed no regressions. If you
have no further issues then I will commit this later tonight ahead of stage4.
Thanks
Kwok
commit 68f17e5d3f28b4150fc0fa9112671403c4519c05
Author: Kwok Cheung Yeung
Date: Sat Jan 16 09:27:28 2021 -0800
More task detach fixes.
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 4e9b21b..b938e6a 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -14942,8 +14942,7 @@ c_finish_omp_clauses (tree clauses, enum
c_omp_region_type ort)
if (detach_seen)
{
error_at (OMP_CLAUSE_LOCATION (c),
- "there can be at most one % clause in a "
- "task construct");
+ "too many % clauses on a task construct");
remove = true;
break;
}
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 9dfaea2..c28cde0 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -7425,8 +7425,7 @@ finish_omp_clauses (tree clauses, enum c_omp_region_type
ort)
if (detach_seen)
{
error_at (OMP_CLAUSE_LOCATION (c),
- "there can be at most one % clause in a "
- "task construct");
+ "too many % clauses on a task
[PATCH] match.pd: Add some __builtin_ctz (x) cmp cst simplifications [PR95527]
Hi!
This patch adds some ctz simplifications (e.g. ctz (x) >= 3 can be done by
testing if the low 3 bits are zero, etc.).
In addition, I've noticed that in the CLZ case, the
#ifdef CLZ_DEFINED_VALUE_AT_ZERO don't really work as intended, they
are evaluated during genmatch and the macro is not defined then
(but, because of the missing tm.h includes it isn't defined in
gimple-match.c or generic-match.c either). And when tm.h is included,
defaults.h is included which defines a fallback version of that macro.
For GCC 12, I wonder if it wouldn't be better to say in addition to
__builtin_c[lt]z*
is always UB at zero that it would be undefined for .C[LT]Z ifn too if it
has just one operand and use a second operand to be the constant we expect
at zero.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2021-01-16 Jakub Jelinek
PR tree-optimization/95527
* generic-match-head.c: Include tm.h.
* gimple-match-head.c: Include tm.h.
* match.pd (CLZ == INTEGER_CST): Don't use
#ifdef CLZ_DEFINED_VALUE_AT_ZERO, only test CLZ_DEFINED_VALUE_AT_ZERO
if clz == CFN_CLZ. Add missing val declaration.
(CTZ cmp CST): New simplifications.
* gcc.dg/tree-ssa/pr95527-2.c: New test.
--- gcc/generic-match-head.c.jj 2021-01-04 10:25:39.146230280 +0100
+++ gcc/generic-match-head.c2021-01-16 13:12:51.783210820 +0100
@@ -37,6 +37,7 @@ along with GCC; see the file COPYING3.
#include "gimplify.h"
#include "optabs-tree.h"
#include "dbgcnt.h"
+#include "tm.h"
/* Routine to determine if the types T1 and T2 are effectively
the same for GENERIC. If T1 or T2 is not a type, the test
--- gcc/gimple-match-head.c.jj 2021-01-04 10:25:39.764223282 +0100
+++ gcc/gimple-match-head.c 2021-01-16 13:13:11.675984551 +0100
@@ -43,6 +43,7 @@ along with GCC; see the file COPYING3.
#include "optabs-tree.h"
#include "tree-eh.h"
#include "dbgcnt.h"
+#include "tm.h"
/* Forward declarations of the private auto-generated matchers.
They expect valueized operands in canonical order and do not
--- gcc/match.pd.jj 2021-01-16 09:21:36.586239939 +0100
+++ gcc/match.pd2021-01-16 14:47:03.265769066 +0100
@@ -6307,30 +6307,97 @@ (define_operator_list COND_TERNARY
(op (clz:s @0) INTEGER_CST@1)
(if (integer_zerop (@1))
/* clz(X) == 0 is (int)X < 0 and clz(X) != 0 is (int)X >= 0. */
-(with { tree stype = signed_type_for (TREE_TYPE (@0));
+(with { tree type0 = TREE_TYPE (@0);
+ tree stype = signed_type_for (type0);
HOST_WIDE_INT val = 0;
-#ifdef CLZ_DEFINED_VALUE_AT_ZERO
/* Punt on hypothetical weird targets. */
- if (CLZ_DEFINED_VALUE_AT_ZERO (TYPE_MODE (TREE_TYPE (@0)),
- val) == 2
+ if (clz == CFN_CLZ
+ && CLZ_DEFINED_VALUE_AT_ZERO (SCALAR_TYPE_MODE (type0),
+ val) == 2
&& val == 0)
stype = NULL_TREE;
-#endif
}
(if (stype)
(cmp (convert:stype @0) { build_zero_cst (stype); })))
/* clz(X) == (prec-1) is X == 1 and clz(X) != (prec-1) is X != 1. */
(with { bool ok = true;
-#ifdef CLZ_DEFINED_VALUE_AT_ZERO
+ HOST_WIDE_INT val = 0;
+ tree type0 = TREE_TYPE (@0);
/* Punt on hypothetical weird targets. */
- if (CLZ_DEFINED_VALUE_AT_ZERO (TYPE_MODE (TREE_TYPE (@0)),
- val) == 2
- && val == TYPE_PRECISION (TREE_TYPE (@0)) - 1)
+ if (clz == CFN_CLZ
+ && CLZ_DEFINED_VALUE_AT_ZERO (SCALAR_TYPE_MODE (type0),
+ val) == 2
+ && val == TYPE_PRECISION (type0) - 1)
ok = false;
-#endif
}
- (if (ok && wi::to_wide (@1) == (TYPE_PRECISION (TREE_TYPE (@0)) - 1))
- (op @0 { build_one_cst (TREE_TYPE (@0)); })))
+ (if (ok && wi::to_wide (@1) == (TYPE_PRECISION (type0) - 1))
+ (op @0 { build_one_cst (type0); })))
+
+/* CTZ simplifications. */
+(for ctz (CTZ)
+ (for op (ge gt le lt)
+ cmp (eq eq ne ne)
+ (simplify
+ /* __builtin_ctz (x) >= C -> (x & ((1 << C) - 1)) == 0. */
+ (op (ctz:s @0) INTEGER_CST@1)
+(with { bool ok = true;
+ HOST_WIDE_INT val = 0;
+ if (!tree_fits_shwi_p (@1))
+ ok = false;
+ else
+ {
+ val = tree_to_shwi (@1);
+ /* Canonicalize to >= or <. */
+ if (op == GT_EXPR || op == LE_EXPR)
+ {
+ if (val == HOST_WIDE_INT_MAX)
+ ok = false;
+ else
+ val++;
+ }
+ }
+ bool zero_res = false;
+ HOST_WIDE_INT zero_val = 0;
+ tree type0 = TREE_TYPE (@0);
+ int prec = TYPE_PRECISION (type0);
+ if (ctz == CFN_CTZ
+
[PATCH] expand: Expand x / y * y as x - x % y if the latter is cheaper [PR96696]
Hi!
The following patch tests both x / y * y and x - x % y expansion for the
former GIMPLE code and chooses the cheaper of those sequences.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2021-01-16 Jakub Jelinek
PR tree-optimization/96696
* expr.c (expand_expr_divmod): New function.
(expand_expr_real_2) : Use it for truncations and
divisions. Formatting fixes.
: Optimize x / y * y as x - x % y if the latter is
cheaper.
* gcc.target/i386/pr96696.c: New test.
--- gcc/expr.c.jj 2021-01-15 19:04:31.293570459 +0100
+++ gcc/expr.c 2021-01-16 11:56:58.658781143 +0100
@@ -8655,6 +8655,56 @@ expand_misaligned_mem_ref (rtx temp, mac
return temp;
}
+/* Helper function of expand_expr_2, expand a division or modulo.
+ op0 and op1 should be already expanded treeop0 and treeop1, using
+ expand_operands. */
+
+static rtx
+expand_expr_divmod (tree_code code, machine_mode mode, tree treeop0,
+ tree treeop1, rtx op0, rtx op1, rtx target, int unsignedp)
+{
+ bool mod_p = (code == TRUNC_MOD_EXPR || code == FLOOR_MOD_EXPR
+ || code == CEIL_MOD_EXPR || code == ROUND_MOD_EXPR);
+ if (SCALAR_INT_MODE_P (mode)
+ && optimize >= 2
+ && get_range_pos_neg (treeop0) == 1
+ && get_range_pos_neg (treeop1) == 1)
+{
+ /* If both arguments are known to be positive when interpreted
+as signed, we can expand it as both signed and unsigned
+division or modulo. Choose the cheaper sequence in that case. */
+ bool speed_p = optimize_insn_for_speed_p ();
+ do_pending_stack_adjust ();
+ start_sequence ();
+ rtx uns_ret = expand_divmod (mod_p, code, mode, op0, op1, target, 1);
+ rtx_insn *uns_insns = get_insns ();
+ end_sequence ();
+ start_sequence ();
+ rtx sgn_ret = expand_divmod (mod_p, code, mode, op0, op1, target, 0);
+ rtx_insn *sgn_insns = get_insns ();
+ end_sequence ();
+ unsigned uns_cost = seq_cost (uns_insns, speed_p);
+ unsigned sgn_cost = seq_cost (sgn_insns, speed_p);
+
+ /* If costs are the same then use as tie breaker the other other
+factor. */
+ if (uns_cost == sgn_cost)
+ {
+ uns_cost = seq_cost (uns_insns, !speed_p);
+ sgn_cost = seq_cost (sgn_insns, !speed_p);
+ }
+
+ if (uns_cost < sgn_cost || (uns_cost == sgn_cost && unsignedp))
+ {
+ emit_insn (uns_insns);
+ return uns_ret;
+ }
+ emit_insn (sgn_insns);
+ return sgn_ret;
+}
+ return expand_divmod (mod_p, code, mode, op0, op1, target, unsignedp);
+}
+
rtx
expand_expr_real_2 (sepops ops, rtx target, machine_mode tmode,
enum expand_modifier modifier)
@@ -9192,14 +9242,78 @@ expand_expr_real_2 (sepops ops, rtx targ
if (!REG_P (op0))
op0 = copy_to_mode_reg (mode, op0);
- return REDUCE_BIT_FIELD (gen_rtx_MULT (mode, op0,
- gen_int_mode (tree_to_shwi (exp1),
-TYPE_MODE (TREE_TYPE (exp1);
+ op1 = gen_int_mode (tree_to_shwi (exp1),
+ TYPE_MODE (TREE_TYPE (exp1)));
+ return REDUCE_BIT_FIELD (gen_rtx_MULT (mode, op0, op1));
}
if (modifier == EXPAND_STACK_PARM)
target = 0;
+ if (SCALAR_INT_MODE_P (mode) && optimize >= 2)
+ {
+ gimple *def_stmt0 = get_def_for_expr (treeop0, TRUNC_DIV_EXPR);
+ gimple *def_stmt1 = get_def_for_expr (treeop1, TRUNC_DIV_EXPR);
+ if (def_stmt0
+ && !operand_equal_p (treeop1, gimple_assign_rhs2 (def_stmt0), 0))
+ def_stmt0 = NULL;
+ if (def_stmt1
+ && !operand_equal_p (treeop0, gimple_assign_rhs2 (def_stmt1), 0))
+ def_stmt1 = NULL;
+
+ if (def_stmt0 || def_stmt1)
+ {
+ /* X / Y * Y can be expanded as X - X % Y too.
+Choose the cheaper sequence of those two. */
+ if (def_stmt0)
+ treeop0 = gimple_assign_rhs1 (def_stmt0);
+ else
+ {
+ treeop1 = treeop0;
+ treeop0 = gimple_assign_rhs1 (def_stmt1);
+ }
+ expand_operands (treeop0, treeop1, subtarget, , ,
+ EXPAND_NORMAL);
+ bool speed_p = optimize_insn_for_speed_p ();
+ do_pending_stack_adjust ();
+ start_sequence ();
+ rtx divmul_ret
+ = expand_expr_divmod (TRUNC_DIV_EXPR, mode, treeop0, treeop1,
+ op0, op1, NULL_RTX, unsignedp);
+ divmul_ret = expand_mult (mode, divmul_ret, op1, target,
+ unsignedp);
+ rtx_insn *divmul_insns = get_insns ();
+ end_sequence ();
+ start_sequence ();
+ rtx modsub_ret
+ =
Re: [PATCH v3] libgcc: Thumb-1 Floating-Point Library for Cortex M0
Hi Christophe, On Fri, Jan 15, 2021, at 4:30 AM, Christophe Lyon wrote: > On Fri, 15 Jan 2021 at 12:39, Daniel Engel wrote: > > > > Hi Christophe, > > > > On Mon, Jan 11, 2021, at 8:39 AM, Christophe Lyon wrote: > > > On Mon, 11 Jan 2021 at 17:18, Daniel Engel wrote: > > > > > > > > On Mon, Jan 11, 2021, at 8:07 AM, Christophe Lyon wrote: > > > > > On Sat, 9 Jan 2021 at 14:09, Christophe Lyon > > > > > wrote: > > > > > > > > > > > > On Sat, 9 Jan 2021 at 13:27, Daniel Engel > > > > > > wrote: > > > > > > > > > > > > > > On Thu, Jan 7, 2021, at 4:56 AM, Richard Earnshaw wrote: > > > > > > > > On 07/01/2021 00:59, Daniel Engel wrote: > > > > > > > > > --snip-- > > > > > > > > > > > > > > > > > > On Wed, Jan 6, 2021, at 9:05 AM, Richard Earnshaw wrote: > > > > > > > > > --snip-- > > > > > > > > > > > > > > > > > >> - finally, your popcount implementations have data in the > > > > > > > > >> code segment. > > > > > > > > >> That's going to cause problems when we have compilation > > > > > > > > >> options such as > > > > > > > > >> -mpure-code. > > > > > > > > > > > > > > > > > > I am just following the precedent of existing lib1funcs (e.g. > > > > > > > > > __clz2si). > > > > > > > > > If this matters, you'll need to point in the right direction > > > > > > > > > for the > > > > > > > > > fix. I'm not sure it does matter, since these functions are > > > > > > > > > PIC anyway. > > > > > > > > > > > > > > > > That might be a bug in the clz implementations - Christophe: > > > > > > > > Any thoughts? > > > > > > > > > > > > > > __clzsi2() has test coverage in > > > > > > > "gcc.c-torture/execute/builtin-bitops-1.c" > > > > > > Thanks, I'll have a closer look at why I didn't see problems. > > > > > > > > > > > > > > > > So, that's because the code goes to the .text section (as opposed to > > > > > .text.noread) > > > > > and does not have the PURECODE flag. The compiler takes care of this > > > > > when generating code with -mpure-code. > > > > > And the simulator does not complain because it only checks loads from > > > > > the segment with the PURECODE flag set. > > > > > > > > > This is far out of my depth, but can something like: > > > > > > > > ifeq (,$(findstring __symbian__,$(shell $(gcc_compile_bare) -dM -E - > > > > > > > > > > > be adapted to: > > > > > > > > a) detect the state of the -mpure-code switch, and > > > > b) pass that flag to the preprocessor? > > > > > > > > If so, I can probably fix both the target section and the data usage. > > > > Just have to add a few instructions to finish unrolling the loop. > > > > > > I must confess I never checked libgcc's Makefile deeply before, > > > but it looks like you can probably detect whether -mpure-code is > > > part of $CFLAGS. > > > > > > However, it might be better to write pure-code-safe code > > > unconditionally because the toolchain will probably not > > > be rebuilt with -mpure-code as discussed before. > > > Or that could mean adding a -mpure-code multilib > > > > I have learned a few things since the last update. I think I know how > > to get -mpure-code out of CFLAGS and into a macro. However, I have hit > > something of a wall with testing. I can't seem to compile any flavor of > > libgcc with CFLAGS_FOR_TARGET="-mpure-code". > > > > 1. Configuring --with-multilib-list=rmprofile results in build failure: > > > > checking for suffix of object files... configure: error: in > > `/home/mirdan/gcc-obj/arm-none-eabi/libgcc': > > configure: error: cannot compute suffix of object files: cannot compile > > See `config.log' for more details > > > >cc1: error: -mpure-code only supports non-pic code on M-profile targets > > > > Yes, I did hit that wall too :-) > > Hence what we discussed earlier: the toolchain is not rebuilt with > -mpure-code. > > Note that there are problems in newlib too, but users of -mpure-code seem > to be able to work around that (eg. using their own startup code and no > stdlib) Is there a current side project to solve the makefile problems? I think I'm back to my original question: If libgcc can't be built with -mpure-code, and users bypass it completely with -nostdlib, then why this conversation about pure-code compatibility of __clzsi2() etc? > > 2. Attempting to filter the multib list results in configuration error. > > This might have been misguided, but it was something I tried: > > > > Error: --with-multilib-list=armv6s-m not supported. > > > > Error: --with-multilib-list=mthumb/march=armv6s-m/mfloat-abi=soft not > > supported > > I think only 2 values are supported: aprofile and rmprofile. It looks like this might require a custom t-* multilib in gcc/config/arm. > > 3. Attempting to configure a single architecture results in a build error. > > > > --with-mode=thumb --with-arch=armv6s-m --with-float=soft > > > > checking for suffix of object files... configure: error: in > > `/home/mirdan/gcc-obj/arm-none-eabi/arm/autofp/v5te/fpu/libgcc': > >
Re: [committed][OG10] Fix offload dwarf info
On 15/01/2021 11:43, Andrew Stubbs wrote:
This patch corrects a problem in which GDB ignores the debug info for
offload kernel entry functions because they're represented as nested
functions inside a function that does not exist on the accelerator
device (only on the host).
Apparently I had a bug in this patch that only showed up after another
clean build (not sure what was different).
This patch fixes it. Apparently the flag_generate_offload was wrong.
Committed to OG10. I will squash the two patches when they go to mainline.
Andrew
Correct fix offload dwarf info
The previous patch wasn't quite right, apparently. Somehow the behaviour
changed after another clean build? This tweak fixes it.
This patch should be squashed with fdcb23540a2 to go to mainline.
gcc/ChangeLog:
* dwarf2out.c (gen_subprogram_die): Check offload attributes only.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index dedfeaf865f..61d8a3f574c 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -23094,9 +23094,8 @@ gen_subprogram_die (tree decl, dw_die_ref context_die)
will ignore the function and everything nested within unless
we give it a notional code range (the values aren't
important, as long as they are valid). */
- if (flag_generate_offload
- && lookup_attribute ("omp target entrypoint",
- DECL_ATTRIBUTES (decl))
+ if (lookup_attribute ("omp target entrypoint",
+ DECL_ATTRIBUTES (decl))
&& subr_die->die_parent
&& subr_die->die_parent->die_tag == DW_TAG_subprogram
&& !get_AT_low_pc (subr_die->die_parent))
Re: [PATCH v2 3/3] RTEMS: Add -mcustom-fpu-cfg=fph2 multilib
On 1/16/21 1:23 AM, Sebastian Huber wrote: This multilib supports Nios II configurations with the "Nios II Floating Point Hardware 2 Component". gcc/ * config/nios2/t-rtems: Reset all MULTILIB_* variables. Shorten multilib directory names. Use MULTILIB_REQUIRED instead of MULTILIB_EXCEPTIONS. Add -mhw-mul -mhw-mulx -mhw-div -mcustom-fpu-cfg=fph2 multilib. OK. -Sandra
Re: [PATCH v2 2/3] nios2: Add -mcustom-fpu-cfg=fph2
On 1/16/21 1:23 AM, Sebastian Huber wrote: The new -mcustom-fpu-cfg=fph2 option variant is useful to build a multilib for the "Nios II Floating Point Hardware 2 Component": https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_nios2_custom_instruction.pdf Directly using the corresponding -mcustom-insn=N options for this floating-point unit leads to a combinatorial explosion in the potential count of multilibs which may break the build. gcc/ * config/nios2/nios2.c (NIOS2_FPU_CONFIG_NUM): Adjust value. (nios2_init_fpu_configs): Provide register values for new -mcustom-fpu-cfg=fph2 option variant. * doc/invoke.texi (-mcustom-fpu-cfg=fph2): Document new option variant. OK. -Sandra
Re: [PATCH v2 1/3] nios2: Remove custom instruction warnings
On 1/16/21 1:23 AM, Sebastian Huber wrote: Do not warn if custom instructions are not used due to missing optimization flags. This prevents build errors with -Werror which cannot be disabled via a dedicated warning option. One reason to remove these warnings is to enable a multilib for the "Nios II Floating Point Hardware 2 Component". For example, the libatomic target library in GCC is built with -Werror and the warnings removed by this patch resulted in errors like: cc1: error: switch '-mcustom-fmins' has no effect unless '-ffinite-math-only' is specified [-Werror] cc1: error: switch '-mcustom-fmaxs' has no effect unless '-ffinite-math-only' is specified [-Werror] cc1: error: switch '-mcustom-round' has no effect unless '-fno-math-errno' is specified [-Werror] gcc/ * config/nios2/nios2.c (nios2_custom_check_insns): Remove custom instruction warnings. OK. -Sandra
Re: [PATCH, v2, OpenMP 5.0, libgomp] Structure element mapping for OpenMP 5.0
On Fri, Dec 04, 2020 at 10:15:46PM +0800, Chung-Lin Tang wrote: > this is a new version of the structure element mapping patch for OpenMP 5.0 > requirement > changes. Sorry for the delay. > +/* Unified reference count for structure element siblings, this is used > + when REFCOUNT_STRUCTELEM_FIRST_P(k->refcount) == true, the first > sibling > + in a structure element sibling list item sequence. */ > +uintptr_t structelem_refcount; > + > +/* When REFCOUNT_STRUCTELEM_P (k->refcount) == true, this field points REFCOUNT_STRUCTELEM_P (k->refcount) is true even for REFCOUNT_STRUCTELEM_FIRST_P(k->refcount), so shouldn't the description say that structelem_refcount_ptr is only used if REFCOUNT_STRUCTELEM_P (k->refcount) && !REFCOUNT_STRUCTELEM_FIRST_P (k->refcount) ? > + into the (above) structelem_refcount field of the _FIRST > splay_tree_key, > + the first key in the created sequence. All structure element siblings > + share a single refcount in this manner. Since these two fields won't > be > + used at the same time, they are stashed in a union. */ > +uintptr_t *structelem_refcount_ptr; > + }; >struct splay_tree_aux *aux; > }; > > /* The comparison function. */ Anyway, most of the patch looks good, but I'd like to understand the rationale for choosing a htab over what I've been trying to suggest, which was essentially instead of incrementing or decrementing refcounts push them into a vector for later incrementing/decrementing, then qsort the vector (by the pointers to refcounts) and increment what the elements point to unless the same address has been incremented/decremented already. Jakub
Re: [PATCH] [WIP] openmp: Add OpenMP 5.0 task detach clause support
On Fri, Jan 15, 2021 at 03:07:56PM +, Kwok Cheung Yeung wrote:
> + {
> + tree detach_decl = OMP_CLAUSE_DECL (*detach_seen);
> +
> + for (pc = , c = clauses; c ; c = *pc)
> + {
> + bool remove = false;
> + if ((OMP_CLAUSE_CODE (c) == OMP_CLAUSE_SHARED
> +|| OMP_CLAUSE_CODE (c) == OMP_CLAUSE_PRIVATE
> +|| OMP_CLAUSE_CODE (c) == OMP_CLAUSE_FIRSTPRIVATE
> +|| OMP_CLAUSE_CODE (c) == OMP_CLAUSE_LASTPRIVATE)
> + && OMP_CLAUSE_DECL (c) == detach_decl)
> + {
> + error_at (OMP_CLAUSE_LOCATION (c),
> + "the event handle of a % clause "
> + "should not be in a data-sharing clause");
> + remove = true;
> + }
I think you don't need this loop, instead you could just check
if (bitmap_bit_p (_head, DECL_UID (detach_decl))
|| bitmap_bit_p (_head, DECL_UID (detach_decl))
|| bitmap_bit_p (_head, DECL_UID (detach_decl)))
> + || TREE_CODE (type) != ENUMERAL_TYPE
|| DECL_NAME (TYPE_NAME (type))
!= get_identifier ("omp_event_handle_t")))
The formatting is off, and I think as a service to Emacs users we are
usually formatting it as:
|| (DECL_NAME (TYPE_NAME (type))
!= get_identifier ("omp_event_handle_t"
> +
> + detach = detach
> +? build_fold_addr_expr (OMP_CLAUSE_DECL (detach))
> +: null_pointer_node;
Again formatting nit, please write:
detach = (detach
? build_fold_addr_expr (OMP_CLAUSE_DECL (detach))
: null_pointer_node);
> @@ -2416,6 +2421,64 @@ finish_taskreg_scan (omp_context *ctx)
> TYPE_FIELDS (ctx->srecord_type) = f1;
> }
> }
> + if (detach_clause)
> + {
> + tree c, field;
> +
> + /* Look for a firstprivate clause with the detach event handle. */
> + for (c = gimple_omp_taskreg_clauses (ctx->stmt);
> +c; c = OMP_CLAUSE_CHAIN (c))
> + {
> + if (OMP_CLAUSE_CODE (c) != OMP_CLAUSE_FIRSTPRIVATE)
> + continue;
> + if (maybe_lookup_decl_in_outer_ctx (OMP_CLAUSE_DECL (c), ctx)
> + == OMP_CLAUSE_DECL (detach_clause))
> + break;
> + }
> +
> + if (c)
> + field = lookup_field (OMP_CLAUSE_DECL (c), ctx);
> + else
> + {
> + /* The detach event handle is not referenced within the
> + task context, so add a temporary field for it here. */
> + field = build_decl (OMP_CLAUSE_LOCATION (detach_clause),
> + FIELD_DECL, NULL_TREE, ptr_type_node);
> + insert_field_into_struct (ctx->record_type, field);
Can't you just force the firstprivate clause during gimplification, so that
it doesn't go away even if not referenced?
That would mean just forcing in | GOVD_SEEN when it is added.
If not, not a big deal, just thought it could be easier.
> +
> + if (ctx->srecord_type)
> + {
> + tree sfield
> + = build_decl (OMP_CLAUSE_LOCATION (detach_clause),
> + FIELD_DECL, NULL_TREE, ptr_type_node);
> + insert_field_into_struct (ctx->srecord_type, sfield);
> + }
> + }
> +
> + /* Move field corresponding to the detach clause first.
> + This is filled by GOMP_task and needs to be in a
> + specific position. */
> + p = _FIELDS (ctx->record_type);
> + while (*p)
> + if (*p == field)
> + *p = DECL_CHAIN (*p);
> + else
> + p = _CHAIN (*p);
> + DECL_CHAIN (field) = TYPE_FIELDS (ctx->record_type);
> + TYPE_FIELDS (ctx->record_type) = field;
> + if (ctx->srecord_type)
> + {
> + field = lookup_sfield (OMP_CLAUSE_DECL (detach_clause), ctx);
> + p = _FIELDS (ctx->srecord_type);
> + while (*p)
> + if (*p == field)
> + *p = DECL_CHAIN (*p);
> + else
> + p = _CHAIN (*p);
> + DECL_CHAIN (field) = TYPE_FIELDS (ctx->srecord_type);
> + TYPE_FIELDS (ctx->srecord_type) = field;
> + }
> + }
>layout_type (ctx->record_type);
>fixup_child_record_type (ctx);
>if (ctx->srecord_type)
> diff --git a/gcc/testsuite/c-c++-common/gomp/task-detach-1.c
> b/gcc/testsuite/c-c++-common/gomp/task-detach-1.c
> new file mode 100644
> index 000..c7dda82
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/gomp/task-detach-1.c
> @@ -0,0 +1,32 @@
> +/* { dg-do compile } */
> +/* { dg-options "-fopenmp" } */
> +
> +#include
> +
> +void f (omp_event_handle_t x, omp_event_handle_t y, int z)
> +{
> + #pragma omp task detach (x) detach (y) /* { dg-error "there can be at most
> one
[PATCH v2 3/3] RTEMS: Add -mcustom-fpu-cfg=fph2 multilib
This multilib supports Nios II configurations with the "Nios II Floating Point Hardware 2 Component". gcc/ * config/nios2/t-rtems: Reset all MULTILIB_* variables. Shorten multilib directory names. Use MULTILIB_REQUIRED instead of MULTILIB_EXCEPTIONS. Add -mhw-mul -mhw-mulx -mhw-div -mcustom-fpu-cfg=fph2 multilib. --- gcc/config/nios2/t-rtems | 146 +-- 1 file changed, 18 insertions(+), 128 deletions(-) diff --git a/gcc/config/nios2/t-rtems b/gcc/config/nios2/t-rtems index f95fa3c4717..beda8328bd2 100644 --- a/gcc/config/nios2/t-rtems +++ b/gcc/config/nios2/t-rtems @@ -1,133 +1,23 @@ # Custom RTEMS multilibs -MULTILIB_OPTIONS = mhw-mul mhw-mulx mhw-div mcustom-fadds=253 mcustom-fdivs=255 mcustom-fmuls=252 mcustom-fsubs=254 +# Reset all MULTILIB variables + +MULTILIB_OPTIONS = +MULTILIB_DIRNAMES = +MULTILIB_EXCEPTIONS= +MULTILIB_REUSE = +MULTILIB_MATCHES = +MULTILIB_REQUIRED = # Enumeration of multilibs -# MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fdivs=255 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fmuls=252/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fmuls=252 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fadds=253 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fdivs=255 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fmuls=252/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fmuls=252 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div/mcustom-fsubs=254 -# MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mhw-div -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fdivs=255 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fmuls=252/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fmuls=252 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fadds=253 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fdivs=255/mcustom-fmuls=252 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fdivs=255/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fdivs=255 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fmuls=252/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fmuls=252 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-mulx -MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fdivs=255 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fmuls=252/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fmuls=252 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fadds=253 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fdivs=255/mcustom-fmuls=252 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fdivs=255/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fdivs=255 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fmuls=252/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fmuls=252 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-div/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS += mhw-mul/mhw-div -MULTILIB_EXCEPTIONS += mhw-mul/mcustom-fadds=253/mcustom-fdivs=255/mcustom-fmuls=252/mcustom-fsubs=254 -MULTILIB_EXCEPTIONS +=
[PATCH v2 2/3] nios2: Add -mcustom-fpu-cfg=fph2
The new -mcustom-fpu-cfg=fph2 option variant is useful to build a
multilib for the "Nios II Floating Point Hardware 2 Component":
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_nios2_custom_instruction.pdf
Directly using the corresponding -mcustom-insn=N options for this
floating-point unit leads to a combinatorial explosion in the potential
count of multilibs which may break the build.
gcc/
* config/nios2/nios2.c (NIOS2_FPU_CONFIG_NUM): Adjust value.
(nios2_init_fpu_configs): Provide register values for new
-mcustom-fpu-cfg=fph2 option variant.
* doc/invoke.texi (-mcustom-fpu-cfg=fph2): Document new option
variant.
---
gcc/config/nios2/nios2.c | 23 ++-
gcc/doc/invoke.texi | 28
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/gcc/config/nios2/nios2.c b/gcc/config/nios2/nios2.c
index e4349e766ae..3ff4ff1bfd2 100644
--- a/gcc/config/nios2/nios2.c
+++ b/gcc/config/nios2/nios2.c
@@ -1208,7 +1208,7 @@ struct nios2_fpu_config
int code[n2fpu_code_num];
};
-#define NIOS2_FPU_CONFIG_NUM 3
+#define NIOS2_FPU_CONFIG_NUM 4
static struct nios2_fpu_config custom_fpu_config[NIOS2_FPU_CONFIG_NUM];
static void
@@ -1252,6 +1252,27 @@ nios2_init_fpu_configs (void)
cfg->code[n2fpu_fsubs] = 254;
cfg->code[n2fpu_fdivs] = 255;
+ NEXT_FPU_CONFIG;
+ cfg->name = "fph2";
+ cfg->code[n2fpu_fabss] = 224;
+ cfg->code[n2fpu_fnegs] = 225;
+ cfg->code[n2fpu_fcmpnes] = 226;
+ cfg->code[n2fpu_fcmpeqs] = 227;
+ cfg->code[n2fpu_fcmpges] = 228;
+ cfg->code[n2fpu_fcmpgts] = 229;
+ cfg->code[n2fpu_fcmples] = 230;
+ cfg->code[n2fpu_fcmplts] = 231;
+ cfg->code[n2fpu_fmaxs] = 232;
+ cfg->code[n2fpu_fmins] = 233;
+ cfg->code[n2fpu_round] = 248;
+ cfg->code[n2fpu_fixsi] = 249;
+ cfg->code[n2fpu_floatis] = 250;
+ cfg->code[n2fpu_fsqrts] = 251;
+ cfg->code[n2fpu_fmuls] = 252;
+ cfg->code[n2fpu_fadds] = 253;
+ cfg->code[n2fpu_fsubs] = 254;
+ cfg->code[n2fpu_fdivs] = 255;
+
#undef NEXT_FPU_CONFIG
gcc_assert (i == NIOS2_FPU_CONFIG_NUM);
}
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8f100911048..3f30230b0c2 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -26121,6 +26121,26 @@ Currently, the following sets are defined:
-mcustom-fdivs=255 @gol
-fsingle-precision-constant}
+@option{-mcustom-fpu-cfg=fph2} is equivalent to:
+@gccoptlist{-mcustom-fabss=224 @gol
+-mcustom-fnegs=225 @gol
+-mcustom-fcmpnes=226 @gol
+-mcustom-fcmpeqs=227 @gol
+-mcustom-fcmpges=228 @gol
+-mcustom-fcmpgts=229 @gol
+-mcustom-fcmples=230 @gol
+-mcustom-fcmplts=231 @gol
+-mcustom-fmaxs=232 @gol
+-mcustom-fmins=233 @gol
+-mcustom-round=248 @gol
+-mcustom-fixsi=249 @gol
+-mcustom-floatis=250 @gol
+-mcustom-fsqrts=251 @gol
+-mcustom-fmuls=252 @gol
+-mcustom-fadds=253 @gol
+-mcustom-fsubs=254 @gol
+-mcustom-fdivs=255 @gol}
+
Custom instruction assignments given by individual
@option{-mcustom-@var{insn}=} options override those given by
@option{-mcustom-fpu-cfg=}, regardless of the
@@ -26131,6 +26151,14 @@ configuration by using the
@code{target("custom-fpu-cfg=@var{name}")}
function attribute (@pxref{Function Attributes})
or pragma (@pxref{Function Specific Option Pragmas}).
+The name @var{fph2} is an abbreviation for @emph{Nios II Floating Point
+Hardware 2 Component}. Please note that the custom instructions enabled by
+@option{-mcustom-fmins=233} and @option{-mcustom-fmaxs=234} are only generated
+if @option{-ffinite-math-only} is specified. The custom instruction enabled by
+@option{-mcustom-round=248} is only generated if @option{-fno-math-errno} is
+specified. In contrast to the other configurations,
+@option{-fsingle-precision-constant} is not set.
+
@end table
These additional @samp{-m} options are available for the Altera Nios II
--
2.26.2
[PATCH v2 1/3] nios2: Remove custom instruction warnings
Do not warn if custom instructions are not used due to missing optimization flags. This prevents build errors with -Werror which cannot be disabled via a dedicated warning option. One reason to remove these warnings is to enable a multilib for the "Nios II Floating Point Hardware 2 Component". For example, the libatomic target library in GCC is built with -Werror and the warnings removed by this patch resulted in errors like: cc1: error: switch '-mcustom-fmins' has no effect unless '-ffinite-math-only' is specified [-Werror] cc1: error: switch '-mcustom-fmaxs' has no effect unless '-ffinite-math-only' is specified [-Werror] cc1: error: switch '-mcustom-round' has no effect unless '-fno-math-errno' is specified [-Werror] gcc/ * config/nios2/nios2.c (nios2_custom_check_insns): Remove custom instruction warnings. --- gcc/config/nios2/nios2.c | 28 1 file changed, 28 deletions(-) diff --git a/gcc/config/nios2/nios2.c b/gcc/config/nios2/nios2.c index 3bffabe9856..e4349e766ae 100644 --- a/gcc/config/nios2/nios2.c +++ b/gcc/config/nios2/nios2.c @@ -1186,34 +1186,6 @@ nios2_custom_check_insns (void) break; } - /* Warn if the user has certain exotic operations that won't get used - without -funsafe-math-optimizations. See expand_builtin () in - builtins.c. */ - if (!flag_unsafe_math_optimizations) -for (i = 0; i < ARRAY_SIZE (nios2_fpu_insn); i++) - if (N2FPU_ENABLED_P (i) && N2FPU_UNSAFE_P (i)) - warning (0, "switch %<-mcustom-%s%> has no effect unless " -"%<-funsafe-math-optimizations%> is specified", -N2FPU_NAME (i)); - - /* Warn if the user is trying to use -mcustom-fmins et. al, that won't - get used without -ffinite-math-only. See fold_builtin_fmin_fmax () - in builtins.c. */ - if (!flag_finite_math_only) -for (i = 0; i < ARRAY_SIZE (nios2_fpu_insn); i++) - if (N2FPU_ENABLED_P (i) && N2FPU_FINITE_P (i)) - warning (0, "switch %<-mcustom-%s%> has no effect unless " -"%<-ffinite-math-only%> is specified", N2FPU_NAME (i)); - - /* Warn if the user is trying to use a custom rounding instruction - that won't get used without -fno-math-errno. See - expand_builtin_int_roundingfn_2 () in builtins.c. */ - if (flag_errno_math) -for (i = 0; i < ARRAY_SIZE (nios2_fpu_insn); i++) - if (N2FPU_ENABLED_P (i) && N2FPU_NO_ERRNO_P (i)) - warning (0, "switch %<-mcustom-%s%> has no effect unless " -"%<-fno-math-errno%> is specified", N2FPU_NAME (i)); - if (errors || custom_code_conflict) fatal_error (input_location, "conflicting use of %<-mcustom%> switches, target attributes, " -- 2.26.2
