[Bug c++/79627] Ice with type of VLA in lambda

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Arseny Solokha from comment #3)
> It is fixed for gcc 10, probably by
> g:00a49cd840f60774b0e9e0109fb10559bc9a9194.

Yes, it's fixed with this commit.

[Bug target/95046] New: Vectorize V2SFmode operations

[ubizjak at gmail dot com]

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

Bug ID: 95046
   Summary: Vectorize V2SFmode operations
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

The compiler should vectorize V2SF operations using XMM registers.

The same principles as applied to integer MMX operations (mmx-with-sse) should
also apply to V2SF mode operations, but to avoid unwanted secondary effects
(e.g. exceptions) extra care should be taken to load values to registers with
parts outside V2SFmode cleared.

Following testcase:

--cut here--
float r[2], a[2], b[2];

void foo (void)
{
  for (int i = 0; i < 2; i++)
r[i] = a[i] + b[i];
}
--cut here--

should vectorize to:

movqa(%rip), %xmm0
movqb(%rip), %xmm1
addps   %xmm1, %xmm0
movlps  %xmm0, r(%rip)

Please note movq insn that assures clearing of top 64bits of 128bit xmm
register.

[Bug target/95046] Vectorize V2SFmode operations

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-05-11
 Target||x86_64
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement

[Bug target/95046] Vectorize V2SFmode operations

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Target Milestone|--- |11.0
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

[Bug bootstrap/95005] zstd.h not found if installed in non-system prefix

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 48503
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48503&action=edit
Patch candidate

Thank you for the bug report.
I'm sending a better patch, can you please test it?

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #25 from Martin Liška  ---
No, there's still the 'ipa_polymorphic_call_context::set_by_invariant' issue
that's waiting for Honza.

[Bug debug/95047] New: Wrong debug information for ternary operator at O0

[massarelli at diag dot uniroma1.it]

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

Bug ID: 95047
   Summary: Wrong debug information for ternary operator at O0
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: massarelli at diag dot uniroma1.it
  Target Milestone: ---

Debug information for ternary operator seems wrong at O0.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/tmp/gcc_build --disable-multilib
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200508 (experimental) (GCC) 

$ lldb -v
  lldb version 11.0.0
  clang revision 23cbea9a04e023d5b79dfee5964fae769340c993
  llvm revision 23cbea9a04e023d5b79dfee5964fae769340c993

