[Bug fortran/95067] [9/10/11 Regression] ICE in tree_fits_shwi_p, at tree.c:7262

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.4

--- Comment #2 from Richard Biener  ---
That commit looks totally unrelated ... but it's eventually that

  /* If there was an input error and we don't really have a type,
 avoid crashing and write something that is at least valid
 by assuming `int'.  */
  if (type == error_mark_node)
type = integer_type_node;

in dbxout_type makes us later use uninitialized low/high.  using
void_type_node might be less error-prone here.

Untested suggestion, that is.  Take it or leave it ;)  (stabs should go away)

[Bug middle-end/95072] [10/11 Regression] -Warray-bounds false positive with flexible array bounds (regression from GCC 9)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|-Warray-bounds false|[10/11 Regression]
   |positive with flexible  |-Warray-bounds false
   |array bounds (regression|positive with flexible
   |from GCC 9) |array bounds (regression
   ||from GCC 9)
   Priority|P3  |P2
   Target Milestone|--- |10.2

[Bug d/95075] New: gcc/d/dmd/dscope.c: 2 * strange assignments ?

[dcb314 at hotmail dot com]

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

Bug ID: 95075
   Summary: gcc/d/dmd/dscope.c: 2 * strange assignments ?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I just tried to build the D compiler with the clang++ compiler.

1.

trunk.git/gcc/d/dmd/dscope.c:318:23: warning: explicitly assigning value of
variable of type 'unsigned int' to itself [-Wself-assign]

Source code is

 fieldInit = fieldInit;

2.

trunk.git/gcc/d/dmd/dscope.c:328:23: warning: explicitly assigning value of
variable of type 'unsigned int' to itself [-Wself-assign]

Duplicate.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
Is libgfortran built with -O2 -funroll-loops or with -O3 (IIRC -O3?).  Note we
see

Estimating sizes for loop 3
 BB: 14, after_exit: 0
  size:   1 _20 = count[n_95];
  size:   1 _21 = _20 + 1;
  size:   1 count[n_95] = _21;
  size:   1 _22 = stride[n_95];
  size:   0 _23 = (long unsigned int) _22;
  size:   1 _44 = _23 - _82;
  size:   1 _45 = _44 * 4;
  size:   1 src_62 = src_85 + _45;
  size:   1 _25 = extent[n_95];
  size:   2 if (_21 == _25)
 BB: 20, after_exit: 1
 BB: 13, after_exit: 0
  size:   1 count[n_95] = 0;
  size:   1 _18 = _22 * _25;
  size:   0 _19 = (long unsigned int) _18;
  size:   1 n_60 = n_95 + 1;
   Induction variable computation will be folded away.
  size:   2 if (dim_43 == n_60)
   Exit condition will be eliminated in last copy.
size: 15-1, last_iteration: 15-3
  Loop size: 15
  Estimated size after unrolling: 129
Making edge 13->20 impossible by redistributing probability to other edges.
../../../trunk/libgfortran/generated/in_pack_i4.c:100:14: optimized: loop with
13 iterations completely unrolled (header execution count 23565294)
Last iteration exit edge was proved true.

Note even with the rs6000 limits turned back to default I see the loop
unrolled (with -O3 or -O2 -funroll-loops).

Checking on x86_64 the file is compiled with -O2 only and we have

size: 17-1, last_iteration: 10-3
  Loop size: 17
  Estimated size after unrolling: 154
Not unrolling loop 3: size would grow.

so what's the speciality on POWER?  Code growth should trigger with -O3 only.
Given we have only a guessed profile (and that does not detect the inner
loop as completely cold) we're allowing growth then.  GCC has no idea the
outer loop iterates more than the inner.

Note re-structuring the loop to use down-counting count[] from extent[] to zero
would be worth experimenting with, likewise "peeling" the dim == 0 loop
and not making the outermost loop key on 'src' (can 'src' be NULL on entry?).

Anyway, completely peeling this loop looks useless - the only benefit
might be better branch prediction (each dimension gets its own entry
in the predictor cache).

If POWER cannot cope with large loops then I wonder why POWER people
increased limits (though even the default limits would unroll the loop).

Thomas - where did you measure the slowness?  For which dimensionality?
I'm quite sure the loop structure will be sub-optimal for certain
input shapes... (stride0 == 1 could even use memcpy for the inner dimension).

[Bug target/95076] New: Failure to optimize out stack alignment on function call of different type

[gabravier at gmail dot com]

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

Bug ID: 95076
   Summary: Failure to optimize out stack alignment on function
call of different type
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

long long f();

int g()
{
return f();
}

With -O3, LLVM outputs :

g(): # @g()
  jmp f() # TAILCALL

GCC outputs : 

g():
  sub rsp, 8
  call f()
  add rsp, 8
  ret

[Bug rtl-optimization/12345] [3.4 Regression] internal compiler error: verify_flow_info failed

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=a62236b9d579315a0482cdd6deb409f76381c233

commit r10-5848-ga62236b9d579315a0482cdd6deb409f76381c233
Author: Martin Liska 
Date:   Tue May 12 09:25:54 2020 +0200

Just test it.

gcc/ChangeLog:

2020-05-12  Martin Liska  

PR ipa/12345
* tree-vrp.c: Done.
* tree.c: Done.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Biener  ---
(In reply to Jiu Fu Guo from comment #18)
> Currently, I'm thinking to enhance GCC 'cunroll' as:
> if the loop has multi-exits or upbound is not a fixed number, we may not do
> 'complete unroll' for the loop, except -funroll-all-loops is specified.

That doens't make much sense (-funroll-all-loops is RTL unroller only).

I think the growth limits are simply too large unless we compute a "win"
which we in this case do not.  So I'd say the growth limits should scale
with win ^ (1/new param) thus if we estimate to eliminate 20% of the
loop stmts due to unrolling then the limit to apply is
limit * (0.2 ^ (1/X)) with X maybe defaulting to 2.

I'd only apply this new limit for peeling (peeling is when the loop count
is not constant and thus we keep the exit tests).

Of course people want more peeling (hello POWER people!)

[Bug debug/95077] New: Wrong backtrace infromation at O1

[massarelli at diag dot uniroma1.it]

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

Bug ID: 95077
   Summary: Wrong backtrace infromation at O1
   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: ---

At line 14 it seems that backtrace information is wrong (pointing at function
dm).

$ cat a.c
static int a, c, d, e;
static void dm() {
  int b = 0;
  for (; b < 56; b++)
a = b;
}
int main() {
  int k;
  dm();
  d = 0;
  for (; d != 38; d = d + 1)
e = 0;
  for (; e < 3; e++)
for (k = 0; k < 4; k++)
  printf("", c);
}

$ 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 20200511 (experimental) (GCC) 


$ lldb -v
lldb version 11.0.0
  clang revision c25b20c0f6c13d68dbc2e185764082d61ae4a132
  llvm revision c25b20c0f6c13d68dbc2e185764082d61ae4a132

$ gdb -v
GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git

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

$ lldb opt 
(lldb) target create "opt"
Current executable set to 'opt' (x86_64).
(lldb) b -l 14
Breakpoint 1: 2 locations.
(lldb) r
Process 172 launched: opt' (x86_64)
Process 172 stopped
* thread #1, name = 'opt', stop reason = breakpoint 1.1
frame #0: 0x00400531 opt`main at a.c:14:17
   11 for (; d != 38; d = d + 1)
   12   e = 0;
   13 for (; e < 3; e++)
-> 14   for (k = 0; k < 4; k++)
   15 printf("", c);
   16   }
(lldb) bt
* thread #1, name = 'opt', stop reason = breakpoint 1.1
  * frame #0: 0x00400531 opt`main at a.c:14:17
frame #1: 0x00400531 opt`main at a.c:9
frame #2: 0x77a05b97 libc.so.6`__libc_start_main(main=(opt`main at
a.c:7:12), argc=1, argv=0x7fffe5b8, init=,
fini=, rtld_fini=, stack_end=0x7fffe5a8) at
libc-start.c:310
frame #3: 0x0040043a opt`_start + 42
(lldb) 

$ gdb opt
Reading symbols from opt...done.
(gdb) b -l 14
Breakpoint 1 at 0x400531: -source a.c -line 14. (2 locations)
(gdb) r
Starting program: opt 
Breakpoint 1, main () at a.c:9
9 dm();
(gdb) s
dm () at a.c:14
14  for (k = 0; k < 4; k++)
(gdb)

[Bug c++/95073] Add "did you mean" when fn declaration could be found via ADL

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-12

[Bug target/94980] [8/9/10/11 Regression] ICE: verify_gimple failed: position plus size exceeds size of referenced object in 'bit_field_ref' with -mavx512vl

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-311-gd17a896da1e898928d337596d029f0ece0039d55
Author: Richard Sandiford 
Date:   Tue May 12 09:01:10 2020 +0100

tree: Add vector_element_bits(_tree) [PR94980 1/3]

A lot of code that wants to know the number of bits in a vector
element gets that information from the element's TYPE_SIZE,
which is always equal to TYPE_SIZE_UNIT * BITS_PER_UNIT.
This doesn't work for SVE and AVX512-style packed boolean vectors,
where several elements can occupy a single byte.

This patch introduces a new pair of helpers for getting the true
(possibly sub-byte) size.  I made a token attempt to convert obvious
element size calculations, but I'm sure I missed some.

2020-05-12  Richard Sandiford  

gcc/
PR tree-optimization/94980
* tree.h (vector_element_bits, vector_element_bits_tree): Declare.
* tree.c (vector_element_bits, vector_element_bits_tree): New.
* match.pd: Use the new functions instead of determining the
vector element size directly from TYPE_SIZE(_UNIT).
* tree-vect-data-refs.c (vect_gather_scatter_fn_p): Likewise.
* tree-vect-patterns.c (vect_recog_mask_conversion_pattern):
Likewise.
* tree-vect-stmts.c (vect_is_simple_cond): Likewise.
* tree-vect-generic.c (expand_vector_piecewise): Likewise.
(expand_vector_conversion): Likewise.
(expand_vector_addition): Likewise for a TYPE_SIZE_UNIT used as
a divisor.  Convert the dividend to bits to compensate.
* tree-vect-loop.c (vectorizable_live_operation): Call
vector_element_bits instead of open-coding it.

