[Bug middle-end/101934] [11 Regression] aarch64 memset code creates unaligned stores for -mstrict-align

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Andrew Pinski
:

https://gcc.gnu.org/g:f00530266f89b28e8286cdd2f587e046a27d2193

commit r11-9001-gf00530266f89b28e8286cdd2f587e046a27d2193
Author: Andrew Pinski 
Date:   Tue Aug 31 04:41:14 2021 +

Fix target/101934: aarch64 memset code creates unaligned stores for
-mstrict-align

The problem here is the aarch64_expand_setmem code did not check
STRICT_ALIGNMENT if it is creating an overlapping store.
This patch adds that check and the testcase works.

gcc/ChangeLog:

PR target/101934
* config/aarch64/aarch64.c (aarch64_expand_setmem):
Check STRICT_ALIGNMENT before creating an overlapping
store.

gcc/testsuite/ChangeLog:

PR target/101934
* gcc.target/aarch64/memset-strict-align-1.c: New test.

(cherry picked from commit a45786e9a31f995087d8cb42bc3a4fe06911e588)

[Bug middle-end/101934] [11 Regression] aarch64 memset code creates unaligned stores for -mstrict-align

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Andrew Pinski  ---
Fixed.

[Bug libstdc++/102358] New: niter_base and miter_base overloaded for move_iterator missing constexpr

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 102358
   Summary: niter_base and miter_base overloaded for move_iterator
missing constexpr
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

stl_iterator.h#L2416:

  template
