[Bug tree-optimization/98516] [11 Regression] Wrong code generated by tree vectorizer since r11-3823-g126ed72b9f48f853

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #10 from rguenther at suse dot de  ---
On Tue, 5 Jan 2021, mar...@mpa-garching.mpg.de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98516
> 
> --- Comment #9 from Martin Reinecke  ---
> Thanks, this fixes the reduced test case for me as well!
> 
> Unfortunately there seems to be more where this one came from, since my
> comprehensive test suite still fails ... I'll try to produce test cases and
> open another bug report.

Thanks, that's appreciated!

[Bug target/98550] [11 Regression] ICE in exact_div, at poly-int.h:2219 on s390x-linux-gnu

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
But I can't reproduce that with the current master with a cross compiler.
Maybe it's fixed?

[Bug target/98550] [11 Regression] ICE in exact_div, at poly-int.h:2219 on s390x-linux-gnu

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Last reconfirmed||2021-01-06
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Reducing that right now..

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Priority|P3  |P1
 CC||segher at gcc dot gnu.org
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW

--- Comment #2 from Martin Liška  ---
Reduced test-case:

$ extern "C" void *memcpy(void *, const void *, unsigned long);
inline void copy_mem(unsigned char *out, unsigned char *in, long n) {
  memcpy(out, in, n);
}
template  void typecast_copy(unsigned char out[], T in, long N) {
  memcpy(out, in, sizeof(T) * N);
}
template  void typecast_copy(T out, unsigned char in[], long N) {
  memcpy(out, in, sizeof(T) * N);
}
unsigned long xor_buf_y[1];
inline void xor_buf(unsigned char out[], unsigned char in[]) {
  unsigned long x[4];
  typecast_copy(x, out, 4);
  typecast_copy(xor_buf_y, in, 4);
  x[0] ^= xor_buf_y[0];
  x[3] ^= 3;
  typecast_copy(out, x, 4);
}
char compress_n_S_10, compress_n_S_8, compress_n_S_27, compress_n_S_25,
compress_n_S_0;
unsigned char compress_n___trans_tmp_1;
unsigned char *compress_n_input;
void compress_n() {
  unsigned char S[32], S2[32];
  S2[9] = compress_n_S_25;
  S2[13] = S[7];
  S2[14] = S[28];
  S2[15] = S2[16] = S[0];
  S2[17] = 9 ^ S[31];
  S2[18] = S[8];
  S2[19] = S[29];
  S2[21] = compress_n_S_27;
  S2[22] = compress_n_S_10;
  S2[23] = S[1];
  S2[24] = S[6];
  S2[25] = S[23];
  S2[6] = S[2] ^ compress_n_S_8;
  S2[7] = S[9];
  S2[8] = S[22];
  S2[29] = S[11] ^ S[17];
  S2[0] = S[12] ^ compress_n_S_0;
  S2[1] = S[5] ^ S[3];
  long x[4], y[4];
  typecast_copy(x, S2, 4);
  typecast_copy(y, compress_n_input, 4);
  x[0] ^= y[0];
  x[1] ^= y[1];
  x[2] ^= x[3] ^= y[3];
  typecast_copy(S, x, 4);
  S2[1] = 5 ^ S[7];
  copy_mem(S, S + 2, 30);
  S[31] = S2[1];
  xor_buf(S, _n___trans_tmp_1);
  S2[2] = S2[3] = S2[4] = S[24];
  S2[5] = S2[0] = compress_n_S_8 ^ S[4] ^ S[28];
  char *__trans_tmp_2;
  memcpy(__trans_tmp_2, S2, 32);
}

$ g++ pr98549.C -c  -O3 -fPIC -fstack-protector
In function ‘void typecast_copy(T, unsigned char*, long int) [with T = long
unsigned int*]’,
inlined from ‘void xor_buf(unsigned char*, unsigned char*)’ at
pr98549.C:15:16,
inlined from ‘void compress_n()’ at pr98549.C:54:10:
pr98549.C:9:9: warning: ‘void* memcpy(void*, const void*, long unsigned int)’
writing 32 bytes into a region of size 8 overflows the destination
[-Wstringop-overflow=]
9 |   memcpy(out, in, sizeof(T) * N);
  |   ~~^~~~
pr98549.C: In function ‘void compress_n()’:
pr98549.C:11:15: note: destination object ‘xor_buf_y’ of size 8
   11 | unsigned long xor_buf_y[1];
  |   ^
during RTL pass: reload
pr98549.C:59:1: internal compiler error: in rs6000_emit_le_vsx_store, at
config/rs6000/rs6000.c:9938
   59 | }
  | ^
