Re: [PATCH] tree-optimization/106365 - DSE of LEN_STORE and MASK_STORE
On 7/21/2022 3:05 AM, Richard Biener via Gcc-patches wrote: The following enhances DSE to handle LEN_STORE (optimally) and MASK_STORE (conservatively). Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Kewen is testing on powerpc. Handling MASK_STORE_LANES in a similar way to MASK_STORE is probably possible but I couldn't figure a way to generate one for testing. STORE_LANES is probably handled already since it's ECF_CONST. PR tree-optimization/106365 * tree-ssa-dse.cc (initialize_ao_ref_for_dse): Handle LEN_STORE, add mode to initialize a may-def and handle MASK_STORE that way. (dse_optimize_stmt): Query may-defs. Handle internal functions LEN_STORE and MASK_STORE similar to how we handle memory builtins but without byte tracking. LGTM. Obviously if you can massage the PR into a testcase, it's even better :-) jeff
Re: [PATCH] c: Fix location for _Pragma tokens [PR97498]
On 7/17/2022 9:24 AM, Lewis Hyatt wrote:
On Sat, Jul 9, 2022 at 11:59 PM Jeff Law via Gcc-patches
wrote:
On 7/9/2022 2:52 PM, Lewis Hyatt via Gcc-patches wrote:
Hello-
PR97498 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498) is another PR
related to the fact that imprecise locations for _Pragma result in
counterintuitive behavior for GCC diagnostic pragmas, which inhibit the
ability to make convenient wrapper macros for enabling and disabling
diagnostics in specific scopes.
It looks like David did a lot of work a few years ago improving this
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558), and in particular
r233637 added a lot of new test coverage for cases that had regressed in the
past.
I think the main source of problems for all remaining issues is that we use
the global input_location for deciding when/if a diagnostic should apply. I
think it should be eventually doable to eliminate this, and rather properly
resolve the token locations to the place they need to be
I've long wanted to see our dependency on input_location be diminished
with the goal of making it go away completely.
so that _Pragma
type wrapper macros just work the way people expect.
Certainly desirable since many projects have built wrapper macros which
use Pragmas to control warnings. One of the biggest QOI implementation
details we've had with the warnings has been problems with location data
leading to an inability to turn them off in specific locations.
So I'm all for improvements, in terms of getting our location data more
correct.
That said, PR97498 can be solved easily with a 2-line fix without removing
input_location, and I think the resulting change to input_location's value
is an improvement that will benefit other areas, so I thought I'd see what
you think about this patch please?
Here is a typical testcase. Note the line continuations so it's all one
logical line.
===
_Pragma("GCC diagnostic push") \
_Pragma("GCC diagnostic ignored \"-Wunused-function\"") \
static void f() {} \
_Pragma("GCC diagnostic pop")
===
What happens is that in C++ mode, input_location is always updated to the
most recently-lexed token, so the above case works fine and does not warn
when compiled with "g++ -Wunused-functions". However, in C mode, it does
warn because input_location in C is almost always set to the start of the
line, and is in this case. So the pop is deemed to take place prior to the
definition of f().
Initially, I thought it best to change input_location for C mode to behave
like C++, and always update to the most recently lexed token. Maybe that's
still the right way to go, but there was a fair amount of testsuite fallout
from that. Most of it, was just that we would need to change the tests to look
for the new locations, and in many cases, the new locations seemed
preferable to the old ones, but it seemed a bit much for now, so I took a
more measured approach and just changed input_location in the specific case
of processing a pragma, to be the location of the CPP_PRAGMA token.
Unfortunately, it turns out that the CPP_PRAGMA token that libcpp provides
to represent the _Pragma() expression doesn't have a valid location with
which input_location could be overridden. Looking into that, in r232893
David added logic which sets the location of all tokens inside the
_Pragma(...) to a reasonable place (namely it points to "_Pragma" at the
expansion point). However, that patch didn't change the location of the
CPP_PRAGMA token itself to similarly point there, so the 2nd line of this
patch does that.
The rest of it is just tweaking a couple tests which were sensitive to the
location being output. In all these cases, the new locations seem more
informative to me than the old ones. With those tweaks, bootstrap + regtest
all languages looks good with no regressions.
Please let me know what you think? Thanks!
gcc/c/ChangeLog:
PR preprocessor/97498
* c-parser.cc (c_parser_pragma): Set input_location to the
location of the pragma, rather than the start of the line.
libcpp/ChangeLog:
PR preprocessor/97498
* directives.cc (destringize_and_run): Override the location of
the CPP_PRAGMA token from a _Pragma directive to the location of
the expansion point, as is done for the tokens lexed from it.
gcc/testsuite/ChangeLog:
PR preprocessor/97498
* c-c++-common/pr97498.c: New test.
* c-c++-common/gomp/pragma-3.c: Adapt for improved warning locations.
* c-c++-common/gomp/pragma-5.c: Likewise.
* gcc.dg/pragma-message.c: Likewise.
libgomp/ChangeLog:
* testsuite/libgomp.oacc-c-c++-common/reduction-5.c: Adapt for
improved warning locations.
* testsuite/libgomp.oacc-c-c++-common/vred2d-128.c: Likewise.
OK for the trunk. Thanks for digging into this!
jeff
There was a request to backport this
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498#c7) since it
Re: [PATCH] PR bootstrap/106472: Add libgo depends on libbacktrace to Makefile.def
On Sat, Jul 30, 2022 at 2:38 PM Roger Sayle wrote: > > > This patch fixes PR bootstrap/106472 by adding a missing dependency > to Makefile.def to allow make bootstrap when configured using > "--enable-languages=go" (and not using make with multiple threads). > > Tested on x86-64-pc-linux-gnu. Ok for mainline? > > > 2022-07-30 Roger Sayle > > ChangeLog > PR bootstrap/106472 > * Makefile.def (dependencies): Make configure-target-libgo depend > upon all-target-libbacktrace. This is OK. Thanks. Ian
Re: [PATCH 1/3] C: Implement C2X N2653 char8_t and UTF-8 string literal changes
On 7/27/22 7:20 PM, Joseph Myers wrote: On Mon, 25 Jul 2022, Tom Honermann via Gcc-patches wrote: diff --git a/gcc/ginclude/stdatomic.h b/gcc/ginclude/stdatomic.h index bfcfdf664c7..75ed7965689 100644 --- a/gcc/ginclude/stdatomic.h +++ b/gcc/ginclude/stdatomic.h @@ -49,6 +49,10 @@ typedef _Atomic long atomic_long; typedef _Atomic unsigned long atomic_ulong; typedef _Atomic long long atomic_llong; typedef _Atomic unsigned long long atomic_ullong; +#if (defined(__CHAR8_TYPE__) \ + && (defined(_GNU_SOURCE) || defined(_ISOC2X_SOURCE))) +typedef _Atomic __CHAR8_TYPE__ atomic_char8_t; +#endif typedef _Atomic __CHAR16_TYPE__ atomic_char16_t; typedef _Atomic __CHAR32_TYPE__ atomic_char32_t; typedef _Atomic __WCHAR_TYPE__ atomic_wchar_t; GCC headers don't test glibc feature test macros such as _GNU_SOURCE and _ISOC2X_SOURCE; they base things only on the standard version (whether directly, or indirectly as via __CHAR8_TYPE__) and standard-defined feature test macros. Ok, thank you, that makes sense. I'll follow up with a revised patch that removes the additional conditions. Tom. (There's one exception in glimits.h - testing __USE_GNU, the macro defined internally by glibc's headers - but I don't think that's something we want to emulate in new code.)
Re: [PATCH 1/1] c++/106423: Fix pragma suppression of -Wc++20-compat diagnostics.
On 7/27/22 7:09 PM, Joseph Myers wrote: On Sun, 24 Jul 2022, Tom Honermann via Gcc-patches wrote: Gcc's '#pragma GCC diagnostic' directives are processed in "early mode" (see handle_pragma_diagnostic_early) for the C++ frontend and, as such, require that the target diagnostic option be enabled for the preprocessor (see c_option_is_from_cpp_diagnostics). This change modifies the -Wc++20-compat option definition to register it as a preprocessor option so that its associated diagnostics can be suppressed. The changes also There are lots of C++ warning options, all of which should support pragma suppression regardless of whether they are relevant to the preprocessor or not. Do they all need this kind of handling, or is it only -Wc++20-compat that has some kind of problem? I had only checked -Wc++20-compat when working on the patch. I did some spot checking now and confirmed that suppression works as expected for C++ for at least the following warnings: -Wuninitialized -Warray-compare -Wbool-compare -Wtautological-compare -Wterminate I don't know the diagnostic framework well. As best I can tell, this issue is specific to the -Wc++20-compat option and when the particular diagnostic is issued (e.g., during lexing as opposed to during parsing). The following call chains appear to be relevant. cp_lexer_new_main -> cp_lexer_handle_early_pragma -> c_invoke_early_pragma_handler cp_parser_* -> cp_parser_pragma -> c_invoke_pragma_handler (where * might be "declaration", "toplevel_declaration", "class_head", "objc_interstitial_code", ...) The -Wc++20-compat enabled warning regarding new keywords in C++20 is issued from cp_lexer_get_preprocessor_token. Tom.
[Ada PATCH] Update configure to check for a recent gnat Ada compiler.
GCC fails to bootstrap when configured with --enable-languages=all on machines that have older versions of GNAT installed as the system Ada compiler. In configure, it's not sufficient to check whether gnat is available, but whether a sufficiently recent version of GNAT is installed. This patch tweaks config/acx.m4 so that conftest.adb also contains a reference to System.CRTL.int64 as required by the current version of gcc/ada/osint.adb. This fixes the build when the system Ada is GNAT v4.8.5 (on Redhat 7) by disabling ada, but continues to work fine when the system Ada is GNAT v11.3.1. Tested in x86_64-pc-linux-gnu. Ok for mainline? 2022-07-30 Roger Sayle ChangeLog * config/acx.me (AC_PROG_GNAT): Update conftest.adb to include features required of the host gnat compiler. * configure: Regenerate. Thanks in advance, Roger -- diff --git a/config/acx.m4 b/config/acx.m4 index b86c4f9..bd3e7f8 100644 --- a/config/acx.m4 +++ b/config/acx.m4 @@ -396,6 +396,10 @@ AC_CHECK_TOOL(GNATMAKE, gnatmake, no) AC_CACHE_CHECK([whether compiler driver understands Ada], acx_cv_cc_gcc_supports_ada, [cat >conftest.adb <&6 else cat >conftest.adb <
[PATCH] PR bootstrap/106472: Add libgo depends on libbacktrace to Makefile.def
This patch fixes PR bootstrap/106472 by adding a missing dependency
to Makefile.def to allow make bootstrap when configured using
"--enable-languages=go" (and not using make with multiple threads).
Tested on x86-64-pc-linux-gnu. Ok for mainline?
2022-07-30 Roger Sayle
ChangeLog
PR bootstrap/106472
* Makefile.def (dependencies): Make configure-target-libgo depend
upon all-target-libbacktrace.
Thanks in advance,
Roger
--
diff --git a/Makefile.def b/Makefile.def
index 72d5854..8804ba6 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -663,6 +663,7 @@ dependencies = { module=configure-target-newlib;
on=all-binutils; };
dependencies = { module=configure-target-newlib; on=all-ld; };
dependencies = { module=configure-target-libgfortran;
on=all-target-libquadmath; };
dependencies = { module=configure-target-libgfortran;
on=all-target-libbacktrace; };
+dependencies = { module=configure-target-libgo; on=all-target-libbacktrace; };
languages = { language=c; gcc-check-target=check-gcc; };
languages = { language=c++;gcc-check-target=check-c++;
[committed] wwwdocs: cxx-status: Move www.open-std.org to https
This is a trivial change which fixes several dozen links. Marek, Jason, Jonathan - I noticed that (in other places) we have both links to www.open-std.org and open-std.org, both of which seem to work. What is the preferred spelling of that site? With or without www? (The latter would be shorter and sweeter. ;-) Gerald --- htdocs/projects/cxx-status.html | 182 1 file changed, 91 insertions(+), 91 deletions(-) diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html index 18fb6408..ae0321c0 100644 --- a/htdocs/projects/cxx-status.html +++ b/htdocs/projects/cxx-status.html @@ -852,25 +852,25 @@ Removing trigraphs - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4086.html;>N4086 + https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4086.html;>N4086 5 u8 character literals - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html;>N4267 + https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html;>N4267 6 __cpp_unicode_characters = 201411 Folding expressions - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4295.html;>N4295 + https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4295.html;>N4295 6 __cpp_fold_expressions = 201411 Attributes for namespaces and enumerators - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4266.html;>N4266 + https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4266.html;>N4266 4.9 (namespaces) 6 (enumerators) @@ -880,43 +880,43 @@ Nested namespace definitions - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4230.html;>N4230 + https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4230.html;>N4230 6 __cpp_nested_namespace_definitions = 201411 Allow constant evaluation for all non-type template arguments - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4268.html;>N4268 + https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4268.html;>N4268 6 __cpp_nontype_template_args = 201411 Extending static_assert - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3928.pdf;>N3928 + https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3928.pdf;>N3928 6 __cpp_static_assert = 201411 New Rules for auto deduction from braced-init-list - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html;>N3922 + https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html;>N3922 5 Allow typename in a template template parameter - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4051.html;>N4051 + https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4051.html;>N4051 5 [[fallthrough] wwwdocs:] attribute - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0188r1.pdf;>P0188R1 + https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0188r1.pdf;>P0188R1 7 __has_cpp_attribute(fallthrough) [[nodiscard] wwwdocs:] attribute - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0189r1.pdf;>P0189R1 + https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0189r1.pdf;>P0189R1 4.8 ([[gnu::warn_unused_result] wwwdocs:]) 7 (P0189R1) @@ -924,7 +924,7 @@ [[maybe_unused] wwwdocs:] attribute - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0212r1.pdf;>P0212R1 + https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0212r1.pdf;>P0212R1 4.8 ([[gnu::unused] wwwdocs:]) 7 (P0212R1) @@ -932,44 +932,44 @@ Extension to aggregate initialization - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0017r1.html;>P0017R1 + https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0017r1.html;>P0017R1 7 __cpp_aggregate_bases >= 201603 Wording for constexpr lambda - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0170r1.pdf;>P0170R1 + https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0170r1.pdf;>P0170R1 7 __cpp_constexpr >= 201603 Unary Folds and Empty Parameter Packs - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0036r0.pdf;>P0036R0 + https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0036r0.pdf;>P0036R0 6 __cpp_fold_expressions >= 201603 Generalizing the Range-Based For Loop - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0184r0.html;>P0184R0 +
Re: [PATCH] stack-protector: Check stack canary for noreturn function
On 7/14/2022 3:55 PM, H.J. Lu via Gcc-patches wrote: Check stack canary for noreturn function to catch stack corruption before calling noreturn function. For C++, check stack canary when throwing exception or resuming stack unwind to avoid corrupted stack. gcc/ PR middle-end/58245 * calls.cc (expand_call): Check stack canary for noreturn function. gcc/testsuite/ PR middle-end/58245 * c-c++-common/pr58245-1.c: New test. * g++.dg/pr58245-1.C: Likewise. * g++.dg/fstack-protector-strong.C: Adjusted. But is this really something we want? I'd actually lean towards eliminating the useless load -- I don't necessarily think we should be treating non-returning paths specially here. The whole point of the stack protector is to prevent the *return* path from going to an attacker controlled location. I'm not sure checking the protector at this point actually does anything particularly useful. jeff
Re: [PATCH] c++: Fix location for -Wunused-macros [PR66290]
On 7/28/2022 8:01 AM, Lewis Hyatt via Gcc-patches wrote: In C++, since all tokens are lexed from libcpp up front, diagnostics generated by libcpp after lexing has completed do not get a valid location from libcpp (rather, libcpp thinks they all pertain to the end of the file.) This has long been addressed using the global variable "done_lexing", which the C++ frontend sets at the appropriate time; when done_lexing is true, then c_cpp_diagnostic(), which outputs libcpp's diagnostics, uses input_location instead of the wrong libcpp location. The C++ frontend arranges that input_location will point to the token it is currently processing, so this generally works fine. However, there is one exception currently, which is -Wunused-macros. This gets generated at the end of processing in cpp_finish (), since we need to wait until then to determine whether a macro was eventually used or not. But the locations it passes to c_cpp_diagnostic () were remembered from the original lexing and hence they should not be overridden with input_location, which is now the one incorrectly pointing to the end of the file. Fixed by setting done_lexing=false again just prior to calling cpp_finish (). I also renamed the variable from done_lexing to "override_libcpp_locations", since it's now not strictly about lexing anymore. There is no new testcase with this patch, since we already had an xfailed testcase which is now fixed. gcc/c-family/ChangeLog: PR c++/66290 * c-common.h: Rename global done_lexing to override_libcpp_locations. * c-common.cc (c_cpp_diagnostic): Likewise. * c-opts.cc (c_common_finish): Set override_libcpp_locations (formerly done_lexing) immediately prior to calling cpp_finish (). gcc/cp/ChangeLog: PR c++/66290 * parser.cc (cp_lexer_new_main): Rename global done_lexing to override_libcpp_locations. gcc/testsuite/ChangeLog: PR c++/66290 * c-c++-common/pragma-diag-15.c: Remove xfail for C++. Ewww. But OK. Jeff
Re: [PATCH v2] cselib: add function to check if SET is redundant [PR106187]
On 7/29/2022 7:52 AM, Richard Earnshaw via Gcc-patches wrote: A SET operation that writes memory may have the same value as an earlier store but if the alias sets of the new and earlier store do not conflict then the set is not truly redundant. This can happen, for example, if objects of different types share a stack slot. To fix this we define a new function in cselib that first checks for equality and if that is successful then finds the earlier store in the value history and checks the alias sets. The routine is used in two places elsewhere in the compiler. Firstly in cfgcleanup and secondly in postreload. gcc/ChangeLog: * alias.h (mems_same_for_tbaa_p): Declare. * alias.cc (mems_same_for_tbaa_p): New function. * dse.cc (record_store): Use it instead of open-coding alias check. * cselib.h (cselib_redundant_set_p): Declare. * cselib.cc: Include alias.h (cselib_redundant_set_p): New function. * cfgcleanup.cc: (mark_effect): Use cselib_redundant_set_p instead of rtx_equal_for_cselib_p. * postreload.c (reload_cse_simplify): Use cselib_redundant_set_p. (reload_cse_noop_set_p): Delete. Seems quite reasonable. The only question I would have would be whether or not you considered including the aliasing info into the hashing used by cselib. You'd probably still need the bulk of this patch as well since we could presumably still get a hash conflict with two stores of the same value to the same location, but with different alias sets (it's just much less likely), so perhaps it doesn't really buy us anything. Ideally this would include a testcase. You might be able to turn that non-executawble reduced case into something useful by scanning the post-reload dumps. Jeff
[PATCH, v4] Fortran: detect blanks within literal constants in free-form mode [PR92805]
Hi Mikael,
Am 30.07.22 um 10:28 schrieb Mikael Morin:
Meh! We killed one check for gfc_current_form but the other one is still
there.
OK, match_kind_param calls two functions that also gobble space, so
there is work remaining here.
So please make match_small_literal_constant and gfc_match_name
space-gobbling wrappers around space-non-gobbling inner functions and
call those inner functions instead in match_kind_param.
well, here's the shortest solution I could come up with.
I added a new argument to 3 functions used in parsing that
controls the gobbling of whitespace. We use this to handle
whitespace for numerical literals, while the parsing of string
literals remains as in the previous version of the patch.
This version obviously ignores Thomas' request, as that would
require to treat gfc_match_char specially...
Regtested again. OK now?
Thanks,
Harald
From cb33d1d0b91b371a864379d920ddaefc15d587f9 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 28 Jul 2022 22:07:02 +0200
Subject: [PATCH] Fortran: detect blanks within literal constants in free-form
mode [PR92805]
gcc/fortran/ChangeLog:
PR fortran/92805
* match.cc (gfc_match_small_literal_int): Make gobbling of leading
whitespace optional.
(gfc_match_name): Likewise.
(gfc_match_char): Likewise.
* match.h (gfc_match_small_literal_int): Adjust prototype.
(gfc_match_name): Likewise.
(gfc_match_char): Likewise.
* primary.cc (match_kind_param): Match small literal int or name
without gobbling whitespace.
(get_kind): Do not skip over blanks in free-form mode.
(match_string_constant): Likewise.
gcc/testsuite/ChangeLog:
PR fortran/92805
* gfortran.dg/literal_constants.f: New test.
* gfortran.dg/literal_constants.f90: New test.
Co-authored-by: Steven G. Kargl
---
gcc/fortran/match.cc | 21 +---
gcc/fortran/match.h | 6 ++---
gcc/fortran/primary.cc| 14 +++
gcc/testsuite/gfortran.dg/literal_constants.f | 20
.../gfortran.dg/literal_constants.f90 | 24 +++
5 files changed, 63 insertions(+), 22 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/literal_constants.f
create mode 100644 gcc/testsuite/gfortran.dg/literal_constants.f90
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index 1aa3053e70e..c0dc0e89361 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -457,7 +457,7 @@ gfc_match_eos (void)
will be set to the number of digits. */
match
-gfc_match_small_literal_int (int *value, int *cnt)
+gfc_match_small_literal_int (int *value, int *cnt, bool gobble_ws)
{
locus old_loc;
char c;
@@ -466,7 +466,8 @@ gfc_match_small_literal_int (int *value, int *cnt)
old_loc = gfc_current_locus;
*value = -1;
- gfc_gobble_whitespace ();
+ if (gobble_ws)
+gfc_gobble_whitespace ();
c = gfc_next_ascii_char ();
if (cnt)
*cnt = 0;
@@ -611,14 +612,15 @@ gfc_match_label (void)
than GFC_MAX_SYMBOL_LEN. */
match
-gfc_match_name (char *buffer)
+gfc_match_name (char *buffer, bool gobble_ws)
{
locus old_loc;
int i;
char c;
old_loc = gfc_current_locus;
- gfc_gobble_whitespace ();
+ if (gobble_ws)
+gfc_gobble_whitespace ();
c = gfc_next_ascii_char ();
if (!(ISALPHA (c) || (c == '_' && flag_allow_leading_underscore)))
@@ -1052,16 +1054,19 @@ cleanup:
}
-/* Tries to match the next non-whitespace character on the input.
- This subroutine does not return MATCH_ERROR. */
+/* Tries to match the next non-whitespace character on the input. This
+ subroutine does not return MATCH_ERROR. When gobble_ws is false, do not
+ skip over leading blanks.
+*/
match
-gfc_match_char (char c)
+gfc_match_char (char c, bool gobble_ws)
{
locus where;
where = gfc_current_locus;
- gfc_gobble_whitespace ();
+ if (gobble_ws)
+gfc_gobble_whitespace ();
if (gfc_next_ascii_char () == c)
return MATCH_YES;
diff --git a/gcc/fortran/match.h b/gcc/fortran/match.h
index 495c93e0b5c..1f53e0cb67d 100644
--- a/gcc/fortran/match.h
+++ b/gcc/fortran/match.h
@@ -45,14 +45,14 @@ extern gfc_access gfc_typebound_default_access;
match gfc_match_special_char (gfc_char_t *);
match gfc_match_space (void);
match gfc_match_eos (void);
-match gfc_match_small_literal_int (int *, int *);
+match gfc_match_small_literal_int (int *, int *, bool = true);
match gfc_match_st_label (gfc_st_label **);
match gfc_match_small_int (int *);
-match gfc_match_name (char *);
+match gfc_match_name (char *, bool = true);
match gfc_match_symbol (gfc_symbol **, int);
match gfc_match_sym_tree (gfc_symtree **, int);
match gfc_match_intrinsic_op (gfc_intrinsic_op *);
-match gfc_match_char (char);
+match gfc_match_char (char, bool = true);
match gfc_match (const char *, ...);
match gfc_match_iterator (gfc_iterator *, int);
match gfc_match_parens (void);
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index 3f01f67cd49..19f2e78c8ff
Re: [PATCH, v3] Fortran: detect blanks within literal constants in free-form mode [PR92805]
Hi Thomas, Am 30.07.22 um 09:46 schrieb Thomas Koenig via Fortran: Hi Harald, This introduces the helper function gfc_match_next_char, which is your second option. I would be a little bit concerned about compilation times with the additional function call overhead. the function it replaces (gfc_match_char) is also in a different file, thus the overhead is at least neutral. Given that the latter has an additional call to gfc_gobble_whitespace(), we actually get better... The function is used only in one place; would it make sense to put it into primary.cc and declare it static? Can do that. Best regards Thomas Thanks, Harald
Re: [PATCH] libgo: Explicitly define SYS_timer_settime for 32-bit musl targets
On Thu, Jul 28, 2022 at 11:15 AM wrote:
>
> From: Sören Tempel
>
> On 32-bit systems, musl only defines SYS_timer_settime32 not
> SYS_timer_settime. This causes the following compilation error:
>
> os_linux.go:251:30: error: reference to undefined name
> '_SYS_timer_settime'
> 251 | return int32(syscall(_SYS_timer_settime,
> uintptr(timerid), uintptr(flags), uintptr(unsafe.Pointer(new)),
> uintptr(unsafe.Pointer(old)), 0, 0))
> | ^
>
> This commit fixes this error by "aliasing" SYS_timer_settime to
> SYS_timer_settime32 if the latter is defined. This is also what
> musl does internally [1].
Committed a slight variant of this, as appended.
Ian
f40686b01bdabba051e3b22165bb576e45ffca74
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 2f2fafde1f1..ca797045d66 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-a62f20ae78ddd41be682dde8cab075ca4f5dbb2a
+d53e8a0e94e34dc609e34dd5e404debda2640cfb
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
diff --git a/libgo/sysinfo.c b/libgo/sysinfo.c
index fc0210992fa..180f5c31d74 100644
--- a/libgo/sysinfo.c
+++ b/libgo/sysinfo.c
@@ -354,6 +354,11 @@ enum {
};
#endif
+#if !defined(SYS_timer_settime) && defined(SYS_timer_settime32)
+// musl defines SYS_timer_settim32 on 32-bit systems.
+#define SYS_timer_settime SYS_timer_settime32
+#endif
+
#if defined(HAVE_LOFF_T)
// loff_t can be defined as a macro; for -fgo-dump-spec make sure we
// see a typedef.
Re: [PATCH] tree-optimization/105679 - disable backward threading of unlikely entry
On 7/29/2022 2:54 AM, Richard Biener via Gcc-patches wrote: The following makes the backward threader reject threads whose entry edge is probably never executed according to the profile. That in particular, for the testcase, avoids threading the irq == 1 check on the path where irq > 31, thereby avoiding spurious -Warray-bounds diagnostics if (irq_1(D) > 31) goto ; [0.00%] else goto ; [100.00%] ;; basic block 3, loop depth 0, count 0 (precise), probably never executed _2 = (unsigned long) irq_1(D); __builtin___ubsan_handle_shift_out_of_bounds (&*.Lubsan_data0, 1, _2); _3 = 1 << irq_1(D); mask_4 = (u32) _3; entry = instance_5(D)->array[irq_1(D)]; capture (mask_4); if (level_6(D) != 0) goto ; [34.00%] else goto ; [66.00%] ;; basic block 5, loop depth 0, count 708669600 (estimated locally), maybe hot if (irq_1(D) == 1) goto ; [20.97%] else goto ; [79.03%] Bootstrap and regtest running on x86_64-unknown-linux-gnu. The testcase in the PR requries both ubsan and sancov so I'm not sure where to put it but IIRC there were quite some duplicate PRs wrt threading unlikely paths exposing diagnostics, eventually some testcase will come out of those (when we identify them). Note the patch is quite conservative in only disabling likely never executed paths rather than requiring maybe_hot_edge_p (OTOH those are somewhat similar in the end). I'm going to push it when testing finishes but maybe there are some testcases to adjust. PR tree-optimization/105679 * tree-ssa-threadbackwards.cc (back_threader_profitability::profitable_path_p): Avoid threading when the entry edge is probably never executed. OK. And more generally I'm absolutely OK with improving the costing heuristics. The one thing we need to keep in mind when adding this kind of check is that we may start seeing new diagnostics from the middle end -- while the path may not be profitable to thread from a performance standpoint, it may be useful to thread from a diagnostic standpoint. But I'd argue that for such cases we really want to move to a model where the predicate analysis bits are used consistently to prune away "can't happen" cases for middle end diagnostics rather than relying on threading to optimize away can't happen cold paths. Jeff
Re: [PATCH] tree-optimization/106422 - verify block copying in forward threading
On 7/29/2022 2:47 AM, Richard Biener via Gcc-patches wrote: The forward threader failed to check whether it can actually duplicate blocks. The following adds this in a similar place the backwards threader performs this check. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/106422 * tree-ssa-threadupdate.cc (fwd_jt_path_registry::update_cfg): Check whether we can copy thread blocks and cancel the thread if not. * gcc.dg/torture/pr106422.c: New testcase. I'm back from PTO. This looks obviously correct to me. jeff
Re: [PATCH] libgccjit.h: Make the macro definition for testing gcc_jit_context_new_bitcast correctly available.
I don't have push rights to the repo, so this would need to be applied manually. Thanks, Vibhav On Tue, Jul 26, 2022 at 4:48 AM David Malcolm wrote: > > On Sat, 2022-07-23 at 13:31 +0530, Vibhav Pant via Jit wrote: > > The macro definition for LIBGCCJIT_HAVE_gcc-jit_context_new_bitcast > > was earlier located in the documentation comment for > > gcc_jit_context_new_bitcast, making it unavailable to code that > > consumed libgccjit.h. This patch moves the definition out of the > > comment, making it effective. > > Good catch! > > Do you have push rights to the git repo, or should I push this? > > Thanks > Dave > -- Vibhav Pant vibh...@gmail.com GPG: 7ED1 D48C 513C A024 BE3A 785F E3FB 28CB 6AB5 9598
Re: [PATCH] Mips: Fix the ASAN shadow offset hook for the n32 ABI
On Mon, 6 Jun 2022, Dimitrije Milosevic wrote: > * config/mips/mips.cc (mips_asan_shadow_offset): Reformat > to handle the N32 ABI. That's not what the change does. > * config/mips/mips.h (SUBTARGET_SHADOW_OFFSET): Remove > the macro, as it is not needed anymore. Why is the macro not needed anymore? I can see the change has already been committed, but no proper review was done and I can hardly see how anyone can know why this change is correct. If someone looks at it say in 10 years' time they can only try to guess. Maciej
[PATCH] libfortran: Fix up boz_15.f90 on powerpc64le with -mabi=ieeelongdouble [PR106079]
Hi!
The boz_15.f90 test FAILs on powerpc64le-linux when -mabi=ieeelongdouble
is used (either default through --with-long-double-format=ieee or
when used explicitly).
The problem is that the read/write transfer routines are called with
BT_REAL (or BT_COMPLEX) type and kind 17 which is magic we use to say
it is the IEEE quad real(kind=16) rather than the IBM double double
real(kind=16). For the floating point input/output we then handle kind
17 specially, but for B/O/Z we just treat the bytes of the floating point
value as binary blob and using 17 in that case results in unexpected
behavior, for write it means we don't estimate right how many chars we'll
need and print etc. rather than what we should, and
even with explicit size we'd print one further byte than intended.
For read it would even mean overwriting some unrelated byte after the
floating point object.
Fixed by using 16 instead of 17 in the read_radix and write_{b,o,z} calls.
Bootstrapped/regtested on powerpc64le-linux, ok for trunk / 12.2?
2022-07-30 Jakub Jelinek
PR libfortran/106079
* io/transfer.c (formatted_transfer_scalar_read,
formatted_transfer_scalar_write): For type BT_REAL with kind 17
change kind to 16 before calling read_radix or write_{b,o,z}.
--- libgfortran/io/transfer.c.jj2022-01-11 23:49:53.695803219 +0100
+++ libgfortran/io/transfer.c 2022-07-29 16:26:58.414855021 +0200
@@ -1614,6 +1614,10 @@ formatted_transfer_scalar_read (st_param
if (!(compile_options.allow_std & GFC_STD_F2008)
&& require_type (dtp, BT_INTEGER, type, f))
return;
+#ifdef HAVE_GFC_REAL_17
+ if (type == BT_REAL && kind == 17)
+ kind = 16;
+#endif
read_radix (dtp, f, p, kind, 2);
break;
@@ -1626,6 +1630,10 @@ formatted_transfer_scalar_read (st_param
if (!(compile_options.allow_std & GFC_STD_F2008)
&& require_type (dtp, BT_INTEGER, type, f))
return;
+#ifdef HAVE_GFC_REAL_17
+ if (type == BT_REAL && kind == 17)
+ kind = 16;
+#endif
read_radix (dtp, f, p, kind, 8);
break;
@@ -1638,6 +1646,10 @@ formatted_transfer_scalar_read (st_param
if (!(compile_options.allow_std & GFC_STD_F2008)
&& require_type (dtp, BT_INTEGER, type, f))
return;
+#ifdef HAVE_GFC_REAL_17
+ if (type == BT_REAL && kind == 17)
+ kind = 16;
+#endif
read_radix (dtp, f, p, kind, 16);
break;
@@ -2085,6 +2097,10 @@ formatted_transfer_scalar_write (st_para
if (!(compile_options.allow_std & GFC_STD_F2008)
&& require_type (dtp, BT_INTEGER, type, f))
return;
+#ifdef HAVE_GFC_REAL_17
+ if (type == BT_REAL && kind == 17)
+ kind = 16;
+#endif
write_b (dtp, f, p, kind);
break;
@@ -2097,6 +2113,10 @@ formatted_transfer_scalar_write (st_para
if (!(compile_options.allow_std & GFC_STD_F2008)
&& require_type (dtp, BT_INTEGER, type, f))
return;
+#ifdef HAVE_GFC_REAL_17
+ if (type == BT_REAL && kind == 17)
+ kind = 16;
+#endif
write_o (dtp, f, p, kind);
break;
@@ -2109,6 +2129,10 @@ formatted_transfer_scalar_write (st_para
if (!(compile_options.allow_std & GFC_STD_F2008)
&& require_type (dtp, BT_INTEGER, type, f))
return;
+#ifdef HAVE_GFC_REAL_17
+ if (type == BT_REAL && kind == 17)
+ kind = 16;
+#endif
write_z (dtp, f, p, kind);
break;
Jakub
[x86_64 PATCH take #2] PR target/106450: Tweak timode_remove_non_convertible_regs.
Many thanks to H.J. for pointing out a better idiom for traversing
the USEs (and also DEFs) of TImode registers in an instruction.
This revised patched has been tested on x86_64-pc-linux-gnu with
make bootstrap and make -k check, both with and without
--target_board=unix{-m32}, with no new failures. Ok for mainline?
2022-07-30 Roger Sayle
H.J. Lu
gcc/ChangeLog
PR target/106450
* config/i386/i386-features.cc (timode_check_non_convertible_regs):
Do nothing if REGNO is set in the REGS bitmap, or is a hard reg.
(timode_remove_non_convertible_regs): Update comment.
Call timode_check_non_convertible_reg on all TImode register
DEFs and USEs in each instruction.
gcc/testsuite/ChangeLog
PR target/106450
* gcc.target/i386/pr106450.c: New test case.
Thanks (H.J. and Uros),
Roger
--
> -Original Message-
> From: H.J. Lu
> Sent: 28 July 2022 17:55
> To: Roger Sayle
> Cc: GCC Patches
> Subject: Re: [x86_64 PATCH] PR target/106450: Tweak
> timode_remove_non_convertible_regs.
>
> On Thu, Jul 28, 2022 at 9:43 AM Roger Sayle
> wrote:
> >
> > This patch resolves PR target/106450, some more fall-out from more
> > aggressive TImode scalar-to-vector (STV) optimizations. I continue to
> > be caught out by how far TImode STV has diverged from DImode/SImode
> > STV, and therefore requires additional (unexpected) tweaking. Many
> > thanks to H.J. Lu for pointing out timode_remove_non_convertible_regs
> > needs to be extended to handle XOR (and other new operations).
> >
> > Unhelpfully the comment above this function states that it's the
> > TImode version of "remove_non_convertible_regs", which doesn't exist
> > anymore, so I've resurrected an explanatory comment from the git history.
> > By refactoring the checks for hard regs and already "marked" regs into
> > timode_check_non_convertible_regs itself, all its callers are
> > simplified. This patch then uses GET_RTX_CLASS to generically handle
> > unary and binary operations, calling timode_check_non_convertible_regs
> > on each TImode register operand in the single_set's SET_SRC.
> >
> > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> > and make -k check, both with and without --target_board=unix{-m32},
> > with no new failures. Ok for mainline?
> >
> >
> > 2022-07-28 Roger Sayle
> >
> > gcc/ChangeLog
> > PR target/106450
> > * config/i386/i386-features.cc (timode_check_non_convertible_regs):
> > Do nothing if REGNO is set in the REGS bitmap, or is a hard reg.
> > (timode_remove_non_convertible_regs): Update comment.
> > Call timode_check_non_convertible_regs on all register operands
> > of supported (binary and unary) operations.
>
> Should we use
>
> df_ref ref;
> FOR_EACH_INSN_USE (ref, insn)
>if (!DF_REF_REG_MEM_P (ref))
> timode_check_non_convertible_regs (candidates, regs,
> DF_REF_REGNO (ref));
>
> to check each use?
>
> > gcc/testsuite/ChangeLog
> > PR target/106450
> > * gcc.target/i386/pr106450.c: New test case.
> >
> >
> > Thanks in advance,
> > Roger
> > --
> --
> H.J.
diff --git a/gcc/config/i386/i386-features.cc b/gcc/config/i386/i386-features.cc
index aa5de71..e4cc4a3 100644
--- a/gcc/config/i386/i386-features.cc
+++ b/gcc/config/i386/i386-features.cc
@@ -1808,6 +1808,11 @@ static void
timode_check_non_convertible_regs (bitmap candidates, bitmap regs,
unsigned int regno)
{
+ /* Do nothing if REGNO is already in REGS or is a hard reg. */
+ if (bitmap_bit_p (regs, regno)
+ || HARD_REGISTER_NUM_P (regno))
+return;
+
for (df_ref def = DF_REG_DEF_CHAIN (regno);
def;
def = DF_REF_NEXT_REG (def))
@@ -1843,7 +1848,13 @@ timode_check_non_convertible_regs (bitmap candidates,
bitmap regs,
}
}
-/* The TImode version of remove_non_convertible_regs. */
+/* For a given bitmap of insn UIDs scans all instructions and
+ remove insn from CANDIDATES in case it has both convertible
+ and not convertible definitions.
+
+ All insns in a bitmap are conversion candidates according to
+ scalar_to_vector_candidate_p. Currently it implies all insns
+ are single_set. */
static void
timode_remove_non_convertible_regs (bitmap candidates)
@@ -1857,25 +1868,20 @@ timode_remove_non_convertible_regs (bitmap candidates)
changed = false;
EXECUTE_IF_SET_IN_BITMAP (candidates, 0, id, bi)
{
- rtx def_set = single_set (DF_INSN_UID_GET (id)->insn);
- rtx dest = SET_DEST (def_set);
- rtx src = SET_SRC (def_set);
-
- if ((!REG_P (dest)
-|| bitmap_bit_p (regs, REGNO (dest))
-|| HARD_REGISTER_P (dest))
- && (!REG_P (src)
- || bitmap_bit_p (regs, REGNO (src))
- || HARD_REGISTER_P (src)))
- continue;
-
- if (REG_P (dest))
- timode_check_non_convertible_regs (candidates,
Re: [PATCH, v3] Fortran: detect blanks within literal constants in free-form mode [PR92805]
Le 29/07/2022 à 23:09, Harald Anlauf via Fortran a écrit :
Hi Mikael,
Am 29.07.22 um 22:36 schrieb Mikael Morin:
Indeed, I overlooked that, but my opinion remains that we shouldn’t
play with fixed vs free form considerations here.
So the options I can see are:
- handle the locus in get_kind; we do it a lot already in matching
functions, so it wouldn’t be different here.
- implement a variant of gfc_match_char without space gobbling.
- use gfc_match(...), which is a bit heavy weight to match a single
char string, but otherwise would keep things concise.
My preference goes to the third option, but I’m fine with either of
them if you have a different one.
how about the attached?
This introduces the helper function gfc_match_next_char, which is
your second option.
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index 3f01f67cd49..9fa6779200f 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -92,14 +92,17 @@ get_kind (int *is_iso_c)
{
int kind;
match m;
+ char c;
*is_iso_c = 0;
- if (gfc_match_char ('_') != MATCH_YES)
+ if (gfc_match_next_char ('_') != MATCH_YES)
return -2;
- m = match_kind_param (, is_iso_c);
- if (m == MATCH_NO)
+ m = MATCH_NO;
+ c = gfc_peek_ascii_char ();
+ if ((gfc_current_form == FORM_FREE && gfc_is_whitespace (c))
+ || (m = match_kind_param (, is_iso_c)) == MATCH_NO)
gfc_error ("Missing kind-parameter at %C");
Meh! We killed one check for gfc_current_form but the other one is still
there.
OK, match_kind_param calls two functions that also gobble space, so
there is work remaining here.
So please make match_small_literal_constant and gfc_match_name
space-gobbling wrappers around space-non-gobbling inner functions and
call those inner functions instead in match_kind_param.
Re: [PATCH, v3] Fortran: detect blanks within literal constants in free-form mode [PR92805]
Hi Harald, This introduces the helper function gfc_match_next_char, which is your second option. I would be a little bit concerned about compilation times with the additional function call overhead. The function is used only in one place; would it make sense to put it into primary.cc and declare it static? Best regards Thomas
Re: [PATCH v3] LoongArch: add addr_global attribute
Hi, Lulu, On Sat, Jul 30, 2022 at 11:13 AM Lulu Cheng wrote: > > > 在 2022/7/30 上午1:17, Xi Ruoyao 写道: > > Change v2 to v3: > - Disable section anchor for addr_global symbols. > - Use -O2 in test to make sure section anchor is disabled. > > -- > > Background: > https://lore.kernel.org/loongarch/d7670b60-2782-4642-995b-7baa01779...@loongson.cn/T/#e1d47e2fe185f2e2be8fdc0784f0db2f644119379 > > Question: Do you have a better name than "addr_global"? > > I think the name can be changed to "get_through_got". What do you think of it? Is this the same thing as "movable" once we used internally? Huacai > > Alternatives: > > 1. Just use "-mno-explicit-relocs -mla-local-with-abs" for kernel > modules. It's stupid IMO. > 2. Implement a "-maddress-local-with-got" option for GCC and use it for > kernel modules. It seems too overkill: we might create many unnecessary > GOT entries. > 3. For all variables with a section attribute, consider it global. It > may make sense, but I just checked x86_64 and riscv and they don't do > this. > 4. Implement -mcmodel=extreme and use it for kernel modules. To me > "extreme" seems really too extreme. > 5. More hacks in kernel. (Convert relocations against .data..percpu with > objtool? But objtool is not even implemented for LoongArch yet.) > > Note: I'll be mostly AFK in the following week. My attempt to finish > the kernel support for new relocs before going AFK now failed miserably > :(. > > -- >8 -- > > A linker script and/or a section attribute may locate a local object in > some way unexpected by the code model, leading to a link failure. This > happens when the Linux kernel loads a module with "local" per-CPU > variables. > > Add an attribute to explicitly mark an variable with the address > unlimited by the code model so we would be able to work around such > problems. > > > Others I think are ok.