[Bug target/94980] [8/9/10/11 Regression] ICE: verify_gimple failed: position plus size exceeds size of referenced object in 'bit_field_ref' with -mavx512vl

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:14605b6bd8c37fffd8065c5c3fe6b1b9d7b2a294

commit r11-312-g14605b6bd8c37fffd8065c5c3fe6b1b9d7b2a294
Author: Richard Sandiford 
Date:   Tue May 12 09:01:12 2020 +0100

tree-vect-generic: Tweak build_replicated_const [PR94980 2/3]

This patch makes build_replicated_const take the number of bits
in VALUE rather than calculating the width from the element type.
The callers can then use vector_element_bits to calculate the
correct element size from the vector type.

2020-05-12  Richard Sandiford  

gcc/
PR tree-optimization/94980
* tree-vect-generic.c (build_replicated_const): Take the number
of bits as a parameter, instead of the type of the elements.
(do_plus_minus): Update accordingly, using vector_element_bits
to calculate the correct number of bits.
(do_negate): Likewise.

[Bug target/94980] [8/9/10/11 Regression] ICE: verify_gimple failed: position plus size exceeds size of referenced object in 'bit_field_ref' with -mavx512vl

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:4c0283b9ad75b128b79c507d78d678123fe9f471

commit r11-313-g4c0283b9ad75b128b79c507d78d678123fe9f471
Author: Richard Sandiford 
Date:   Tue May 12 09:01:13 2020 +0100

tree-vect-generic: Fix bitfield widths [PR94980 3/3]

This third patch of three actually fixes the PR.  We were using
8-bit BIT_FIELD_REFs to access single-bit elements, and multiplying
the vector index by 8 bits rather than 1 bit.

2020-05-12  Richard Sandiford  

gcc/
PR tree-optimization/94980
* tree-vect-generic.c (expand_vector_comparison): Use
vector_element_bits_tree to get the element size in bits,
rather than using TYPE_SIZE.
(expand_vector_condition, vector_element): Likewise.

gcc/testsuite/
PR tree-optimization/94980
* gcc.target/i386/pr94980.c: New test.

[Bug libstdc++/93244] std::filesystem::path::generic_string doesn't convert the first slash on Windows

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=af213b4c4ca30e55de64f8b1e0bf442df08f3e6d

commit r10-5851-gaf213b4c4ca30e55de64f8b1e0bf442df08f3e6d
Author: Jonathan Wakely 
Date:   Mon Jan 13 10:02:39 2020 +

libstdc++: Ensure root-dir converted to forward slash (PR93244)

PR libstdc++/93244
* include/bits/fs_path.h (path::generic_string)
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Convert root-dir to
forward-slash.
* testsuite/27_io/filesystem/path/generic/generic_string.cc: Check
root-dir is converted to forward slash in generic pathname.
* testsuite/27_io/filesystem/path/generic/utf.cc: New test.
* testsuite/27_io/filesystem/path/generic/wchar_t.cc: New test.

[Bug ipa/93223] [9/10 Regression] ICE in devirtualization_time_bonus at gcc/ipa-cp.c:3161 since r261744

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=8a37df5e5cb2de8302f9412173103593ec53961e

commit r10-5852-g8a37df5e5cb2de8302f9412173103593ec53961e
Author: Martin Jambor 
Date:   Mon Jan 13 19:13:46 2020 +0100

IPA: Avoid segfault in devirtualization_time_bonus (PR 93223)

2020-01-13  Martin Jambor  

PR ipa/93223
* ipa-cp.c (devirtualization_time_bonus): Check whether isummary is
NULL.

testsuite/
* g++.dg/ipa/pr93223.C: New test.

[Bug target/94980] [8/9/10/11 Regression] ICE: verify_gimple failed: position plus size exceeds size of referenced object in 'bit_field_ref' with -mavx512vl

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Fixed on master.  As mentioned on-list, GCC 7 generated wrong code
instead of ICEing, and there's a danger GCC 8+ could regress to that
in other cases if we backported the patches.  So instead it seems
more appropriate to leave the branches alone for now and perhaps
revisit if a real-world test case comes along.  We might by that
time have found more places that need similar fixes.

[Bug c++/95063] [11 Regression] ICE in tsubst_decl, at cp/pt.c:14633

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:99b0c9ec47d563d1f780cb678c04d37c9835440f

commit r11-314-g99b0c9ec47d563d1f780cb678c04d37c9835440f
Author: Jakub Jelinek 
Date:   Tue May 12 10:00:32 2020 +0200

openmp: Fix up handling of DECL_OMP_PRIVATIZED_MEMBER for bit-fields
[PR95063]

The r11-15 change broke this testcase, as it now asserts type is equal to
the type of the DECL_VALUE_EXPR, but for DECL_OMP_PRIVATIZED_MEMBER
artificial
vars mapping to bitfields it wasn't.  Fixed by changing the
DECL_OMP_PRIVATIZED_MEMBER var type in that case.

2020-05-12  Jakub Jelinek  

PR c++/95063
* pt.c (tsubst_decl): Deal with DECL_OMP_PRIVATIZED_MEMBER for
a bit-field.

* g++.dg/gomp/pr95063.C: New test.

