[Bug target/106488] New: [13 Regression] ICE: in ix86_output_ssemov, at config/i386/i386.cc:5565 with -O2 -fno-dce -fno-tree-vrp -mf16c -fno-tree-coalesce-vars

[zsojka at seznam dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106488

Bug ID: 106488
   Summary: [13 Regression] ICE: in ix86_output_ssemov, at
config/i386/i386.cc:5565 with -O2 -fno-dce
-fno-tree-vrp -mf16c -fno-tree-coalesce-vars
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 53389
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53389=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-dce -fno-tree-vrp -mf16c
-fno-tree-coalesce-vars testcase.c -Wno-psabi
during RTL pass: final
testcase.c: In function 'foo':
testcase.c:16:1: internal compiler error: in ix86_output_ssemov, at
config/i386/i386.cc:5565
   16 | }
  | ^
0x82ca5f ix86_output_ssemov(rtx_insn*, rtx_def**)
/repo/gcc-trunk/gcc/config/i386/i386.cc:5565
0xfe6ba3 final_scan_insn_1
/repo/gcc-trunk/gcc/final.cc:2826
0xfe732b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/repo/gcc-trunk/gcc/final.cc:2939
0xfe74d4 final_1
/repo/gcc-trunk/gcc/final.cc:1996
0xfe81a8 rest_of_handle_final
/repo/gcc-trunk/gcc/final.cc:4284
0xfe81a8 execute
/repo/gcc-trunk/gcc/final.cc:4364
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-1899-20220730103523-ga63b99f24df-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-1899-20220730103523-ga63b99f24df-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220730 (experimental) (GCC)

[Bug fortran/106487] Calls to ___builtin_nested_func_ptr_created that cannot be resolved on M1 (Apple silicon)

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106487

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
There is a github issue related to this already and this is not a fsf gcc
release.

[Bug fortran/106487] New: Calls to ___builtin_nested_func_ptr_created that cannot be resolved on M1 (Apple silicon)

