[PATCH v2]: testcases for "ICE for unknown parameter to constexpr'd switch-statement, PR113545"
> Date: Wed, 7 Feb 2024 16:32:57 -0500
> From: Jason Merrill
> Incidentally, these testcases seem to require C++14; you can't have a
> switch in a constexpr function in C++11.
Update, v2 (from v1 that had a few requests from Marek
resolved from v0 that was posted together with my patch^Whack):
Move from cpp0x to cpp1y. Qualify with c++14 instead of
c++11. Add a one-liner commit-message.
I checked that these DTRT. Currently:
Using "make check-gcc-c++ RUNTESTFLAGS=dg.exp=constexpr-reinterpret\*":
Running /x/gcc/gcc/testsuite/g++.dg/dg.exp ...
=== g++ Summary ===
# of expected passes33
# of expected failures 3
# of unresolved testcases 3
# of unsupported tests 4
...and that there's an XPASS when a ICE-resolving patch is
applied, testing each of my hack and Jason's, both yield:
Using /x/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific
interface file.
Running /x/gcc/gcc/testsuite/g++.dg/dg.exp ...
XPASS: g++.dg/cpp1y/constexpr-reinterpret3.C -std=c++14 (internal compiler
error)
XPASS: g++.dg/cpp1y/constexpr-reinterpret3.C -std=c++17 (internal compiler
error)
XPASS: g++.dg/cpp1y/constexpr-reinterpret3.C -std=c++20 (internal compiler
error)
And (since it appears the benefit isn't obvious) why commit
a test-cases before the fix? Well, I'm not dead sure the
fix both gets there soon, and that it then stays there.
Even if it does so within decent time, as an exception
(IIUC) because we're in stage 4 and the bug is not a
regression, it could easily be reverted if it'd uncover some
other wart that's not sufficiently easily resolved.
Also, the fix seems to me sufficiently remote to the
gcc_assert, that the execution path leading to it could be
diverted; hidden or resolved while fixing something else,
and then it'd be nice to know that it fixed *this* bug too.
To wit: More dg-ice test-cases! Don't fear adding xfails or
dg-ices! Marek, you write that dg-ice support. Thank you!
Ok to commit?
-- >8 --
gcc/testsuite:
Test-cases, with constexpr-reinterpret3.C dg-ice:ing the PR c++/113545 bug.
PR c++/113545
* g++.dg/cpp1y/constexpr-reinterpret3.C,
g++.dg/cpp1y/constexpr-reinterpret4.C: New tests.
---
.../g++.dg/cpp1y/constexpr-reinterpret3.C | 55 +++
.../g++.dg/cpp1y/constexpr-reinterpret4.C | 54 ++
2 files changed, 109 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-reinterpret3.C
create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-reinterpret4.C
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-reinterpret3.C
b/gcc/testsuite/g++.dg/cpp1y/constexpr-reinterpret3.C
new file mode 100644
index ..ed914383f78b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-reinterpret3.C
@@ -0,0 +1,55 @@
+// PR c++/113545
+// { dg-do run { target c++14 } }
+// { dg-ice "PR112545 - constexpr function with switch called for
reinterpret_cast" }
+
+char foo;
+
+// This one caught a call to gcc_unreachable in
+// cp/constexpr.cc:label_matches, when passed a convert_expr from the
+// cast in the call.
+constexpr unsigned char swbar(__UINTPTR_TYPE__ baz)
+{
+ switch (baz)
+{
+case 13:
+ return 11;
+case 14:
+ return 78;
+case 2048:
+ return 13;
+default:
+ return 42;
+}
+}
+
+// For reference, the equivalent* if-statements.
+constexpr unsigned char ifbar(__UINTPTR_TYPE__ baz)
+{
+ if (baz == 13)
+return 11;
+ else if (baz == 14)
+return 78;
+ else if (baz == 2048)
+return 13;
+ else
+return 42;
+}
+
+__attribute__ ((__noipa__))
+void xyzzy(int x)
+{
+ if (x != 42)
+__builtin_abort ();
+}
+
+int main()
+{
+ unsigned const char c = swbar(reinterpret_cast<__UINTPTR_TYPE__>());
+ xyzzy(c);
+ unsigned const char d = ifbar(reinterpret_cast<__UINTPTR_TYPE__>());
+ xyzzy(d);
+ unsigned const char e = swbar((__UINTPTR_TYPE__) );
+ xyzzy(e);
+ unsigned const char f = ifbar((__UINTPTR_TYPE__) );
+ xyzzy(f);
+}
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-reinterpret4.C
b/gcc/testsuite/g++.dg/cpp1y/constexpr-reinterpret4.C
new file mode 100644
index ..9aaa6e463bc6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-reinterpret4.C
@@ -0,0 +1,54 @@
+// PR c++/113545
+// { dg-do compile { target c++14 } }
+
+char foo;
+
+// This one caught a call to gcc_unreachable in
+// cp/constexpr.cc:label_matches, when passed a convert_expr from the
+// cast in the call.
+constexpr unsigned char swbar(__UINTPTR_TYPE__ baz)
+{
+ switch (baz)
+{
+case 13:
+ return 11;
+case 14:
+ return 78;
+case 2048:
+ return 13;
+default:
+ return 42;
+}
+}
+
+// For reference, the equivalent* if-statements.
+constexpr unsigned char ifbar(__UINTPTR_TYPE__ baz)
+{
+ if (baz == 13)
+return 11;
+ else if (baz == 14)
+return 78;
+ else if (baz == 2048)
+return 13;
+ else
+return 42;
+}
+
+__attribute__ ((__noipa__))
+void
Re: [PATCH] Fortran: error recovery on arithmetic overflow on unary operations [PR113799]
On 2/8/24 1:03 PM, Harald Anlauf wrote: Dear all, the attached patch improves error recovery when we encounter an array constructor where a unary operator (e.g. minus) is applied and -frange-check is active. The solution is not to terminate early in that case to avoid inconsistencies between check_result and reduce_unary when such a situation occurs. (There might be similar issues for binary operators, not treated here.) Regtested on x86_64-pc-linux-gnu. OK for mainline? The ICE/memory corruption is actually a 10+ regression. Do we need a backport? Thanks, Harald Hi Harald, This patch looks OK. Thanks, Jerry
Re: [PATCH v2] testsuite: Pattern does not match when using --specs=nano.specs
On Feb 8, 2024, at 9:44 AM, Torbjörn SVENSSON wrote: > > Changes since v1: > - Replaced .* with [^\r\n]* to avoid matching newline. > > Ok for trunk and releases/gcc-13? Ok.
[PING 1] [PATCH] htdocs: correct spelling and use https in examples
Hello Polite reminder of patch for review. Thanks, Jonny Forwarded Message Subject: [PATCH] htdocs: correct spelling and use https in examples Date: Wed, 6 Dec 2023 22:33:14 + From: Jonny Grant To: gcc-patches@gcc.gnu.org CC: Joseph Myers Revised version of this patch after review. ChangeLog: htdocs: correct spelling and use https in examples. >From 52d413bce86827f2add424e78321b509661f6f59 Mon Sep 17 00:00:00 2001 From: Jonathan Grant Date: Wed, 6 Dec 2023 22:27:29 + Subject: [PATCH] htdocs: correct spelling and use https in examples Signed-off-by: Jonathan Grant --- htdocs/bugs/management.html | 2 +- htdocs/codingrationale.html | 2 +- htdocs/contribute.html| 6 +++--- htdocs/gcc-14/changes.html| 2 +- htdocs/gccmission.html| 2 +- htdocs/git.html | 7 +++ htdocs/projects/cfg.html | 2 +- htdocs/projects/cli.html | 2 +- htdocs/projects/cxx-reflection/index.html | 2 +- htdocs/projects/optimize.html | 6 +++--- htdocs/projects/tree-profiling.html | 2 +- htdocs/testing/index.html | 2 +- 12 files changed, 18 insertions(+), 19 deletions(-) diff --git a/htdocs/bugs/management.html b/htdocs/bugs/management.html index 28dfa76a..b2bb740e 100644 --- a/htdocs/bugs/management.html +++ b/htdocs/bugs/management.html @@ -64,7 +64,7 @@ perspective, these are the relevant ones and what their values mean: The status and resolution fields define and track the life cycle of a bug. In addition to their https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html;>regular -descriptions, we also use two adition status values: +descriptions, we also use two additional status values: diff --git a/htdocs/codingrationale.html b/htdocs/codingrationale.html index 6cc76885..c51c9da4 100644 --- a/htdocs/codingrationale.html +++ b/htdocs/codingrationale.html @@ -155,7 +155,7 @@ Wide use of implicit conversion can cause some very surprising results. C++03 has no explicit conversion operators, -and hence using them cannot avoid suprises. +and hence using them cannot avoid surprises. Wait for C++11. diff --git a/htdocs/contribute.html b/htdocs/contribute.html index 7c1ae323..152675fa 100644 --- a/htdocs/contribute.html +++ b/htdocs/contribute.html @@ -299,7 +299,7 @@ followed by a colon. For example, Some large components may be subdivided into sub-components. If -the subcomponent name is not disctinct in its own right, you can use the +the subcomponent name is not distinct in its own right, you can use the form component/sub-component:. Series identifier @@ -329,7 +329,7 @@ the commit message so that Bugzilla will correctly notice the commit. If your patch relates to two bugs, then write [PRn, PRm]. For multiple bugs, just cite the most relevant one in the summary and use an -elipsis instead of the second, or subsequent PR numbers; list all the +ellipsis instead of the second, or subsequent PR numbers; list all the related PRs in the body of the commit message in the normal way. It is not necessary to cite bugs that are closed as duplicates of @@ -354,7 +354,7 @@ together. If you submit a new version of a patch series, then you should start a new email thread (don't reply to the original patch series). This avoids email threads becoming confused between discussions of the -first and subsequent revisions of the patch set. Your cover leter +first and subsequent revisions of the patch set. Your cover letter (0/nnn) should explain clearly what has been changed between the two patch series. Also state if some of the patches are unchanged between revisions; this saves maintainers having to re-review the diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 5a453437..bd51ecb4 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -34,7 +34,7 @@ a work-in-progress. another structure, is deprecated. Refer to https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html;> Zero Length Arrays. - Any code relying on this extension should be modifed to ensure that + Any code relying on this extension should be modified to ensure that C99 flexible array members only end up at the ends of structures. Please use the warning option https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wflex-array-member-not-at-end;>-Wflex-array-member-not-at-end to diff --git a/htdocs/gccmission.html b/htdocs/gccmission.html index 58a12755..1124fe9f 100644 --- a/htdocs/gccmission.html +++ b/htdocs/gccmission.html @@ -55,7 +55,7 @@ GCC. Patches will be considered equally based on their technical merits. All individuals and companies are welcome to contribute - as long as they accept the groundrules. + as long as they accept the ground rules. Open mailing lists. Developer
Re: [PATCH v2] c++: make build_throw SFINAE-friendly [PR98388]
On Thu, Feb 08, 2024 at 04:53:45PM -0500, Jason Merrill wrote:
> On 2/8/24 11:51, Marek Polacek wrote:
> > On Thu, Feb 08, 2024 at 08:49:28AM -0500, Patrick Palka wrote:
> > > On Wed, 7 Feb 2024, Marek Polacek wrote:
> > >
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > >
> > > > -- >8 --
> > > > Here the problem is that we give hard errors while substituting
> > > > template parameters during overload resolution of is_throwable
> > > > which has an invalid throw in decltype.
> > > >
> > > > The backtrace shows that fn_type_unification -> instantiate_template
> > > > -> tsubst* passes complain=0 as expected, but build_throw doesn't
> > > > have a complain parameter. So let's add one. Also remove a redundant
> > > > local variable which I should have removed in my P2266 patch.
> > > >
> > > > But there's still something not quite clear to me. I claim that 'b'
> > > > in the testcase should evaluate to false since the first overload ought
> > > > to have been discarded. EDG 6.6 agrees, but clang++, msvc, and icx
> > > > evaluate
> > > > it to true. Who's right?
>
> I think it should be true since P1155, which we implement in C++20 mode and
> above (or rather, we implement the sequel P2266); since then we implicitly
> move from the function parameter.
>
> The patch looks good except that we should test this expected value.
I could add
#if __cplusplus >= 202002L
static_assert (b, "move from the function parameter");
#else
static_assert (!b, "no move from the function parameter");
#endif
but that's going to fail for C++20 and above. I wonder if this is the
second half of the problem in 113789?
I could comment the first static_assert and add a FIXME if that sounds good?
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/cpp0x/sfinae69.C
> > @@ -0,0 +1,16 @@
> > +// PR c++/98388
> > +// { dg-do compile { target c++11 } }
> > +
> > +struct moveonly {
> > +moveonly() = default;
> > +moveonly(moveonly&&) = default;
> > +};
> > +
> > +template
> > +constexpr auto is_throwable(T t) -> decltype(throw t, true) {
> > +return true;
> > +}
> > +template
> > +constexpr bool is_throwable(...) { return false; }
> > +
> > +constexpr bool b = is_throwable(moveonly{});
Marek
[PATCH] libgccjit: Clear pending_assemble_externals_processed
Hi.
This patch fixes the bug 113842.
I cannot yet add a test with this patch since it requires using
try/catch which is not yet merged in master.
Thanks for the review.
From 71f5f5fa8e68594454d5511b6d0c795bc6a8c37a Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Fri, 26 Jan 2024 11:31:47 -0500
Subject: [PATCH] libgccjit: Clear pending_assemble_externals_processed
Without this patch, code using exception handling will fail the
following assert in the function assemble_external_libcall in varasm.cc:
gcc_assert (!pending_assemble_externals_processed)
gcc/ChangeLog:
PR jit/113842
* toplev.cc (toplev::finalize): Call varasm_cc_finalize.
* varasm.cc (varasm_cc_finalize): New function to clear
pending_assemble_externals_processed.
* varasm.h (varasm_cc_finalize): New function.
---
gcc/toplev.cc | 1 +
gcc/varasm.cc | 8
gcc/varasm.h | 2 ++
3 files changed, 11 insertions(+)
diff --git a/gcc/toplev.cc b/gcc/toplev.cc
index 175d4cd18fa..eca8ba292b4 100644
--- a/gcc/toplev.cc
+++ b/gcc/toplev.cc
@@ -2372,6 +2372,7 @@ toplev::finalize (void)
ira_costs_cc_finalize ();
tree_cc_finalize ();
reginfo_cc_finalize ();
+ varasm_cc_finalize ();
/* save_decoded_options uses opts_obstack, so these must
be cleaned up together. */
diff --git a/gcc/varasm.cc b/gcc/varasm.cc
index fa17eff551e..2aa46b498e4 100644
--- a/gcc/varasm.cc
+++ b/gcc/varasm.cc
@@ -8661,4 +8661,12 @@ handle_vtv_comdat_section (section *sect, const_tree decl ATTRIBUTE_UNUSED)
switch_to_comdat_section(sect, DECL_NAME (decl));
}
+void
+varasm_cc_finalize (void)
+{
+#ifdef ASM_OUTPUT_EXTERNAL
+ pending_assemble_externals_processed = false;
+#endif
+}
+
#include "gt-varasm.h"
diff --git a/gcc/varasm.h b/gcc/varasm.h
index d9311dc370b..26e6fab8601 100644
--- a/gcc/varasm.h
+++ b/gcc/varasm.h
@@ -81,4 +81,6 @@ extern rtx assemble_trampoline_template (void);
extern void switch_to_comdat_section (section *, tree);
+extern void varasm_cc_finalize (void);
+
#endif // GCC_VARASM_H
--
2.43.0
Re: [PATCH v2] c++: make build_throw SFINAE-friendly [PR98388]
On 2/8/24 11:51, Marek Polacek wrote:
On Thu, Feb 08, 2024 at 08:49:28AM -0500, Patrick Palka wrote:
On Wed, 7 Feb 2024, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here the problem is that we give hard errors while substituting
template parameters during overload resolution of is_throwable
which has an invalid throw in decltype.
The backtrace shows that fn_type_unification -> instantiate_template
-> tsubst* passes complain=0 as expected, but build_throw doesn't
have a complain parameter. So let's add one. Also remove a redundant
local variable which I should have removed in my P2266 patch.
But there's still something not quite clear to me. I claim that 'b'
in the testcase should evaluate to false since the first overload ought
to have been discarded. EDG 6.6 agrees, but clang++, msvc, and icx evaluate
it to true. Who's right?
I think it should be true since P1155, which we implement in C++20 mode
and above (or rather, we implement the sequel P2266); since then we
implicitly move from the function parameter.
The patch looks good except that we should test this expected value.
Thanks to Patrick for notifying me of this PR. This doesn't fully fix
113789; there I think I'll have to figure our why a candidate wasn't
discarded from the overload set.
gcc/cp/ChangeLog:
* coroutines.cc (coro_rewrite_function_body): Pass tf_warning_or_error
to build_throw.
(morph_fn_to_coro): Likewise.
* cp-tree.h (build_throw): Adjust.
* except.cc (expand_end_catch_block): Pass tf_warning_or_error to
build_throw.
(build_throw): Add a tsubst_flags_t parameter. Use it. Remove
redundant variable. Guard an inform call.
* parser.cc (cp_parser_throw_expression): Pass tf_warning_or_error
to build_throw.
* pt.cc (tsubst_expr) : Pass complain to build_throw.
libcc1/ChangeLog:
* libcp1plugin.cc (plugin_build_unary_expr): Pass tf_error to
build_throw.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/sfinae69.C: New test.
---
gcc/cp/coroutines.cc | 4 ++--
gcc/cp/cp-tree.h | 3 ++-
gcc/cp/except.cc | 31 +++
gcc/cp/parser.cc | 2 +-
gcc/cp/pt.cc | 2 +-
gcc/testsuite/g++.dg/cpp0x/sfinae69.C | 16 ++
libcc1/libcp1plugin.cc| 4 ++--
7 files changed, 37 insertions(+), 25 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/sfinae69.C
diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 3194c911e8c..9b037edbd14 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -4246,7 +4246,7 @@ coro_rewrite_function_body (location_t fn_start, tree
fnbody, tree orig,
boolean_type_node, i_a_r_c);
finish_if_stmt_cond (not_iarc, not_iarc_if);
/* If the initial await resume called value is false, rethrow... */
- tree rethrow = build_throw (fn_start, NULL_TREE);
+ tree rethrow = build_throw (fn_start, NULL_TREE, tf_warning_or_error);
suppress_warning (rethrow);
finish_expr_stmt (rethrow);
finish_then_clause (not_iarc_if);
@@ -5151,7 +5151,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree
*destroyer)
tree del_coro_fr = coro_get_frame_dtor (coro_fp, orig, frame_size,
promise_type, fn_start);
finish_expr_stmt (del_coro_fr);
- tree rethrow = build_throw (fn_start, NULL_TREE);
+ tree rethrow = build_throw (fn_start, NULL_TREE, tf_warning_or_error);
suppress_warning (rethrow);
finish_expr_stmt (rethrow);
finish_handler (handler);
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 969c7239c97..334c11396c2 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7185,7 +7185,8 @@ extern void init_exception_processing (void);
extern tree expand_start_catch_block (tree);
extern void expand_end_catch_block(void);
extern tree build_exc_ptr (void);
-extern tree build_throw(location_t, tree);
+extern tree build_throw(location_t, tree,
+tsubst_flags_t);
extern int nothrow_libfn_p(const_tree);
extern void check_handlers(tree);
extern tree finish_noexcept_expr (tree, tsubst_flags_t);
diff --git a/gcc/cp/except.cc b/gcc/cp/except.cc
index d17a57d3fbc..ed704b6c28a 100644
--- a/gcc/cp/except.cc
+++ b/gcc/cp/except.cc
@@ -486,7 +486,8 @@ expand_end_catch_block (void)
|| DECL_DESTRUCTOR_P (current_function_decl))
&& !in_nested_catch ())
{
- tree rethrow = build_throw (input_location, NULL_TREE);
+ tree rethrow = build_throw (input_location, NULL_TREE,
+
Re: [PATCH] gcc/doc: spelling mistakes and example
On 10/01/2024 21:26, Jonny Grant wrote:
>
>
> On 03/12/2023 17:55, David Malcolm wrote:
>> On Sun, 2023-12-03 at 11:59 +, Jonny Grant wrote:
>>>
>>>
>>> On 03/12/2023 04:03, Xi Ruoyao wrote:
On Sun, 2023-12-03 at 00:17 +, Jonny Grant wrote:
> @@ -733,7 +733,7 @@ To configure GCC:
> @smallexample
> % mkdir @var{objdir}
> % cd @var{objdir}
> -% @var{srcdir}/configure [@var{options}] [@var{target}]
> +% ../@var{srcdir}/configure [@var{options}] [@var{target}]
> @end smallexample
No, this is definitely incorrect. srcdir is the path (it may be
relative or absolute) to the GCC source tree. It's not necessary
to be
placed in the parent directory of objdir.
>>>
>>> Fair enough.
>>>
>>> Can the spelling corrections still be merged? Or should I re-submit
>>> the patch without that line?
>>
>> The spelling corrections look OK to me.
>>
>> Do you have an account that can push commits, or would you need this
>> done for you?
>>
>> Please can you add Signed-off-by lines to your patches/commits
>> (via -s); see https://gcc.gnu.org/dco.html
>>
>> Thanks
>> Dave
>
> Hi Dave
>
> Would need someone to push the commits as I don't have an account.
>
> I'll use -s for next patches, I've emailed again with the line added:
>
> Signed-off-by: Jonathan Grant
>
> Thanks, Jonny
Hi Dave
May I ask for review of my revised patch please.
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642539.html
Kind regards, Jonny
[committed] libstdc++: Fix comment typo in std::atomic>
Tested aarch64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr_atomic.h: Fix typo in comment.
---
libstdc++-v3/include/bits/shared_ptr_atomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/bits/shared_ptr_atomic.h
b/libstdc++-v3/include/bits/shared_ptr_atomic.h
index 58aea96492e..1403c6a17c5 100644
--- a/libstdc++-v3/include/bits/shared_ptr_atomic.h
+++ b/libstdc++-v3/include/bits/shared_ptr_atomic.h
@@ -557,7 +557,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
__glibcxx_assert(__o != memory_order_release
&& __o != memory_order_acq_rel);
- // Ensure that the correct value of _M_ptr is visible after locking.,
+ // Ensure that the correct value of _M_ptr is visible after locking,
// by upgrading relaxed or consume to acquire.
if (__o != memory_order_seq_cst)
__o = memory_order_acquire;
--
2.43.0
[committed] libstdc++: Add comment to gslice::operator=(const gslice&) [PR100147]
Tested aarch64-linux. Pushed to trunk.
-- >8 --
There's no need to check for self-assignment here, it would just add
extra code for an unlikely case. Add a comment saying so.
libstdc++-v3/ChangeLog:
PR libstdc++/100147
* include/bits/gslice.h (operator=): Add comment about lack of
self-assignment check.
---
libstdc++-v3/include/bits/gslice.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libstdc++-v3/include/bits/gslice.h
b/libstdc++-v3/include/bits/gslice.h
index 3d78da2bd75..d9a8b929a57 100644
--- a/libstdc++-v3/include/bits/gslice.h
+++ b/libstdc++-v3/include/bits/gslice.h
@@ -169,6 +169,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
inline gslice&
gslice::operator=(const gslice& __g)
{
+// Safe for self-assignment. Checking for it would add overhead just to
+// optimize a case that should never happen anyway.
if (__g._M_index)
__g._M_index->_M_increment_use();
if (_M_index && _M_index->_M_decrement_use() == 0)
--
2.43.0
Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]
On 2/8/24 12:55, Paolo Bonzini wrote: On 2/8/24 18:16, Jason Merrill wrote: Hmm. In stage 1, when we build with the system gcc, I'd think we want the just-built gnat1 to find the system libgcc. In stage 2, when we build with the stage 1 gcc, we want the just-built gnat1 to find the stage 1 libgcc. In neither case do we want it to find the libgcc from the current stage. So it seems to me that what we want is for stage2+ LD_LIBRARY_PATH to include the TARGET_LIB_PATH from the previous stage. Something like the below, on top of the earlier patch. Does this make sense? Does it work on Darwin? Oops, that was broken, please consider this one instead: Yes, this one makes sense (and the current code would not work since it lacks the prev- prefix on TARGET_LIB_PATH). Indeed, that seems like evidence that the only element of TARGET_LIB_PATH that has been useful in HOST_EXPORTS is the prev- part of HOST_LIB_PATH_gcc. So, here's another patch that just includes that for post-stage1: From 3709ba23e4e3f5f6b2b6af709179ea5e471e2a55 Mon Sep 17 00:00:00 2001 From: Jason Merrill Date: Wed, 24 Jan 2024 07:47:26 -0500 Subject: [PATCH] build: drop target libs from LD_LIBRARY_PATH [PR105688] To: gcc-patches@gcc.gnu.org The patch for PR22340 (r104978) moved the adding of TARGET_LIB_PATH to RPATH_ENVVAR from POSTSTAGE1_HOST_EXPORTS to HOST_EXPORTS, but didn't mention that in the ChangeLog; it also wasn't part of the patch that was sent to gcc-patches. I suspect it was included accidentally? It also causes PR105688 when rebuilding stage1: once the stage1 libstdc++ has been built, if calling the system gcc to build host code involves invoking any tool that links against libstdc++.so (gold, ccache) they get the just-built library instead of the system library they expect. Reverting that hunk of the change fixed my problem with bubblestrapping GCC 12 with ccache on a host with a newer system libstdc++. But I believe that adding TARGET_LIB_PATH to RPATH_ENVVAR is not needed for post-stage1 either. Including TARGET_LIB_PATH goes back to r37545, with the stated rationale of getting other C++ library configury to succeed, but that seems like a rationale for having it in TARGET_EXPORTS, not HOST_. And when building stage2+, looking for current stage target libraries isn't what we want anyway; we would have wanted the previous stage target libraries, and we haven't been looking for them, except for the previous stage libgcc that we get from HOST_LIB_PATH_gcc. So, for stage2+, let's add just prev-gcc. PR bootstrap/105688 ChangeLog: * Makefile.tpl (HOST_EXPORTS): Don't add TARGET_LIB_PATH to RPATH_ENVVAR. (POSTSTAGE1_HOST_EXPORTS): Add PREV_HOST_LIB_PATH_gcc. (PREV_HOST_LIB_PATH_gcc): Split out from HOST_LIB_PATH_gcc. * Makefile.in: Regenerate. --- Makefile.in | 7 +++ Makefile.tpl | 7 +++ 2 files changed, 6 insertions(+), 8 deletions(-) diff --git a/Makefile.in b/Makefile.in index edb0c8a9a42..c248003ee36 100644 --- a/Makefile.in +++ b/Makefile.in @@ -242,9 +242,6 @@ HOST_EXPORTS = \ ISLLIBS="$(HOST_ISLLIBS)"; export ISLLIBS; \ ISLINC="$(HOST_ISLINC)"; export ISLINC; \ XGCC_FLAGS_FOR_TARGET="$(XGCC_FLAGS_FOR_TARGET)"; export XGCC_FLAGS_FOR_TARGET; \ -@if gcc-bootstrap - $(RPATH_ENVVAR)=`echo "$(TARGET_LIB_PATH)$$$(RPATH_ENVVAR)" | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \ -@endif gcc-bootstrap $(RPATH_ENVVAR)=`echo "$(HOST_LIB_PATH)$$$(RPATH_ENVVAR)" | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); POSTSTAGE1_CXX_EXPORT = \ @@ -269,6 +266,7 @@ POSTSTAGE1_CXX_EXPORT = \ # Similar, for later GCC stages. POSTSTAGE1_HOST_EXPORTS = \ $(HOST_EXPORTS) \ + $(RPATH_ENVVAR)=`echo "$(HOST_PREV_LIB_PATH_gcc)$$$(RPATH_ENVVAR)" | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \ CC="$(STAGE_CC_WRAPPER) $$r/$(HOST_SUBDIR)/prev-gcc/xgcc$(exeext) \ -B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ \ $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CC; \ @@ -775,7 +773,8 @@ HOST_LIB_PATH = $(HOST_LIB_PATH_gmp)$(HOST_LIB_PATH_mpfr)$(HOST_LIB_PATH_mpc)$(H # Define HOST_LIB_PATH_gcc here, for the sake of TARGET_LIB_PATH, ouch @if gcc -HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/gcc$(GCC_SHLIB_SUBDIR):$$r/$(HOST_SUBDIR)/prev-gcc$(GCC_SHLIB_SUBDIR): +HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/gcc$(GCC_SHLIB_SUBDIR): +HOST_PREV_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/prev-gcc$(GCC_SHLIB_SUBDIR): @endif gcc diff --git a/Makefile.tpl b/Makefile.tpl index adbcbdd1d57..844b9e8f63a 100644 --- a/Makefile.tpl +++ b/Makefile.tpl @@ -245,9 +245,6 @@ HOST_EXPORTS = \ ISLLIBS="$(HOST_ISLLIBS)"; export ISLLIBS; \ ISLINC="$(HOST_ISLINC)"; export ISLINC; \ XGCC_FLAGS_FOR_TARGET="$(XGCC_FLAGS_FOR_TARGET)"; export XGCC_FLAGS_FOR_TARGET; \ -@if gcc-bootstrap - $(RPATH_ENVVAR)=`echo "$(TARGET_LIB_PATH)$$$(RPATH_ENVVAR)" | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \ -@endif gcc-bootstrap $(RPATH_ENVVAR)=`echo
[PATCH v3] c++: DR2237, cdtor and template-id tweaks [PR107126]
On Wed, Feb 07, 2024 at 05:19:56PM -0500, Jason Merrill wrote:
> On 2/5/24 22:11, Marek Polacek wrote:
> > On Mon, Feb 05, 2024 at 10:14:34AM -0500, Jason Merrill wrote:
> > > On 2/3/24 10:24, Marek Polacek wrote:
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > >
> > > > I'm not certain OPT_Wc__20_extensions is the best thing for something
> > > > from [diff.cpp17]; would you prefer something else?
> > >
> > > I think it wants its own flag, that is enabled in C++20 or by
> > > -Wc++20-compat.
> >
> > That seems best. I called it -Wdeprecated-template-id-cdtor.
> > > > + if (cxx_dialect >= cxx20)
> > > > + {
> > > > + if (!cp_parser_simulate_error (parser))
> > > > + pedwarn (tilde_loc, OPT_Wc__20_extensions,
> > > > + "template-id not allowed for destructor");
> > > > + return error_mark_node;
> > > > + }
> > > > + warning_at (tilde_loc, OPT_Wc__20_compat,
> > > > + "template-id not allowed for destructor in
> > > > C++20");
> > >
> > > After a pedwarn we should accept the code, not return error_mark_node.
> >
> > /facepalm, yes.
> > > I'm also concerned about pedwarn/warnings not guarded by
> > > !cp_parser_uncommited_to_tentative_parse; that often leads to warning
> > > about
> > > a tentative parse as a declaration that is eventually abandoned in favor
> > > of
> > > a perfectly fine parse as an expression.
> >
> > Done.
> > > It would be good for cp_parser_context to add a vec of warnings to emit at
> > > cp_parser_parse_definitely time, and then
> > > cp_parser_pedwarn/cp_parser_warning to fill it...
> >
> > That would be nice; I don't think we can fix bugs like PR61259 otherwise.
> >
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > Since my r11-532 changes to implement DR2237, for this test:
> >
> >template
> >struct S {
> > S();
> >};
> >
> > in C++20 we emit the ugly:
> >
> > q.C:3:8: error: expected unqualified-id before ')' token
> > 3 | S();
> >
> > which doesn't explain what the problem is. This patch improves that
> > diagnostic, reduces the error to a pedwarn, and adds a -Wc++20-compat
> > diagnostic. We now say:
> >
> > q.C:3:7: warning: template-id not allowed for constructor in C++20
> > [-Wdeprecated-template-id-cdtor]
> > 3 | S();
> > q.C:3:7: note: remove the '< >'
> >
> > This patch does *not* fix
> >
> > where the C++20 diagnostic is missing altogether.
> >
> > -Wc++20-compat triggered in libitm/; I sent a patch for that.
> >
> > DR 2237
> > PR c++/107126
> > PR c++/97202
> >
> > gcc/c-family/ChangeLog:
> >
> > * c-opts.cc (c_common_post_options): In C++20 or with -Wc++20-compat,
> > turn on -Wdeprecated-template-id-cdtor.
> > * c.opt (Wdeprecated-template-id-cdtor): New.
> >
> > gcc/cp/ChangeLog:
> >
> > * parser.cc (cp_parser_unqualified_id): Downgrade the DR2237 error to
> > a pedwarn.
> > (cp_parser_constructor_declarator_p): Likewise.
> >
> > diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
> > index 3748ccd49ff..473eaf4f1f7 100644
> > --- a/gcc/cp/parser.cc
> > +++ b/gcc/cp/parser.cc
> > @@ -6717,12 +6717,17 @@ cp_parser_unqualified_id (cp_parser* parser,
> > /* DR 2237 (C++20 only): A simple-template-id is no longer valid as the
> >declarator-id of a constructor or destructor. */
> > - if (token->type == CPP_TEMPLATE_ID && declarator_p
> > - && cxx_dialect >= cxx20)
> > + if (token->type == CPP_TEMPLATE_ID
> > + && declarator_p
> > + && !cp_parser_uncommitted_to_tentative_parse_p (parser)
> > + && !cp_parser_simulate_error (parser))
>
> Calling both _uncommitted_ and _simulate_ here is redundant since _simulate_
> checks _uncommitted_; since you check _uncommitted_ first, _simulate_ will
> never do anything.
Oops, pardon me.
> And checking either of them before cxx_dialect seems wrong; we don't want
> _simulate_ in pre-C++20 mode where it isn't an error, but we do want
> _simulate_ in C++20 mode when uncommitted.
I see.
> > @@ -32550,6 +32555,19 @@ cp_parser_constructor_declarator_p (cp_parser
> > *parser, cp_parser_flags flags,
> > /* We did not really want to consume any tokens. */
> > cp_parser_abort_tentative_parse (parser);
> > + /* DR 2237 (C++20 only): A simple-template-id is no longer valid as the
> > + declarator-id of a constructor or destructor. */
> > + if (constructor_p
> > + && saw_template_id
> > + && !cp_parser_uncommitted_to_tentative_parse_p (parser))
>
> As above, checking _uncommitted_ before cxx_dialect seems wrong for C++20.
>
> If testing succeeded with this patch, maybe we can't get here while parsing
> tentatively, and we just want a checking_assert (!_uncommitted_) in both
> places? Or would that break on 97202?
I can add the
[PATCH] Fortran: error recovery on arithmetic overflow on unary operations [PR113799]
Dear all,
the attached patch improves error recovery when we encounter an
array constructor where a unary operator (e.g. minus) is applied
and -frange-check is active. The solution is not to terminate
early in that case to avoid inconsistencies between check_result
and reduce_unary when such a situation occurs.
(There might be similar issues for binary operators, not treated
here.)
Regtested on x86_64-pc-linux-gnu. OK for mainline?
The ICE/memory corruption is actually a 10+ regression.
Do we need a backport?
Thanks,
Harald
From eec039211e396e35204b55588013d74289a984cd Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 8 Feb 2024 21:51:38 +0100
Subject: [PATCH] Fortran: error recovery on arithmetic overflow on unary
operations [PR113799]
PR fortran/113799
gcc/fortran/ChangeLog:
* arith.cc (reduce_unary): Remember any overflow encountered during
reduction of unary arithmetic operations on array constructors and
continue, and return error status, but terminate on serious errors.
gcc/testsuite/ChangeLog:
* gfortran.dg/arithmetic_overflow_2.f90: New test.
---
gcc/fortran/arith.cc| 11 ---
gcc/testsuite/gfortran.dg/arithmetic_overflow_2.f90 | 12
2 files changed, 20 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/arithmetic_overflow_2.f90
diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index 0598f6ac51b..d17d1aaa1d9 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -1323,6 +1323,7 @@ reduce_unary (arith (*eval) (gfc_expr *, gfc_expr **), gfc_expr *op,
gfc_constructor *c;
gfc_expr *r;
arith rc;
+ bool ov = false;
if (op->expr_type == EXPR_CONSTANT)
return eval (op, result);
@@ -1336,13 +1337,17 @@ reduce_unary (arith (*eval) (gfc_expr *, gfc_expr **), gfc_expr *op,
{
rc = reduce_unary (eval, c->expr, );
- if (rc != ARITH_OK)
+ /* Remember any overflow encountered during reduction and continue,
+ but terminate on serious errors. */
+ if (rc == ARITH_OVERFLOW)
+ ov = true;
+ else if (rc != ARITH_OK)
break;
gfc_replace_expr (c->expr, r);
}
- if (rc != ARITH_OK)
+ if (rc != ARITH_OK && rc != ARITH_OVERFLOW)
gfc_constructor_free (head);
else
{
@@ -1363,7 +1368,7 @@ reduce_unary (arith (*eval) (gfc_expr *, gfc_expr **), gfc_expr *op,
*result = r;
}
- return rc;
+ return ov ? ARITH_OVERFLOW : rc;
}
diff --git a/gcc/testsuite/gfortran.dg/arithmetic_overflow_2.f90 b/gcc/testsuite/gfortran.dg/arithmetic_overflow_2.f90
new file mode 100644
index 000..6ca27f74215
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/arithmetic_overflow_2.f90
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! { dg-additional-options "-frange-check" }
+!
+! PR fortran/113799 - handle arithmetic overflow on unary minus
+
+program p
+ implicit none
+ real, parameter :: inf = real(z'7F80')
+ real, parameter :: someInf(*) = [inf, 0.]
+ print *, -someInf ! { dg-error "Arithmetic overflow" }
+ print *, minval(-someInf) ! { dg-error "Arithmetic overflow" }
+end
--
2.35.3
Re: Repost [PATCH 1/6] Add -mcpu=future
On Fri, Jan 05, 2024 at 06:35:37PM -0500, Michael Meissner wrote:
> * config/rs6000/rs6000.opt (-mfuture): New undocumented debug switch.
No. Never ever use a flag that does what -mcpu= should do. We're
still trying to recover from previous such mistakes. Don't add more
please.
> +++ b/gcc/config/rs6000/rs6000-c.cc
> @@ -447,6 +447,8 @@ rs6000_target_modify_macros (bool define_p, HOST_WIDE_INT
> flags)
> rs6000_define_or_undefine_macro (define_p, "_ARCH_PWR9");
>if ((flags & OPTION_MASK_POWER10) != 0)
> rs6000_define_or_undefine_macro (define_p, "_ARCH_PWR10");
> + if ((flags & OPTION_MASK_FUTURE) != 0)
> +rs6000_define_or_undefine_macro (define_p, "_ARCH_PWR_FUTURE");
if a & B) != 0) != 0) != 0) ? You can do just
if (a & B)
Yes, existing code already does the silly thing, but just fix it then,
don't add more :-)
(And no if ((a & B)) either please).
> +static int
> +rs600_cpu_index_lookup (enum processor_type processor)
> +{
> + for (size_t i = 0; i < ARRAY_SIZE (processor_target_table); i++)
> +if (processor_target_table[i].processor == processor)
> + return i;
> +
> + return -1;
> +}
"int i" please, not "size_t". This has nothing to do with object sizes.
The loop counter will always be a small number.
> + /* At the moment, we don't have explict -mtune=future support. If the user
"At the moment" is out of date almost as soon as you write it. It is
better to avoid such terms ;-)
> + explicitly tried to use -mtune=future, give a warning. If not, use the
> + power10 tuning until future tuning is added. */
There should be Power11 tuning now, please use that?
So please post this -- as a separate series, and not as a single patch --
after fixing the things Ke Wen pointed out. Thanks!
Segher
Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]
> On 8 Feb 2024, at 19:25, Jason Merrill wrote: > > On 2/8/24 12:51, Iain Sandoe wrote: >>> On 8 Feb 2024, at 17:16, Jason Merrill wrote: >>> >>> On 2/8/24 12:12, Jason Merrill wrote: On 2/8/24 10:04, Iain Sandoe wrote: > Hi Jason, > > I have tested this on modern Darwin (with libc++ as the system library) > and on > older Darwin, where we do see the issue - because the system linker is > written > in C++ and links with libstdc++ (so sometimes we get a crash, or worse > unpredictable > beahviour). Thank you! > - > > For modern Darwin [ > macOS 10.11] , there’s no issue seen so far, but > for older Darwin…. > >> On 8 Feb 2024, at 05:36, Alexandre Oliva wrote: >> >> On Feb 6, 2024, Jason Merrill wrote: >> >>> Reverting that hunk of the change fixed my problem with bubblestrapping >>> GCC >>> 12 with ccache on a host with a newer system libstdc++. >> >> Did you have libcc1, gnattools and gotools enabled in your testing? > > … I have done all but “go” since that’s not supported on Darwin. > > The patch breaks bootstrap on older Darwin because: > >Ada uses exceptions. >gnat1 pulls in system libraries that link with the system unwinder >- so we have to link gnat1 “-shared-libgcc” >- which means we need to be able to find the just-built one when > building the target libs. Hmm. In stage 1, when we build with the system gcc, I'd think we want the just-built gnat1 to find the system libgcc. In stage 2, when we build with the stage 1 gcc, we want the just-built gnat1 to find the stage 1 libgcc. In neither case do we want it to find the libgcc from the current stage. So it seems to me that what we want is for stage2+ LD_LIBRARY_PATH to include the TARGET_LIB_PATH from the previous stage. Something like the below, on top of the earlier patch. Does this make sense? >> Yes in terms of me mixing up “just built” and “prev-*“ > > I've been unclear about that myself. > >> However, IIUC this still means we’re adding LD_LIBRARY_PATHs for each target >> library, including libstdc++ (so I’m not sure if it solves the problem that >> I’d seen before). > > Yes, after stage 1. > > You're right that we won't need all of the stage1 target libraries to run the > stage2 compiler. But if your gnat1 is linked with shared libgcc, isn't also > linked with shared libstdc++, so it would need to find the stage1 libstdc++? No, we continue to link with -static-libstdc++ (the only reason we use shared libgcc is to avoid two unwinders in the same process, which never ends well - usually gnat1 hangs) > In general, though, it would make sense to decide whether to include both > libgcc and libstdc++ based on with_static_shared_libraries. And likewise the > other language runtimes (libada, libgfortran, ...)? Right now, AFAIK the only target runtimes used by host tools are libstdc++, libgcc and libgnat. I agree that might change with rust - since the rust folks are talking about using one of the runtimes in the FE, I am not aware of other language FEs requiring their targte runtimes to be available to the host tools (adding Gaius in case I missed something with m2 - which is quite complex inthe bootstrapping). linking these shared would seem to me to be placing additional constraints on the build that are likely to take some shaking down - personally, I much prefer a toolchain with no shared deps - since then one knows what was tested is not going to change in reponse to some DSO update. > We probably don't need libgomp/libatomic/libitm? unless/until we have multiple threads in the compiler(s), it seems unlikely, indeed > libsanitizer/vtv/ssp should only be needed for a bootstrap using those > hardening options. Ah, now in that case we probably _do_ need to force shared libstdc++ (since the sanitizers link against c++ lib) - an alternative is to force all of libstdc++.a to be included in the host tools, and use that to provide the symbols, > If your stage2 gnat1 does need the stage1 libstdc++ and you're also using the > system ld that needs the system libstdc++, that seems to call for another > approach discussed on the PR: have exec-tool.in splice out the build > directory from LD_LIBRARY_PATH when calling a tool from outside the build > directory. I’ve done all sorts of dances with this - e.g. linking the ld with a specially-named libstdc++ (or forcing the linker to be statically linked - although that creates a secondary problem since the Darwin libLTO (for clang) is also linked against c++) Iain > > Jason
Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]
On 2/8/24 12:51, Iain Sandoe wrote: On 8 Feb 2024, at 17:16, Jason Merrill wrote: On 2/8/24 12:12, Jason Merrill wrote: On 2/8/24 10:04, Iain Sandoe wrote: Hi Jason, I have tested this on modern Darwin (with libc++ as the system library) and on older Darwin, where we do see the issue - because the system linker is written in C++ and links with libstdc++ (so sometimes we get a crash, or worse unpredictable beahviour). Thank you! - For modern Darwin [ > macOS 10.11] , there’s no issue seen so far, but for older Darwin…. On 8 Feb 2024, at 05:36, Alexandre Oliva wrote: On Feb 6, 2024, Jason Merrill wrote: Reverting that hunk of the change fixed my problem with bubblestrapping GCC 12 with ccache on a host with a newer system libstdc++. Did you have libcc1, gnattools and gotools enabled in your testing? … I have done all but “go” since that’s not supported on Darwin. The patch breaks bootstrap on older Darwin because: Ada uses exceptions. gnat1 pulls in system libraries that link with the system unwinder - so we have to link gnat1 “-shared-libgcc” - which means we need to be able to find the just-built one when building the target libs. Hmm. In stage 1, when we build with the system gcc, I'd think we want the just-built gnat1 to find the system libgcc. In stage 2, when we build with the stage 1 gcc, we want the just-built gnat1 to find the stage 1 libgcc. In neither case do we want it to find the libgcc from the current stage. So it seems to me that what we want is for stage2+ LD_LIBRARY_PATH to include the TARGET_LIB_PATH from the previous stage. Something like the below, on top of the earlier patch. Does this make sense? Yes in terms of me mixing up “just built” and “prev-*“ I've been unclear about that myself. However, IIUC this still means we’re adding LD_LIBRARY_PATHs for each target library, including libstdc++ (so I’m not sure if it solves the problem that I’d seen before). Yes, after stage 1. You're right that we won't need all of the stage1 target libraries to run the stage2 compiler. But if your gnat1 is linked with shared libgcc, isn't also linked with shared libstdc++, so it would need to find the stage1 libstdc++? In general, though, it would make sense to decide whether to include both libgcc and libstdc++ based on with_static_shared_libraries. And likewise the other language runtimes (libada, libgfortran, ...)? We probably don't need libgomp/libatomic/libitm? libsanitizer/vtv/ssp should only be needed for a bootstrap using those hardening options. If your stage2 gnat1 does need the stage1 libstdc++ and you're also using the system ld that needs the system libstdc++, that seems to call for another approach discussed on the PR: have exec-tool.in splice out the build directory from LD_LIBRARY_PATH when calling a tool from outside the build directory. Jason
Re: Repost [PATCH 1/6] Add -mcpu=future
On Wed, Feb 07, 2024 at 05:21:10PM +0800, Kewen.Lin wrote: > on 2024/2/6 14:01, Michael Meissner wrote: > > It was more as a separation. The MPCCORE, CELL, PPCA2, and TITAN are rather > > old processors. I'll probably remove Titan soonish, btw. We have adjusted code around it for what, fifteen years? But the hardware never materialized. There are more silly things in our backend, but this one takes the prize. > OK, considering we only get this warning once for a simple case, I'm inclined > not to keep a static variable for it, it's the same as what we do currently > for option conflict errors emission. But I'm fine for either. Whatever is easiest. Segher
Re: Repost [PATCH 1/6] Add -mcpu=future
On Tue, Feb 06, 2024 at 01:01:52AM -0500, Michael Meissner wrote: > > Nit: Named as "ISA_FUTURE_MASKS_SERVER" seems more accurate as it's > > constituted > > with ISA_3_1_MASKS_**SERVER** ... > > Well the _SERVER stuff was due to the power7 days when we still had to support > the E500 in the main rs6000 tree. But I will change it to be more consistant > in the future patches. "_SERVER" still is a good shortish name for the server systems ;-) > > > @@ -67,7 +67,9 @@ enum processor_type > > > PROCESSOR_MPCCORE, > > > PROCESSOR_CELL, > > > PROCESSOR_PPCA2, > > > - PROCESSOR_TITAN > > > + PROCESSOR_TITAN, > > > + > > > > Nit: unintentional empty line? > > > > > + PROCESSOR_FUTURE > > > }; > > It was more as a separation. The MPCCORE, CELL, PPCA2, and TITAN are rather > old processors. I don't recall why we kept them after the POWER. Please don't add random separations. > Logically we should re-order the list and move MPCCORE, etc. earlier, but I > will delete the blank line in future patches. Don't randomly reorder, either. _FUTURE should be added after POWER11. > > I think we should also update asm_names in driver-rs6000.cc. > > Ok. Though the driver-rs6000.cc stuff won't kick in until we have a real > system that matches "future". Or when during development you have that faked. You did test it, right? :-) Segher
Re: Repost [PATCH 0/6] PowerPC Future patches
Hi! On Fri, Jan 05, 2024 at 06:27:05PM -0500, Michael Meissner wrote: > In the current MMA subsystem for Power10, there are 8 512-bit accumulator > registers. These accumulators are each tied to sets of 4 FPR registers. When Four VSX registers -- the FP registers are only a 64 bit part of each of those. Please do not call those VSX registers "FPRs". They are not. > These patches add support for the 512-bit accumulators within the dense math > system, and for allocation of the 1,024-bit DMRs. At this time, no additional > built-in functions will be done to support any dense math features other than > doing data movement between the DMRs and the VSX registers. Before we can > look > at adding any new dense math support other than data movement, we need the GCC > compiler to be able to allocate and use these DMRs. Okido. > If you compile with -mcpu=power10, the wD constraint will match the equivalent > FPR register that overlaps with the accumulator. If you compile with > -mcpu=future, the wD constraint will match the DMR register and not the FPR > register. > > These patches also modifies the print_operand %A output modifier to print out > DMR register numbers if -mcpu=future, and continue to print out the FPR > register number divided by 4 for -mcpu=power10. Yup. Unfortunately that is the best we can do probably. It _feels_ fragile, but it wil probably be okay in practice. > Going forward, hopefully if you modify your code to use the wD constraint and > %A output modifier, you can write code that switches more easily between the > two systems. But it will never become completely transparent. Luckily the old thing will over time fade into the background. So, please post the -mcpu=future patches in a separate series, first. I'll comment on that patch in a minute, you'll probably want to take those comments into consideration before posting that series ;-) Segher
Re: [Committed] RISC-V: Fix rvv intrinsic pragma tests dejagnu selector
Committed
On 1/30/2024 9:51 AM, Palmer Dabbelt wrote:
On Mon, 29 Jan 2024 11:38:12 PST (-0800), e...@rivosinc.com wrote:
Adding rvv related flags (i.e. --param=riscv-autovec-preference) to
non vector targets bypassed the dejagnu skip test directive. Change the
target selector to skip if rvv is enabled
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/abi-1.c: change selector
* gcc.target/riscv/rvv/base/pragma-2.c: ditto
* gcc.target/riscv/rvv/base/pragma-3.c: ditto
Signed-off-by: Edwin Lu
---
gcc/testsuite/gcc.target/riscv/rvv/base/abi-1.c | 2 +-
gcc/testsuite/gcc.target/riscv/rvv/base/pragma-2.c | 2 +-
gcc/testsuite/gcc.target/riscv/rvv/base/pragma-3.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/abi-1.c
b/gcc/testsuite/gcc.target/riscv/rvv/base/abi-1.c
index 2eef9e1e1a8..a072bdd47bf 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/abi-1.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/abi-1.c
@@ -1,5 +1,5 @@
/* { dg-do compile { target { ! riscv_xtheadvector } } } */
-/* { dg-skip-if "test rvv intrinsic" { *-*-* } { "*" } {
"-march=rv*v*" } } */
+/* { dg-skip-if "test rvv intrinsic" { ! riscv_v } } */
void foo0 () {__rvv_bool64_t t;}
void foo1 () {__rvv_bool32_t t;}
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-2.c
b/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-2.c
index fd2aa3066cd..fc1bb13c53d 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-2.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-2.c
@@ -1,4 +1,4 @@
/* { dg-do compile } */
-/* { dg-skip-if "test rvv intrinsic" { *-*-* } { "*" } {
"-march=rv*v*" } } */
+/* { dg-skip-if "test rvv intrinsic" { ! riscv_v } } */
#pragma riscv intrinsic "vector"
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-3.c
b/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-3.c
index 96a0e051a29..45580bb2faa 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-3.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pragma-3.c
@@ -1,4 +1,4 @@
/* { dg-do compile } */
-/* { dg-skip-if "test rvv intrinsic" { *-*-* } { "*" } {
"-march=rv*v*" } } */
+/* { dg-skip-if "test rvv intrinsic" { ! riscv_v } */
#pragma riscv intrinsic "report-error" /* { dg-error {unknown
'#pragma riscv intrinsic' option 'report-error'} } */
Reviewed-by: Palmer Dabbelt
Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]
On 2/8/24 18:16, Jason Merrill wrote: Hmm. In stage 1, when we build with the system gcc, I'd think we want the just-built gnat1 to find the system libgcc. In stage 2, when we build with the stage 1 gcc, we want the just-built gnat1 to find the stage 1 libgcc. In neither case do we want it to find the libgcc from the current stage. So it seems to me that what we want is for stage2+ LD_LIBRARY_PATH to include the TARGET_LIB_PATH from the previous stage. Something like the below, on top of the earlier patch. Does this make sense? Does it work on Darwin? Oops, that was broken, please consider this one instead: Yes, this one makes sense (and the current code would not work since it lacks the prev- prefix on TARGET_LIB_PATH). Paolo
Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]
> On 8 Feb 2024, at 17:16, Jason Merrill wrote: > > On 2/8/24 12:12, Jason Merrill wrote: >> On 2/8/24 10:04, Iain Sandoe wrote: >>> Hi Jason, >>> >>> I have tested this on modern Darwin (with libc++ as the system library) and >>> on >>> older Darwin, where we do see the issue - because the system linker is >>> written >>> in C++ and links with libstdc++ (so sometimes we get a crash, or worse >>> unpredictable >>> beahviour). >> Thank you! >>> - >>> >>> For modern Darwin [ > macOS 10.11] , there’s no issue seen so far, but for >>> older Darwin…. >>> On 8 Feb 2024, at 05:36, Alexandre Oliva wrote: On Feb 6, 2024, Jason Merrill wrote: > Reverting that hunk of the change fixed my problem with bubblestrapping > GCC > 12 with ccache on a host with a newer system libstdc++. Did you have libcc1, gnattools and gotools enabled in your testing? >>> >>> … I have done all but “go” since that’s not supported on Darwin. >>> >>> The patch breaks bootstrap on older Darwin because: >>> >>>Ada uses exceptions. >>>gnat1 pulls in system libraries that link with the system unwinder >>>- so we have to link gnat1 “-shared-libgcc” >>>- which means we need to be able to find the just-built one when >>> building the target libs. >> Hmm. In stage 1, when we build with the system gcc, I'd think we want the >> just-built gnat1 to find the system libgcc. >> In stage 2, when we build with the stage 1 gcc, we want the just-built gnat1 >> to find the stage 1 libgcc. >> In neither case do we want it to find the libgcc from the current stage. >> So it seems to me that what we want is for stage2+ LD_LIBRARY_PATH to >> include the TARGET_LIB_PATH from the previous stage. Something like the >> below, on top of the earlier patch. >> Does this make sense? Yes in terms of me mixing up “just built” and “prev-*“ However, IIUC this still means we’re adding LD_LIBRARY_PATHs for each target library, including libstdc++ (so I’m not sure if it solves the problem that I’d seen before). I can see we need to add any paths to shared libraries used by the host tools (so that, perhaps, we’ll need to add libgrust if the rust FE uses that) but, otherwise AFAIK, the only [shared] target library used by the host tools is libgcc_s (when gnat1 needs it) - otherwise we default to static linking of libstdc++ and libgcc (and the gnat* tools link libgnat statically too) ? >> Does it work on Darwin? I’ll kick off a run shortly - know later this evening. Iain > > Oops, that was broken, please consider this one instead: > > <0001-build-add-prev-target-libs-to-rpath.patch>
[PATCH v2] testsuite: Pattern does not match when using --specs=nano.specs
Changes since v1:
- Replaced .* with [^\r\n]* to avoid matching newline.
Ok for trunk and releases/gcc-13?
--
When running the testsuite for newlib nano, the --specs=nano.specs
option is used. This option prepends cpp_unique_options with
"-isystem =/include/newlib-nano" so that the newlib nano header files
override the newlib standard ones. As the -isystem option is prepended,
the -quiet option is no longer the first option to cc1. Adjust the test
accordingly.
Patch has been verified on Windows and Linux.
gcc/testsuite/ChangeLog:
* gcc.misc-tests/options.exp: Allow other options before the
-quite option for cc1.
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/gcc.misc-tests/options.exp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.misc-tests/options.exp
b/gcc/testsuite/gcc.misc-tests/options.exp
index ec026ecf77d..6e6e40c183d 100644
--- a/gcc/testsuite/gcc.misc-tests/options.exp
+++ b/gcc/testsuite/gcc.misc-tests/options.exp
@@ -57,7 +57,7 @@ proc check_for_all_options {language gcc_options
compiler_pattern as_pattern ld_
remote_file build delete $dumpfile
}
-if {![regexp -- "/${compiler}(\\.exe)? -quiet.*$compiler_pattern"
$gcc_output]} {
+if {![regexp -- "/${compiler}(\\.exe)?
\[^\r\n\]*-quiet.*$compiler_pattern" $gcc_output]} {
fail "$test (compiler options)"
return
}
--
2.25.1
Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]
On 2/8/24 12:12, Jason Merrill wrote: On 2/8/24 10:04, Iain Sandoe wrote: Hi Jason, I have tested this on modern Darwin (with libc++ as the system library) and on older Darwin, where we do see the issue - because the system linker is written in C++ and links with libstdc++ (so sometimes we get a crash, or worse unpredictable beahviour). Thank you! - For modern Darwin [ > macOS 10.11] , there’s no issue seen so far, but for older Darwin…. On 8 Feb 2024, at 05:36, Alexandre Oliva wrote: On Feb 6, 2024, Jason Merrill wrote: Reverting that hunk of the change fixed my problem with bubblestrapping GCC 12 with ccache on a host with a newer system libstdc++. Did you have libcc1, gnattools and gotools enabled in your testing? … I have done all but “go” since that’s not supported on Darwin. The patch breaks bootstrap on older Darwin because: Ada uses exceptions. gnat1 pulls in system libraries that link with the system unwinder - so we have to link gnat1 “-shared-libgcc” - which means we need to be able to find the just-built one when building the target libs. Hmm. In stage 1, when we build with the system gcc, I'd think we want the just-built gnat1 to find the system libgcc. In stage 2, when we build with the stage 1 gcc, we want the just-built gnat1 to find the stage 1 libgcc. In neither case do we want it to find the libgcc from the current stage. So it seems to me that what we want is for stage2+ LD_LIBRARY_PATH to include the TARGET_LIB_PATH from the previous stage. Something like the below, on top of the earlier patch. Does this make sense? Does it work on Darwin? Oops, that was broken, please consider this one instead: From 4c9558e7f82f95fb7583892c18401bc2ba98ec4d Mon Sep 17 00:00:00 2001 From: Jason Merrill Date: Thu, 8 Feb 2024 11:58:11 -0500 Subject: [PATCH] build: add prev target libs to rpath To: gcc-patches@gcc.gnu.org ChangeLog: * Makefile.tpl (POSTSTAGE1_HOST_EXPORTS): Add TARGET_PREV_LIB_PATH to RPATH_ENVVAR. * Makefile.in: Regenerate. --- Makefile.in | 14 +- Makefile.tpl | 8 +++- 2 files changed, 20 insertions(+), 2 deletions(-) diff --git a/Makefile.in b/Makefile.in index c2843d5df89..4b168cb2087 100644 --- a/Makefile.in +++ b/Makefile.in @@ -266,6 +266,7 @@ POSTSTAGE1_CXX_EXPORT = \ # Similar, for later GCC stages. POSTSTAGE1_HOST_EXPORTS = \ $(HOST_EXPORTS) \ + $(RPATH_ENVVAR)=`echo "$(TARGET_PREV_LIB_PATH)$$$(RPATH_ENVVAR)" | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \ CC="$(STAGE_CC_WRAPPER) $$r/$(HOST_SUBDIR)/prev-gcc/xgcc$(exeext) \ -B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ \ $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CC; \ @@ -727,41 +728,51 @@ all: # This is the list of directories that may be needed in RPATH_ENVVAR # so that programs built for the target machine work. TARGET_LIB_PATH = $(TARGET_LIB_PATH_libstdc++-v3)$(TARGET_LIB_PATH_libsanitizer)$(TARGET_LIB_PATH_libvtv)$(TARGET_LIB_PATH_libssp)$(TARGET_LIB_PATH_libphobos)$(TARGET_LIB_PATH_libgm2)$(TARGET_LIB_PATH_libgomp)$(TARGET_LIB_PATH_libitm)$(TARGET_LIB_PATH_libatomic)$(HOST_LIB_PATH_gcc) +TARGET_PREV_LIB_PATH = $(TARGET_PREV_LIB_PATH_libstdc++-v3)$(TARGET_PREV_LIB_PATH_libsanitizer)$(TARGET_PREV_LIB_PATH_libvtv)$(TARGET_PREV_LIB_PATH_libssp)$(TARGET_PREV_LIB_PATH_libphobos)$(TARGET_PREV_LIB_PATH_libgm2)$(TARGET_PREV_LIB_PATH_libgomp)$(TARGET_PREV_LIB_PATH_libitm)$(TARGET_PREV_LIB_PATH_libatomic)$(HOST_PREV_LIB_PATH_gcc) @if target-libstdc++-v3 TARGET_LIB_PATH_libstdc++-v3 = $$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs: +TARGET_PREV_LIB_PATH_libstdc++-v3 = $$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs: @endif target-libstdc++-v3 @if target-libsanitizer TARGET_LIB_PATH_libsanitizer = $$r/$(TARGET_SUBDIR)/libsanitizer/.libs: +TARGET_PREV_LIB_PATH_libsanitizer = $$r/prev-$(TARGET_SUBDIR)/libsanitizer/.libs: @endif target-libsanitizer @if target-libvtv TARGET_LIB_PATH_libvtv = $$r/$(TARGET_SUBDIR)/libvtv/.libs: +TARGET_PREV_LIB_PATH_libvtv = $$r/prev-$(TARGET_SUBDIR)/libvtv/.libs: @endif target-libvtv @if target-libssp TARGET_LIB_PATH_libssp = $$r/$(TARGET_SUBDIR)/libssp/.libs: +TARGET_PREV_LIB_PATH_libssp = $$r/prev-$(TARGET_SUBDIR)/libssp/.libs: @endif target-libssp @if target-libphobos TARGET_LIB_PATH_libphobos = $$r/$(TARGET_SUBDIR)/libphobos/src/.libs: +TARGET_PREV_LIB_PATH_libphobos = $$r/prev-$(TARGET_SUBDIR)/libphobos/src/.libs: @endif target-libphobos @if target-libgm2 TARGET_LIB_PATH_libgm2 = $$r/$(TARGET_SUBDIR)/libgm2/.libs: +TARGET_PREV_LIB_PATH_libgm2 = $$r/prev-$(TARGET_SUBDIR)/libgm2/.libs: @endif target-libgm2 @if target-libgomp TARGET_LIB_PATH_libgomp = $$r/$(TARGET_SUBDIR)/libgomp/.libs: +TARGET_PREV_LIB_PATH_libgomp = $$r/prev-$(TARGET_SUBDIR)/libgomp/.libs: @endif target-libgomp @if target-libitm TARGET_LIB_PATH_libitm = $$r/$(TARGET_SUBDIR)/libitm/.libs: +TARGET_PREV_LIB_PATH_libitm = $$r/prev-$(TARGET_SUBDIR)/libitm/.libs: @endif
Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]
On 2/8/24 10:04, Iain Sandoe wrote: Hi Jason, I have tested this on modern Darwin (with libc++ as the system library) and on older Darwin, where we do see the issue - because the system linker is written in C++ and links with libstdc++ (so sometimes we get a crash, or worse unpredictable beahviour). Thank you! - For modern Darwin [ > macOS 10.11] , there’s no issue seen so far, but for older Darwin…. On 8 Feb 2024, at 05:36, Alexandre Oliva wrote: On Feb 6, 2024, Jason Merrill wrote: Reverting that hunk of the change fixed my problem with bubblestrapping GCC 12 with ccache on a host with a newer system libstdc++. Did you have libcc1, gnattools and gotools enabled in your testing? … I have done all but “go” since that’s not supported on Darwin. The patch breaks bootstrap on older Darwin because: Ada uses exceptions. gnat1 pulls in system libraries that link with the system unwinder - so we have to link gnat1 “-shared-libgcc” - which means we need to be able to find the just-built one when building the target libs. Hmm. In stage 1, when we build with the system gcc, I'd think we want the just-built gnat1 to find the system libgcc. In stage 2, when we build with the stage 1 gcc, we want the just-built gnat1 to find the stage 1 libgcc. In neither case do we want it to find the libgcc from the current stage. So it seems to me that what we want is for stage2+ LD_LIBRARY_PATH to include the TARGET_LIB_PATH from the previous stage. Something like the below, on top of the earlier patch. Does this make sense? Does it work on Darwin? From 1115afdce16742003030599aab327daaf9db5073 Mon Sep 17 00:00:00 2001 From: Jason Merrill Date: Thu, 8 Feb 2024 11:58:11 -0500 Subject: [PATCH] build: add prev target libs to rpath To: gcc-patches@gcc.gnu.org ChangeLog: * Makefile.tpl (POSTSTAGE1_HOST_EXPORTS): Add TARGET_PREV_LIB_PATH to RPATH_ENVVAR. * Makefile.in: Regenerate. --- Makefile.in | 14 +- Makefile.tpl | 10 +- 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/Makefile.in b/Makefile.in index c2843d5df89..31737cba37f 100644 --- a/Makefile.in +++ b/Makefile.in @@ -266,6 +266,7 @@ POSTSTAGE1_CXX_EXPORT = \ # Similar, for later GCC stages. POSTSTAGE1_HOST_EXPORTS = \ $(HOST_EXPORTS) \ + $(RPATH_ENVVAR)=`echo "$(TARGET_PREV_LIB_PATH)$$$(RPATH_ENVVAR)" | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \ CC="$(STAGE_CC_WRAPPER) $$r/$(HOST_SUBDIR)/prev-gcc/xgcc$(exeext) \ -B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ \ $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CC; \ @@ -727,41 +728,51 @@ all: # This is the list of directories that may be needed in RPATH_ENVVAR # so that programs built for the target machine work. TARGET_LIB_PATH = $(TARGET_LIB_PATH_libstdc++-v3)$(TARGET_LIB_PATH_libsanitizer)$(TARGET_LIB_PATH_libvtv)$(TARGET_LIB_PATH_libssp)$(TARGET_LIB_PATH_libphobos)$(TARGET_LIB_PATH_libgm2)$(TARGET_LIB_PATH_libgomp)$(TARGET_LIB_PATH_libitm)$(TARGET_LIB_PATH_libatomic)$(HOST_LIB_PATH_gcc) +TARGET_PREV_LIB_PATH = $(TARGET_PREV_LIB_PATH_libstdc++-v3)$(TARGET_PREV_LIB_PATH_libsanitizer)$(TARGET_PREV_LIB_PATH_libvtv)$(TARGET_PREV_LIB_PATH_libssp)$(TARGET_PREV_LIB_PATH_libphobos)$(TARGET_PREV_LIB_PATH_libgm2)$(TARGET_PREV_LIB_PATH_libgomp)$(TARGET_PREV_LIB_PATH_libitm)$(TARGET_PREV_LIB_PATH_libatomic)$(HOST_PREV_LIB_PATH_gcc) @if target-libstdc++-v3 TARGET_LIB_PATH_libstdc++-v3 = $$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs: +TARGET_PREV_LIB_PATH_libstdc++-v3 = $$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs: @endif target-libstdc++-v3 @if target-libsanitizer TARGET_LIB_PATH_libsanitizer = $$r/$(TARGET_SUBDIR)/libsanitizer/.libs: +TARGET_PREV_LIB_PATH_libsanitizer = $$r/prev-$(TARGET_SUBDIR)/libsanitizer/.libs: @endif target-libsanitizer @if target-libvtv TARGET_LIB_PATH_libvtv = $$r/$(TARGET_SUBDIR)/libvtv/.libs: +TARGET_PREV_LIB_PATH_libvtv = $$r/prev-$(TARGET_SUBDIR)/libvtv/.libs: @endif target-libvtv @if target-libssp TARGET_LIB_PATH_libssp = $$r/$(TARGET_SUBDIR)/libssp/.libs: +TARGET_PREV_LIB_PATH_libssp = $$r/prev-$(TARGET_SUBDIR)/libssp/.libs: @endif target-libssp @if target-libphobos TARGET_LIB_PATH_libphobos = $$r/$(TARGET_SUBDIR)/libphobos/src/.libs: +TARGET_PREV_LIB_PATH_libphobos = $$r/prev-$(TARGET_SUBDIR)/libphobos/src/.libs: @endif target-libphobos @if target-libgm2 TARGET_LIB_PATH_libgm2 = $$r/$(TARGET_SUBDIR)/libgm2/.libs: +TARGET_PREV_LIB_PATH_libgm2 = $$r/prev-$(TARGET_SUBDIR)/libgm2/.libs: @endif target-libgm2 @if target-libgomp TARGET_LIB_PATH_libgomp = $$r/$(TARGET_SUBDIR)/libgomp/.libs: +TARGET_PREV_LIB_PATH_libgomp = $$r/prev-$(TARGET_SUBDIR)/libgomp/.libs: @endif target-libgomp @if target-libitm TARGET_LIB_PATH_libitm = $$r/$(TARGET_SUBDIR)/libitm/.libs: +TARGET_PREV_LIB_PATH_libitm = $$r/prev-$(TARGET_SUBDIR)/libitm/.libs: @endif target-libitm @if target-libatomic TARGET_LIB_PATH_libatomic = $$r/$(TARGET_SUBDIR)/libatomic/.libs:
Re: [committed] libstdc++: Guard tr2::bases and tr2::direct_bases with __has_builtin
On Thu, 8 Feb 2024 at 16:02, Jonathan Wakely wrote: > Tested x86_64-linux. Pusued to trunk. I'll backport it too. > Only to gcc-13 though, because __has_builtin(__bases) is false for gcc-12.
[PATCH v2] c++: make build_throw SFINAE-friendly [PR98388]
On Thu, Feb 08, 2024 at 08:49:28AM -0500, Patrick Palka wrote:
> On Wed, 7 Feb 2024, Marek Polacek wrote:
>
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > Here the problem is that we give hard errors while substituting
> > template parameters during overload resolution of is_throwable
> > which has an invalid throw in decltype.
> >
> > The backtrace shows that fn_type_unification -> instantiate_template
> > -> tsubst* passes complain=0 as expected, but build_throw doesn't
> > have a complain parameter. So let's add one. Also remove a redundant
> > local variable which I should have removed in my P2266 patch.
> >
> > But there's still something not quite clear to me. I claim that 'b'
> > in the testcase should evaluate to false since the first overload ought
> > to have been discarded. EDG 6.6 agrees, but clang++, msvc, and icx evaluate
> > it to true. Who's right?
> >
> > Thanks to Patrick for notifying me of this PR. This doesn't fully fix
> > 113789; there I think I'll have to figure our why a candidate wasn't
> > discarded from the overload set.
> >
> > gcc/cp/ChangeLog:
> >
> > * coroutines.cc (coro_rewrite_function_body): Pass tf_warning_or_error
> > to build_throw.
> > (morph_fn_to_coro): Likewise.
> > * cp-tree.h (build_throw): Adjust.
> > * except.cc (expand_end_catch_block): Pass tf_warning_or_error to
> > build_throw.
> > (build_throw): Add a tsubst_flags_t parameter. Use it. Remove
> > redundant variable. Guard an inform call.
> > * parser.cc (cp_parser_throw_expression): Pass tf_warning_or_error
> > to build_throw.
> > * pt.cc (tsubst_expr) : Pass complain to build_throw.
> >
> > libcc1/ChangeLog:
> >
> > * libcp1plugin.cc (plugin_build_unary_expr): Pass tf_error to
> > build_throw.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/cpp0x/sfinae69.C: New test.
> > ---
> > gcc/cp/coroutines.cc | 4 ++--
> > gcc/cp/cp-tree.h | 3 ++-
> > gcc/cp/except.cc | 31 +++
> > gcc/cp/parser.cc | 2 +-
> > gcc/cp/pt.cc | 2 +-
> > gcc/testsuite/g++.dg/cpp0x/sfinae69.C | 16 ++
> > libcc1/libcp1plugin.cc| 4 ++--
> > 7 files changed, 37 insertions(+), 25 deletions(-)
> > create mode 100644 gcc/testsuite/g++.dg/cpp0x/sfinae69.C
> >
> > diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
> > index 3194c911e8c..9b037edbd14 100644
> > --- a/gcc/cp/coroutines.cc
> > +++ b/gcc/cp/coroutines.cc
> > @@ -4246,7 +4246,7 @@ coro_rewrite_function_body (location_t fn_start, tree
> > fnbody, tree orig,
> > boolean_type_node, i_a_r_c);
> >finish_if_stmt_cond (not_iarc, not_iarc_if);
> >/* If the initial await resume called value is false, rethrow... */
> > - tree rethrow = build_throw (fn_start, NULL_TREE);
> > + tree rethrow = build_throw (fn_start, NULL_TREE,
> > tf_warning_or_error);
> >suppress_warning (rethrow);
> >finish_expr_stmt (rethrow);
> >finish_then_clause (not_iarc_if);
> > @@ -5151,7 +5151,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree
> > *destroyer)
> >tree del_coro_fr = coro_get_frame_dtor (coro_fp, orig, frame_size,
> > promise_type, fn_start);
> >finish_expr_stmt (del_coro_fr);
> > - tree rethrow = build_throw (fn_start, NULL_TREE);
> > + tree rethrow = build_throw (fn_start, NULL_TREE,
> > tf_warning_or_error);
> >suppress_warning (rethrow);
> >finish_expr_stmt (rethrow);
> >finish_handler (handler);
> > diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> > index 969c7239c97..334c11396c2 100644
> > --- a/gcc/cp/cp-tree.h
> > +++ b/gcc/cp/cp-tree.h
> > @@ -7185,7 +7185,8 @@ extern void init_exception_processing (void);
> > extern tree expand_start_catch_block (tree);
> > extern void expand_end_catch_block (void);
> > extern tree build_exc_ptr (void);
> > -extern tree build_throw(location_t, tree);
> > +extern tree build_throw(location_t, tree,
> > +tsubst_flags_t);
> > extern int nothrow_libfn_p (const_tree);
> > extern void check_handlers (tree);
> > extern tree finish_noexcept_expr (tree, tsubst_flags_t);
> > diff --git a/gcc/cp/except.cc b/gcc/cp/except.cc
> > index d17a57d3fbc..ed704b6c28a 100644
> > --- a/gcc/cp/except.cc
> > +++ b/gcc/cp/except.cc
> > @@ -486,7 +486,8 @@ expand_end_catch_block (void)
> > || DECL_DESTRUCTOR_P (current_function_decl))
> >&& !in_nested_catch ())
> > {
> > - tree rethrow = build_throw (input_location, NULL_TREE);
> > + tree rethrow = build_throw (input_location, NULL_TREE,
> > +
Re: [PATCH] c++: Don't ICE for unknown parameter to constexpr'd switch-statement, PR113545
> Date: Thu, 8 Feb 2024 11:22:47 -0500 > From: Marek Polacek > I'm confused; are you planning to use the dg-ice directive I invented > some years ago? Please, let's keep the discussion about the test-cases in that thread. brgds, H-P
Re: [PATCH] c++: Don't ICE for unknown parameter to constexpr'd switch-statement, PR113545
On Thu, Feb 08, 2024 at 05:07:21PM +0100, Hans-Peter Nilsson wrote:
> > Date: Thu, 8 Feb 2024 10:44:31 -0500
> > From: Marek Polacek
> > Cc: ja...@redhat.com, gcc-patches@gcc.gnu.org
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> >
> > On Thu, Feb 08, 2024 at 04:40:40PM +0100, Hans-Peter Nilsson wrote:
> > > > Date: Wed, 7 Feb 2024 21:11:59 -0500
> > > > From: Marek Polacek
> > >
> > > > On Wed, Feb 07, 2024 at 04:32:57PM -0500, Jason Merrill wrote:
> > > > > On 2/6/24 19:23, Hans-Peter Nilsson wrote:
> > > > > > > Date: Mon, 22 Jan 2024 14:33:59 -0500
> > > > > > > From: Marek Polacek
> > > > > >
> > > > > > > On Mon, Jan 22, 2024 at 06:02:32PM +0100, Hans-Peter Nilsson
> > > > > > > wrote:
> > > > > > > > I don't really know whether this is the right way to treat
> > > > > > > > CONVERT_EXPR as below, but... Regtested native
> > > > > > > > x86_64-linux-gnu. Ok to commit?
> > > > > > >
> > > > > > > Thanks for taking a look at this problem.
> > > > > >
> > > > > > Thanks for the initial review.
> > >
> > > > > Incidentally, these testcases seem to require C++14; you can't have a
> > > > > switch
> > > > > in a constexpr function in C++11.
> > > > >
> > > > > Jason
> > > >
> > > > > diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
> > > > > index 2ebb1470dd5..fa346fe01c9 100644
> > > > > --- a/gcc/cp/constexpr.cc
> > > > > +++ b/gcc/cp/constexpr.cc
> > > > > @@ -7106,6 +7106,16 @@ cxx_eval_switch_expr (const constexpr_ctx
> > > > > *ctx, tree t,
> > > > >cond = cxx_eval_constant_expression (ctx, cond, vc_prvalue,
> > > > > non_constant_p, overflow_p);
> > > > >VERIFY_CONSTANT (cond);
> > > > > + if (TREE_CODE (cond) != INTEGER_CST)
> > > > > +{
> > > > > + /* If the condition doesn't reduce to an INTEGER_CST it isn't
> > > > > a usable
> > > > > + switch condition even if it's constant enough for other things
> > > > > + (c++/113545). */
> > > > > + gcc_checking_assert (ctx->quiet);
> > > > > + *non_constant_p = true;
> > > > > + return t;
> > > > > +}
> > > > > +
> > > > >*jump_target = cond;
> > > > >
> > > > >tree body
> > > >
> > > > The patch makes sense to me, although I'm afraid that losing the
> > > > REINTERPRET_CAST_P flag will cause other issues.
> > > >
> > > > HP, sorry that I never got back to you. I would be more than happy to
> > > > take the patch above, add some tests and test/bootstrap it, unless you
> > > > want to do that yourself.
> > > >
> > > > Thanks & sorry again,
> > >
> > > No worries, feel very welcome to deal with handling the
> > > actual fix. Also, you're better prepared than me, when it
> > > comes to dealing with any possible fallout. :)
> > >
> > > I'll send an updated version of the test-cases, moving them
> > > to the C++14 test directory (cpp1y, right?) and qualify them
> > > as c++14 instead, as Jason pointed out.
> >
> > Right, cpp1y is c++14. Note that we wouldn't push the tests separately
> > to the patch itself, unless it's something that already works. Thanks,
> >
> > Marek
>
> But, the tests work. They passes as-is, as they track the
> ICE, but will XPASS (that part) once a fix is committed (at
> which time: "I checked that these behave as expected (xfail
> as ICE properly) without the previosly posted patch to
> cp/constexpr.cc and XPASS with it applied."
I'm confused; are you planning to use the dg-ice directive I invented
some years ago? I wanted to encourage people to add tests for
old unfixed PRs so that if a fix fixes an (un)related older problem, we
know it before pushing the patch.
(I don't think an XFAIL will work for an ICE -- that prompted dg-ice.)
> Once the fix works, the xfail for the ICE should be removed.
> (Hm, better comment on the patches in a reply to that message. :)
>
> The point is that for this type of bug it's useful to have a
> test-case tracking it, before a fix is committed.
I'd tend to agree but here we already have a fix, so one commit seems
better than multiple commits. But if that's what you want to do, I
guess I'm not going to stand in your way.
Marek
Re: [PATCH] Revert "Pass GUILE down to subdirectories"
On Thu, Feb 8, 2024 at 11:10 AM Andrew Burgess wrote: > > Christian Biesinger writes: > > > On Mon, Jan 22, 2024 at 7:21 PM Tom Tromey wrote: > > > >> This reverts commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f. > >> > >> This patch caused problems for some users when building gdb, because > >> it would cause 'guild' to be invoked with the wrong versin of guile. > >> > > > > Is "guild" here a typo? (I don't see a "guild" binary when installing > > guile-3.0) > > guild is the guile compiler. There's certainly a guild binary with > 3.02 and 3.0.9, as well as every 2.x I've checked. What version exactly > are you using? Oh, that was my mistake, I installed guile-3.0 which does not contain guild but guile-3.0-dev does contain it. (Debian) Christian
Re: [PATCH] Revert "Pass GUILE down to subdirectories"
Christian Biesinger writes: > On Mon, Jan 22, 2024 at 7:21 PM Tom Tromey wrote: > >> This reverts commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f. >> >> This patch caused problems for some users when building gdb, because >> it would cause 'guild' to be invoked with the wrong versin of guile. >> > > Is "guild" here a typo? (I don't see a "guild" binary when installing > guile-3.0) guild is the guile compiler. There's certainly a guild binary with 3.02 and 3.0.9, as well as every 2.x I've checked. What version exactly are you using? Thanks, Andrew
Re: [PATCH] c++: Don't ICE for unknown parameter to constexpr'd switch-statement, PR113545
> Date: Thu, 8 Feb 2024 10:44:31 -0500
> From: Marek Polacek
> Cc: ja...@redhat.com, gcc-patches@gcc.gnu.org
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Thu, Feb 08, 2024 at 04:40:40PM +0100, Hans-Peter Nilsson wrote:
> > > Date: Wed, 7 Feb 2024 21:11:59 -0500
> > > From: Marek Polacek
> >
> > > On Wed, Feb 07, 2024 at 04:32:57PM -0500, Jason Merrill wrote:
> > > > On 2/6/24 19:23, Hans-Peter Nilsson wrote:
> > > > > > Date: Mon, 22 Jan 2024 14:33:59 -0500
> > > > > > From: Marek Polacek
> > > > >
> > > > > > On Mon, Jan 22, 2024 at 06:02:32PM +0100, Hans-Peter Nilsson wrote:
> > > > > > > I don't really know whether this is the right way to treat
> > > > > > > CONVERT_EXPR as below, but... Regtested native
> > > > > > > x86_64-linux-gnu. Ok to commit?
> > > > > >
> > > > > > Thanks for taking a look at this problem.
> > > > >
> > > > > Thanks for the initial review.
> >
> > > > Incidentally, these testcases seem to require C++14; you can't have a
> > > > switch
> > > > in a constexpr function in C++11.
> > > >
> > > > Jason
> > >
> > > > diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
> > > > index 2ebb1470dd5..fa346fe01c9 100644
> > > > --- a/gcc/cp/constexpr.cc
> > > > +++ b/gcc/cp/constexpr.cc
> > > > @@ -7106,6 +7106,16 @@ cxx_eval_switch_expr (const constexpr_ctx *ctx,
> > > > tree t,
> > > >cond = cxx_eval_constant_expression (ctx, cond, vc_prvalue,
> > > >non_constant_p, overflow_p);
> > > >VERIFY_CONSTANT (cond);
> > > > + if (TREE_CODE (cond) != INTEGER_CST)
> > > > +{
> > > > + /* If the condition doesn't reduce to an INTEGER_CST it isn't a
> > > > usable
> > > > +switch condition even if it's constant enough for other things
> > > > +(c++/113545). */
> > > > + gcc_checking_assert (ctx->quiet);
> > > > + *non_constant_p = true;
> > > > + return t;
> > > > +}
> > > > +
> > > >*jump_target = cond;
> > > >
> > > >tree body
> > >
> > > The patch makes sense to me, although I'm afraid that losing the
> > > REINTERPRET_CAST_P flag will cause other issues.
> > >
> > > HP, sorry that I never got back to you. I would be more than happy to
> > > take the patch above, add some tests and test/bootstrap it, unless you
> > > want to do that yourself.
> > >
> > > Thanks & sorry again,
> >
> > No worries, feel very welcome to deal with handling the
> > actual fix. Also, you're better prepared than me, when it
> > comes to dealing with any possible fallout. :)
> >
> > I'll send an updated version of the test-cases, moving them
> > to the C++14 test directory (cpp1y, right?) and qualify them
> > as c++14 instead, as Jason pointed out.
>
> Right, cpp1y is c++14. Note that we wouldn't push the tests separately
> to the patch itself, unless it's something that already works. Thanks,
>
> Marek
But, the tests work. They passes as-is, as they track the
ICE, but will XPASS (that part) once a fix is committed (at
which time: "I checked that these behave as expected (xfail
as ICE properly) without the previosly posted patch to
cp/constexpr.cc and XPASS with it applied."
Once the fix works, the xfail for the ICE should be removed.
(Hm, better comment on the patches in a reply to that message. :)
The point is that for this type of bug it's useful to have a
test-case tracking it, before a fix is committed.
brgds, H-P
Re: LoongArch: Backport r14-4674 "LoongArch: Delete macro definition ASM_OUTPUT_ALIGN_WITH_NOP."?
在 2024/2/7 上午12:23, Xi Ruoyao 写道: Hi Lulu, I'm proposing to backport r14-4674 "LoongArch: Delete macro definition ASM_OUTPUT_ALIGN_WITH_NOP." to releases/gcc-12 and releases/gcc-13. The reasons: 1. Strictly speaking, the old ASM_OUTPUT_ALIGN_WITH_NOP macro may cause a correctness issue. For example, a developer may use -falign- functions=16 and then use the low 4 bits of a function pointer to encode some metainfo. Then ASM_OUTPUT_ALIGN_WITH_NOP causes the functions not really aligned to a 16 bytes boundary, causing some breakage. 2. With Binutils-2.42, ASM_OUTPUT_ALIGN_WITH_NOP can cause illegal opcodes. For example: .globl _start _start: .balign 32 nop nop nop addi.d $a0, $r0, 1 .balign 16,54525952,4 addi.d $a0, $a0, 1 is assembled and linked to: 0220 <_start>: 220: 0340nop 224: 0340nop 228: 0340nop 22c: 02c00404li.d$a0, 1 230: .word 0x # <== OOPS! 234: 02c00484addi.d $a0, $a0, 1 Arguably this is a bug in GAS (it should at least error out for the unsupported case where .balign 16,54525952,4 appears with -mrelax; I'd prefer it to support the 3-operand .align directive even -mrelax for reasons I've given in [1]). But we can at least work it around by removing ASM_OUTPUT_ALIGN_WITH_NOP to allow using GCC 13.3 with Binutils 2.42. 3. Without ASM_OUTPUT_ALIGN_WITH_NOP, GCC just outputs something like ".align 5" which works as expected since Binutils-2.38. 4. GCC < 14 does not have a default setting of -falign-*, so changing this won't affect anyone who do not specify -falign-* explicitly. [1]:https://github.com/loongson-community/discussions/issues/41#issuecomment-1925872603 Is it OK to backport r14-4674 into releases/gcc-12 and releases/gcc-13 then? Ok, I agree with you. Thanks!
[committed] libstdc++: Guard tr2::bases and tr2::direct_bases with __has_builtin
Tested x86_64-linux. Pusued to trunk. I'll backport it too.
-- >8 --
These non-standard extensions use GCC-specific built-ins. Use
__has_builtin to avoid errors when Clang compiles this header.
See https://github.com/llvm/llvm-project/issues/24289
libstdc++-v3/ChangeLog:
* include/tr2/type_traits (bases, direct_bases): Use
__has_builtin to check if required built-ins are supported.
---
libstdc++-v3/include/tr2/type_traits | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/tr2/type_traits
b/libstdc++-v3/include/tr2/type_traits
index a7ebaf66947..603039de894 100644
--- a/libstdc++-v3/include/tr2/type_traits
+++ b/libstdc++-v3/include/tr2/type_traits
@@ -82,20 +82,23 @@ namespace tr2
/// Sequence abstraction metafunctions for manipulating a typelist.
-
+#if __has_builtin(__bases)
/// Enumerate all the base classes of a class. Form of a typelist.
template
struct bases
{
typedef __reflection_typelist<__bases(_Tp)...> type;
};
+#endif
+#if __has_builtin(__direct_bases)
/// Enumerate all the direct base classes of a class. Form of a typelist.
template
struct direct_bases
{
typedef __reflection_typelist<__direct_bases(_Tp)...>type;
};
+#endif
/// @} group metaprogramming
}
--
2.43.0
Re: [PATCH] c++: Don't ICE for unknown parameter to constexpr'd switch-statement, PR113545
On Thu, Feb 08, 2024 at 04:40:40PM +0100, Hans-Peter Nilsson wrote:
> > Date: Wed, 7 Feb 2024 21:11:59 -0500
> > From: Marek Polacek
>
> > On Wed, Feb 07, 2024 at 04:32:57PM -0500, Jason Merrill wrote:
> > > On 2/6/24 19:23, Hans-Peter Nilsson wrote:
> > > > > Date: Mon, 22 Jan 2024 14:33:59 -0500
> > > > > From: Marek Polacek
> > > >
> > > > > On Mon, Jan 22, 2024 at 06:02:32PM +0100, Hans-Peter Nilsson wrote:
> > > > > > I don't really know whether this is the right way to treat
> > > > > > CONVERT_EXPR as below, but... Regtested native
> > > > > > x86_64-linux-gnu. Ok to commit?
> > > > >
> > > > > Thanks for taking a look at this problem.
> > > >
> > > > Thanks for the initial review.
>
> > > Incidentally, these testcases seem to require C++14; you can't have a
> > > switch
> > > in a constexpr function in C++11.
> > >
> > > Jason
> >
> > > diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
> > > index 2ebb1470dd5..fa346fe01c9 100644
> > > --- a/gcc/cp/constexpr.cc
> > > +++ b/gcc/cp/constexpr.cc
> > > @@ -7106,6 +7106,16 @@ cxx_eval_switch_expr (const constexpr_ctx *ctx,
> > > tree t,
> > >cond = cxx_eval_constant_expression (ctx, cond, vc_prvalue,
> > > non_constant_p, overflow_p);
> > >VERIFY_CONSTANT (cond);
> > > + if (TREE_CODE (cond) != INTEGER_CST)
> > > +{
> > > + /* If the condition doesn't reduce to an INTEGER_CST it isn't a
> > > usable
> > > + switch condition even if it's constant enough for other things
> > > + (c++/113545). */
> > > + gcc_checking_assert (ctx->quiet);
> > > + *non_constant_p = true;
> > > + return t;
> > > +}
> > > +
> > >*jump_target = cond;
> > >
> > >tree body
> >
> > The patch makes sense to me, although I'm afraid that losing the
> > REINTERPRET_CAST_P flag will cause other issues.
> >
> > HP, sorry that I never got back to you. I would be more than happy to
> > take the patch above, add some tests and test/bootstrap it, unless you
> > want to do that yourself.
> >
> > Thanks & sorry again,
>
> No worries, feel very welcome to deal with handling the
> actual fix. Also, you're better prepared than me, when it
> comes to dealing with any possible fallout. :)
>
> I'll send an updated version of the test-cases, moving them
> to the C++14 test directory (cpp1y, right?) and qualify them
> as c++14 instead, as Jason pointed out.
Right, cpp1y is c++14. Note that we wouldn't push the tests separately
to the patch itself, unless it's something that already works. Thanks,
Marek
Re: [PATCH] c++: Don't ICE for unknown parameter to constexpr'd switch-statement, PR113545
> Date: Wed, 7 Feb 2024 21:11:59 -0500
> From: Marek Polacek
> On Wed, Feb 07, 2024 at 04:32:57PM -0500, Jason Merrill wrote:
> > On 2/6/24 19:23, Hans-Peter Nilsson wrote:
> > > > Date: Mon, 22 Jan 2024 14:33:59 -0500
> > > > From: Marek Polacek
> > >
> > > > On Mon, Jan 22, 2024 at 06:02:32PM +0100, Hans-Peter Nilsson wrote:
> > > > > I don't really know whether this is the right way to treat
> > > > > CONVERT_EXPR as below, but... Regtested native
> > > > > x86_64-linux-gnu. Ok to commit?
> > > >
> > > > Thanks for taking a look at this problem.
> > >
> > > Thanks for the initial review.
> > Incidentally, these testcases seem to require C++14; you can't have a switch
> > in a constexpr function in C++11.
> >
> > Jason
>
> > diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
> > index 2ebb1470dd5..fa346fe01c9 100644
> > --- a/gcc/cp/constexpr.cc
> > +++ b/gcc/cp/constexpr.cc
> > @@ -7106,6 +7106,16 @@ cxx_eval_switch_expr (const constexpr_ctx *ctx, tree
> > t,
> >cond = cxx_eval_constant_expression (ctx, cond, vc_prvalue,
> >non_constant_p, overflow_p);
> >VERIFY_CONSTANT (cond);
> > + if (TREE_CODE (cond) != INTEGER_CST)
> > +{
> > + /* If the condition doesn't reduce to an INTEGER_CST it isn't a
> > usable
> > +switch condition even if it's constant enough for other things
> > +(c++/113545). */
> > + gcc_checking_assert (ctx->quiet);
> > + *non_constant_p = true;
> > + return t;
> > +}
> > +
> >*jump_target = cond;
> >
> >tree body
>
> The patch makes sense to me, although I'm afraid that losing the
> REINTERPRET_CAST_P flag will cause other issues.
>
> HP, sorry that I never got back to you. I would be more than happy to
> take the patch above, add some tests and test/bootstrap it, unless you
> want to do that yourself.
>
> Thanks & sorry again,
No worries, feel very welcome to deal with handling the
actual fix. Also, you're better prepared than me, when it
comes to dealing with any possible fallout. :)
I'll send an updated version of the test-cases, moving them
to the C++14 test directory (cpp1y, right?) and qualify them
as c++14 instead, as Jason pointed out.
brgds, H-P
[PATCH] arm: testsuite: fix issues relating to fp16 alternative testing
The v*_fp16_xN_1.c tests on Arm have been unstable since they were
added. This is not a problem with the tests themselves, or even the
patches that were added, but with the testsuite infrastructure. It
turned out that another set of dg- tests for fp16 were corrupting the
cached set of options used by the new tests, leading to running the
tests with incorrect flags.
So the primary goal of this patch is to fix the incorrect internal
caching of the options needed to enable fp16 alternative format on
Arm: the code was storing the result in the same variable that was
being used for neon_fp16 and this was leading to testsuite instability
for tests that were checking for neon with fp16.
But in cleaning this up I also noted that we weren't then applying the
flags correctly having detected what they were, so we also address
that.
I suspect there are still some further issues to address here, since
the framework does not correctly test that the multilibs and startup
code enable alternative format; but this is still an improvement over
what we had before.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp
(check_effective_target_arm_fp16_alternative_ok_nocache): Use
et_arm_fp16_alternative_flags to cache the result. Improve test
for FP16 availability.
(add_options_for_arm_fp16_alternative): Use
et_arm_fp16_alternative_flags.
* g++.dg/ext/arm-fp16/arm-fp16-ops-3.C: Update dg-* flags.
* g++.dg/ext/arm-fp16/arm-fp16-ops-4.C: Likewise.
* gcc.dg/torture/arm-fp16-int-convert-alt.c: Likewise.
* gcc.dg/torture/arm-fp16-ops-3.c: Likewise.
* gcc.dg/torture/arm-fp16-ops-4.c: Likewise.
* gcc.target/arm/fp16-aapcs-3.c: Likewise.
* gcc.target/arm/fp16-aapcs-4.c: Likewise.
* gcc.target/arm/fp16-compile-alt-1.c: Likewise.
* gcc.target/arm/fp16-compile-alt-10.c: Likewise.
* gcc.target/arm/fp16-compile-alt-11.c: Likewise.
* gcc.target/arm/fp16-compile-alt-12.c: Likewise.
* gcc.target/arm/fp16-compile-alt-2.c: Likewise.
* gcc.target/arm/fp16-compile-alt-3.c: Likewise.
* gcc.target/arm/fp16-compile-alt-4.c: Likewise.
* gcc.target/arm/fp16-compile-alt-5.c: Likewise.
* gcc.target/arm/fp16-compile-alt-6.c: Likewise.
* gcc.target/arm/fp16-compile-alt-7.c: Likewise.
* gcc.target/arm/fp16-compile-alt-8.c: Likewise.
* gcc.target/arm/fp16-compile-alt-9.c: Likewise.
* gcc.target/arm/fp16-rounding-alt-1.c: Likewise.
---
.../g++.dg/ext/arm-fp16/arm-fp16-ops-3.C | 2 +-
.../g++.dg/ext/arm-fp16/arm-fp16-ops-4.C | 3 ++-
.../gcc.dg/torture/arm-fp16-int-convert-alt.c| 2 +-
gcc/testsuite/gcc.dg/torture/arm-fp16-ops-3.c| 2 +-
gcc/testsuite/gcc.dg/torture/arm-fp16-ops-4.c| 3 ++-
gcc/testsuite/gcc.target/arm/fp16-aapcs-3.c | 3 ++-
gcc/testsuite/gcc.target/arm/fp16-aapcs-4.c | 3 ++-
.../gcc.target/arm/fp16-compile-alt-1.c | 2 +-
.../gcc.target/arm/fp16-compile-alt-10.c | 3 ++-
.../gcc.target/arm/fp16-compile-alt-11.c | 3 ++-
.../gcc.target/arm/fp16-compile-alt-12.c | 2 +-
.../gcc.target/arm/fp16-compile-alt-2.c | 2 +-
.../gcc.target/arm/fp16-compile-alt-3.c | 2 +-
.../gcc.target/arm/fp16-compile-alt-4.c | 2 +-
.../gcc.target/arm/fp16-compile-alt-5.c | 2 +-
.../gcc.target/arm/fp16-compile-alt-6.c | 2 +-
.../gcc.target/arm/fp16-compile-alt-7.c | 3 ++-
.../gcc.target/arm/fp16-compile-alt-8.c | 2 +-
.../gcc.target/arm/fp16-compile-alt-9.c | 2 +-
.../gcc.target/arm/fp16-rounding-alt-1.c | 4 +++-
gcc/testsuite/lib/target-supports.exp| 16
21 files changed, 37 insertions(+), 28 deletions(-)
diff --git a/gcc/testsuite/g++.dg/ext/arm-fp16/arm-fp16-ops-3.C b/gcc/testsuite/g++.dg/ext/arm-fp16/arm-fp16-ops-3.C
index 29080c7514f..5eceb3074df 100644
--- a/gcc/testsuite/g++.dg/ext/arm-fp16/arm-fp16-ops-3.C
+++ b/gcc/testsuite/g++.dg/ext/arm-fp16/arm-fp16-ops-3.C
@@ -1,6 +1,6 @@
/* Test various operators on __fp16 and mixed __fp16/float operands. */
/* { dg-do run { target arm*-*-* } } */
/* { dg-require-effective-target arm_fp16_alternative_ok } */
-/* { dg-options "-mfp16-format=alternative" } */
+/* { dg-add-options arm_fp16_alternative } */
#include "arm-fp16-ops.h"
diff --git a/gcc/testsuite/g++.dg/ext/arm-fp16/arm-fp16-ops-4.C b/gcc/testsuite/g++.dg/ext/arm-fp16/arm-fp16-ops-4.C
index 4be8883faad..d86019f1469 100644
--- a/gcc/testsuite/g++.dg/ext/arm-fp16/arm-fp16-ops-4.C
+++ b/gcc/testsuite/g++.dg/ext/arm-fp16/arm-fp16-ops-4.C
@@ -1,6 +1,7 @@
/* Test various operators on __fp16 and mixed __fp16/float operands. */
/* { dg-do run { target arm*-*-* } } */
/* { dg-require-effective-target arm_fp16_alternative_ok } */
-/* { dg-options "-mfp16-format=alternative -ffast-math" } */
+/* { dg-options "-ffast-math" } */
+/* {
Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]
Hi Jason, I have tested this on modern Darwin (with libc++ as the system library) and on older Darwin, where we do see the issue - because the system linker is written in C++ and links with libstdc++ (so sometimes we get a crash, or worse unpredictable beahviour). - For modern Darwin [ > macOS 10.11] , there’s no issue seen so far, but for older Darwin…. > On 8 Feb 2024, at 05:36, Alexandre Oliva wrote: > > On Feb 6, 2024, Jason Merrill wrote: > >> Reverting that hunk of the change fixed my problem with bubblestrapping GCC >> 12 with ccache on a host with a newer system libstdc++. > > Did you have libcc1, gnattools and gotools enabled in your testing? … I have done all but “go” since that’s not supported on Darwin. The patch breaks bootstrap on older Darwin because: Ada uses exceptions. gnat1 pulls in system libraries that link with the system unwinder - so we have to link gnat1 “-shared-libgcc” - which means we need to be able to find the just-built one when building the target libs. - that means we need to find it as a host library, which we were getting away with because the host list was appended to the target list. To recover bootstrap I think the following addition is needed: diff --git a/Makefile.tpl b/Makefile.tpl index cb39fbd0434..65621bf6882 100644 --- a/Makefile.tpl +++ b/Makefile.tpl @@ -663,7 +663,7 @@ TARGET_LIB_PATH_[+module+] = $$r/$(TARGET_SUBDIR)/[+module+]/[+lib_path+]: # so that programs built for the host machine work. HOST_LIB_PATH = [+ FOR host_modules +][+ IF lib_path +]$(HOST_LIB_PATH_[+module+])[+ ENDIF lib_path +][+ - ENDFOR host_modules +] + ENDFOR host_modules +]$(HOST_LIB_PATH_gcc) # Define HOST_LIB_PATH_gcc here, for the sake of TARGET_LIB_PATH, ouch @if gcc It’s not clear to me why we consider prev-gcc as relevant to host libgcc (we must have built libgcc in order to have linked it to any host deps .. but perhaps I’m missing a case). I agree with the sentiment below that this is a delicate area…. > Those non-bootstrapped tools are most likely to be problem spots. > > I have a vague recollection that, in native scenarios, when > bootstrapping but not when not boostrapping, they are (or used to be?) > built using the just-built (last-stage) compiler and target libraries, > rather than system tools or previous stage (which I believe would fail > bootstrap-lean). > > Just by looking at the current code I can't bring back to mind all the > involved moving parts :-/ but my guess is that the need for > TARGET_LIB_PATH comes about for this combination of circumstances, in > which we would need to use the just-built native-target libstdc++ to > link or to run these host tools using the just-built tools. > > Having a newer system libstdc++ would, I suspect, unfortunately mask the > problem that those who had an older or no system libstdc++ would likely > run into. > > > OTOH, if the system linker requires the newer system library, and ld.so > and ld overload LD_LIBRARY_PATH for both the libraries loaded for ld to > run, the libraries ld searches to link executables, and the libraries > loaded for so-linked programs to run, we seem to need some means to > distinguish between these three circumstances so as to be able to set > LD_LIBRARY_PATH correctly for each one, whether the libstdc++ we're > building is newer or older than the system one. And there's an added > complication that any single ld invocation involves two different and > potentially conflicting uses of LD_LIBRARY_PATH. > > /me runs screaming :-) > > > Perhaps the best we can do out of these conflicting requirements is to > somehow detect a system libstdc++ newer than the one we're about to > build, and fail early if we find that some of the tools depend on the > newer libstdc++, or disable this env var setting for this case only and > hope the newer system library is compatible enough. > > Holy nightmare, Batman! :-) :-( > > > Perhaps the way to go is an explicit configure setting, recommended by > the fail early, to disable the env var setting? > > -- > Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ > Free Software Activist GNU Toolchain Engineer > More tolerance and less prejudice are key for inclusion and diversity > Excluding neuro-others for not behaving ""normal"" is *not* inclusive
RE: [PATCH]middle-end: add two debug counters for early-break vectorization debugging
On Thu, 8 Feb 2024, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Thursday, February 8, 2024 2:16 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> > Subject: Re: [PATCH]middle-end: add two debug counters for early-break
> > vectorization debugging
> >
> > On Thu, 8 Feb 2024, Tamar Christina wrote:
> >
> > > Hi All,
> > >
> > > This adds two new debug counter to aid in debugging early break code.
> > >
> > > - vect_force_last_exit: when reached will always force the final loop
> > > exit.
> > > - vect_skip_exit: when reached will skip selecting the current candidate
> > > exit
> > > as the loop exit.
> > >
> > > The first counter essentially allows you to turn off the PEELED case and
> > > the
> > > second counter to pick a different exit, which may mean you pick no exit
> > > at
> > > all.
> > >
> > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> > >
> > > Ok for master?
> > >
> > > Thanks,
> > > Tamar
> > >
> > > gcc/ChangeLog:
> > >
> > > * dbgcnt.def (vect_force_last_exit, vect_skip_exit): New.
> > > * tree-vect-loop.cc (vec_init_loop_exit_info): Use them.
> > >
> > > --- inline copy of patch --
> > > diff --git a/gcc/dbgcnt.def b/gcc/dbgcnt.def
> > > index
> > ed9f062eac2c28c52df76b39d4312dd9fde1c800..8f7bebf93fceabdf6ae86c2df5
> > 91eae4848b8a5c 100644
> > > --- a/gcc/dbgcnt.def
> > > +++ b/gcc/dbgcnt.def
> > > @@ -213,5 +213,7 @@ DEBUG_COUNTER (stv_conversion)
> > > DEBUG_COUNTER (tail_call)
> > > DEBUG_COUNTER (tree_sra)
> > > DEBUG_COUNTER (treepre_insert)
> > > +DEBUG_COUNTER (vect_force_last_exit)
> > > DEBUG_COUNTER (vect_loop)
> > > +DEBUG_COUNTER (vect_skip_exit)
> > > DEBUG_COUNTER (vect_slp)
> > > diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> > > index
> > eed2268e9bae7e7ad36d13da03e0b54eab26ef6f..854e9d78bc71721e6559a6bc
> > 5dff78c813603a78 100644
> > > --- a/gcc/tree-vect-loop.cc
> > > +++ b/gcc/tree-vect-loop.cc
> > > @@ -58,6 +58,7 @@ along with GCC; see the file COPYING3. If not see
> > > #include "tree-eh.h"
> > > #include "case-cfn-macros.h"
> > > #include "langhooks.h"
> > > +#include "dbgcnt.h"
> > >
> > > /* Loop Vectorization Pass.
> > >
> > > @@ -977,6 +978,20 @@ vec_init_loop_exit_info (class loop *loop)
> > >if (exits.length () == 1)
> > > return exits[0];
> > >
> > > + /* Check to see if we've been asked to force the last exit. */
> > > + if (!dbg_cnt (vect_force_last_exit))
> > > +{
> > > + basic_block bb = ip_normal_pos (loop);
> > > + if (!bb)
> > > + return NULL;
> > > +
> > > + edge exit = EDGE_SUCC (bb, 0);
> > > + if (exit->dest == loop->latch)
> > > + return EDGE_SUCC (bb, 1);
> > > +
> > > + return exit;
> >
> > Err, that's quite odd. Why not just below do
> >
> > > +}
> > > +
> > >/* If we have multiple exits we only support counting IV at the moment.
> > > Analyze all exits and return the last one we can analyze. */
> > >class tree_niter_desc niter_desc;
> > > @@ -998,6 +1013,7 @@ vec_init_loop_exit_info (class loop *loop)
> > > && exit->src == single_pred (loop->latch)
> > > && (integer_nonzerop (may_be_zero)
> > > || COMPARISON_CLASS_P (may_be_zero
> > > + && dbg_cnt (vect_skip_exit)
> >
> > && (dbg_cnt (vect_force_last_exit)
> > || exit->src == single_pred (loop->latch))
> >
> > (also computed above already)? It's also oddly named, it's more like
> > vect_allow_peeled_exit or so.
>
> Because this isn't deterministic. If a loop has n exits the above always
> forces
> you to pick the final one regardless of n, rather than just skip
> consideration of an exit.
Well, you can always do (before the loop)
bool force_last_exit = dbg_cnt (vect_force_last_exit);
to evaluate it only once. I think for debug counters we should avoid
introducing more lines of code when possible (the above big odd blob).
> And in that case is there a point in analyzing all the exits just to throw
> away the information?
>
> Doing in inside the consideration check would only skip one exit unless I'm
> misunderstanding.
>
> >
> > It's also seemingly redundant with vect_skip_exit, no?
> >
> > Note the counter gets incremented even if we'd not consider the exit
> > because we have a later candidate already.
> >
> > I fear it's going to be quite random even with the debug counter.
>
> It is, I think the first counter is more useful. But in general the reason I
> kept the second counter
> which kinda does what was suggested in the RFC I sent before was that it
> should in theory at
> least allow us to test forcing of a PEELED case. Since we generally prefer
> the non-PEELED case
> if possible.
>
> At least that was the intention.
For the PEELED case I wondered if a --param vect-allow-early-exit-peeled
defaulted to 1 would make more sense. Of course it doesn't do this
per loop.
> Thanks,
> Tamar
>
[PATCH, OpenACC 2.7] struct/array reductions for Fortran
Hi Tobias, Thomas,
this patch adds support for Fortran to use arrays and struct(record) types in
OpenACC reductions.
There is still some shortcomings in the current state, mainly that only
explicit-shaped arrays can be used (like its C counterpart). Anything else is
currently a bit more complicated in the middle-end, since the existing
reduction code creates an "init-op" (literal of initial values) which can't be
done when say TYPE_MAX_VALUE (TYPE_DOMAIN (array_type)) is not a tree constant.
I think we'll be on the hook to solve this later, but I think the current state
is okay to submit.
Tested without regressions on mainline (on top of first struct/array reduction
patch[1])
Thanks,
Chung-Lin
[1] https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641669.html
2024-02-08 Chung-Lin Tang
gcc/fortran/ChangeLog:
* openmp.cc (oacc_reduction_defined_type_p): New function.
(resolve_omp_clauses): Adjust OpenACC array reduction error case. Use
oacc_reduction_defined_type_p for OpenACC.
* trans-openmp.cc (gfc_trans_omp_array_reduction_or_udr):
Add 'bool openacc' parameter, adjust part of function to be !openacc
only.
(gfc_trans_omp_reduction_list): Add 'bool openacc' parameter, pass to
calls to gfc_trans_omp_array_reduction_or_udr.
(gfc_trans_omp_clauses): Add 'openacc' argument to calls to
gfc_trans_omp_reduction_list.
(gfc_trans_omp_do): Pass 'op == EXEC_OACC_LOOP' as 'bool openacc'
parameter in call to gfc_trans_omp_clauses.
gcc/ChangeLog:
* omp-low.cc (omp_reduction_init_op): Add checking if reduced array
has constant bounds.
(lower_oacc_reductions): Add handling of error_mark_node.
gcc/testsuite/ChangeLog:
* gfortran.dg/goacc/array-reduction.f90: Adjust testcase.
* gfortran.dg/goacc/reduction.f95: Likewise.
libgomp/ChangeLog:
* libgomp/testsuite/libgomp.oacc-fortran/reduction-9.f90: New testcase.
* libgomp/testsuite/libgomp.oacc-fortran/reduction-10.f90: Likewise.
* libgomp/testsuite/libgomp.oacc-fortran/reduction-11.f90: Likewise.
* libgomp/testsuite/libgomp.oacc-fortran/reduction-12.f90: Likewise.
* libgomp/testsuite/libgomp.oacc-fortran/reduction-13.f90: Likewise.
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index 0af80d54fad..4bba9e666d6 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -7047,6 +7047,72 @@ oacc_is_loop (gfc_code *code)
|| code->op == EXEC_OACC_LOOP;
}
+static bool
+oacc_reduction_defined_type_p (enum gfc_omp_reduction_op rop, gfc_typespec *ts)
+{
+ if (rop == OMP_REDUCTION_USER || rop == OMP_REDUCTION_NONE)
+return false;
+
+ if (ts->type == BT_INTEGER)
+switch (rop)
+ {
+ case OMP_REDUCTION_AND:
+ case OMP_REDUCTION_OR:
+ case OMP_REDUCTION_EQV:
+ case OMP_REDUCTION_NEQV:
+ return false;
+ default:
+ return true;
+ }
+
+ if (ts->type == BT_LOGICAL)
+switch (rop)
+ {
+ case OMP_REDUCTION_AND:
+ case OMP_REDUCTION_OR:
+ case OMP_REDUCTION_EQV:
+ case OMP_REDUCTION_NEQV:
+ return true;
+ default:
+ return false;
+ }
+
+ if (ts->type == BT_REAL || ts->type == BT_COMPLEX)
+switch (rop)
+ {
+ case OMP_REDUCTION_PLUS:
+ case OMP_REDUCTION_TIMES:
+ case OMP_REDUCTION_MINUS:
+ return true;
+
+ case OMP_REDUCTION_AND:
+ case OMP_REDUCTION_OR:
+ case OMP_REDUCTION_EQV:
+ case OMP_REDUCTION_NEQV:
+ return false;
+
+ case OMP_REDUCTION_MAX:
+ case OMP_REDUCTION_MIN:
+ return ts->type != BT_COMPLEX;
+ case OMP_REDUCTION_IAND:
+ case OMP_REDUCTION_IOR:
+ case OMP_REDUCTION_IEOR:
+ return false;
+ default:
+ gcc_unreachable ();
+ }
+
+ if (ts->type == BT_DERIVED)
+{
+ for (gfc_component *p = ts->u.derived->components; p; p = p->next)
+ if (!oacc_reduction_defined_type_p (rop, >ts))
+ return false;
+ return true;
+}
+
+ return false;
+}
+
static void
resolve_scalar_int_expr (gfc_expr *expr, const char *clause)
{
@@ -8137,13 +8203,15 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses
*omp_clauses,
else
n->sym->mark = 1;
- /* OpenACC does not support reductions on arrays. */
- if (n->sym->as)
+ /* OpenACC current only supports array reductions on explicit-shape
+arrays. */
+ if ((n->sym->as && n->sym->as->type != AS_EXPLICIT)
+ || n->sym->attr.codimension)
gfc_error ("Array %qs is not permitted in reduction at %L",
n->sym->name, >where);
}
}
-
+
for (n = omp_clauses->lists[OMP_LIST_TO]; n; n = n->next)
n->sym->mark = 0;
for (n = omp_clauses->lists[OMP_LIST_FROM]; n; n = n->next)
@@ -8797,39 +8865,46 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses
*omp_clauses,
RE: [PATCH]middle-end: add two debug counters for early-break vectorization debugging
> -Original Message-
> From: Richard Biener
> Sent: Thursday, February 8, 2024 2:16 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH]middle-end: add two debug counters for early-break
> vectorization debugging
>
> On Thu, 8 Feb 2024, Tamar Christina wrote:
>
> > Hi All,
> >
> > This adds two new debug counter to aid in debugging early break code.
> >
> > - vect_force_last_exit: when reached will always force the final loop exit.
> > - vect_skip_exit: when reached will skip selecting the current candidate
> > exit
> > as the loop exit.
> >
> > The first counter essentially allows you to turn off the PEELED case and the
> > second counter to pick a different exit, which may mean you pick no exit at
> > all.
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> >
> > Ok for master?
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > * dbgcnt.def (vect_force_last_exit, vect_skip_exit): New.
> > * tree-vect-loop.cc (vec_init_loop_exit_info): Use them.
> >
> > --- inline copy of patch --
> > diff --git a/gcc/dbgcnt.def b/gcc/dbgcnt.def
> > index
> ed9f062eac2c28c52df76b39d4312dd9fde1c800..8f7bebf93fceabdf6ae86c2df5
> 91eae4848b8a5c 100644
> > --- a/gcc/dbgcnt.def
> > +++ b/gcc/dbgcnt.def
> > @@ -213,5 +213,7 @@ DEBUG_COUNTER (stv_conversion)
> > DEBUG_COUNTER (tail_call)
> > DEBUG_COUNTER (tree_sra)
> > DEBUG_COUNTER (treepre_insert)
> > +DEBUG_COUNTER (vect_force_last_exit)
> > DEBUG_COUNTER (vect_loop)
> > +DEBUG_COUNTER (vect_skip_exit)
> > DEBUG_COUNTER (vect_slp)
> > diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> > index
> eed2268e9bae7e7ad36d13da03e0b54eab26ef6f..854e9d78bc71721e6559a6bc
> 5dff78c813603a78 100644
> > --- a/gcc/tree-vect-loop.cc
> > +++ b/gcc/tree-vect-loop.cc
> > @@ -58,6 +58,7 @@ along with GCC; see the file COPYING3. If not see
> > #include "tree-eh.h"
> > #include "case-cfn-macros.h"
> > #include "langhooks.h"
> > +#include "dbgcnt.h"
> >
> > /* Loop Vectorization Pass.
> >
> > @@ -977,6 +978,20 @@ vec_init_loop_exit_info (class loop *loop)
> >if (exits.length () == 1)
> > return exits[0];
> >
> > + /* Check to see if we've been asked to force the last exit. */
> > + if (!dbg_cnt (vect_force_last_exit))
> > +{
> > + basic_block bb = ip_normal_pos (loop);
> > + if (!bb)
> > + return NULL;
> > +
> > + edge exit = EDGE_SUCC (bb, 0);
> > + if (exit->dest == loop->latch)
> > + return EDGE_SUCC (bb, 1);
> > +
> > + return exit;
>
> Err, that's quite odd. Why not just below do
>
> > +}
> > +
> >/* If we have multiple exits we only support counting IV at the moment.
> > Analyze all exits and return the last one we can analyze. */
> >class tree_niter_desc niter_desc;
> > @@ -998,6 +1013,7 @@ vec_init_loop_exit_info (class loop *loop)
> >&& exit->src == single_pred (loop->latch)
> >&& (integer_nonzerop (may_be_zero)
> >|| COMPARISON_CLASS_P (may_be_zero
> > + && dbg_cnt (vect_skip_exit)
>
> && (dbg_cnt (vect_force_last_exit)
> || exit->src == single_pred (loop->latch))
>
> (also computed above already)? It's also oddly named, it's more like
> vect_allow_peeled_exit or so.
Because this isn't deterministic. If a loop has n exits the above always forces
you to pick the final one regardless of n, rather than just skip consideration
of an exit.
And in that case is there a point in analyzing all the exits just to throw away
the information?
Doing in inside the consideration check would only skip one exit unless I'm
misunderstanding.
>
> It's also seemingly redundant with vect_skip_exit, no?
>
> Note the counter gets incremented even if we'd not consider the exit
> because we have a later candidate already.
>
> I fear it's going to be quite random even with the debug counter.
It is, I think the first counter is more useful. But in general the reason I
kept the second counter
which kinda does what was suggested in the RFC I sent before was that it should
in theory at
least allow us to test forcing of a PEELED case. Since we generally prefer the
non-PEELED case
if possible.
At least that was the intention.
Thanks,
Tamar
>
> Can you see whether it really helps you?
>
> > && (!candidate
> > || dominated_by_p (CDI_DOMINATORS, exit->src,
> > candidate->src)))
> >
> >
> >
> >
> >
>
> --
> Richard Biener
> SUSE Software Solutions Germany GmbH,
> Frankenstrasse 146, 90461 Nuernberg, Germany;
> GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
Re: [PATCH]middle-end: add two debug counters for early-break vectorization debugging
On Thu, 8 Feb 2024, Tamar Christina wrote:
> Hi All,
>
> This adds two new debug counter to aid in debugging early break code.
>
> - vect_force_last_exit: when reached will always force the final loop exit.
> - vect_skip_exit: when reached will skip selecting the current candidate exit
> as the loop exit.
>
> The first counter essentially allows you to turn off the PEELED case and the
> second counter to pick a different exit, which may mean you pick no exit at
> all.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> * dbgcnt.def (vect_force_last_exit, vect_skip_exit): New.
> * tree-vect-loop.cc (vec_init_loop_exit_info): Use them.
>
> --- inline copy of patch --
> diff --git a/gcc/dbgcnt.def b/gcc/dbgcnt.def
> index
> ed9f062eac2c28c52df76b39d4312dd9fde1c800..8f7bebf93fceabdf6ae86c2df591eae4848b8a5c
> 100644
> --- a/gcc/dbgcnt.def
> +++ b/gcc/dbgcnt.def
> @@ -213,5 +213,7 @@ DEBUG_COUNTER (stv_conversion)
> DEBUG_COUNTER (tail_call)
> DEBUG_COUNTER (tree_sra)
> DEBUG_COUNTER (treepre_insert)
> +DEBUG_COUNTER (vect_force_last_exit)
> DEBUG_COUNTER (vect_loop)
> +DEBUG_COUNTER (vect_skip_exit)
> DEBUG_COUNTER (vect_slp)
> diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> index
> eed2268e9bae7e7ad36d13da03e0b54eab26ef6f..854e9d78bc71721e6559a6bc5dff78c813603a78
> 100644
> --- a/gcc/tree-vect-loop.cc
> +++ b/gcc/tree-vect-loop.cc
> @@ -58,6 +58,7 @@ along with GCC; see the file COPYING3. If not see
> #include "tree-eh.h"
> #include "case-cfn-macros.h"
> #include "langhooks.h"
> +#include "dbgcnt.h"
>
> /* Loop Vectorization Pass.
>
> @@ -977,6 +978,20 @@ vec_init_loop_exit_info (class loop *loop)
>if (exits.length () == 1)
> return exits[0];
>
> + /* Check to see if we've been asked to force the last exit. */
> + if (!dbg_cnt (vect_force_last_exit))
> +{
> + basic_block bb = ip_normal_pos (loop);
> + if (!bb)
> + return NULL;
> +
> + edge exit = EDGE_SUCC (bb, 0);
> + if (exit->dest == loop->latch)
> + return EDGE_SUCC (bb, 1);
> +
> + return exit;
Err, that's quite odd. Why not just below do
> +}
> +
>/* If we have multiple exits we only support counting IV at the moment.
> Analyze all exits and return the last one we can analyze. */
>class tree_niter_desc niter_desc;
> @@ -998,6 +1013,7 @@ vec_init_loop_exit_info (class loop *loop)
> && exit->src == single_pred (loop->latch)
> && (integer_nonzerop (may_be_zero)
> || COMPARISON_CLASS_P (may_be_zero
> + && dbg_cnt (vect_skip_exit)
&& (dbg_cnt (vect_force_last_exit)
|| exit->src == single_pred (loop->latch))
(also computed above already)? It's also oddly named, it's more like
vect_allow_peeled_exit or so.
It's also seemingly redundant with vect_skip_exit, no?
Note the counter gets incremented even if we'd not consider the exit
because we have a later candidate already.
I fear it's going to be quite random even with the debug counter.
Can you see whether it really helps you?
> && (!candidate
> || dominated_by_p (CDI_DOMINATORS, exit->src,
>candidate->src)))
>
>
>
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
Re: [PATCH] libgccjit: Add support for machine-dependent builtins
David: Ping. On Wed, 2024-01-10 at 18:58 -0500, Antoni Boucher wrote: > Here it is: https://gcc.gnu.org/pipermail/jit/2023q4/001725.html > > On Wed, 2024-01-10 at 18:44 -0500, David Malcolm wrote: > > On Wed, 2024-01-10 at 18:29 -0500, Antoni Boucher wrote: > > > David: Ping in case you missed this patch. > > > > For some reason it's not showing up in patchwork (or, at least, I > > can't > > find it there). Do you have a URL for it there? > > > > Sorry about this > > Dave > > > > > > > > On Sat, 2023-02-11 at 17:37 -0800, Andrew Pinski wrote: > > > > On Sat, Feb 11, 2023 at 4:31 PM Antoni Boucher via Gcc-patches > > > > wrote: > > > > > > > > > > Hi. > > > > > This patch adds support for machine-dependent builtins in > > > > > libgccjit > > > > > (bug 108762). > > > > > > > > > > There are two things I don't like in this patch: > > > > > > > > > > 1. There are a few functions copied from the C frontend > > > > > (common_mark_addressable_vec and a few others). > > > > > > > > > > 2. Getting a target builtin only works from the second > > > > > compilation > > > > > since the type information is recorded at the first > > > > > compilation. > > > > > I > > > > > couldn't find a way to get the builtin data without using the > > > > > langhook. > > > > > It is necessary to get the type information for type checking > > > > > and > > > > > instrospection. > > > > > > > > > > Any idea how to fix these issues? > > > > > > > > Seems like you should do this patch in a few steps; that is > > > > split > > > > it > > > > up. > > > > Definitely split out GCC_JIT_TYPE_BFLOAT16 support. > > > > I also think the vector support should be in a different patch > > > > too. > > > > > > > > Splitting out these parts would definitely make it easier for > > > > review > > > > and make incremental improvements. > > > > > > > > Thanks, > > > > Andrew Pinski > > > > > > > > > > > > > > > > > > > > > > Thanks for the review. > > > > > >
Re: [PATCH] c++/modules: anon union member of as-base class [PR112580]
On Thu, 1 Feb 2024, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Ping. FWIW this fixes the remaining reported xtreme-header FAILs on
x86_64-linux with -mx32 (not totally sure why the fails don't happen
without -mx32).
>
> -- >8 --
>
> Here when streaming in the fields of the as-base version of
> _Formatting_scanner we end up clobbering ANON_AGGR_TYPE_FIELD
> of the anonymous union type, since it turns out this type is shared
> between the original FIELD_DECL and the as-base FIELD_DECL copy (copied
> during layout_class_type). ANON_AGGR_TYPE_FIELD first gets properly set
> to the original FIELD_DECL when streaming in the canonical definition of
> _Formatting_scanner, and then gets overwritten to the as-base
> FIELD_DECL when streaming in the the as-base definition. This leads to
> lookup_anon_field giving the wrong answer when resolving the _M_values
> use.
>
> This patch makes us avoid overwriting ANON_AGGR_TYPE_FIELD when streaming
> in an as-base class definition, it should already be properly set at that
> point.
>
> PR c++/112580
>
> gcc/cp/ChangeLog:
>
> * module.cc (trees_in::read_class_def): When streaming in
> an anonymous union field of an as-base class, don't clobber
> ANON_AGGR_TYPE_FIELD.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/modules/anon-3_a.H: New test.
> * g++.dg/modules/anon-3_b.C: New test.
> ---
> gcc/cp/module.cc| 12 ++--
> gcc/testsuite/g++.dg/modules/anon-3_a.H | 21 +
> gcc/testsuite/g++.dg/modules/anon-3_b.C | 8
> 3 files changed, 39 insertions(+), 2 deletions(-)
> create mode 100644 gcc/testsuite/g++.dg/modules/anon-3_a.H
> create mode 100644 gcc/testsuite/g++.dg/modules/anon-3_b.C
>
> diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> index 3c2fef0e3f4..d36ba2eeeb3 100644
> --- a/gcc/cp/module.cc
> +++ b/gcc/cp/module.cc
> @@ -12178,8 +12178,16 @@ trees_in::read_class_def (tree defn, tree
> maybe_template)
>
> if (TREE_CODE (decl) == FIELD_DECL
> && ANON_AGGR_TYPE_P (TREE_TYPE (decl)))
> - ANON_AGGR_TYPE_FIELD
> - (TYPE_MAIN_VARIANT (TREE_TYPE (decl))) = decl;
> + {
> + tree anon_type = TYPE_MAIN_VARIANT (TREE_TYPE (decl));
> + if (DECL_NAME (defn) == as_base_identifier)
> + /* ANON_AGGR_TYPE_FIELD should already point to the
> +original FIELD_DECL, don't overwrite it to point
> +to the as-base FIELD_DECL copy. */
> + gcc_checking_assert (ANON_AGGR_TYPE_FIELD (anon_type));
> + else
> + ANON_AGGR_TYPE_FIELD (anon_type) = decl;
> + }
>
> if (TREE_CODE (decl) == USING_DECL
> && TREE_CODE (USING_DECL_SCOPE (decl)) == RECORD_TYPE)
> diff --git a/gcc/testsuite/g++.dg/modules/anon-3_a.H
> b/gcc/testsuite/g++.dg/modules/anon-3_a.H
> new file mode 100644
> index 000..64a6aab51dd
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/modules/anon-3_a.H
> @@ -0,0 +1,21 @@
> +// PR c++/112580
> +// { dg-additional-options "-fmodule-header" }
> +// { dg-module-cmi {} }
> +
> +template
> +struct _Formatting_scanner {
> + union {
> +int _M_values = 42;
> + };
> + virtual int _M_format_arg() { return _M_values; }
> +};
> +
> +template
> +auto __do_vformat_to() {
> + _Formatting_scanner s;
> + return s;
> +}
> +
> +inline auto vformat() {
> + return __do_vformat_to();
> +}
> diff --git a/gcc/testsuite/g++.dg/modules/anon-3_b.C
> b/gcc/testsuite/g++.dg/modules/anon-3_b.C
> new file mode 100644
> index 000..d676fe47536
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/modules/anon-3_b.C
> @@ -0,0 +1,8 @@
> +// PR c++/112580
> +// { dg-additional-options "-fmodules-ts" }
> +
> +import "anon-3_a.H";
> +
> +int main() {
> + vformat()._M_format_arg();
> +}
> --
> 2.43.0.493.gbc7ee2e5e1
>
>
Re: [PATCH] c++: make build_throw SFINAE-friendly [PR98388]
On Wed, 7 Feb 2024, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> Here the problem is that we give hard errors while substituting
> template parameters during overload resolution of is_throwable
> which has an invalid throw in decltype.
>
> The backtrace shows that fn_type_unification -> instantiate_template
> -> tsubst* passes complain=0 as expected, but build_throw doesn't
> have a complain parameter. So let's add one. Also remove a redundant
> local variable which I should have removed in my P2266 patch.
>
> But there's still something not quite clear to me. I claim that 'b'
> in the testcase should evaluate to false since the first overload ought
> to have been discarded. EDG 6.6 agrees, but clang++, msvc, and icx evaluate
> it to true. Who's right?
>
> Thanks to Patrick for notifying me of this PR. This doesn't fully fix
> 113789; there I think I'll have to figure our why a candidate wasn't
> discarded from the overload set.
>
> gcc/cp/ChangeLog:
>
> * coroutines.cc (coro_rewrite_function_body): Pass tf_warning_or_error
> to build_throw.
> (morph_fn_to_coro): Likewise.
> * cp-tree.h (build_throw): Adjust.
> * except.cc (expand_end_catch_block): Pass tf_warning_or_error to
> build_throw.
> (build_throw): Add a tsubst_flags_t parameter. Use it. Remove
> redundant variable. Guard an inform call.
> * parser.cc (cp_parser_throw_expression): Pass tf_warning_or_error
> to build_throw.
> * pt.cc (tsubst_expr) : Pass complain to build_throw.
>
> libcc1/ChangeLog:
>
> * libcp1plugin.cc (plugin_build_unary_expr): Pass tf_error to
> build_throw.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/cpp0x/sfinae69.C: New test.
> ---
> gcc/cp/coroutines.cc | 4 ++--
> gcc/cp/cp-tree.h | 3 ++-
> gcc/cp/except.cc | 31 +++
> gcc/cp/parser.cc | 2 +-
> gcc/cp/pt.cc | 2 +-
> gcc/testsuite/g++.dg/cpp0x/sfinae69.C | 16 ++
> libcc1/libcp1plugin.cc| 4 ++--
> 7 files changed, 37 insertions(+), 25 deletions(-)
> create mode 100644 gcc/testsuite/g++.dg/cpp0x/sfinae69.C
>
> diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
> index 3194c911e8c..9b037edbd14 100644
> --- a/gcc/cp/coroutines.cc
> +++ b/gcc/cp/coroutines.cc
> @@ -4246,7 +4246,7 @@ coro_rewrite_function_body (location_t fn_start, tree
> fnbody, tree orig,
> boolean_type_node, i_a_r_c);
>finish_if_stmt_cond (not_iarc, not_iarc_if);
>/* If the initial await resume called value is false, rethrow... */
> - tree rethrow = build_throw (fn_start, NULL_TREE);
> + tree rethrow = build_throw (fn_start, NULL_TREE, tf_warning_or_error);
>suppress_warning (rethrow);
>finish_expr_stmt (rethrow);
>finish_then_clause (not_iarc_if);
> @@ -5151,7 +5151,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree
> *destroyer)
>tree del_coro_fr = coro_get_frame_dtor (coro_fp, orig, frame_size,
> promise_type, fn_start);
>finish_expr_stmt (del_coro_fr);
> - tree rethrow = build_throw (fn_start, NULL_TREE);
> + tree rethrow = build_throw (fn_start, NULL_TREE, tf_warning_or_error);
>suppress_warning (rethrow);
>finish_expr_stmt (rethrow);
>finish_handler (handler);
> diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> index 969c7239c97..334c11396c2 100644
> --- a/gcc/cp/cp-tree.h
> +++ b/gcc/cp/cp-tree.h
> @@ -7185,7 +7185,8 @@ extern void init_exception_processing (void);
> extern tree expand_start_catch_block (tree);
> extern void expand_end_catch_block (void);
> extern tree build_exc_ptr(void);
> -extern tree build_throw (location_t, tree);
> +extern tree build_throw (location_t, tree,
> + tsubst_flags_t);
> extern int nothrow_libfn_p (const_tree);
> extern void check_handlers (tree);
> extern tree finish_noexcept_expr (tree, tsubst_flags_t);
> diff --git a/gcc/cp/except.cc b/gcc/cp/except.cc
> index d17a57d3fbc..ed704b6c28a 100644
> --- a/gcc/cp/except.cc
> +++ b/gcc/cp/except.cc
> @@ -486,7 +486,8 @@ expand_end_catch_block (void)
> || DECL_DESTRUCTOR_P (current_function_decl))
>&& !in_nested_catch ())
> {
> - tree rethrow = build_throw (input_location, NULL_TREE);
> + tree rethrow = build_throw (input_location, NULL_TREE,
> + tf_warning_or_error);
>/* Disable all warnings for the generated rethrow statement. */
>suppress_warning (rethrow);
>finish_expr_stmt (rethrow);
> @@ -607,7 +608,7 @@ wrap_cleanups_r (tree
[PATCH]middle-end: add two debug counters for early-break vectorization debugging
Hi All,
This adds two new debug counter to aid in debugging early break code.
- vect_force_last_exit: when reached will always force the final loop exit.
- vect_skip_exit: when reached will skip selecting the current candidate exit
as the loop exit.
The first counter essentially allows you to turn off the PEELED case and the
second counter to pick a different exit, which may mean you pick no exit at
all.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
* dbgcnt.def (vect_force_last_exit, vect_skip_exit): New.
* tree-vect-loop.cc (vec_init_loop_exit_info): Use them.
--- inline copy of patch --
diff --git a/gcc/dbgcnt.def b/gcc/dbgcnt.def
index
ed9f062eac2c28c52df76b39d4312dd9fde1c800..8f7bebf93fceabdf6ae86c2df591eae4848b8a5c
100644
--- a/gcc/dbgcnt.def
+++ b/gcc/dbgcnt.def
@@ -213,5 +213,7 @@ DEBUG_COUNTER (stv_conversion)
DEBUG_COUNTER (tail_call)
DEBUG_COUNTER (tree_sra)
DEBUG_COUNTER (treepre_insert)
+DEBUG_COUNTER (vect_force_last_exit)
DEBUG_COUNTER (vect_loop)
+DEBUG_COUNTER (vect_skip_exit)
DEBUG_COUNTER (vect_slp)
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index
eed2268e9bae7e7ad36d13da03e0b54eab26ef6f..854e9d78bc71721e6559a6bc5dff78c813603a78
100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -58,6 +58,7 @@ along with GCC; see the file COPYING3. If not see
#include "tree-eh.h"
#include "case-cfn-macros.h"
#include "langhooks.h"
+#include "dbgcnt.h"
/* Loop Vectorization Pass.
@@ -977,6 +978,20 @@ vec_init_loop_exit_info (class loop *loop)
if (exits.length () == 1)
return exits[0];
+ /* Check to see if we've been asked to force the last exit. */
+ if (!dbg_cnt (vect_force_last_exit))
+{
+ basic_block bb = ip_normal_pos (loop);
+ if (!bb)
+ return NULL;
+
+ edge exit = EDGE_SUCC (bb, 0);
+ if (exit->dest == loop->latch)
+ return EDGE_SUCC (bb, 1);
+
+ return exit;
+}
+
/* If we have multiple exits we only support counting IV at the moment.
Analyze all exits and return the last one we can analyze. */
class tree_niter_desc niter_desc;
@@ -998,6 +1013,7 @@ vec_init_loop_exit_info (class loop *loop)
&& exit->src == single_pred (loop->latch)
&& (integer_nonzerop (may_be_zero)
|| COMPARISON_CLASS_P (may_be_zero
+ && dbg_cnt (vect_skip_exit)
&& (!candidate
|| dominated_by_p (CDI_DOMINATORS, exit->src,
candidate->src)))
--
diff --git a/gcc/dbgcnt.def b/gcc/dbgcnt.def
index
ed9f062eac2c28c52df76b39d4312dd9fde1c800..8f7bebf93fceabdf6ae86c2df591eae4848b8a5c
100644
--- a/gcc/dbgcnt.def
+++ b/gcc/dbgcnt.def
@@ -213,5 +213,7 @@ DEBUG_COUNTER (stv_conversion)
DEBUG_COUNTER (tail_call)
DEBUG_COUNTER (tree_sra)
DEBUG_COUNTER (treepre_insert)
+DEBUG_COUNTER (vect_force_last_exit)
DEBUG_COUNTER (vect_loop)
+DEBUG_COUNTER (vect_skip_exit)
DEBUG_COUNTER (vect_slp)
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index
eed2268e9bae7e7ad36d13da03e0b54eab26ef6f..854e9d78bc71721e6559a6bc5dff78c813603a78
100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -58,6 +58,7 @@ along with GCC; see the file COPYING3. If not see
#include "tree-eh.h"
#include "case-cfn-macros.h"
#include "langhooks.h"
+#include "dbgcnt.h"
/* Loop Vectorization Pass.
@@ -977,6 +978,20 @@ vec_init_loop_exit_info (class loop *loop)
if (exits.length () == 1)
return exits[0];
+ /* Check to see if we've been asked to force the last exit. */
+ if (!dbg_cnt (vect_force_last_exit))
+{
+ basic_block bb = ip_normal_pos (loop);
+ if (!bb)
+ return NULL;
+
+ edge exit = EDGE_SUCC (bb, 0);
+ if (exit->dest == loop->latch)
+ return EDGE_SUCC (bb, 1);
+
+ return exit;
+}
+
/* If we have multiple exits we only support counting IV at the moment.
Analyze all exits and return the last one we can analyze. */
class tree_niter_desc niter_desc;
@@ -998,6 +1013,7 @@ vec_init_loop_exit_info (class loop *loop)
&& exit->src == single_pred (loop->latch)
&& (integer_nonzerop (may_be_zero)
|| COMPARISON_CLASS_P (may_be_zero
+ && dbg_cnt (vect_skip_exit)
&& (!candidate
|| dominated_by_p (CDI_DOMINATORS, exit->src,
candidate->src)))
[patch,avr,applied] Tidy up gen-avr-mmcu-specs.cc
This patchlet tidies up gen-avr-mmcu-specs.cc.
Some information was computed more than once, in different
functions. The patch uses a new struct to pass around information.
Johann
AVR: Tidy up gen-avr-mmcu-specs.cc
gcc/
* config/avr/gen-avr-mmcu-specs.cc (struct McuInfo): New.
(main, print_mcu, diagnose_mrodata_in_ram): Pass it down.
--diff --git a/gcc/config/avr/gen-avr-mmcu-specs.cc b/gcc/config/avr/gen-avr-mmcu-specs.cc
index 41ebfa82eb5..ea69145d404 100644
--- a/gcc/config/avr/gen-avr-mmcu-specs.cc
+++ b/gcc/config/avr/gen-avr-mmcu-specs.cc
@@ -129,62 +129,70 @@ static const bool have_avrxmega3_rodata_in_flash = false;
#endif
-static void
-diagnose_mrodata_in_ram (FILE *f, const char *spec, const avr_mcu_t *mcu)
+struct McuInfo
{
- enum avr_arch_id arch_id = mcu->arch_id;
- const avr_arch_t *arch = _arch_types[arch_id];
- const bool is_arch = mcu->macro == NULL;
- const bool flmap = (mcu->dev_attribute & AVR_ISA_FLMAP);
- const bool have_flmap2 = have_avrxmega2_flmap && arch_id == ARCH_AVRXMEGA2;
- const bool have_flmap4 = have_avrxmega4_flmap && arch_id == ARCH_AVRXMEGA4;
- const bool have_flmap = flmap && (have_flmap2 || have_flmap4);
-
- const bool rodata_in_flash = (arch_id == ARCH_AVRTINY
-|| (arch_id == ARCH_AVRXMEGA3
-&& have_avrxmega3_rodata_in_flash));
+ enum avr_arch_id arch_id;
+ const avr_arch_t *arch;
+ bool is_arch, is_device;
+ bool flmap, have_flmap2, have_flmap4, have_flmap;
+ bool rodata_in_flash;
// Device name as used by the vendor, extracted from "__AVR___".
char mcu_Name[50] = { 0 };
- if (! is_arch)
-snprintf (mcu_Name, 1 + strlen (mcu->macro) - strlen ("__AVR___"),
- "%s", mcu->macro + strlen ("__AVR_"));
+ McuInfo (const avr_mcu_t *mcu)
+: arch_id (mcu->arch_id), arch (& avr_arch_types[arch_id]),
+ is_arch (mcu->macro == NULL), is_device (! is_arch),
+ flmap (mcu->dev_attribute & AVR_ISA_FLMAP),
+ have_flmap2 (have_avrxmega2_flmap && arch_id == ARCH_AVRXMEGA2),
+ have_flmap4 (have_avrxmega4_flmap && arch_id == ARCH_AVRXMEGA4),
+ have_flmap (flmap && (have_flmap2 || have_flmap4)),
+ rodata_in_flash (arch_id == ARCH_AVRTINY
+ || (arch_id == ARCH_AVRXMEGA3
+ && have_avrxmega3_rodata_in_flash))
+ {
+if (is_device)
+ snprintf (mcu_Name, 1 + strlen (mcu->macro) - strlen ("__AVR_" "__"),
+ "%s", mcu->macro + strlen ("__AVR_"));
+ }
+};
+
+
+static void
+diagnose_mrodata_in_ram (FILE *f, const char *spec, const avr_mcu_t *mcu,
+ const McuInfo )
+{
fprintf (f, "%s:\n", spec);
- if (rodata_in_flash && is_arch)
+ if (mi.rodata_in_flash && mi.is_arch)
fprintf (f, "\t%%{mrodata-in-ram: %%e-mrodata-in-ram is not supported"
" for %s}", mcu->name);
- else if (rodata_in_flash)
+ else if (mi.rodata_in_flash)
fprintf (f, "\t%%{mrodata-in-ram: %%e-mrodata-in-ram is not supported"
- " for %s (arch=%s)}", mcu_Name, arch->name);
- else if (is_arch)
+ " for %s (arch=%s)}", mi.mcu_Name, mi.arch->name);
+ else if (mi.is_arch)
{
- if (! have_flmap2 && ! have_flmap4)
+ if (! mi.have_flmap2 && ! mi.have_flmap4)
fprintf (f, "\t%%{mno-rodata-in-ram: %%e-mno-rodata-in-ram is not"
" supported for %s}", mcu->name);
}
- else if (! have_flmap)
+ else if (! mi.have_flmap)
fprintf (f, "\t%%{mno-rodata-in-ram: %%e-mno-rodata-in-ram is not supported"
- " for %s (arch=%s)}", mcu_Name, arch->name);
+ " for %s (arch=%s)}", mi.mcu_Name, mi.arch->name);
fprintf (f, "\n\n");
}
static void
-print_mcu (const avr_mcu_t *mcu)
+print_mcu (const avr_mcu_t *mcu, const McuInfo )
{
const char *sp8_spec;
const char *rcall_spec;
const avr_mcu_t *arch_mcu;
- const avr_arch_t *arch;
- enum avr_arch_id arch_id = mcu->arch_id;
for (arch_mcu = mcu; arch_mcu->macro; )
arch_mcu--;
- if (arch_mcu->arch_id != arch_id)
+ if (arch_mcu->arch_id != mi.arch_id)
exit (EXIT_FAILURE);
- arch = _arch_types[arch_id];
-
char name[100];
if (snprintf (name, sizeof name, "specs-%s", mcu->name) >= (int) sizeof name)
exit (EXIT_FAILURE);
@@ -196,29 +204,26 @@ print_mcu (const avr_mcu_t *mcu)
bool rmw = (mcu->dev_attribute & AVR_ISA_RMW) != 0;
bool sp8 = (mcu->dev_attribute & AVR_SHORT_SP) != 0;
bool rcall = (mcu->dev_attribute & AVR_ISA_RCALL);
- bool flmap = (mcu->dev_attribute & AVR_ISA_FLMAP);
- bool is_arch = mcu->macro == NULL;
- bool is_device = ! is_arch;
int rodata_pm_offset = 0;
int pm_base_address = 0;
- if (arch->flash_pm_offset
+ if (mi.arch->flash_pm_offset
&& mcu->flash_pm_offset
- && mcu->flash_pm_offset != arch->flash_pm_offset)
+ && mcu->flash_pm_offset != mi.arch->flash_pm_offset)
{
rodata_pm_offset = mcu->flash_pm_offset;
}
- if (arch->flash_pm_offset)
+ if (mi.arch->flash_pm_offset)
{
pm_base_address = mcu->flash_pm_offset
? mcu->flash_pm_offset
- : arch->flash_pm_offset;
+ : mi.arch->flash_pm_offset;
[patch,avr,applied] PR113824: Fix multilib set for ATA5795
This device was in the wrong multilib set.
Johann
--
AVR: target/113824 - Fix multilib set for ATA5795.
gcc/
PR target/113824
* config/avr/avr-mcus.def (ata5797): Move from avr5 to avr4.
* doc/avr-mmcu.texi: Rebuild.diff --git a/gcc/config/avr/avr-mcus.def b/gcc/config/avr/avr-mcus.def
index 7ddfba0a13c..27812d441f7 100644
--- a/gcc/config/avr/avr-mcus.def
+++ b/gcc/config/avr/avr-mcus.def
@@ -138,9 +138,10 @@ AVR_MCU ("attiny167",ARCH_AVR35, AVR_ISA_NONE, "__AVR_ATtiny167__",
AVR_MCU ("attiny1634", ARCH_AVR35, AVR_ISA_NONE, "__AVR_ATtiny1634__", 0x0100, 0x0, 0x4000, 0)
/* Enhanced, <= 8K. */
AVR_MCU ("avr4", ARCH_AVR4, AVR_ISA_NONE, NULL, 0x0060, 0x0, 0x2000, 0)
+AVR_MCU ("ata5795", ARCH_AVR4, AVR_ISA_NONE, "__AVR_ATA5795__", 0x0100, 0x0, 0x2000, 0)
AVR_MCU ("ata6285", ARCH_AVR4, AVR_ISA_NONE, "__AVR_ATA6285__", 0x0100, 0x0, 0x2000, 0)
AVR_MCU ("ata6286", ARCH_AVR4, AVR_ISA_NONE, "__AVR_ATA6286__", 0x0100, 0x0, 0x2000, 0)
-AVR_MCU ("ata6289", ARCH_AVR4, AVR_ISA_NONE, "__AVR_ATA6289__", 0x0100, 0x0, 0x2000, 0)
+AVR_MCU ("ata6289", ARCH_AVR4, AVR_ISA_NONE, "__AVR_ATA6289__", 0x0100, 0x0, 0x2000, 0)
AVR_MCU ("ata6612c", ARCH_AVR4, AVR_ISA_NONE, "__AVR_ATA6612C__", 0x0100, 0x0, 0x2000, 0)
AVR_MCU ("atmega8", ARCH_AVR4, AVR_ISA_NONE, "__AVR_ATmega8__", 0x0060, 0x0, 0x2000, 0)
AVR_MCU ("atmega8a", ARCH_AVR4, AVR_ISA_NONE, "__AVR_ATmega8A__", 0x0060, 0x0, 0x2000, 0)
@@ -172,7 +173,6 @@ AVR_MCU ("ata5787", ARCH_AVR5, AVR_ISA_NONE, "__AVR_ATA5787__",
AVR_MCU ("ata5790", ARCH_AVR5, AVR_ISA_NONE, "__AVR_ATA5790__", 0x0100, 0x0, 0x4000, 0)
AVR_MCU ("ata5790n", ARCH_AVR5, AVR_ISA_NONE, "__AVR_ATA5790N__", 0x0100, 0x0, 0x4000, 0)
AVR_MCU ("ata5791", ARCH_AVR5, AVR_ISA_NONE, "__AVR_ATA5791__", 0x0100, 0x0, 0x4000, 0)
-AVR_MCU ("ata5795", ARCH_AVR5, AVR_ISA_NONE, "__AVR_ATA5795__", 0x0100, 0x0, 0x2000, 0)
AVR_MCU ("ata5831", ARCH_AVR5, AVR_ISA_NONE, "__AVR_ATA5831__", 0x0200, 0x8000, 0xd000, 0)
AVR_MCU ("ata5835", ARCH_AVR5, AVR_ISA_NONE, "__AVR_ATA5835__", 0x0200, 0x8000, 0xd200, 0)
AVR_MCU ("ata6613c", ARCH_AVR5, AVR_ISA_NONE, "__AVR_ATA6613C__", 0x0100, 0x0, 0x4000, 0)
diff --git a/gcc/doc/avr-mmcu.texi b/gcc/doc/avr-mmcu.texi
index f38a0e06343..dcbf4ef7247 100644
--- a/gcc/doc/avr-mmcu.texi
+++ b/gcc/doc/avr-mmcu.texi
@@ -34,11 +34,11 @@
@item @anchor{avr4}avr4
``Enhanced'' devices with up to 8@tie{}KiB of program memory.
-@*@var{mcu}@tie{}= @code{atmega48}, @code{atmega48a}, @code{atmega48p}, @code{atmega48pa}, @code{atmega48pb}, @code{atmega8}, @code{atmega8a}, @code{atmega8hva}, @code{atmega88}, @code{atmega88a}, @code{atmega88p}, @code{atmega88pa}, @code{atmega88pb}, @code{atmega8515}, @code{atmega8535}, @code{ata6285}, @code{ata6286}, @code{ata6289}, @code{ata6612c}, @code{at90pwm1}, @code{at90pwm2}, @code{at90pwm2b}, @code{at90pwm3}, @code{at90pwm3b}, @code{at90pwm81}.
+@*@var{mcu}@tie{}= @code{atmega48}, @code{atmega48a}, @code{atmega48p}, @code{atmega48pa}, @code{atmega48pb}, @code{atmega8}, @code{atmega8a}, @code{atmega8hva}, @code{atmega88}, @code{atmega88a}, @code{atmega88p}, @code{atmega88pa}, @code{atmega88pb}, @code{atmega8515}, @code{atmega8535}, @code{ata5795}, @code{ata6285}, @code{ata6286}, @code{ata6289}, @code{ata6612c}, @code{at90pwm1}, @code{at90pwm2}, @code{at90pwm2b}, @code{at90pwm3}, @code{at90pwm3b}, @code{at90pwm81}.
@item @anchor{avr5}avr5
``Enhanced'' devices with 16@tie{}KiB up to 64@tie{}KiB of program memory.
-@*@var{mcu}@tie{}= @code{atmega16}, @code{atmega16a}, @code{atmega16hva}, @code{atmega16hva2}, @code{atmega16hvb}, @code{atmega16hvbrevb}, @code{atmega16m1}, @code{atmega16u4}, @code{atmega161}, @code{atmega162}, @code{atmega163}, @code{atmega164a}, @code{atmega164p}, @code{atmega164pa}, @code{atmega165}, @code{atmega165a}, @code{atmega165p}, @code{atmega165pa}, @code{atmega168}, @code{atmega168a}, @code{atmega168p}, @code{atmega168pa}, @code{atmega168pb}, @code{atmega169}, @code{atmega169a}, @code{atmega169p}, @code{atmega169pa}, @code{atmega32}, @code{atmega32a}, @code{atmega32c1}, @code{atmega32hvb}, @code{atmega32hvbrevb}, @code{atmega32m1}, @code{atmega32u4}, @code{atmega32u6}, @code{atmega323}, @code{atmega324a}, @code{atmega324p}, @code{atmega324pa}, @code{atmega324pb}, @code{atmega325}, @code{atmega325a}, @code{atmega325p}, @code{atmega325pa}, @code{atmega328}, @code{atmega328p}, @code{atmega328pb}, @code{atmega329}, @code{atmega329a}, @code{atmega329p}, @code{atmega329pa}, @code{atmega3250}, @code{atmega3250a}, @code{atmega3250p}, @code{atmega3250pa}, @code{atmega3290}, @code{atmega3290a}, @code{atmega3290p}, @code{atmega3290pa}, @code{atmega406}, @code{atmega64}, @code{atmega64a},
Re: [PATCH]middle-end: don't cache restart_loop in vectorizable_live_operations [PR113808]
On Thu, Feb 08, 2024 at 10:54:07AM +, Tamar Christina wrote: > > Please either drop lastprivate(k) clause or use linear(k:1) > > The iteration var of simd loop without collapse or with > > collapse(1) is implicitly linear with the step, and even linear > > means the value from the last iteration can be used after the > > simd construct. Overriding the data sharing to something different > > has been only added recently to OpenMP and isn't really needed here. > > > > Sorry I know very little about fortran, is this ok? > > Regtested on aarch64-none-linux-gnu and no issues. > > Ok for master? > > Thanks, > Tamar > > gcc/testsuite/ChangeLog: > > PR tree-optimization/113808 > * gfortran.dg/vect/vect-early-break_1-PR113808.f90: Moved to... > * gfortran.dg/vect/vect-early-break_1-pr113808.f90: ...here. Yes, thanks. Jakub
RE: [PATCH]middle-end: don't cache restart_loop in vectorizable_live_operations [PR113808]
> Please either drop lastprivate(k) clause or use linear(k:1) > The iteration var of simd loop without collapse or with > collapse(1) is implicitly linear with the step, and even linear > means the value from the last iteration can be used after the > simd construct. Overriding the data sharing to something different > has been only added recently to OpenMP and isn't really needed here. > Sorry I know very little about fortran, is this ok? Regtested on aarch64-none-linux-gnu and no issues. Ok for master? Thanks, Tamar gcc/testsuite/ChangeLog: PR tree-optimization/113808 * gfortran.dg/vect/vect-early-break_1-PR113808.f90: Moved to... * gfortran.dg/vect/vect-early-break_1-pr113808.f90: ...here. --- inline copy of patch --- diff --git a/gcc/testsuite/gfortran.dg/vect/vect-early-break_1-PR113808.f90 b/gcc/testsuite/gfortran.dg/vect/vect-early-break_1-pr113808.f90 similarity index 93% rename from gcc/testsuite/gfortran.dg/vect/vect-early-break_1-PR113808.f90 rename to gcc/testsuite/gfortran.dg/vect/vect-early-break_1-pr113808.f90 index 5c339fa7a348fac5527bbbf456a535da96b5c1ed..6f92e9095bdee08a5a9db2816f57da6c14d91b11 100644 --- a/gcc/testsuite/gfortran.dg/vect/vect-early-break_1-PR113808.f90 +++ b/gcc/testsuite/gfortran.dg/vect/vect-early-break_1-pr113808.f90 @@ -9,7 +9,7 @@ program main integer :: n, i,k n = 11 do i = 1, n,2 -!$omp simd lastprivate(k) +!$omp simd do k = 1, i + 41 if (k > 11 + 41 .or. k < 1) error stop end do rb18253.patch Description: rb18253.patch
Re: [PATCH]middle-end: don't cache restart_loop in vectorizable_live_operations [PR113808]
On Thu, Feb 08, 2024 at 10:37:14AM +, Tamar Christina wrote:
> PR tree-optimization/113808
> * tree-vect-loop.cc (vectorizable_live_operation): Don't cache the
> value cross iterations.
>
> gcc/testsuite/ChangeLog:
>
> PR tree-optimization/113808
> * gfortran.dg/vect/vect-early-break_1-PR113808.f90: New test.
Please use lowercase pr instead of PR for consistency with all the other
tests in the directory.
> --- inline copy of patch --
> diff --git a/gcc/testsuite/gfortran.dg/vect/vect-early-break_1-PR113808.f90
> b/gcc/testsuite/gfortran.dg/vect/vect-early-break_1-PR113808.f90
> new file mode 100644
> index
> ..5c339fa7a348fac5527bbbf456a535da96b5c1ed
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/vect/vect-early-break_1-PR113808.f90
> @@ -0,0 +1,21 @@
> +! { dg-add-options vect_early_break }
> +! { dg-require-effective-target vect_early_break }
> +! { dg-require-effective-target vect_long_long }
> +! { dg-additional-options "-fopenmp-simd" }
> +
> +! { dg-final { scan-tree-dump "LOOP VECTORIZED" "vect" } }
> +
> +program main
> + integer :: n, i,k
> + n = 11
> + do i = 1, n,2
> +!$omp simd lastprivate(k)
Please either drop lastprivate(k) clause or use linear(k:1)
The iteration var of simd loop without collapse or with
collapse(1) is implicitly linear with the step, and even linear
means the value from the last iteration can be used after the
simd construct. Overriding the data sharing to something different
has been only added recently to OpenMP and isn't really needed here.
> +do k = 1, i + 41
> + if (k > 11 + 41 .or. k < 1) error stop
> +end do
> + end do
> + if (k /= 53) then
> +print *, k, 53
> +error stop
> + endif
> +end
Jakub
[patch, avr, applied] Specs always define __AVR_PM_BASE_ADDRESS__ when the core has it
This defines the spec always when the core has it, not only
override it when it differs from the core's value.
Johann
--
AVR: Always define __AVR_PM_BASE_ADDRESS__ in specs provided the core
has it.
gcc/
* config/avr/gen-avr-mmcu-specs.cc (print_mcu) <*cpp_mcu>: Spec always
defines __AVR_PM_BASE_ADDRESS__ if the core has it.
diff --git a/gcc/config/avr/gen-avr-mmcu-specs.cc b/gcc/config/avr/gen-avr-mmcu-specs.cc
index 06d9d3c8d7d..41ebfa82eb5 100644
--- a/gcc/config/avr/gen-avr-mmcu-specs.cc
+++ b/gcc/config/avr/gen-avr-mmcu-specs.cc
@@ -199,13 +199,21 @@ print_mcu (const avr_mcu_t *mcu)
bool flmap = (mcu->dev_attribute & AVR_ISA_FLMAP);
bool is_arch = mcu->macro == NULL;
bool is_device = ! is_arch;
- int flash_pm_offset = 0;
+ int rodata_pm_offset = 0;
+ int pm_base_address = 0;
if (arch->flash_pm_offset
&& mcu->flash_pm_offset
&& mcu->flash_pm_offset != arch->flash_pm_offset)
{
- flash_pm_offset = mcu->flash_pm_offset;
+ rodata_pm_offset = mcu->flash_pm_offset;
+}
+
+ if (arch->flash_pm_offset)
+{
+ pm_base_address = mcu->flash_pm_offset
+ ? mcu->flash_pm_offset
+ : arch->flash_pm_offset;
}
if (is_arch
@@ -339,8 +347,8 @@ print_mcu (const avr_mcu_t *mcu)
fprintf (f, "*link_arch:\n\t%s", link_arch_spec);
if (is_device
- && flash_pm_offset)
-fprintf (f, " --defsym=__RODATA_PM_OFFSET__=0x%x", flash_pm_offset);
+ && rodata_pm_offset)
+fprintf (f, " --defsym=__RODATA_PM_OFFSET__=0x%x", rodata_pm_offset);
fprintf (f, "\n\n");
if (is_device)
@@ -381,10 +389,10 @@ print_mcu (const avr_mcu_t *mcu)
fprintf (f, "*cpp_mcu:\n");
fprintf (f, "\t-D%s", mcu->macro);
- if (flash_pm_offset)
+ if (pm_base_address)
{
fprintf (f, " -U__AVR_PM_BASE_ADDRESS__");
- fprintf (f, " -D__AVR_PM_BASE_ADDRESS__=0x%x", flash_pm_offset);
+ fprintf (f, " -D__AVR_PM_BASE_ADDRESS__=0x%x", pm_base_address);
}
if (have_flmap)
fprintf (f, " -D__AVR_HAVE_FLMAP__");
[PATCH] Revert part of vect_analyze_early_break_dependences changes
I've reconsidered my last change to dr_may_alias_p and decided
it was correct before. The following reverts that change.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-data-refs.cc (vect_analyze_early_break_dependences):
Revert last change to dr_may_alias_p.
---
gcc/tree-vect-data-refs.cc | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
index e16796323b3..2170d17e839 100644
--- a/gcc/tree-vect-data-refs.cc
+++ b/gcc/tree-vect-data-refs.cc
@@ -772,11 +772,7 @@ vect_analyze_early_break_dependences (loop_vec_info
loop_vinfo)
the store. */
for (auto dr_read : bases)
- /* Note we're not passing the DRs in stmt order here
- since the DR dependence checking routine does not
- envision we're moving stores down. The read-write
- order tricks it to avoid applying TBAA. */
- if (dr_may_alias_p (dr_read, dr_ref, loop_nest))
+ if (dr_may_alias_p (dr_ref, dr_read, loop_nest))
{
if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION,
--
2.35.3
Re: [PATCH]middle-end: don't cache restart_loop in vectorizable_live_operations [PR113808]
On Thu, 8 Feb 2024, Tamar Christina wrote:
> Hi All,
>
> There's a bug in vectorizable_live_operation that restart_loop is defined
> outside the loop.
>
> This variable is supposed to indicate whether we are doing a first or last
> index reduction. The problem is that by defining it outside the loop it
> becomes
> dependent on the order we visit the USE/DEFs.
>
> In the given example, the loop isn't PEELED, but we visit the early exit uses
> first. This then sets the boolean to true and it can't get to false again.
>
> So when we visit the main exit we still treat it as an early exit for that
> SSA name.
>
> This cleans it up and renames the variables to something that's hopefully
> clearer to their intention.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and
> x86_64-pc-linux-gnu no issues.
>
> Ok for master?
OK.
Thanks,
Richard.
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> PR tree-optimization/113808
> * tree-vect-loop.cc (vectorizable_live_operation): Don't cache the
> value cross iterations.
>
> gcc/testsuite/ChangeLog:
>
> PR tree-optimization/113808
> * gfortran.dg/vect/vect-early-break_1-PR113808.f90: New test.
>
> --- inline copy of patch --
> diff --git a/gcc/testsuite/gfortran.dg/vect/vect-early-break_1-PR113808.f90
> b/gcc/testsuite/gfortran.dg/vect/vect-early-break_1-PR113808.f90
> new file mode 100644
> index
> ..5c339fa7a348fac5527bbbf456a535da96b5c1ed
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/vect/vect-early-break_1-PR113808.f90
> @@ -0,0 +1,21 @@
> +! { dg-add-options vect_early_break }
> +! { dg-require-effective-target vect_early_break }
> +! { dg-require-effective-target vect_long_long }
> +! { dg-additional-options "-fopenmp-simd" }
> +
> +! { dg-final { scan-tree-dump "LOOP VECTORIZED" "vect" } }
> +
> +program main
> + integer :: n, i,k
> + n = 11
> + do i = 1, n,2
> +!$omp simd lastprivate(k)
> +do k = 1, i + 41
> + if (k > 11 + 41 .or. k < 1) error stop
> +end do
> + end do
> + if (k /= 53) then
> +print *, k, 53
> +error stop
> + endif
> +end
> diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> index
> 190df9ec7741fd05aa0b9abe150baf06b2ca9a57..eed2268e9bae7e7ad36d13da03e0b54eab26ef6f
> 100644
> --- a/gcc/tree-vect-loop.cc
> +++ b/gcc/tree-vect-loop.cc
> @@ -10950,7 +10950,7 @@ vectorizable_live_operation (vec_info *vinfo,
> stmt_vec_info stmt_info,
>did. For the live values we want the value at the start of the
> iteration
>rather than at the end. */
>edge main_e = LOOP_VINFO_IV_EXIT (loop_vinfo);
> - bool restart_loop = LOOP_VINFO_EARLY_BREAKS_VECT_PEELED (loop_vinfo);
> + bool all_exits_as_early_p = LOOP_VINFO_EARLY_BREAKS_VECT_PEELED
> (loop_vinfo);
>FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, lhs)
> if (!is_gimple_debug (use_stmt)
> && !flow_bb_inside_loop_p (loop, gimple_bb (use_stmt)))
> @@ -10966,8 +10966,7 @@ vectorizable_live_operation (vec_info *vinfo,
> stmt_vec_info stmt_info,
> /* For early exit where the exit is not in the BB that leads
>to the latch then we're restarting the iteration in the
>scalar loop. So get the first live value. */
> - restart_loop = restart_loop || !main_exit_edge;
> - if (restart_loop
> + if ((all_exits_as_early_p || !main_exit_edge)
> && STMT_VINFO_DEF_TYPE (stmt_info) == vect_induction_def)
> {
> tmp_vec_lhs = vec_lhs0;
>
>
>
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
[PATCH]middle-end: don't cache restart_loop in vectorizable_live_operations [PR113808]
Hi All,
There's a bug in vectorizable_live_operation that restart_loop is defined
outside the loop.
This variable is supposed to indicate whether we are doing a first or last
index reduction. The problem is that by defining it outside the loop it becomes
dependent on the order we visit the USE/DEFs.
In the given example, the loop isn't PEELED, but we visit the early exit uses
first. This then sets the boolean to true and it can't get to false again.
So when we visit the main exit we still treat it as an early exit for that
SSA name.
This cleans it up and renames the variables to something that's hopefully
clearer to their intention.
Bootstrapped Regtested on aarch64-none-linux-gnu and
x86_64-pc-linux-gnu no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
PR tree-optimization/113808
* tree-vect-loop.cc (vectorizable_live_operation): Don't cache the
value cross iterations.
gcc/testsuite/ChangeLog:
PR tree-optimization/113808
* gfortran.dg/vect/vect-early-break_1-PR113808.f90: New test.
--- inline copy of patch --
diff --git a/gcc/testsuite/gfortran.dg/vect/vect-early-break_1-PR113808.f90
b/gcc/testsuite/gfortran.dg/vect/vect-early-break_1-PR113808.f90
new file mode 100644
index
..5c339fa7a348fac5527bbbf456a535da96b5c1ed
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/vect/vect-early-break_1-PR113808.f90
@@ -0,0 +1,21 @@
+! { dg-add-options vect_early_break }
+! { dg-require-effective-target vect_early_break }
+! { dg-require-effective-target vect_long_long }
+! { dg-additional-options "-fopenmp-simd" }
+
+! { dg-final { scan-tree-dump "LOOP VECTORIZED" "vect" } }
+
+program main
+ integer :: n, i,k
+ n = 11
+ do i = 1, n,2
+!$omp simd lastprivate(k)
+do k = 1, i + 41
+ if (k > 11 + 41 .or. k < 1) error stop
+end do
+ end do
+ if (k /= 53) then
+print *, k, 53
+error stop
+ endif
+end
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index
190df9ec7741fd05aa0b9abe150baf06b2ca9a57..eed2268e9bae7e7ad36d13da03e0b54eab26ef6f
100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -10950,7 +10950,7 @@ vectorizable_live_operation (vec_info *vinfo,
stmt_vec_info stmt_info,
did. For the live values we want the value at the start of the
iteration
rather than at the end. */
edge main_e = LOOP_VINFO_IV_EXIT (loop_vinfo);
- bool restart_loop = LOOP_VINFO_EARLY_BREAKS_VECT_PEELED (loop_vinfo);
+ bool all_exits_as_early_p = LOOP_VINFO_EARLY_BREAKS_VECT_PEELED
(loop_vinfo);
FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, lhs)
if (!is_gimple_debug (use_stmt)
&& !flow_bb_inside_loop_p (loop, gimple_bb (use_stmt)))
@@ -10966,8 +10966,7 @@ vectorizable_live_operation (vec_info *vinfo,
stmt_vec_info stmt_info,
/* For early exit where the exit is not in the BB that leads
to the latch then we're restarting the iteration in the
scalar loop. So get the first live value. */
- restart_loop = restart_loop || !main_exit_edge;
- if (restart_loop
+ if ((all_exits_as_early_p || !main_exit_edge)
&& STMT_VINFO_DEF_TYPE (stmt_info) == vect_induction_def)
{
tmp_vec_lhs = vec_lhs0;
--
diff --git a/gcc/testsuite/gfortran.dg/vect/vect-early-break_1-PR113808.f90
b/gcc/testsuite/gfortran.dg/vect/vect-early-break_1-PR113808.f90
new file mode 100644
index
..5c339fa7a348fac5527bbbf456a535da96b5c1ed
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/vect/vect-early-break_1-PR113808.f90
@@ -0,0 +1,21 @@
+! { dg-add-options vect_early_break }
+! { dg-require-effective-target vect_early_break }
+! { dg-require-effective-target vect_long_long }
+! { dg-additional-options "-fopenmp-simd" }
+
+! { dg-final { scan-tree-dump "LOOP VECTORIZED" "vect" } }
+
+program main
+ integer :: n, i,k
+ n = 11
+ do i = 1, n,2
+!$omp simd lastprivate(k)
+do k = 1, i + 41
+ if (k > 11 + 41 .or. k < 1) error stop
+end do
+ end do
+ if (k /= 53) then
+print *, k, 53
+error stop
+ endif
+end
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index
190df9ec7741fd05aa0b9abe150baf06b2ca9a57..eed2268e9bae7e7ad36d13da03e0b54eab26ef6f
100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -10950,7 +10950,7 @@ vectorizable_live_operation (vec_info *vinfo,
stmt_vec_info stmt_info,
did. For the live values we want the value at the start of the
iteration
rather than at the end. */
edge main_e = LOOP_VINFO_IV_EXIT (loop_vinfo);
- bool restart_loop = LOOP_VINFO_EARLY_BREAKS_VECT_PEELED (loop_vinfo);
+ bool all_exits_as_early_p = LOOP_VINFO_EARLY_BREAKS_VECT_PEELED
(loop_vinfo);
FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, lhs)
if (!is_gimple_debug (use_stmt)
&& !flow_bb_inside_loop_p
[PATCH][committed]middle-end: fix pointer conversion error in testcase vect-early-break_110-pr113467.c
Hi All,
I had missed a conversion from unsigned long to uint64_t.
This fixes the failing test on -m32.
Regtested on x86_64-pc-linux-gnu with -m32 and no issues.
Committed as obvious.
Thanks,
Tamar
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-early-break_110-pr113467.c: Change unsigned long *
to uint64_t *.
--- inline copy of patch --
diff --git a/gcc/testsuite/gcc.dg/vect/vect-early-break_110-pr113467.c
b/gcc/testsuite/gcc.dg/vect/vect-early-break_110-pr113467.c
index
1e2c47be5fdf1e1fed88e4b5f45d7eda6c3b85d1..12d0ea1e871b51742c040c909ea5741bc820206e
100644
--- a/gcc/testsuite/gcc.dg/vect/vect-early-break_110-pr113467.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-early-break_110-pr113467.c
@@ -10,7 +10,7 @@
typedef struct gcry_mpi *gcry_mpi_t;
struct gcry_mpi {
int nlimbs;
- unsigned long *d;
+ uint64_t *d;
};
long gcry_mpi_add_ui_up;
--
diff --git a/gcc/testsuite/gcc.dg/vect/vect-early-break_110-pr113467.c
b/gcc/testsuite/gcc.dg/vect/vect-early-break_110-pr113467.c
index
1e2c47be5fdf1e1fed88e4b5f45d7eda6c3b85d1..12d0ea1e871b51742c040c909ea5741bc820206e
100644
--- a/gcc/testsuite/gcc.dg/vect/vect-early-break_110-pr113467.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-early-break_110-pr113467.c
@@ -10,7 +10,7 @@
typedef struct gcry_mpi *gcry_mpi_t;
struct gcry_mpi {
int nlimbs;
- unsigned long *d;
+ uint64_t *d;
};
long gcry_mpi_add_ui_up;
[PATCH] libstdc++: Use _GLIBCXX_USE_BUILTIN_TRAIT for is_same
Since is_same has a fallback native implementation, and
_GLIBCXX_HAVE_BUILTIN_IS_SAME does not support toggling which
implementation to use, we remove the _GLIBCXX_HAVE_BUILTIN_IS_SAME
definition and use _GLIBCXX_USE_BUILTIN_TRAIT instead.
libstdc++-v3/ChangeLog:
* include/bits/c++config (_GLIBCXX_HAVE_BUILTIN_IS_SAME):
Removed.
* include/std/type_traits (is_same): Use
_GLIBCXX_USE_BUILTIN_TRAIT instead of
_GLIBCXX_HAVE_BUILTIN_IS_SAME.
(is_same_v): Likewise.
Signed-off-by: Ken Matsui
---
libstdc++-v3/include/bits/c++config | 4
libstdc++-v3/include/std/type_traits | 9 +
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/libstdc++-v3/include/bits/c++config
b/libstdc++-v3/include/bits/c++config
index ad07ce92d5f..b57e3f338e9 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -845,10 +845,6 @@ namespace __gnu_cxx
# define _GLIBCXX_HAVE_BUILTIN_IS_AGGREGATE 1
#endif
-#if _GLIBCXX_HAS_BUILTIN(__is_same)
-# define _GLIBCXX_HAVE_BUILTIN_IS_SAME 1
-#endif
-
#if _GLIBCXX_HAS_BUILTIN(__builtin_launder)
# define _GLIBCXX_HAVE_BUILTIN_LAUNDER 1
#endif
diff --git a/libstdc++-v3/include/std/type_traits
b/libstdc++-v3/include/std/type_traits
index a9bb2806ca9..21402fd8c13 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -1470,16 +1470,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// Type relations.
/// is_same
+#if _GLIBCXX_USE_BUILTIN_TRAIT(__is_same)
template
struct is_same
-#ifdef _GLIBCXX_HAVE_BUILTIN_IS_SAME
: public __bool_constant<__is_same(_Tp, _Up)>
+{ };
#else
+ template
+struct is_same
: public false_type
-#endif
{ };
-#ifndef _GLIBCXX_HAVE_BUILTIN_IS_SAME
template
struct is_same<_Tp, _Tp>
: public true_type
@@ -3496,7 +3497,7 @@ template
template
inline constexpr size_t extent_v<_Tp[], _Idx> = extent_v<_Tp, _Idx - 1>;
-#ifdef _GLIBCXX_HAVE_BUILTIN_IS_SAME
+#if _GLIBCXX_USE_BUILTIN_TRAIT(__is_same)
template
inline constexpr bool is_same_v = __is_same(_Tp, _Up);
#else
--
2.43.0
[PATCH] ipa: Avoid excessive removing of SSAs (PR 113757)
Hi,
PR 113757 shows that the code which was meant to debug-reset and
remove SSAs defined by LHSs of calls redirected to
__builtin_unreachable can trigger also when speculative
devirtualization creates a call to a noreturn function (and since it
is noreturn, it does not bother dealing with its return value).
What is more, it seems that the code handling this case is not really
necessary. I feel slightly idiotic about this because I have a
feeling that I added it because of a failing test-case but I can
neither find the testcase nor a reason why the code in
cgraph_edge::redirect_call_stmt_to_callee would not be sufficient (it
turns the SSA name into a default-def, a bit like IPA-SRA, but any
code dominated by a call to a noreturn is not dangerous when it comes
to its side-effects). So this patch just removes the handling.
Bootstrapped and tested on x86_64-linux and ppc64le-linux. I have also
LTO-bootstrapped and LTO-profilebootstrapped the patch on x86_64-linux.
OK for master?
Thanks,
Martin
gcc/ChangeLog:
2024-02-07 Martin Jambor
PR ipa/113757
* tree-inline.cc (redirect_all_calls): Remove code adding SSAs to
id->killed_new_ssa_names.
gcc/testsuite/ChangeLog:
2024-02-07 Martin Jambor
PR ipa/113757
* g++.dg/ipa/pr113757.C: New test.
---
gcc/testsuite/g++.dg/ipa/pr113757.C | 14 ++
gcc/tree-inline.cc | 14 ++
2 files changed, 16 insertions(+), 12 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/ipa/pr113757.C
diff --git a/gcc/testsuite/g++.dg/ipa/pr113757.C
b/gcc/testsuite/g++.dg/ipa/pr113757.C
new file mode 100644
index 000..885d4010a10
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr113757.C
@@ -0,0 +1,14 @@
+// { dg-do compile }
+// { dg-options "-O2 -fPIC" }
+// { dg-require-effective-target fpic }
+
+long size();
+struct ll { virtual int hh(); };
+ll *slice_owner;
+int ll::hh() { __builtin_exit(0); }
+int nn() {
+ if (size())
+return 0;
+ return slice_owner->hh();
+}
+int (*a)() = nn;
diff --git a/gcc/tree-inline.cc b/gcc/tree-inline.cc
index 75c10eb7dfc..cac41b4f031 100644
--- a/gcc/tree-inline.cc
+++ b/gcc/tree-inline.cc
@@ -2984,23 +2984,13 @@ redirect_all_calls (copy_body_data * id, basic_block bb)
gimple *stmt = gsi_stmt (si);
if (is_gimple_call (stmt))
{
- tree old_lhs = gimple_call_lhs (stmt);
struct cgraph_edge *edge = id->dst_node->get_edge (stmt);
if (edge)
{
if (!id->killed_new_ssa_names)
id->killed_new_ssa_names = new hash_set (16);
- gimple *new_stmt
- = cgraph_edge::redirect_call_stmt_to_callee (edge,
- id->killed_new_ssa_names);
- if (old_lhs
- && TREE_CODE (old_lhs) == SSA_NAME
- && !gimple_call_lhs (new_stmt))
- /* In case of IPA-SRA removing the LHS, the name should have
- been already added to the hash. But in case of redirecting
- to builtin_unreachable it was not and the name still should
- be pruned from debug statements. */
- id->killed_new_ssa_names->add (old_lhs);
+ cgraph_edge::redirect_call_stmt_to_callee (edge,
+ id->killed_new_ssa_names);
if (stmt == last && id->call_stmt && maybe_clean_eh_stmt (stmt))
gimple_purge_dead_eh_edges (bb);
--
2.43.0
[patch,avr,applied]: Rename %_misc specs.
This renames pecs like cc1_misc to cc1_rodata_in_ram to
point out their purpose.
Johann
--
AVR: Rename device-specs %_misc to %_rodata_in_ram.
gcc/
* config/avr/gen-avr-mmcu-specs.cc: Rename spec cc1_misc to
cc1_rodata_in_ram. Rename spec link_misc to link_rodata_in_ram.
Remove spec asm_misc.
* config/avr/specs.h: Same.
diff --git a/gcc/config/avr/gen-avr-mmcu-specs.cc b/gcc/config/avr/gen-avr-mmcu-specs.cc
index 02778aa3ce8..06d9d3c8d7d 100644
--- a/gcc/config/avr/gen-avr-mmcu-specs.cc
+++ b/gcc/config/avr/gen-avr-mmcu-specs.cc
@@ -294,7 +294,7 @@ print_mcu (const avr_mcu_t *mcu)
: "\t%{mabsdata}");
// -m[no-]rodata-in-ram basically affects linking, but sanity-check early.
- fprintf (f, "*cc1_misc:\n\t%%(check_rodata_in_ram)\n\n");
+ fprintf (f, "*cc1_rodata_in_ram:\n\t%%(check_rodata_in_ram)\n\n");
// avr-gcc specific specs for assembling / the assembler.
@@ -319,8 +319,6 @@ print_mcu (const avr_mcu_t *mcu)
? "\t%{mno-skip-bug}"
: "\t%{!mskip-bug: -mno-skip-bug}");
- fprintf (f, "*asm_misc:\n" /* empty */ "\n\n");
-
// avr-specific specs for linking / the linker.
int wrap_k =
@@ -361,7 +359,7 @@ print_mcu (const avr_mcu_t *mcu)
}
// -m[no-]rodata-in-ram affects linking. Sanity check its usage.
- fprintf (f, "*link_misc:\n\t%%(check_rodata_in_ram)\n\n");
+ fprintf (f, "*link_rodata_in_ram:\n\t%%(check_rodata_in_ram)\n\n");
// Specs known to GCC.
diff --git a/gcc/config/avr/specs.h b/gcc/config/avr/specs.h
index 574402035bc..0ccc37b8844 100644
--- a/gcc/config/avr/specs.h
+++ b/gcc/config/avr/specs.h
@@ -36,7 +36,7 @@ along with GCC; see the file COPYING3. If not see
"%(cc1_errata_skip) " \
"%(cc1_rmw) " \
"%(cc1_absdata) " \
- "%(cc1_misc) "
+ "%(cc1_rodata_in_ram) "
#undef CC1PLUS_SPEC
#define CC1PLUS_SPEC\
@@ -54,8 +54,7 @@ along with GCC; see the file COPYING3. If not see
"%(asm_relax) " \
"%(asm_rmw) " \
"%(asm_gccisr) " \
- "%(asm_errata_skip) " \
- "%(asm_misc) "
+ "%(asm_errata_skip) "
#define LINK_RELAX_SPEC \
"%{mrelax:--relax} "
@@ -67,7 +66,7 @@ along with GCC; see the file COPYING3. If not see
"%(link_text_start) " \
"%(link_relax) " \
"%(link_pmem_wrap) " \
- "%(link_misc) " \
+ "%(link_rodata_in_ram) " \
"%{shared:%eshared is not supported} "
#undef LIB_SPEC
Re: [PATCH] libstdc++: Work around modules issue causing hello-1 ICE [PR113710]
On Wed, 7 Feb 2024, 19:20 Patrick Palka, wrote:
> On Wed, 7 Feb 2024, Jonathan Wakely wrote:
>
> >
> >
> > On Wed, 7 Feb 2024 at 17:29, Patrick Palka wrote:
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> >
> > OK.
> >
> > Do we have a reduced testcase to track the modules bug that will still
> exist in the FE?
>
> https://gcc.gnu.org/PR113814
Excellent, thanks!
>
> >
> >
> >
> > -- >8 --
> >
> > The forward declarations of std::get in added in
> > r14-8710-g65b4cba9d6a9ff are causing an ICE in the test
> modules/hello-1
> > due to what seems to be a declaration merging issue in modules.
> >
> > What seems to be happening is that in hello-1_b.C we first include
> > , which indirectly includes which
> forms
> > the dependent specialization tuple_element<__i,
> tuple<_Elements...>>
> > (appearing in some of the std::get overloads) and adds it to the
> > specializations table.
> >
> > We then import hello which indirectly includes (in the
> GMF),
> > within which we define a partial specialization of tuple_element
> with
> > that same template-id. So importing hello in turn streams in this
> > partial specialization, but we don't notice it matches the
> previously
> > created dependent specialization, and we end up with two equivalent
> > types for this template-id with different TYPE_CANONICAL.
> >
> > This patch works around this issue by adding a forward declaration
> of
> > the tuple_element partial specialization from to
>
> > so that it appears alongside the dependent specialization of the
> same
> > template-id. So when including we immediately
> register
> > the template-id as a partial specialization, and if we later
> stream in the
> > partial specialization the MK_partial case of
> trees_in::key_mergeable will
> > match them up. (So perhaps a proper modules fix for this might be
> to make
> > key_mergeable try to match up a streamed in partial specialization
> with an
> > existing specialization from the table via
> match_mergeable_specialization.)
> >
> > PR c++/113710
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/bits/stl_pair.h (tuple_element): Add forward
> > declaration of the partial specialization for tuple.
> > ---
> >libstdc++-v3/include/bits/stl_pair.h | 5 +
> >1 file changed, 5 insertions(+)
> >
> > diff --git a/libstdc++-v3/include/bits/stl_pair.h
> b/libstdc++-v3/include/bits/stl_pair.h
> > index 00ec53ebc33..8c71b1350e5 100644
> > --- a/libstdc++-v3/include/bits/stl_pair.h
> > +++ b/libstdc++-v3/include/bits/stl_pair.h
> > @@ -1153,6 +1153,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >struct tuple_element<1, pair<_Tp1, _Tp2>>
> >{ typedef _Tp2 type; };
> >
> > + // Forward declare the partial specialization for std::tuple
> > + // to work around modules bug PR c++/113710.
> > + template
> > +struct tuple_element<__i, tuple<_Types...>>;
> > +
> >#if __cplusplus >= 201703L
> > template
> >inline constexpr size_t tuple_size_v> = 2;
> > --
> > 2.43.0.561.g235986be82
> >
> >
> >
[PATCH wwwdoc] Hardware-assisted AddressSanitizer now works for x86_64 with LAM_U57
--- htdocs/gcc-14/changes.html | 5 + 1 file changed, 5 insertions(+) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 6d917535..a022357a 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -499,6 +499,11 @@ a work-in-progress. -march=knm, -mtune=knl or -mtune=knm compiler switches. Support will be removed in GCC 15. + https://gcc.gnu.org/gcc-11/changes.html;>Hardware-assisted +AddressSanitizer now works for the x86-64 target with LAM_U57. +-fsanitize=hwaddress will enable -mlam=u57 +by default. + -- 2.31.1