auto
__niter_base(move_iterator<_Iterator> __it)
-> decltype(make_move_iterator(__niter_base(__it.base(
{ return make_move_iterator(__niter_base(__it.base())); }

  template
auto
__miter_base(move_iterator<_Iterator> __it)
-> decltype(__miter_base(__it.base()))
{ return __miter_base(__it.base()); }

They seem to be missing constexpr:

#include 
#include 

constexpr bool b = [] {
  std::array in{}, out{};
  std::move(std::move_iterator(in.begin()), std::move_iterator(in.end()),
out.begin());
  return true;
}();

https://godbolt.org/z/PTrTnxTnK

[Bug c++/102357] The type specified by explicitly defaulted special member function that is different with it should have had is well-formed

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

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

--- Comment #1 from Andrew Pinski  ---
Was there a change to C++ beteween C++17 and C++20 here?  A defect report?
Because clang errors out with the same message as GCC for C++17

[Bug middle-end/78463] pure/const functions are assumed not to trap

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

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

--- Comment #2 from Richard Biener  ---
There were more instances fixed (like PR70586 was), but there may be still
cases left.  Also there's still the missed optimization of
computing/propagating 'notrap'.

[Bug c++/102357] The type specified by explicitly defaulted special member function that is different with it should have had is well-formed

[xmh970252187 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from jim x  ---
This part in c++20 is more clear than c++17, which is added since c++20, see
https://timsong-cpp.github.io/cppwp/n4861/dcl.fct.def.default#2. What the
version I'm testing the code is GCC 12.0 with -std=c++20 command. See
https://godbolt.org/z/d7h4Mj3qG

[Bug c++/94302] [DR 2310] Type completeness and derived-to-base pointer conversions

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-16
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug c++/102357] The type specified by explicitly defaulted special member function that is different with it should have had is well-formed

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

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

--- Comment #3 from Andrew Pinski  ---
So I suspect it is/was DR 2221 :).
Basicallythe editorial changes resolved it.

So yes there is a change between C++17 and C++20.

[Bug c++/102357] The type specified by explicitly defaulted special member function that is different with it should have had is well-formed

[xmh970252187 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from jim x  ---
I haven't found that pull request. However, the proposal sources from P0641R2,
see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0641r2.html

[Bug middle-end/102080] [12 Regression] avx512vl related ICE, on firefox-92 gcc ICEs: in expand_insn, at optabs.c:7946 by r12-2679

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

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:a26ff83ed07e33c4aa46f3314553c0d15ca21100

commit r12-3569-ga26ff83ed07e33c4aa46f3314553c0d15ca21100
Author: liuhongt 
Date:   Thu Sep 2 13:05:54 2021 +0800

Check mask type when doing cond_op related gimple simplification.

gcc/ChangeLog:

PR middle-end/102080
* match.pd: Check mask type when doing cond_op related gimple
simplification.
* tree.c (is_truth_type_for): New function.
* tree.h (is_truth_type_for): New declaration.

gcc/testsuite/ChangeLog:

PR middle-end/102080
* gcc.target/i386/pr102080.c: New test.

[Bug c++/102305] intrinsic __is_constructible is wrong for templated abstract classes

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

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

--- Comment #8 from Jakub Jelinek  ---
Fixed for 11.3+ now too.

[Bug c++/88578] Static C++ objects with flexible array members overlap when initializes are non-const

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

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

--- Comment #8 from Jakub Jelinek  ---
Fixed for 12.1+ and 11.3+ for now.

[Bug c++/102295] ELF symbol sizes for variable-length objects are too small (C++)

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

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

--- Comment #10 from Jakub Jelinek  ---
Fixed also for 11.3+.

[Bug tree-optimization/102359] New: ICE gimplification failed since r12-3433-ga25e0b5e6ac8a77a

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

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

Bug ID: 102359
   Summary: ICE gimplification failed since
r12-3433-ga25e0b5e6ac8a77a
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: qing.zhao at oracle dot com
  Target Milestone: ---

The following fails:

$ cat cxx.cpp
struct A {
  double a = 111;
  auto foo() {
return [*this] { return a; };
  }
};
int X = A{}.foo()();

$ g++ cxx.cpp -c -ftrivial-auto-var-init=zero
gimplification failed:
&__closure->__this 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x77718930 fields  context

full-name "const struct A"
needs-constructor X() X(constX&) this=(X&) n_parents=0
use_template=0 interface-unknown
pointer_to_this  reference_to_this
>
readonly sizes-gimplified unsigned DI size  unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x77731000>
readonly
arg:0 
readonly
arg:0 
arg:0 
arg:1 
cxx.cpp:4:18 start: cxx.cpp:4:18 finish: cxx.cpp:4:18>
arg:1 
used nonlocal decl_7 DF cxx.cpp:4:14 size  unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context
 chain >
cxx.cpp:4:18 start: cxx.cpp:4:18 finish: cxx.cpp:4:18>>
cxx.cpp: In lambda function:
cxx.cpp:4:18: internal compiler error: gimplification failed
4 | return [*this] { return a; };
  |  ^
0xf2510a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:15569
0xf31e2b gimplify_modify_expr
/home/marxin/Programming/gcc/gcc/gimplify.c:5960
0xf2161f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:14556
0xf2515c gimplify_stmt(tree_node**, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:7006
0xf25196 gimplify_and_add(tree_node*, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:494
0xf25706 gimplify_assign(tree_node*, tree_node*, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:16148
0xf33fc8 gimple_add_init_for_auto_var
/home/marxin/Programming/gcc/gcc/gimplify.c:1777
0xf33fc8 gimplify_decl_expr
/home/marxin/Programming/gcc/gcc/gimplify.c:1937
0xf21a03 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:14753
0xf2515c gimplify_stmt(tree_node**, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:7006
0xf22f33 gimplify_statement_list
/home/marxin/Programming/gcc/gcc/gimplify.c:1997
0xf22f33 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:15001
0xf2515c gimplify_stmt(tree_node**, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:7006
0xf25fd0 gimplify_bind_expr
/home/marxin/Programming/gcc/gcc/gimplify.c:1426
0xf21f1a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:14757
0xf2515c gimplify_stmt(tree_node**, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:7006
0xf275e3 gimplify_body(tree_node*, bool)
/home/marxin/Programming/gcc/gcc/gimplify.c:15802
0xf27a7c gimplify_function_tree(tree_node*)
/home/marxin/Programming/gcc/gcc/gimplify.c:15956
0xd5c037 cgraph_node::analyze()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:670
0xd5ec77 analyze_functions
/home/marxin/Programming/gcc/gcc/cgraphunit.c:1234
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/102359] ICE gimplification failed since r12-3433-ga25e0b5e6ac8a77a

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

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
   Last reconfirmed||2021-09-16
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |12.0

[Bug tree-optimization/102360] New: ICE in can_native_interpret_type_p at gcc/fold-const.c:8800

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

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

Bug ID: 102360
   Summary: ICE in can_native_interpret_type_p at
gcc/fold-const.c:8800
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: qing.zhao at oracle dot com
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: aarch64-linux-gnu

The following fails:

$ aarch64-linux-gnu-g++
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/pr71294.C -fno-tree-dse -O1
-ftrivial-auto-var-init=pattern -c
during RTL pass: expand
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/pr71294.C: In function ‘void
fn1()’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/pr71294.C:58:19: internal
compiler error: Segmentation fault
   58 |   B d;
  |   ^
0xda6f3f crash_signal
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/toplev.c:328
0x7786239f ???
../sysdeps/unix/sysv/linux/sigaction.c:10
0xaaec00 can_native_interpret_type_p(tree_node*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/fold-const.c:8800
0xb614c6 expand_DEFERRED_INIT
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/internal-fn.c:3054
0x9885b7 expand_call_stmt
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:2749
0x9885b7 expand_gimple_stmt_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:3876
0x9885b7 expand_gimple_stmt
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:4040
0x98d112 expand_gimple_basic_block
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:6082
0x98ef66 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:6808
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/102360] ICE in can_native_interpret_type_p at gcc/fold-const.c:8800

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |12.0
   Priority|P3  |P1

[Bug rtl-optimization/102356] [11/12 Regression] compile-time explosion at -O3 -g in var-tracking since r11-209-g74dc179a6da33cd0

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|compile-time explosion at   |[11/12 Regression]
   |-O3 -g in var-tracking  |compile-time explosion at
   ||-O3 -g in var-tracking
   ||since
   ||r11-209-g74dc179a6da33cd0
 CC||marxin at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
If I see correctly, it started with r11-209-g74dc179a6da33cd0.

[Bug tree-optimization/102360] ICE in can_native_interpret_type_p at gcc/fold-const.c:8800

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2021-09-16

--- Comment #1 from Richard Biener  ---
Confirmed.

Program received signal SIGSEGV, Segmentation fault.
0x012f2e6b in can_native_interpret_type_p (type=)
at ../../src/trunk/gcc/fold-const.c:8800
8800  switch (TREE_CODE (type))


3049  if (!can_native_interpret_type_p (var_type))
3050{
3051  alt_type
3052= lang_hooks.types.type_for_mode (TYPE_MODE (var_type),
3053  TYPE_UNSIGNED
(var_type));
3054  gcc_assert (can_native_interpret_type_p (alt_type));
3055}

alt_type doesn't need to exist.  TYPE_MODE is OImode here.
Another issue will be that native_interpret_int refuses to interpret
types bigger than 128bit.  So using

  alt_type = build_nonstandard_integer_type 
   (GET_MODE_BITSIZE (TYPE_MODE (var_type)), 1);

will likely not help.  But if we know we're using an integer type
we can natively interpret ourselves.

Note there's another hole with variable-size and SVE vector modes I think.

I'm testing something.

[Bug target/102353] powerpc64le-linux-gnu build failure when build != host

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

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #5 from Tobias Burnus  ---
As crossref:

* r12-3098-g34ad198138f7a64355c92090e1db260ee135495d caused the regression
  "rs6000: Incorporate new builtins code into the build machinery"

* Submitted patch by me at:
  https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579553.html

[Bug tree-optimization/102359] ICE gimplification failed since r12-3433-ga25e0b5e6ac8a77a

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Confirmed.  So we end with '&__closure->__this' which indeed isn't an lvalue.

The issue here is that we are initializing the VAR_DECL 'this' but that
has a DECL_VALUE_EXPR expanding to &__closure->__this:

const struct A * const this [value-expr: &__closure->__this];

note the variable is const as well, so emitting a runtime initializer might
have other issues (like trapping ...), or in this case, not being an lvalue.

But note the FE fails to mark the decl as TREE_READONLY - that would be an
easy thing to check (and something we fail to check in is_var_need_auto_init).
Thus sth like

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index f680292fd91..b2bfab47a2f 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -1824,7 +1824,9 @@ gimple_add_padding_init_for_auto_var (tree decl, bool
is_vla,
 static bool
 is_var_need_auto_init (tree decl)
 {
-  if (auto_var_p (decl)
+  if (VAR_P (decl)
+  && !TREE_READONLY (decl)
+  && auto_var_p (decl)
   && (flag_auto_var_init > AUTO_INIT_UNINITIALIZED)
   && (!lookup_attribute ("uninitialized", DECL_ATTRIBUTES (decl)))
   && !is_empty_type (TREE_TYPE (decl)))

should be needed.

Jason, any idea?

[Bug c++/102350] __builtin_source_location not available in earlier language modes

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

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

--- Comment #5 from Jonathan Wakely  ---
Sure. It's just a question of whether we're trying to provide a general purpose
extension available for users, or an internal helper for the std::lib. IIRC we
explicitly decided we only cared about supporting the latter.

[Bug c++/102350] __builtin_source_location not available in earlier language modes

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

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

--- Comment #6 from Jakub Jelinek  ---
Note, having the struct somewhere else isn't that useful unless you know
exactly how its non-static data members are named and what they mean, so
ideally a class with accessor methods, which is what std::source_location
provides currently.

At least during the development of __builtin_source_location, the exact naming
conventions of the members was left to the library (whether it wants _M_ or __
prefixes of the member names), the final implementation uses the libstdc++
naming conventions, but I bet if e.g. libc++ implements  we
could add support even for __ prefixes.

[Bug fortran/81344] Can't disable -ffpe-trap (or not documented)

[michael.osipov at siemens dot com via Gcc-bugs]

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

Michael Osipov  changed:

   What|Removed |Added

 CC||michael.osipov at siemens dot 
com

--- Comment #7 from Michael Osipov  ---
I'd like to request to seriously reconsider this ticket. We are currently
porting several 100 000 of LoC (electrical engineering) from HP Fortran F90 on
HP-UX to GFortran 9-11. The HP Fortran compiler convienently provides (for the
last 15 years):

> +FPOZVD and +FPo

Uppercase means enable and lowercase disable. I have the exact same situation
as Ignacio. CMake default config is +FPOZVD which translates to
-ffpe-trap=overflow,zero,invalid,denormal.
A small amount of applications disable a few flags to be runnable at all.
Properly applied with CMake
* Compile time: ./CMakeFiles/di1308.dir/flags.make:Fortran_FLAGS = +DSnative
+save -minshared +check=all +noppu +FPOZVD -w +FPo -g
* Link time: ./CMakeFiles/di1308.dir/link.txt:/opt/fortran90/bin/f90
-Wl,+s,+nodefaultrpath -Wl,-a,shared_archive -Wl,+n -Wl,+noobjdebug
-Wl,+dbgfile,di1308.dbg +DSnative +save -minshared +check=all +noppu +FPOZVD -w
+FPo -g 

There must be a way to have the same in GCC.

[Bug c/102361] New: Errors compiling Linux kernel 5.14.4 with CONFIG_FORTIFY=y

[dac324 at yahoo dot de via Gcc-bugs]

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

Bug ID: 102361
   Summary: Errors compiling Linux kernel 5.14.4 with
CONFIG_FORTIFY=y
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dac324 at yahoo dot de
  Target Milestone: ---

GCC version: gcc (GCC) 12.0.0 20210910 (experimental)

With this version, it is not possible to compile the Linux kernel sources
(tested with both 5.14.1 and 5.14.4). 

Problem is that GCC 12 conflicts with CONFIG_FORTIFY=y.

Errors thrown with the 5.14.1 kernel sources:

In function 'memset',
inlined from 'init_rock_state.part.0' at fs/isofs/rock.c:74:2:
./include/linux/fortify-string.h:172:17: error: call to '__write_overflow'
declared with attribute error: detected write beyond size of object passed as
1st parameter
  172 | __write_overflow();
  | ^~
make[2]: *** [scripts/Makefile.build:271: fs/isofs/rock.o] Error 1
make[1]: *** [scripts/Makefile.build:514: fs/isofs] Error 2

In function 'memcpy',
inlined from 'tl_to_darg.part.0' at fs/ext4/fast_commit.c:1295:2:
./include/linux/fortify-string.h:187:25: error: call to '__read_overflow2'
declared with attribute error: detected read beyond size of object passed as
2nd parameter
  187 | __read_overflow2();
  | ^~
make[2]: *** [scripts/Makefile.build:271: fs/ext4/fast_commit.o] Error 1
make[1]: *** [scripts/Makefile.build:514: fs/ext4] Error 2


Error thrown with the 5.14.4 kernel sources:

In Function »memcpy«,
inserted from von »tl_to_darg.part.0« bei fs/ext4/fast_commit.c:1295:2:
./include/linux/fortify-string.h:187:25: Error: call to »__read_overflow2«
declared with attribute error: detected read beyond size of object passed as
2nd parameter
  187 | __read_overflow2();
  | ^~


With GCC 11, these errors do not occur. Hence, I must assume that they are
related to the compiler version.

[Bug c++/102357] The type specified by explicitly defaulted special member function that is different with it should have had is well-formed

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-09-16
 Ever confirmed|0   |1

--- Comment #5 from Jonathan Wakely  ---
(In reply to jim x from comment #0)
> There are no requirements to let implementations report an diagnosis, let

Implementations are always permitted to issue diagnostics (as warnings) for any
code.

> alone make the program ill-formed. A warning is sufficient here.

A warning is a diagnostic, so you're contradicting yourself.

The code is not ill-formed in C++20, so the implementation should "accept and
correctly execute" it ([intro.compliance.general] p2). So confirmed as a bug.

https://gcc.gnu.org/projects/cxx-status.html says that GCC 9 implemented
P0641R2, but apparently missed this bit.

[Bug c++/102357] The type specified by explicitly defaulted special member function that is different with it should have had is well-formed

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

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

--- Comment #6 from Jonathan Wakely  ---
https://github.com/cplusplus/draft/commit/219538a7be4f3e71f05070d1a52aa7150505e732
is the editorial change that resolved CWG 2221, but I don't think it's relevant
here.

[Bug ipa/60865] ICE: verify_cgraph_node failed: comdat-local function called by outside its comdat with -fdeclone-ctor-dtor

[zsojka at seznam dot cz via Gcc-bugs]

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

Zdenek Sojka  changed:

   What|Removed |Added

  Known to work||5.5.0, 6.5.0, 7.5.0, 8.5.0

--- Comment #4 from Zdenek Sojka  ---
I can't reproduce this any more on gcc-5.5.0 or newer, even with enabled
checking:

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-5-branch/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-5-branch/binary-5-branch-20171010081101-g926d9947847-checking-yes-rtl-df-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/5.5.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-5-branch//configure --enable-languages=c,c++
--disable-nls --enable-checking=yes,rtl,df --without-cloog --without-ppl
--without-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-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-5-branch//binary-5-branch-20171010081101-g926d9947847-checking-yes-rtl-df-nographite-amd64
Thread model: posix
gcc version 5.5.0 (GCC) 

$ x86_64-pc-linux-gnu-gcc -O3 -fdeclone-ctor-dtor
--param=ipa-cp-eval-threshold=1 testcase.C -c
(no output)

[Bug c++/102350] __builtin_source_location not available in earlier language modes

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Peter Dimov  ---
(In reply to Jonathan Wakely from comment #5)
> Sure. It's just a question of whether we're trying to provide a general
> purpose extension available for users, or an internal helper for the
> std::lib. IIRC we explicitly decided we only cared about supporting the
> latter.

Yes, of course. It's just that __builtin_source_location is so painfully close
to exactly what I want - it gives a single pointer representing the location -
that it would be a pity not being able to use it without -std=c++20.

[Bug c++/102350] __builtin_source_location not available in earlier language modes

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Peter Dimov  ---
(In reply to Jakub Jelinek from comment #6)
> Note, having the struct somewhere else isn't that useful unless you know
> exactly how its non-static data members are named and what they mean, so
> ideally a class with accessor methods, which is what std::source_location
> provides currently.

I was going to undefined-behavior my way to victory by making
boost::source_location layout-compatible with the internal struct, and just
casting the result of __builtin_source_location to boost::source_location
const*. I think this works under the GCC object model?

[Bug c++/102350] __builtin_source_location not available in earlier language modes

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

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

--- Comment #9 from Jakub Jelinek  ---
That would be an aliasing violation.
The artificial vars created by __builtin_source_location have the
std::source_location::__impl type, so accessing those using some other dynamic
type is invalid.

[Bug other/102362] New: 'dump_printf_loc' doesn't work from 'gate' method of a 'gimple_opt_pass'

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

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

Bug ID: 102362
   Summary: 'dump_printf_loc' doesn't work from 'gate' method of a
'gimple_opt_pass'
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

'dump_printf_loc' (guarded by the usual 'if (dump_enabled_p ())') of course
does work when called from the 'execute' method of a 'gimple_opt_pass', but I
found that it doesn't work when called from the 'gate' method:
'dumps_are_enabled' is 'false' at that point.

This may or may not be related to the "For some reason, this doesn't work"
issue I observed in commit 11b8286a83289f5b54e813f14ff56d730c3f3185 "[OpenACC
privatization] Largely extend diagnostics and corresponding testsuite coverage
[PR90115]": 'gcc/config/nvptx/nvptx.c:nvptx_goacc_expand_var_decl':

#if 0 /* For some reason, this doesn't work.  */
if (dump_enabled_p ())
  [dump_printf_loc ([...])]
#else /* ..., thus emulate that, good enough for testsuite usage.  */
[...]
#endif

[Bug c++/102350] __builtin_source_location not available in earlier language modes

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Peter Dimov  ---
(In reply to Jakub Jelinek from comment #9)
> That would be an aliasing violation.
> The artificial vars created by __builtin_source_location have the
> std::source_location::__impl type, so accessing those using some other
> dynamic type is invalid.

In that case, the only valid way to use the result of __builtin_source_location
would just be std::source_location itself. :-/

I wonder whether there's a conformance problem in making it available. It's
true that the identifier `source_location` isn't reserved, but only programs
that include `` can tell the difference, and these programs
(assuming they existed and worked) will probably be broken anyway because now
they'll be including the standard header instead of their own.

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

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

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

--- Comment #3 from Kewen Lin  ---
This seems not a target specific issue. I noticed the target_option tree node
is created expectedly when seeing target pragma, it explains why it works well
without lto. When lto does streaming out, it does stream the target_option
node. 

Creating output block for decls
Creating compressed section .gnu.lto_.decls.db802b44a7cc3ae9
Outputting global stream
 0:  
Streaming tree  
 Start of LTO_tree_scc of size 1
  Streaming header ofto decls
  Streaming body ofto decls
 286 bytes
 Start of LTO_tree_scc of size 1
  Streaming header ofto decls
  Streaming body ofto decls
 149 bytes

But debugging the read_decls part, I noticed it can materialize the
corresponding option_node, but it seems we don't associate this option_node to
the related function_decl. 


I constructed one aarch64 test case, it fails as well.

int64x2_t v1 = {100, 200};
int32x4_t v2 = {11, 22, 33, 44};

#pragma GCC target ("+simd")
int main()
{
  uint64x2_t vres = (uint64x2_t) __builtin_aarch64_usubw2v4si (v1, v2);
  printf("vres: %lld %lld\n", vres[0], vres[1]);
  return 0;
}

Command: -march=armv8-a+nosimd -flto

It can pass without -flto.

[Bug c/102361] Errors compiling Linux kernel 5.14.4 with CONFIG_FORTIFY=y

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2021-09-16
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Please isolate a pre-processed source file (-E) option and attach it here
together with the used command line.

[Bug c++/102350] __builtin_source_location not available in earlier language modes

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

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

--- Comment #11 from Jakub Jelinek  ---
That is not possible, because std::source_location::current() should be
consteval and it can't be in C++ < 20, and without consteval it will behave
significantly differently.  Note, the C++ FE knows
std::source_location::current() and has magic behavior for it, just consteval
semantics is not enough.
And by providing std::source_location without the current method for C++ < 20
there would be no way to initialize it to __builtin_source_location (),
std::source_location::__impl is private...

[Bug c++/102350] __builtin_source_location not available in earlier language modes

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

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

--- Comment #12 from Jonathan Wakely  ---
We could have added std::__source_location_impl as the type that the built-in
returns and used that instead of making it a private member of
std::source_location. That would also have allowed it to be used by
std::experimental::source_location, and by other users outside the std::lib.

[Bug c++/102350] __builtin_source_location not available in earlier language modes

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

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

--- Comment #13 from Jonathan Wakely  ---
It wouldn't work correctly in all cases, as Jakub points out, because
std::source_location::current() is part of the magic.

And I'm not convinced we want/need to support those uses.

[Bug c++/102350] __builtin_source_location not available in earlier language modes

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

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

--- Comment #14 from Jakub Jelinek  ---
But we haven't done that that way and how would headers know if the
__builtin_source_location that is available is the old or new one?
As for std::experimental::source_location, could we change ABI of those?

[Bug c++/102350] __builtin_source_location not available in earlier language modes

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #15 from Peter Dimov  ---
(In reply to Jonathan Wakely from comment #13)
> It wouldn't work correctly in all cases, as Jakub points out, because
> std::source_location::current() is part of the magic.
> 
> And I'm not convinced we want/need to support those uses.

I think that users of __builtin_source_location will be content with the subset
of uses it supports. :-)

[Bug c++/102350] __builtin_source_location not available in earlier language modes

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #16 from Peter Dimov  ---
(In reply to Jakub Jelinek from comment #14)
> But we haven't done that that way and how would headers know if the
> __builtin_source_location that is available is the old or new one?

The header could do

namespace std {

  struct __source_location_impl { ... };

  class source_location {

using __impl = __source_location_impl;

// ...

  };
}

unless the compiler looks specifically for a nested struct, in which case

  class source_location {

struct __impl: __source_location_impl {};

// ...

  };

[Bug other/102362] 'dump_printf_loc' doesn't work from 'gate' method of a 'gimple_opt_pass'

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

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

--- Comment #1 from Richard Biener  ---
Why would you call such method from the gate()?

[Bug c++/102350] __builtin_source_location not available in earlier language modes

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

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

--- Comment #17 from Jakub Jelinek  ---
You'd need a different builtin (so that you know the presence of the builtin
means the new behavior), ideally tell the builtin some way the type it should
construct objects in (as opposed to std::source_location::__impl), because
otherwise you don't know how __builtin_source_location will behave (except for
libstdc++ where for GCC we expect to support only the same GCC/libstdc++
combo).
But more importantly, how would you use the builtin?  I expect not using the
builtin directly, so through a macro?  Otherwise, if it is some inline
function, you'd most likely get the location of the inline function and not
that of the caller.  That is part of the magic std::source_location::current
behavior where exactly takes the location from for the builtin...

[Bug c++/102363] New: source_location in await_transform has function_name referring to internal coroutine funclet rather than source-level function

[redbeard0531 at gmail dot com via Gcc-bugs]

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

Bug ID: 102363
   Summary: source_location in await_transform has function_name
referring to internal coroutine funclet rather than
source-level function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

When a promise_type::await_transform() has a defaulted argument of
source_location::current(), it refers to the location of the co_await that
triggered the await_transform. This is really useful for building runtime
diagnostics and tracing. The file/line/column fields all seem to be filled out
correctly, however, the function_name field refers to an internal funclet that
the coroutine function is split into. I think it would be more useful if it had
the original corountine function name since that is what users will be
expecting.

Example: https://godbolt.org/z/sbMsPG8Eq

Output:
  good: /app/example.cpp:20:43: example func()
  bad: /app/example.cpp:25:14: void func(func()::_Z4funcv.frame*)

Source (compiled with just -std=c++20):
#include 
#include 
#include 
struct example {
struct promise_type {
std::suspend_never initial_suspend() { return {}; }
std::suspend_never final_suspend() noexcept { return {}; }
void unhandled_exception() { throw; }
example get_return_object() { return {}; }
void return_void() {}

auto await_transform(const char* dummy, std::source_location l =
std::source_location::current()) {
printf("bad: %s:%u:%u: %s\n", l.file_name(), l.line(), l.column(),
l.function_name());
return std::suspend_never();
}
};
};

example func() {
auto l = std::source_location::current();
printf("good: %s:%u:%u: %s\n", l.file_name(), l.line(), l.column(),
l.function_name());

// bad location points here:
//   v
co_await "pretend this is an awaitable";
}

int main() {
func();
}

[Bug tree-optimization/102360] ICE in can_native_interpret_type_p at gcc/fold-const.c:8800

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:8d6b12b2233dabf3573383a15ccc67fdb925e5b3

commit r12-3578-g8d6b12b2233dabf3573383a15ccc67fdb925e5b3
Author: Richard Biener 
Date:   Thu Sep 16 11:19:14 2021 +0200

middle-end/102360 - adjust .DEFERRED_INIT expansion

This avoids using native_interpret_type when we cannot do it with
the original type of the variable, instead use an integer type
for the initialization and side-step the size limitation of
native_interpret_int.

2021-09-16  Richard Biener  

PR middle-end/102360
* internal-fn.c (expand_DEFERRED_INIT): Make pattern-init
of non-memory more robust.

* g++.dg/pr102360.C: New testcase.

[Bug tree-optimization/102360] ICE in can_native_interpret_type_p at gcc/fold-const.c:8800

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug other/102362] 'dump_printf_loc' doesn't work from 'gate' method of a 'gimple_opt_pass'

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

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

--- Comment #2 from Thomas Schwinge  ---
Here, to emit 'note: [...]' ('-fopt-info-note') if because of certain input
source code characteristics (derived from
'DECL_ATTRIBUTES(current_function_decl)'), certain code transformations
do/don't need to be done.  Primarily for GCC test suite usage (matching
'dg-note' for the relevant lines), but may also be useful for users.  (I can of
course move the detection of "certain input source code characteristics" and
'dump_printf_loc' into 'execute', but it was surprising that I couldn't do it
in 'gate'.)

[Bug c++/102350] __builtin_source_location not available in earlier language modes

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #18 from Peter Dimov  ---
I would use it like this: https://godbolt.org/z/1eqEx6678

#include 

struct error_category
{
};

error_category const& system_category();

struct error_code
{
error_code( int v, error_category const& cat, void const* loc =
__builtin_source_location() );
};

int main()
{
error_code ec( 5, system_category() );
}

provided, of course, I have some not-undefined way to interpret its result.

[Bug tree-optimization/102364] New: wrong code at -O1 and above on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 102364
   Summary: wrong code at -O1 and above on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[581] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210916 (experimental) [master r12-3577-g275a076f762] (GCC) 
[582] % 
[582] % gcctk -O0 small.c; a.out
[583] % 
[583] % gcctk -O1 small.c
[584] % ./a.out
Aborted
[585] % 
[585] % cat small.c
int a, b, *c = &b;
short d;
int main() {
  unsigned e = 1;
  for (d = 9; d > 8; d += 2) {
int *f = &a, **g = &f;
if (d > ++e)
  *g = c;
if (f != &b)
  __builtin_abort ();
  }
  return 0;
}

[Bug tree-optimization/102364] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-3136-g3673dcf6d6baeb67

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||guojiufu at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|wrong code at -O1 and above |[12 Regression] wrong code
   |on x86_64-linux-gnu |at -O1 and above on
   ||x86_64-linux-gnu since
   ||r12-3136-g3673dcf6d6baeb67

--- Comment #1 from Martin Liška  ---
Started with r12-3136-g3673dcf6d6baeb67.

[Bug tree-optimization/102364] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-3136-g3673dcf6d6baeb67

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

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

Martin Liška  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=102087
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |12.0
   Last reconfirmed||2021-09-16

[Bug tree-optimization/102364] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-3136-g3673dcf6d6baeb67

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P1
Version|unknown |12.0

[Bug c++/102350] __builtin_source_location not available in earlier language modes

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

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

--- Comment #19 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #14)
> As for std::experimental::source_location, could we change ABI of those?

Yes, we don't promise stability between major releases for the experimental
stuff (although in practice it doesn't change).

[Bug web/102365] New: Function attribute docs should have an anchor or id on each attribute.

[redbeard0531 at gmail dot com via Gcc-bugs]

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

Bug ID: 102365
   Summary: Function attribute docs should have an anchor or id on
each attribute.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html

This would make it easier to link to the docs for a specific attribute. There
is currently an anchor on the  tag (eg
https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html#index-g_t_0040code_007bartificial_007d-function-attribute-2500
for artificial), but that will scroll down so that the name of the attribute
isn't shown. Ideally the anchor should be on the  tag instead. A nice
enhancement would be to make the attribute name be a self-link to make it easy
to get the link without needing to poke in the browser's inspect facility.

[Bug web/102365] Function attribute docs should have an anchor or id on each attribute.

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-16
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, it's a known issue and one of the motivation why we should switch ti
Sphinx documentation.

[Bug web/102365] Function attribute docs should have an anchor or id on each attribute.

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

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

--- Comment #2 from Jonathan Wakely  ---
See e.g. https://gcc.gnu.org/pipermail/gcc/2021-August/237078.html

[Bug c/102361] Errors compiling Linux kernel 5.14.4 with CONFIG_FORTIFY=y

[dac324 at yahoo dot de via Gcc-bugs]

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

--- Comment #2 from DAC324  ---
Please let me kindly ask you for instructions on how to do that. 
As described in the introduction, I was trying to compile the Linux kernel from
the usual source tarball available on kernel.org.

What I did after extracting the sources was:

make menuconfig
make

If I understand correctly, I will have to interrupt the make process to extract
a pre-processed source file?

Please let me kindly ask for additional guidance.

Thank you very much and kind regards.

[Bug c/102361] Errors compiling Linux kernel 5.14.4 with CONFIG_FORTIFY=y

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
See https://gcc.gnu.org/bugs/
On the kernel side, I guess you want to use make V=1 so that it shows the
compiler command lines, then copy & paste relevant command both here and into
command line where you add -save-temps to it to get preprocessed source.

[Bug target/102353] powerpc64le-linux-gnu build failure when build != host

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

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

--- Comment #6 from Bill Schmidt  ---
Thanks, Tobias!  I'm sorry for getting this exactly backwards...

Your patch looks good.  I am doing a quick host=target=build bootstrap and will
respond on-list when it'sdone.

[Bug c/102361] Errors compiling Linux kernel 5.14.4 with CONFIG_FORTIFY=y

[dac324 at yahoo dot de via Gcc-bugs]

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

--- Comment #4 from DAC324  ---
Please let me kindly ask you for instructions on how to do that. 
As described in the introduction, I was trying to compile the Linux kernel from
the usual source tarball available on kernel.org.

What I did after extracting the sources was:

make menuconfig
make

If I understand correctly, I will have to interrupt the make process to extract
a pre-processed source file?

Please let me kindly ask for additional guidance.

Thank you very much and kind regards.

[Bug c/102361] Errors compiling Linux kernel 5.14.4 with CONFIG_FORTIFY=y

[dac324 at yahoo dot de via Gcc-bugs]

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

--- Comment #5 from DAC324  ---
OK, here we go:

make -f ./scripts/Makefile.build obj=mm/kfence \
 \
need-builtin=1 \
need-modorder=1
  gcc -Wp,-MMD,mm/.memcontrol.o.d -nostdinc -isystem
/usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include -I./arch/x86/include
-I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi
-I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi
-include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h
-include ./include/linux/compiler_types.h -D__KERNEL__ -fmacro-prefix-map=./=
-Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration
-Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu89
-mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64
-falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387
-mpreferred-stack-boundary=3 -mskip-rax-setup -march=sandybridge -mno-red-zone
-mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables
-mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables
-fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation
-Wno-format-overflow -Wno-address-of-packed-member -O2
-fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong
-Wimplicit-fallthrough=5 -Wno-unused-but-set-variable
-Wno-unused-const-variable -fno-stack-clash-protection -g -gdwarf-4 -pg
-mrecord-mcount -mfentry -DCC_USING_FENTRY -Wdeclaration-after-statement -Wvla
-Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds
-Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized
-fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time
-Werror=incompatible-pointer-types -Werror=designated-init
-Wno-packed-not-aligned -fplugin=./scripts/gcc-plugins/structleak_plugin.so
-fplugin-arg-structleak_plugin-byref-all -DSTRUCTLEAK_PLUGIN   
-DKBUILD_MODFILE='"mm/memcontrol"' -DKBUILD_BASENAME='"memcontrol"'
-DKBUILD_MODNAME='"memcontrol"' -D__KBUILD_MODNAME=kmod_memcontrol -c -o
mm/memcontrol.o mm/memcontrol.c
In file included from ./include/linux/string.h:262,
 from ./include/linux/bitmap.h:10,
 from ./include/linux/cpumask.h:12,
 from ./arch/x86/include/asm/paravirt.h:17,
 from ./arch/x86/include/asm/irqflags.h:63,
 from ./include/linux/irqflags.h:16,
 from ./include/linux/rcupdate.h:26,
 from ./include/linux/rculist.h:11,
 from ./include/linux/pid.h:5,
 from ./include/linux/sched.h:14,
 from ./include/linux/cgroup.h:12,
 from ./include/linux/memcontrol.h:13,
 from mm/memcontrol.c:29:
In function 'memset',
inlined from 'uncharge_gather_clear.part.0' at mm/memcontrol.c:6835:2:
./include/linux/fortify-string.h:172:17: error: call to '__write_overflow'
declared with attribute error: detected write beyond size of object passed as
1st parameter
  172 | __write_overflow();
  | ^~
make[1]: *** [scripts/Makefile.build:271: mm/memcontrol.o] Error 1
make: *** [Makefile:1851: mm] Error 2

[Bug c++/102283] Inconsistent/wrong overload resolution when using an initializer list and a defaulted template parameter

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

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

--- Comment #3 from Patrick Palka  ---
(In reply to Giuseppe D'Angelo from comment #2)
> Hi,
> 
> Do you think that in my original testcase the call should be rejected as
> ambiguous as well? (It seems "reasonable" to me, but maybe I'm missing some
> niche detail about overload resolution when combined with template
> deduction.)
> 
> 
> This small variation over the testcase:
> 
> 
> struct A { };
> struct B { };
> 
> template 
> void f(T &&); // #1
> void f(const B&) = delete; // #2
> 
> int main() {
>   f({});
> }
> 
> This now makes GCC select #2, and fail to compile because it's deleted;

I think this is because GCC considers the two ICSes to be incomparable, but
then #2 wins over #1 anyway because non-templates are preferred over templates
(as per [over.match.best]).

Whereas with Clang/MSVC, I presume they consider the ICS for #1 to be better
than that for #2 (though I haven't found the wording in the standard that
supports this), so #1 wins during the ICS comparison stage of overload
resolution.

> Clang and MSVC still select #1. But a further, minor change:
> 
> 
> struct A { };
> struct B { };
> 
> template  // <-- changed this
> void f(T &&); // #1
> void f(const B&) = delete; // #2
> 
> int main() {
>   f({});
> }
> 
> makes GCC select #1...

This example is a different because the ICS for #1 is a standard conversion
sequence (since the {} initializes a non-class) whereas for #2 it's a
user-defined conversion sequence (since the {} initializes a class), and the
former kind is always better than the latter.  So #1 wins due to having the
better ICS.

[Bug c/102361] Errors compiling Linux kernel 5.14.4 with CONFIG_FORTIFY=y

[dac324 at yahoo dot de via Gcc-bugs]

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

--- Comment #6 from DAC324  ---
Created attachment 51469
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51469&action=edit
File mm/memcontrol.c saved with -save-temps option

[Bug c/102361] Errors compiling Linux kernel 5.14.4 with CONFIG_FORTIFY=y

[dac324 at yahoo dot de via Gcc-bugs]

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

--- Comment #7 from DAC324  ---
Created attachment 51470
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51470&action=edit
File mm/memcontrol.c saved with -save-temps option (2/2)

[Bug c/102361] Errors compiling Linux kernel 5.14.4 with CONFIG_FORTIFY=y

[dac324 at yahoo dot de via Gcc-bugs]

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

--- Comment #8 from DAC324  ---
This is the first error; if make is used with -j greater than 1, several of
those errors occur (see introduction).

[Bug fortran/102366] New: [10/11/12 Regression] Illegal instruction with large arrays

[dominiq at lps dot ens.fr via Gcc-bugs]

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

Bug ID: 102366
   Summary: [10/11/12 Regression] Illegal instruction with large
arrays
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
  Target Milestone: ---

The following test

REAL(KIND=4) :: a(16776325), s
a=1.0_8
END

gives at run time

Illegal instruction

a(16775301) to a(16776324) gives

Segmentation fault

and below a(16776323) the code run as expected.

This occurred between r12-3046 (OK) and r12-3430 and r10-10049 (OK) and
r10-10122. It also affects r11-8981.

Note that

REAL(KIND=4) :: a(16776325), s
a(16776325)=1.0_8
END

compiles and runs witout problem.

[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Target||x86_64-darwin,
   ||x86_64-linux-gnu
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-09-16
 Ever confirmed|0   |1
   Keywords||wrong-code
 CC||iains at gcc dot gnu.org

--- Comment #1 from Iain Sandoe  ---
also fails on x86_64 linux (with a segv rather than a ill).

Linux:

(gdb) r
Starting program: /home/iains/t 

Program received signal SIGSEGV, Segmentation fault.
0x0040118c in MAIN__ () at dom1.f90:2
2   a=1.0_8


Darwin:

Process 14098 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x7ffeebbff900)
frame #0: 0x00010ec2 t`MAIN__ at dom1.f90:2:7
   1REAL(KIND=4) :: a(16,1024,1024), s
-> 2a=1.0_8
   3END
Target 0: (t) stopped.

[Bug c++/102367] New: Types may be defined in `decltype` or `sizeof` expressions in C++20

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 102367
   Summary: Types may be defined in `decltype` or `sizeof`
expressions in C++20
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

Since C++20 lambdas are allowed in not-evaluated context. So the code as
follows must be valid:
```
using T = decltype( []{ struct S{}; return S{}; }() );

[[maybe_unused]] constexpr auto N 
  = sizeof( []{ struct S{}; return S{}; }() );
```

It is indeed accepted by MSVC and Clang, but rejected by GCC, demo:
https://gcc.godbolt.org/z/jYjxcr1eP

The error is
```
error: types may not be defined in 'decltype' expressions
1 | using T = decltype( []{ struct S{}; return S{}; }() );
  | ^
: In lambda function:
:4:33: error: types may not be defined in 'sizeof' expressions
4 |   = sizeof( []{ struct S{}; return S{}; }() );
  | 
```

[Bug fortran/102368] New: Failure to compile program using the C_SIZEOF function in ISO_C_BINDING

[longb at cray dot com via Gcc-bugs]

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

Bug ID: 102368
   Summary: Failure to compile program using the C_SIZEOF function
in ISO_C_BINDING
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

> cat test.f90
program main
use,intrinsic ::  iso_c_binding
implicit none

character(kind=c_char, len=*), parameter :: blergh = 'abc'

print *, c_sizeof(blergh)
print *, c_sizeof(.true.)
print *, c_sizeof(5)
print *, c_sizeof(5.0)
print *, c_sizeof(5.0d0)
end program main

> gfortran test.f90
test.f90:7:18:

7 | print *, c_sizeof(blergh)
  |  1
Error: 'x' argument of 'c_sizeof' intrinsic at (1) must be an interoperable
data entity: Type shall have a character length of 1

> ifort test.f90
> ./a.out
 3
 4
 4
 4
 8

gfortran appears to be using pre-F08 rules for C_SIZEOF.

[Bug fortran/102369] New: VALUE attribute for arrays not allowed

[longb at cray dot com via Gcc-bugs]

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

Bug ID: 102369
   Summary: VALUE attribute for arrays not allowed
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

> cat test.f90
module mymod
contains
pure real function myfunc(x)
integer, value, dimension(:), intent(in) :: x
myfunc = x(1)
end function myfunc
end module mymod
program main
use mymod
implicit none
integer, parameter :: sz = 10
integer, dimension(sz) :: foo
foo = 42
print *, myfunc(foo)
end program main

> ifort test.f90
> ./a.out
   42.0

> gfortran test.f90
test.f90:4:14:

4 | integer, value, dimension(:), intent(in) :: x
  |  1
Error: VALUE attribute conflicts with DIMENSION attribute at (1)
test.f90:3:27:

3 | pure real function myfunc(x)
  |   1
Error: Dummy procedure 'x' of PURE procedure at (1) must also be PURE
test.f90:5:9:

5 | myfunc = x(1)
  | 1
Error: Reference to impure function 'x' at (1) within a PURE procedure
test.f90:9:5:

9 | use mymod
  | 1
Fatal Error: Cannot open module file 'mymod.mod' for reading at (1): No such
file or directory
compilation terminated.

> gfortran --version
GNU Fortran (GCC) 11.2.0 20210728 (Cray Inc.)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug fortran/102369] VALUE attribute for arrays not allowed

[longb at cray dot com via Gcc-bugs]

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

--- Comment #1 from Bill Long  ---
I assume the cascade of error messages all originate with the first one. The
combination of VALUE for an array is allowed in F08 and later versions.

[Bug demangler/102370] New: Runtime failure with allocatable component of allocatable parent and MOVE_ALLOC

[longb at cray dot com via Gcc-bugs]

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

Bug ID: 102370
   Summary: Runtime failure with allocatable component of
allocatable parent and MOVE_ALLOC
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

> cat test.f90
program main
implicit none

type mytype
real :: val
integer :: idx
type(mytype), allocatable :: next
end type mytype

type (mytype), allocatable :: top, temp
temp = mytype (5.0, 5, temp )
call move_alloc(top, temp%next)
call move_alloc(temp, top)
print *, temp%val
end program main

# Cray compiler
> ftn test.f90
> ./a.out
 5.

> gfortran test.f90
> ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f88d658e49f in ???
#1  0x7f88d72fc5c0 in get_float_string
at
../../../cray-gcc-11.2.0-202108140355.9bf1fd589a5c1/libgfortran/io/write_float.def:1110
#2  0x7f88d72fec65 in list_formatted_write_scalar
at
../../../cray-gcc-11.2.0-202108140355.9bf1fd589a5c1/libgfortran/io/write.c:1903
#3  0x400c91 in ???
#4  0x401145 in ???
#5  0x7f88d6579349 in ???
#6  0x4007c9 in ???
at ../sysdeps/x86_64/start.S:120
#7  0x in ???
Segmentation fault (core dumped)

[Bug fortran/102371] New: Error for type spec in FORALL statement

[longb at cray dot com via Gcc-bugs]

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

Bug ID: 102371
   Summary: Error for type spec in FORALL statement
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

> cat test.f90
program main
implicit none
integer, parameter :: long = selected_int_kind(18)
integer(long), parameter :: very_large = 128_long
integer, allocatable, dimension(:,:) :: ary
allocate(ary(very_large, 2))
forall(integer(long) :: i=1:very_large, j=1:2)
ary(i, j) = i * j
end forall
print *, ary(5, 2)
deallocate(ary)
end program main

> ifort test.f90
> ./a.out
  10

> gfortran test.f90
test.f90:7:8:

7 | forall(integer(long) :: i=1:very_large, j=1:2)
  |1
Error: Syntax error in FORALL statement at (1)
test.f90:9:3:

9 | end forall
  |   1
Error: Expecting END PROGRAM statement at (1)
test.f90:8:5:

8 | ary(i, j) = i * j
  | 1
Error: Symbol 'i' at (1) has no IMPLICIT type
test.f90:8:8:

8 | ary(i, j) = i * j
  |1
Error: Symbol 'j' at (1) has no IMPLICIT type



I assume all the errors are a cascade from the first error, which is the issue
in this bug.  FORALL statements are supposed to allow a type spec.

[Bug target/102372] New: [12 regression] ICE in gfortran.dg/ISO_Fortran_binding_1.f90 after r12-3482

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

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

Bug ID: 102372
   Summary: [12 regression] ICE in
gfortran.dg/ISO_Fortran_binding_1.f90 after r12-3482
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:5f6a6c91d7c592cb49f7c519f289777eac09bb74, r12-3482

This revision causes ICEs on power7 BE.  I did not see any failures on power 8
BE nor any power LE machines.

make  -k check-gcc-fortran
RUNTESTFLAGS="dg.exp=gfortran.dg/ISO_Fortran_binding_1.f90"

FAIL: gfortran.dg/ISO_Fortran_binding_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error)
FAIL: gfortran.dg/ISO_Fortran_binding_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gfortran.dg/ISO_Fortran_binding_1.f90   -O3 -g  (internal compiler error)
FAIL: gfortran.dg/ISO_Fortran_binding_1.f90   -O3 -g  (test for excess errors)

# of expected passes8
# of unexpected failures4
# of unresolved testcases   2

spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.f90
-fdiagnostics-plain-output -fdiagnostics-plain-output -O3 -g -pedantic-errors
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.c
-dumpbase 
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-lm -o ./ISO_Fortran_binding_1.exe
during GIMPLE pass: slp
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.f90:6:33:
internal compiler error: in rs6000_builtin_vectorization_cost, at
config/rs6000/rs6000.c:5215
0x11136277 rs6000_builtin_vectorization_cost
/home/seurer/gcc/git/gcc-test/gcc/config/rs6000/rs6000.c:5215
0x10f8f367 builtin_vectorization_cost
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.h:1520
0x10f8f367 record_stmt_cost(vec*, int,
vect_cost_for_stmt, _stmt_vec_info*, tree_node*, int, vect_cost_model_location)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.c:109
0x10f8fad7 record_stmt_cost
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.h:1913
0x10f8fad7 vect_get_store_cost(vec_info*, _stmt_vec_info*, int, unsigned int*,
vec*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.c:1049
0x10fb065b vect_model_store_cost
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.c:972
0x10fb065b vectorizable_store
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.c:7421
0x10fba8ef vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.c:10972
0x11009bab vect_slp_analyze_node_operations_1
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4523
0x11009bab vect_slp_analyze_node_operations
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4681
0x1100dc87 vect_slp_analyze_operations(vec_info*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4920
0x11011153 vect_slp_analyze_bb_1
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:5860
0x11011153 vect_slp_region
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:5907
0x110130d7 vect_slp_bbs
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:6099
0x11013733 vect_slp_function(function*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:6187
0x1101ee77 execute
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.c:1454
Pl

commit 5f6a6c91d7c592cb49f7c519f289777eac09bb74
Author: Richard Earnshaw 
Date:   Fri Sep 3 17:06:15 2021 +0100

gimple: allow more folding of memcpy [PR102125]

[Bug fortran/102371] Error for type spec in FORALL statement

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||kargl at gcc dot gnu.org
   Priority|P3  |P4
   Last reconfirmed||2021-09-16

--- Comment #1 from kargl at gcc dot gnu.org ---
This is likely a du0plicate of PR 78219.  Comment #7 of
that PR contains a patch, which should fix both PR 78219
and this PR.  Don't know if anyone will ever get around
to actually committed the patch.

[Bug tree-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22

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

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

--- Comment #4 from Martin Jambor  ---
(In reply to Martin Jambor from comment #3)
> ...I'll have a very brief look at what is actually happening just so that I
> have more reasons to believe this is not a code placement issue again.

The hot function is at the same address when compiled by both
revisions and the newer version looks sufficiently different.  I even
tried sprinkling it with nops and it did not help.  I am no saying we
are not bumping against some michro-architectural peculiarity but it
does not seem to be a code placement issue.

[Bug c++/39270] Explicit instantiation rejected

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka  ---
Slightly more reduced rejects-valid testcase:

template
void f(U); // #1

template
void f(int) { } // #2

template void f(int);


more_specialized_inst is unable to determine that #2 is more specialized than
#1.  Perhaps we should be passing the explicitly specified template arguments
to get_bindings?  But that ends up breaking
gcc/testsuite/g++.old-deja/g++.pt/explicit22.C among others..

[Bug c++/39270] Explicit instantiation rejected

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

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

Patrick Palka  changed:

   What|Removed |Added

 Blocks||102184

--- Comment #4 from Patrick Palka  ---
PR102184 is probably due to the same underlying bug


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102184
[Bug 102184] Explicit template instantiation thinks there is an ambiguous
template specialization when there is none for concepts

[Bug target/102353] powerpc64le-linux-gnu build failure when build != host

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:acd7e7b33fd576b336ca0bf5ec51f77b32ba51cc

commit r12-3581-gacd7e7b33fd576b336ca0bf5ec51f77b32ba51cc
Author: Tobias Burnus 
Date:   Thu Sep 16 18:35:34 2021 +0200

PowerPC: Fix rs6000-gen-builtins with build != host [PR102353]

This mimics what the main Makefile.in does: compile the generator
files under build (with Makefile.in's 'build/%.o' rule for compilation).
It also adds $(RUN_GEN) to optionally run it with valgrind and
the $(build_exeext) suffix.

Before, the .o files were compiled with $(COMPILE), causing link
error with $(LINKER_FOR_BUILD) for build != host.

gcc/
PR target/102353
* config/rs6000/t-rs6000 (build/rs6000-gen-builtins.o,
build/rbtree.o):
Added 'build/' to target, use build/%.o rule.
(build/rs6000-gen-builtins$(build_exeext)): Add 'build/' and
'$(build_exeext)' to target and 'build/' for the *.o files.
(rs6000-builtins.c): Update for those changes; run
rs6000-gen-builtins
with $(RUN_GEN).

[Bug target/102353] powerpc64le-linux-gnu build failure when build != host

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

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Tobias Burnus  ---
Should be FIXED :-)

@Bill: Thanks for testing the native build!

[Bug tree-optimization/102238] alias_offset in gimple-ssa-sprintf.c is broken

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

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks|102216  |84774
   Last reconfirmed||2021-09-16
 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=102216
 Ever confirmed|0   |1

--- Comment #5 from Martin Sebor  ---
Confirmed with the simplified test case below.  DOM3 is the last pass to run
before strlen.  The strlen output shows the sprintf call is being folded to
strcpy.  I'm not sure what the relationship of this bug is to pr102216 but a
missing -Wrestrict cannot be a cause of a missed optimization.  I've moved
pr102216 to See Also.

$ cat pr102238.c && gcc -O2 -S -Wall -fdump-tree-dom3=/dev/stdout pr102238.c
struct A
{
  char a[4];
};

struct B
{
  struct A a1, a2;
};

void f (struct B *p)
{
  enum { off = __builtin_offsetof (struct B, a2.a) };

  char *s = (char*)p + off;
  char *d = p->a2.a;

  __builtin_sprintf (d, "%s", s);   // missing -Wrestrict
}

;; Function f (f, funcdef_no=0, decl_uid=1983, cgraph_uid=1, symbol_order=0)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }
void f (struct B * p)
{
  char * d;
  char * s;

   [local count: 1073741824]:
  s_2 = p_1(D) + 4;
  d_3 = &p_1(D)->a2.a;
  __builtin_sprintf (d_3, "%s", s_2);
  return;

}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
[Bug 84774] [meta-bug] bogus/missing -Wrestrict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102216
[Bug 102216] [12 Regression] missed optimization causing Warray-bounds

[Bug tree-optimization/102238] alias_offset in gimple-ssa-sprintf.c is broken

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #6 from Martin Sebor  ---
Let me handle this.

[Bug debug/102373] New: Segmentation fault in dwarf2out.c, line 32744

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

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

Bug ID: 102373
   Summary: Segmentation fault in dwarf2out.c, line 32744
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux*
Target: hppa64-hp-hpux*
 Build: hppa64-hp-hpux*

Created attachment 51471
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51471&action=edit
Fix NULL pointer dereference

The fault occurs on trunk with the following:

int
main (void)
{
  return 0;
}

/home/dave/gnu/gcc/objdir64/./gcc/cc1 -fpreprocessed xxx.i -quiet -dumpbase xxx
.c -dumpbase-ext .c -g -O2 -version -fno-checking -o xxx.s
GNU C17 (GCC) version 12.0.0 20210907 (experimental) (hppa64-hp-hpux11.11)
compiled by GNU C version 12.0.0 20210907 (experimental), GMP version
6.
1.1, MPFR version 3.1.5, MPC version 1.0.3, isl version isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 12.0.0 20210907 (experimental) (hppa64-hp-hpux11.11)
compiled by GNU C version 12.0.0 20210907 (experimental), GMP version
6.
1.1, MPFR version 3.1.5, MPC version 1.0.3, isl version isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 64b9df7c6b0f1e93f698a828b6c17964
xxx.c:5:1: internal compiler error: Segmentation fault
5 | }
  | ^

(gdb) r
Starting program: /home/dave/gnu/gcc/objdir64/gcc/cc1 -fpreprocessed xxx.i
-quiet -dumpbase xxx.c -dumpbase-ext .c -g -O2 -version -fno-checking -o xxx.s
GNU C17 (GCC) version 12.0.0 20210907 (experimental) (hppa64-hp-hpux11.11)
compiled by GNU C version 12.0.0 20210907 (experimental), GMP version
6.1.1, MPFR version 3.1.5, MPC version 1.0.3, isl version isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 12.0.0 20210907 (experimental) (hppa64-hp-hpux11.11)
compiled by GNU C version 12.0.0 20210907 (experimental), GMP version
6.1.1, MPFR version 3.1.5, MPC version 1.0.3, isl version isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 64b9df7c6b0f1e93f698a828b6c17964

Program received signal SIGSEGV, Segmentation fault.
0x406939b4 in dwarf2out_early_finish (
filename=0x800100313eb0 "xxx.c") at ../../gcc/gcc/dwarf2out.c:32744
32744   producer_string = gen_producer_string (lang_hooks.name,
(gdb) disass
Dump of assembler code for function dwarf2out_early_finish(char const*):
   0x406938c8 <+0>: std rp,-10(sp)
   0x406938cc <+4>: addil L%-16800,dp,r1
   0x406938d0 <+8>: ldo 180(sp),sp
   0x406938d4 <+12>:std r13,-c8(sp)
   0x406938d8 <+16>:ldd 2b0(r1),r13
   0x406938dc <+20>:addil L%-16000,dp,r1
   0x406938e0 <+24>:std r7,-98(sp)
   0x406938e4 <+28>:ldd 230(r1),r7
   0x406938e8 <+32>:std r6,-90(sp)
   0x406938ec <+36>:std r18,-f0(sp)
   0x406938f0 <+40>:std r17,-e8(sp)
   0x406938f4 <+44>:std r16,-e0(sp)
   0x406938f8 <+48>:std r15,-d8(sp)
   0x406938fc <+52>:std r14,-d0(sp)
   0x40693900 <+56>:std r12,-c0(sp)
   0x40693904 <+60>:std r11,-b8(sp)
   0x40693908 <+64>:std r10,-b0(sp)
   0x4069390c <+68>:std r9,-a8(sp)
   0x40693910 <+72>:std r8,-a0(sp)
   0x40693914 <+76>:std r5,-88(sp)
   0x40693918 <+80>:std r4,-80(sp)
   0x4069391c <+84>:std r3,-78(sp)
---Type  to continue, or q  to quit---
   0x40693920 <+88>:ldb 0(r13),r19
   0x40693924 <+92>:std r19,-108(sp)
   0x40693928 <+96>:ldb 0(r7),ret0
   0x4069392c <+100>:   cmpib,<> 0,ret0,0x40695434

   0x40693930 <+104>:   copy r26,r6
   0x40693934 <+108>:   ldi 1,ret0
   0x40693938 <+112>:   stb ret0,0(r13)
   0x4069393c <+116>:   addil L%-16000,dp,r1
   0x40693940 <+120>:   ldd 238(r1),r11
   0x40693944 <+124>:   ldd 0(r11),r26
   0x40693948 <+128>:   cmpb,*= r0,r26,0x40694c60

   0x4069394c <+132>:   ldo -30(sp),ret1
   0x40693950 <+136>:   copy dp,r4
   0x40693954 <+140>:   ldo -30(sp),ret1
   0x40693958 <+144>:   b,l 0x40640ec0 ,rp
   0x4069395c <+148>:   ldi 25,r25
   0x40693960 <+152>:   copy r4,dp
   0x40693964 <+156>:   addil L%-27800,dp,r1
   0x40693968 <+160>:   ldd 440(r1),r31
   0x4069396c <+164>:   addil L%-27800,dp,r1
---Type  to continue, or q  to quit---
   0x40693970 <+168>:   copy ret0,r3
   0x40693974 <+172>:   ldd 

[Bug debug/102373] Segmentation fault in dwarf2out.c, line 32744

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Comment on attachment 51471
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51471
Fix NULL pointer dereference

This looks wrong, comp_unit_die () should have DW_AT_producer at this point.
gen_compile_unit_die should have added it...

[Bug tree-optimization/102238] alias_offset in gimple-ssa-sprintf.c is broken

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||102216

--- Comment #7 from Andrew Pinski  ---
(In reply to Martin Sebor from comment #5)
> Confirmed with the simplified test case below.  DOM3 is the last pass to run
> before strlen.  The strlen output shows the sprintf call is being folded to
> strcpy.  I'm not sure what the relationship of this bug is to pr102216 but a
> missing -Wrestrict cannot be a cause of a missed optimization.  I've moved
> pr102216 to See Also.

This issue is blocking the patch which I have created for PR 102216 and that is
how I found this issue so yes it is still blocking PR 102216.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102216
[Bug 102216] [12 Regression] missed optimization causing Warray-bounds

[Bug other/92435] % format codes for diagnostics are not documented in the GCC internals manual

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

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

--- Comment #4 from Eric Gallager  ---
(In reply to Martin Sebor from comment #3)
> See also the following question:
>   https://gcc.gnu.org/pipermail/gcc/2021-September/237281.html
> It would be helpful to document the GCC specific directives somewhere.  The
> -Wformat-diag GCC-developer warning option could also stand to be documented.

Yeah I was trying to convince the Wesnoth devs to look at -Wformat-diag for
inspiration for their own message-strings linter, but since it wasn't
documented, they didn't really know what to do, so I agree that documenting
that would be useful, too

[Bug c++/102283] Inconsistent/wrong overload resolution when using an initializer list and a defaulted template parameter

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Jason Merrill  ---
(In reply to Patrick Palka from comment #1)
> According to http://eel.is/c++draft/over.ics.rank#3.3 the two ICSes should
> be incomparable since they initialize different classes, so at least
> according to that paragraph it appears GCC is behaving correctly here.

I agree with your reading.

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

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

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

Eric Gallager  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||egallager at gcc dot gnu.org
 Status|ASSIGNED|RESOLVED

--- Comment #23 from Eric Gallager  ---
(In reply to Eric Gallager from comment #22)
> (In reply to Eric Gallager from comment #20)
> > (In reply to m...@gcc.gnu.org from comment #19)
> > > I'm fine with Backporting for affected branches.
> > 
> > So... that's still 6 and 7 at this point?
> 
> Er well just 7 now, since 6 is closed

7 is closed now, too, so I think that's all affected branches closed, meaning
this ought to be fixed on all open branches... closing as FIXED.

[Bug bootstrap/67102] Parallel build fails in libffi/configure

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

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

--- Comment #4 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:db1a65d9364fe72c2fff65fb2dec051728b6f3fa

commit r12-3583-gdb1a65d9364fe72c2fff65fb2dec051728b6f3fa
Author: Andrew Pinski 
Date:   Wed Sep 15 09:51:08 2021 +

Fix PR 67102: Add libstdc++ dependancy to libffi

The error message is obvious -funconfigured-libstdc++-v3 is used
on the g++ command line.  So we just add the dependancy.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

ChangeLog:

PR bootstrap/67102
* Makefile.def: Have configure-target-libffi depend on
all-target-libstdc++-v3.
* Makefile.in: Regenerate.

[Bug bootstrap/67102] Parallel build fails in libffi/configure

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Andrew Pinski  ---
Fixed.

[Bug debug/102373] Segmentation fault in dwarf2out.c, line 32744

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2021-09-16 1:38 p.m., jakub at gcc dot gnu.org wrote:
> This looks wrong, comp_unit_die () should have DW_AT_producer at this point.
> gen_compile_unit_die should have added it...
I did change dwarf_version to 4.

[Bug fortran/102287] optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines.

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:cfea7b86f2430b9cb8018379b071f4004233119c

commit r12-3584-gcfea7b86f2430b9cb8018379b071f4004233119c
Author: Harald Anlauf 
Date:   Thu Sep 16 20:12:21 2021 +0200

Fortran - fix handling of optional allocatable DT arguments with
INTENT(OUT)

gcc/fortran/ChangeLog:

PR fortran/102287
* trans-expr.c (gfc_conv_procedure_call): Wrap deallocation of
allocatable components of optional allocatable derived type
procedure arguments with INTENT(OUT) into a presence check.

gcc/testsuite/ChangeLog:

PR fortran/102287
* gfortran.dg/intent_out_14.f90: New test.

[Bug target/59697] Function attribute __target_(("no-avx)) does not work

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|Function attribute  |Function attribute
   |__target_(("no-avx)) work   |__target_(("no-avx)) does
   |on Windows/mingw but fails  |not work
   |on Linux.   |
   Keywords||rejects-valid
   Last reconfirmed||2021-09-16
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Confirmed.  The target header files don't turn off what was turned on via the
command line which causes the inline functions not to be usable that way.

In older versions of GCC this produced wrong code but in newer versions GCC
rejects the code.

Note clang has the same behavior ...

[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:58c76fb477b51adeb9241de0b175a817e9c73b8a

commit r11-9008-g58c76fb477b51adeb9241de0b175a817e9c73b8a
Author: Harald Anlauf 
Date:   Mon Sep 13 19:28:10 2021 +0200

Fortran - ensure simplification of bounds of array-valued named constants

gcc/fortran/ChangeLog:

PR fortran/82314
* decl.c (add_init_expr_to_sym): For proper initialization of
array-valued named constants the array bounds need to be
simplified before adding the initializer.

gcc/testsuite/ChangeLog:

PR fortran/82314
* gfortran.dg/pr82314.f90: New test.

(cherry picked from commit 104c05c5284b7822d770ee51a7d91946c7e56d50)

[Bug fortran/85130] Substrings out of range are not rejected

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:3bc4ed085145e1cb6089841c811094633eea7431

commit r11-9009-g3bc4ed085145e1cb6089841c811094633eea7431
Author: Harald Anlauf 
Date:   Mon Sep 13 19:26:35 2021 +0200

Fortran - fix handling of substring start and end indices

gcc/fortran/ChangeLog:

PR fortran/85130
* expr.c (find_substring_ref): Handle given substring start and
end indices as signed integers, not unsigned.

gcc/testsuite/ChangeLog:

PR fortran/85130
* gfortran.dg/substr_6.f90: Revert commit r8-7574, adding again
test that was erroneously considered as illegal.

(cherry picked from commit 8d93ba93d3b13ac3d3c34404cad87732c809605b)

[Bug target/102374] New: Should ignore spaces in target attribute

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

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

Bug ID: 102374
   Summary: Should ignore spaces in target attribute
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
void calculate_sse(void) __attribute__ ((__target__ ("no-avx, sse2")));

Currently we error out:
:1:6: error: attribute ' sse2' argument 'target' is unknown
1 | void calculate_sse(void) __attribute__ ((__target__ ("no-avx, sse2")));
  |  ^

It was not so obvious why though, the problem is there is a space after the
comma.

[Bug target/102375] New: (aarch64) Should allow space in target attribute

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

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

Bug ID: 102375
   Summary: (aarch64) Should allow space in target attribute
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*-*

Take:
void calculate(void) __attribute__ ((__target__ ("+sve, +sve2")));

Currently we produce:
:1:65: error: pragma or attribute 'target(" +sve2")' is not valid
1 | void calculate(void) __attribute__ ((__target__ ("+sve, +sve2")));
  | ^

It is not so obvious the space is not allowed here but maybe it should be.

[Bug target/102376] New: [aarch64] using target("sve") attribute without a + is not very helpful on what is wrong

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

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

Bug ID: 102376
   Summary: [aarch64] using target("sve") attribute without a + is
not very helpful on what is wrong
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*-*

Take:
void calculate(void) __attribute__ ((__target__ ("sve")));

Currently GCC produces:
:1:57: error: pragma or attribute 'target("sve")' is not valid
1 | void calculate(void) __attribute__ ((__target__ ("sve")));
  | ^

But maybe it should tell you that you need to add a + in front of sve.

Also this is inconstitant with x86_64 where you don't need the + sign.

[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:c38626f7a66dea400e54f671bfe32dc46e11ad44

commit r10-10131-gc38626f7a66dea400e54f671bfe32dc46e11ad44
Author: Harald Anlauf 
Date:   Thu Sep 9 21:34:01 2021 +0200

Fortran - out of bounds in array constructor with implied do loop

gcc/fortran/ChangeLog:

PR fortran/98490
* trans-expr.c (gfc_conv_substring): Do not generate substring
bounds check for implied do loop index variable before it actually
becomes defined.

gcc/testsuite/ChangeLog:

PR fortran/98490
* gfortran.dg/bounds_check_23.f90: New test.

(cherry picked from commit 5fe0865ab788bdc387b284a3ad57e5a95a767b18)

[Bug fortran/101327] ICE in find_array_element, at fortran/expr.c:1355

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:5595cc9eb709c4aef1c7bbbfc6b106cf6d5bee91

commit r10-10132-g5595cc9eb709c4aef1c7bbbfc6b106cf6d5bee91
Author: Harald Anlauf 
Date:   Tue Sep 7 20:51:49 2021 +0200

Fortran - improve error recovery determining array element from constructor

gcc/fortran/ChangeLog:

PR fortran/101327
* expr.c (find_array_element): When bounds cannot be determined as
constant, return error instead of aborting.

gcc/testsuite/ChangeLog:

PR fortran/101327
* gfortran.dg/pr101327.f90: New test.

(cherry picked from commit 2a1537a19cb2fa85823cfa18ed40baa4b259b4e3)