[apersaud at lbl dot gov via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106487

Bug ID: 106487
   Summary: Calls to ___builtin_nested_func_ptr_created that
cannot be resolved on M1 (Apple silicon)
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: apersaud at lbl dot gov
  Target Milestone: ---

I'm trying to compile a program (not public available) on an M1 and am running
in an issue where the linker is complaining about unknown functions

U ___builtin_nested_func_ptr_created
U ___builtin_nested_func_ptr_deleted

I'm using:

> gfortran-12 --version
GNU Fortran (Homebrew GCC 12.1.0_1) 12.1.0
[...]

Since I cannot share the source code. I tried to reduce it to a small program:
"""
MODULE focus
  IMPLICIT NONE
  PRIVATE

  PUBLIC  myinit
  ABSTRACT INTERFACE
 REAL(kind=8) FUNCTION dummyf(x)
   REAL(kind=8), INTENT(IN) :: x
 END FUNCTION dummyf
  end INTERFACE

CONTAINS

  SUBROUTINE myfun(fun,  x, res)
! return res = fun(x)
IMPLICIT NONE
PROCEDURE(dummyf) :: fun
REAL(kind=8), INTENT(INOUT) :: x
INTEGER, INTENT(OUT) :: res
res = fun(x)
  end SUBROUTINE myfun

  SUBROUTINE myinit()
IMPLICIT NONE
INTEGER :: its, nfcalls
REAL(kind=8) :: ftv

CALL myfun(internal_func,  ftv,  its)
  CONTAINS
FUNCTION internal_func(fv)
  IMPLICIT NONE
  REAL(kind=8), INTENT(IN) :: fv
  REAL(kind=8) :: internal_func
  !internal_func = nfcalls   ! create links to
___builtin_nested_func_ptr_created
  internal_func = 111! this works
END FUNCTION internal_func
  END SUBROUTINE myinit

END MODULE focus
"""

The problem seems to be the function definition in the contains block of a
subroutine.
However, if this is not working on the M1, I would have expected some kind of
warning or error message, but the file compiles OK and only fails in a later
linker stage when the two mentioned functions cannot be found.

The command I used to compile was 
"gfortran-12 -m64 -O2 -c input.f95"

When I comment out the "internal_func = nfcalls" line and uncomment the
following line, the compiler does not link to these two functions (this only
works with the -O2 flag enabled though, so it probably just inlines the
function calls and therefore there is no CONTAINS block anymore?)

I'm not that familiar with fortran/gfortran...Not sure if this can/should be
fixed, but I thought I report it.

[Bug c++/71954] template partial specialization for constexpr error

[lichray at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71954

Zhihao Yuan  changed:

   What|Removed |Added

 CC||lichray at gmail dot com

--- Comment #5 from Zhihao Yuan  ---
Please fix. The workaround is to write

struct Struct {
template 
constexpr static bool use_cond = false;
};

template 
constexpr bool Struct::use_cond = true;

But when the enclosing context is a class template, writing such a partial
specialization will be very tedious.

Re: [PATCH] tree-optimization/106365 - DSE of LEN_STORE and MASK_STORE

[Jeff Law via Gcc-patches]

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]

[Jeff Law via Gcc-patches]

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

[Ian Lance Taylor via Gcc-patches]

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

[Bug tree-optimization/105679] [12 Regression] extra -Warray-bounds warning added with -fsanitize=shift due to jump threading

[kees at outflux dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679

--- Comment #6 from Kees Cook  ---
(In reply to Richard Biener from comment #5)
> Should be fixed on trunk.  Can you check on the original unreduced testcase?

Thanks! I've done test builds and can confirm these two false positives have
been eliminated:

arch/x86/kvm/emulate.c:251:27: warning: array subscript 32 is above array
bounds of 'long unsigned int[17]' [-Warray-bounds]
arch/x86/kvm/ioapic.c:213:33: warning: array subscript 32 is above array bounds
of 'union kvm_ioapic_redirect_entry[24]' [-Warray-bounds]

Is this backportable to gcc 12?

Re: [PATCH 1/3] C: Implement C2X N2653 char8_t and UTF-8 string literal changes

[Tom Honermann via Gcc-patches]

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.

[Tom Honermann via Gcc-patches]

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.

gcc-12-20220730 is now available

[GCC Administrator via Gcc]

Snapshot gcc-12-20220730 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20220730/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-12 revision 681c73db9bd156f9b65a73ccc6c4a0a697fe70d6

You'll find:

 gcc-12-20220730.tar.xz   Complete GCC

  SHA256=224ef6d5892c5b14fe3b41b4a97a5debae09f8658799859c65964b4aea86ae49
  SHA1=114b4e9fca29dc005b690edff6911adc4fec9392

Diffs from 12-20220723 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug c++/106486] C++ warning for -Wmissing-prototypes is pure nuisance

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106486

--- Comment #1 from Andrew Pinski  ---
> which is often painful to do without structural Makefile changes.

Not true. Most makefiles have CFLAGS and CXXFLAGS. And then use a common
OPTFLAGS or something similar. It seems like setting CXXFLAGS directly to
CFLAGS is wrong.

[Bug c++/106486] New: C++ warning for -Wmissing-prototypes is pure nuisance

[hpa at zytor dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106486

Bug ID: 106486
   Summary: C++ warning for -Wmissing-prototypes is pure nuisance
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hpa at zytor dot com
  Target Milestone: ---

Since upgrading to gcc 12.1.1, I keep getting the following warning through
various projects:

cc1plus: warning: command-line option ‘-Wmissing-prototypes’ is valid for
C/ObjC but not for C++

This warning is pure nuisance. In a mixed-language project it is *extra*
important that the right prototypes are used, and it is far easier to enable
-Wmissing-prototypes project wide. This warning implies that one would have to
conditionalize the -W options based on the language of an input file, which is
often painful to do without structural Makefile changes.

Note that there doesn't seem to be any way to squelch this warning, either
(e.g. a -Wno-warning-not-applicable option or similar.)
cc1plus: warning: command-line option ‘-Wmissing-prototypes’ is valid for
C/ObjC but not for C++

[Bug target/106484] Failure to optimize uint64_t/constant division on ARM32

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106484

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/106485] Can't use heap pointer in `static_assert`

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106485

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=105826

--- Comment #1 from Andrew Pinski  ---
I think this is a dup of bug 105826.

[Bug c++/105619] Wrong "used in its own initializer" with class prvalue

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105619

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=64989

--- Comment #2 from Andrew Pinski  ---
I think this is a dup of bug 64989.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[roger at nextmovesoftware dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472

Roger Sayle  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com

--- Comment #11 from Roger Sayle  ---
Patch proposed:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/599095.html

[Ada PATCH] Update configure to check for a recent gnat Ada compiler.

[Roger Sayle]

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

[Roger Sayle]

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

[Gerald Pfeifer]

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

[Jeff Law via Gcc-patches]

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: [RFC] Analysis of PR105586 and possible approaches to fix issue

[Jeff Law via Gcc]

On 7/27/2022 12:58 AM, Richard Biener via Gcc wrote:

On Tue, Jul 26, 2022 at 8:55 PM Surya Kumari Jangala via Gcc
 wrote:

Hi,
I am working on PR105586. This is a -fcompare-debug failure, with the 
differences starting during sched1 pass. The sequence of two instructions in a 
basic block (block 4) is flipped with -g.
In addition to this, another difference is that an insn is assigned a different 
cycle in debug vs non-debug modes.
More specifically, the 2nd instruction in basic block 4 is assigned to cycle 0 
w/o -g but to cycle 1 w/ -g. I felt that this could be resulting in the 
flipping of the later insns in the bb, so I started to investigate the 
difference in cycle assignment.

In the routine schedule_block(), after scheduling an insn(schedule_insn()), 
prune_ready_list() is called if the ready list is not empty. This routine goes 
thru all the insns in the ready list and for each insn it checks if there is a 
state transition. If there is no state transition, then INSN_TICK(insn) is set 
to current_cycle+1.

After scheduling the first insn in bb 4, when prune_ready_list() is called, we 
see that for the debug mode run, there is no state transition for the second 
insn and hence it's INSN_TICK is updated. For the non-debug run, a state 
transition exists and the INSN_TICK is not updated. This was resulting in the 
second insn being scheduled in cycle 1 in the debug mode, and in cycle 0 in the 
non-debug mode.

It turned out that the initial dfa state of the basic block (‘init_state’ 
parameter of schedule_block()) was different in debug and non-debug modes.

After scheduling a basic block, it’s current dfa state is copied to the 
fall-thru basic block. In other words, the initial dfa state of the fall thru 
bb is the current state of the bb that was just scheduled.

Basic block 4 is the fall-thru bb for basic block 3. In non-debug mode, bb 3 
has only a NOTE insn and hence scheduling of bb 3 is skipped. Since bb 3 is not 
scheduled, it’s state is not copied to bb 4. Whereas in debug mode, bb3 has a 
NOTE insn and a DEBUG insn. So bb 3 is “scheduled” and it’s dfa state is copied 
to bb4. [The dfa state of bb 3 is obtained from it’s parent bb, ie, bb 2]. 
Hence the initial dfa state of bb 4 is different in debug and non-debug modes 
due to the difference in the insns in the predecessor bb (bb 3).

The routine no_real_insns_p() is called to check if scheduling can be skipped 
for a basic block. This routine checks for NOTE and LABEL insns and it returns 
‘true’ if a basic block contains only NOTE/LABEL insns. Hence, any basic block 
which has only NOTE or LABEL insns is not scheduled.

To fix the issue of insns being assigned different cycles, there are two 
possible solutions:

1. Modify no_real_insns_p() to treat a DEBUG insn as a non-real insn (similar 
to NOTE and LABEL). With this change, bb 3 will not be scheduled in the debug 
mode (as it contains only NOTE and DEBUG insns). If scheduling is skipped, then 
bb 3’s state is not copied to bb 4 and the initial dfa state of bb 4 will be 
same in both debug and non-debug modes
2. Copy dfa state of a basic block to it’s fall-thru block only if the basic 
block contains ‘real’ insns (ie, it should contain at least one insn which is 
not a LABEL, NOTE or DEBUG). This will prevent copying of dfa state from bb 3 
to bb 4 in debug mode.

Do you know why the DFA state is not always copied to the fallthru
destination and then copied further even if the block does not contain
any (real) insns?  It somewhat sounds like premature optimization
breaking things here...
Yea (premature optimization) and probably just an oversight thinking 
that a block with no real insns could be totally ignored.


jeff

Re: [PATCH] c++: Fix location for -Wunused-macros [PR66290]

[Jeff Law via Gcc-patches]

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

[Bug c++/106485] New: Can't use heap pointer in `static_assert`

[johelegp at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106485

Bug ID: 106485
   Summary: Can't use heap pointer in `static_assert`
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/W4r6oMa3M.

```C++
struct I {
  int* i = new int{1};
  constexpr ~I() { delete i; }
};
static_assert([] { return I{}.i; }());
static_assert(I{}.i);
```

```
:5:19: error: non-constant condition for static assertion
5 | static_assert(I{}.i);
  |   ^
:5:19: error: the value of '' is not usable in a constant
expression
:5:17: note: '' was not declared 'constexpr'
5 | static_assert(I{}.i);
  | ^
Compiler returned: 1
```

It works wrapped in an IILE, or if the `int` is uninitialized.

Re: [PATCH v2] cselib: add function to check if SET is redundant [PR106187]

[Jeff Law via Gcc-patches]

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]

[Harald Anlauf via Gcc-patches]

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 

[Bug target/106484] Failure to optimize uint64_t/constant division on ARM32

[rsaxvc at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106484

rsaxvc at gmail dot com changed:

   What|Removed |Added

 CC||rsaxvc at gmail dot com

--- Comment #1 from rsaxvc at gmail dot com ---
Created attachment 53388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53388=edit
example umulh implementation

C implementation of umulh which can be used to optimize uint64_t/constant
division on 32-bit processors without a umulh instruction but with a
32x32=64bit multiplier.

[Bug target/106484] New: Failure to optimize uint64_t/constant division on ARM32

[rsaxvc at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106484

Bug ID: 106484
   Summary: Failure to optimize uint64_t/constant division on
ARM32
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsaxvc at gmail dot com
  Target Milestone: ---
Target: arm

The following test function compiles into a call to __aeabi_uldivmod, even
though the divisor is a constant. Here's an example function:

#include 
uint64_t ns_to_s( uint64_t ns64 )
{
return ns64 / 10ULL;
}

CortexM4(-O3 -Wall -Wextra -mcpu=cortex-m4) assembly:

ns_to_s(unsigned long long):
push{r3, lr}
adr r3, .L4
ldrdr2, [r3]
bl  __aeabi_uldivmod
pop {r3, pc}
.L4:
.word   10
.word   0

Interestingly, gcc 12.1 for aarch64 compiles the above C function by
implementing division by a constant with scaled multiplication by the inverse
using the umulh instruction(not present on 32-bit ARM). (-O3 -Wall -Wextra):

ns_to_s(unsigned long):
mov x1, 23123
lsr x0, x0, 9
movkx1, 0xa09b, lsl 16
movkx1, 0xb82f, lsl 32
movkx1, 0x44, lsl 48
umulh   x0, x0, x1
lsr x0, x0, 11
ret

Instead, if something like __umulh could be added to libgcc, then GCC could use
the constants generated in the aarch64 logic to implement uint64_t/constant
division. Example umulh approach is attached. On Cortex-M4, the umulh-based
approach is significantly faster, although this depends on the specific libc
__aeabi_uldivmod linked against as well as the numerator.

Re: [PATCH, v3] Fortran: detect blanks within literal constants in free-form mode [PR92805]

[Harald Anlauf via Gcc-patches]

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

[Ian Lance Taylor via Gcc-patches]

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

[Jeff Law via Gcc-patches]

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

[Jeff Law via Gcc-patches]

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

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[schwab--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472

--- Comment #10 from Andreas Schwab  ---
libbacktrace and libphobos are target modules that are part of the bootstrap
stages.  libgo and libgfortran are target modules that are _not_ part of the
bootstrap stages.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
toplevel Makefile.in has:
all-target-libphobos: maybe-all-target-libbacktrace
and
all-target-libgo: maybe-all-target-libbacktrace
configure-target-libgfortran: maybe-all-target-libbacktrace
but unlike the first one, the latter two are surrounded by
@unless gcc-bootstrap
...
@endunless gcc-bootstrap
and when bootstrap isn't disabled they don't appear in toplevel Makefile.
What causes that difference, no idea.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[roger at nextmovesoftware dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472

--- Comment #8 from Roger Sayle  ---
Investigating further, using an absolute path doesn't help, but interestingly
after the failure, repeatedly trying "make -j 8 bootstrap" a few times, allows
the build to progress after several attempts, so it looks like a race condition
issue, caused by a missing (serializing) dependency.

Re: [PATCH] libgccjit.h: Make the macro definition for testing gcc_jit_context_new_bitcast correctly available.

[Vibhav Pant via Gcc-patches]

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

[Maciej W. Rozycki]

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

[Bug c++/106483] undefined reference to function implemented in shared library if putting main.cpp after options, but non of any error when putting before options

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106483

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jonathan Wakely  ---
Firstly, this is the linker doing this, not GCC. GCC just passes the arguments
to the linker in the order you specify them.

Secondly, this is the correct behaviour. Your linker is set up to default to
--as-needed which means that shared libraries on the command line will only get
used if they satisfy a non-weak undefined reference from a regular object file
that has already been processed by the linker. If you put -ladd before main.cpp
then there are no undefined symbols yet, so the library is just ignored.

https://web.archive.org/web/20210609020437/c-faq.com/lib/libsearch.html

Either link with -Wl,--no-as-needed to change the linker's behaviour so that
shared libraries are always used, or put the libraries in the right order.

[Bug c++/106483] New: undefined reference to function implemented in shared library if putting main.cpp after options, but non of any error when putting before options

[xyang619 at 126 dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106483

Bug ID: 106483
   Summary: undefined reference to function implemented in shared
library if putting main.cpp after options, but non of
any error when putting before options
   Product: gcc
   Version: og10 (devel/omp/gcc-10)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xyang619 at 126 dot com
  Target Milestone: ---

GCC version and OS: gcc version 10.2.1 20210110 (Debian 10.2.1-6)
Code example to reproduce the bugs:
#add.h
int add(int, int);

#add.cpp

#include "add.h"
int add(int a, int b) {
return a+b;
}

#main.cpp
#include "add.h"
#include 
int main() {
int a=2;
int b=3;
int c=add(a,b);
printf("%d\n", c);
return 0;
}

#first, compile add.cpp to shared library, it works well
g++ -Wall -fPIC -shared -o libadd.so add.cpp

#second, compile main.cpp and link with the libadd.so, it will produce error as
followed:
g++ -Wall -L. -ladd -o add_main main.cpp
/usr/bin/ld: /tmp/ccCzqGbU.o: in function `main':
main.cpp:(.text+0x21): undefined reference to `add(int, int)'
collect2: error: ld returned 1 exit status

#however, if I put the main.cpp before the options, it works well
g++ main.cpp -Wall -L. -ladd -o add_main

[PATCH] libfortran: Fix up boz_15.f90 on powerpc64le with -mabi=ieeelongdouble [PR106079]

[Jakub Jelinek via Gcc-patches]

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

[Bug target/101438] Compiler hang on inline asm with local register and alloca

[andrey.vihrov at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101438

--- Comment #4 from Andrey Vihrov  ---
Looks like this is a duplicate of bug 105032 (or vice versa).

Both samples from this bug succeed for me with GCC 11.3 and GCC 12.

[Bug libfortran/106079] [12/13 regression] gfortran.dg/boz_15.f90 fails after r12-6498-g07c60b8e33

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106079

--- Comment #6 from Jakub Jelinek  ---
And on the box I was working on this fix (Fedora 34, glibc 2.33) without the
fix I see in ../configure --enable-languages=c,c++,fortran
--with-long-double-format=ieee --with-long-double-128
make check-gfortran RUNTESTFLAGS='dg.exp=boz* c-interop.exp'
Running /home/jakub/gcc/gcc/testsuite/gfortran.dg/c-interop/c-interop.exp ...
Running /home/jakub/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/boz_15.f90   -O0  execution test
FAIL: gfortran.dg/boz_15.f90   -O1  execution test
FAIL: gfortran.dg/boz_15.f90   -O2  execution test
FAIL: gfortran.dg/boz_15.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/boz_15.f90   -O3 -g  execution test
FAIL: gfortran.dg/boz_15.f90   -Os  execution test

=== gfortran Summary ===

# of expected passes1963
# of unexpected failures6
# of unsupported tests  12
and with the change:
Running /home/jakub/gcc/gcc/testsuite/gfortran.dg/c-interop/c-interop.exp ...
Running /home/jakub/gcc/gcc/testsuite/gfortran.dg/dg.exp ...

=== gfortran Summary ===

# of expected passes1969
# of unsupported tests  12

For the latter

PASS: gfortran.dg/c-interop/allocatable-dummy.f90   -Os  execution test
CFI_allocate: Base address of C descriptor must be NULL.
CFI_allocate: The object of the C descriptor must be a pointer or allocatable
variable.
CFI_deallocate: Base address is already NULL.
PASS: gfortran.dg/c-interop/allocate-errors.f90   -O0  execution test
PASS: gfortran.dg/c-interop/argument-association-assumed-rank-7.f90   -O1 
execution test
PASS: gfortran.dg/c-interop/argument-association-assumed-rank-7.f90   -O2 
(test for excess errors)




PASS: gfortran.dg/c-interop/cf-descriptor-3.f90   -O2  execution test
,
   ]>
,
   ]>
,
   ]>
PASS: gfortran.dg/c-interop/cf-descriptor-7.f90   -Os  execution test
]>
]>
]>
]>
PASS: gfortran.dg/c-interop/contiguous-3.f90   -O0  execution test
in the log.  So, I can't really reproduce the above.

Not really clear how it could be related though, e.g. contiguous-3.f90 doesn't
have anything real/complex related in it.
C_LONG_DOUBLE is only present in typecodes-array-longdouble.f90 and
typecodes-scalar-longdouble.f90.

[Bug libfortran/106079] [12/13 regression] gfortran.dg/boz_15.f90 fails after r12-6498-g07c60b8e33

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106079

--- Comment #5 from Jakub Jelinek  ---
Strange, in my 12 branch distro (scratch) build the only differences with the
patch are:
-FAIL: gfortran.dg/boz_15.f90   -O0  execution test
-FAIL: gfortran.dg/boz_15.f90   -O1  execution test
-FAIL: gfortran.dg/boz_15.f90   -O2  execution test
-FAIL: gfortran.dg/boz_15.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
-FAIL: gfortran.dg/boz_15.f90   -O3 -g  execution test
-FAIL: gfortran.dg/boz_15.f90   -Os  execution test
and nothing else.

[Bug debug/106261] [10/11 Regression] ICE in output_call_frame_info, at dwarf2out.cc:943

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106261

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression] ICE   |[10/11 Regression] ICE in
   |in output_call_frame_info,  |output_call_frame_info, at
   |at dwarf2out.cc:943 |dwarf2out.cc:943

--- Comment #7 from Jakub Jelinek  ---
Fixed for 12.2+ too.

[Bug middle-end/106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106449

--- Comment #13 from Jakub Jelinek  ---
Fixed for 12.2+ too.

[Bug bootstrap/106482] New: [12 Regression] bootstrap of 12.1.0 using 4.8.2 fails with C++ errors

[skunk at iskunk dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106482

Bug ID: 106482
   Summary: [12 Regression] bootstrap of 12.1.0 using 4.8.2 fails
with C++ errors
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

I attempted to bootstrap 12.1.0 using GCC 4.8.2. The documented prerequisites
include an "ISO C++11 compiler," so this appears to be a supported arrangement.

GCC 12 was configured with --disable-shared --disable-nls
--enable-version-specific-runtime-libs --with-pic --disable-multilib
--with-arch=opteron --disable-libcc1 --enable-languages=c,c++,lto

The bootstrap failed as shown below. I was able to bootstrap 10.2.0 using the
original compiler, and then bootstrapped 12.1.0 with that intermediary.


tg-g++ -std=c++11  -fno-PIE -c   -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/src/gcc-12.1.0/gcc
-I/home/src/gcc-12.1.0/gcc/. -I/home/src/gcc-12.1.0/gcc/../include
-I/home/src/gcc-12.1.0/gcc/../libcpp/include
-I/home/src/gcc-12.1.0/gcc/../libcody -I/home/sfw/arch/linux64/include
-I/home/sfw/arch/linux64/include -I/home/sfw/arch/linux64/include 
-I/home/src/gcc-12.1.0/gcc/../libdecnumber
-I/home/src/gcc-12.1.0/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/src/gcc-12.1.0/gcc/../libbacktrace   -o fwprop.o -MT fwprop.o -MMD -MP
-MF ./.deps/fwprop.TPo /home/src/gcc-12.1.0/gcc/fwprop.cc
In file included from /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:491:0,
 from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.tcc:24:1: error: prototype for
'typename base_splay_tree::node_type
base_splay_tree::get_child(typename Accessors::node_type, unsigned
int)' does not match any in class 'base_splay_tree'
 base_splay_tree::get_child (node_type node, unsigned int index)
 ^
In file included from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45:0,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.h:125:20: error: candidate is: static
typename Accessors::node_type base_splay_tree::get_child(typename
Accessors::node_type, unsigned int)
   static node_type get_child (node_type, unsigned int);
^
In file included from /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:491:0,
 from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.tcc:49:1: error: prototype for
'typename base_splay_tree::node_type
base_splay_tree::promote_child(typename Accessors::node_type,
unsigned int)' does not match any in class 'base_splay_tree'
 base_splay_tree::promote_child (node_type node, unsigned int index)
 ^
In file included from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45:0,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.h:128:15: error: candidates are:
static void base_splay_tree::promote_child(typename
Accessors::node_type, unsigned int, typename Accessors::node_type)
   static void promote_child (node_type, unsigned int, node_type);
   ^
/home/src/gcc-12.1.0/gcc/splay-tree-utils.h:127:20: error:
static typename Accessors::node_type
base_splay_tree::promote_child(typename Accessors::node_type,
unsigned int)
   static node_type promote_child (node_type, unsigned int);
^
In file included from /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:491:0,
 from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.tcc:187:1: error: prototype for
'typename base_splay_tree::node_type
base_splay_tree::splay_limit(typename Accessors::node_type)' does
not match any in class 'base_splay_tree'
 base_splay_tree::splay_limit (node_type start)
 ^
In file included from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45:0,
 from /home/src/gcc-12.1.0/gcc/fwprop.cc:29:
/home/src/gcc-12.1.0/gcc/splay-tree-utils.h:131:20: error: candidate is:
template template static typename
Accessors::node_type base_splay_tree::splay_limit(typename
Accessors::node_type)
   static node_type splay_limit (node_type);
^
In file included from /home/src/gcc-12.1.0/gcc/splay-tree-utils.h:491:0,
 from /home/src/gcc-12.1.0/gcc/rtl-ssa.h:45,
 from 

[x86_64 PATCH take #2] PR target/106450: Tweak timode_remove_non_convertible_regs.

[Roger Sayle]

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, 

[Bug middle-end/106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106449

--- Comment #12 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:681c73db9bd156f9b65a73ccc6c4a0a697fe70d6

commit r12-8645-g681c73db9bd156f9b65a73ccc6c4a0a697fe70d6
Author: Jakub Jelinek 
Date:   Fri Jul 29 09:49:11 2022 +0200

openmp: Fix up handling of non-rectangular simd loops with pointer type
iterators [PR106449]

There were 2 issues visible on this new testcase, one that we didn't have
special POINTER_TYPE_P handling in a few spots of expand_omp_simd - for
pointers we need to use POINTER_PLUS_EXPR and need to have the non-pointer
part in sizetype, for non-rectangular loop on the other side we can rely on
multiplication factor 1, pointers can't be multiplied, without those
changes
we'd ICE.  The other issue was that we put n2 expression directly into a
comparison in a condition and regimplified that, for the [512] case that
and with gimplification being destructed that unfortunately meant
modification
of original fd->loops[?].n2.  Fixed by unsharing the expression.  This was
causing a runtime failure on the testcase.

2022-07-29  Jakub Jelinek  

PR middle-end/106449
* omp-expand.cc (expand_omp_simd): Fix up handling of pointer
iterators in non-rectangular simd loops.  Unshare fd->loops[i].n2
or n2 before regimplifying it inside of a condition.

* testsuite/libgomp.c-c++-common/pr106449.c: New test.

(cherry picked from commit 97d32048c04e9787fccadc4bae1c042754503e34)

[Bug debug/106261] [10/11/12 Regression] ICE in output_call_frame_info, at dwarf2out.cc:943

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106261

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:0062d8491c20eb95411ac0b112e09ec0cee836d1

commit r12-8644-g0062d8491c20eb95411ac0b112e09ec0cee836d1
Author: Jakub Jelinek 
Date:   Wed Jul 27 12:06:22 2022 +0200

cgraphunit: Don't emit asm thunks for -dx [PR106261]

When -dx option is used (didn't know we have it and no idea what is it
useful for), we just expand functions to RTL and then omit all further
RTL passes, so the normal functions aren't actually emitted into assembly,
just variables.
The following testcase ICEs, because we don't emit the methods, but do
emit thunks pointing to that and those thunks have unwind info and rely on
at least some real functions to be emitted (which is normally the case,
thunks are only emitted for locally defined functions) because otherwise
there are no CIEs, only FDEs and dwarf2out is upset about it.

The following patch fixes that by not emitting assembly thunks for -dx
either.

2022-07-27  Jakub Jelinek  

PR debug/106261
* cgraphunit.cc (cgraph_node::assemble_thunks_and_aliases): Don't
output asm thunks for -dx.

* g++.dg/debug/pr106261.C: New test.

(cherry picked from commit f9671b60f9395cb1dca128b92f5dd215f5aeaae1)

[Bug middle-end/106144] wide_int shifted_mask() and mask() do not agree

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106144

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:527dccb33e54ffe49fb1507fc4539968f48a9d12

commit r12-8643-g527dccb33e54ffe49fb1507fc4539968f48a9d12
Author: Jakub Jelinek 
Date:   Fri Jul 1 11:17:41 2022 +0200

wide-int: Fix up wi::shifted_mask [PR106144]

As the following self-test testcase shows, wi::shifted_mask sometimes
doesn't create canonicalized wide_ints, which then fail to compare equal
to canonicalized wide_ints with the same value.
In particular, wi::mask (128, false, 128) gives { -1 } with len 1 and prec
128,
while wi::shifted_mask (0, 128, false, 128) gives { -1, -1 } with len 2
and prec 128.
The problem is that the code is written with the assumption that there are
3 bit blocks (or 2 if start is 0), but doesn't consider the possibility
where there are 2 bit blocks (or 1 if start is 0) where the highest block
isn't present.  In that case, there is the optional block of negate ? 0 :
-1
elts, followed by just one elt (either one from the if (shift) or just
negate ? -1 : 0) and the rest is implicit sign-extension.
Only if end < prec there is 1 or more bits above it that have different bit
value and so we need to emit all the elts till end and then one more elt.

if (end == prec) would work too, because we have:
  if (width > prec - start)
width = prec - start;
  unsigned int end = start + width;
so end is guaranteed to be end <= prec, dunno what is preferred.

2022-07-01  Jakub Jelinek  

PR middle-end/106144
* wide-int.cc (wi::shifted_mask): If end >= prec, return right
after
emitting element for shift or if shift is 0 first element after
start.
(wide_int_cc_tests): Add tests for equivalency of wi::mask and
wi::shifted_mask with 0 start.

(cherry picked from commit e52592073f6df3d7a3acd9f0436dcc32a8b7493d)

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[roger at nextmovesoftware dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472

--- Comment #7 from Roger Sayle  ---
At the point that this fails there is no
/home/roger/GCC/clean_go/x86_64-pc-linux-gnu/libbacktrace directory whilst
the build (make) is in /home/roger/GCC/clean_go/x86_64-pc-linux-gnu/libgo
I also don't use any "make -j N ..." flags, i.e. a purely sequential build,
so somewhere/somehow libgo is being built before libbacktrace ["-j" might 
also explain why the missing dependency isn't osbserved by everybody].

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[schwab--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472

--- Comment #6 from Andreas Schwab  ---
So what's the contents of .../x86_64-pc-linux-gnu/libbacktrace?

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[roger at nextmovesoftware dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472

Roger Sayle  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-30
 Status|UNCONFIRMED |NEW
 CC||roger at nextmovesoftware dot 
com
 Ever confirmed|0   |1

--- Comment #5 from Roger Sayle  ---
I see the same problem, building out of the source tree on x86_64-pc-linux-gnu
with GNU make 3.82.  I thought it was a (long standing) known issue, like in PR
104290, but it looks like some folks see this and others don't.  Odd.

make[4]: *** No rule to make target `../libbacktrace/libbacktrace.la', needed
by `libgo.la'.  Stop.
make[4]: Leaving directory `/home/roger/GCC/clean_go/x86_64-pc-linux-gnu/libgo'

configured with:
../gcc/configure --enable-languages=go

Perhaps it's using relative rather than absolute paths to configure?

Re: [PATCH, v3] Fortran: detect blanks within literal constants in free-form mode [PR92805]

[Mikael Morin]

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.

[Bug tree-optimization/106099] [13 Regression] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649

[zsojka at seznam dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106099

--- Comment #10 from Zdenek Sojka  ---
Thank you for the patch; I can still trigger the ICE with a degenerate testcase
though:

$ cat testcase.c
void
foo (void)
{
  for (unsigned i = 0; i == 0; i++)
__builtin_printf ("%d", i);
}
$ x86_64-pc-linux-gnu-gcc -O -fharden-compares -fno-tree-forwprop -fno-tree-ch
-fno-tree-dominator-opts -fno-tree-ccp -funreachable-traps
--param=scev-max-expr-size=1 testcase.c 
during GIMPLE pass: optimized
testcase.c: In function 'foo':
testcase.c:2:1: internal compiler error: in execute_todo, at passes.cc:2140
2 | foo (void)
  | ^~~
0x75616a execute_todo
/repo/gcc-trunk/gcc/passes.cc:2140
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/106481] [13 Regression] ICE: in native_encode_rtx, at simplify-rtx.cc:6884 with -O2 -fno-dce -fno-forward-propagate -fno-rerun-cse-after-loop

[roger at nextmovesoftware dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106481

Roger Sayle  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Last reconfirmed||2022-07-30
 Status|UNCONFIRMED |ASSIGNED
 CC||roger at nextmovesoftware dot 
com
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com

--- Comment #1 from Roger Sayle  ---
More TImode STV fallout.  This time with REG_EQUAL notes containing VOIDmode
(implicitly TImode) const_wide_int not being converted to explicit V1TImode
const_vector.  I'm bootstrapping and regression testing a fix.
[Thanks again to Zdenek]

Re: [PATCH, v3] Fortran: detect blanks within literal constants in free-form mode [PR92805]

[Thomas Koenig via Gcc-patches]

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

[Bug target/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

[sam at gentoo dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458

--- Comment #7 from Sam James  ---
Thanks Dave. I'd seen this failure when testing glibc 2.36 but hadn't looked
into it more (too warm to keep machine on).

[Bug target/68485] ICE while building gpsd package on microblaze

[sam at gentoo dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485

Sam James  changed:

   What|Removed |Added

 CC||sam at gentoo dot org

--- Comment #12 from Sam James  ---
Ajit doesn't seem to have a Bugzilla account.

[no subject]

[waqar ahmad via Gcc]

I want to apply for security visa for football match in Qatar

[Bug target/106481] New: [13 Regression] ICE: in native_encode_rtx, at simplify-rtx.cc:6884 with -O2 -fno-dce -fno-forward-propagate -fno-rerun-cse-after-loop

[zsojka at seznam dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106481

Bug ID: 106481
   Summary: [13 Regression] ICE: in native_encode_rtx, at
simplify-rtx.cc:6884 with -O2 -fno-dce
-fno-forward-propagate -fno-rerun-cse-after-loop
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 53387
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53387=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-dce -fno-forward-propagate
-fno-rerun-cse-after-loop testcase.c -Wno-psabi
testcase.c:13:1: internal compiler error: in native_encode_rtx, at
simplify-rtx.cc:6884
   13 | }
  | ^
0x7857b6 native_encode_rtx(machine_mode, rtx_def*, vec&, unsigned int, unsigned int)
/repo/gcc-trunk/gcc/simplify-rtx.cc:6884
0x16f2feb optimize_constant_pool
/repo/gcc-trunk/gcc/varasm.cc:4437
0x16fcbff output_shared_constant_pool()
/repo/gcc-trunk/gcc/varasm.cc:4544
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-1895-20220729130134-g6e0ca3fe88d-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-1895-20220729130134-g6e0ca3fe88d-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220729 (experimental) (GCC)

Re: [PATCH v3] LoongArch: add addr_global attribute

[Huacai Chen via Gcc-patches]

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.