0x606caa rs6000_emit_le_vsx_store(rtx_def*, rtx_def*, machine_mode)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/config/rs6000/rs6000.c:9938
0x1252e57 gen_movv2di(rtx_def*, rtx_def*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/config/rs6000/vector.md:155
0x999ce7 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/recog.h:407
0x999ce7 emit_move_insn_1(rtx_def*, rtx_def*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/expr.c:3764
0x99a11c emit_move_insn(rtx_def*, rtx_def*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/expr.c:3934
0xb16086 lra_emit_move(rtx_def*, rtx_def*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/lra.c:502
0xb29343 curr_insn_transform
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/lra-constraints.c:4547
0xb2a465 lra_constraints(bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/lra-constraints.c:5138
0xb18632 lra(_IO_FILE*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/lra.c:2329
0xad5a89 do_reload
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/ira.c:5802
0xad5a89 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/ira.c:5988
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/98544] [11 regression] Wrong code generated by tree vectorizer since r11-3917-g28290cb50c7dbf87

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[11 regression] Wrong code  |[11 regression] Wrong code
   |generated by tree   |generated by tree
   |vectorizer  |vectorizer since
   ||r11-3917-g28290cb50c7dbf87

--- Comment #3 from Martin Liška  ---
For g++ bug2.cc  -std=c++17 -O1 -mavx -ftree-loop-vectorize, it started with
r11-3917-g28290cb50c7dbf87.

[Bug tree-optimization/98544] [11 regression] Wrong code generated by tree vectorizer

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Confirmed, one can reduce that to a single loop vectorization:

$ g++ bug2.cc  -std=c++17 -O1 -mavx -ftree-loop-vectorize
-fdbg-cnt=vect_loop:10-10 && ./a.out

but the loop is quite huge.

[Bug lto/98540] [8/9/10/11 Regression] ICE: error: type variant with 'TYPE_ALIAS_SET_KNOWN_P' since r7-6939-g853ef4e5632df328

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-01-06
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Martin Liška  ---
Confirmed, reducing that right now..

[Bug lto/98540] [8/9/10/11 Regression] ICE: error: type variant with 'TYPE_ALIAS_SET_KNOWN_P' since r7-6939-g853ef4e5632df328

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

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

--- Comment #2 from Martin Liška  ---
Created attachment 49894
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49894=edit
Reduced test-case

Started with r7-6939-g853ef4e5632df328 and it was rejected before:

$ g++ lambda.cpp -O3 -Wall -flto -c -std=c++17
lambda.cpp: In function ‘void iterateMatchesFullSimd()’:
lambda.cpp:254:9: warning: typedef ‘using TBlastRecord = int’ locally defined
but not used [-Wunused-local-typedefs]
  254 |   using TBlastRecord = int;
  | ^~~~
lambda.cpp: At global scope:
lambda.cpp:258:1: error: type variant with ‘TYPE_ALIAS_SET_KNOWN_P’
  258 | }
  | ^
 
unit-size 
align:16 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x77415498 precision:16 min  max
>
sizes-gimplified type_6 HI size  unit-size

align:16 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x7755ba80 nunits:1>
 
unit-size 
align:16 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x77415498 precision:16 min  max
>
sizes-gimplified type_6 HI size  unit-size

align:16 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x7755ba80 nunits:1>
during IPA pass: *free_lang_data
lambda.cpp:258:1: internal compiler error: ‘verify_type’ failed
0x139f4d0 verify_type(tree_node const*)
/home/marxin/Programming/gcc/gcc/tree.c:14906
0x13a2407 free_lang_data
/home/marxin/Programming/gcc/gcc/tree.c:6436
0x13a2407 execute
/home/marxin/Programming/gcc/gcc/tree.c:6481
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/98555] New: Functions optimized to zero length break function pointer inequality

[bugdal at aerifal dot cx via Gcc-bugs]

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

Bug ID: 98555
   Summary: Functions optimized to zero length break function
pointer inequality
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

Given a function such as

void foo() { __builtin_unreachable(); }

or optimized to such due to unconditional undefined behavior when the function
is reached, GCC emits a zero-length function. This causes the address of foo to
be equal to the address of whatever function happens to follow foo, breaking
the language requirement that distinct functions' addresses compare not-equal.

As far as I can tell, all versions back to 4.x or earlier are affected.

[Bug c++/98554] New: why the explicit conversion function of derived class return type is not a candidate in the context of direct-initialization

[xmh970252187 at gmail dot com via Gcc-bugs]

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

Bug ID: 98554
   Summary: why the explicit conversion function of derived class
return type is not a candidate in the context of
direct-initialization
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xmh970252187 at gmail dot com
  Target Milestone: ---

#include 
struct A{
A() = default;
A(A const&){}
};
struct B:A{};
struct C{
explicit operator B(){
return B{};
}
};

int main(){
   C c;
   A a(c);  // #1
}

In this example, GCC reports an error and the note is:  

return type 'B' of explicit conversion function cannot be converted to 'const
A' with a qualification conversion 

The restriction for the second standard conversion of explicit conversion
functions which shall be a qualified conversion is defined in the section
[over.match.conv#1](https://eel.is/c++draft/over.match.conv#1). However, that
section totally says about the initialization for an object of **non-class**
type.  In this example, the candidate functions should obey the rule defined in
section [over.match.copy#1](https://eel.is/c++draft/over.match.copy#1), the
relevant rule is: 
> When the type of the initializer expression is a class type “cv S”, 
> conversion functions are considered. The permissible types for non-explicit 
> conversion functions are T and any class derived from T. When initializing a 
> temporary object ([class.mem]) to be bound to the first parameter of a 
> constructor where the parameter is of type “reference to cv2 T” and the 
> constructor is called with a single argument in the context of 
> direct-initialization of an object of type “cv3 T”, the permissible types for 
> explicit conversion functions are the same; otherwise there are none.

In this example, the object be direct-initialized is the `a` at #1, which has
class type `A`, and the initializer is object `c` whose type is `C`. First, in
order to initialize the object `a`, the following rule will be applied to
>Otherwise, if the initialization is direct-initialization, or if it is 
>copy-initialization where the cv-unqualified version of the source type is the 
>same class as, or a derived class of, the class of the destination, 
>constructors are considered. The applicable constructors are enumerated 
>([over.match.ctor]), and the best one is chosen through overload resolution 
>([over.match]).   

Here, `A(A const&)` is a candidate function and its parameter is of type
"reference to cv2 A", so the explicit conversion functions of class `C` should
be considered. And the standard says "the permissible types for explicit
conversion functions are the same". So in this context, `explicit operator B()`
should be used in the conversion sequence. Moreover, since a conversion
function whose return type is A can be used in this context, why wouldn't B
which is derived A be. Isn't B is-A?

[Bug tree-optimization/98138] BB vect fail to SLP one case

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

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

--- Comment #5 from Kewen Lin  ---
(In reply to Kewen Lin from comment #4)
> One rough idea seems:
>   1) Relax this condition all_uniform_p somehow to get SLP instance building
> to go deeper and get those p1/p2 loads as SLP nodes.
>   2) Introduce one more vect_pattern recognizer to catch this kind of
> pattern, transform the slp instance as we expect. I assume we can know the
> whole slp instance then we can transform it as we want here. Probably need
> some costing condition to gate this pattern matching.
>   3) If 2) fail, trim the slp instance from those nodes which satisfy
> all_uniform_p condition to ensure it's same as before.
> 

For 2), instead of vect_pattern with IFN, the appropriate place seems to be
vect_optimize_slp.

But after more thinking, building SLP instance starting from group loads
instead of group stores looks more straightforward. 

  a0 = (p1[0] - p2[0]);
  a1 = (p1[1] - p2[1]);
  a2 = (p1[2] - p2[2]);
  a3 = (p1[3] - p2[3]);

Building the vector  looks more natural and then check the uses
of its all lanes and special patterns to have vector  and
repeat similarly.

Hi Richi,

Is this a good example to request SLP instance build starting group loads?

[Bug tree-optimization/98537] [11 Regression] ICE in emit_move_insn since r11-5839

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #1)
> Mine.

For vec_cmpmn, it goes into ix86_expand_fp_vec_cmp/ix86_expand_int_vec_cmp,
when cmp is integer mask, we need to use ix86_expand_sse_movcc instead of
emit_move_insn.

[Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change

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

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

Tobias Schlüter  changed:

   What|Removed |Added

 CC||tobi at gcc dot gnu.org

--- Comment #1 from Tobias Schlüter  ---
There's a typo in the example, /= instead of !=.  Fixed example below:

I sprinkled const's all over foo's prototype and 'i' still gets reloaded so it
stands to reason that the compiler doesn't see the optimization opportunity. 

==

void foo (int *);

void bar (int n)
{
  int i;
  for (i=0; i

[Bug tree-optimization/98537] [11 Regression] ICE in emit_move_insn since r11-5839

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
Mine.

[Bug fortran/98517] gfortran segfault on character array initialization from parameter value since r8-5900-g266404a8d62b99ab

[emr-gnu at hev dot psu.edu via Gcc-bugs]

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

--- Comment #5 from Eric Reischer  ---
Sorry, that meant to say, "I can confirm the attached patch resolves the
crash".

Thanks :-)

[Bug analyzer/97072] -Wanalyzer-malloc-leak false positive when writing through some pointers

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Should be fixed by the above commit.

[Bug analyzer/98223] gcc.dg/analyzer/pr94851-1.c XPASSes

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed by the above commit.

[Bug analyzer/98073] error: in can_merge_p, at analyzer/region-model.cc

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Thanks for filing this.

This is fixed for GCC 11, but is not fixable for GCC 10.  Marking as resolved.

[Bug analyzer/97072] -Wanalyzer-malloc-leak false positive when writing through some pointers

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r11-6497-gac3966e315ada63eb379d560a012fa77c3909155
Author: David Malcolm 
Date:   Tue Jan 5 20:54:50 2021 -0500

analyzer: fix false leaks when writing through unknown ptrs [PR97072]

gcc/analyzer/ChangeLog:
PR analyzer/97072
* region-model-reachability.cc (reachable_regions::init_cluster):
Convert symbolic region handling to a switch statement.  Add cases
to handle SK_UNKNOWN and SK_CONJURED.

gcc/testsuite/ChangeLog:
PR analyzer/97072
* gcc.dg/analyzer/pr97072.c: New test.

[Bug analyzer/98073] error: in can_merge_p, at analyzer/region-model.cc

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:23fc2be633c61f24a4fbd4096c669e7147ca44ae

commit r11-6496-g23fc2be633c61f24a4fbd4096c669e7147ca44ae
Author: David Malcolm 
Date:   Tue Jan 5 20:53:40 2021 -0500

analyzer: add regression test for PR 98073

This ICE was fixed by r11-2694-g808f4dfeb3a95f50 (aka the big state
rewrite for GCC 11).

gcc/testsuite/ChangeLog:
PR analyzer/98073
* gcc.dg/analyzer/pr98073.c: New test.

[Bug analyzer/98223] gcc.dg/analyzer/pr94851-1.c XPASSes

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r11-6495-gdf1eba3ceada6e8990c00ccfa6c5a2c9b1c13334
Author: David Malcolm 
Date:   Tue Jan 5 20:51:50 2021 -0500

analyzer: remove xfail [PR98223]

The bogus leak message went away after
fcae5121154d1c3382b056bcc2c563cedac28e74 (aka "Hybrid EVRP and
testcases") due to that patch improving a phi node in the gimple input
to the analyzer.

gcc/testsuite/ChangeLog:
PR analyzer/98223
* gcc.dg/analyzer/pr94851-1.c: Remove xfail.

[Bug c++/98441] [11 Regression] member function pointer incorrectly parsed as having trailing return type

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

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

--- Comment #8 from Marek Polacek  ---
Looks like a simple thinko:

--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -12241,9 +12241,11 @@ grokdeclarator (const cp_declarator *declarator,
tree late_return_type = declarator->u.function.late_return_type;
if (tree auto_node = type_uses_auto (type))
  {
-   if (!late_return_type && funcdecl_p)
+   if (!late_return_type)
  {
-   if (current_class_type
+   if (!funcdecl_p)
+ /* auto (*fp)() = f; is OK.  */;
+   else if (current_class_type
&& LAMBDA_TYPE_P (current_class_type))
  /* OK for C++11 lambdas.  */;
else if (cxx_dialect < cxx14)

[Bug middle-end/98553] New: missing warning on strncmp reading past the end of a zero size member array

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

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

Bug ID: 98553
   Summary: missing warning on strncmp reading past the end of a
zero size member array
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC diagnoses the out-of-bounds reads by strcmp in fx and f0 but fails to
diagnose the corresponding out-of-bounds reads by strncmp in gx and g0.  In all
four functions the size of the character array is zero and so each call to the
string function starts reading past its end, and so past the end of the
enclosing object.

$ cat b.c && gcc -O2 -S -Wall -Wextra b.c
extern int strcmp (const char*, const char*);

void init (void*);

int fx (void)
{
  struct { char n, a[]; } a;
  init ();
  return 0 == strcmp (a.a, "123");   // -Wstringop-overread (good)
}

int f0 (void)
{
  struct { char n, a[0]; } a;
  init ();
  return 0 == strcmp (a.a, "123");   // -Wstringop-overread (good)
}


extern int strncmp (const char*, const char*, __SIZE_TYPE__);

int gx (void)
{
  struct { char n, a[]; } a;
  init ();
  return 0 == strncmp (a.a, "123", 3);   // missing -Wstringop-overread
}

int g0 (void)
{
  struct { char n, a[0]; } a;
  init ();
  return 0 == strncmp (a.a, "123", 3);   // missing -Wstringop-overread
}
b.c: In function ‘fx’:
b.c:9:15: warning: ‘strcmp’ reading 1 or more bytes from a region of size 0
[-Wstringop-overread]
9 |   return 0 == strcmp (a.a, "123");   // -Wstringop-overread (good)
  |   ^~~
b.c:7:20: note: source object ‘a’ of size 0
7 |   struct { char n, a[]; } a;
  |^
b.c: In function ‘f0’:
b.c:16:15: warning: ‘strcmp’ reading 1 or more bytes from a region of size 0
[-Wstringop-overread]
   16 |   return 0 == strcmp (a.a, "123");   // -Wstringop-overread (good)
  |   ^~~
b.c:14:20: note: source object ‘a’ of size 0
   14 |   struct { char n, a[0]; } a;
  |^

[Bug fortran/98517] gfortran segfault on character array initialization from parameter value since r8-5900-g266404a8d62b99ab

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #4 from Steve Kargl  ---
On Tue, Jan 05, 2021 at 09:19:51PM +, emr-gnu at hev dot psu.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98517
> 
> --- Comment #3 from Eric Reischer  ---
> Confirm the attached patch resolves the crash.

Of course, it resolves the ICE.  I wouldn't have posted it, otherwise. :-)

>  I have not checked, however, if the generated code is correct.

Given that the code only contains declaration statements, the
generated code with -fdump-tree-original is correct.

% gfcg -c -fdec -fdump-tree-original a.f90
% cat a.f90.005t.original 
__attribute__((fn spec (". ")))
void test_bug ()
{

}

[Bug c++/98551] [10/11 Regression] ICE in replace_result_decl, at cp/constexpr.c:2150

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Priority|P3  |P2
   Target Milestone|--- |10.3
Summary|[11 Regression] ICE in  |[10/11 Regression] ICE in
   |replace_result_decl, at |replace_result_decl, at
   |cp/constexpr.c:2150 |cp/constexpr.c:2150
   Last reconfirmed||2021-01-05
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Started with r10-7718.

[Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change

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

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

Thomas Koenig  changed:

   What|Removed |Added

Version|unknown |11.0
   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=31593
   Severity|normal  |enhancement

[Bug tree-optimization/98552] New: Make more use of __builtin_undefined for assuring that variables do not change

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

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

Bug ID: 98552
   Summary: Make more use of __builtin_undefined for assuring that
variables do not change
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Consider

void foo (int *);

void bar (int n)
{
  int i;
  for (i=0; i

[Bug c++/98551] New: [11 Regression] ICE in replace_result_decl, at cp/constexpr.c:2150

[doko at debian dot org via Gcc-bugs]

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

Bug ID: 98551
   Summary: [11 Regression] ICE in replace_result_decl, at
cp/constexpr.c:2150
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen with trunk 20210102, building the verdigris package.

$ cat tutorial.ii
template  struct integer_sequence;
template  using index_sequence = integer_sequence;
struct QNonConstOverload {
  template 
  constexpr auto operator()(R(T::*ptr)) -> decltype(ptr) {
return ptr;
  }
};
template  QNonConstOverload qOverload;
struct make_index_sequence_helper {
  using result = index_sequence<>;
};
template  using make_index_sequence = make_index_sequence_helper::result;
template  using StaticStringArray = const char[N];
template > struct StaticString;
template  struct StaticString> {
  constexpr StaticString(StaticStringArray);
};
struct {
} W_EmptyFlag;
template  struct MetaMethodInfo {
  F func;
  StaticString paramTypes;
};
template 
constexpr MetaMethodInfo makeMetaSlotInfo(F f, StaticStringArray
,
ParamTypes) {
  return {f, name};
}
class SlotTutorial {
  using W_ThisType = SlotTutorial;
  void overload() {
MetaMethodInfo __trans_tmp_3 =
makeMetaSlotInfo(qOverload<>(_ThisType::overload), "overload",
 W_EmptyFlag)
  }
};

$ g++ -c -O0 -std=gnu++14 -Wall tutorial.ii 
tutorial.ii: In member function ‘void SlotTutorial::overload()’:
tutorial.ii:34:37:   in ‘constexpr’ expansion of
‘qOverload<>.QNonConstOverload::operator()(::overload)’
tutorial.ii:35:37: internal compiler error: in replace_result_decl, at
cp/constexpr.c:2150
   35 |  W_EmptyFlag)
  | ^
0x810fad replace_result_decl
../../src/gcc/cp/constexpr.c:2150
0x810fad cxx_eval_call_expression
../../src/gcc/cp/constexpr.c:2792
0x137c484 cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:6117
0x1496170 cxx_bind_parameters_in_call
../../src/gcc/cp/constexpr.c:1594
0x1496170 cxx_eval_call_expression
../../src/gcc/cp/constexpr.c:2533
0x137c484 cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:6117
0x1378d10 cxx_eval_outermost_constant_expr
../../src/gcc/cp/constexpr.c:7126
0x1385bd5 maybe_constant_value(tree_node*, tree_node*, bool)
../../src/gcc/cp/constexpr.c:7397
0x1385518 cp_fully_fold(tree_node*)
../../src/gcc/cp/cp-gimplify.c:2155
0x13583b0 cp_fully_fold_init(tree_node*)
../../src/gcc/cp/cp-gimplify.c:2176
0x13583b0 store_init_value(tree_node*, tree_node*, vec**, int)
../../src/gcc/cp/typeck2.c:803
0x133ec91 check_initializer
../../src/gcc/cp/decl.c:7028
0x132e912 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../src/gcc/cp/decl.c:7946
0x12f4415 cp_parser_init_declarator
../../src/gcc/cp/parser.c:21798
0x12ed5ae cp_parser_simple_declaration
../../src/gcc/cp/parser.c:14378
0x1398990 cp_parser_declaration_statement
../../src/gcc/cp/parser.c:13522
0x1355413 cp_parser_statement
../../src/gcc/cp/parser.c:11746
0x13515a5 cp_parser_statement_seq_opt
../../src/gcc/cp/parser.c:12112
0x13515a5 cp_parser_compound_statement
../../src/gcc/cp/parser.c:12062
0x134f2f7 cp_parser_function_body
../../src/gcc/cp/parser.c:23987
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

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

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

--- Comment #15 from Michael Meissner  ---
FWIW, the hook that will need to be modified is rs6000_md_asm_adjust in
rs6000.c.  It appears you are passed the outputs, the inputs, the constraints,
and the clobbers.  Right now, we just mark the CA register as being clobbered.

The simplest approach is just to prohibit both prefixed and pc-relative
addresses from being passed to the asm.  If a prefixed/pc-relative address is
passed as an input/output, we would need to force the address to a base
register, and rewrite the input/output to use that new base register.  That
will allow traditional code to work.

I suspect if we wanted to enable users to actually do prefixed loads/stores in
the asm, we would need a constraint that says this address must be prefixed. 
Possibly another one for pc-relative.  And then the hook would allow the
address without modification.

[Bug go/98510] [11 Regression] bootstrap broken in libgo on sparc64-linux-gnu, building the 32bit multilib

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #3 from Ian Lance Taylor  ---
Should be fixed.

[Bug bootstrap/98493] [11 regression] bootstrap build fails in go part of build after r11-6371

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #4 from Ian Lance Taylor  ---
Should be fixed (this time for sure).

[Bug go/98510] [11 Regression] bootstrap broken in libgo on sparc64-linux-gnu, building the 32bit multilib

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

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

commit r11-6489-gf47c00cf95d7dbbe7147c61a4a6bc20921c3da2c
Author: Ian Lance Taylor 
Date:   Mon Jan 4 13:10:38 2021 -0800

syscall: don't define sys_SETREUID and friends

We don't use them, since we always call the C library functions which do
the right thing anyhow.  And they aren't defined on all GNU/Linux variants.

Fixes PR go/98510

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/281473

[Bug bootstrap/98493] [11 regression] bootstrap build fails in go part of build after r11-6371

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

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

commit r11-6488-ga9f76d03bbc791cb55e4e0658f23efd0103ea9b0
Author: Ian Lance Taylor 
Date:   Mon Jan 4 12:43:25 2021 -0800

internal/cpu: more build fixes for Go1.16beta1 release

Some files were missing from the libgo copy of internal/cpu, because they
used to only declare CacheLinePadSize which libgo gets from goarch.sh.
Now they also declare doinit, so copy them over.  Adjust cpu_other.go.

Fix the amd64p32 build by adding a build constraint to cpu_no_name.go.

Fixes PR go/98493

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/281472

[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
See also PR78746, comment#17.  A patch was submitted there to solve this issue.

[Bug c++/82099] internal compiler error: in type_throw_all_p, at cp/except.c:1186 when using a function pointer for templated predicate

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #12 from Marek Polacek  ---
Fixed.

[Bug c++/96675] [10 Regression] tautological-compare warning emitted for NTTP bitwise comparison

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
Fixed.

[Bug c++/96742] [10 Regression] "warning: comparison of unsigned expression in ‘< 0’ is always false" with dependent values

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #11 from Marek Polacek  ---
Fixed.

[Bug c++/97975] [8/9 Regression] ICE unexpected expression '(int)A< >::b' of kind implicit_conv_expr

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] ICE |[8/9 Regression] ICE
   |unexpected expression   |unexpected expression
   |'(int)A<|'(int)A<
   ||
   |>::b' of kind   |>::b' of kind
   |implicit_conv_expr  |implicit_conv_expr
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Marek Polacek  ---
Fixed in GCC 10 too.

[Bug c++/98043] [8/9 Regression] ICE ‘verify_gimple’ failed since r5-3726-g083e891e69429f93b958f6c18e2d52f515bae572

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] ICE |[8/9 Regression] ICE
   |‘verify_gimple’ failed  |‘verify_gimple’ failed
   |since   |since
   |r5-3726-g083e891e69429f93b9 |r5-3726-g083e891e69429f93b9
   |58f6c18e2d52f515bae572  |58f6c18e2d52f515bae572
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #12 from Marek Polacek  ---
Fixed in GCC 10 too.

[Bug c++/98103] [10 Regression] ICE tree check: expected tree that contains 'decl minimal' structure, have 'integer_cst' in cxx_eval_dynamic_cast_fn, at cp/constexpr.c:2003

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Fixed.

[Bug c++/97427] constexpr destructor for const object incorrectly rejected as modifying const object

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed.

[Bug c++/82099] internal compiler error: in type_throw_all_p, at cp/except.c:1186 when using a function pointer for templated predicate

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Marek Polacek
:

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

commit r10-9209-gff22b4e8d0613170601d28eec9462ea31147c7c7
Author: Marek Polacek 
Date:   Tue Jan 5 16:33:07 2021 -0500

c++: ICE with deferred noexcept when deducing targs [PR82099]

In this test we ICE in type_throw_all_p because it got a deferred
noexcept which it shouldn't.  Here's the story:

In noexcept61.C, we call bar, so we perform overload resolution.  When
adding the (only) candidate, we need to deduce template arguments, so
call fn_type_unification as usually.  That deduces U to

  void (*) (int &, int &)

which is correct, but its noexcept-spec is deferred_noexcept.  Then
we call add_function_candidate (bar), wherein we try to create an
implicit conversion sequence for every argument.  Since baz is
of unknown type, we instantiate_type it; it is a TEMPLATE_ID_EXPR
so that calls resolve_address_of_overloaded_function.  But we crash
there, because target_type contains the deferred_noexcept.

So we need to maybe_instantiate_noexcept before we can compare types.
resolve_overloaded_unification seemed like the appropriate spot, now
fn_type_unification produces the function type with its noexcept-spec
instantiated.  This shouldn't go against CWG 1330 because here we
really need to instantiate the noexcept-spec.

This also fixes class-deduction76.C, a dg-ice test I recently added,
therefore this fix also fixes c++/90799, yay.

gcc/cp/ChangeLog:

PR c++/82099
* pt.c (resolve_overloaded_unification): Call
maybe_instantiate_noexcept after instantiating the function
decl.

gcc/testsuite/ChangeLog:

PR c++/82099
* g++.dg/cpp0x/noexcept61.C: New test.

[Bug c++/96675] [10 Regression] tautological-compare warning emitted for NTTP bitwise comparison

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

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

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

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

commit r10-9208-g6fd09a6e8bcadaa69e1fdca09263990cc1c5245f
Author: Marek Polacek 
Date:   Sat Oct 24 15:26:27 2020 -0400

c++: Prevent warnings for value-dependent exprs [PR96742]

Here, in r11-155, I changed the call to uses_template_parms to
type_dependent_expression_p_push to avoid a crash in C++98 in
value_dependent_expression_p on a non-constant expression.  But that
prompted a host of complaints that we now warn for value-dependent
expressions in templates.  Those warnings are technically valid, but
people still don't want them because they're awkward to avoid.  This
patch uses value_dependent_expression_p or type_dependent_expression_p.
But make sure that we don't ICE in value_dependent_expression_p by
checking potential_constant_expression first.

gcc/cp/ChangeLog:

PR c++/96675
PR c++/96742
* pt.c (tsubst_copy_and_build): Call value_dependent_expression_p
or
type_dependent_expression_p instead of
type_dependent_expression_p_push.
But only call value_dependent_expression_p for expressions that are
potential_constant_expression.

gcc/testsuite/ChangeLog:

PR c++/96675
PR c++/96742
* g++.dg/warn/Wdiv-by-zero-3.C: Turn dg-warning into dg-bogus.
* g++.dg/warn/Wtautological-compare3.C: New test.
* g++.dg/warn/Wtype-limits5.C: New test.
* g++.old-deja/g++.pt/crash10.C: Remove dg-warning.

(cherry picked from commit 976e7ef1a2d54f46021f74d071d9fdb9631298f8)

[Bug c++/96742] [10 Regression] "warning: comparison of unsigned expression in ‘< 0’ is always false" with dependent values

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

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

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

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

commit r10-9208-g6fd09a6e8bcadaa69e1fdca09263990cc1c5245f
Author: Marek Polacek 
Date:   Sat Oct 24 15:26:27 2020 -0400

c++: Prevent warnings for value-dependent exprs [PR96742]

Here, in r11-155, I changed the call to uses_template_parms to
type_dependent_expression_p_push to avoid a crash in C++98 in
value_dependent_expression_p on a non-constant expression.  But that
prompted a host of complaints that we now warn for value-dependent
expressions in templates.  Those warnings are technically valid, but
people still don't want them because they're awkward to avoid.  This
patch uses value_dependent_expression_p or type_dependent_expression_p.
But make sure that we don't ICE in value_dependent_expression_p by
checking potential_constant_expression first.

gcc/cp/ChangeLog:

PR c++/96675
PR c++/96742
* pt.c (tsubst_copy_and_build): Call value_dependent_expression_p
or
type_dependent_expression_p instead of
type_dependent_expression_p_push.
But only call value_dependent_expression_p for expressions that are
potential_constant_expression.

gcc/testsuite/ChangeLog:

PR c++/96675
PR c++/96742
* g++.dg/warn/Wdiv-by-zero-3.C: Turn dg-warning into dg-bogus.
* g++.dg/warn/Wtautological-compare3.C: New test.
* g++.dg/warn/Wtype-limits5.C: New test.
* g++.old-deja/g++.pt/crash10.C: Remove dg-warning.

(cherry picked from commit 976e7ef1a2d54f46021f74d071d9fdb9631298f8)

[Bug c++/97975] [8/9/10 Regression] ICE unexpected expression '(int)A< >::b' of kind implicit_conv_expr

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

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

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

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

commit r10-9207-gd0684e49ee8d859fc527b22ed206930371a3
Author: Marek Polacek 
Date:   Tue Dec 1 10:39:08 2020 -0500

c++: Fix ICE with inline variable in template [PR97975]

In this test, we have

  static inline const int c = b;

in a class template, and we call store_init_value as usual.  There, the
value is

  IMPLICIT_CONV_EXPR(b)

which is is_nondependent_static_init_expression but isn't
is_nondependent_constant_expression (they only differ in STRICT).
We call fold_non_dependent_expr, but that just returns the expression
because it only instantiates is_nondependent_constant_expression
expressions.  Since we're not checking the initializer of a constexpr
variable, we go on to call maybe_constant_init, whereupon we crash
because it tries to evaluate all is_nondependent_static_init_expression
expressions, which our value is, but it still contains a template code.

I think the fix is to call fold_non_dependent_init instead of
maybe_constant_init, and only call fold_non_dependent_expr on the
"this is a constexpr variable" path so as to avoid instantiating twice
in a row.  Outside a template this should also avoid evaluating the
value twice.

gcc/cp/ChangeLog:

PR c++/97975
* constexpr.c (fold_non_dependent_init): Add a tree parameter.
Use it.
* cp-tree.h (fold_non_dependent_init): Add a tree parameter with
a default value.
* typeck2.c (store_init_value): Call fold_non_dependent_expr
only when checking the initializer for constexpr variables.
Call fold_non_dependent_init instead of maybe_constant_init.

gcc/testsuite/ChangeLog:

PR c++/97975
* g++.dg/cpp1z/inline-var8.C: New test.

(cherry picked from commit 69bf1c7d5ee21392334f1982d1b40c38e103bbd4)

[Bug c++/98043] [8/9/10 Regression] ICE ‘verify_gimple’ failed since r5-3726-g083e891e69429f93b958f6c18e2d52f515bae572

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:48aa64322e824d674b955459ea3816f3047629a3

commit r10-9206-g48aa64322e824d674b955459ea3816f3047629a3
Author: Marek Polacek 
Date:   Wed Dec 2 10:47:49 2020 -0500

c++: ICE with switch and scoped enum bit-fields [PR98043]

In this testcase we are crashing trying to gimplify a switch, because
the types of the switch condition and case constants have different
TYPE_PRECISIONs.

This started with my r5-3726 fix: SWITCH_STMT_TYPE is supposed to be the
original type of the switch condition before any conversions, so in the
C++ FE we need to use unlowered_expr_type to get the unlowered type of
enum bit-fields.

Normally, the switch type is subject to integral promotions, but here
we have a scoped enum type and those don't promote:

  enum class B { A };
  struct C { B c : 8; };

  switch (x.c) // type B
case B::A: // type int, will be converted to B

Here TREE_TYPE is "signed char" but SWITCH_STMT_TYPE is "B".  When
gimplifying this in gimplify_switch_expr, the index type is "B" and
we convert all the case values to "B" in preprocess_case_label_vec,
but SWITCH_COND is of type "signed char": gimple_switch_index should
be the (possibly promoted) type, not the original type, so we gimplify
the "x.c" SWITCH_COND to a SSA_NAME of type "signed char".  And then
we crash because the precision of the index type doesn't match the
precision of the case value type.

I think it makes sense to do the following; at the end of pop_switch
we've already issued the switch warnings, and since scoped enums don't
promote, it should be okay to use the type of SWITCH_STMT_COND.  The
r5-3726 change was about giving warnings for enum bit-fields anyway.

gcc/cp/ChangeLog:

PR c++/98043
* decl.c (pop_switch): If SWITCH_STMT_TYPE is a scoped enum type,
set it to the type of SWITCH_STMT_COND.

gcc/testsuite/ChangeLog:

PR c++/98043
* g++.dg/cpp0x/enum41.C: New test.

(cherry picked from commit 7482d5a3acb7a8a5564f5cddc4f9d2ebbaea75e4)

[Bug c++/98103] [10 Regression] ICE tree check: expected tree that contains 'decl minimal' structure, have 'integer_cst' in cxx_eval_dynamic_cast_fn, at cp/constexpr.c:2003

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

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

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

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

commit r10-9205-ga38b0c6d62d90a5a30cbd00d32e7b58ee1a21b78
Author: Marek Polacek 
Date:   Wed Dec 2 14:33:13 2020 -0500

c++: ICE with -fsanitize=vptr and constexpr dynamic_cast [PR98103]

-fsanitize=vptr initializes all vtable pointers to null so that it can
catch invalid calls; see cp_ubsan_maybe_initialize_vtbl_ptrs.  That
means that evaluating a vtable reference can produce a null pointer
in this mode, so cxx_eval_dynamic_cast_fn should check that and give
and error.

gcc/cp/ChangeLog:

PR c++/98103
* constexpr.c (cxx_eval_dynamic_cast_fn): If the evaluating of
vtable
yields a null pointer, give an error and return.  Use objtype.

gcc/testsuite/ChangeLog:

PR c++/98103
* g++.dg/ubsan/vptr-18.C: New test.

(cherry picked from commit 0221c656bbe5b4ab54e784df3b109c60cb27e5b6)

[Bug c++/97427] constexpr destructor for const object incorrectly rejected as modifying const object

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

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

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

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

commit r10-9204-g4a8a0d38b128d36a0cf1ac6a7879307b937418ee
Author: Marek Polacek 
Date:   Tue Jan 5 16:27:30 2021 -0500

c++: Fix wrong error with constexpr destructor [PR97427]

When I implemented the code to detect modifying const objects in
constexpr contexts, we couldn't have constexpr destructors, so I didn't
consider them.  But now we can and that caused a bogus error in this
testcase: [class.dtor]p5 says that "const and volatile semantics are not
applied on an object under destruction.  They stop being in effect when
the destructor for the most derived object starts." so we have to clear
the TREE_READONLY flag we set on the object after the constructors have
been called to mark it as no-longer-under-construction.  In the ~Foo
call it's now an object under destruction, so don't report those errors.

gcc/cp/ChangeLog:

PR c++/97427
* constexpr.c (cxx_set_object_constness): New function.
(cxx_eval_call_expression): Set new_obj for destructors too.
Call cxx_set_object_constness to set/unset TREE_READONLY of
the object under construction/destruction.

gcc/testsuite/ChangeLog:

PR c++/97427
* g++.dg/cpp2a/constexpr-dtor10.C: New test.

[Bug libfortran/98507] timezone is incorrect on last day of year for "TZ" hours

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Component|fortran |libfortran

--- Comment #1 from anlauf at gcc dot gnu.org ---
Not a confirmation, just an observation: libgfortran/intrinsics/time_1.h
prefers gettimeofday over clock_gettime, whereas the Linux manpages have:

GETTIMEOFDAY(2) Linux Programmer's Manual
GETTIMEOFDAY(2)

CONFORMING TO
   SVr4, 4.3BSD.   POSIX.1-2001  describes  gettimeofday()  but  not 
settimeofday().
   POSIX.1-2008  marks gettimeofday() as obsolete, recommending the use of
clock_get-
   time(2) instead.


Janne chose this prioritization in 2012, but there is no comment explaining
his choice.  Should this be revisited?

[Bug target/98550] New: [11 Regression] ICE in exact_div, at poly-int.h:2219 on s390x-linux-gnu

[doko at debian dot org via Gcc-bugs]

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

Bug ID: 98550
   Summary: [11 Regression] ICE in exact_div, at poly-int.h:2219
on s390x-linux-gnu
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen with trunk 20210102 on s390x-linux-gnu

https://launchpadlibrarian.net/515474155/buildlog_ubuntu-hirsute-s390x.kmc_2.3+dfsg-9_BUILDING.txt.gz

not yet reduced. search for "BEGIN GCC DUMP" for compiler flags and configure
options.

[Bug fortran/98517] gfortran segfault on character array initialization from parameter value since r8-5900-g266404a8d62b99ab

[emr-gnu at hev dot psu.edu via Gcc-bugs]

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

--- Comment #3 from Eric Reischer  ---
Confirm the attached patch resolves the crash.  I have not checked, however, if
the generated code is correct.

[Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[doko at debian dot org via Gcc-bugs]

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

Bug ID: 98549
   Summary: [11 Regression] ICE in rs6000_emit_le_vsx_store, at
config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen with trunk 20210102 on powerpc64le-linux-gnu, not yet reduced.

https://launchpadlibrarian.net/515474879/buildlog_ubuntu-hirsute-ppc64el.botan_2.17.2+dfsg-2_BUILDING.txt.gz

search for "BEGIN GCC DUMP" for compiler options and configure flags.

[Bug middle-end/98548] New: missing warning on strcmp with a nonstring member

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

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

Bug ID: 98548
   Summary: missing warning on strcmp with a nonstring member
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

-Wstringop-overread detects the misuse of the nonstring array as a strcmp
argument in f() but not in g().  Both calls should trigger a warning.

$ cat b.c && gcc -O2 -S -Wall -Wextra b.c
struct A
{
  char a[4] __attribute__ ((nonstring));
  char b[8];
};

int f (void)
{
  extern struct A a;
  return 0 == __builtin_strcmp (a.a, a.b);   // warning (good)
}

int g (struct A *p)
{
  return 0 == __builtin_strcmp (p->a, p->b);   // missing warning
}
b.c: In function ‘f’:
b.c:10:15: warning: ‘__builtin_strcmp’ argument 1 declared attribute
‘nonstring’ is smaller than the specified bound 8 [-Wstringop-overread]
   10 |   return 0 == __builtin_strcmp (a.a, a.b);
  |   ^~~
b.c:3:8: note: argument ‘a’ declared here
3 |   char a[4] __attribute__ ((nonstring));
  |^

[Bug bootstrap/98506] ../../gcc/libcody/resolver.cc:178:43: error: 'O_CLOEXEC' was not declared in thi s scope

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

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

--- Comment #2 from Nathan Sidwell  ---
Your patch is fine, if you'd like to apply it.   I'd not noticed it go by :(

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

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

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

--- Comment #14 from Bill Schmidt  ---
I agree, Peter.

[Bug fortran/78746] charlen_03, charlen_10 ICE

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #22 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2021-January/01.html

[Bug c++/98547] GCC spends many minutes instead of seconds building a file with array initialization

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Almost surely a dup, perhaps of 94957.

[Bug c++/98547] New: GCC spends many minutes instead of seconds building a file with array initialization

[ilord.tiran at yandex dot ru via Gcc-bugs]

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

Bug ID: 98547
   Summary: GCC spends many minutes instead of seconds building a
file with array initialization
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ilord.tiran at yandex dot ru
  Target Milestone: ---

Hi, GCC Team.

GCC spends a lot of time building the code below, the code in a real project is
compiled for more than an hour. It looks like a GCC has problem with long array
initialization. All versions of GCC that I have tested are affected by this
bug.

GCC/Linux ENV:

$ g++ --version

g++ (Ubuntu 10.2.0-5ubuntu1~20.04) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

How to reproduce:

$ time g++ -O3 long_build.cpp -o long_build_gcc

real6m49,286s
user6m48,478s
sys 0m0,526s

Clang compiles this code in less than a minute

$ clang++ --version

Ubuntu clang version
11.0.1-++20201126023002+d8e8ae195a2-1~exp1~20201126013616.135
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$ time clang++ -O3 long_build.cpp -o long_build_clang

real0m0,208s
user0m0,194s
sys 0m0,008s

Output file is huge. It contains copy-paste assembly for each array member
initialization:

proydakov@:~/gcc-bug$ ls -lah
total 1,2M
drwxrwxr-x  2 proydakov proydakov 4,0K янв  5 23:26 .
drwxrwxr-x 19 proydakov proydakov 4,0K ноя 15 22:44 ..
-rwxrwxr-x  1 proydakov proydakov  17K янв  5 22:03 long_build_clang
-rw-rw-r--  1 proydakov proydakov  477 янв  5 23:10 long_build.cpp
-rwxrwxr-x  1 proydakov proydakov 1,2M янв  5 22:48 long_build_gcc
-rw-rw-r--  1 proydakov proydakov  618 янв  5 23:10 long_build.ii

Code snippet:

struct header_t
{
unsigned msg_id;
unsigned length;
};
template
struct packet_t
{
enum { DATA_SIZE = MTU - sizeof(HEADER) };
packet_t() : data{}
{
header.msg_id = 0;
header.length = sizeof(HEADER);
}
HEADER header;
char data[DATA_SIZE];
};
struct pool
{
pool() : packets{}
{
}
packet_t packets[1024 * 16];
};
int main()
{
pool l;
return sizeof(l);
}

Best regards, Proydakov Evgeny.

[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Bernd Edlinger  ---
> when you leave just one of those tests, you can
> get somewhat more verbose output by using something like that:
>
> make check-gcc-c RUNTESTFLAGS="--target_board=unix/-v/-Wl,-v outputs.exp"

I've just run the corresponding xgcc invocation manually.

> you should see where the collect-ld is invoked:
>
> collect2 version 11.0.0 20210105 (experimental)^M
> /home/ed/gnu/gcc-build/gcc/collect-ld @outputs.ld1_args^M
> GNU ld (GNU Binutils) 2.35.1^M
>
> The arguments are in a response-file: @outputs.ld1_args
> maybe that looks different for you?

It certainly does (Solaris ld doesn't support -v, so no -Wl,-v here), as
I found in collect2.c (do_link): the @ files are only passed if
HAVE_GNU_LD and at_file_supplied.  The former is certainly false for
Solaris ld, so we'll certainly see no outputs.ld1_args passed.

[Bug tree-optimization/98535] [11 Regression] ICE in operands_scanner::get_expr_operands(tree_node**, int) building 538.imagick_r

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
g:6c3ce63b04b38f84c0357e4648383f0e3ab11cd9

[Bug other/98533] [11 Regression] ICE: 'verify_type' failed

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug c/98536] warning with -Wvla-parameter for unspecified bound getting specified later

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #2 from Martin Uecker  ---

The whole point of '*' is to have a way to not specify the bound. It is a very
explicit way of saying that I can't (or don't want) to specify the bound.

In contrast of not specifying anything, i.e. [], which might be careless
omission. So in the later case, I think the warning makes sense but for '*' it
should not be on by default.

[Bug fortran/98517] gfortran segfault on character array initialization from parameter value since r8-5900-g266404a8d62b99ab

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/98517] gfortran segfault on character array initialization from parameter value since r8-5900-g266404a8d62b99ab

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

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

--- Comment #2 from kargl at gcc dot gnu.org ---
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 249f402b8d9..da8e3b63249 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -12437,7 +12437,8 @@ resolve_charlen (gfc_charlen *cl)
}

   /* cl->length has been resolved.  It should have an integer type.  */
-  if (cl->length->ts.type != BT_INTEGER || cl->length->rank != 0)
+  if (cl->length
+ && (cl->length->ts.type != BT_INTEGER || cl->length->rank != 0))
{
  gfc_error ("Scalar INTEGER expression expected at %L",
 >length->where);

[Bug c++/98545] [11 Regression] ICE in write_expression, at cp/mangle.c:3352

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2021-01-05
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Priority|P3  |P1
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
Started with r11-6301.

[Bug middle-end/98508] Sanitizer disable -Wall and -Wextra

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

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

--- Comment #5 from Martin Sebor  ---
There's no need to change the fn spec.  The simple (and safe) solution to this
request is to check calls to see if they're to IFN_ASAN_MARK, like this:

diff --git a/gcc/tree-ssa-uninit.c b/gcc/tree-ssa-uninit.c
index 516a7bd2c99..c3718f96b55 100644
--- a/gcc/tree-ssa-uninit.c
+++ b/gcc/tree-ssa-uninit.c
@@ -209,6 +209,11 @@ check_defs (ao_ref *ref, tree vdef, void *data_)
 {
   check_defs_data *data = (check_defs_data *)data_;
   gimple *def_stmt = SSA_NAME_DEF_STMT (vdef);
+  if (is_gimple_call (def_stmt)
+  && gimple_call_internal_p (def_stmt)
+  && gimple_call_internal_fn (def_stmt) == IFN_ASAN_MARK)
+return false;
+
   /* If this is a clobber then if it is not a kill walk past it.  */
   if (gimple_clobber_p (def_stmt))
 {

[Bug c++/98546] New: long compilation

[ilord.tiran at yandex dot ru via Gcc-bugs]

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

Bug ID: 98546
   Summary: long compilation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ilord.tiran at yandex dot ru
  Target Milestone: ---

[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL

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

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

--- Comment #7 from Bernd Edlinger  ---
when you leave just one of those tests, you can
get somewhat more verbose output by using something like that:

make check-gcc-c RUNTESTFLAGS="--target_board=unix/-v/-Wl,-v outputs.exp"


you should see where the collect-ld is invoked:

collect2 version 11.0.0 20210105 (experimental)^M
/home/ed/gnu/gcc-build/gcc/collect-ld @outputs.ld1_args^M
GNU ld (GNU Binutils) 2.35.1^M

The arguments are in a response-file: @outputs.ld1_args
maybe that looks different for you?

[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #4 from Bernd Edlinger  ---
> It is interesting that some tests are reported failing
> on the x86_64-pc-linux-gnu platform that I also use.

Right: it's not the platform per se but something about it or the tools
used.

> I really wonder what prevents these failures for me.

The weird thing is that I've just run runtest --tool gcc outputs.exp in
one of yesterday's build directories (build are currently running) and
the only failures from outputs.exp are

FAIL: outputs exe savetmp namedb: outputs.ld1_args
FAIL: outputs exe savetmp named2: outputs.ld1_args
FAIL: outputs exe savetmp named2: outputs.ld1_args
FAIL: outputs exe savetmp named2: outputs.ld1_args

Every other failure has vanished.

> Could you say if there the outputs.exp test case
> produces additional temp files in the /tmp folder when it fails?

No: the only things left in /tmp from previous builds are from libgo
make check.

[Bug tree-optimization/98544] [11 regression] Wrong code generated by tree vectorizer

[martin--- via Gcc-bugs]

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

--- Comment #1 from Martin Reinecke  ---
Problem seems to be related to the use of __restrict__.

If I remove the DUCC0_RESTRICT from the function definitions of "radb3",
"radb4" etc., the problem goes away.

However I don't see where I'm violating the promise made by __restrict__ in
these functions ...

[Bug c++/98545] New: [11 Regression] ICE in write_expression, at cp/mangle.c:3352

[doko at debian dot org via Gcc-bugs]

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

Bug ID: 98545
   Summary: [11 Regression] ICE in write_expression, at
cp/mangle.c:3352
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen with trunk 20210102, building the sopt package

$ cat serial_vs_parallel_padmm.ii
class Matrix {
public:
  Matrix();
  template  Matrix(OtherDerived);
};
template  using Vector = Matrix;
class L1TightFrame {
protected:
  template  void operator()(T0, double, T1);
};
class L1 : L1TightFrame {
public:
  template 
  auto tight_frame(T...) -> decltype(operator()(T()...)) {}
};
template  class ImagingProximalADMM {
public:
  template  ImagingProximalADMM(DERIVED);
  L1 l1_proximal() const;
  int operator()() {
int result, __trans_tmp_10;
Vector<> out, __trans_tmp_12;
operator()(out, __trans_tmp_10, __trans_tmp_12);
return result;
  }
  int operator()(Vector<> &, Vector<> const &, Vector<> const &) const;
  template 
  void l1_proximal(T0 out, double gamma, T1 x) const {
l1_proximal().tight_frame(out, gamma, x);
  }
};
template 
int ImagingProximalADMM::operator()(Vector<> &, Vector<> const &,
Vector<> const &) const {
  int result;
  [&](Vector<> out, double gamma, Vector<> x) { l1_proximal(out, gamma, x); };
  return result;
}
Vector<> y = ImagingProximalADMM(y)();

$ g++ -c -O0 -std=gnu++11 serial_vs_parallel_padmm.ii
serial_vs_parallel_padmm.ii: In instantiation of ‘decltype
(((L1*)this)->L1TightFrame::operator()(T()...)) L1::tight_frame(T ...) [with T
= {Matrix, double, Matrix}]’:
serial_vs_parallel_padmm.ii:14:8: internal compiler error: in write_expression,
at cp/mangle.c:3352
   14 |   auto tight_frame(T...) -> decltype(operator()(T()...)) {}
  |^~~
0x97242d write_expression
../../src/gcc/cp/mangle.c:3352
0x190cd14 write_expression
../../src/gcc/cp/mangle.c:3449
0x14b393f write_type
../../src/gcc/cp/mangle.c:2343
0x14bafb1 write_bare_function_type
../../src/gcc/cp/mangle.c:2746
0x12bdcb0 mangle_decl_string
../../src/gcc/cp/mangle.c:4001
0x12bcfcc get_mangled_id
../../src/gcc/cp/mangle.c:4022
0x12bcfcc mangle_decl(tree_node*)
../../src/gcc/cp/mangle.c:4060
0x12b4558 decl_assembler_name(tree_node*)
../../src/gcc/tree.c:708
0x12b4558 symtab_node::get_comdat_group_id()
../../src/gcc/cgraph.h:253
0x12b4558 analyze_functions
../../src/gcc/cgraphunit.c:1185
0x17f0543 symbol_table::finalize_compilation_unit()
../../src/gcc/cgraphunit.c:2513
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL

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

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

--- Comment #5 from Tobias Burnus  ---
(In reply to Rainer Orth from comment #0)
> * Despite -save-temps, the lto-wrapper input objects are removed at the end,
>   so I cannot manually rerun lto-wrapper to investigate.

You could modify
  gcc/testsuite/gcc.misc-tests/outputs.exp
to:

* only run a single 'outest' which is failing (e.g. comment all 'outest' lines
but 'outputs lto st mult dumpdir named')

* Remove 'file delete' in 'proc outest'

Run the test and check which files are under /tmp + test directory - and
compare it with the failing while (which checks with 'file exists' or using
'glob').

[Bug target/98495] X86 _mm_extract_pi16 incorrectly sign extends result

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r11-6484-gf6dd35cf9300ae482038c26655b3cee3e72cefb1
Author: H.J. Lu 
Date:   Tue Jan 5 10:57:20 2021 -0800

x86: Use unsigned short to compute pextrw result

Use unsigned short to compute the zero-extended pextrw result.

PR target/98495
* gcc.target/i386/sse2-mmx-pextrw.c (compute_correct_result): Use
unsigned short to compute pextrw result.

[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL

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

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

--- Comment #4 from Bernd Edlinger  ---
It is interesting that some tests are reported failing
on the x86_64-pc-linux-gnu platform that I also use.

I really wonder what prevents these failures for me.

Could you say if there the outputs.exp test case
produces additional temp files in the /tmp folder when it fails?

[Bug middle-end/98508] Sanitizer disable -Wall and -Wextra

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

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

--- Comment #4 from Jakub Jelinek  ---
It is not simple at all.  While the ifns don't modify the references variable,
they do modify the corresponding shadow memory, which is something GCC aliasing
oracle doesn't track at all, so by supplying detailed fnspec about the ifns
there is a very high risk it will start miscompiling things.
I have tried it in the past, and it just didn't work.

[Bug tree-optimization/98535] [11 Regression] ICE in operands_scanner::get_expr_operands(tree_node**, int) building 538.imagick_r

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Bisection points to 6c3ce63b04b38f84c0357e4648383f0e3ab11cd9

[Bug c++/98544] New: [11 regression] Wrong code generated by tree vectorizer

[martin--- via Gcc-bugs]

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

Bug ID: 98544
   Summary: [11 regression] Wrong code generated by tree
vectorizer
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Created attachment 49893
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49893=edit
test case

The attached test case (sorry, I don't have the time to reduce this properly at
the moment ...) tests real-valued FFTs of different lengths and should not
output anything if compiled properly.

However, with current trunk and the following compiler command line, some of
the results are really wrong:

martin@debian:~/codes/ducc/bug$ g++ -std=c++17 -O1 -mavx -ftree-vectorize
bug2.cc
martin@debian:~/codes/ducc/bug$ ./a.out
problem at length 15; discrepancy is 4.40898
problem at length 20; discrepancy is 4.54691
problem at length 21; discrepancy is 3.70442
problem at length 25; discrepancy is 8.40318
problem at length 27; discrepancy is 8.44956
problem at length 28; discrepancy is 3.12203
problem at length 30; discrepancy is 8.81795

The discrepancies should be below 1e-15.

The failure goes away when removing either "-ftree-vectorize" or "-mavx". On
released versions of gcc, it runs fine.

[Bug middle-end/98508] Sanitizer disable -Wall and -Wextra

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||msebor at gcc dot gnu.org
  Component|c++ |middle-end
 Blocks||24639
   Last reconfirmed||2021-01-05

--- Comment #3 from Martin Sebor  ---
It's possible (and obviously desirable) but difficult in general, which is why
it hasn't been done yet.

But in this case it shouldn't be hard: the warning is suppressed because the
code finds the ASAN_MARK (UNPOISON, , 4); call in the IL below, and treats it
like any other pass-by-reference call: it assumes that it might write to s and
thus initialize it.  The "fix" is simple: teach the warning that the .ASAN
directive doesn't do that.

int main ()
{
  int D.2825;

  {
struct S s;

try
  {
.ASAN_MARK (UNPOISON, , 4);
s = s;
  }
finally
  {
.ASAN_MARK (POISON, , 4);
  }
  }
  D.2825 = 0;
  return D.2825;
}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug c++/98515] [11 Regression] Possible regression causing "is protected within this context" error

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/98543] New: fails to diagnose unnecessary functions

[tiagomacarios at gmail dot com via Gcc-bugs]

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

Bug ID: 98543
   Summary: fails to diagnose unnecessary functions
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tiagomacarios at gmail dot com
  Target Milestone: ---

clang diagnoses unnecessary functions, gcc fails to:

https://godbolt.org/z/vvErGh

static void f()
{
   [[maybe_unused]] auto var = 
}

[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from Bernd Edlinger  ---
> Unfortunately I cannot reproduce.
>
> I configured like this:
> ../gcc-trunk/configure --prefix=/home/ed/gnu/install --enable-languages=all
>
> and use
> GNU ld (GNU Binutils) 2.35.1

As I mentioned, it reliably FAILs on Solaris with both the native linker
and GNU ld, and in some configurations on Linux, Darwin, and FreeBSD.  I
don't know where the common ground between those configs is, and THB
have absolutely no idea what is happening here.  This LTO stuff remains
a mystery to me.

[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL

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

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

--- Comment #2 from Bernd Edlinger  ---
Unfortunately I cannot reproduce.

I configured like this:
../gcc-trunk/configure --prefix=/home/ed/gnu/install --enable-languages=all

and use
GNU ld (GNU Binutils) 2.35.1

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

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

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

Bug 94802 Summary: Failure to recognize identities with __builtin_clz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94802

   What|Removed |Added

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

[Bug tree-optimization/94802] Failure to recognize identities with __builtin_clz

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #12 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/94802] Failure to recognize identities with __builtin_clz

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

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

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

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

commit r11-6482-g5de7bf5bc98ec9edc6838a443521204d0eca7605
Author: Jakub Jelinek 
Date:   Tue Jan 5 19:13:29 2021 +0100

expand: Fold x - y < 0 to x < y during expansion [PR94802]

My earlier patch to simplify x - y < 0 etc. for signed subtraction
with undefined overflow into x < y in match.pd regressed some tests,
even when it was guarded to be post-IPA, the following patch thus
attempts to optimize that during expansion instead (which is the last
time we can do it, afterwards we lose the information whether it was
x - y < 0 or (int) ((unsigned) x - y) < 0 for which we couldn't
optimize it.

2021-01-05  Jakub Jelinek  

PR tree-optimization/94802
* expr.h (maybe_optimize_sub_cmp_0): Declare.
* expr.c: Include tree-pretty-print.h and flags.h.
(maybe_optimize_sub_cmp_0): New function.
(do_store_flag): Use it.
* cfgexpand.c (expand_gimple_cond): Likewise.

* gcc.target/i386/pr94802.c: New test.
* gcc.dg/Wstrict-overflow-25.c: Remove xfail.

[Bug c/98536] warning with -Wvla-parameter for unspecified bound getting specified later

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
The warning in both cases (reproduced below) is to encourage specifying the
bounds in declarations and discourage the use of [*].  At some point [*] needs
to be replaced by an actual bound so it might as well be done at the point of
the declaration where it can be used by tools for bounds checking.  I see [*]
as analogous to a function without a prototype.  Both have some uses that can't
be easily achieved by other means but both are dangerous and best avoided.

$ gcc -S -Wall pr98536.c
pr98536.c:2:17: warning: argument 1 of type ‘double[3]’ declared as an ordinary
array [-Wvla-parameter]
2 | void foo(double x[3]) { }
  |  ~~~^~~~
pr98536.c:1:17: note: previously declared as a variable length array
‘double[*]’
1 | void foo(double x[*]);
  |  ~~~^~~~
pr98536.c:5:17: warning: argument 1 of type ‘double[*]’ declared with 1
unspecified variable bound [-Wvla-parameter]
5 | void bar(double x[*]);
  |  ~~~^~~~
pr98536.c:6:17: note: subsequently declared as ‘double[n]’ with 0 unspecified
variable bounds
6 | void bar(double x[n]) { }
  |  ~~~^~~~

[Bug tree-optimization/98516] [11 Regression] Wrong code generated by tree vectorizer since r11-3823-g126ed72b9f48f853

[martin--- via Gcc-bugs]

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

--- Comment #9 from Martin Reinecke  ---
Thanks, this fixes the reduced test case for me as well!

Unfortunately there seems to be more where this one came from, since my
comprehensive test suite still fails ... I'll try to produce test cases and
open another bug report.

[Bug c/98539] incorrect warning with -Wvla-parameter for unspecified bound in multi-dim array

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

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

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

[Bug c/98091] unspecified VLA bound formatted as [0] instead of [*] in -Wvla-parameter

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Duplicated by pr98539.

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

[Bug c/98539] incorrect warning with -Wvla-parameter for unspecified bound in multi-dim array

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   Last reconfirmed||2021-01-05
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
The internal representation of [*] is the same as [0] so except in the most
significant bounds the warning can't distinguish between one and the other (see
pr98091).  It has to pick one and it chooses to consider it a VLA.  Let me
confirm this bug here and resolve pr98091 as a duplicate.

[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib

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

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

--- Comment #13 from Peter Bergner  ---
We are talking inline asm here, correct?  If so, the user is fully in charge of
using the correct mnemonic.  It just seems to me that "m" should always mean
non pc-relative addresses for all the existing inline asm and we should have a
new constraint that allows pc-relative addressing.  The user would just need to
ensure to use the correct mnemonic with the correct constraint.  Or am I
missing something here?

[Bug c/98503] [11 regression] -Warray-bounds false positive with global variables at -O2 since r11-3306-g3f9a497d1b0dd9da

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

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

--- Comment #10 from Martin Sebor  ---
The main purpose of the "partly outside" warning is to detect reads/writes that
cross the trailing array boundary.  Those typically come up when a "typeless"
buffer (either char array or one allocated by a function like malloc) is used
to store a sequence of heterogeneous elements.  Besides these bugs the warning
also detects other kinds of invalid accesses that span the boundary, like in
comment #0.  The access there in invalid for a different reason than the usual
-Warray-bounds, so issuing a warning that's controlled by a different option
would be appropriate (-Wstrict-aliasing seems like a good fit).  It's something
we have discussed doing but it's not at the top my to do list.  Making it
conditional on -fstrict-aliasing might be worth considering as well.

[Bug c++/98501] potential optimization for base<->derived pointer casts

[vanyacpp at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Ivan Sorokin  ---
(In reply to Richard Biener from comment #1)
> I think there's a duplicate of this PR.

I searched the list of bugs and I found PR95663. Is it it?

[Bug tree-optimization/98535] [11 Regression] ICE in operands_scanner::get_expr_operands(tree_node**, int) building 538.imagick_r

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

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
This backtrace started with my commit 64432b680eab0bddbe9a4ad4798457cf6a14ad60
but before this it still ICEd with:
foo.c: In function 'i':
foo.c:12:1: error: type mismatch in 'vec_perm_expr'
   12 | i() {
  | ^
vector([4,4]) unsigned short
vector([4,4]) unsigned short
unsigned long
vector([4,4]) ssizetype
_112 = VEC_PERM_EXPR <_111, niters.19_72, { 0, POLY_INT_CST [4, 4], 1,
POLY_INT_CST [5, 4], 2, POLY_INT_CST [6, 4], ... }>;
during GIMPLE pass: vect

[Bug c/63944] [DR413] Partial overriding of nonconstant struct/union initializers with designated initializers

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c/64918] invalid (?) warning when initializing structure

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #11 from Marek Polacek  ---
Fixed.

[Bug c/65455] typeof _Atomic fails

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/91465] [9 Regression] unexpected expression of kind overload (ICE)

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #11 from Marek Polacek  ---
Fixed in GCC 10.

[Bug c++/91678] [9 Regression] decltype returns wrong type under certain conditions

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #14 from Marek Polacek  ---
Fixed.