[Bug libstdc++/93244] std::filesystem::path::generic_string doesn't convert the first slash on Windows

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška  ---
(In reply to CVS Commits from comment #13)
> The master branch has been updated by Martin Liska :
> 
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;
> h=af213b4c4ca30e55de64f8b1e0bf442df08f3e6d
> 
> commit r10-5851-gaf213b4c4ca30e55de64f8b1e0bf442df08f3e6d
> Author: Jonathan Wakely 
> Date:   Mon Jan 13 10:02:39 2020 +
> 
> libstdc++: Ensure root-dir converted to forward slash (PR93244)
> 
> PR libstdc++/93244
> * include/bits/fs_path.h (path::generic_string)
> [_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Convert root-dir to
> forward-slash.
> * testsuite/27_io/filesystem/path/generic/generic_string.cc:
> Check
> root-dir is converted to forward slash in generic pathname.
> * testsuite/27_io/filesystem/path/generic/utf.cc: New test.
> * testsuite/27_io/filesystem/path/generic/wchar_t.cc: New test.

Please ignore this message, it comes from a testing script.

[Bug ipa/93223] [9/10 Regression] ICE in devirtualization_time_bonus at gcc/ipa-cp.c:3161 since r261744

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #7 from Martin Liška  ---
(In reply to CVS Commits from comment #6)
> The master branch has been updated by Martin Liska :
> 
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;
> h=8a37df5e5cb2de8302f9412173103593ec53961e
> 
> commit r10-5852-g8a37df5e5cb2de8302f9412173103593ec53961e
> Author: Martin Jambor 
> Date:   Mon Jan 13 19:13:46 2020 +0100
> 
> IPA: Avoid segfault in devirtualization_time_bonus (PR 93223)
> 
> 2020-01-13  Martin Jambor  
> 
> PR ipa/93223
> * ipa-cp.c (devirtualization_time_bonus): Check whether isummary
> is
> NULL.
> 
> testsuite/
> * g++.dg/ipa/pr93223.C: New test.

Please ignore this message, it comes from a testing script.

[Bug sanitizer/95033] [11 Regression] ICE in set_parm_rtl, at cfgexpand.c:1310 since r11-165-geb72dc663e9070b2

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-315-g6b41920bd5c68998a53de749b4fe5c0b8875db6c
Author: Martin Liska 
Date:   Tue May 12 10:23:09 2020 +0200

ASAN: clear DECL_NOT_GIMPLE_REG_P.

PR sanitizer/95033
PR sanitizer/95051
* sanopt.c (sanitize_rewrite_addressable_params):
Clear DECL_NOT_GIMPLE_REG_P for argument.
PR sanitizer/95033
PR sanitizer/95051
* g++.dg/asan/function-argument-4.C: New test.
* gcc.dg/asan/pr95033.c: New test.
* gcc.dg/asan/pr95051.c: New test.

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

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-315-g6b41920bd5c68998a53de749b4fe5c0b8875db6c
Author: Martin Liska 
Date:   Tue May 12 10:23:09 2020 +0200

ASAN: clear DECL_NOT_GIMPLE_REG_P.

PR sanitizer/95033
PR sanitizer/95051
* sanopt.c (sanitize_rewrite_addressable_params):
Clear DECL_NOT_GIMPLE_REG_P for argument.
PR sanitizer/95033
PR sanitizer/95051
* g++.dg/asan/function-argument-4.C: New test.
* gcc.dg/asan/pr95033.c: New test.
* gcc.dg/asan/pr95051.c: New test.

[Bug sanitizer/95033] [11 Regression] ICE in set_parm_rtl, at cfgexpand.c:1310 since r11-165-geb72dc663e9070b2

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

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

[marxin at gcc dot gnu.org]

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

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

   What|Removed |Added

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

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed now.

[Bug c++/95073] Add "did you mean" when fn declaration could be found via ADL

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This part is still useful, to show the one that *was* found, but couldn't be
called:

q.C:9:15: note: declared here
9 |   extern void f();
  |   ^


If that is replaced then it's not clear why "expected 0" would be true, and why
N::f wasn't found by ADL. It might also be helpful to explain that a block
scope function declaration suppresses ADL.

So maybe keep the current diagnostic unchanged, but then add a new note after
it?

q.C: In function ‘void g()’:
q.C:11:6: error: too many arguments to function ‘void f()’
   11 |   f(x);
  |  ^
q.C:9:15: note: declared here
9 |   extern void f();
  |   ^
q.C:11:3: note: block-scope function declaration prevents argument dependent
lookup for unqualified name; did you mean 'N::f'?
  f(x);
  ^
  N::f
q.C:3:8: note: 'N::f' declared here
  void f(X);
   ^


It might be better to say "local" instead of "block-scope" (not strictly
correct, but more likely to be understood by users).

[Bug libstdc++/84766] __verbose_terminate_handler mistakes parallel unhandled exceptions for recursive std::terminate() calls

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I don't think we want to use another TLS entry just for this handler, so I'm
leaning towards the nice suggestion to say "reentrant" instead.

[Bug c++/95074] Function found via ADL when it should not

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-12
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug libstdc++/94906] memory corruption in std::pmr::monotonic_buffer_resource

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8136-gdc103060c18656affaecfdd57faa4e0237dadcd3
Author: Jonathan Wakely 
Date:   Tue May 12 09:54:44 2020 +0100

libstdc++: Fix incorrect size calculation in PMR resource  (PR 94906)

Calculating the size of a chunk being returned to the upstream allocator
was done with a 32-bit type, so it wrapped if the chunk was 4GB or
larger.

I don't know how to test this without allocating 4GB, so there's no test
in the testsuite. It has been tested manually of course.

Backport from mainline
2020-05-04  Jonathan Wakely  

PR libstdc++/94906
* src/c++17/memory_resource.cc
(monotonic_buffer_resource::_Chunk::release): Use size_t for shift
operands.

[Bug libstdc++/94933] std::fill_n delegates to __builtin_memset which is not constexpr

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:8836c35d5d6fefa514cb78cb6800670869fb1df2

commit r10-8135-g8836c35d5d6fefa514cb78cb6800670869fb1df2
Author: Jonathan Wakely 
Date:   Tue May 12 09:54:24 2020 +0100

libstdc++: Make byte-sized std::fill_n a constant expression (PR 94933)

The overload for byte types uses memset and isn't constexpr. This adds
the specifier and uses std::is_constant_evaluated() to provide a
compile-time alternative.

Backport from mainline
2020-05-03  Jonathan Wakely  

PR libstdc++/94933
* include/bits/stl_algobase.h (__fill_a1): Make overload for byte
types
usable in constant expressions.
* testsuite/25_algorithms/fill_n/constexpr.cc: Test with bytes and
non-scalars.

[Bug c++/77892] local function declarations don't match namespace scope declarations

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |9.0
 Status|NEW |RESOLVED
  Known to fail||5.5.0, 6.4.0, 7.3.0, 8.1.0
  Known to work||6.5.0, 7.4.0, 8.2.0
   Keywords|rejects-valid   |link-failure

--- Comment #2 from Jonathan Wakely  ---
Fixed for 6.5, 7.4, 8.2 and later, by r262678 for PR c++/86208

[Bug target/95078] New: Missing fwprop for SIB address

[crazylht at gmail dot com]

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

Bug ID: 95078
   Summary: Missing fwprop for SIB address
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i386, x86-64

cat test.c

int foo (int* p1, int* p2, int scale)
{
int ret = *(p1 + scale * 4 + 11);
*p2 = 3;
int ret2 = *(p1 + scale * 4 + 11);
return ret + ret2;
}

gcc11 -O2 test.c -S 

foo(int*, int*, int):
sall$2, %edx
movslq  %edx, %rdx
leaq44(%rdi,%rdx,4), %rdx  --- redundant could be fwprop
movl(%rdx), %eax
movl$3, (%rsi)
addl(%rdx), %eax
ret

fwprop failed to propagate this because it think cost of address
44(%rdi,%rdx,4) is more expensive than (%rdx), that's correct locally, but
under global view, if it could be propagated into both movl, leaq would be
eliminated, which benifits performance.

The ideal place to handle this issue is TER opt in pass_expand, but currently
TER only handle simple situation  single use and block level

 48   A pass is made through the function, one block at a time.  No cross block 
 49   information is tracked.   
 50 
 51   Variables which only have one use, and whose defining stmt is considered  
 52   a replaceable expression (see ssa_is_replaceable_p) are tracked to see
whether 
 53   they can be replaced at their use location.   

Should TER be extended?

Another testcase has this issue in more complex cfg

Refer to
https://godbolt.org/z/ofjH9R

[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 #21 from Thomas Koenig  ---
(In reply to Richard Biener from comment #19)
> Is libgfortran built with -O2 -funroll-loops or with -O3 (IIRC -O3?). 

Just plain -O2 (for size reasons), with matmul as an exception
where we add -funroll-loops and other optoins.

> so what's the speciality on POWER?  Code growth should trigger with -O3 only.
> Given we have only a guessed profile (and that does not detect the inner
> loop as completely cold) we're allowing growth then.  GCC has no idea the
> outer loop iterates more than the inner.

As a test, I changed the condition of the loop in question to

@@ -88,7 +88,7 @@ internal_pack_r4 (gfc_array_r4 * source)
   count[0]++;
   /* Advance to the next source element.  */
   index_type n = 0;
-  while (count[n] == extent[n])
+  while (unlikely (count[n] == extent[n]))
 {
   /* When we get to the end of a dimension, reset it and increment
  the next dimension.  */

which then results in

   while (__builtin_expect(!!(count[n] == extent[n]), 0))

and the loop is still completely peeled on POWER at -O2, which
I do not understand.

> Thomas - where did you measure the slowness?  For which dimensionality?

Actually, I didn't, I just made an assumption that it would be
bad for speed as well.  The tests that I ran then didn't show any
such slowdown, so I guess the POWER9 branch predictor is doing
a good job here.

However, this kind of loop is the standard way of accessing multi-
dimensional arrays of unknown dimension in libgfortran. It occurs
in around 400 files there, sometimes more than once, so the size issue
is significant.  I haven't checked if there is an actual degradation
for other use cases. 

> I'm quite sure the loop structure will be sub-optimal for certain
> input shapes... (stride0 == 1 could even use memcpy for the inner dimension).

Yes. I plan to revisit this when looking at PR 93114, where I have
to touch that part of the code anyway.

[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 #22 from Thomas Koenig  ---
Here are the details of how I tested this.

I generated the in_pack_r4.i and in_unpack_r4.i by adding -save-temps to the
Makefile options in ~/trunk-bin/powerpc64le-unknown-linux-gnu/libgfortran ,
then removing in_pack_r4.* and in_unpack_r4.* there and running make.

In the benchmark directory, I then used

bench.f90:

program main
  real, dimension(:,:), allocatable :: a
  allocate (a(5,4))
  call random_number (a)
  do i=1,500
 call foo(a(i::2,:))
 call foo(a)
  end do
end program main

foo.f90:

subroutine foo(a)
  real, dimension(*) :: a
end subroutine foo

(constants can be adjusted).  The first call to foo needs a repacking,
the second one is just to confuse the optimizer not to exit the loop.

With the command line

gfortran -g -fno-inline-arg-packing  -O2 bench.f90 foo.f90  in_pack_r4.i
in_unpack_r4.i -static-libgfortran && time ./a.out

a test can be run. -fno-inline-arg-repacking is important because
otherwise the internal packing routines will not be called, and
putting in in_pack_r4.i and in_unpack_r4.i will use those instead
of the ones from the (static) library.

in_pack_r4.i and in_unpack_r4.i can then be adjusted, for
exmaple by adding a #pragma GCC unroll 1.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #23 from Richard Biener  ---
(In reply to Richard Biener from comment #20)
> (In reply to Jiu Fu Guo from comment #18)
> > Currently, I'm thinking to enhance GCC 'cunroll' as:
> > if the loop has multi-exits or upbound is not a fixed number, we may not do
> > 'complete unroll' for the loop, except -funroll-all-loops is specified.
> 
> That doens't make much sense (-funroll-all-loops is RTL unroller only).
> 
> I think the growth limits are simply too large unless we compute a "win"
> which we in this case do not.  So I'd say the growth limits should scale
> with win ^ (1/new param) thus if we estimate to eliminate 20% of the
> loop stmts due to unrolling then the limit to apply is
> limit * (0.2 ^ (1/X)) with X maybe defaulting to 2.
> 
> I'd only apply this new limit for peeling (peeling is when the loop count
> is not constant and thus we keep the exit tests).
> 
> Of course people want more peeling (hello POWER people!)

Btw, the issue with the rs6000 code at present is that it uses
unroll_only_small_loops but that only affects the RTL unroller
while the enablement of -funroll-loops at -O2 affects GIMPLE
as well but unconstrained (with -O3 params).  For the main
unroll pass (not cunrolli) this triggers code size growth:

  unsigned int val = tree_unroll_loops_completely (flag_unroll_loops
   || flag_peel_loops
   || optimize >= 3, true);

the "original" patch also adjusted parameters.  If the intent is to only
affect the RTL unroller then we need a separate flag controlling it
(yeah, using the same flags as heuristic trigger was probably bad).

[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 #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Tobias Burnus
:

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

commit r10-8137-g8aeffc4c9f47dd09ccc6a82d9fae35931414eb4d
Author: Tobias Burnus 
Date:   Tue May 12 12:07:39 2020 +0200

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

gcc/fortran/
2020-05-12  Tobias Burnus  

Backported from mainline
2020-05-11  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-12  Tobias Burnus  

Backported from mainline
2020-05-11  Jakub Jelinek  
Tobias Burnus  

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

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

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #10 from Tobias Burnus  ---
FIXED.

Thanks for the bug report!

[Bug tree-optimization/95060] vfnmsub132ps is not generated with -ffast-math

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 48515
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48515&action=edit
gcc11-pr95060.patch

Untested fix.

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

[rguenther at suse dot de]

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

--- Comment #24 from rguenther at suse dot de  ---
On Tue, 12 May 2020, tkoenig at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
> 
> --- Comment #21 from Thomas Koenig  ---
> (In reply to Richard Biener from comment #19)
> > Is libgfortran built with -O2 -funroll-loops or with -O3 (IIRC -O3?). 
> 
> Just plain -O2 (for size reasons), with matmul as an exception
> where we add -funroll-loops and other optoins.
> 
> > so what's the speciality on POWER?  Code growth should trigger with -O3 
> > only.
> > Given we have only a guessed profile (and that does not detect the inner
> > loop as completely cold) we're allowing growth then.  GCC has no idea the
> > outer loop iterates more than the inner.
> 
> As a test, I changed the condition of the loop in question to
> 
> @@ -88,7 +88,7 @@ internal_pack_r4 (gfc_array_r4 * source)
>count[0]++;
>/* Advance to the next source element.  */
>index_type n = 0;
> -  while (count[n] == extent[n])
> +  while (unlikely (count[n] == extent[n]))
>  {
>/* When we get to the end of a dimension, reset it and increment
>   the next dimension.  */
> 
> which then results in
> 
>while (__builtin_expect(!!(count[n] == extent[n]), 0))
> 
> and the loop is still completely peeled on POWER at -O2, which
> I do not understand.

We end up with a 90% vs. 10% probability:

;;succ:   13 [10.0% (guessed)]  count:4740826 (estimated locally) 
(TRUE_VALUE,EXECUTABLE)
;;15 [90.0% (guessed)]  count:42667438 (estimated locally) 
(FALSE_VALUE,EXECUTABLE)

...

;;   basic block 13, loop depth 2, count 4740826 (estimated locally), 
maybe hot

which is still maybe hot :/  There is now 
__builtin_expect_with_probability, but I wonder why we end up
with a maybe-hot count regardless of the __builtin_expect.

Using

__builtin_expect_with_probability (!!(count[n] == extent[n]), 0, 1)

makes it assumed to be never executed but as soon as I use
__builtin_expect_with_probability basic block counts all end up
zero!?

Honza?

[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

Michael Kuhn  changed:

   What|Removed |Added

  Attachment #48482|0   |1
is obsolete||

--- Comment #5 from Michael Kuhn  ---
Created attachment 48516
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48516&action=edit
Updated zstd patch

Thanks for investigating! Sadly, this still does not work for me, even with
master.
If I do "make lto-compress.o" in the gcc subdirectory, it works (and includes
the include path), but a normal "make" in the build directory does not.

In Spack, another issue has come up: When building with Clang (as frequently
done on macOS), libzstd cannot be found. After some investigation, it seems
that the library path is also not set correctly.

I have come up with the attached updated patch that allows me build GCC with
zstd in a non-standard path. It is also a bit cleaner than the previous
approach.

[Bug libstdc++/95079] New: unorderd_map::insert_or_assign and try_emplace should only hash and mod once unless there is a rehash.

[redbeard0531 at gmail dot com]

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

Bug ID: 95079
   Summary: unorderd_map::insert_or_assign and try_emplace should
only hash and mod once unless there is a rehash.
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

Currently insert_or_assign() and try_emplace() call find(key) and fall back to
emplace(...) if that fails to find the key. The computed hash (and more
importantly in general) the modded bucket index computed by find() is thrown
away and recomputed by emplace(). Instead they should compute the hash once,
and unless there is a rehash, also only do the modulus once. This optimization
is already performed for operator[].

https://godbolt.org/z/cw82RC shows that the hasher is invoked once for
operator[] and twice for insert_or_assign().
http://quick-bench.com/ge8Suq7PcdRKm6IBQbjvwuXhW6Y shows that there is a
significant performance difference (20% in this test).

(I know std::unordered_map is always going to be less than fast on 64-bit
platforms, but it doesn't need to be slower than it needs to be...)

[Bug analyzer/94689] arrays of functions are not meaningful

[pmatos at gcc dot gnu.org]

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

--- Comment #4 from pmatos at gcc dot gnu.org ---
Unfortunately a fix for this didn't make it into 10.1. We can still not analyze
racket source code due to this issue.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:90aea3e8d4f6119a9b666275b274bc4c251a7c91

commit r11-317-g90aea3e8d4f6119a9b666275b274bc4c251a7c91
Author: Eric Botcazou 
Date:   Tue May 12 13:14:20 2020 +0200

Fix incorrect scalar storage order handling

This fixes an oversight in the new canonicalization code for packable
types: it does not take into account the scalar storage order.

PR ada/95035
* gcc-interface/utils.c (packable_type_hasher::equal): Also compare
the scalar storage order.
(hash_packable_type): Also hash the scalar storage order.
(hash_pad_type): Likewise.

[Bug debug/95080] New: [10/11 Regression] -fcompare-debug failure (length) with -Og -fcse-follow-jumps -fnon-call-exceptions

[zsojka at seznam dot cz]

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

Bug ID: 95080
   Summary: [10/11 Regression] -fcompare-debug failure (length)
with -Og -fcse-follow-jumps -fnon-call-exceptions
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-g++ -Og -fcse-follow-jumps -fnon-call-exceptions
-fcompare-debug testcase.C
x86_64-pc-linux-gnu-g++: error: testcase.C: '-fcompare-debug' failure (length)

$ diff -u testcase.gkd testcase.gk.gkd 
--- testcase.gkd2020-05-12 13:14:06.626740964 +0200
+++ testcase.gk.gkd 2020-05-12 13:14:06.716740965 +0200
@@ -51,12 +51,10 @@
 (reg:DI 5 di [93]))# {*movdi_internal}
  (expr_list:REG_DEAD (reg:DI 5 di [93])
 (nil)))
-(insn # 0 0 4 (set (reg:QI 0 ax [orig:86 _11 ] [86])
-(const_int 0 [0])) "testcase.C":8:14# {*movqi_internal}
+(insn # 0 0 4 (set (reg:QI 0 ax [orig:89 _14 ] [89])
+(const_int 0 [0])) "testcase.C":15:14# {*movqi_internal}
  (expr_list:REG_EQUIV (const_int 0 [0])
-(expr_list:REG_EH_REGION (const_int -1 [0x])
-(nil
-(note # 0 0 NOTE_INSN_DELETED)
+(nil)))
 (insn # 0 0 4 (set (reg:CCZ 17 flags)
 (compare:CCZ (reg:QI 0 ax [orig:89 _14 ] [89])
 (const_int 0 [0]))) "testcase.C":22:3# {*cmpqi_ccno_1}

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

[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

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

--- Comment #4 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug debug/95080] [10/11 Regression] -fcompare-debug failure (length) with -Og -fcse-follow-jumps -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.2

[Bug libstdc++/95079] unorderd_map::insert_or_assign and try_emplace should only hash and mod once unless there is a rehash.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-12

--- Comment #1 from Jonathan Wakely  ---
Agreed, thanks for the analysis.

[Bug c++/95081] New: Copyright infringement by ROS2

[pacoarjonilla at yahoo dot es]

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

Bug ID: 95081
   Summary: Copyright infringement by ROS2
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pacoarjonilla at yahoo dot es
  Target Milestone: ---

Created attachment 48518
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48518&action=edit
Infringing source file

Please excuse me if this is not the right place to post this notice.

ROS2 (Robot Operating System) by Open Robotics has infringed copyright of GCC
standard library. At least, they have copied portions of stl_vector.h of the
C++ component of GCC, without crediting the authors and replacing the GPL
license with the Apache license. Here is the modified file:

https://github.com/ros2/rosidl/blob/master/rosidl_runtime_cpp/include/rosidl_runtime_cpp/bounded_vector.hpp

Commit f25db23d093ea075f8bbb0015597b091400889e2 of the rosidl project.

[Bug c/84685] Designated initializers warning

[chrubis at suse dot cz]

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

Cyril Hrubis  changed:

   What|Removed |Added

 CC||chrubis at suse dot cz

--- Comment #4 from Cyril Hrubis  ---
Created attachment 48519
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48519&action=edit
Simplified reproducer.

I got a plenty of these useless warnings as well for LTP
https://github.com/linux-test-project/ltp.

It also looks like the warning is not printed in the compound literal is last
in the structure. In my case swapping struct bar *b and int a silences the
warning.

[Bug libstdc++/94933] std::fill_n delegates to __builtin_memset which is not constexpr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed for 10.2

[Bug target/95078] Missing fwprop for SIB address

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
TER should go away, not be extended.  So you are suggesting that we replace

leaq44(%rdi,%rdx,4), %rdx  --- redundant could be fwprop
movl(%rdx), %eax
movl$3, (%rsi)
addl(%rdx), %eax

with

movl   44(%rdi,%rdx,4), %eax
movl$3, (%rsi)
addl   44(%rdi,%rdx,4), %eax

?  The variant that looks bigger is actually one byte smaller.  Note as
soon as there are three uses it will be larger again...

So this is really something for RTL and yeah, fwprop only makes "local"
decisions.  Note that I think that your proposed variant will consume
more resources since the complex addressing modes are likely split into
a separate uop.  Yes, overall I'd expect less latency for your sequence.

[Bug c++/95081] Copyright infringement by ROS2

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-12
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
You've attached an HTML file, not source code.

I don't see the copied code, which parts of the file are taken from GCC?

[Bug debug/95077] Wrong backtrace infromation at O1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||9.3.1
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-12

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

[Bug c++/95081] Copyright infringement by ROS2

[pacoarjonilla at yahoo dot es]

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

Paco Arjonilla  changed:

   What|Removed |Added

  Attachment #48518|0   |1
is obsolete||

--- Comment #2 from Paco Arjonilla  ---
Created attachment 48520
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48520&action=edit
Really infringing source code

Sorry for the html file.

If you compare the attached file with stl_vector.h, you can clearly see that
the code is derived from GCC: They have only kept the vector class, rename
vector to BoundedVector, and made the member function modifications to suit
their needs. The identifier naming is the same, the syntax has been kept, most
of the comments remain in the copied portions.

[Bug c++/94924] Default equality operator for C-array compares addresses, not data

[rhalbersma at gmail dot com]

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

--- Comment #1 from rhalbersma  ---
I just became aware of [depr.array.comp] in N4861

"Equality and relational comparisons (7.6.10, 7.6.9) between two operands of
array type are deprecated."

This is very surprising to say the least and disqualifies default op= for any
class containing a C-array. 

But in any case, should such code generate a warning message? And this bug be
closed?

[Bug middle-end/94988] [11 Regression] FAIL: gcc.target/i386/pr64110.c scan-assembler vmovd[\\t ]

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 CC||ro at gcc dot gnu.org
 Status|RESOLVED|REOPENED

--- Comment #5 from Rainer Orth  ---
One new testcase FAILs on several targets:

+FAIL: gcc.dg/torture/pr94988.c   -O0  execution test
+FAIL: gcc.dg/torture/pr94988.c   -O1  execution test
+FAIL: gcc.dg/torture/pr94988.c   -O2  execution test
+FAIL: gcc.dg/torture/pr94988.c   -O2 -flto  execution test
+FAIL: gcc.dg/torture/pr94988.c   -O2 -flto -flto-partition=none  execution
test
+FAIL: gcc.dg/torture/pr94988.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
+FAIL: gcc.dg/torture/pr94988.c   -O3 -g  execution test
+FAIL: gcc.dg/torture/pr94988.c   -Os  execution test

I'm seeing it on 32 and 64-bit sparc-sun-solaris2.11, and there are also
reports
for moxie-unknown-elf, powerpc64-unknown-linux-gnu, s390x-ibm-linux-gnu, all
big-endian targets AFAICS.

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

[ro at gcc dot gnu.org]

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

Bug 94988 Summary: [11 Regression] FAIL: gcc.target/i386/pr64110.c 
scan-assembler vmovd[\\t ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94988

   What|Removed |Added

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

[Bug target/95076] Failure to tail-call on function call of different return type

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|Failure to optimize out |Failure to tail-call on
   |stack alignment on function |function call of different
   |call of different type on   |return type
   |x86 |
 CC||hjl.tools at gmail dot com
 Target||x86_64-*-* i?86-*-*

--- Comment #1 from Richard Biener  ---
GCC doesn't tail-call because the return types are not compatible.  With a call
it cannot optimize the stack adjustment because of the ABI.

Note I'm not sure whether the ABI allows %rax to contain "garbage" in the
upper half for a function returning in %eax.  So what LLVM does may be wrong.

[Bug target/95032] [11 Regression] ICE in extract_insn, at recog.c:2294 since r11-187-g98329e3f5b85acc50d

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
Ah.  I couldn't reproduce this, but I used -mcpu=future.

Please don't use -mfuture, it does not work, it cannot work.

[Bug c++/94924] Default equality operator for C-array compares addresses, not data

[rhalbersma at gmail dot com]

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

--- Comment #2 from rhalbersma  ---
OK, Alisdair Meredith points out on Twitter that in [class.compare.default]/6
there is a special sentence on array class data members

In that list, any subobject of array type is recursively expanded to the
sequence of its elements, in the order of increasing subscript.

So only direct array comparisons are deprecated.

[Bug target/95032] [11 Regression] ICE in extract_insn, at recog.c:2294 since r11-187-g98329e3f5b85acc50d

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
(It currently enables p10 insns, but it leaves p9 insns disabled (and any
older insns your compiler doesn't default to as well)).

[Bug middle-end/94988] [11 Regression] FAIL: gcc.target/i386/pr64110.c scan-assembler vmovd[\\t ]

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:119a7db1e05c9741803b3ff93266b00fd535732a

commit r11-320-g119a7db1e05c9741803b3ff93266b00fd535732a
Author: Richard Biener 
Date:   Tue May 12 14:13:32 2020 +0200

middle-end/94988 fix testcase for big-endian

The testcase only works for little-endian, mark it so.

2020-05-12  Richard Biener  

PR middle-end/94988
* gcc.dg/torture/pr94988.c: Disable runtime test for
* non-little-endian.

[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 94988, which changed state.

Bug 94988 Summary: [11 Regression] FAIL: gcc.target/i386/pr64110.c 
scan-assembler vmovd[\\t ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94988

   What|Removed |Added

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

[Bug middle-end/94988] [11 Regression] FAIL: gcc.target/i386/pr64110.c scan-assembler vmovd[\\t ]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[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

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-12

--- Comment #6 from Richard Biener  ---
OK, so for non 7 BE we end up not vectorizing because it doesn't look
profitable
which IMHO is good.  It would be nice to also see dumps before the respective
rev. because in theory (well...) the cost computation should be the same.
Ah!  OK, so we now have

0x10002001470 _1 1 times vec_construct costs 2 in prologue
0x10002001470 _1 1 times vec_construct costs 2 in prologue
0x10002001470 _1 2 times vector_store costs 2 in body
0x10001ecfcc0 _1 1 times scalar_store costs 1 in body
0x10001ecfcc0 _2 1 times scalar_store costs 1 in body
0x10001ecfcc0 _3 1 times scalar_store costs 1 in body
0x10001ecfcc0 _4 1 times scalar_store costs 1 in body

that is, the SLP graph has the expected cost.  Originally we likely
had costed against 4 scalar stores and 4 scalar loads (but the scalar
loads will still be there).  On x86_64 we get

0x3975280 _1 1 times vec_construct costs 8 in prologue
0x3975280 _1 1 times vec_construct costs 8 in prologue
0x3975280 _1 2 times vector_store costs 24 in body
0x3942cb0 _1 1 times scalar_store costs 12 in body
0x3942cb0 _2 1 times scalar_store costs 12 in body
0x3942cb0 _3 1 times scalar_store costs 12 in body
0x3942cb0 _4 1 times scalar_store costs 12 in body

so it's still profitable there.

Note I suggest to leave the FAILs in place for now since in my dev tree
I see the vec_construct gone again so it would start passing again
on ppc as well.

Sorry for the intermediate breakage.

[Bug middle-end/95021] [10/11 Regression] Bogus -Wclobbered warning

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
The problem is since df_lr_bb_local_compute has

   /* If the def is to only part of the reg, it does
   not kill the other defs that reach here.  */
if (!(DF_REF_FLAGS (def) & (DF_REF_PARTIAL | DF_REF_CONDITIONAL)))
  {
unsigned int dregno = DF_REF_REGNO (def);
bitmap_set_bit (&bb_info->def, dregno);
bitmap_clear_bit (&bb_info->use, dregno);
  }

it doesn't consider

(insn 40 39 25 3 (set (subreg:SI (reg/v:DI 85 [ target ]) 4)
(subreg:SI (reg:V2DI 90) 0)) "x.i":17:7 -1
 (nil))

as a def.

[Bug target/95076] Failure to tail-call on function call of different return type

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-12
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
 CC||crazylht at gmail dot com
 Ever confirmed|0   |1

[Bug target/95076] Failure to tail-call on function call of different return type

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Richard Biener from comment #1)
> GCC doesn't tail-call because the return types are not compatible.  With a
> call
> it cannot optimize the stack adjustment because of the ABI.
> 
> Note I'm not sure whether the ABI allows %rax to contain "garbage" in the
> upper half for a function returning in %eax.  So what LLVM does may be wrong.

Don't upper bits of %rax in GCC generate code also contain garbage?

[Bug target/95076] Failure to tail-call on function call of different return type

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
This ia32 psABI return value discussion also applies here:

https://groups.google.com/forum/#!searchin/ia32-abi/return$20value%7Csort:date/ia32-abi/9H4BBrIdkmk/sjWw06ZPnS4J

[Bug target/95076] Failure to tail-call on function call of different return type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Yeah, I believe it is safe in this case, but we would need the info whether the
conversion is ok or not already during the tailc pass and on many targets such
a conversion is not ok (e.g. if the target says that the value is zero-extended
into 64-bits or sign-extended, or 32-bit and 64-bit returned in different
register, whatever).
The question is if the existing target hooks are sufficient to query this or if
we need a new target hook.

[Bug target/95082] New: LE implementations of vec_cnttz_lsbb and vec_cntlz_lsbb are wrong

[wschmidt at gcc dot gnu.org]

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

Bug ID: 95082
   Summary: LE implementations of vec_cnttz_lsbb and
vec_cntlz_lsbb are wrong
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
  Target Milestone: ---

For little endian, we need to swap vctzlsbb and vclzlsbb, but today we generate
the BE instruction in all cases.

[Bug target/95082] LE implementations of vec_cnttz_lsbb and vec_cntlz_lsbb are wrong

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-12
 Ever confirmed|0   |1
   Target Milestone|--- |11.0
 CC||segher at gcc dot gnu.org

--- Comment #1 from Bill Schmidt  ---
Confirmed.

[Bug middle-end/95021] [10/11 Regression] Bogus -Wclobbered warning

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
STV generates:

8d b6 00 00 00 00   lea0x0(%esi),%esi
a1 00 00 00 00  mov0x0,%eax R_386_32target_p
83 ec 08sub$0x8,%esp
f3 0f 7e 00 movq   (%eax),%xmm0
a1 00 00 00 00  mov0x0,%eax R_386_32c
66 0f 6f c8 movdqa %xmm0,%xmm1
66 0f 7e 44 24 10   movd   %xmm0,0x10(%esp)
66 0f 73 d1 20  psrlq  $0x20,%xmm1
66 0f d6 00 movq   %xmm0,(%eax)
66 0f 7e 4c 24 14   movd   %xmm1,0x14(%esp)
ff 74 24 14 pushl  0x14(%esp)
ff 74 24 14 pushl  0x14(%esp)
e8 fc ff ff ff  callR_386_PC32  e

instead of

8d b6 00 00 00 00   lea0x0(%esi),%esi
a1 00 00 00 00  mov0x0,%eax R_386_32target_p
8b 0d 00 00 00 00   mov0x0,%ecx R_386_32c
83 ec 08sub$0x8,%esp
8b 50 04mov0x4(%eax),%edx
8b 00   mov(%eax),%eax
89 51 04mov%edx,0x4(%ecx)
89 01   mov%eax,(%ecx)
52  push   %edx
50  push   %eax
e8 fc ff ff ff  callR_386_PC32  e

It is hard to tell if vector is faster.

[Bug target/95083] New: x86 fp_movcc expansion depends on real_cst sharing

[rguenth at gcc dot gnu.org]

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

Bug ID: 95083
   Summary: x86 fp_movcc expansion depends on real_cst sharing
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

I see gcc.target/i386/avxfp-1.c FAILing, which is

double x;
void
t()
{
  x=x>5?x:5;
}

double x;
void
q()
{
  x=x<5?x:5;
}

and q() recognized as FP min by ix86_expand_fp_movcc because the doesn't
pass prepare_cmp_insn () and later ifcvt matches up the originally
distinct pseudos for the two mentions of '5'.  For t() prepare_cmp_insn ()
succeeeds and ix86_expand_fp_movcc expands this to a UNSPEC_BLEND
(because the two mentions of '5' get a different pseudo so this doesn't
look like a max).  The first prepare_cmp_insn fails because it is fed

(lt (reg:DF 82 [ x.3_1 ])
(const_double:DF 5.0e+0 [0x0.ap+3]))

and appearantly we cannot do a lt compare(?) (but later during ifcvt we can).

Note the above is when expanding from a COND_EXPR, thus

t ()
{
  double x.1_1;
  double iftmp.0_3;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  x.1_1 = x;
  iftmp.0_3 = x.1_1 > 5.0e+0 ? x.1_1 : 5.0e+0;
  x = iftmp.0_3;
  return;

and

q ()
{
  double x.3_1;
  double iftmp.2_3;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  x.3_1 = x;
  iftmp.2_3 = x.3_1 < 5.0e+0 ? x.3_1 : 5.0e+0;
  x = iftmp.2_3;
  return;

similar FAILs occur for

FAIL: gcc.target/i386/avxfp-1.c scan-assembler vmaxsd
FAIL: gcc.target/i386/avxfp-2.c scan-assembler vminsd
FAIL: gcc.target/i386/ssefp-1.c scan-assembler maxsd
FAIL: gcc.target/i386/ssefp-2.c scan-assembler minsd

So what's missing is simplification of 

Trying 8 -> 9:
8: r87:DF=r85:DF

[Bug target/95083] x86 fp_movcc expansion depends on real_cst sharing

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|10.0|11.0
   Keywords||missed-optimization
 CC||uros at gcc dot gnu.org
 Target||x86_64-*-* i?86-*-*

--- Comment #1 from Richard Biener  ---
Needs https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545588.html to
reproduce.

[Bug tree-optimization/95084] New: code sinking prevents if-conversion

[rguenth at gcc dot gnu.org]

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

Bug ID: 95084
   Summary: code sinking prevents if-conversion
   Product: gcc
   Version: 11.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: ---

There's a pass ordering issue between the sink pass and tree-if-conv, if
conversion for vectorization.  When sink sinks a possibly trapping operation
to a place that is only conditionally executed if-conversion fails which
results in failed vectorization.  This can be seen with
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545588.html applied
for gcc.dg/vect/pr56541.c (and it's ifcvt counterpart
gcc.dg/tree-ssa/ifc-pr56541.c).  But I've also seen this in other context.

Here

  iftmp.2_17 = rR_19 < rL_20 ? rR_19 : rL_20;
  iftmp.3_3 = rR_19 < rL_20 ? rL_20 : rR_19;
  if (iftmp.3_3 > 0.0)
goto ; [INV]
  else
goto ; [INV]

   :

   :
  # iftmp.4_14 = PHI 
  if (iftmp.4_14 > 0.0)

becomes

  iftmp.3_3 = rR_17 < rL_18 ? rL_18 : rR_17;
  if (iftmp.3_3 > 0.0)
goto ; [59.00%]
  else
goto ; [41.00%]

   [local count: 435831803]:
  goto ; [100.00%]

   [local count: 627172605]:
  iftmp.2_15 = rR_17 < rL_18 ? rR_17 : rL_18;
  if (iftmp.2_15 > 0.0)

and the now conditionally executed FP comparison can trap.

[Bug middle-end/95021] [10/11 Regression] Bogus -Wclobbered warning

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Tue, 12 May 2020, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95021
> 
> --- Comment #4 from H.J. Lu  ---
> The problem is since df_lr_bb_local_compute has
> 
>/* If the def is to only part of the reg, it does
>not kill the other defs that reach here.  */
> if (!(DF_REF_FLAGS (def) & (DF_REF_PARTIAL | DF_REF_CONDITIONAL)))
>   {
> unsigned int dregno = DF_REF_REGNO (def);
> bitmap_set_bit (&bb_info->def, dregno);
> bitmap_clear_bit (&bb_info->use, dregno);
>   }
> 
> it doesn't consider
> 
> (insn 40 39 25 3 (set (subreg:SI (reg/v:DI 85 [ target ]) 4)
> (subreg:SI (reg:V2DI 90) 0)) "x.i":17:7 -1
>  (nil))
> 
> as a def.

Which it isn't since it sets the upper half of reg:DI 85 only.

[Bug c++/95085] New: diagnostic on designated-initializer from braced-init-list could be better

[barry.revzin at gmail dot com]

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

Bug ID: 95085
   Summary: diagnostic on designated-initializer from
braced-init-list could be better
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

In this program (note the typo in the call to f):

struct A {
int width, height;
};

void f(A);
void g() {
f(A{.width=1, .hieght=2});
}

gcc's diagnostic is absolutely excellent:

:7:20: error: field designator 'hieght' does not refer to any field in
type 'A'; did you mean 'height'?
f(A{.width=1, .hieght=2});
   ^~
   height
:2:16: note: 'height' declared here
int width, height;
   ^

However, if instead of calling f(A{...}) we instead just call f({...}) (as is
common to do if the type name is meaningless and is just used as a proxy for
named function arguments):

struct A {
int width, height;
};

void f(A);
void g() {
f({.width=1, .hieght=2});
}

then we get a much worse diagnostic:

:7:5: error: no matching function for call to 'f'
f({.width=1, .hieght=2});
^
:5:6: note: candidate function not viable: cannot convert initializer
list argument to 'A'
void f(A);
 ^

Basically just: "error". Would it be possible to get the same quality of
diagnostic from the named call case as it is in the just-a-braced-init-list
case?

[Bug c++/95086] New: brace initialization in captures doesn't work with function calls

[nico at josuttis dot de]

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

Bug ID: 95086
   Summary: brace initialization in captures doesn't work with
function calls
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nico at josuttis dot de
  Target Milestone: ---

AFAIK, since C++17 we should be able to do:

 [&coll{std::as_const(vec)}] {}

but it doesn't compile:
 prog.cc: In function 'int main()':
 prog.cc:10:44: error:
   cannot capture '{std::as_const >(vec)}' by reference
10 |   [&coll{std::as_const(vec)}] {  // ERROR???
   |^

However, both using = for the initialization:
 [&coll = std::as_const(vec)] {
and for simple initializations using braces:
 [max{42}] {
work fine.

Other compilers do it as I expect.
It seems to be a problem when reference captures are initialized by function
calls (or other expressions).

See
 https://wandbox.org/permlink/LMSfQ1nLszVHQ4LF

[Bug c++/95086] brace initialization in captures doesn't work with function calls

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
I got impatient and reported it for you yesterday :-)

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

[Bug c++/95069] Capture by reference cannot use list-initalization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||nico at josuttis dot de

--- Comment #1 from Jonathan Wakely  ---
*** Bug 95086 has been marked as a duplicate of this bug. ***

[Bug c++/95069] Capture by reference cannot use list-initalization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-12
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
Reduced:

int i;
auto ok = [&x = i] {};
auto err = [&x{i}] {};

l.cc:3:17: error: cannot capture '{i}' by reference
3 | auto err = [&x{i}] {};
  | ^

[Bug c++/95085] diagnostic on designated-initializer from braced-init-list could be better

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||diagnostic
   Last reconfirmed||2020-05-12

--- Comment #1 from Jonathan Wakely  ---
There is a related problem without designated initializers:

struct A { A(int); };
int f(A);
int i = f(A(nullptr));
int j = f(A{nullptr});

d.cc:3:20: error: no matching function for call to 'A::A(std::nullptr_t)'
...
d.cc:4:20: error: no matching function for call to 'A::A()'
...

It also seems inconsistent to say "initializer list argument" in one place and 
"" in another, although maybe the latter is
because it's inside a quoted C++ expression, not prose.

[Bug c++/95081] Copyright infringement by ROS2

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #3 from Jonathan Wakely  ---
Parameter names are not copyrightable. If you want to define a class with the
same API as std::vector then of course you're going to use the same names for
the member functions.

The only thing copyrightable in there are the comments. I suggest you bring
this up with the ROS2 project, or the Free Software Foundation. There's no GCC
bug here.

See https://www.gnu.org/licenses/gpl-violation.en.html

[Bug c++/95074] Function found via ADL when it should not

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/95087] New: [11 Regression] ICE in gimplify_expr, at gimplify.c:14382

[asolokha at gmx dot com]

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

Bug ID: 95087
   Summary: [11 Regression] ICE in gimplify_expr, at
gimplify.c:14382
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-11.0.0-alpha20200510 snapshot (g:13a46321516e2efd3bbb1f1899c539c6724240a9)
ICEs when compiling
gcc/testsuite/g++.dg/coroutines/co-return-syntax-08-bad-return.C w/
-fcoroutines:

% g++-11.0.0 -fcoroutines -c
gcc/testsuite/g++.dg/coroutines/co-return-syntax-08-bad-return.C
gcc/testsuite/g++.dg/coroutines/co-return-syntax-08-bad-return.C: In function
'Coro bar()':
gcc/testsuite/g++.dg/coroutines/co-return-syntax-08-bad-return.C:37:1: error: a
'return' statement is not allowed in coroutine; did you mean 'co_return'?
   37 | bar () // { dg-error {a 'return' statement is not allowed} }
  | ^~~
gcc/testsuite/g++.dg/coroutines/co-return-syntax-08-bad-return.C:42:5: internal
compiler error: in gimplify_expr, at gimplify.c:14382
   42 | co_return;
  | ^
0x700e91 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:14382
0xd5871b gimplify_cleanup_point_expr
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:6802
0xd3f9c5 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:13977
0xd42c46 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:6802
0xd5549a gimplify_cond_expr
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:4256
0xd3f9e2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:13542
0xd57c8b gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:6802
0xd57c8b gimplify_body(tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:14834
0xd580fd gimplify_function_tree(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/gimplify.c:14988
0xb96967 cgraph_node::analyze()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/cgraphunit.c:670
0xb99587 analyze_functions
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/cgraphunit.c:1227
0xb9a152 symbol_table::finalize_compilation_unit()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/cgraphunit.c:2971

[Bug target/95046] Vectorize V2SFmode operations

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:6416f67273aaeafd6ad89c2c82076dabb50f8dbe

commit r11-322-g6416f67273aaeafd6ad89c2c82076dabb50f8dbe
Author: Uros Bizjak 
Date:   Tue May 12 17:06:13 2020 +0200

i386: Add V2SFmode NEG, ABS and logic insn patterns [PR95046]

gcc/ChangeLog:

PR target/95046
* config/i386/mmx.md (v2sf2): New insn pattern.
(*mmx_v2sf2): New insn_and_split pattern.
(*mmx_nabsv2sf2): Ditto.
(*mmx_andnotv2sf3): New insn pattern.
(*mmx_v2sf3): Ditto.
* config/i386/i386.md (absneg_op): New code attribute.
* config/i386/i386.c (ix86_build_const_vector): Handle V2SFmode.
(ix86_build_signbit_mask): Ditto.

testsuite/ChangeLog:

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

[Bug target/95046] Vectorize V2SFmode operations

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:2a2dea6b63ae600eb1d084c06d8a3ba42c66dd6b

commit r11-323-g2a2dea6b63ae600eb1d084c06d8a3ba42c66dd6b
Author: Uros Bizjak 
Date:   Tue May 12 17:08:03 2020 +0200

i386: Add V2SFmode NEG, ABS and logic insn patterns [PR95046]

gcc/ChangeLog:

PR target/95046
* config/i386/mmx.md (v2sf2): New insn pattern.
(*mmx_v2sf2): New insn_and_split pattern.
(*mmx_nabsv2sf2): Ditto.
(*mmx_andnotv2sf3): New insn pattern.
(*mmx_v2sf3): Ditto.
* config/i386/i386.md (absneg_op): New code attribute.
* config/i386/i386.c (ix86_build_const_vector): Handle V2SFmode.
(ix86_build_signbit_mask): Ditto.

testsuite/ChangeLog:

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

[Bug middle-end/44665] typo in comment, incorrect/out-of-date comment

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #3 from Arseny Solokha  ---
I believe this PR can be finally closed.

[Bug libgomp/68033] OpenMP: ICE with teams distribute

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #3 from Arseny Solokha  ---
Both testcases are accepted by gcc 8 and newer.

[Bug c++/86142] hard error for bad delete-expression in SFINAE context

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
Looks ever since r10-2197, GCC 10 correctly performs SFINAE for the first two
overloaded calls.

But could you explain why

  int z = f();

should resolve to the second overload of f?

My understanding is that 'delete' on a pointer to void is undefined behavior,
but is not ill-formed, so there is no substitution failure and we should select
the first overload.

[Bug c++/78752] [concepts] ICE with constrained variadic member function

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-330-gfa31a3cdbf1571286671d8d3a83e31676862583e
Author: Patrick Palka 
Date:   Tue May 12 12:20:55 2020 -0400

c++: Add abbreviated fn template test for [PR78752]

This adds an abbreviated function template version of the testcase in
PR78752, which seems to already be fixed.

gcc/testsuite/ChangeLog:

PR c++/78752
* g++.dg/cpp2a/concepts-pr78752-2.C: New test.

[Bug fortran/95088] New: ICE in gfc_build_class_symbol, at fortran/class.c:653

[gs...@t-online.de]

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

Bug ID: 95088
   Summary: ICE in gfc_build_class_symbol, at fortran/class.c:653
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

The search for internal restrictions of names has brought to light 
a few critical cases, in the following case the change occurs between 
61 (ok) and 62 (ICE) :


$ cat z1_61.f90
module m234567890123456789012345678901234567890123456789012345678901
   type t234567890123456789012345678901234567890123456789012345678901 &
  (n234567890123456789012345678901234567890123456789012345678901)
  integer, kind ::
n234567890123456789012345678901234567890123456789012345678901
   end type
   type, extends
(t234567890123456789012345678901234567890123456789012345678901) :: &
  a234567890123456789012345678901234567890123456789012345678901
   end type
   interface
  module subroutine
s234567890123456789012345678901234567890123456789012345678901 &
 (x234567890123456789012345678901234567890123456789012345678901)

class(a234567890123456789012345678901234567890123456789012345678901(8)) :: &
x234567890123456789012345678901234567890123456789012345678901
  end
   end interface
end


$ cat z1_62.f90
module m2345678901234567890123456789012345678901234567890123456789012
   type t2345678901234567890123456789012345678901234567890123456789012 &
  (n2345678901234567890123456789012345678901234567890123456789012)
  integer, kind ::
n2345678901234567890123456789012345678901234567890123456789012
   end type
   type, extends
(t2345678901234567890123456789012345678901234567890123456789012) :: &
  a2345678901234567890123456789012345678901234567890123456789012
   end type
   interface
  module subroutine
s2345678901234567890123456789012345678901234567890123456789012 &
 (x2345678901234567890123456789012345678901234567890123456789012)

class(a2345678901234567890123456789012345678901234567890123456789012(8)) :: &
x2345678901234567890123456789012345678901234567890123456789012
  end
   end interface
end


$ cat z1_63.f90
module m23456789012345678901234567890123456789012345678901234567890123
   type t23456789012345678901234567890123456789012345678901234567890123 &
  (n23456789012345678901234567890123456789012345678901234567890123)
  integer, kind ::
n23456789012345678901234567890123456789012345678901234567890123
   end type
   type, extends
(t23456789012345678901234567890123456789012345678901234567890123) :: &
  a23456789012345678901234567890123456789012345678901234567890123
   end type
   interface
  module subroutine
s23456789012345678901234567890123456789012345678901234567890123 &
 (x23456789012345678901234567890123456789012345678901234567890123)

class(a23456789012345678901234567890123456789012345678901234567890123(8)) :: &
x23456789012345678901234567890123456789012345678901234567890123
  end
   end interface
end


$ gfortran-11-20200510 -c z1_61.f90
$
$ gfortran-11-20200510 -c z1_62.f90
f951: internal compiler error: Segmentation fault
0xbb93cf crash_signal
../../gcc/toplev.c:328
0x62fcb8 gfc_build_class_symbol(gfc_typespec*, symbol_attribute*,
gfc_array_spec**)
../../gcc/fortran/class.c:653
0x6365ac build_sym
../../gcc/fortran/decl.c:1746
0x640e09 variable_decl
../../gcc/fortran/decl.c:2780
0x640e09 gfc_match_data_decl()
../../gcc/fortran/decl.c:6170
0x6a4533 match_word
../../gcc/fortran/parse.c:65
0x6a4533 decode_statement
../../gcc/fortran/parse.c:376
0x6a5f7a next_free
../../gcc/fortran/parse.c:1279
0x6a5f7a next_statement
../../gcc/fortran/parse.c:1511
0x6a8324 parse_spec
../../gcc/fortran/parse.c:3738
0x6a7cce parse_interface
../../gcc/fortran/parse.c:3601
0x6a7cce parse_spec
../../gcc/fortran/parse.c:3875
0x6ab59e parse_module
../../gcc/fortran/parse.c:6115
0x6ab8e7 gfc_parse_file()
../../gcc/fortran/parse.c:6428
0x6f7a7f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug target/95046] Vectorize V2SFmode operations

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:955b1f929906cabc5b17c40cbc7d767eebd64cc7

commit r11-331-g955b1f929906cabc5b17c40cbc7d767eebd64cc7
Author: Uros Bizjak 
Date:   Tue May 12 18:36:27 2020 +0200

i386: Add V2SFmode FMA insn patterns [PR95046]

gcc/ChangeLog:

PR target/95046
* config/i386/mmx.md (fmav2sf4): New insn pattern.
(fmsv2sf4): Ditto.
(fnmav2sf4): Ditto.
(fnmsv2sf4): Ditto.

testsuite/ChangeLog:

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

[Bug c++/67491] [meta-bug] concepts issues

[ppalka at gcc dot gnu.org]

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

Bug 78752 Summary: [concepts] ICE with constrained variadic member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78752

   What|Removed |Added

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

[Bug c++/78752] [concepts] ICE with constrained variadic member function

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |10.0

--- Comment #5 from Patrick Palka  ---
Looks like this PR is completely fixed for GCC 10/11 since the concepts-cxx2a
merge.

[Bug fortran/95089] New: ICE in gfc_get_derived_type, at fortran/trans-types.c:2843

[gs...@t-online.de]

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

Bug ID: 95089
   Summary: ICE in gfc_get_derived_type, at
fortran/trans-types.c:2843
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Switches between 57 (ok) and 58 (ICE) :


$ cat z1_57.f90
module m23456789012345678901234567890123456789012345678901234567
   type t23456789012345678901234567890123456789012345678901234567
  type(t23456789012345678901234567890123456789012345678901234567), &
  pointer :: z23456789012345678901234567890123456789012345678901234567
   end type
end


$ cat z1_58.f90
module m234567890123456789012345678901234567890123456789012345678
   type t234567890123456789012345678901234567890123456789012345678
  type(t234567890123456789012345678901234567890123456789012345678), &
  pointer :: z234567890123456789012345678901234567890123456789012345678
   end type
end


$ cat z1_63.f90
module m23456789012345678901234567890123456789012345678901234567890123
   type t23456789012345678901234567890123456789012345678901234567890123
  type(t23456789012345678901234567890123456789012345678901234567890123), &
  pointer ::
z23456789012345678901234567890123456789012345678901234567890123
   end type
end


$ gfortran-11-20200510 -c z1_57.f90 -fcoarray=lib
$ gfortran-11-20200510 -c z1_58.f90 -fcoarray=single
$
$ gfortran-11-20200510 -c z1_58.f90 -fcoarray=lib
f951: internal compiler error: in gfc_get_derived_type, at
fortran/trans-types.c:2843
0x77bbf6 gfc_get_derived_type(gfc_symbol*, int)
../../gcc/fortran/trans-types.c:2843
0x77bee8 gfc_typenode_for_spec(gfc_typespec*, int)
../../gcc/fortran/trans-types.c:1166
0x77c13e gfc_sym_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2247
0x7208fe gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1767
0x723b58 gfc_create_module_variable
../../gcc/fortran/trans-decl.c:5297
0x6e2f72 do_traverse_symtree
../../gcc/fortran/symbol.c:4147
0x72435b gfc_generate_module_vars(gfc_namespace*)
../../gcc/fortran/trans-decl.c:5796
0x6fed94 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2238
0x6abd11 translate_all_program_units
../../gcc/fortran/parse.c:6293
0x6abd11 gfc_parse_file()
../../gcc/fortran/parse.c:6545
0x6f7a7f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/95090] New: ICE: identifier overflow: 129

[gs...@t-online.de]

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

Bug ID: 95090
   Summary: ICE: identifier overflow: 129
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Switches between name length 54 (ok) and 55 (ICE) :


$ cat z1_54.f90
module m23456789012345678901234567890123456789012345678901234
   type t23456789012345678901234567890123456789012345678901234 &
  (n23456789012345678901234567890123456789012345678901234)
  integer, len :: n23456789012345678901234567890123456789012345678901234 =
8
   end type
   integer :: a23456789012345678901234567890123456789012345678901234
   integer :: b23456789012345678901234567890123456789012345678901234(3)[*]
   data b23456789012345678901234567890123456789012345678901234 /1,2,3/
contains
   subroutine s23456789012345678901234567890123456789012345678901234
  type(t23456789012345678901234567890123456789012345678901234 &
 (n23456789012345678901234567890123456789012345678901234)) :: &
 z23456789012345678901234567890123456789012345678901234
   end
end


$ cat z1_55.f90
module m234567890123456789012345678901234567890123456789012345
   type t234567890123456789012345678901234567890123456789012345 &
  (n234567890123456789012345678901234567890123456789012345)
  integer, len :: n234567890123456789012345678901234567890123456789012345 =
8
   end type
   integer :: a234567890123456789012345678901234567890123456789012345
   integer :: b234567890123456789012345678901234567890123456789012345(3)[*]
   data b234567890123456789012345678901234567890123456789012345 /1,2,3/
contains
   subroutine s234567890123456789012345678901234567890123456789012345
  type(t234567890123456789012345678901234567890123456789012345 &
 (n234567890123456789012345678901234567890123456789012345)) :: &
 z234567890123456789012345678901234567890123456789012345
   end
end


$ cat z1_63.f90
module m23456789012345678901234567890123456789012345678901234567890123
   type t23456789012345678901234567890123456789012345678901234567890123 &
  (n23456789012345678901234567890123456789012345678901234567890123)
  integer, len ::
n23456789012345678901234567890123456789012345678901234567890123 = 8
   end type
   integer :: a23456789012345678901234567890123456789012345678901234567890123
   integer ::
b23456789012345678901234567890123456789012345678901234567890123(3)[*]
   data b23456789012345678901234567890123456789012345678901234567890123 /1,2,3/
contains
   subroutine s23456789012345678901234567890123456789012345678901234567890123
  type(t23456789012345678901234567890123456789012345678901234567890123 &
 (n23456789012345678901234567890123456789012345678901234567890123)) ::
&
 z23456789012345678901234567890123456789012345678901234567890123
   end
end


$ cat z1_63_clean.f90
module m23456789012345678901234567890123456789012345678901234567890123
   type t23456789012345678901234567890123456789012345678901234567890123 &
  (n23456789012345678901234567890123456789012345678901234567890123)
  integer, len ::
n23456789012345678901234567890123456789012345678901234567890123 = 8
   end type
   integer :: a23456789012345678901234567890123456789012345678901234567890123
   integer ::
b23456789012345678901234567890123456789012345678901234567890123(3)[*]
   data b23456789012345678901234567890123456789012345678901234567890123 /1,2,3/
contains
   subroutine s23456789012345678901234567890123456789012345678901234567890123
  type(t23456789012345678901234567890123456789012345678901234567890123 &
 (3)) :: &
 z23456789012345678901234567890123456789012345678901234567890123
   end
end


$ gfortran-11-20200510 -c z1_54.f90 -fcoarray=lib
$ gfortran-11-20200510 -c z1_55.f90 -fcoarray=single
$
$ gfortran-11-20200510 -c z1_55.f90 -fcoarray=lib
f951: internal compiler error: identifier overflow: 129
0x64db59 gfc_report_diagnostic
../../gcc/fortran/error.c:782
0x64f27a gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1402
0x676b1f gfc_get_string(char const*, ...)
../../gcc/fortran/iresolve.c:69
0x71bb8a gfc_build_qualified_array
../../gcc/fortran/trans-decl.c:994
0x720d24 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1793
0x723b58 gfc_create_module_variable
../../gcc/fortran/trans-decl.c:5297
0x6e2f72 do_traverse_symtree
../../gcc/fortran/symbol.c:4147
0x72435b gfc_generate_module_vars(gfc_namespace*)
../../gcc/fortran/trans-decl.c:5796
0x6fed94 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2238
0x6abd11 translate_all_program_units
../../gcc/fortran/parse.c:6293
0x6abd11 gfc_parse_file()
../../gcc/fortran/parse.c:6545
0x6f7a7f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/95091] New: ICE in gfc_hash_value, at fortran/class.c:538

[gs...@t-online.de]

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

Bug ID: 95091
   Summary: ICE in gfc_hash_value, at fortran/class.c:538
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

A more complex example, switches between 44 (ok) and 45 (ICE) :
(backtrace varies with release and name length)


$ cat z1_44.f90
module m2345678901234567890123456789012345678901234
  type t2345678901234567890123456789012345678901234
  end type
  interface
module subroutine s2345678901234567890123456789012345678901234 &
  (x2345678901234567890123456789012345678901234)
end
  end interface
end
submodule(m2345678901234567890123456789012345678901234) &
  n2345678901234567890123456789012345678901234
  type, extends(t2345678901234567890123456789012345678901234) :: &
u2345678901234567890123456789012345678901234
  end type
end


$ cat z1_45.f90
module m23456789012345678901234567890123456789012345
  type t23456789012345678901234567890123456789012345
  end type
  interface
module subroutine s23456789012345678901234567890123456789012345 &
  (x23456789012345678901234567890123456789012345)
end
  end interface
end
submodule(m23456789012345678901234567890123456789012345) &
  n23456789012345678901234567890123456789012345
  type, extends(t23456789012345678901234567890123456789012345) :: &
u23456789012345678901234567890123456789012345
  end type
end


$ cat z1_63.f90
module m23456789012345678901234567890123456789012345678901234567890123
  type t23456789012345678901234567890123456789012345678901234567890123
  end type
  interface
module subroutine
s23456789012345678901234567890123456789012345678901234567890123 &
  (x23456789012345678901234567890123456789012345678901234567890123)
end
  end interface
end
submodule(m23456789012345678901234567890123456789012345678901234567890123) &
  n23456789012345678901234567890123456789012345678901234567890123
  type,
extends(t23456789012345678901234567890123456789012345678901234567890123) :: &
u23456789012345678901234567890123456789012345678901234567890123
  end type
end


$ gfortran-11-20200510 -c z1_44.f90
$
$ gfortran-11-20200510 -c z1_45.f90
f951: internal compiler error: Segmentation fault
0xbb93cf crash_signal
../../gcc/toplev.c:328
0x64003a gfc_match_function_decl()
../../gcc/fortran/decl.c:7355
gfortran: internal compiler error: Segmentation fault signal terminated program
f951


$ gfortran-11-20200510 -c z1_63.f90
f951: internal compiler error: Segmentation fault
0xbb93cf crash_signal
../../gcc/toplev.c:328
0x62c64c gfc_hash_value(gfc_symbol*)
../../gcc/fortran/class.c:538
gfortran: internal compiler error: Segmentation fault signal terminated program
f951
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/87847] spec_hasher::hash does not match with spec_hasher::equal

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=94454

--- Comment #11 from Patrick Palka  ---
I posted a patch to enable sanitization for the spec_hasher tables for GCC 11
here: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545525.html

With current trunk I wasn't able to reproduce any sanitization errors in the
testsuite or in other libraries even with a debugging patch similar to Martin's
(on x86_64-pc-linux-gnu).  I suspect they have been fixed by the patches for
PR94454.

[Bug debug/95080] [10/11 Regression] -fcompare-debug failure (length) with -Og -fcse-follow-jumps -fnon-call-exceptions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Started with r10-3542-g0b92cf305dcf34387a8e2564e55ca8948df3b47a 
Given that, most likely latent before.

[Bug testsuite/95092] New: new test case gcc.dg/asan/pr95051.c fails

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95092
   Summary: new test case gcc.dg/asan/pr95051.c fails
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

Executing on host: /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test2/gcc/
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/asan/pr95051.c
-fsanitize=address -g
-I/home/seurer/gcc/git/gcc-test2/gcc/testsuite/../../libsanitizer/include
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never-O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  -fsanitize=kernel-address
--param=asan-stack=1 -O2 -S -o pr95051.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test2/gcc/
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/asan/pr95051.c
-fsanitize=address -g
-I/home/seurer/gcc/git/gcc-test2/gcc/testsuite/../../libsanitizer/include
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects -fsanitize=kernel-address
--param=asan-stack=1 -O2 -S -o pr95051.s
cc1: error: '-fsanitize=address' is incompatible with
'-fsanitize=kernel-address'
compiler exited with status 1
FAIL: gcc.dg/asan/pr95051.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
Excess errors:
cc1: error: '-fsanitize=address' is incompatible with
'-fsanitize=kernel-address'