$ cat a.c
short a;
short
b( left,  right )
{
  return
((left < 0) || (((int)right) < 0) || (((int)right) >= 32) || (left >
((32767) >> ((int)right ?
0 :
left
;
}
int main ()
{
a = b(4294967286 , 5);
}

$ gcc -O0 -g a.c

$ lldb a.out

* thread #1, name = 'a.out', stop reason = breakpoint 2.1
frame #0: 0x004004c1 unopt`main at a.c:13:9
   10   }
   11   int main ()
   12   {
-> 13   a = b(4294967286 , 5);
   14   }
(lldb) s
Process 78 stopped
* thread #1, name = 'a.out', stop reason = step in
frame #0: 0x0040048c unopt`b(left=-10, right=5) at a.c:7:7
   4{
   5  return
   6((left < 0) || (((int)right) < 0) || (((int)right) >= 32) || (left
> ((32767) >> ((int)right ?
-> 70 :
   8left
   9;
   10   }
(lldb) s
Process 78 stopped
* thread #1, name = 'a.out', stop reason = step in
frame #0: 0x004004bb unopt`b(left=-10, right=5) at a.c:10:1
   70 :
   8left
   9;
-> 10   }
   11   int main ()
   12   {
   13   a = b(4294967286 , 5);
(lldb) s
Process 78 stopped
* thread #1, name = 'a.out', stop reason = step in
frame #0: 0x004004d5 unopt`main at a.c:13:7
   10   }
   11   int main ()
   12   {
-> 13   a = b(4294967286 , 5);
   14   }

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[marxin at gcc dot gnu.org]

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

--- Comment #17 from Martin Liška  ---
All right, I'll prepare a patch for that.

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:10a9bf806cf180915c20f9971d33da8ff2d663c1

commit r11-260-g10a9bf806cf180915c20f9971d33da8ff2d663c1
Author: Martin Liska 
Date:   Mon May 11 09:25:46 2020 +0200

Add caveat about parsing of .gcda and .gcno files.

PR gcov-profile/94928
* gcov-io.h: Add caveat about coverage format parsing and
possible outdated documentation.

[Bug regression/95025] [11 Regression] ICE in execute_sm_exit at gcc/tree-ssa-loop-im.c:2224 since r11-161-g283cb9ea6293e813

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
(In reply to David Binderman from comment #1)
> I see this bug also. Another C test case is available on request.

Please attach it.

[Bug tree-optimization/95045] [11 Regression] wrong code at -O3 on x86_64-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
  Known to work||10.1.0
 CC||marxin at gcc dot gnu.org
Summary|wrong code at -O3 on|[11 Regression] wrong code
   |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu
  Known to fail||11.0
Version|unknown |11.0

[Bug c/95044] [10/11 Regression] -Wreturn-local-addr false alarm since r10-1741-gaac9480da1ffd037

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
Summary|-Wreturn-local-addr false   |[10/11 Regression]
   |alarm in GCC 10.1.0 |-Wreturn-local-addr false
   |(regression)|alarm since
   ||r10-1741-gaac9480da1ffd037
   Last reconfirmed||2020-05-11
  Known to work||9.3.0
 Ever confirmed|0   |1
  Known to fail||10.1.0, 11.0
 Status|UNCONFIRMED |NEW

[Bug analyzer/95043] GCC 10 Analyzer and false positive on 'memcpy(dest, src, count);'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-05-11
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org

[Bug debug/95047] Wrong debug information for ternary operator at O0

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
GCC puts the line information as the line/collumn as the ':' part of the
ternary 
 opertator.

   :
  [t666.c:7:7] if (left_3(D) >= 0)
goto ; [INV]
  else
goto ; [INV]

   :
  [t666.c:6:17] if (right_4(D) >= 0)
goto ; [INV]
  else
goto ; [INV]

   :
  [t666.c:6:39] if (right_4(D) <= 31)
goto ; [INV]
  else
goto ; [INV]

   :
  [t666.c:6:83] _1 = 32767 >> right_4(D);
  [t666.c:6:63] if (left_3(D) <= _1)
goto ; [INV]
  else
goto ; [INV]

   :
  [t666.c:7:7] iftmp.0_5 = (short int) left_3(D);
  [t666.c:7:7] goto ; [INV]

   :
  [t666.c:7:7] iftmp.0_6 = 0;

   :
  # iftmp.0_2 = PHI <[t666.c:7:7] iftmp.0_5(6), [t666.c:7:7] iftmp.0_6(7)>
  [t666.c:7:7] _7 = iftmp.0_2;

[Bug analyzer/95042] ICE in can_merge_p, at analyzer/region-model.cc:2053

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-11

--- Comment #1 from Martin Liška  ---
Started with r10-7502-ga96f1c38a787fbc8.

[Bug c/95040] typo in common.opt: manging

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:850322dff702aa538919daf165d3dff5c8f723ca

commit r11-261-g850322dff702aa538919daf165d3dff5c8f723ca
Author: Martin Liska 
Date:   Mon May 11 09:34:22 2020 +0200

Fix typo in fprofile-prefix-path.

PR c/95040
* common.opt: Fix typo in option description.

[Bug regression/95025] [11 Regression] ICE in execute_sm_exit at gcc/tree-ssa-loop-im.c:2224 since r11-161-g283cb9ea6293e813

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
Created attachment 48504
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48504&action=edit
C source code

[Bug c/95040] typo in common.opt: manging

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Martin Liska
:

https://gcc.gnu.org/g:340c711bc0835346000d7863155fbf82af42828e

commit r10-8129-g340c711bc0835346000d7863155fbf82af42828e
Author: Martin Liska 
Date:   Mon May 11 09:35:16 2020 +0200

Fix typo in fprofile-prefix-path.

Backport from mainline
2020-05-11  Martin Liska  

PR c/95040
* common.opt: Fix typo in option description.

[Bug c/95040] typo in common.opt: manging

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug regression/95025] [11 Regression] ICE in execute_sm_exit at gcc/tree-ssa-loop-im.c:2224 since r11-161-g283cb9ea6293e813

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to David Binderman from comment #3)
> Created attachment 48504 [details]
> C source code

I'm gonna reduce that.

[Bug regression/95025] [11 Regression] ICE in execute_sm_exit at gcc/tree-ssa-loop-im.c:2224 since r11-161-g283cb9ea6293e813

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
$ cat pr95025.c
static int a;
short b;
int *c;
void d() {
  for (;; a -= 1)
for (; b; b += 1) {
  *c ^= 5;
  if (a)
return;
}
}

$ gcc -O2 -c pr95025.c -Werror
during GIMPLE pass: lim
pr95025.c: In function ‘d’:
pr95025.c:4:6: internal compiler error: Segmentation fault
4 | void d() {
  |  ^
0xe36b0f crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:328
0x778fef1f ???
   
/usr/src/debug/glibc-2.31-4.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x72dd2c execute_sm_exit
/home/marxin/Programming/gcc/gcc/tree-ssa-loop-im.c:2224
0xf71d25 hoist_memory_references
/home/marxin/Programming/gcc/gcc/tree-ssa-loop-im.c:2562
0xf71d25 store_motion_loop
/home/marxin/Programming/gcc/gcc/tree-ssa-loop-im.c:2824
0xf70a21 store_motion_loop
/home/marxin/Programming/gcc/gcc/tree-ssa-loop-im.c:2830
0xf72cca store_motion
/home/marxin/Programming/gcc/gcc/tree-ssa-loop-im.c:2845
0xf72cca tree_ssa_lim
/home/marxin/Programming/gcc/gcc/tree-ssa-loop-im.c:3065
0xf72cca execute
/home/marxin/Programming/gcc/gcc/tree-ssa-loop-im.c:3115
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug debug/95047] Wrong debug information for ternary operator at O0

[massarelli at diag dot uniroma1.it]

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

--- Comment #2 from Luca Massarelli  ---
Ok, so it seems that there is an inconsistency with -Og:

$ gcc -Og -g -o opt a.c

$ lldb opt
* thread #1, name = 'opt', stop reason = breakpoint 1.1
frame #0: 0x004004bb opt`main at a.c:13:9
   10   }
   11   int main ()
   12   {
-> 13   a = b(4294967286 , 5);
   14   }
(lldb) s
Process 101 stopped
* thread #1, name = 'opt', stop reason = step in
frame #0: 0x00400482 opt`b(left=-10, right=5) at a.c:6:12
   3b( left,  right )
   4{
   5  return
-> 6((left < 0) || (((int)right) < 0) || (((int)right) >= 32) || (left
> ((32767) >> ((int)right ?
   70 :
   8left
   9;
(lldb) s
Process 101 stopped
* thread #1, name = 'opt', stop reason = step in
frame #0: 0x00400490 opt`b(left=-10, right=5) at a.c:7:7
   4{
   5  return
   6((left < 0) || (((int)right) < 0) || (((int)right) >= 32) || (left
> ((32767) >> ((int)right ?
-> 70 :
   8left
   9;
   10   }
(lldb) s
Process 101 stopped
* thread #1, name = 'opt', stop reason = step in
frame #0: 0x004004cf opt`main at a.c:13:7
   10   }
   11   int main ()
   12   {
-> 13   a = b(4294967286 , 5);
   14   }

[Bug regression/95025] [11 Regression] ICE in execute_sm_exit at gcc/tree-ssa-loop-im.c:2224 since r11-161-g283cb9ea6293e813

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman  ---
My creduced version is similar:

static a;
short b;
*c;
d() {
  for (;; a--)
for (; b; b++) {
  *c = 5;
  if (a)
return;
}
}

Flag -O2 on x86_64 required. The code seems to compile ok
on the raspberry pi.

[Bug analyzer/95031] GCC 10 Analyzer and fatal error: Terminated signal terminated program cc1plus

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-11
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[guojiufu at gcc dot gnu.org]

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

--- Comment #10 from Jiu Fu Guo  ---
For power, the patch enables -funroll-loops (with small loops unroller in RTL)
and which also enabled the 'cunroll'(complete unroller) on tree. 

For this loop(the inner loop), 'cunroll' figures out that the loop is executed
at most 13 times. Then the complete unroller could handle this loop.

[Bug analyzer/95031] GCC 10 Analyzer and fatal error: Terminated signal terminated program cc1plus

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
It finished for me with ~16GB memory eaten in:
user3m59.520s

[Bug libstdc++/95048] New: wstring-constructor of std::filesystem::path throws for non-ASCII characters

[kontakt at neonfoto dot de]

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

Bug ID: 95048
   Summary: wstring-constructor of std::filesystem::path throws
for non-ASCII characters
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kontakt at neonfoto dot de
  Target Milestone: ---

When trying to port our Windows application to Linux, I encountered a problem
constructing an instance of std::filesystem::path with a wide-character literal
containing a non-ASCII wchar:

#include 

int main()
{
std::filesystem::path p = L"ä";
}

This builds fine with g++-10 -Wall -Wextra -pedantic -std=c++17 minimal.cpp on
my Ubuntu 18.04 in WSL (using g++ from this ppa:
https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test) but throws an
exception on execution: 

terminate called after throwing an instance of
'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: Cannot convert character sequence: Invalid or
incomplete multibyte or wide character

Reading the C++ standard, I believe this should not happen and libstdc++ should
be able to convert the wchar literal to a path. Using clang with libc++ instead
of libstdc++ performs a conversion as I expected. Trying different versions of
g++ in the Compiler Explorer (https://godbolt.org/z/KQD1I6) shows that this
also used to work with g++9.1 and stopped working in g++9.2.

The problem was already described by someone else in this StackOverflow post:
https://stackoverflow.com/questions/58521857/cross-platform-way-to-handle-stdstring-stdwstring-with-stdfilesystempath

[Bug tree-optimization/95045] [11 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
OK, this one is an interesting one (might be also latent before the rewrite). 
I'll deal with it separately.  The issue is around the inner loop having
multiple exits, one being also the exit from the outer loop and edge
inserts on that edge getting mis-ordered (we commit them only after processing
all inserts).

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #19 from Martin Liška  ---
Looking at the source file paths for tramp3d, there are quite some system
headers:

gcov tramp3d-v4.ii 2>/dev/null | sort | grep find_source | uniq -c | sort -n
  2 find_source: /usr/include/c++/6/iostream
  3 find_source: /usr/include/c++/6/bits/char_traits.h
  3 find_source: /usr/include/c++/6/ext/type_traits.h
  3 find_source: /usr/include/c++/6/iomanip
  5 find_source: /usr/include/c++/6/new
  6 find_source: /usr/include/c++/6/cmath
  6 find_source: /usr/include/c++/6/limits
 15 find_source: /usr/include/c++/6/bits/stl_function.h
 15 find_source: /usr/include/c++/6/bits/stl_iterator_base_types.h
 20 find_source: /usr/include/c++/6/bits/allocated_ptr.h
 22 find_source: /usr/include/c++/6/bits/basic_string.tcc
 22 find_source: /usr/include/c++/6/bits/predefined_ops.h
 32 find_source: /usr/include/c++/6/bits/basic_string.h
 32 find_source: /usr/include/c++/6/bits/list.tcc
 48 find_source: /usr/include/c++/6/ext/aligned_buffer.h
 53 find_source: /usr/include/c++/6/bits/stl_map.h
 55 find_source: /usr/include/c++/6/bits/stl_pair.h
 60 find_source: /usr/include/c++/6/ext/alloc_traits.h
 68 find_source: /usr/include/c++/6/bits/stl_iterator_base_funcs.h
 76 find_source: /usr/include/c++/6/bits/stl_heap.h
 78 find_source: /usr/include/c++/6/bits/cpp_type_traits.h
130 find_source: /usr/include/c++/6/bits/stl_algo.h
198 find_source: /usr/include/c++/6/bits/allocator.h
205 find_source: /usr/include/c++/6/bits/stl_list.h
253 find_source: /usr/include/c++/6/bits/move.h
269 find_source: /usr/include/c++/6/bits/stl_bvector.h
443 find_source: /usr/include/c++/6/bits/alloc_traits.h
445 find_source: /usr/include/c++/6/bits/stl_construct.h
582 find_source: /usr/include/c++/6/bits/stl_tree.h
604 find_source: /usr/include/c++/6/ext/new_allocator.h
779 find_source: /usr/include/c++/6/bits/stl_algobase.h
909 find_source: /usr/include/c++/6/bits/stl_iterator.h
992 find_source: /usr/include/c++/6/bits/vector.tcc
   1034 find_source: /usr/include/c++/6/bits/stl_uninitialized.h
   2145 find_source: /usr/include/c++/6/bits/stl_vector.h
  59079 find_source: tramp3d-v4.cpp

I bet one doesn't want to prefix all the system files with a prefix. That said,
I am not planning to add the option for prefixes.
Please open a separate bug with a feature request if you really need it. It
seems to me that merging the 3 components is an easy task (compared to parsing
of .gcda/.gcno files).

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[guojiufu at gcc dot gnu.org]

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

--- Comment #11 from Jiu Fu Guo  ---
In general, 'cunroll' could help performance visibly on some workload, like
SPEC. 
In this case, it may be in question if the performance is improved.

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[guojiufu at gcc dot gnu.org]

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

--- Comment #12 from Jiu Fu Guo  ---
> executed at most 13 times. Then the complete unroller could handle this loop.

Correction: 13+1 times

[Bug debug/95047] Wrong debug information for ternary operator at O0

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
That is because when GCC does for -Og:
  [t666.c:6:12] _1 = left_6(D) >= 0;
  [t666.c:6:34] _2 = right_7(D) >= 0;
  [t666.c:6:17] _3 = _1 & _2;
  [t666.c:7:7] if (_3 != 0)

This "optimization" happens at early on.  I have not looked into why the line
numbers are different.

[Bug fortran/59107] [8/9/10/11 Regression] Spurious "Type specified for intrinsic function 'command_argument_count' at (1) is ignored" under -Wsurprising.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from CVS Commits  ---
The master branch has been updated by Mark Eggleston
:

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

commit r11-262-gdbeaa7ab81a37acadc9af6e7990332604252de20
Author: Mark Eggleston 
Date:   Thu Apr 23 10:33:14 2020 +0100

Fortran : Spurious warning message with -Wsurprising PR59107

This change is from a patch developed for gcc-5.  The code
has moved on since then requiring a change to interface.c

2020-05-11  Janus Weil  
Dominique d'Humieres  

gcc/fortran/

PR fortran/59107
* gfortran.h: Rename field resolved as resolve_symbol_called
and assign two 2 bits instead of 1.
* interface.c (check_dtio_interface1): Use new field name.
(gfc_find_typebound_dtio_proc): Use new field name.
* resolve.c (gfc_resolve_intrinsic): Replace check of the formal
field with resolve_symbol_called is at least 2, if it is not
set the field to 2.  (resolve_typebound_procedure): Use new field
name.  (resolve_symbol): Use new field name and check whether it
is at least 1, if it is not set the field to 1.

2020-05-11  Mark Eggleston  

gcc/testsuite/

PR fortran/59107
* gfortran.dg/pr59107.f90: New test.

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[guojiufu at gcc dot gnu.org]

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

--- Comment #13 from Jiu Fu Guo  ---
In this case, the loop body execution is at most a given number, but not an
exact number. It would be only some iterations are executed at runtime. As
above said this may false for 'while (count[n] == extent[n])'.

There may be a possible enhancement for the 'cunroll'.

[Bug bootstrap/95005] zstd.h not found if installed in non-system prefix

[gcc at ikkoku dot de]

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

--- Comment #2 from Michael Kuhn  ---
(In reply to Martin Liška from comment #1)
> Thank you for the bug report.
> I'm sending a better patch, can you please test it?

I applied your patch on top of the GCC 10.1.0 tarball. Sadly, it still fails
with the same error. It looks like ZSTD_CPPFLAGS is not actually exported/set
anywhere (only available in configure), which is why I made use of
ZSTD_INCLUDE.

[Bug c/94981] Wrong casts on Power machines dealing with fctiwuz instruction

[tony.reix at atos dot net]

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

--- Comment #8 from Tony Reix  ---
On fedora31/x86_64, when compiling with -funsigned-char, some parts of Boost
math do not compile. With some changes like: static_cast(-5) , it is easy to
make these tests to work both with -fsigned-char or -funsigned-char.
However, there are several other places where Boost expects chars to be signed
and that would require to change them too. Moreover, I have no idea yet if such
a change does modify the semantic of this Boost math code, or not. Moreover,
Boost makes use of C++ include files which have a different behavior on AIX
when converting floating point numbers to unsigned ints, vs Fedora. Thus, I
should discuss with Boost community and check if Boost is designed to handle
unsigned chars in addition to signed char, but some cases were not correctly
handled, or if Boost requires signed chars.

[Bug c/95049] New: GCC never terminates with trivial input program

[luis at luismarques dot eu]

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

Bug ID: 95049
   Summary: GCC never terminates with trivial input program
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luis at luismarques dot eu
  Target Milestone: ---

Since at least GCC 9.1 the following trivial program results in an infinite
compilation time when compiling with -O2 or higher. This continues to happen
with GCC trunk as of the date of filing this bug.

void a() {
  for (int b; b; b = !b) {
  }
}

[Bug c/95002] VLA: 'var = sizeof array' gives spurous '= array, ' instead of just '= '

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
The "array," is added by c_expr_sizeof_expr:

  if (c_vla_type_p (TREE_TYPE (folded_expr)))
{
  /* sizeof is evaluated when given a vla (C99 6.5.3.4p2).  */
  ret.value = build2 (C_MAYBE_CONST_EXPR, TREE_TYPE (ret.value),
  folded_expr, ret.value);
  C_MAYBE_CONST_EXPR_NON_CONST (ret.value) = !expr_const_operands;
  SET_EXPR_LOCATION (ret.value, loc);
}

[Bug c/94981] Wrong casts on Power machines dealing with fctiwuz instruction

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
I should note aarch64 and arm both use unsigned char as the default too.

[Bug target/95046] Vectorize V2SFmode operations

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:7c355156aa20eaec7401d7c66f6a6cfbe597abc2

commit r11-263-g7c355156aa20eaec7401d7c66f6a6cfbe597abc2
Author: Uros Bizjak 
Date:   Mon May 11 11:16:31 2020 +0200

i386: Vectorize basic V2SFmode operations [PR94913]

Enable V2SFmode vectorization and vectorize V2SFmode PLUS,
MINUS, MULT, MIN and MAX operations using XMM registers.

To avoid unwanted secondary effects (e.g. exceptions), load values
to XMM registers using MOVQ that clears high bits of the XMM
register outside V2SFmode.

The compiler now vectorizes e.g.:

float r[2], a[2], b[2];

void
test_plus (void)
{
  for (int i = 0; i < 2; i++)
r[i] = a[i] + b[i];
}

to:
movqa(%rip), %xmm0
movqb(%rip), %xmm1
addps   %xmm1, %xmm0
movlps  %xmm0, r(%rip)
ret

gcc/ChangeLog:

PR target/95046
* config/i386/i386.c (ix86_vector_mode_supported_p):
Vectorize 3dNOW! vector modes for TARGET_MMX_WITH_SSE.
* config/i386/mmx.md (*mov_internal): Do not set
mode of alternative 13 to V2SF for TARGET_MMX_WITH_SSE.

(mmx_addv2sf3): Change operand predicates from
nonimmediate_operand to register_mmxmem_operand.
(addv2sf3): New expander.
(*mmx_addv2sf3): Add SSE/AVX alternatives.  Change operand
predicates from nonimmediate_operand to register_mmxmem_operand.
Enable instruction pattern for TARGET_MMX_WITH_SSE.

(mmx_subv2sf3): Change operand predicate from
nonimmediate_operand to register_mmxmem_operand.
(mmx_subrv2sf3): Ditto.
(subv2sf3): New expander.
(*mmx_subv2sf3): Add SSE/AVX alternatives.  Change operand
predicates from nonimmediate_operand to register_mmxmem_operand.
Enable instruction pattern for TARGET_MMX_WITH_SSE.

(mmx_mulv2sf3): Change operand predicates from
nonimmediate_operand to register_mmxmem_operand.
(mulv2sf3): New expander.
(*mmx_mulv2sf3): Add SSE/AVX alternatives.  Change operand
predicates from nonimmediate_operand to register_mmxmem_operand.
Enable instruction pattern for TARGET_MMX_WITH_SSE.

(mmx_v2sf3): Change operand predicates from
nonimmediate_operand to register_mmxmem_operand.
(v2sf3): New expander.
(*mmx_v2sf3): Add SSE/AVX alternatives.  Change operand
predicates from nonimmediate_operand to register_mmxmem_operand.
Enable instruction pattern for TARGET_MMX_WITH_SSE.
(mmx_ieee_v2sf3): Ditto.

testsuite/ChangeLog:

PR target/95046
* gcc.target/i386/pr95046-1.c: New test.

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[tkoenig at gcc dot gnu.org]

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

--- Comment #14 from Thomas Koenig  ---
Most Fortran arrays are one- or two-dimensional.

Assuming a 10*10 two-dimensional array that is being packed, the
condition will be tested 121 times and the loop body will be entered
12 times. Only once will it run two times.

So, unrolling is definitely not good here.

[Bug bootstrap/95005] zstd.h not found if installed in non-system prefix

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Michael Kuhn from comment #2)
> (In reply to Martin Liška from comment #1)
> > Thank you for the bug report.
> > I'm sending a better patch, can you please test it?
> 
> I applied your patch on top of the GCC 10.1.0 tarball. Sadly, it still fails
> with the same error. It looks like ZSTD_CPPFLAGS is not actually
> exported/set anywhere (only available in configure), which is why I made use
> of ZSTD_INCLUDE.

You are right! It should be actually added to CXXFLAGS that are not respected
in gcc/Makefile:
https://github.com/gcc-mirror/gcc/blob/master/gcc/configure.ac#L1380

I'm investigating that.

[Bug tree-optimization/95049] GCC never terminates with trivial input program

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-11
 Status|UNCONFIRMED |ASSIGNED

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

[Bug c++/95050] New: coroutine: no "mandatory copy elision" for prvalue await_resume expression.

[okannen at gmail dot com]

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

Bug ID: 95050
   Summary: coroutine: no "mandatory copy elision" for prvalue
await_resume expression.
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: okannen at gmail dot com
  Target Milestone: ---

Checked with gcc version 10.1.1 20200508 (GCC) (see bellow for the `gcc -v`
output)

The result of the await-resume expression is not directly used to initialize
the result of the co_await expression.

This has the observable side effect to cause a (move) copy construction when
the result the await-resume expression is a prvalue.

I think the pertinent standard paragraph is, [expr.await]/§5.3
> [...] the await-resume expression is evaluated, and its result is the result 
> of the await-expression.

The code bellow compiles on clang but fail to compile on gcc:

#ifdef __clang__
#include 
using namespace std::experimental;
#else
#include 
using namespace std;
#endif

struct task
{
struct promise_type
{
auto get_return_object () -> task 
{
return {};
}

auto initial_suspend () -> suspend_never
{
return {};
}

auto final_suspend () -> suspend_always
{
return {};
}

void unhandled_exception ()
{ }

void return_void ()
{}
};
};

struct ret_type 
{
ret_type () = default;
ret_type (const ret_type&) =delete;
};

struct awaiter
{

auto await_ready() const -> bool 
{
return true;
}

void await_suspend (coroutine_handle<>)
{}

auto await_resume() -> ret_type
{
return {};
}

};

task f()
{
ret_type r2 {co_await awaiter{}};
};

int main()
{
auto x = f();
return 0;
}   

This code was tentatively compiled with `c++ -std=c++20 -fcoroutines`

`gcc -v`:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/olivier/usr/libexec/gcc/x86_64-pc-linux-gnu/10/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-libsanitizer
--prefix=/home/olivier/usr/ --with-gcc-major-version-only --disable-bootstrap
--enable-language=c,c++,lto
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.1.1 20200508 (GCC)

[Bug fortran/59107] [8/9/10/11 Regression] Spurious "Type specified for intrinsic function 'command_argument_count' at (1) is ignored" under -Wsurprising.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #20 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:2653784e500eccf5d5c2518914b1d9663fe63648

commit r10-8131-g2653784e500eccf5d5c2518914b1d9663fe63648
Author: Mark Eggleston 
Date:   Thu Apr 23 10:33:14 2020 +0100

Fortran : Spurious warning message with -Wsurprising PR59107

This change is from a patch developed for gcc-5.  The code
has moved on since then requiring a change to interface.c

2020-05-11  Mark Eggleston  

Backported from mainline
2020-05-11  Janus Weil  
Dominique d'Humieres  

gcc/fortran/

PR fortran/59107
* gfortran.h: Rename field resolved as resolve_symbol_called
and assign two 2 bits instead of 1.
* interface.c (check_dtio_interface1): Use new field name.
(gfc_find_typebound_dtio_proc): Use new field name.
* resolve.c (gfc_resolve_intrinsic): Replace check of the formal
field with resolve_symbol_called is at least 2, if it is not
set the field to 2.  (resolve_typebound_procedure): Use new field
name.  (resolve_symbol): Use new field name and check whether it
is at least 1, if it is not set the field to 1.

Backported from mainline
2020-05-11  Mark Eggleston  

gcc/testsuite/

PR fortran/59107
* gfortran.dg/pr59107.f90: New test.

[Bug bootstrap/95005] zstd.h not found if installed in non-system prefix

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #4 from Martin Liška  ---
Hm, I must say that current master works for me:

$ ../configure --with-zstd=/tmp/sparta
...
$ make lto-compress.o
g++ -fno-PIE -c  -I/home/marxin/Programming/gcc/gcc/../zlib -g 
-I/tmp/sparta/include -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc/gcc
-I/home/marxin/Programming/gcc/gcc/.
-I/home/marxin/Programming/gcc/gcc/../include
-I/home/marxin/Programming/gcc/gcc/../libcpp/include 
-I/home/marxin/Programming/gcc/gcc/../libdecnumber
-I/home/marxin/Programming/gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/marxin/Programming/gcc/gcc/../libbacktrace   -o lto-compress.o -MT
lto-compress.o -MMD -MP -MF ./.deps/lto-compress.TPo
/home/marxin/Programming/gcc/gcc/lto-compress.c

you can find "-I/tmp/sparta/include" at the command line.

[Bug ada/95035] [11 regression] gnat.dg/sso/p10.adb FAILs

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-11

--- Comment #1 from Eric Botcazou  ---
I can reproduce.

[Bug ada/95035] [11 regression] gnat.dg/sso/p10.adb FAILs

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Fixing.

[Bug c/95044] [10/11 Regression] -Wreturn-local-addr false alarm since r10-1741-gaac9480da1ffd037

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
I think there is another very similar bug report.

  # buf_1 = PHI <&stack_buf(2), buf_15(6)>
[...]
  if (&stack_buf != buf_1)

in each branch, we thus know what buf_1 is, so we could replace it with buf_15
in

  # _3 = PHI <_17(5), buf_1(4)>
  return _3;

(or is that bad for register pressure?)

Or use it as a hint to thread that path, or add some logic to
Wreturn_local_addr, but that's getting more complicated.

[Bug c/95051] New: error: invalid RHS for gimple memory store:

[dcb314 at hotmail dot com]

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

Bug ID: 95051
   Summary: error: invalid RHS for gimple memory store:
   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: ---

Created attachment 48505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48505&action=edit
gzipped C source code

>From a compile of recent linux linux-5.7-rc5 with recent gcc trunk,
I get 

drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_dbgdev.c: In function
‘dbgdev_diq_submit_ib.constprop’:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_dbgdev.c:47:12: error: invalid RHS for
gimple memory store: ‘parm_decl’
vmid0_address

vmid0_address

# .MEM_120 = VDEF <.MEM_37(D)>
vmid0_address = vmid0_address;
during GIMPLE pass: sanopt
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_dbgdev.c:47:12: internal compiler
error: verify_gimple failed
0xf62dd1 verify_gimple_in_cfg(function*, bool)
../../trunk.git/gcc/tree-cfg.c:5461
0xdfe00f execute_function_todo
../../trunk.git/gcc/passes.c:1985
0xdff371 do_per_function
../../trunk.git/gcc/passes.c:1640
0xdff371 execute_todo
../../trunk.git/gcc/passes.c:2039

This problem seems to have first occurred sometime between 20200507 and
20200508.

Source code attached. I'll have my usual go at reducing the code.

[Bug c/95044] [10/11 Regression] -Wreturn-local-addr false alarm since r10-1741-gaac9480da1ffd037

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Peeling off the first iteration might be the answer.  Thread jumping could do
that but normally is not used for that, especially through other condtionals.

[Bug c/95051] error: invalid RHS for gimple memory store:

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Flags required:

-w -O2  -std=gnu90   -fsanitize=kernel-address --param=asan-stack=1

[Bug c/95051] error: invalid RHS for gimple memory store:

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
Reduced code:

struct a {
  struct {
struct {
  int b
} c
  }
};
struct d {
  struct {
int e
  } f
} g(h) {
  struct a *i;
  struct d *j = &h;
  i->c.b = j->f.e;
}

[Bug c/95052] New: Excess padding of partially initialized strings/char arrays

[krzysztof.a.nowicki+gcc at gmail dot com]

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

Bug ID: 95052
   Summary: Excess padding of partially initialized strings/char
arrays
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krzysztof.a.nowicki+gcc at gmail dot com
  Target Milestone: ---

Created attachment 48506
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48506&action=edit
generated assembly (GCC 11.0 trunk, -Os -g0)

When compiling the following code with -Os:

  extern void func(char *buf, unsigned size);
  int main(int argc, char *argv[])
  {
char str[1*1024*1024] =
"fooiuhluhpiuhliuhliyfyukyfklyugkiuhpoipoipoipoipoipoipoipoipoipoipoipoipoimipoipiuhoulouihnliuhl";
char arr[1*1024*1024] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7,
8, 9, 0, 1, 6, 2, 3, 4, 5, 6, 7, 8, 9, 0, 3, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1,
2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0};
func(str, sizeof(str));
func(arr, sizeof(arr));
 }

GCC generates initializers for both local variables (str and arr) in the
.rodata section and at run-time initializes the explicit part of the variable
with the provided contents, and zero-inits the remainder.

Unfortunately the initializer stored in the .rodata section is padded up to the
target array size:

.LC0:
.string
"fooiuhluhpiuhliuhliyfyukyfklyugkiuhpoipoipoipoipoipoipoipoipoipoipoipoipoimipoipiuhoulouihnliuhl"
.zero   1048479
.LC1:
.string "\001\026\003\004\005?\007\b'"
.string "\001\002\003\004\005>\033\b1"
.string "\001\006\002\003\004\005\006\007\b\t"
.string "\003\001\002\003\004\005\006\007\b\t"
.string "\001\002\003\004\005\006\007\b\t"
.string "\001\002\003\004\005\006\007\b\t"
.string "\002\002\003\004\005>\033\b1"
.string "\001\006\002\003\004\005\006\007\b\t"
.string "\003\001\002\003\004\005\006\007\b\t"
.string "\001\002\003\004\005\006\007\b\t"
.string "\001\002\003\004\005"
.zero   1048466

This causes the resulting binary to become unnecessarily large, even though the
zero padding is completely redundant (the run-time initializer code does not
copy these bytes to the target variable, but zero-initializes them.

I suspect that this is caused by GCC not being able to distinguish between:
 - initialization of a global (or static local) variable,
 - initialization of a local variable

In the former case the contents of the variable live in the read/write data
section and are initialized by the compiler. In such case padding is necessary
as any further changes to the variable will be done in-place.

In the latter case the contents of the variable live on the stack and are
initialized from a read-only copy in the read-only data section. In such case
only the non-zero explicitly initialized part needs to be stored - any padding
can be skipped as it will not be used.

This mis-optimization occurs depending on compiler flags, architecture and size
of the array as well as the initialized part, as GCC may choose (and usually
does) to initialize the variable by using store assembly instructions with
immediate values, as this method is usually faster at the cost of increased
code size.

[Bug fortran/95053] New: [11.0 regression] ICE in f951: gfc_divide()

[juergen.reuter at desy dot de]

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

Bug ID: 95053
   Summary: [11.0 regression] ICE in f951: gfc_divide()
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

Created attachment 48507
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48507&action=edit
Reproducer

In some of our legacy code which we are still using, the new gcc/gfortran 11.0
release seems to have introduced a regression which leads to an ICE with the
following message, cf. below. I presume that this regression has been
introduced after the 11.0.0 has been opened, so must be really fresh. 
The file is attached, ist just 250 lines. 
$ gfortran -c mnstin.f 
f951: internal compiler error: gfc_divide(): Bad basic type
0x7fce8b gfc_report_diagnostic
../../gcc/fortran/error.c:782
0x7fce8b gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1402
0x7c4411 gfc_divide(gfc_expr*, gfc_expr*)
../../gcc/fortran/arith.c:1831
0x838665 match_add_operand
../../gcc/fortran/matchexp.c:394
0x8388c6 match_level_2
../../gcc/fortran/matchexp.c:480
0x838aa6 match_level_3
../../gcc/fortran/matchexp.c:551
0x838bd8 match_level_4
../../gcc/fortran/matchexp.c:599
0x838bd8 match_and_operand
../../gcc/fortran/matchexp.c:693
0x838de6 match_or_operand
../../gcc/fortran/matchexp.c:722
0x838ee6 match_equiv_operand
../../gcc/fortran/matchexp.c:765
0x838fe8 match_level_5
../../gcc/fortran/matchexp.c:811
0x8380c2 gfc_match_expr(gfc_expr**)
../../gcc/fortran/matchexp.c:870
0x863fda match_actual_arg
../../gcc/fortran/primary.c:1662
0x8656a5 gfc_match_actual_arglist(int, gfc_actual_arglist**, bool)
../../gcc/fortran/primary.c:1927
0x867ecd gfc_match_rvalue(gfc_expr**)
../../gcc/fortran/primary.c:3611
0x8382bf match_primary
../../gcc/fortran/matchexp.c:157
0x8382bf match_level_1
../../gcc/fortran/matchexp.c:211
0x8382bf match_mult_operand
../../gcc/fortran/matchexp.c:267
0x8385fc match_add_operand
../../gcc/fortran/matchexp.c:356
0x8388c6 match_level_2
../../gcc/fortran/matchexp.c:480

[Bug c++/95054] New: internal compiler error while overloading class constructor using variadic templates constraint by c++20 concepts

[breyer.marcel at web dot de]

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

Bug ID: 95054
   Summary: internal compiler error while overloading class
constructor using variadic templates constraint by
c++20 concepts
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: breyer.marcel at web dot de
  Target Milestone: ---

Overloading a class constructor with variadic templates where both are
constraint by c++20 concepts fails to compile with a internal compiler error.

Minimal example (using -std=c++2a):
#include 

class A {
template 
A(T&&... args) { }

template 
A(T&&... args) { }
};

Error message:
: In instantiation of 'template  requires (... &&
integral) A::A(T&& ...)':

:8:22:   required from here

:8:22: internal compiler error: in push_access_scope, at cp/pt.c:241

8 | A(T&&... args) { }

  |  ^

Full code: https://godbolt.org/z/9byrBN

GCC compiles correctly if you replace the c++20 concepts with "old" SFINAE.
It also compiles WITH concepts on member functions and non-member functions.

clang 10.0.0 and MSVC v19.24 do compile the constructor case correctly.

[Bug c/95052] Excess padding of partially initialized strings/char arrays

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-11
   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
I'm not sure what you describe as padding is padding.  Instead it's valid to
access all elements of the array you declare and thus it must be initialized.

What could be done is elide zero-padding parts to a memset() call.

[Bug tree-optimization/95051] error: invalid RHS for gimple memory store:

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|c   |tree-optimization
Version|unknown |11.0
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 Depends on||95033
   Last reconfirmed||2020-05-11

--- Comment #3 from Richard Biener  ---
Confirmed, looks related to PR95033

The ICE occurs in sanopt


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95033
[Bug 95033] [11 Regression] ICE in set_parm_rtl, at cfgexpand.c:1310 since
r11-165-geb72dc663e9070b2

[Bug fortran/59107] [8/9/10/11 Regression] Spurious "Type specified for intrinsic function 'command_argument_count' at (1) is ignored" under -Wsurprising.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:5a17beaecadf10d1c9c44d2b31eedc11dfdea35a

commit r9-8584-g5a17beaecadf10d1c9c44d2b31eedc11dfdea35a
Author: Mark Eggleston 
Date:   Mon May 11 12:38:14 2020 +0100

Fortran : Spurious warning message with -Wsurprising PR59107

This change is from a patch developed for gcc-5.  The code
has moved on since then requiring a change to interface.c

2020-05-11  Mark Eggleston  

Backported from mainline
2020-05-11  Janus Weil  
Dominique d'Humieres  

gcc/fortran/

PR fortran/59107
* gfortran.h: Rename field resolved as resolve_symbol_called
and assign two 2 bits instead of 1.
* interface.c (gfc_find_typebound_dtio_proc): Use new field name.
* resolve.c (gfc_resolve_intrinsic): Replace check of the formal
field with resolve_symbol_called is at least 2, if it is not
set the field to 2.  (resolve_typebound_procedure): Use new field
name.  (resolve_symbol): Use new field name and check whether it
is at least 1, if it is not set the field to 1.

Backported from mainline
2020-05-11  Mark Eggleston  

gcc/testsuite/

PR fortran/59107
* gfortran.dg/pr59107.f90: New test.

[Bug tree-optimization/95049] [9/10/11 Regression] GCC never terminates with trivial input program

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|GCC never terminates with   |[9/10/11 Regression] GCC
   |trivial input program   |never terminates with
   ||trivial input program
   Target Milestone|--- |9.4
   Priority|P3  |P2

[Bug target/95055] New: gcc.dg/compat/scalar-by-value-3 fails on aarch64 after r11-165-geb72dc663e9070b281be83a80f6f838a3a878822

[clyon at gcc dot gnu.org]

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

Bug ID: 95055
   Summary: gcc.dg/compat/scalar-by-value-3 fails on aarch64 after
r11-165-geb72dc663e9070b281be83a80f6f838a3a878822
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi,

After r11-165-geb72dc663e9070b281be83a80f6f838a3a878822, I've noticed that
scalar-by-value-3 fails on aarch64:
gcc.dg/compat/scalar-by-value-3 c_compat_x_tst.o-c_compat_y_tst.o execute 
gcc.dg/compat/scalar-by-value-4 c_compat_x_tst.o-c_compat_y_tst.o execute 
gcc.dg/compat/scalar-by-value-5 c_compat_x_tst.o-c_compat_y_tst.o execute 
gcc.dg/compat/scalar-by-value-6 c_compat_x_tst.o-c_compat_y_tst.o execute 
gcc.dg/compat/scalar-return-3 c_compat_x_tst.o-c_compat_y_tst.o execute 
gcc.dg/compat/scalar-return-4 c_compat_x_tst.o-c_compat_y_tst.o execute

[Bug fortran/95053] [11.0 regression] ICE in f951: gfc_divide()

[juergen.reuter at desy dot de]

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

--- Comment #1 from Jürgen Reuter  ---
I shrank the example even further:
  SUBROUTINE MNSTIN
 132  FORMAT (' UNIT',I3,' ALREADY OPENED WITH NAME:',A/
 +' NEW NAME IGNORED:',A)
  RETURN
  END

It looks like it is the combination of integer format with this special form of
character line continuation.

[Bug fortran/95053] [11.0 regression] ICE in f951: gfc_divide()

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
(In reply to Jürgen Reuter from comment #1)
> I shrank the example even further:
>   SUBROUTINE MNSTIN
>  132  FORMAT (' UNIT',I3,' ALREADY OPENED WITH NAME:',A/
>  +' NEW NAME IGNORED:',A)
>   RETURN
>   END
> 
> It looks like it is the combination of integer format with this special form
> of character line continuation.

Indeed, I found an even shorter reproducer:

  SUBROUTINE MNSTIN ()
* Adding a comma before or after the "/" avoids the ICE
 132  FORMAT (A/
 + ' B')
  END

I am responsible for the change in gfc_divide, but fail to see
where there is a division...

[Bug c++/94955] [10/11 Regression] ICE in to_wide

[john at mcfarlane dot name]

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

--- Comment #5 from John McFarlane  ---
I have applied a workaround and am not blocked:
https://github.com/johnmcfarlane/cnl/pull/589/commits/ca3478ed0002e5834227d7b6fa0010910aabc875

[Bug tree-optimization/90668] loop invariant moving a dependent store out of a loop

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #4 from Arseny Solokha  ---
I cannot reproduce it anymore on x86_64 w/ gcc-11.0.0-alpha20200510 snapshot
(g:13a46321516e2efd3bbb1f1899c539c6724240a9), while gcc 9 and 10 are still
affected.

[Bug target/95056] New: slp-perm-9.c fails on aarch64 after gbc484e250990393e887f7239157cc85ce6fadcce

[clyon at gcc dot gnu.org]

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

Bug ID: 95056
   Summary: slp-perm-9.c fails on aarch64 after
gbc484e250990393e887f7239157cc85ce6fadcce
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi,

I've noticed that
FAIL: gcc.dg/vect/slp-perm-9.c -flto -ffat-lto-objects  scan-tree-dump-times
vect "permutation requires at least three vectors" 1
FAIL: gcc.dg/vect/slp-perm-9.c scan-tree-dump-times vect "permutation requires
at least three vectors" 1

on aarch64

since commit gbc484e250990393e887f7239157cc85ce6fadcce

[Bug objc++/95013] [11 Regression] FAIL: obj-c++.dg/property/property-neg-6.mm syntax-error-10.mm

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c/95057] New: missing -Wunused-but-set-variable warning on multiple assignments, not all of them used

[vincent-gcc at vinc17 dot net]

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

Bug ID: 95057
   Summary: missing -Wunused-but-set-variable warning on multiple
assignments, not all of them used
   Product: gcc
   Version: 10.1.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: ---

With -Wunused-but-set-variable, GCC does not warn in the following cases:

int f (int i)
{
  int j;
  j = i + 1;  /* unused */
  j = i + 2;
  return j;
}

int g (int i)
{
  int j, k;
  j = i + 1;
  k = j + 1;
  j = i + 2;  /* unused */
  return k;
}

Note: it is possible that PR44677 may be regarded as a particular case of this
bug.

[Bug c/95057] missing -Wunused-but-set-variable warning on multiple assignments, not all of them used

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
That is something this warning can't warn about.
The warning is a simple FE warning that uses two bits, one for whether certain
decl was used and one whether it was read.  The warning then diagnoses those
that have the former bit set and not the latter (of course, there are some
exceptions etc.).

[Bug tree-optimization/57359] store motion causes wrong code for union access at -O3

[rguenth at gcc dot gnu.org]

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

Bug 90668 Summary: loop invariant moving a dependent store out of a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90668

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug tree-optimization/90668] loop invariant moving a dependent store out of a loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

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

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

[Bug tree-optimization/57359] store motion causes wrong code for union access at -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

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

[Bug tree-optimization/95056] [11 Regression] slp-perm-9.c fails on aarch64 after gbc484e250990393e887f7239157cc85ce6fadcce

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|10.0|11.0
  Component|target  |tree-optimization
   Target Milestone|--- |11.0
   Keywords||missed-optimization
Summary|slp-perm-9.c fails on   |[11 Regression]
   |aarch64 after   |slp-perm-9.c fails on
   |gbc484e250990393e887f723915 |aarch64 after
   |7cc85ce6fadcce  |gbc484e250990393e887f723915
   ||7cc85ce6fadcce

--- Comment #1 from Richard Biener  ---
Hmm, load-lane support should be unaffected (but I didn't test obviously).  I
hope aarch64 folks can investigate - eventually the permute check done in
vectorizable_load needs adjustment / moving.

[Bug other/95058] New: [11 regression] vector test case failures starting with r11-205

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95058
   Summary: [11 regression] vector test case failures starting
with r11-205
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

this run: g:bc484e250990393e887f7239157cc85ce6fadcce, r11-205:

This occurs on all powerpc 64 targets:

FAIL: gcc.dg/vect/bb-slp-pr68892.c -flto -ffat-lto-objects 
scan-tree-dump-times slp2 "Basic block will be vectorized" 1
FAIL: gcc.dg/vect/bb-slp-pr68892.c scan-tree-dump-times slp2 "Basic block will
be vectorized" 1


This one only occurs on power 7 BE:

FAIL: gcc.dg/vect/bb-slp-pr69907.c -flto -ffat-lto-objects  scan-tree-dump slp1
"BB vectorization with gaps at the end of a load is not supported"
FAIL: gcc.dg/vect/bb-slp-pr69907.c scan-tree-dump slp1 "BB vectorization with
gaps at the end of a load is not supported"

[Bug target/95055] [11 Regression] gcc.dg/compat/scalar-by-value-3 fails on aarch64 after r11-165-geb72dc663e9070b281be83a80f6f838a3a878822

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|gcc.dg/compat/scalar-by-val |[11 Regression]
   |ue-3 fails on aarch64 after |gcc.dg/compat/scalar-by-val
   |r11-165-geb72dc663e9070b281 |ue-3 fails on aarch64 after
   |be83a80f6f838a3a878822  |r11-165-geb72dc663e9070b281
   ||be83a80f6f838a3a878822
   Target Milestone|--- |11.0
Version|10.0|11.0
 CC||rguenth at gcc dot gnu.org
   Keywords||wrong-code

[Bug fortran/95053] [11.0 regression] ICE in f951: gfc_divide()

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug tree-optimization/95058] [11 regression] vector test case failures starting with r11-205

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
  Component|other   |tree-optimization

--- Comment #1 from Richard Biener  ---
Can you attach the dumps for power7 and "the rest"?

[Bug c/95057] missing -Wunused-but-set-variable warning on multiple assignments, not all of them used

[vincent-gcc at vinc17 dot net]

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

--- Comment #2 from Vincent Lefèvre  ---
(In reply to Jakub Jelinek from comment #1)
> That is something this warning can't warn about.
> The warning is a simple FE warning that uses two bits, one for whether
> certain decl was used and one whether it was read.  The warning then
> diagnoses those that have the former bit set and not the latter (of course,
> there are some exceptions etc.).

But when the variable is assigned, the "read" bit could be reset.

[Bug objc++/95013] [11 Regression] FAIL: obj-c++.dg/property/property-neg-6.mm syntax-error-10.mm

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

--- Comment #6 from Bill Seurer  ---
These started with r11-204 and occur on powerpc64 BE and LE as well.

commit debfaee5d51e3c07bb88a971618de2baff35d9c0
Author: Nathan Sidwell 
Date:   Fri May 8 08:43:16 2020 -0700

EOF has a location

There's no need to special-case EOF's location.  For the complete file we
give it a legitimate location.  And for deferred parses we now zap a
temporary EOF
onto the next token, so we can just use its location anyway.

[Bug c/95052] Excess padding of partially initialized strings/char arrays

[krzysztof.a.nowicki+gcc at gmail dot com]

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

--- Comment #2 from Krzysztof Nowicki  ---
(In reply to Richard Biener from comment #1)
> I'm not sure what you describe as padding is padding.  Instead it's valid to
> access all elements of the array you declare and thus it must be initialized.

Not in this case, as this is a constant initializer, which is anonymous and is
never accessible from the code directly.

> What could be done is elide zero-padding parts to a memset() call.

Exactly, this is what I mean. Currently this actually happens in the generated
code (see attachment), but the part of GCC which allocates the variable in the
.rodata section doesn't know that and allocates memory for the full contents
including the zero padding.

[Bug c/95057] missing -Wunused-but-set-variable warning on multiple assignments, not all of them used

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
It can't.  The warning isn't flow sensitive, doesn't know about assignments,
conditionals etc.
What you are thinking of is something that can be only done much later, but at
that point one risks that there is compiler-introduced dead code that wasn't
really the fault of the user.

[Bug go/95059] New: GCCGO cannot be compiled for ARM64 ILP32 ABI

[mikulas at artax dot karlin.mff.cuni.cz]

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

Bug ID: 95059
   Summary: GCCGO cannot be compiled for ARM64 ILP32 ABI
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: mikulas at artax dot karlin.mff.cuni.cz
CC: cmang at google dot com
  Target Milestone: ---

Compiling gcc on ARM64 with these options fails. It worked on gcc 9.

#!/bin/sh
set -e
MAKEFLAGS=-j4
export MAKEFLAGS
../gcc-10.1.0/configure \
--prefix=/usr/local/gcc-10.1.0-fail/\
--enable-lto\
--with-system-zlib  \
--enable-languages=c,c++,go \
--enable-multilib   \
--with-multilib-list=lp64,ilp32 \
--disable-libsanitizer
nice -n 20 make

../../../../gcc-10.1.0/libgo/go/runtime/mpagealloc.go:226:38: error: shift
count overflow
  226 |  chunks [1 << pallocChunksL1Bits]*[1 << pallocChunksL2Bits]pallocData
  |  ^
../../../../gcc-10.1.0/libgo/go/runtime/mgcscavenge.go:530:15: error: shift
count overflow
  530 |l2 := (*[1 <<
pallocChunksL2Bits]pallocData)(atomic.Loadp(unsafe.Pointer(&s.chunks[i.l1()])))
  |   ^
../../../../gcc-10.1.0/libgo/go/runtime/mpagealloc.go:138:22: error: shift
count overflow
  138 |   return uint(i) & (1<> pallocChunksL1Shift
  | ^
../../../../gcc-10.1.0/libgo/go/runtime/mpagealloc_64bit.go:34:2: error:
integer constant overflow
   34 |  summaryL0Bits,
  |  ^
make[8]: *** [Makefile:2865: runtime.lo] Chyba 1
make[8]: *** Čeká se na nedokončené úlohy…

[Bug c/95052] Excess padding of partially initialized strings/char arrays

[krzysztof.a.nowicki+gcc at gmail dot com]

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

--- Comment #3 from Krzysztof Nowicki  ---
Note, that this missed optimization is actually a regression (at least in our
case on MIPS64). Commit 23aa9f7c4637ad51587e536e245ae6adb5391bbc (released in
GCC 8.x) added the possibility to optimize initialization of a char array into
a string initialization. This means that this code:

  #include 
  int main(int argc, char *argv[])
  { 
char buf[1*1024*1024] = { 0 };
return read(0, buf, sizeof buf);
  }

generates the following binary sizes for MIPS64:

 * 13632 bytes (GCC-6.4)
 * 1061656 bytes (GCC-9.1)

[Bug go/95059] GCCGO cannot be compiled for ARM64 ILP32 ABI

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
See .

[Bug c/95057] missing -Wunused-but-set-variable warning on multiple assignments, not all of them used

[vincent-gcc at vinc17 dot net]

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

--- Comment #4 from Vincent Lefèvre  ---
OK, so the work (for this warning or a new one) should be done later, but early
enough not to be affected by optimizations.

One of the goals would be to detect a missing check of a return value of a
function call (typically an error status). For such a typical usage, the same
variable can be reused for each error status.

  int r;

  r = call1 (...);
  check (r);
  /* ... */
  r = call2 (...);
  check (r);
  /* ... */
  r = call3 (...);
  check (r);

If a check is missing, there should be a warning.

[Bug c/95002] VLA: 'var = sizeof array' gives spurous '= array, ' instead of just '= '

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
As discussed with Joseph on IRC:

* The 'array, 4*len' is one on purpose per C spec
  (sizeof for an expression with VLA type is defined to evaluate its argument.)
* g++ might not do this, if so, it is a bug.

* Convert should do the folding and leave the fold to gimple folding

[Bug c/95002] VLA: 'var = sizeof array' gives spurous '= array, ' instead of just '= '

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #3)
> * Convert should do the folding and leave the fold to gimple folding

Which means that one has to do this kind of folding before handling the
share/map handling for OpenMP/OpenACC.

[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[guojiufu at gcc dot gnu.org]

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

--- Comment #15 from Jiu Fu Guo  ---
Hi Thomas,
Are you using a test case to check the performance? If you have, would you
please share it, then we can use it to tune a heuristic improvement for
cunroll.

Thanks.

[Bug fortran/59107] [8/9/10/11 Regression] Spurious "Type specified for intrinsic function 'command_argument_count' at (1) is ignored" under -Wsurprising.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #22 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Mark Eggleston
:

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

commit r8-10247-g3d32b5c89438dbec423e48954ebffe51ee2b8dda
Author: Mark Eggleston 
Date:   Mon May 11 12:38:14 2020 +0100

Fortran : Spurious warning message with -Wsurprising PR59107

This change is from a patch developed for gcc-5.  The code
has moved on since then requiring a change to interface.c

2020-05-11  Mark Eggleston  

Backported from mainline
2020-05-11  Janus Weil  
Dominique d'Humieres  

gcc/fortran/

PR fortran/59107
* gfortran.h: Rename field resolved as resolve_symbol_called
and assign two 2 bits instead of 1.
* interface.c (gfc_find_typebound_dtio_proc): Use new field name.
* resolve.c (gfc_resolve_intrinsic): Replace check of the formal
field with resolve_symbol_called is at least 2, if it is not
set the field to 2.  (resolve_symbol): Use new field name and
check whether it is at least 1, if it is not set the field to 1.

Backported from mainline
2020-05-11  Mark Eggleston  

gcc/testsuite/

PR fortran/59107
* gfortran.dg/pr59107.f90: New test.

[Bug fortran/59107] [8/9/10/11 Regression] Spurious "Type specified for intrinsic function 'command_argument_count' at (1) is ignored" under -Wsurprising.

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #23 from markeggleston at gcc dot gnu.org ---
Commits to master and backported to gcc-10, gcc-9 and gcc-8.

[Bug c/95002] VLA: 'var = sizeof array' gives spurous '= array, ' instead of just '= '

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Or deal with that during gimplification.

[Bug target/94991] aarch64: ICE: Segmentation fault with option -mgeneral-regs-only

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:248e357f6941fe9409658386dc9b86b75dfd96c6

commit r11-269-g248e357f6941fe9409658386dc9b86b75dfd96c6
Author: Fei Yang 
Date:   Mon May 11 15:18:47 2020 +0100

aarch64: Fix ICE when expanding scalar floating move with
-mgeneral-regs-only. [PR94991]

In the testcase for PR94991, we are doing FAIL for scalar floating move
expand
pattern since TARGET_FLOAT is false with option -mgeneral-regs-only. But
move
expand pattern cannot fail. It would be better to replace the FAIL with
code
that bitcasts to the equivalent integer mode using gen_lowpart.

2020-05-11  Felix Yang  

gcc/
PR target/94991
* config/aarch64/aarch64.md (mov):
Bitcasts to the equivalent integer mode using gen_lowpart
instead of doing FAIL for scalar floating point move.

gcc/testsuite/
PR target/94991
* gcc.target/aarch64/mgeneral-regs_5.c: New test.

[Bug c/95044] [10/11 Regression] -Wreturn-local-addr false alarm since r10-1741-gaac9480da1ffd037

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #3 from Martin Sebor  ---
This looks like a duplicate of pr93644, including the test case involving the
careadlinkat function.

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

[Bug other/90556] [meta-bug] bogus/missing -Wreturn-local-addr

[msebor at gcc dot gnu.org]

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

Bug 95044 Summary: [10/11 Regression] -Wreturn-local-addr false alarm since 
r10-1741-gaac9480da1ffd037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95044

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug middle-end/93644] [10/11 Regression] spurious -Wreturn-local-addr with PHI of PHI

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||eggert at cs dot ucla.edu

--- Comment #8 from Martin Sebor  ---
*** Bug 95044 has been marked as a duplicate of this bug. ***

[Bug target/95046] Vectorize V2SFmode operations

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r11-270-gaa4317866bf3e9f42f3b8e3b1b1ec113ed1f818d
Author: Uros Bizjak 
Date:   Mon May 11 16:37:19 2020 +0200

i386: Improve basic vectorized V2SFmode operations [PR95046]

Use plain "v" constraint for AVX alternatives and add "prefix" attribute.

gcc/ChangeLog:

PR target/95046
* config/i386/mmx.md (mmx_addv2sf3): Use "v" constraint
instead of "Yv" for AVX alternatives.  Add "prefix" attribute.
(*mmx_addv2sf3): Ditto.
(*mmx_subv2sf3): Ditto.
(*mmx_mulv2sf3): Ditto.
(*mmx_v2sf3): Ditto.
(mmx_ieee_v2sf3): Ditto.

[Bug fortran/94672] [10/11 Regression] gfortran/OpenMP chokes on PRESENT(array) despite of SHARED(array): Error: ‘array’ not specified in enclosing ‘parallel’

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:892c7427ee234c04852e90d9ce32913a429adf9d

commit r11-271-g892c7427ee234c04852e90d9ce32913a429adf9d
Author: Tobias Burnus 
Date:   Mon May 11 16:39:20 2020 +0200

[Fortran] Fix/modify present() handling for assumed-shape optional (PR
94672)

gcc/fortran/
2020-05-07  Tobias Burnus  

PR fortran/94672
* trans.h (gfc_conv_expr_present): Add use_saved_decl=false
argument.
* trans-expr.c (gfc_conv_expr_present): Likewise; use DECL directly
and only if use_saved_decl is true, use the actual PARAM_DECL arg
(saved
descriptor).
* trans-array.c (gfc_trans_dummy_array_bias): Set local 'arg.0'
variable to NULL if 'arg' is not present.
* trans-openmp.c (gfc_omp_check_optional_argument): Simplify by
checking
'arg.0' instead of the true PARM_DECL.
(gfc_omp_finish_clause): Remove setting 'arg.0' to NULL.

gcc/testsuite/
2020-05-07  Jakub Jelinek  
Tobias Burnus  

PR fortran/94672
* gfortran.dg/gomp/pr94672.f90: New.
* gfortran.dg/missing_optional_dummy_6a.f90: Update scan-tree.

[Bug target/95052] Excess padding of partially initialized strings/char arrays

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Component|c   |target

--- Comment #4 from Martin Sebor  ---
The optimization in g:23aa9f7c4637ad51587e536e245ae6adb5391bbc should only
convert into a STRING_CST the initial portion of the braced initializer list up
to just past the last non-nul character.  The remaining nuls should be skipped.
 In other words, this

char buf[1*1024*1024] = { 0 };

should result in the same IL as this equivalent:

char buf[1*1024*1024] = "";

I don't expect the commit above to have changed anything for the latter form,
and I would expect each back end to choose the same optimal code to emit in
both cases.  So I don't think the commit above is a regression; it just exposed
an inefficiency that was already present.

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[myron.walker at gmail dot com]

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

--- Comment #20 from Myron Walker  ---
So I will probably continue working on the python script or package that can do
much of the enhanced processing.  One of the benefits of the python is I can
process the code coverage data outside of a build environment altogether.

[Bug target/95052] Excess padding of partially initialized strings/char arrays

[krzysztof.a.nowicki+gcc at gmail dot com]

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

--- Comment #5 from Krzysztof Nowicki  ---
(In reply to Martin Sebor from comment #4)
> I don't expect the commit above to have changed anything for the latter
> form, and I would expect each back end to choose the same optimal code to
> emit in both cases.  So I don't think the commit above is a regression; it
> just exposed an inefficiency that was already present.

Yes, from the implementation point of view I agree - the missed optimization
was there all the time and this commit exposed it in one more use case, where
it wasn't seen before. However from the point of view of an application
developer on an embedded system, who has developed it with some memory
constraints in mind, a sudden increase of memory usage, possibly causing an OOM
since the memory budget on this system is very tight (legacy platform), just by
upgrading the compiler is a regression.