[Bug fortran/101079] [OPENMP] The value of list-item in linear clause in loop construct is not calculated on each iteration

[xiao.liu--- via Gcc-bugs]

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

--- Comment #3 from xiao@compiler-dev.com  ---
(In reply to Jakub Jelinek from comment #1)
> Under discussions in OpenMP language committee, but the latest proposal is
> that this is invalid, you need to increment the linear variable by
> linear-step in the body of the construct.  If that is voted into 5.2, we
> won't be changing GCC for this which always assumed that is the case.  Not
> incrementing it in the body means that the testcase will behave
> significantly differently with -fno-openmp, and also result in worse
> generated code for many cases that do increment the linear variables.

Please ignore the comment 2, the testcase contained in is also wrong, an
increment should be added as the last statement in the loop body.

[Bug fortran/101079] [OPENMP] The value of list-item in linear clause in loop construct is not calculated on each iteration

[xiao.liu--- via Gcc-bugs]

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

--- Comment #2 from xiao@compiler-dev.com  ---
(In reply to Jakub Jelinek from comment #1)
> Under discussions in OpenMP language committee, but the latest proposal is
> that this is invalid, you need to increment the linear variable by
> linear-step in the body of the construct.  If that is voted into 5.2, we
> won't be changing GCC for this which always assumed that is the case.  Not
> incrementing it in the body means that the testcase will behave
> significantly differently with -fno-openmp, and also result in worse
> generated code for many cases that do increment the linear variables.

Thanks for your reply. Indeed, all the testcases I have came across about
linear clause within loop construct have the increment for linear variable in
loop body, but mostly testcases about linear clause within simd construct
don't.
Could you help to confirm whether linear clause within simd construct is
handled correctly in the following testcase?

program p
  integer, parameter :: M = 1
  integer :: b
  integer :: c(M), i
  b = 10
  !$omp simd linear(b:5)
  do i = 1, M
c(i) = b
  end do
  print *, c(1), c(2), c(3), c(4), c(M)
  print *, "final b:", b
end program

When compile with option -O0, the output is,

  10  10  10  10  10
 final b:  10

when compile with option -O1, -O2, -O3 or -Os, the output is,

  10  15  20  25   50005
 final b:   50005

[Bug sanitizer/101111] xgcc cross-compiler for x86_64-apple-darwin in GCC 11.1 doesn't generate weak symbols, resulting in undefined reference to ___lsan_default_suppressions

[mose at gnu dot org via Gcc-bugs]

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

--- Comment #6 from Mosè Giordano  ---
Created attachment 51038
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51038=edit
Patch to fix the reported issue

Please find attached a patch to fix the reported issue.  I replaced the bashism
+= with simple string interpolation, to make it complaint with strict POSIX
shells.

[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation

[ndesaulniers at google dot com via Gcc-bugs]

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

--- Comment #10 from Nick Desaulniers  ---
Link to kernel patches:
https://lore.kernel.org/lkml/20210618233023.1360185-1-ndesaulni...@google.com/

[Bug libstdc++/100387] ranges::minmax compares moved-out value

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r12-1656-gcc9c94d43dcfa98436152af9c00f011e9dab25f6
Author: Patrick Palka 
Date:   Fri Jun 18 19:33:39 2021 -0400

libstdc++: Reduce ranges::minmax/minmax_element comparison complexity

This rewrites ranges::minmax and ranges::minmax_element so that it
performs at most 3*N/2 many comparisons, as required by the standard.
In passing, this also fixes PR100387 by avoiding a premature std::move
in ranges::minmax and in std::shift_right.

PR libstdc++/100387

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (__minmax_fn::operator()): Rewrite
to limit comparison complexity to 3*N/2.
(__minmax_element_fn::operator()): Likewise.
(shift_right): Avoid premature std::move of __result.
* testsuite/25_algorithms/minmax/constrained.cc (test04, test05):
New tests.
* testsuite/25_algorithms/minmax_element/constrained.cc (test02):
Likewise.

[Bug c/101131] New: ICE with -O2: in noninterposable_alias, at symtab.c:2011

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 101131
   Summary: ICE with -O2: in noninterposable_alias, at
symtab.c:2011
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.M5bbDhYIJL-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210618 (experimental) [master revision
:9f6824b35:688359a27d835bbdab554fdf5eb207f1bd678371] (GCC)

$ cat mutant.c
extern_declared_variable;
global_defined_function() { static_function(); }
__attribute__((ifunc("resolver"))) static_function() {
  if (extern_declared_variable)
return global_defined_function();
}

$ gcc-trunk -O2 mutant.c
mutant.c:1:1: warning: data definition has no type or storage class
1 | extern_declared_variable;
  | ^~~~
mutant.c:1:1: warning: type defaults to ‘int’ in declaration of
‘extern_declared_variable’ [-Wimplicit-int]
mutant.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | global_defined_function() { static_function(); }
  | ^~~
mutant.c: In function ‘global_defined_function’:
mutant.c:2:29: warning: implicit declaration of function ‘static_function’
[-Wimplicit-function-declaration]
2 | global_defined_function() { static_function(); }
  | ^~~
mutant.c: At top level:
mutant.c:3:36: warning: return type defaults to ‘int’ [-Wimplicit-int]
3 | __attribute__((ifunc("resolver"))) static_function() {
  |^~~
mutant.c:3:36: warning: ‘alias’ attribute ignored because function is defined
[-Wattributes]
during IPA pass: whole-program
mutant.c:6:1: internal compiler error: in noninterposable_alias, at
symtab.c:2011
6 | }
  | ^
0x695a35 symtab_node::noninterposable_alias()
/tmp/tmp.M5bbDhYIJL-gcc-builder/gcc/gcc/symtab.c:2011
0x19fd08f function_and_variable_visibility
/tmp/tmp.M5bbDhYIJL-gcc-builder/gcc/gcc/ipa-visibility.c:773
0x19fd6ca whole_program_function_and_variable_visibility
/tmp/tmp.M5bbDhYIJL-gcc-builder/gcc/gcc/ipa-visibility.c:921
0x19fd6ca execute
/tmp/tmp.M5bbDhYIJL-gcc-builder/gcc/gcc/ipa-visibility.c:969
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug sanitizer/101111] xgcc cross-compiler for x86_64-apple-darwin in GCC 11.1 doesn't generate weak symbols, resulting in undefined reference to ___lsan_default_suppressions

[mose at gnu dot org via Gcc-bugs]

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

--- Comment #5 from Mosè Giordano  ---
Ok, I finally found the culprit: `libsanitizer` does already have a way to add
`-Wl,-undefined,dynamic_lookup` to CXXFLAGS, but it uses a bashism:
.
 On Alpine Linux, the system where I'm doing the compilation, sh isn't bash and
appending to a string variable with += isn't valid.  Scavenging the compilation
log I found

/workspace/srcdir/gcc-11.1.0/libsanitizer/configure:
/workspace/srcdir/gcc-11.1.0/libsanitizer/configure.tgt: line 68:
EXTRA_CXXFLAGS+=-Wl,-undefined,dynamic_lookup: not found

If I replace

EXTRA_CXXFLAGS+="-Wl,-undefined,dynamic_lookup"

with

EXTRA_CXXFLAGS="${EXTRA_CXXFLAGS} -Wl,-undefined,dynamic_lookup"

compilation of GCC is finally successful.

[Bug sanitizer/101111] xgcc cross-compiler for x86_64-apple-darwin in GCC 11.1 doesn't generate weak symbols, resulting in undefined reference to ___lsan_default_suppressions

[mose at gnu dot org via Gcc-bugs]

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

--- Comment #4 from Mosè Giordano  ---
You're right, in `x86_64-apple-darwin14/libsanitizer/config.log` I can see that
`build == x86_64-linux-musl` and `host == target == x86_64-apple-darwin`, but
still, in `x86_64-apple-darwin14/libsanitizer` I don't see any reference to
linker flags like `-undefined dynamic_lookup`, `-U `, `-undefined
suppress` or anything like that.  Maybe libsanitizer should use something
similar to `GCC_CHECK_ELF_STYLE_WEAKREF`
()
to actually use any these flags?  The undefined functions mentioned in the
error message use ELF-style weak symbols, but without appropriate flags the
macOS linker will complain.

[Bug c++/101130] Broken backward compatibility after __attribute__-noexcept order change

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
It was changed by the r265787 fix for PR 60503, but maybe that should only have
been for C++11-style attributes not GNU ones.

[Bug tree-optimization/101110] [12 regression] gcc.c-torture/execute/950704-1.c fails after r12-1546

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #2 from Andrew Macleod  ---
I think the patch for PR 101014 resolves this testcase...  Let me know if this
is fixed on trunk now.

[Bug c++/101130] New: Broken backward compatibility after __attribute__-noexcept order change

[alex at webprise dot net via Gcc-bugs]

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

Bug ID: 101130
   Summary: Broken backward compatibility after
__attribute__-noexcept order change
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alex at webprise dot net
  Target Milestone: ---

Testcase:

void f() {
   []() __attribute__((__noinline__)) noexcept {
  void g() noexcept; g(), g();
   }();
}

This started to produce (3!) syntax error messages in g++9.1 whereas g++8.5 and
below accept them and do the expected thing.

The new accepted syntax is:

void f() {
   []() noexcept __attribute__((__noinline__)) {
  void g() noexcept; g(), g();
   }();
}

I do not know whether the change was on purpose, and apparently it has to do
with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60503. As to the backward
compatibility, I do not know whether many users actually depend on it, but at
least my codebase does depend on this nice trick (to force object code
deduplication for slow paths). The problem is that all versions of clang++
still accept the old syntax and so this affects compiler independence (icpc
accepts both since much time ago), so maybe I should open the bug on them;-)
Using the standard C++ attributes [[__gnu__::__noinline__]] is also not an
option since as a warning message states for both g++ and clang++ and the
assembly output evidences, this applies to the application operator type, not
to the operator itself and so does nothing (a solution is proposed for C++2b).

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[amacleod at redhat dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 101014, which changed state.

Bug 101014 Summary: [12 Regression] Big compile time hog with -O3 since 
r12-1268-g9858cd1a6827ee7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #10 from Andrew Macleod  ---
Really fixed this time.

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:870b674f72d4894b94efa61764fd87ecec29ffde

commit r12-1652-g870b674f72d4894b94efa61764fd87ecec29ffde
Author: Andrew MacLeod 
Date:   Fri Jun 18 12:33:18 2021 -0400

Remove poor value computations.

Remove the old "poor value" approach which made callbacks into ranger
from the cache.  Use only the best available value for all propagation.

PR tree-optimization/101014
* gimple-range-cache.cc (ranger_cache::ranger_cache): Remove poor
value list.
(ranger_cache::~ranger_cache): Ditto.
(ranger_cache::enable_new_values): Delete.
(ranger_cache::push_poor_value): Delete.
(ranger_cache::range_of_def): Remove poor value processing.
(ranger_cache::entry_range): Ditto.
(ranger_cache::fill_block_cache): Ditto.
* gimple-range-cache.h (class ranger_cache): Remove poor value
members.
* gimple-range.cc (gimple_ranger::range_of_expr): Remove call.
* gimple-range.h (class gimple_ranger): Adjust.

[Bug libstdc++/95833] Incorrect static_assert in std::reduce overload taking a binary functor

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Fixed for 9.5, 10.4 and 11.2

Thanks for the report.

[Bug libstdc++/95833] Incorrect static_assert in std::reduce overload taking a binary functor

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

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

commit r9-9594-gae17634d5fce496a50477eb0199f1eda8249622f
Author: Jonathan Wakely 
Date:   Fri Jun 18 14:46:58 2021 +0100

libstdc++: Replace incorrect static assertion in std::reduce [PR95833]

The standard does not require the iterator's value type to be
convertible to the result type, it only requires that the result of
dereferencing the iterator can be passed to the binary function.

libstdc++-v3/ChangeLog:

PR libstdc++/95833
* include/std/numeric (reduce(Iter, Iter, T, BinaryOp)): Replace
incorrect static_assert with ones matching the 'Mandates'
conditions in the standard.
* testsuite/26_numerics/reduce/95833.cc: New test.

(cherry picked from commit 0532452dcd17910dfd3d2b0df50dfe3ef1194bf7)

[Bug target/101129] [11/12 Regression] wrong code at -O1 since r11-5839

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

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

--- Comment #2 from Jakub Jelinek  ---
Optimized difference:
--- pr101129.c.244t.optimized.r11-5838  2021-06-18 22:40:20.915971652 +0200
+++ pr101129.c.244t.optimized.r11-5839  2021-06-18 22:40:34.739789553 +0200
@@ -8,6 +8,7 @@ void foo0 (u32 u32_0, U * ret)
   __int128 _1;
   vector(16) unsigned char _2;
   unsigned char _3;
+  vector(16)  _4;
   vector(16) signed char _5;
   __int128 _6;
   __int128 _7;
@@ -31,7 +32,8 @@ void foo0 (u32 u32_0, U * ret)
   _14 = u32_0_13(D) & 4;
   _3 = (unsigned char) _14;
   _2 = {_3, _3, _3, _3, _3, _3, _3, _3, _3, _3, _3, _3, _3, _3, _3, _3};
-  _5 = .VCONDU (_2, { 5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, { -1,
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 }, { 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, 108);
+  _4 = _2 < { 5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
+  _5 = VIEW_CONVERT_EXPR(_4);
   _6 = VIEW_CONVERT_EXPR<__int128>(_5);
   u128_2_15 = _1 * _6;
   _7 = u128_2_15 >> 64;
Assembly difference:
--- pr101129.s.r11-5838 2021-06-18 22:40:20.919971599 +0200
+++ pr101129.s.r11-5839 2021-06-18 22:40:34.743789500 +0200
@@ -14,19 +14,16 @@ foo0:
.localentry foo0,.-foo0
rlwinm 9,3,0,29,29
mtvsrd 32,9
-   vspltb 0,0,7
+   vspltb 1,0,7
addis 9,2,.LC0@toc@ha
addi 9,9,.LC0@toc@l
-   lxvd2x 33,0,9
-   vcmpgtub 0,1,0
-   addi 9,1,-16
-   xxpermdi 32,32,32,2
-   stxvd2x 32,0,9
-   ld 9,-8(1)
-   ld 10,-16(1)
+   lxvd2x 32,0,9
+   vcmpgtub 0,0,1
+   mfvsrd 11,32
+   xxpermdi 0,32,32,3
+   mfvsrd 10,0
+   add 10,11,10
mulld 10,10,3
-   mulhdu 3,3,9
-   add 10,10,3
addis 9,2,.LANCHOR0@toc@ha
lbz 9,.LANCHOR0@toc@l(9)
add 10,10,9

[Bug target/101129] [11/12 Regression] wrong code at -O1 since r11-5839

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12 Regression] wrong|[11/12 Regression] wrong
   |code at -O1 |code at -O1 since r11-5839
   Last reconfirmed||2021-06-18
   Priority|P3  |P2
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jakub Jelinek  ---
Started with r11-5839-g3a6e3ad38a17a03ee0139b49a0946e7b9ded1eb1

[Bug target/100777] MMA builtin usage ICEs when used in a #pragma omp parallel and using -fopenmp

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #6 from Peter Bergner  ---
Fixed everywhere.

[Bug target/99842] MMA test case ICEs using -O3

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #7 from Peter Bergner  ---
Fixed everywhere.

[Bug sanitizer/101111] xgcc cross-compiler for x86_64-apple-darwin in GCC 11.1 doesn't generate weak symbols, resulting in undefined reference to ___lsan_default_suppressions

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Mosè Giordano from comment #2) 
> GCC uses libtool checks to set these flags:
>  h=1d9ae59be6798555b7020a66e0f622ff8bf752cc;
> hb=50bc9185c2821350f0b785d6e23a6e9dcde58466#l8839>.  This is a check on
> `$host_cpu-$host_os`, however I'm compiling a cross-compiler (`build == host
> == x86_64-linux-musl`, `target == x86_64-apple-darwin`, I may have been
> inaccurate before), so shouldn't this check use `$target_cpu-$target_os`
> instead?

No host usage here is correct.  This is a (target) library which means the host
(and target) are set x86_64-apple-darwin and the build is set to
x86_64-linux-musl.

[Bug libstdc++/80196] fenv_t not declared

[gr.audio at gmail dot com via Gcc-bugs]

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

Guillaume  changed:

   What|Removed |Added

 CC||gr.audio at gmail dot com

--- Comment #7 from Guillaume  ---
Same problem while trying to build gcc 11.1.0 on Arch Linux (host and target =
Windows).

Configuration:

configure --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--prefix="$PREFIX" --disable-nls --enable-languages=c,c++,ada
--with-pkgversion=GR20210618 --enable-threads=win32 --disable-win32-registry
--disable-multilib --enable-shared --enable-static --disable-sjlj-exceptions
--with-dwarf2

Adding the '--disable-libstdcxx-pch' option doesn't help in my case, same
errors.

The cross-compiler installed on my Arch Linux for building Windows executables
is x86_64-w64-mingw32-gcc.

'x86_64-w64-mingw32-gcc -v' yields:

Utilisation des specs internes.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/11.1.0/lto-wrapper
Cible : x86_64-w64-mingw32
Configuré? avec: /build/mingw-w64-gcc/src/gcc/configure --prefix=/usr
--libexecdir=/usr/lib --target=x86_64-w64-mingw32
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,lto,c++,ada,objc,obj-c++,fortran --enable-shared
--enable-static --enable-threads=posix --enable-fully-dynamic-string
--enable-libstdcxx-time=yes --enable-libstdcxx-filesystem-ts=yes
--with-system-zlib --enable-cloog-backend=isl --enable-lto --enable-libgomp
--disable-multilib --enable-checking=release --disable-sjlj-exceptions
--with-dwarf2
Modè?le de thread: posix
Algorithmes de compression LTO supporté?s: zlib zstd
gcc version 11.1.0 (GCC)

[Bug sanitizer/101111] xgcc cross-compiler for x86_64-apple-darwin in GCC 11.1 doesn't generate weak symbols, resulting in undefined reference to ___lsan_default_suppressions

[mose at gnu dot org via Gcc-bugs]

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

--- Comment #2 from Mosè Giordano  ---
I've gathered some more information.  In LLVM, libsanitizer uses
-Wl,-U, to allow the macOS linker accept undefined symbols and
mimic ELF weak symbols, see
,
and

for the list of weak symbols in lsan.

GCC uses libtool checks to set these flags:
.
 This is a check on `$host_cpu-$host_os`, however I'm compiling a
cross-compiler (`build == host == x86_64-linux-musl`, `target ==
x86_64-apple-darwin`, I may have been inaccurate before), so shouldn't this
check use `$target_cpu-$target_os` instead?

[Bug c++/80431] Use of "this" pointer in member initializer causes constructor not to be called (or ICE on gcc 7)

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Ever confirmed|0   |1
 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-06-18
  Known to fail|5.4.0, 6.3.0|

--- Comment #1 from Patrick Palka  ---
Confirmed, this never worked.

[Bug c/101125] warn when a construct would become invalid if a function were replaced by a function-like macro

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #2 from Vincent Lefèvre  ---
Even though GCC support fast inline functions, some libraries may still use
function-like macros. In particular, this is still the case with glibc (e.g.
pthread_cleanup_pop).

[Bug target/101129] [11/12 Regression] wrong code at -O1

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.2
  Component|rtl-optimization|target

[Bug rtl-optimization/101129] New: [11/12 Regression] wrong code at -O1

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 101129
   Summary: [11/12 Regression] wrong code at -O1
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: powerpc64le-unknown-linux-gnu

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

Output:
$ powerpc64le-unknown-linux-gnu-gcc -O testcase.c -static
$ qemu-ppc64le -- ./a.out 
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted


$ powerpc64le-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64le/bin/powerpc64le-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-1607-20210617224441-g2786064d91f-checking-yes-rtl-df-extra-powerpc64le/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/12.0.0/lto-wrapper
Target: powerpc64le-unknown-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
--with-sysroot=/usr/powerpc64le-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=powerpc64le-unknown-linux-gnu
--with-ld=/usr/bin/powerpc64le-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc64le-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-1607-20210617224441-g2786064d91f-checking-yes-rtl-df-extra-powerpc64le
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210618 (experimental) (GCC)

[Bug fortran/95501] ICE in gfc_match_pointer_assignment, at fortran/match.c:1422

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-12, and backported to 11- and 10-branch.  Closing.

Thanks for the report!

[Bug fortran/95502] ICE in gfc_check_do_variable, at fortran/parse.c:4446

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-12, and backported to 11- and 10-branch.  Closing.

Thanks for the report!

[Bug fortran/95502] ICE in gfc_check_do_variable, at fortran/parse.c:4446

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

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

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

https://gcc.gnu.org/g:0c084361a5a800ee0920bf29b6673816d2b35e76

commit r10-9946-g0c084361a5a800ee0920bf29b6673816d2b35e76
Author: Harald Anlauf 
Date:   Wed Jun 16 22:04:22 2021 +0200

Fortran - ICE in gfc_check_do_variable, at fortran/parse.c:4446

Avoid NULL pointer dereferences during error recovery.

gcc/fortran/ChangeLog:

PR fortran/95501
PR fortran/95502
* expr.c (gfc_check_pointer_assign): Avoid NULL pointer
dereference.
* match.c (gfc_match_pointer_assignment): Likewise.
* parse.c (gfc_check_do_variable): Avoid comparison with NULL
symtree.

gcc/testsuite/ChangeLog:

PR fortran/95501
PR fortran/95502
* gfortran.dg/pr95502.f90: New test.

(cherry picked from commit cfe0a2ec26867b290eb84af00317e60f8b67455c)

[Bug fortran/95501] ICE in gfc_match_pointer_assignment, at fortran/match.c:1422

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

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

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

https://gcc.gnu.org/g:0c084361a5a800ee0920bf29b6673816d2b35e76

commit r10-9946-g0c084361a5a800ee0920bf29b6673816d2b35e76
Author: Harald Anlauf 
Date:   Wed Jun 16 22:04:22 2021 +0200

Fortran - ICE in gfc_check_do_variable, at fortran/parse.c:4446

Avoid NULL pointer dereferences during error recovery.

gcc/fortran/ChangeLog:

PR fortran/95501
PR fortran/95502
* expr.c (gfc_check_pointer_assign): Avoid NULL pointer
dereference.
* match.c (gfc_match_pointer_assignment): Likewise.
* parse.c (gfc_check_do_variable): Avoid comparison with NULL
symtree.

gcc/testsuite/ChangeLog:

PR fortran/95501
PR fortran/95502
* gfortran.dg/pr95502.f90: New test.

(cherry picked from commit cfe0a2ec26867b290eb84af00317e60f8b67455c)

[Bug fortran/95502] ICE in gfc_check_do_variable, at fortran/parse.c:4446

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

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

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

https://gcc.gnu.org/g:067e45a6f376582b1d3d36cc9b2124b60093b5c2

commit r11-8622-g067e45a6f376582b1d3d36cc9b2124b60093b5c2
Author: Harald Anlauf 
Date:   Wed Jun 16 22:04:22 2021 +0200

Fortran - ICE in gfc_check_do_variable, at fortran/parse.c:4446

Avoid NULL pointer dereferences during error recovery.

gcc/fortran/ChangeLog:

PR fortran/95501
PR fortran/95502
* expr.c (gfc_check_pointer_assign): Avoid NULL pointer
dereference.
* match.c (gfc_match_pointer_assignment): Likewise.
* parse.c (gfc_check_do_variable): Avoid comparison with NULL
symtree.

gcc/testsuite/ChangeLog:

PR fortran/95501
PR fortran/95502
* gfortran.dg/pr95502.f90: New test.

(cherry picked from commit cfe0a2ec26867b290eb84af00317e60f8b67455c)

[Bug fortran/95501] ICE in gfc_match_pointer_assignment, at fortran/match.c:1422

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

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

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

https://gcc.gnu.org/g:067e45a6f376582b1d3d36cc9b2124b60093b5c2

commit r11-8622-g067e45a6f376582b1d3d36cc9b2124b60093b5c2
Author: Harald Anlauf 
Date:   Wed Jun 16 22:04:22 2021 +0200

Fortran - ICE in gfc_check_do_variable, at fortran/parse.c:4446

Avoid NULL pointer dereferences during error recovery.

gcc/fortran/ChangeLog:

PR fortran/95501
PR fortran/95502
* expr.c (gfc_check_pointer_assign): Avoid NULL pointer
dereference.
* match.c (gfc_match_pointer_assignment): Likewise.
* parse.c (gfc_check_do_variable): Avoid comparison with NULL
symtree.

gcc/testsuite/ChangeLog:

PR fortran/95501
PR fortran/95502
* gfortran.dg/pr95502.f90: New test.

(cherry picked from commit cfe0a2ec26867b290eb84af00317e60f8b67455c)

[Bug c++/92752] [9/10/11/12 Regression] Bogus "ignored qualifiers" warning on const-qualified pointer-to-member-function objects

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

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

Patrick Palka  changed:

   What|Removed |Added

  Known to fail||10.1.0, 11.1.0, 8.4.0,
   ||9.3.0
   Last reconfirmed||2021-06-18
  Known to work||7.5.0
Summary|Bogus "ignored qualifiers"  |[9/10/11/12 Regression]
   |warning on const-qualified  |Bogus "ignored qualifiers"
   |pointer-to-member-function  |warning on const-qualified
   |objects |pointer-to-member-function
   ||objects
 Ever confirmed|0   |1
 CC||ppalka at gcc dot gnu.org
   Target Milestone|--- |9.5
 Status|UNCONFIRMED |NEW

--- Comment #1 from Patrick Palka  ---
Confirmed.  We started to emit the bogus warning after r8-901.

[Bug target/101128] DFP support for aarch64 is missing

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #3 from joseph at codesourcery dot com  ---
Bug 91985 was the bug that DFP constants were wrongly accepted by older 
GCC versions on architectures lacking DFP support.

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Resolution|WONTFIX |---

--- Comment #24 from Martin Sebor  ---
Andrew, please don't close bugs that others are working on (i.e., in an
ASSIGNED state with an active Assignee).  Thanks!

[Bug middle-end/100755] Error with fortran object (v11.1.0)

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Likely fixed on mainline with the fix for pr100283.

[Bug libstdc++/95833] Incorrect static_assert in std::reduce overload taking a binary functor

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

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

commit r10-9945-g3a37d5c0bd3451104ddab85f69ec37b50d31fa7f
Author: Jonathan Wakely 
Date:   Fri Jun 18 14:46:58 2021 +0100

libstdc++: Replace incorrect static assertion in std::reduce [PR95833]

The standard does not require the iterator's value type to be
convertible to the result type, it only requires that the result of
dereferencing the iterator can be passed to the binary function.

libstdc++-v3/ChangeLog:

PR libstdc++/95833
* include/std/numeric (reduce(Iter, Iter, T, BinaryOp)): Replace
incorrect static_assert with ones matching the 'Mandates'
conditions in the standard.
* testsuite/26_numerics/reduce/95833.cc: New test.

(cherry picked from commit 0532452dcd17910dfd3d2b0df50dfe3ef1194bf7)

[Bug d/101127] d: Compile-time reflection for supported built-ins

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #1 from Iain Buclaw  ---
There's the language hook LANG_HOOKS_BUILTIN_FUNCTION_EXT_SCOPE, which seems to
do what we want on the surface, but then there's a question over whether this
is to be correct.

---
// static condition is false
static if (__traits(compiles, __builtin_ia32_pmulhrsw128))
pragma(msg, "Yes SSSE3 support");
else
{
short8 truc(short8 a, short8 b) @target("ssse3") // adds SSSE3 built-ins.
{
return __builtin_ia32_pmulhrsw128(a, b);
}
}

// static condition could be true, depending on order of evaluation.
static if (__traits(compiles, __builtin_ia32_pmaddubsw128))
pragma(msg, "Yes SSSE3 support");

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

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

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

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

https://gcc.gnu.org/g:6fc543396345900f460c9fa7121239cb1ebbc3a3

commit r12-1650-g6fc543396345900f460c9fa7121239cb1ebbc3a3
Author: Harald Anlauf 
Date:   Fri Jun 18 19:34:15 2021 +0200

Fortran - fix conversion to result type for the min/max intrinsic

gcc/fortran/ChangeLog:

PR fortran/100283
PR fortran/101123
* trans-intrinsic.c (gfc_conv_intrinsic_minmax): Unconditionally
convert result of min/max to result type.

gcc/testsuite/ChangeLog:

PR fortran/100283
PR fortran/101123
* gfortran.dg/min0_max0_1.f90: New test.
* gfortran.dg/min0_max0_2.f90: New test.

[Bug fortran/100283] [11/12 Regression] Call to MIN0 with integer(8) arguments raises an ICE

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

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

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

https://gcc.gnu.org/g:6fc543396345900f460c9fa7121239cb1ebbc3a3

commit r12-1650-g6fc543396345900f460c9fa7121239cb1ebbc3a3
Author: Harald Anlauf 
Date:   Fri Jun 18 19:34:15 2021 +0200

Fortran - fix conversion to result type for the min/max intrinsic

gcc/fortran/ChangeLog:

PR fortran/100283
PR fortran/101123
* trans-intrinsic.c (gfc_conv_intrinsic_minmax): Unconditionally
convert result of min/max to result type.

gcc/testsuite/ChangeLog:

PR fortran/100283
PR fortran/101123
* gfortran.dg/min0_max0_1.f90: New test.
* gfortran.dg/min0_max0_2.f90: New test.

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> Why don't you do se->expr = convert (type, mvar); unconditionally?  That
> should
> create FIX_TRUNC_EXPR for the FLOAT_TYPE -> INTEGER_TYPE conversion as well,
> but will handle correctly even INTEGER_TYPE -> INTEGER_TYPE conversions etc.?

Will do.  This also regtests cleanly.

Will prepare a testcase also for the related pr100283 which is fixed with
this change and commit shortly.

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|ASSIGNED|RESOLVED

--- Comment #23 from Andrew Pinski  ---
In https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101119#c1 it was decided this
was not to be fixed.

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||zhongyunde at huawei dot com

--- Comment #22 from Andrew Pinski  ---
*** Bug 101119 has been marked as a duplicate of this bug. ***

[Bug c++/101119] Missing the check about modify global variable for __attribute__((const)) function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|WONTFIX |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
Dup of bug 18487.

*** This bug has been marked as a duplicate of bug 18487 ***

[Bug c/101125] warn when a construct would become invalid if a function were replaced by a function-like macro

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
I really doubt this is an useful warning really.  GCC has already had a notion
that inline functions should be as fast as macro functions and type safe ...

[Bug target/96253] decimal floating point missing on ARM

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-06-18
 Ever confirmed|0   |1
   Keywords||ABI
 Status|UNCONFIRMED |NEW

[Bug target/96253] decimal floating point missing on ARM

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||caparson at uwaterloo dot ca

--- Comment #2 from Andrew Pinski  ---
*** Bug 101128 has been marked as a duplicate of this bug. ***

[Bug target/101128] DFP support for aarch64 is missing

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
Dup of bug 96253.

*** This bug has been marked as a duplicate of bug 96253 ***

[Bug target/101128] Decimal floating point fails on ARM with gcc-10/11 but works with gcc-6/7/8/9

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ABI
 Target||aarch64
  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
The patches to support DFP for aarch64 were never accepted upstream ...
And the last I heard ARM was supposed to handle the ABI but never did 

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

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

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

--- Comment #5 from Jakub Jelinek  ---
This is clearly a FE bug:
gfc_conv_intrinsic_minmax does:
  if (TREE_CODE (type) == INTEGER_TYPE)
se->expr = fold_build1_loc (input_location, FIX_TRUNC_EXPR, type, mvar);
  else
se->expr = convert (type, mvar);
and as type (in this kase integer(kind=8)) is INTEGER_TYPE, it creates a
FIX_TRUNC_EXPR.  But that is only valid if mvar has floating point type, which
is not the case here.
Why don't you do se->expr = convert (type, mvar); unconditionally?  That should
create FIX_TRUNC_EXPR for the FLOAT_TYPE -> INTEGER_TYPE conversion as well,
but will handle correctly even INTEGER_TYPE -> INTEGER_TYPE conversions etc.?

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Untested potential fix:

diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 73b0bcc9dea..e578449995a 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -4147,10 +4147,7 @@ gfc_conv_intrinsic_minmax (gfc_se * se, gfc_expr * expr,
enum tree_code op)
build_empty_stmt (input_location));
   gfc_add_expr_to_block (>pre, tmp);
 }
-  if (TREE_CODE (type) == INTEGER_TYPE)
-se->expr = fold_build1_loc (input_location, FIX_TRUNC_EXPR, type, mvar);
-  else
-se->expr = convert (type, mvar);
+  se->expr = convert (type, mvar);
 }

Not sure if there is some cornercase which will get mishandled.

[Bug c/101128] New: Decimal floating point fails on ARM with gcc-10/11 but works with gcc-6/7/8/9

[caparson at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 101128
   Summary: Decimal floating point fails on ARM with gcc-10/11 but
works with gcc-6/7/8/9
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: caparson at uwaterloo dot ca
  Target Milestone: ---

Created attachment 51036
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51036=edit
A short snippet that reproduces the bug on ARM machines

Repro:
compile the following program (also attached) on an ARM machine with gcc-10 or
gcc-11.

  void fred() {
  1.0DL;
  }

You will receive the following error:

  gcc-10 test.c
  test.c: In function 'fred':
  test.c:2:5: error: decimal floating-point not supported for this target
  2 | 1.0DL;
| ^

The two ARM machines we tested this on are Huawei TaiShan 2280 V2 and Raspberry
Pi 4 Model B Rev 1.

Huawei
$ uname -a
Linux algol 5.4.0-74-generic #83-Ubuntu SMP Sat May 8 02:34:05 UTC 2021 aarch64
aarch64 aarch64 GNU/Linux

Raspberrypi
$ uname -a
Linux cfapi1 5.4.0-1036-raspi #39-Ubuntu SMP PREEMPT Wed May 12 17:37:51 UTC
2021 aarch64 aarch64 aarch64 GNU/Linux

If you compile with gcc-6 to gcc-9 this compiles without issue.

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

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

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #3 from Dominique d'Humieres  ---
I think this PR should be closed as invalid.

When using -fdefault_*, it is the user's responsibility to check that the
promotion is compatible with procedure arguments: MAX0 is expecting INTEGER(4)
and is given INTEGER(8).

The code compiles if MAX0 is replaced with the generic function MAX.

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Why on Earth would somebody really want to combine legacy MAX0 with
IMPLICIT INTEGER*4 and -fdefault-integer-8?

Reduced testcase:

  SUBROUTINE TEST
  IMPLICIT INTEGER*4 (I-N)
  MAXMN=MAX0(M,N)
  END

Dump tree:

__attribute__((fn spec (". ")))
void test ()
{
  integer(kind=4) m;
  integer(kind=4) maxmn;
  integer(kind=4) n;

  {
integer(kind=4) M.0;

M.0 = m;
M.0 = MAX_EXPR ;
maxmn = (integer(kind=4)) (integer(kind=8)) M.0;
  }
}

Is the dump tree inaccurate?  It matches my expectation.

Note: the code compiles with MAX0 replaced by (the generic) MAX.

[Bug libstdc++/95833] Incorrect static_assert in std::reduce overload taking a binary functor

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

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

commit r11-8621-gfe918041ce9809755a7e1b2f62071c2b27829610
Author: Jonathan Wakely 
Date:   Fri Jun 18 14:46:58 2021 +0100

libstdc++: Replace incorrect static assertion in std::reduce [PR95833]

The standard does not require the iterator's value type to be
convertible to the result type, it only requires that the result of
dereferencing the iterator can be passed to the binary function.

libstdc++-v3/ChangeLog:

PR libstdc++/95833
* include/std/numeric (reduce(Iter, Iter, T, BinaryOp)): Replace
incorrect static_assert with ones matching the 'Mandates'
conditions in the standard.
* testsuite/26_numerics/reduce/95833.cc: New test.

(cherry picked from commit 0532452dcd17910dfd3d2b0df50dfe3ef1194bf7)

[Bug target/99939] CMSE: -march=armv8.1-m.main+mve does not support CMSE correctly.

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

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

SRINATH PARVATHANENI  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from SRINATH PARVATHANENI  ---
Fixed

[Bug target/100856] Arm: Multilib mapping is missing for CDE arguments.

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

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

SRINATH PARVATHANENI  changed:

   What|Removed |Added

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

--- Comment #4 from SRINATH PARVATHANENI  ---
Fixed.

[Bug target/101016] Arm: vld1q polymorphic variants failing with undefined reference to `__ARM_undef` error.

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

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

SRINATH PARVATHANENI  changed:

   What|Removed |Added

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

--- Comment #4 from SRINATH PARVATHANENI  ---
Fixed

[Bug d/101127] New: d: Compile-time reflection for supported built-ins

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 101127
   Summary: d: Compile-time reflection for supported built-ins
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

With the 11 release, compile-time reflection support was added for vector
types, but this does not extend to built-ins that use them.

e.g:
---

// This prints "Yes" with -mavx because vector(float[8]) also becomes
available.
static if (__traits(compiles, __builtin_ia32_andps256 ))
pragma(msg, "Yes AVX support");
else
pragma(msg, "No AVX support");


// Always prints "Yes", because vector(short[8]) is available from -msse
static if (__traits(compiles, __builtin_ia32_pmulhrsw128))
pragma(msg, "Yes SSSE3 support");
else
pragma(msg, "No SSSE3 support");

[Bug target/100856] Arm: Multilib mapping is missing for CDE arguments.

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by SRINATH PARVATHANENI
:

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

commit r10-9944-ge5384e746639b2d4084a95605f7be1ef45395768
Author: Srinath Parvathaneni 
Date:   Fri Jun 18 13:21:51 2021 +0100

arm: Fix multilib mapping for CDE extensions [PR100856].

On passing +cdecp[0-7] extension to the -march string in command line
options,
multilib linking is failing as mentioned in PR100856. This patch fixes this
issue by
generating a separate canonical string by removing compiler options which
are not
required for multilib linking from march string and assign the new string
to mlibarch
option. This mlibarch string is used for multilib comparison.

gcc/ChangeLog:

2021-06-10  Srinath Parvathaneni  

PR target/100856
* common/config/arm/arm-common.c (arm_canon_arch_option_1): New
function
derived from arm_canon_arch.
(arm_canon_arch_option): Call it.
(arm_canon_arch_multilib_option): New function.
* config/arm/arm-cpus.in (IGNORE_FOR_MULTILIB): New fgroup.
* config/arm/arm.h (arm_canon_arch_multilib_option): New prototype.
(CANON_ARCH_MULTILIB_SPEC_FUNCTION): New macro.
(MULTILIB_ARCH_CANONICAL_SPECS): New macro.
(DRIVER_SELF_SPECS): Add MULTILIB_ARCH_CANONICAL_SPECS.
* config/arm/arm.opt (mlibarch): New option.
* config/arm/t-rmprofile (MULTILIB_MATCHES): For armv8*-m, replace
use
of march on RHS with mlibarch.

gcc/testsuite/ChangeLog:

2021-06-10  Srinath Parvathaneni  

PR target/100856
* gcc.target/arm/acle/pr100856.c: New test.
* gcc.target/arm/multilib.exp: Add tests for cde options.

(cherry picked from commit f58d03b5df25f9eab06b7eacea8da780fc2e0219)

[Bug target/101016] Arm: vld1q polymorphic variants failing with undefined reference to `__ARM_undef` error.

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by SRINATH PARVATHANENI
:

https://gcc.gnu.org/g:9ea29759feb45c4418a2eebb212368f49e3e179d

commit r10-9943-g9ea29759feb45c4418a2eebb212368f49e3e179d
Author: Srinath Parvathaneni 
Date:   Fri Jun 11 18:11:58 2021 +0100

arm: Fix polymorphic variants failing with undefined reference to
`__ARM_undef` error.

This patch fixes the issue mentioned in PR101016, which is mve polymorphic
variants
failing at linking with undefined reference to "__ARM_undef" error.

gcc/ChangeLog:

2021-06-11  Srinath Parvathaneni  

PR target/101016
* config/arm/arm_mve.h (__arm_vld1q): Change __ARM_mve_coerce(p0,
int8_t const *) to __ARM_mve_coerce1(p0, int8_t *) in the argument
for
the polymorphic variants matching code.
(__arm_vld1q_z): Likewise.
(__arm_vld2q): Likewise.
(__arm_vld4q): Likewise.
(__arm_vldrbq_gather_offset): Likewise.
(__arm_vldrbq_gather_offset_z): Likewise.

gcc/testsuite/ChangeLog:

2021-06-11  Srinath Parvathaneni  

PR target/101016
* gcc.target/arm/mve/intrinsics/pr101016.c: New test.

(cherry picked from commit b13f297f01c943aa167f7c6eb94bed40dce0d553)

[Bug target/100856] Arm: Multilib mapping is missing for CDE arguments.

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-11 branch has been updated by SRINATH PARVATHANENI
:

https://gcc.gnu.org/g:85f85b7e62aacc6abae475932cf483a4c80176ce

commit r11-8620-g85f85b7e62aacc6abae475932cf483a4c80176ce
Author: Srinath Parvathaneni 
Date:   Fri Jun 18 13:21:51 2021 +0100

arm: Fix multilib mapping for CDE extensions [PR100856].

On passing +cdecp[0-7] extension to the -march string in command line
options,
multilib linking is failing as mentioned in PR100856. This patch fixes this
issue by
generating a separate canonical string by removing compiler options which
are not
required for multilib linking from march string and assign the new string
to mlibarch
option. This mlibarch string is used for multilib comparison.

gcc/ChangeLog:

2021-06-10  Srinath Parvathaneni  

PR target/100856
* common/config/arm/arm-common.c (arm_canon_arch_option_1): New
function
derived from arm_canon_arch.
(arm_canon_arch_option): Call it.
(arm_canon_arch_multilib_option): New function.
* config/arm/arm-cpus.in (IGNORE_FOR_MULTILIB): New fgroup.
* config/arm/arm.h (arm_canon_arch_multilib_option): New prototype.
(CANON_ARCH_MULTILIB_SPEC_FUNCTION): New macro.
(MULTILIB_ARCH_CANONICAL_SPECS): New macro.
(DRIVER_SELF_SPECS): Add MULTILIB_ARCH_CANONICAL_SPECS.
* config/arm/arm.opt (mlibarch): New option.
* config/arm/t-rmprofile (MULTILIB_MATCHES): For armv8*-m, replace
use
of march on RHS with mlibarch.

gcc/testsuite/ChangeLog:

2021-06-10  Srinath Parvathaneni  

PR target/100856
* gcc.target/arm/acle/pr100856.c: New test.
* gcc.target/arm/multilib.exp: Add tests for cde options.

(cherry picked from commit f58d03b5df25f9eab06b7eacea8da780fc2e0219)

[Bug target/101016] Arm: vld1q polymorphic variants failing with undefined reference to `__ARM_undef` error.

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-11 branch has been updated by SRINATH PARVATHANENI
:

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

commit r11-8619-gd4eafcd3d3b0dade7b61468dc546bcfadf8993ef
Author: Srinath Parvathaneni 
Date:   Fri Jun 11 18:11:58 2021 +0100

arm: Fix polymorphic variants failing with undefined reference to
`__ARM_undef` error.

This patch fixes the issue mentioned in PR101016, which is mve polymorphic
variants
failing at linking with undefined reference to "__ARM_undef" error.

gcc/ChangeLog:

2021-06-11  Srinath Parvathaneni  

PR target/101016
* config/arm/arm_mve.h (__arm_vld1q): Change __ARM_mve_coerce(p0,
int8_t const *) to __ARM_mve_coerce1(p0, int8_t *) in the argument
for
the polymorphic variants matching code.
(__arm_vld1q_z): Likewise.
(__arm_vld2q): Likewise.
(__arm_vld4q): Likewise.
(__arm_vldrbq_gather_offset): Likewise.
(__arm_vldrbq_gather_offset_z): Likewise.

gcc/testsuite/ChangeLog:

2021-06-11  Srinath Parvathaneni  

PR target/101016
* gcc.target/arm/mve/intrinsics/pr101016.c: New test.

(cherry picked from commit b13f297f01c943aa167f7c6eb94bed40dce0d553)

[Bug c++/101126] New: Enabling modules suppresses creation of precompiled headers

[overlord624 at gmail dot com via Gcc-bugs]

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

Bug ID: 101126
   Summary: Enabling modules suppresses creation of precompiled
headers
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: overlord624 at gmail dot com
  Target Milestone: ---

The output of a precompiled header is suppressed if modules are enabled via
-fmodules-ts. This can be reproduced with the following invocation using any
valid input:
g++-11 -x c++-header -std=c++20 -fmodules-ts -o header.hpp.gch header.hpp

As described in the manual, -fmodules-ts implicitly sets -fmodule-header when
the input is a header file which results in the creation of a compiled header
unit in the module cache and causes the output parameter to be silently ignored
as a side effect.

-
$ g++-11 -v
Using built-in specs.
COLLECT_GCC=g++-11
COLLECT_LTO_WRAPPER=/media/extra/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /media/extra/sources/gcc/configure --host=x86_64-pc-linux-gnu
--prefix=/media/extra --disable-multilib --enable-threads --enable-tls
--enable-languages=c,c++ --disable-nls
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.1 20210402 (experimental) (GCC)

[Bug c++/101118] coroutines: unexpected ODR warning for coroutine frame type in LTO builds

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

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

--- Comment #4 from Iain Sandoe  ---
(In reply to Nils Gladitz from comment #3)
> Thanks for looking into this!

just speculation so far ...

> Any idea what the potential implications are?

Not yet.

> I assume I can't just ignore the warning as this will likely break code?

My expectations at present is that the front end actions on a coroutine are
expected to produce functions and a frame type that are TU-local.

At this point, it's not clear whether it is ever valid to merge these using LTO
(and I don't think that was specifically addressed in any of my discussions in
WG21 or with implementers on other compilers).

> When I turn off LTO the diagnostic will go away but the ODR violations are
> still there; could they still break something?

I *think* the "ODR violation" is to do with not giving the frame types unique
names per TU so that there is a [probably invalid] attempt to merge them.

.. but, as noted above, I guess we should consider carefully if the frames can
ever be considered mergeable (which would imply that the actor and destroyer
functions were also).

If they are _never_ validly mergeable, then the ODR violation is not "real" but
the consequence of a naming scheme that is not good enough.  As per my
expectations when implementing that is the case (i.e. it should be OK).

[Bug c++/101118] coroutines: unexpected ODR warning for coroutine frame type in LTO builds

[nilsgladitz at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Nils Gladitz  ---
Thanks for looking into this!

Any idea what the potential implications are?
I assume I can't just ignore the warning as this will likely break code?
When I turn off LTO the diagnostic will go away but the ODR violations are
still there; could they still break something?

[Bug libstdc++/100384] Compiling in c++17 mode breaks compilation of functions named visit()

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.5

--- Comment #11 from Jonathan Wakely  ---
Fixed for 9.5, 10.4 and 11.2

[Bug libstdc++/100630] Unexpected implicit conversion from volatile bool& to std::filesystem::path in gcc <= 10

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Fixed for 9.5, 10.4 and 11.2

[Bug libstdc++/91488] [9/10 Regression] char_traits::length causes "inlining failed in call to always_inline" error with -fgnu-tm -O2 -std=c++17

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #12 from Jonathan Wakely  ---
Fixed for 9.5, 10.4 and 11.2

[Bug libstdc++/99006] make_shared silently works

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |9.5
 Status|NEW |RESOLVED

--- Comment #8 from Jonathan Wakely  ---
Fixed for 9.5, 10.4 and 11.2

[Bug libstdc++/100630] Unexpected implicit conversion from volatile bool& to std::filesystem::path in gcc <= 10

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

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

commit r9-9593-g3c805829c9023da48db6d636221fd79612dff7ea
Author: Jonathan Wakely 
Date:   Mon May 17 11:54:06 2021 +0100

libstdc++: Fix filesystem::path constraints for volatile [PR 100630]

The constraint check for filesystem::path construction uses
decltype(__is_path_src(declval())) which mean it considers
conversion from an rvalue.  When Source is a volatile-qualified type
it cannot use is_path_src(const Unknown&) because a const lvalue
reference can only bind to a non-volatile rvalue.

Since the relevant path members all have a const Source& parameter,
the constraint should be defined in terms of declval(),
not declval(). This avoids the problem of volatile-qualified
rvalues, because we no longer use an rvalue at all.

libstdc++-v3/ChangeLog:

PR libstdc++/100630
* include/bits/fs_path.h (__is_constructible_from): Test
construction from a const lvalue, not an rvalue.
* include/experimental/bits/fs_path.h (__is_constructible_from):
Likewise.
* testsuite/27_io/filesystem/path/construct/100630.cc: New test.
* testsuite/experimental/filesystem/path/construct/100630.cc:
New test.

(cherry picked from commit 4cd69a5a0dd31bc6fdef1bbabc8d6d1416014ea1)

[Bug libstdc++/100384] Compiling in c++17 mode breaks compilation of functions named visit()

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:91d29ed563bd7e787921f997ea2f80cd87ee59b2

commit r9-9592-g91d29ed563bd7e787921f997ea2f80cd87ee59b2
Author: Jonathan Wakely 
Date:   Tue May 4 12:16:46 2021 +0100

libstdc++: Do not use deduced return type for std::visit [PR 100384]

This avoids errors outside the immediate context when std::visit is an
overload candidate because of ADL, but not actually viable.

The solution is to give std::visit a non-deduced return type. New
helpers are introduced for that.

libstdc++-v3/ChangeLog:

PR libstdc++/100384
* include/std/variant (__get_t): New alias template yielding the
return type of std::get on a variant.
(__visit_result_t): New alias template yielding the result of
std::visit.
(__do_visit): Use __get_t.
(visit): Use __visit_result_t for return type.
* testsuite/20_util/variant/100384.cc: New test.

(cherry picked from commit af5b2b911dd80ae9cc87404b7e7ab807cf6655d4)

[Bug libstdc++/99006] make_shared silently works

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:79fa567e234585dc6a71f9bd069101c993513f3e

commit r9-9591-g79fa567e234585dc6a71f9bd069101c993513f3e
Author: Jonathan Wakely 
Date:   Thu Apr 22 15:46:51 2021 +0100

libstdc++: Reject std::make_shared [PR 99006]

Prior to C++20 it should be ill-formed to use std::make_shared with an
array type (and we don't support the C++20 feature to make it valid yet
anyway).

libstdc++-v3/ChangeLog:

PR libstdc++/99006
* include/bits/shared_ptr.h (allocate_shared): Assert that _Tp
is not an array type.
* include/bits/shared_ptr_base.h (__allocate_shared): Likewise.
* testsuite/20_util/shared_ptr/creation/99006.cc: New test.

(cherry picked from commit 55650236cd97d81f42f9fdb4f6bcb12babafe51f)

[Bug libstdc++/91488] [9/10 Regression] char_traits::length causes "inlining failed in call to always_inline" error with -fgnu-tm -O2 -std=c++17

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

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

commit r9-9590-gcc44169fc7bc7552eb85f143f4fee9c8bcdd5e49
Author: Jonathan Wakely 
Date:   Thu Jun 17 14:11:22 2021 +0100

libstdc++: Simplify constexpr checks in std::char_traits [PR 91488]

This removes the 'static' keyword from the helper functions added by
r8-1294 to detect whether the char_traits member functions can be
evaluated at compile time. This prevents the "inlining failed" error
reported in the PR.

The new testcase from the PR is added to the libitm testsuite, because
that's where we can be sure it's OK to use the -fgnu-tm option.

Signed-off-by: Jonathan Wakely 

PR libstdc++/91488

libstdc++-v3/ChangeLog:

* include/bits/char_traits.h (__constant_string_p)
(__constant_array_p): Give external linkage.

libitm/ChangeLog:

* testsuite/libitm.c++/libstdc++-pr91488.C: New test.

(cherry picked from commit b376b1ef38971b84975ad1540bf5d2ae0b924e76)

[Bug c/101125] New: warn when a construct would become invalid if a function were replaced by a function-like macro

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

Bug ID: 101125
   Summary: warn when a construct would become invalid if a
function were replaced by a function-like macro
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

In the standard C library and some other libraries (like GNU MPFR), functions
may be replaced by function-like macros with the same behavior. So, in order to
detect potential portability issues, GCC should provide a warning to check
whether a construct used with a function call would become invalid if the
function were replaced by a macro.

Such a difference can at least come from the use of the comma in some
expressions. Example:

struct s { int a, b; };
void f (int);
#define F(X) f(X)
void g (void)
{
  f ((struct s){0,1}.a);
  F ((struct s){0,1}.a);
}

The call to f is valid, but the use of the macro yields an error because the
preprocessor assumes that there are 2 arguments in the call: "(struct s){0" and
"1}.a". Here, one should use additional parentheses:

  F (((struct s){0,1}.a));

AFAIK, the library (which provides the function and the macro in a header file)
cannot do anything to avoid such an error; only the user can avoid it, but he
may not be aware of the issue as long as only a function is provided. Hence the
usefulness of the proposed warning.

[Bug libstdc++/95833] Incorrect static_assert in std::reduce overload taking a binary functor

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:0532452dcd17910dfd3d2b0df50dfe3ef1194bf7

commit r12-1645-g0532452dcd17910dfd3d2b0df50dfe3ef1194bf7
Author: Jonathan Wakely 
Date:   Fri Jun 18 14:46:58 2021 +0100

libstdc++: Replace incorrect static assertion in std::reduce [PR95833]

The standard does not require the iterator's value type to be
convertible to the result type, it only requires that the result of
dereferencing the iterator can be passed to the binary function.

libstdc++-v3/ChangeLog:

PR libstdc++/95833
* include/std/numeric (reduce(Iter, Iter, T, BinaryOp)): Replace
incorrect static_assert with ones matching the 'Mandates'
conditions in the standard.
* testsuite/26_numerics/reduce/95833.cc: New test.

[Bug libstdc++/95833] Incorrect static_assert in std::reduce overload taking a binary functor

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |9.5
   Last reconfirmed||2021-06-18
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug libstdc++/101124] New: [12 Regression] pair(0, 0) was intended to be deprecated, but is rejected now

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

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

Bug ID: 101124
   Summary: [12 Regression] pair(0, 0) was intended to be
deprecated, but is rejected now
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

r12-220-gd96db15967e78d7cecea3b1cf3169ceb924678ac intended to deprecate the
non-standard constructors allowing this:

#include 
std::pair p(0, 0);

However, as reported in PR 100375 the hack doesn't work, and it triggers a
warning (which is an error with -Wpedantic):

pair.C:2:29: warning: ISO C++ says that these are ambiguous, even though the
worst conversion for the first is better than the worst conversion for the
second:
2 | std::pair p(0, 0);
  | ^
In file included from /home/jwakely/gcc/12/include/c++/12.0.0/utility:70,
 from pair.C:1:
/home/jwakely/gcc/12/include/c++/12.0.0/bits/stl_pair.h:426:17: note: candidate
1: 'constexpr std::pair<_T1, _T2>::pair(const _T1&, const _T2&) [with _U1 =
long int*; _U2 = int; typename std::enable_if<(std::_PCC::_ConstructiblePair<_U1, _U2>() && std::_PCC::_ImplicitlyConvertiblePair<_U1, _U2>()), bool>::type  = true;
_T1 = long int*; _T2 = int]'
  426 |   constexpr pair(const _T1& __a, const _T2& __b)
  | ^~~~
/home/jwakely/gcc/12/include/c++/12.0.0/bits/stl_pair.h:511:18: note: candidate
2: 'constexpr std::pair<_T1, _T2>::pair(std::pair<_T1,
_T2>::__null_ptr_constant, _U2&&) [with _U2 = int; typename std::enable_if<((!
std::__or_, std::is_same<_U2, _T2&> >::value) &&
std::_PCC::_DeprConsPair()),
bool>::type  = true; _T1 = long int*; _T2 = int]'
  511 |constexpr pair(__null_ptr_constant, _U2&& __y)
  |  ^~~~


Maybe this is OK, because it's a non-standard feature and so rejecting it with
-Wpedantic might be OK. But my intention was to accept it with a deprecation
warning for GCC 12, and only make it ill-formed for GCC 13.

I need to see if it's possible to make it work as intended, and if not then
just remove the hack and make it ill-formed for GCC 12.

[Bug tree-optimization/101112] [12 regression] ICE compiling gcc.dg/pr86179.c after r12-1551

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #6 from Richard Biener  ---
*** Bug 101122 has been marked as a duplicate of this bug. ***

[Bug c/101122] ice in vect_slp_analyze_node_operations

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Richard Biener  ---
dup

*** This bug has been marked as a duplicate of bug 101112 ***

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2021-06-18
 CC||anlauf at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords|needs-bisection |

--- Comment #1 from Jakub Jelinek  ---
Started with r11-2746-g3c04bd60e56da399a441f73ebb687b5039b9cf3f

[Bug tree-optimization/101121] [12 Regression] 416.gamess grd2b.f does not finish building

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

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

--- Comment #1 from Richard Biener  ---
Created attachment 51035
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51035=edit
reduced testcase

Reduced testcase - it must get still smaller but it only very slowly reduces
now.

[Bug c/101122] ice in vect_slp_analyze_node_operations

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #1 from seurer at gcc dot gnu.org ---
This is also failing on powerpc64.  I believe this is the commit that broke
things:

g:3dfa4fe9f1a089b2b3906c83e22a1b39c49d937c, r12-1551 

commit 3dfa4fe9f1a089b2b3906c83e22a1b39c49d937c
Author: Richard Biener 
Date:   Tue Jun 8 15:10:45 2021 +0200

Vectorization of BB reductions



Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr86179.c   
-fdiagnostics-plain-output   -O3 -S -o pr86179.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr86179.c
-fdiagnostics-plain-output -O3 -S -o pr86179.s
during GIMPLE pass: vect
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr86179.c: In function 'c':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/pr86179.c:7:6: internal
compiler error: in vect_slp_analyze_node_operations, at tree-vect-slp.c:4541
0x10f66307 vect_slp_analyze_node_operations
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4539
0x10f65993 vect_slp_analyze_node_operations
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4482
0x10f65993 vect_slp_analyze_node_operations
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4482
0x10f65993 vect_slp_analyze_node_operations
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4482
0x10f65993 vect_slp_analyze_node_operations
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4482
0x10f68667 vect_slp_analyze_operations(vec_info*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.c:4737
0x10f381fb vect_analyze_loop_2
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.c:2396
0x10f3a5c7 vect_analyze_loop(loop*, vec_info_shared*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.c:2986
0x10f7c25f try_vectorize_loop_1
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.c:1004
0x10f7d14f vectorize_loops()
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.c:1238
0x10dbde47 execute
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-loop.c:414

[Bug c/100618] Add a -fno-semantic-interposition variant which allows variable interposition

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |WORKSFORME

[Bug fortran/101079] [OPENMP] The value of list-item in linear clause in loop construct is not calculated on each iteration

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Under discussions in OpenMP language committee, but the latest proposal is that
this is invalid, you need to increment the linear variable by linear-step in
the body of the construct.  If that is voted into 5.2, we won't be changing GCC
for this which always assumed that is the case.  Not incrementing it in the
body means that the testcase will behave significantly differently with
-fno-openmp, and also result in worse generated code for many cases that do
increment the linear variables.

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.2
  Known to work||10.3.1
   Priority|P3  |P4
   Keywords||ice-on-valid-code,
   ||needs-bisection, wrong-code

[Bug fortran/101123] New: [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

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

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

Bug ID: 101123
   Summary: [11/12 Regression] Invalid code for MAX0 with
-fdefault-integer-8
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

> cat TESTN.f 
  IMPLICIT DOUBLE PRECISION (A-H,O-R,T-Z), INTEGER*4 (I-N)
  COMMON KN(100)
  KN(3)=10
  KN(4)=20
  CALL TEST
C
  STOP  
  END
C  _
C
  SUBROUTINE TEST
  IMPLICIT DOUBLE PRECISION (A-H,O-R,T-Z), INTEGER*4 (I-N)
C
  COMMON KN(100)
C
  EQUIVALENCE (KN( 3),M ), (KN( 4),N )
  MAXMN=MAX0(M,N)
  RETURN
  END

> ~/install/gcc-11/usr/local/bin/gfortran TESTN.f -c -fdefault-integer-8  
> -fchecking
TESTN.f:11:21:

   11 |   SUBROUTINE TEST
  | ^
Error: invalid types in conversion to integer
integer(kind=8)
integer(kind=4)
_2 = (integer(kind=8)) M.0;
TESTN.f:11: confused by earlier errors, bailing out

[Bug c/101122] New: ice in vect_slp_analyze_node_operations

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 101122
   Summary: ice in vect_slp_analyze_node_operations
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

In the gcc testsuite, file gcc.dg/pr86179.c, with flag -O3
on raspberry pi 3, does this:

$ /home/pi/gcc/results/bin/gcc -c -O3 gcc.dg/pr86179.c
during GIMPLE pass: vect
gcc.dg/pr86179.c: In function 'c':
gcc.dg/pr86179.c:7:6: internal compiler error: in
vect_slp_analyze_node_operations, at tree-vect-slp.c:4539
7 | void c(int32_t *d, char *g)
  |  ^
0xd4f447 vect_slp_analyze_node_operations
../../trunk/gcc/tree-vect-slp.c:4539

This seemed fine three days ago, with git hash 4986946f3b761dd4,
but now seems broken with git hash a4fc63e0c3c6c7b8.

There is something to be said for making sure that all the C/C++/Fortran files
in the gcc test suite don't ice with flag -O3, or flag -O3 -march=native,
independent of the usual -O setting for that test.

[Bug libstdc++/100384] Compiling in c++17 mode breaks compilation of functions named visit()

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

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

commit r10-9937-g8ad4d9b46944db1be6f1b216b5b8e74bd9f66937
Author: Jonathan Wakely 
Date:   Tue May 4 12:16:46 2021 +0100

libstdc++: Do not use deduced return type for std::visit [PR 100384]

This avoids errors outside the immediate context when std::visit is an
overload candidate because of ADL, but not actually viable.

The solution is to give std::visit a non-deduced return type. New
helpers are introduced for that, and existing ones refactored slightly.

libstdc++-v3/ChangeLog:

PR libstdc++/100384
* include/std/variant (__get_t): New alias template yielding the
return type of std::get on a variant.
(__visit_result_t): New alias template yielding the result of
std::visit.
(__same_types): Move into namespace __detail::__variant.
(__check_visitor_results): Likewise. Use __invoke_result_t and
__get_t.
(__check_visitor_result): Remove.
(visit): Use __visit_result_t for return type.
* testsuite/20_util/variant/100384.cc: New test.

(cherry picked from commit af5b2b911dd80ae9cc87404b7e7ab807cf6655d4)

[Bug libstdc++/99006] make_shared silently works

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:36d6e7fe997aa85dc64b13ce4bb3c2e51e13cd36

commit r10-9936-g36d6e7fe997aa85dc64b13ce4bb3c2e51e13cd36
Author: Jonathan Wakely 
Date:   Thu Apr 22 15:46:51 2021 +0100

libstdc++: Reject std::make_shared [PR 99006]

Prior to C++20 it should be ill-formed to use std::make_shared with an
array type (and we don't support the C++20 feature to make it valid yet
anyway).

libstdc++-v3/ChangeLog:

PR libstdc++/99006
* include/bits/shared_ptr.h (allocate_shared): Assert that _Tp
is not an array type.
* include/bits/shared_ptr_base.h (__allocate_shared): Likewise.
* testsuite/20_util/shared_ptr/creation/99006.cc: New test.

(cherry picked from commit 55650236cd97d81f42f9fdb4f6bcb12babafe51f)

[Bug c++/101119] Missing the check about modify global variable for __attribute__((const)) function

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Richard Biener  ---
That's on purpose for the case you know what you are doing (TM).

[Bug target/99939] CMSE: -march=armv8.1-m.main+mve does not support CMSE correctly.

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by SRINATH PARVATHANENI
:

https://gcc.gnu.org/g:0fd8e3ac9db8aed59db610b29d83a49b89a638c1

commit r10-9935-g0fd8e3ac9db8aed59db610b29d83a49b89a638c1
Author: Srinath Parvathaneni 
Date:   Fri Jun 11 15:56:37 2021 +0100

arm: Fix the mve multilib for the broken cmse support (pr99939).

The current CMSE support in the multilib build for
"-march=armv8.1-m.main+mve -mfloat-abi=hard -mfpu=auto" is broken
as specified in PR99939 and this patch fixes the issue.

gcc/testsuite/ChangeLog:

2021-06-11  Srinath Parvathaneni  

PR target/99939
* gcc.target/arm/cmse/cmse-18.c: Add separate scan-assembler
directives check for target is v8.1-m.main+mve or not before
comparing the assembly output.
* gcc.target/arm/cmse/cmse-20.c: New test.

libgcc/ChangeLog:

2021-06-11  Srinath Parvathaneni  

PR target/99939
* config/arm/cmse_nonsecure_call.S: Add __ARM_FEATURE_MVE
macro.
* config/arm/t-arm: To link cmse.o and cmse_nonsecure_call.o
on passing -mcmse option.

(cherry picked from commit c5ed0148347beea1bd34795de146a2454c36)

[Bug target/99939] CMSE: -march=armv8.1-m.main+mve does not support CMSE correctly.

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-11 branch has been updated by SRINATH PARVATHANENI
:

https://gcc.gnu.org/g:94d5c3a781ccfb70d5b0c2401be8a5bb7af396bb

commit r11-8618-g94d5c3a781ccfb70d5b0c2401be8a5bb7af396bb
Author: Srinath Parvathaneni 
Date:   Fri Jun 11 15:56:37 2021 +0100

arm: Fix the mve multilib for the broken cmse support (pr99939).

The current CMSE support in the multilib build for
"-march=armv8.1-m.main+mve -mfloat-abi=hard -mfpu=auto" is broken
as specified in PR99939 and this patch fixes the issue.

gcc/testsuite/ChangeLog:

2021-06-11  Srinath Parvathaneni  

PR target/99939
* gcc.target/arm/cmse/cmse-18.c: Add separate scan-assembler
directives check for target is v8.1-m.main+mve or not before
comparing the assembly output.
* gcc.target/arm/cmse/cmse-20.c: New test.

libgcc/ChangeLog:

2021-06-11  Srinath Parvathaneni  

PR target/99939
* config/arm/cmse_nonsecure_call.S: Add __ARM_FEATURE_MVE
macro.
* config/arm/t-arm: To link cmse.o and cmse_nonsecure_call.o
on passing -mcmse option.

(cherry picked from commit c5ed0148347beea1bd34795de146a2454c36)

[Bug target/100856] Arm: Multilib mapping is missing for CDE arguments.

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by SRINATH PARVATHANENI
:

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

commit r12-1644-gf58d03b5df25f9eab06b7eacea8da780fc2e0219
Author: Srinath Parvathaneni 
Date:   Fri Jun 18 13:21:51 2021 +0100

arm: Fix multilib mapping for CDE extensions [PR100856].

On passing +cdecp[0-7] extension to the -march string in command line
options,
multilib linking is failing as mentioned in PR100856. This patch fixes this
issue by
generating a separate canonical string by removing compiler options which
are not
required for multilib linking from march string and assign the new string
to mlibarch
option. This mlibarch string is used for multilib comparison.

gcc/ChangeLog:

2021-06-10  Srinath Parvathaneni  

PR target/100856
* common/config/arm/arm-common.c (arm_canon_arch_option_1): New
function
derived from arm_canon_arch.
(arm_canon_arch_option): Call it.
(arm_canon_arch_multilib_option): New function.
* config/arm/arm-cpus.in (IGNORE_FOR_MULTILIB): New fgroup.
* config/arm/arm.h (arm_canon_arch_multilib_option): New prototype.
(CANON_ARCH_MULTILIB_SPEC_FUNCTION): New macro.
(MULTILIB_ARCH_CANONICAL_SPECS): New macro.
(DRIVER_SELF_SPECS): Add MULTILIB_ARCH_CANONICAL_SPECS.
* config/arm/arm.opt (mlibarch): New option.
* config/arm/t-rmprofile (MULTILIB_MATCHES): For armv8*-m, replace
use
of march on RHS with mlibarch.

gcc/testsuite/ChangeLog:

2021-06-10  Srinath Parvathaneni  

PR target/100856
* gcc.target/arm/acle/pr100856.c: New test.
* gcc.target/arm/multilib.exp: Add tests for cde options.

[Bug tree-optimization/101120] vn_reference_maybe_forwprop_address can take much compile-time

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

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

--- Comment #2 from Richard Biener  ---
Created attachment 51034
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51034=edit
patch

That fixes the attached but we also have loads of dead loads around which
exposes
the IV opts issue at -Ofast where IVOPTs analyzes all the dead loads
with zero-use LHS.  While we have

  PUSH_INSERT_PASSES_WITHIN (pass_vectorize)
  NEXT_PASS (pass_dce);
  POP_INSERT_PASSES ()

there's no such attempt after SLP passes.

But pruning the DR chain after SLP permute is possible as another hack.

[Bug libstdc++/91488] [9/10 Regression] char_traits::length causes "inlining failed in call to always_inline" error with -fgnu-tm -O2 -std=c++17

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

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

commit r10-9932-gb7cf6b97fc3f6c02a5d0114fed14f40b08ab3ad8
Author: Jonathan Wakely 
Date:   Thu Jun 17 14:11:22 2021 +0100

libstdc++: Simplify constexpr checks in std::char_traits [PR 91488]

This removes the 'static' keyword from the helper functions added by
r8-1294 to detect whether the char_traits member functions can be
evaluated at compile time. This prevents the "inlining failed" error
reported in the PR.

The new testcase from the PR is added to the libitm testsuite, because
that's where we can be sure it's OK to use the -fgnu-tm option.

As a drive-by fix, the feature test macros for C++20 P0980R1 support are
made to depend on whether __cpp_lib_is_constant_evaluated is defined.

Signed-off-by: Jonathan Wakely 

PR libstdc++/91488

libstdc++-v3/ChangeLog:

* include/bits/basic_string.h (__cpp_lib_constexpr_string): Only
define C++20 value when std::is_constant_evaluated is available.
* include/bits/char_traits.h (__cpp_lib_constexpr_char_traits):
Likewise.
(__constant_string_p, __constant_array_p): Give external
linkage.
* include/std/version (__cpp_lib_constexpr_char_traits)
(__cpp_lib_constexpr_string): Only define C++20 values when
is_constant_evaluated is available.

libitm/ChangeLog:

* testsuite/libitm.c++/libstdc++-pr91488.C: New test.

(cherry picked from commit b376b1ef38971b84975ad1540bf5d2ae0b924e76)

[Bug tree-optimization/101121] [12 Regression] 416.gamess grd2b.f does not finish building

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Keywords||compile-time-hog
   Target Milestone|--- |12.0
 Ever confirmed|0   |1
   Last reconfirmed||2021-06-18

[Bug tree-optimization/101121] New: [12 Regression] 416.gamess grd2b.f does not finish building

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

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

Bug ID: 101121
   Summary: [12 Regression] 416.gamess grd2b.f does not finish
building
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

With -Ofast -march=haswell -std=legacy -fno-aggressive-loop-optimizations this
is somewhere stuck in SLP build not making progress.

[Bug tree-optimization/101112] [12 regression] ICE compiling gcc.dg/pr86179.c after r12-1551

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

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

Richard Biener  changed:

   What|Removed |Added

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

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