[Bug tree-optimization/96563] Failure to optimize loop with condition to simple arithmetic

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Last reconfirmed||2020-08-11
 Ever confirmed|0   |1
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization

--- Comment #1 from Marc Glisse  ---
At -O2 (before uncprop)

   [local count: 151290756]:

   [local count: 976138698]:
  # i_9 = PHI <0(2), i_4(6)>
  if (x_3(D) == i_9)
goto ; [5.50%]
  else
goto ; [94.50%]

   [local count: 922451069]:
  i_4 = i_9 + 1;
  if (i_4 != 10)
goto ; [89.42%]
  else
goto ; [10.58%]

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

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

   [local count: 53687628]:

   [local count: 151290756]:
  # _2 = PHI <8(7), 4(8)>
  return _2;

We don't really do anything special. At -O3, the loop gets unrolled

   [local count: 151290757]:
  if (x_3(D) == 0)
goto ; [5.50%]
  else
goto ; [94.50%]

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

   [local count: 142969766]:
  if (x_3(D) == 1)
goto ; [5.50%]
  else
goto ; [94.50%]

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

   [local count: 135106428]:
  if (x_3(D) == 2)
goto ; [5.50%]
  else
goto ; [94.50%]

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

   [local count: 127675576]:
  if (x_3(D) == 3)
goto ; [5.50%]
  else
goto ; [94.50%]

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

   [local count: 120653419]:
  if (x_3(D) == 4)
goto ; [5.50%]
  else
goto ; [94.50%]

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

   [local count: 114017483]:
  if (x_3(D) == 5)
goto ; [5.50%]
  else
goto ; [94.50%]

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

   [local count: 107746521]:
  if (x_3(D) == 6)
goto ; [5.50%]
  else
goto ; [94.50%]

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

   [local count: 101820460]:
  if (x_3(D) == 7)
goto ; [5.50%]
  else
goto ; [94.50%]

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

   [local count: 96220334]:
  if (x_3(D) == 8)
goto ; [5.50%]
  else
goto ; [94.50%]

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

   [local count: 90928219]:
  if (x_3(D) == 9)
goto ; [5.50%]
  else
goto ; [94.50%]

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

   [local count: 97603126]:

   [local count: 151290756]:
  # _2 = PHI <8(14), 4(12), 8(22), 8(21), 8(20), 8(19), 8(18), 8(17), 8(16),
8(15), 8(23)>
  return _2;

We have code in reassoc to handle x==0||x==1||x==2 and turn it into a range
test. I suspect the issue is related to those empty bb between the condition
and the PHI that hides the fact that they are jumping to the same place
eventually. Fixing this for the unrolled case is thus probably easiest,
although of course it would be nice if it also worked for 99 instead of 9,
where we are not going to unroll.

[Bug target/96558] [11 Regression] ICE in extract_constrain_insn, at recog.c:2195 (error: insn does not satisfy its constraints)

[asolokha at gmx dot com]

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

--- Comment #1 from Arseny Solokha  ---
The internal loop can be simplified a bit:

  do
{
  long int lf = (long int) f1 ? h1 : 0;

  ky += lf;
  vh = lf | f1;
  f1 = 1;
}
  while (vh < (f1 ^ 2));

[Bug target/96072] ICE: Segmentation fault (in add_reg_note)

[asolokha at gmx dot com]

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

--- Comment #1 from Arseny Solokha  ---
testsuite/gcc.target/s390/20041109-1.c is another similar case which clobbers
SP on PowerPC. Maybe it's time to turn

  warning: listing the stack pointer register 'sp' in a clobber list is
deprecated

into a hard error and be done with it?

[Bug target/96551] [10/11 Regression] FAIL: gcc.target/i386/vectorize8.c (internal compiler error)

[crazylht at gmail dot com]

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

--- Comment #1 from Hongtao.liu  ---
For `vec_unpacku_float_hi_v16si` `vec_unpacku_float_lo_v16si`

---
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index cf083ca28aa..2e60f596bc1 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -6973,7 +6973,7 @@

   emit_insn (gen_vec_extract_hi_v16si (tmp[3], operands[1]));
   emit_insn (gen_floatv8siv8df2 (tmp[2], tmp[3]));
-  emit_insn (gen_rtx_SET (k, gen_rtx_LT (QImode, tmp[2], tmp[0])));
+  ix86_expand_mask_vec_cmp (k, LT, tmp[2], tmp[0]);
   emit_insn (gen_addv8df3_mask (tmp[2], tmp[2], tmp[1], tmp[2], k));
   emit_move_insn (operands[0], tmp[2]);
   DONE;
@@ -7020,7 +7020,7 @@
   k = gen_reg_rtx (QImode);

   emit_insn (gen_avx512f_cvtdq2pd512_2 (tmp[2], operands[1]));
-  emit_insn (gen_rtx_SET (k, gen_rtx_LT (QImode, tmp[2], tmp[0])));
+  ix86_expand_mask_vec_cmp (k, LT, tmp[2], tmp[0]);
   emit_insn (gen_addv8df3_mask (tmp[2], tmp[2], tmp[1], tmp[2], k));
   emit_move_insn (operands[0], tmp[2]);
   DONE;
---

[Bug c++/96164] Constraints and explicit template instantiation

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #6 from Patrick Palka  ---
This should be fixed for GCC 10.3+, thanks for the report.

[Bug c++/96164] Constraints and explicit template instantiation

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:215927a736d21d8cff8baeb50f687911a00149b9

commit r10-8602-g215927a736d21d8cff8baeb50f687911a00149b9
Author: Patrick Palka 
Date:   Wed Jul 29 22:06:33 2020 -0400

c++: constraints and explicit instantiation [PR96164]

When considering to instantiate a member of a class template as part of
an explicit instantiation of the class template, we need to first check
the member's constraints before proceeding with the instantiation of the
member.

gcc/cp/ChangeLog:

PR c++/96164
* constraint.cc (constraints_satisfied_p): Return true if
!flags_concepts.
* pt.c (do_type_instantiation): Update a paragraph taken from
[temp.explicit] to reflect the latest specification.  Don't
instantiate a member with unsatisfied constraints.

gcc/testsuite/ChangeLog:

PR c++/96164
* g++.dg/cpp2a/concepts-explicit-inst5.C: New test.

(cherry picked from commit dc3d1e181445fafbbd146eb355a750c41c338794)

[Bug target/96562] Rather poor assembly generated for copy-list-initialization in return statement.

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-08-11

--- Comment #2 from H.J. Lu  ---
Add -mavx to -O2 triggers this.

[Bug gcov-profile/96534] keep gcov intermediate format

[xlwu at synopsys dot com]

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

--- Comment #3 from xlwu at synopsys dot com ---
(In reply to xlwu from comment #2)
> (In reply to Martin Liška from comment #1)
> > (In reply to xlwu from comment #0)
> > > since gcc9, the gcov did not support intermediate format and replace with
> > > json format , our application deeply depend on intermediate format , is it
> > > possible to restore the intermediate format ?
> > 
> > No, the support was removed from the GCC.
> > 
> > > or could you let me know any
> > > workaround ? 
> > 
> > Sure, it's very easy. One can get the very same information from the new
> > JSON format (which is fairly simple):
> > 
> > https://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html
> > 
> > > 
> > > background :
> > > I am a software engineer from SNPS , we have an application that extract 
> > > all
> > > file+functions and it's related lines per test case, and we save this data
> > > into DB which help us to predict the test to verify when RnD updated any
> > > lines in source code before their check in. we call this application as
> > > "smart regression". 
> > 
> > That's a nice usage of the GCOV and the new format should simplify your 
> > life.
> > 
> > > 
> > > now , when gcov move to json file, it increase the size a lot which affect
> > > the efficiency to parse the data
> > 
> > I'm aware of the limitation. Note that the JSON format is compressed with
> > gzip.
> > Can you please share more statistics?
> 
> I did not have the real statistics yet as our company is not yet moved to
> gcc9 (maybe end of this year ).
> 
> and even the size of the compressed file is smaller , but we have to unzip
> and parse it , right? it just increase the workload . 
> 
> however, the stdout option ( -t ) could be very helpful , we don't need to
> write to disk and just parse the stdout content.
> 
> well, I also notice that the "function_name" in "lines" object is mangled
> even I use "--demangled-names" option, can you print the demangled_name when
> "-m" option given ? ( yes I know there is demangled name in "functions" part
> ) . the reason is: we need to know the exact function name and it's lines,
> in current format , we have to find all demangled function name and it's
> start and end line number, then check the lines part to assign each lines
> into functions .

OK, maybe this is not a good idea , I guess this will increase the size much
larger 

> > 
> > > , what's worse, we had to revise our code
> > > to support the new json format while we need to support the old format in
> > > the same time , as our company have many products and each product have 
> > > many
> > > live branches , some of them still using gcc6 version.
> > 
> > I see. As mentioned, porting to the new format should be fairly simple.
> > 
> > > 
> > > I tried to use older gcov version on the new gcc instructed gcda and gcno
> > > file , it did not work.
> > 
> > Please don't do it.

[Bug tree-optimization/96563] New: Failure to optimize loop with condition to simple arithmetic

[gabravier at gmail dot com]

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

Bug ID: 96563
   Summary: Failure to optimize loop with condition to simple
arithmetic
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(int x)
{
int i = 0;
while (i <= 9)
{
if (i == x)
return 8;
++i;
}
return 4;
}

This can be optimized to `return 4 + ((x <= 9) * 4);`. This transformation is
done by LLVM, but not by GCC.

[Bug gcov-profile/96534] keep gcov intermediate format

[xlwu at synopsys dot com]

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

--- Comment #2 from xlwu at synopsys dot com ---
(In reply to Martin Liška from comment #1)
> (In reply to xlwu from comment #0)
> > since gcc9, the gcov did not support intermediate format and replace with
> > json format , our application deeply depend on intermediate format , is it
> > possible to restore the intermediate format ?
> 
> No, the support was removed from the GCC.
> 
> > or could you let me know any
> > workaround ? 
> 
> Sure, it's very easy. One can get the very same information from the new
> JSON format (which is fairly simple):
> 
> https://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html
> 
> > 
> > background :
> > I am a software engineer from SNPS , we have an application that extract all
> > file+functions and it's related lines per test case, and we save this data
> > into DB which help us to predict the test to verify when RnD updated any
> > lines in source code before their check in. we call this application as
> > "smart regression". 
> 
> That's a nice usage of the GCOV and the new format should simplify your life.
> 
> > 
> > now , when gcov move to json file, it increase the size a lot which affect
> > the efficiency to parse the data
> 
> I'm aware of the limitation. Note that the JSON format is compressed with
> gzip.
> Can you please share more statistics?

I did not have the real statistics yet as our company is not yet moved to gcc9
(maybe end of this year ).

and even the size of the compressed file is smaller , but we have to unzip and
parse it , right? it just increase the workload . 

however, the stdout option ( -t ) could be very helpful , we don't need to
write to disk and just parse the stdout content.

well, I also notice that the "function_name" in "lines" object is mangled even
I use "--demangled-names" option, can you print the demangled_name when "-m"
option given ? ( yes I know there is demangled name in "functions" part ) . the
reason is: we need to know the exact function name and it's lines, in current
format , we have to find all demangled function name and it's start and end
line number, then check the lines part to assign each lines into functions .

> 
> > , what's worse, we had to revise our code
> > to support the new json format while we need to support the old format in
> > the same time , as our company have many products and each product have many
> > live branches , some of them still using gcc6 version.
> 
> I see. As mentioned, porting to the new format should be fairly simple.
> 
> > 
> > I tried to use older gcov version on the new gcc instructed gcda and gcno
> > file , it did not work.
> 
> Please don't do it.

[Bug c++/88003] ICE on outside definition of inner function-local class in poplevel_class, at cp/name-lookup.c:4325

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

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

commit r11-2642-gc01b22f12291691d1ce89f82211f00eae4398e18
Author: Marek Polacek 
Date:   Mon Aug 10 19:57:27 2020 -0400

c++: Add unfixed test [PR88003]

Now that dg-ice is available, let's try it out.

gcc/testsuite/ChangeLog:

PR c++/88003
* g++.dg/cpp1y/auto-fn61.C: New test.

[Bug target/96562] Rather poor assembly generated for copy-list-initialization in return statement.

[maxim.yegorushkin at gmail dot com]

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

--- Comment #1 from Maxim Egorushkin  ---
Correction:

Span f(unsigned char* p, unsigned char* q) {
return {p, static_cast(q - p)};
}

[Bug target/96562] New: Rather poor assembly generated for copy-list-initialization in return statement.

[maxim.yegorushkin at gmail dot com]

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

Bug ID: 96562
   Summary: Rather poor assembly generated for
copy-list-initialization in return statement.
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maxim.yegorushkin at gmail dot com
  Target Milestone: ---

Rather poor assembly generated for trivial code.

The following code:

template
struct Span {
P begin_;
SizeT size_;
};

Span f(char* p, char* q) {
return {p, static_cast(q - p)};
}

When compiled with gcc-6.1 to gcc-10.2 with options "-O3 -march=skylake
-mtune=skylake" produces unexpectedly long and sub-optimal assembly code:

f(unsigned char*, unsigned char*):
mov QWORD PTR [rsp-16], 0
mov QWORD PTR [rsp-24], rdi
sub rsi, rdi
vmovdqa xmm1, XMMWORD PTR [rsp-24]
vpinsrd xmm0, xmm1, esi, 2
vmovdqa XMMWORD PTR [rsp-24], xmm0
mov rax, QWORD PTR [rsp-24]
mov rdx, QWORD PTR [rsp-16]
ret

clang with the same options produces the expected assembly:

f(unsigned char*, unsigned char*):
mov rdx, rsi
mov rax, rdi
sub edx, eax
ret

Is there a way to make gcc produce the expected assembly, please?

https://gcc.godbolt.org/z/bacGW8

[Bug ipa/96482] [10/11 Regression] Combination of -finline-small-functions and ipa-cp optimisations causes incorrect values being passed to a function since r279523

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

--- Comment #7 from Martin Liška  ---
Fine, I can reproduce that locally, working on that!
Thanks for the instructions.

[Bug middle-end/96561] New: missing warning for buffer overflow with negative offset

[msebor at gcc dot gnu.org]

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

Bug ID: 96561
   Summary: missing warning for buffer overflow with negative
offset
   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: ---

Only two of the four equivalent instances of buffer overflow in the test
program  below are detected.  All four should be.

Even the member into which the store writes isn't mentioned, the store in
'MEM[(int *)p_1(D) + 3B] = 0' in the last two instances can be diagnosed based
on the analysis that starting offset of the access, p_1(D) + 3B, points to one
member of the struct while the ending offset, p_1(D) + 3B + sizeof (int),
points to another.

$ cat t.c && gcc -O2 -S -Wall -Wextra -fdump-tree-vrp=/dev/stdout -xc++ t.c
void* operator new (__SIZE_TYPE__, void *p) { return p; }

struct S { int n; char a[0]; };

void f0 (struct S *p)
{
  new (>a[-1]) int ();// -Wplacement-new (good)
}

void f1 (struct S *p)
{
  p->a[-1] = 0;  // -Warray-bounds (also good)
}

void f2 (struct S *p)
{
  char *q = p->a;
  q[-1] = 0;   // no warning
}

void f3 (struct S *p)
{
  char *q = p->a;
  __builtin_memset (q - 1, 0, sizeof (int));   // no warning
}

t.c: In function ‘void f0(S*)’:
t.c:7:8: warning: placement new constructing an object of type ‘int’ and size
‘4’ in a region of type ‘char [0]’ and size ‘0’ [-Wplacement-new=]
7 |   new (>a[-1]) int ();// -Wplacement-new (good)
  |^

;; Function operator new (_ZnwmPv, funcdef_no=0, decl_uid=2337, cgraph_uid=1,
symbol_order=0)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:



operator new (long unsigned int D.2335, void * p)
{
   [local count: 1073741824]:
  return p_1(D);

}



;; Function operator new (_ZnwmPv, funcdef_no=0, decl_uid=2337, cgraph_uid=1,
symbol_order=0)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:



operator new (long unsigned int D.2335, void * p)
{
   [local count: 1073741824]:
  return p_1(D);

}



;; Function f0 (_Z2f0P1S, funcdef_no=1, decl_uid=2344, cgraph_uid=2,
symbol_order=1)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:



f0 (struct S * p)
{
   [local count: 1073741824]:
  MEM[(int *)p_1(D) + 3B] = 0;
  return;

}



;; Function f0 (_Z2f0P1S, funcdef_no=1, decl_uid=2344, cgraph_uid=2,
symbol_order=1)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:



f0 (struct S * p)
{
   [local count: 1073741824]:
  MEM[(int *)p_1(D) + 3B] = 0;
  return;

}



;; Function f1 (_Z2f1P1S, funcdef_no=2, decl_uid=2350, cgraph_uid=3,
symbol_order=2)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:



t.c: In function ‘void f1(S*)’:
t.c:12:10: warning: array subscript -1 is below array bounds of ‘char [0]’
[-Warray-bounds]
   12 |   p->a[-1] = 0;  // -Warray-bounds (also good)
  |   ~~~^
t.c:3:24: note: while referencing ‘S::a’
3 | struct S { int n; char a[0]; };
  |^
f1 (struct S * p)
{
   [local count: 1073741824]:
  p_2(D)->a[-1] = 0;
  return;

}



;; Function f1 (_Z2f1P1S, funcdef_no=2, decl_uid=2350, cgraph_uid=3,
symbol_order=2)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:



f1 (struct S * p)
{
   [local count: 1073741824]:
  p_2(D)->a[-1] = 0;
  return;

}



;; Function f2 (_Z2f2P1S, funcdef_no=3, decl_uid=2353, cgraph_uid=4,
symbol_order=3)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:



f2 (struct S * p)
{
   [local count: 1073741824]:
  MEM[(char *)p_1(D) + 3B] = 0;
  return;

}



;; Function f2 (_Z2f2P1S, funcdef_no=3, decl_uid=2353, cgraph_uid=4,
symbol_order=3)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:



f2 (struct S * p)
{
   [local count: 1073741824]:
  MEM[(char *)p_1(D) + 3B] = 0;
  return;

}



;; Function f3 (_Z2f3P1S, funcdef_no=4, decl_uid=2357, cgraph_uid=5,
symbol_order=4)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:

_1: char * [1B, +INF]
p_2(D): struct S * VARYING


f3 (struct S * p)
{
  char * _1;

   [local count: 1073741824]:
  _1 =   [(void *)p_2(D) + 3B];
  __builtin_memset (_1, 0, 4);
  

[Bug tree-optimization/96554] -Wall does not include -Wnull-dereference

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
(In reply to Martin Sebor from comment #5)
> The latest trunk of GCC 11 has over 700 distinct instances of the
> -Wnull-dereference warning so some work is still needed before it can be
> enabled in either -Wextra or -Wall.  Here's the breakdown:

It'd be interesting to know how many would still be caught by a
“must” version of the option, if it was split into a may/must pair
(as per earlier suggestions in Wnull-dereference).  Maybe we could
emulate that by sticking in a postdominannce test and rerunning
the numbers…

[Bug libstdc++/94681] filesystem::sysmlink_status using stat instead of lstat when --disable-libstdcxx-filesystem-ts

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2638-g5b065f0563262a0d6cd1fea8426913bfdd841301
Author: Jonathan Wakely 
Date:   Mon Aug 10 18:58:14 2020 +0100

libstdc++: Fix build for targets without lstat [PR 94681]

libstdc++-v3/ChangeLog:

PR libstdc++/94681
* src/c++17/fs_ops.cc (read_symlink): Use posix::lstat instead
of calling ::lstat directly.
* src/filesystem/ops.cc (read_symlink): Likewise.

[Bug testsuite/96525] new test gcc.target/powerpc/pr96493.c fails

[bergner at gcc dot gnu.org]

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

--- Comment #7 from Peter Bergner  ---
(In reply to seurer from comment #6)
> That changed the test to unsupported on the p8 where it had failed
> previously.
[snip]
> # of unsupported tests1

That is what I would expect on a system with an old binutils.  Do you have a
testsuite run that has a newer power10 enabled binutils?  Then hopefully, you
should see a PASS of the dg-do link command.

[Bug c++/96560] New: Substitution triggers compile-time error when it shouldn't

[mpolacek at gcc dot gnu.org]

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

Bug ID: 96560
   Summary: Substitution triggers compile-time error when it
shouldn't
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This triggers the static_assert while it shouldn't, because DR 1227 says "The
substitution proceeds in lexical order and stops when a condition that causes
deduction to fail is encountered."  Compiles with clang++/EDG.

template
struct enable_if { };

template
struct enable_if {
  using type = T;
};

template
struct hard_error {
  static_assert(sizeof(T) == 0);
  static inline constexpr bool value = true;
};

template
struct always_false {
  static inline constexpr bool value = false;
};

template
int foo (int, typename enable_if::value, int>::type = 0,
  typename enable_if::value, int>::type = 0 )
{
  return 0;
}

template
char const *foo (long)
{
  return "";
}

int
main ()
{
  char const *sz = foo(0);
}

[Bug libstdc++/90704] [LWG 3430] filesystem::path overloads for file streams are not conforming

[manx-bugzilla at problemloesungsmaschine dot de]

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

--- Comment #8 from Jörn Heusipp  ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Jörn Heusipp from comment #5)

> > and just pray and hope that libstdc++ will not change its non-conforming
> > SFINAE-using implementation details to some other non-conforming
> > implementation details in some future version.
> 
> Or just convert to filesystem::path explicitly.

I'd rather not use std::filesystem whatsoever at all than polluting the whole
code base with redundant explicit conversions. This is exactly what I am trying
to avoid here in the first place by implementing implicit conversion (which the
standard allows me to do). Your implementation breaks this, because you decided
to disregard the standard in order to break string_view conversions. If you
want to break string_view, break it. But please do so selectively and do not
break other implicit conversions at the same time. There is no reason to. This
is just sad.

> > Can you guarantee, that you wont ever change your non-conforming SFINAE
> > implementation whatsoever at all? If not, please just fix it. The standard
> > is absolutely clear here.
> 
> The standard is flawed and no longer follows its own design. I want to get
> some clarity about the intended design.

The intended design of std::basic_fstream::basic_fstream(const
filesystem::path& s, ios_base::openmode mode = ios_base::in | ios_base::out);
(literally from the standard) is unambiguously clear to me. I am allowed to
provide types which are implicitly convertible (as long as no other implicit
conversion causes ambiguity with other overloads). Again, this is IMO unrelated
to whatever the intention for std::string_view might or might not have been.
The fact that they rely on the same overload is coincidence. Are you arguing
that no user-defined type should ever be implicitly convertible to
std::filesystem::path? If so, can you provide reasoning?

[Bug rtl-optimization/48037] Missed optimization: unnecessary register moves

[glisse at gcc dot gnu.org]

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

--- Comment #10 from Marc Glisse  ---
We now generate just
sqrtpd  %xmm0, %xmm0
for 2 and 4,
sqrtpd  (%rdi), %xmm0
for 3, and
movupd  (%rdi), %xmm0
sqrtpd  %xmm0, %xmm0
for 1 (for alignment reasons I guess, the movu disappears with -mavx).

Should we close it as fixed? Or update the testcase to perform a different
operation that isn't recognized?

[Bug target/96559] New: Wrong code with -march=z900 -mtune=z9-109

[marxin at gcc dot gnu.org]

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

Bug ID: 96559
   Summary: Wrong code with -march=z900 -mtune=z9-109
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: krebbel at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: s390x-linux-gnu

For the following test-case (reduced from Firefox):

$ cat ff.ii
char compute___trans_tmp_3;
long CountLeadingZeroes64_aValue;
void CeilingLog2() {
  compute___trans_tmp_3 = __builtin_clzll(CountLeadingZeroes64_aValue);
}

we end with:

$ ./xgcc -B. ff.ii -march=z900 -mtune=z9-109 -S -o/dev/stdout -O1
...
.globl __clzdi2
.align  8
.globl _Z11CeilingLog2v
.type   _Z11CeilingLog2v, @function
_Z11CeilingLog2v:
.LFB0:
stmg%r12,%r15,96(%r15)
.LCFI0:
aghi%r15,-160
.LCFI1:
larl%r12,.LANCHOR0
lg  %r2,0(%r12)
brasl   %r14,__clzdi2
stc %r2,8(%r12)
lg  %r4,272(%r15)
lmg %r12,%r15,256(%r15)

which is bogus as __clzdi2 points to the very same place as _Z11CeilingLog2v.
So 
 brasl  %r14,__clzdi2 is an infinite loop.

The .globl for __clzdi2 is emitted in the following back-trace:

Breakpoint 5, default_globalize_label (stream=0x2712300, name=0x77700d50
"__clzdi2") at /home/marxin/Programming/gcc/gcc/varasm.c:7321
7321  fputs (GLOBAL_ASM_OP, stream);
Missing separate debuginfos, use: zypper install
libmpfr6-debuginfo-4.1.0-1.1.x86_64 libzstd1-debuginfo-1.4.5-2.2.x86_64
(gdb) bt
#0  default_globalize_label (stream=0x2712300, name=0x77700d50 "__clzdi2")
at /home/marxin/Programming/gcc/gcc/varasm.c:7321
#1  0x0125d536 in default_external_libcall (fun=0x77764648) at
/home/marxin/Programming/gcc/gcc/targhooks.c:107
#2  0x016c5d15 in assemble_external_libcall (fun=0x77764648) at
/home/marxin/Programming/gcc/gcc/varasm.c:2506
#3  0x00cf28f6 in emit_library_call_value_1 (retval=1,
orgfun=0x77764648, value=0x0, fn_type=, outmode=E_SImode,
nargs=1, args=) at /home/marxin/Programming/gcc/gcc/calls.c:5272
#4  0x010dd18b in emit_library_call_value (fun=0x77764648,
value=0x0, fn_type=LCT_CONST, outmode=E_SImode, arg1=0x77764630,
arg1_mode=E_DImode) at /home/marxin/Programming/gcc/gcc/rtl.h:4245
#5  0x010d06d2 in expand_unop (mode=E_DImode, unoptab=clz_optab,
op0=0x77764630, target=0x777644f8, unsignedp=1) at
/home/marxin/Programming/gcc/gcc/optabs.c:3059
#6  0x00cd49d5 in expand_builtin_unop (target_mode=E_SImode,
exp=, target=0x777644f8, subtarget=, op_optab=clz_optab) at /home/marxin/Programming/gcc/gcc/tree.h:3296
#7  0x00cea061 in expand_builtin (exp=,
target=, subtarget=0x0, mode=E_SImode, ignore=0) at
/home/marxin/Programming/gcc/gcc/builtins.c:8236
#8  0x00e38f5d in expand_expr_real_1 (exp=,
target=, tmode=E_SImode, modifier=EXPAND_NORMAL,
alt_rtl=0x7fffdb48, inner_reference_p=) at
/home/marxin/Programming/gcc/gcc/expr.c:11237
#9  0x00e42281 in store_expr (exp=,
target=0x777644f8, call_param_p=, nontemporal=, reverse=) at /home/marxin/Programming/gcc/gcc/expr.c:5852
#10 0x00e444cf in expand_assignment (to=,
from=, nontemporal=) at
/home/marxin/Programming/gcc/gcc/expr.c:5588
#11 0x00d09e34 in expand_call_stmt (stmt=0x77fc4510) at
/home/marxin/Programming/gcc/gcc/cfgexpand.c:2701
#12 expand_gimple_stmt_1 (stmt=) at
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3682
#13 expand_gimple_stmt (stmt=) at
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3847
#14 0x00d0f60b in expand_gimple_basic_block (bb=,
disable_tail_calls=) at
/home/marxin/Programming/gcc/gcc/cfgexpand.c:5888
#15 0x00d110b7 in (anonymous namespace)::pass_expand::execute
(this=, fun=0x77759000) at
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6572
#16 0x0112fd75 in execute_one_pass (pass=) at /home/marxin/Programming/gcc/gcc/passes.c:2509
#17 0x0113009a in execute_pass_list_1 (pass=) at /home/marxin/Programming/gcc/gcc/passes.c:2597
#18 0x01130123 in execute_pass_list (fn=0x77759000, pass=) at /home/marxin/Programming/gcc/gcc/passes.c:2608
#19 0x00d44cec in cgraph_node::expand (this=) at
/home/marxin/Programming/gcc/gcc/context.h:48
#20 0x00d462ff in expand_all_functions () at
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2472
#21 symbol_table::compile (this=0x775d9000) at
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2835
#22 0x00d48713 in symbol_table::compile (this=0x775d9000) at
/home/marxin/Programming/gcc/gcc/cgraphunit.c:3013
#23 symbol_table::finalize_compilation_unit (this=0x775d9000) at
/home/marxin/Programming/gcc/gcc/cgraphunit.c:3013
#24 0x01265fae in 

[Bug target/50829] avx extra copy for _mm256_insertf128_pd

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||10.1.0
 Resolution|--- |FIXED
  Known to fail||9.3.0

--- Comment #14 from Marc Glisse  ---
This was fixed (by Jakub I think).

[Bug fortran/96556] [11.0 regression] ICE via segmentation violation

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #7 from Thomas Koenig  ---
Fixed, closing.

Thanks for the bug report and the quick identification of the culprit!

[Bug libstdc++/90704] [LWG 3430] filesystem::path overloads for file streams are not conforming

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
btw in practice the fact this is SUSPENDED today is absolutely no different to
the status yesterday. It didn't work in GCC yesterday and it doesn't work
today. The only change is I've publicly stated my intention to discuss this
with the committee before doing anything here.

I could revert the status, and still do nothing here, but that serves no
purpose.

[Bug fortran/96556] [11.0 regression] ICE via segmentation violation

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Thomas Kथà¤nig :

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

commit r11-2636-ga5da50ed65a835dc1ed6179e3f2b6164fd6e4969
Author: Thomas Koenig 
Date:   Mon Aug 10 19:10:26 2020 +0200

Fix NULL pointer dereference in doloop_contained_function_call.

gcc/fortran/ChangeLog:

PR fortran/96556
* frontend-passes.c (doloop_contained_function_call):
Do not dereference a NULL pointer for value.function.esym.

gcc/testsuite/ChangeLog:

PR fortran/96556
* gfortran.dg/do_check_15.f90: New test.

[Bug libstdc++/90704] [LWG 3430] filesystem::path overloads for file streams are not conforming

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jörn Heusipp from comment #5)
> > Status: SUSPENDED
> 
> Well, coming from bug 95642, which has been marked as a duplicate of this
> bug, this is *very* disappointing.
> 
> 
> The C++17 standard absolutely clearly specifies that the constructor is
> overloaded for std::filesystem::path. libstdc++'s SFINAE implementation is
> incompatible because it fails for user-defined types that are implicitly
> convertible to std::filesystem::path.

And also for string_view, because that's convertible to filesystem::path, and
that is the topic of the issue reported against the standard.

> In order to at all be able to sensibly use libstdc++ std::filesystem::path
> in my codebase, I would have to put this awful work-around (making tons of
> assumptions about libstdc++'s enable_if expression) into my own type
> mpt::PathString:

Or you can just convert it to filesystem::path explicitly before passing it to
fstream members.


> and just pray and hope that libstdc++ will not change its non-conforming
> SFINAE-using implementation details to some other non-conforming
> implementation details in some future version.

Or just convert to filesystem::path explicitly.

> Can you guarantee, that you wont ever change your non-conforming SFINAE
> implementation whatsoever at all? If not, please just fix it. The standard
> is absolutely clear here.

The standard is flawed and no longer follows its own design. I want to get some
clarity about the intended design.

> After having said all this, I am not even sure anymore that this bug report
> here actually is a duplicate of my bug 95642. I am concerned about implicit
> conversion to std::filesystem::path not working, while this bug report is
> concerned about std::string_view not working. Please consider re-opening bug
> 95642.

They're exactly the same.

string_view is expected to work by converting to filesystem::path, which is the
same as your type.

[Bug target/96558] New: [11 Regression] ICE in extract_constrain_insn, at recog.c:2195 (error: insn does not satisfy its constraints)

[asolokha at gmx dot com]

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

Bug ID: 96558
   Summary: [11 Regression] ICE in extract_constrain_insn, at
recog.c:2195 (error: insn does not satisfy its
constraints)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu-gcc

gcc-11.0.0-alpha20200809 snapshot (g:71197a5d13d0b540a9b5efe7ae2512d76386e9d1)
ICEs when compiling the following testcase w/ -O2 -fno-expensive-optimizations
-fno-gcse:

int ky;
long int h1;
__int128 f1;

int
sd (void);

int __attribute__ ((simd))
i8 (void)
{
  __int128 vh;

  if (sd () == 0)
h1 = 0;

  do
{
  long int lf = h1;
  long int w1 = f1;

  if (w1 == 0)
lf = 0;
  else
lf = lf && w1;

  ky += lf;

  vh = lf | f1;
  f1 = 1;
}
  while (vh < (f1 ^ 2));

  return 0;
}

% x86_64-unknown-linux-gnu-gcc-11.0.0 -O2 -fno-expensive-optimizations
-fno-gcse -c yocbyzz3.c
yocbyzz3.c: In function 'i8.simdclone.6':
yocbyzz3.c:34:1: error: insn does not satisfy its constraints:
   34 | }
  | ^
(insn 157 14 158 3 (parallel [
(set (reg:DI 20 xmm0 [orig:121 _53 ] [121])
(const_int 0 [0]))
(clobber (reg:CC 17 flags))
]) "yocbyzz3.c":13:6 68 {*movdi_xor}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
during RTL pass: cprop_hardreg
yocbyzz3.c:34:1: internal compiler error: in extract_constrain_insn, at
recog.c:2195
0x68e957 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200809/work/gcc-11-20200809/gcc/rtl-error.c:108
0x68e97d _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200809/work/gcc-11-20200809/gcc/rtl-error.c:118
0x68cfb5 extract_constrain_insn(rtx_insn*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200809/work/gcc-11-20200809/gcc/recog.c:2195
0xcf76fb copyprop_hardreg_forward_1
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200809/work/gcc-11-20200809/gcc/regcprop.c:802
0xcf864e execute
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200809/work/gcc-11-20200809/gcc/regcprop.c:1367

[Bug fortran/96556] [11.0 regression] ICE via segmentation violation

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
One-line fix.

[Bug ipa/96482] [10/11 Regression] Combination of -finline-small-functions and ipa-cp optimisations causes incorrect values being passed to a function since r279523

[yevh.kolesnikov at gmail dot com]

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

--- Comment #6 from Yevhenii Kolesnikov  ---
(In reply to Jan Hubicka from comment #4)
> that patch makes ccp to actually use the bit info ipa-cp determines. Before
> we used it only to detect pointer alignments if I remember correctly. So it
> looks like propagation bug uncovered by the change.  Smaller testcase or
> reproduction steps would be indeed welcome.

Unfortunately, I wasn't able to create a standalone reproducer yet. Even in
mesa it's sometimes finicky to catch this bug. For example, simply adding an
fprintf to aforementioned function addr_to_index, prevents it from inlining.  

As for the reproduction steps with mesa:

1. Build mesa as described in comment #5
2. LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/builds/mesa-bug/lib/ mpv any_video.mp4
3. mesa crashes. Backtrace will slightly differ depending on the driver in use.
So far, I've been describing behavior on "iris" driver (default driver for
Intel GPUs). I assume, similar optimisation patterns occur in several places,
when building mesa.

[Bug c++/96497] Compare std::variant with int using C++20 <=> is not a constant expression

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Should be fixed for 11, I think we should backport to 10.3 too eventually.

[Bug fortran/96556] [11.0 regression] ICE via segmentation violation

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-08-10
   Keywords||ice-on-valid-code
   Priority|P3  |P4
 CC||tkoenig at gcc dot gnu.org

--- Comment #4 from Dominique d'Humieres  ---
Likely r11-2578.

[Bug libstdc++/90704] [LWG 3430] filesystem::path overloads for file streams are not conforming

[manx-bugzilla at problemloesungsmaschine dot de]

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

--- Comment #5 from Jörn Heusipp  ---

> Status: SUSPENDED

Well, coming from bug 95642, which has been marked as a duplicate of this bug,
this is *very* disappointing.


The C++17 standard absolutely clearly specifies that the constructor is
overloaded for std::filesystem::path. libstdc++'s SFINAE implementation is
incompatible because it fails for user-defined types that are implicitly
convertible to std::filesystem::path.
In order to at all be able to sensibly use libstdc++ std::filesystem::path in
my codebase, I would have to put this awful work-around (making tons of
assumptions about libstdc++'s enable_if expression) into my own type
mpt::PathString:
+   // work-around for GCC bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95642 /
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90704
+   mpt::PathString & make_preferred()
+   {
+   *this =
mpt::PathString::FromFsPath(std::filesystem::path{path}.make_preferred());
+   return *this;
+   }
+   mpt::PathString filename() const
+   {
+   return
mpt::PathString::FromFsPath(std::filesystem::path{path}.filename());
+   }
+   std::filesystem::path c_str() const
+   {
+   return std::filesystem::path{path}; 
+   }
and just pray and hope that libstdc++ will not change its non-conforming
SFINAE-using implementation details to some other non-conforming implementation
details in some future version.
Can you guarantee, that you wont ever change your non-conforming SFINAE
implementation whatsoever at all? If not, please just fix it. The standard is
absolutely clear here.
If you insist on doing something non-standard-conforming because of
std::string_view, at the very least please do it for string_view only, without
breaking behaviour for std::filesystem::path. Compatibility with
std::experimental::filesystem::path can also be implemented without breaking
the standard-specified std::filesystem::path overloads.


The issue risen by https://cplusplus.github.io/LWG/issue3430 about the fear of
implicit allocation is not convincing to me. std::basic_fstream accesses the
filesystem, inducing all kinds of memory allocations, in-kernel blocking, and
disk I/O. Some additional user space allocations just do not matter here. None
of the call chain is specified noexcept either.
While the issue of desiring std::string_view overloads itself appears
reasonable to me, I fail to see why this issue should wait on that particular
standard change. Even if std::string_view overloads existed, the current
libstdc++ implementation would still be non-conforming for the
std::filesystem::path overload and would need to be changed in exactly the same
way as according to the current standard.


The suggestion of forcing std::filesystem::path arguments to be exactly
std::filesystem::path (i.e. making the current libstdc++ conforming by forcing
the bug on everyone else) breaks backwards compatibility for other (currently
conforming) implementations and IMO is also wrong on a higher level. There
exist legitimate and semantically sound reasons to have user-defined types that
are implicitly convertible to std::filesystem::path (std::filesystem::path's
greedy behaviour of silently doing enconding conversions from char (which may
be in locale encoding or utf8 in C++17, no way to tell) and thereby potentially
losing data, being one of them, making it impossible to use it safely by
itself). In the end, IMO std::filesystem::path should never have been
implicitly convertible from a string in the first place. *This* is where the
problems began. A string is not necessarily a path, which is why implicit
conversion was/is wrong here. I doubt that will ever change by now, though,
making it even more important to be able to wrap std::filesystem::path in an
encoding-type-safe user-defined type.


So, there are a couple of things wrong related to std::filesystem::path. The
only way to sanely use it, is by strictly adhering to the agreed-upon standard.
Delaying conformance with the standard until after some unrelated (to the
std::filesystem::path overload) problems are resolved in the standard makes
little sense to me, as it makes std::filesystem::path mostly unusable (without
extremely ugly work-arounds) in the meantime (which could easily be multiple
years) in code portable between different implementations.

libstdc++ needs to get fixed as soon as possible. It is currently blocking
progress in portable downstream users.


After having said all this, I am not even sure anymore that this bug report
here actually is a duplicate of my bug 95642. I am concerned about implicit
conversion to std::filesystem::path not working, while this bug report is
concerned about std::string_view not working. Please consider re-opening bug
95642.

[Bug fortran/96556] [11.0 regression] ICE via segmentation violation

[juergen.reuter at desy dot de]

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

--- Comment #3 from Jürgen Reuter  ---
Created attachment 49038
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49038=edit
Final reproducer, some 70 lines

[Bug c++/96557] Diagnostics: Can you tell me why it's not a constant expression?

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||diagnostic
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2020-08-10

--- Comment #1 from Marek Polacek  ---
That would be great to have.

[Bug testsuite/96525] new test gcc.target/powerpc/pr96493.c fails

[seurer at gcc dot gnu.org]

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

--- Comment #6 from seurer at gcc dot gnu.org ---
That changed the test to unsupported on the p8 where it had failed previously.

Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ power10_hw_available2538527.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -mcpu=power10  -lm  -o
power10_hw_available2538527.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ power10_hw_available2538527.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -mcpu=power10 -lm -o
power10_hw_available2538527.exe
Assembler messages:
Error: invalid switch -mpower10
Error: unrecognized option -mpower10
compiler exited with status 1
Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/-fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never 
-fdiagnostics-urls=never  -c -o powerpc_elfv22538527.o powerpc_elfv22538527.c  
 (timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -c -o powerpc_elfv22538527.o powerpc_elfv22538527.c
Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/-fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never 
-fdiagnostics-urls=never  -mcpu=power10 -c -o power10_ok2538527.o
power10_ok2538527.c(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -mcpu=power10 -c -o power10_ok2538527.o
power10_ok2538527.c
Assembler messages:
Error: invalid switch -mpower10
Error: unrecognized option -mpower10
compiler exited with status 1
UNSUPPORTED: gcc.target/powerpc/pr96493.c

. . .

=== gcc Summary ===

# of unsupported tests  1

[Bug fortran/96101] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2398

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from Dominique d'Humieres  ---
The patch works as expected and even fixes pr91862.

[Bug c++/96557] New: Diagnostics: Can you tell me why it's not a constant expression?

[barry.revzin at gmail dot com]

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

Bug ID: 96557
   Summary: Diagnostics: Can you tell me why it's not a constant
expression?
   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: ---

Consider:

struct X {
char storage[100] = {};
char const* head = storage;
};

void f() {
constexpr X x = {};
}

gcc correctly rejects this with:

error: 'X{"", ((const char*)(& x.X::storage))}' is not a constant expression
7 | constexpr X x = {};
  |  ^

It'd be great if the error here actually indicated _why_ it's not a constant
expression (or how to fix it). clang does a little bit better:

:7:17: error: constexpr variable 'x' must be initialized by a constant
expression
constexpr X x = {};
^   ~~
:7:17: note: pointer to subobject of 'x' is not a constant expression
:7:17: note: declared here

But ideally we get some message about specifically 'head' pointing to 'storage'
and a fixup suggesting making the variable x static.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
When you choose RESOLVED you can pick various types of resolution, FIXED,
INVALID, DUPLICATE, MOVED, WORKSFORME etc.

[Bug c++/96543] null check on template pointer parameter fails

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
No, it's fine. I've categorized it as a diagnostic bug, i.e. a bug in a
warning.

[Bug libstdc++/94681] filesystem::sysmlink_status using stat instead of lstat when --disable-libstdcxx-filesystem-ts

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Thanks, I thought this might reveal some new issues :-)

I'll fix it asap.

[Bug fortran/96556] [11.0 regression] ICE via segmentation violation

[juergen.reuter at desy dot de]

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

--- Comment #2 from Jürgen Reuter  ---
Created attachment 49037
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49037=edit
2nd reproducer, single file, shortening further

[Bug c++/96497] Compare std::variant with int using C++20 <=> is not a constant expression

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2635-g5c64df80df274c753bfc8415bd902e1180e76f6a
Author: Jakub Jelinek 
Date:   Mon Aug 10 17:53:46 2020 +0200

c++: Fix constexpr evaluation of SPACESHIP_EXPR [PR96497]

The following valid testcase is rejected, because
cxx_eval_binary_expression
is called on the SPACESHIP_EXPR with lval = true, as the address of the
spaceship needs to be passed to a method call.
After recursing on the operands and calling genericize_spaceship which
turns
it into a TARGET_EXPR with initialization, we call
cxx_eval_constant_expression
on it which succeeds, but then we fall through into code that will
VERIFY_CONSTANT (r) which FAILs because it is an address of a variable. 
Rather
than avoiding that for lval = true and SPACESHIP_EXPR, the patch just tail
calls cxx_eval_constant_expression - I believe that call should perform all
the needed verifications.

2020-08-10  Jakub Jelinek  

PR c++/96497
* constexpr.c (cxx_eval_binary_expression): For SPACESHIP_EXPR,
tail
call cxx_eval_constant_expression after genericize_spaceship to
avoid
undesirable further VERIFY_CONSTANT.

* g++.dg/cpp2a/spaceship-constexpr3.C: New test.

[Bug tree-optimization/96554] -Wall does not include -Wnull-dereference

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   Last reconfirmed||2020-08-10
  Component|c   |tree-optimization
 Blocks||86172
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #5 from Martin Sebor  ---
The latest trunk of GCC 11 has over 700 distinct instances of the
-Wnull-dereference warning so some work is still needed before it can be
enabled in either -Wextra or -Wall.  Here's the breakdown:

DiagnosticCount   UniqueFiles
-Wnull-dereference 3862  713  168
-Wimplicit-fallthrough=   411
-Wstringop-truncation 311
-Wreturn-local-addr   211
-Wmaybe-uninitialized 222

-Wnull-dereference Instances:
  cc1plus: warning: potential null pointer dereference [-Wnull-dereference]
  /src/gcc/trunk/gcc/analyzer/checker-path.cc:737
  /src/gcc/trunk/gcc/analyzer/checker-path.cc:745
  /src/gcc/trunk/gcc/analyzer/checker-path.cc:958
  /src/gcc/trunk/gcc/analyzer/diagnostic-manager.cc:339
  /src/gcc/trunk/gcc/analyzer/diagnostic-manager.cc:456
  /src/gcc/trunk/gcc/analyzer/diagnostic-manager.cc:777
  /src/gcc/trunk/gcc/analyzer/diagnostic-manager.cc:778
  /src/gcc/trunk/gcc/analyzer/engine.cc:1844
  /src/gcc/trunk/gcc/analyzer/engine.cc:2683
  /src/gcc/trunk/gcc/analyzer/engine.cc:3570
  /src/gcc/trunk/gcc/analyzer/engine.cc:3656
  /src/gcc/trunk/gcc/analyzer/engine.cc:834
  /src/gcc/trunk/gcc/analyzer/exploded-graph.h:263
  /src/gcc/trunk/gcc/analyzer/program-point.h:225
  /src/gcc/trunk/gcc/analyzer/program-state.cc:134
  /src/gcc/trunk/gcc/analyzer/program-state.cc:241
  /src/gcc/trunk/gcc/analyzer/program-state.cc:266
  /src/gcc/trunk/gcc/analyzer/program-state.cc:267
  /src/gcc/trunk/gcc/analyzer/program-state.cc:472
  /src/gcc/trunk/gcc/analyzer/program-state.cc:473
  /src/gcc/trunk/gcc/analyzer/program-state.cc:488
  /src/gcc/trunk/gcc/analyzer/program-state.cc:489
  /src/gcc/trunk/gcc/analyzer/program-state.cc:514
  /src/gcc/trunk/gcc/analyzer/program-state.cc:584
  /src/gcc/trunk/gcc/analyzer/program-state.cc:585
  /src/gcc/trunk/gcc/analyzer/region-model.cc:1486
  /src/gcc/trunk/gcc/analyzer/region-model.cc:1571
  /src/gcc/trunk/gcc/analyzer/region-model.cc:2126
  /src/gcc/trunk/gcc/analyzer/region-model.cc:2606
  /src/gcc/trunk/gcc/analyzer/region-model.cc:424
  /src/gcc/trunk/gcc/analyzer/region-model.h:1195
  /src/gcc/trunk/gcc/analyzer/region-model.h:121
  /src/gcc/trunk/gcc/analyzer/region-model.h:129
  /src/gcc/trunk/gcc/analyzer/region-model.h:1583
  /src/gcc/trunk/gcc/analyzer/region-model.h:1587
  /src/gcc/trunk/gcc/analyzer/region-model.h:484
  /src/gcc/trunk/gcc/analyzer/region-model.h:869
  /src/gcc/trunk/gcc/analyzer/region-model.h:882
  /src/gcc/trunk/gcc/analyzer/region-model.h:912
  /src/gcc/trunk/gcc/analyzer/state-purge.h:95
  /src/gcc/trunk/gcc/analyzer/supergraph.cc:177
  /src/gcc/trunk/gcc/analyzer/supergraph.cc:198
  /src/gcc/trunk/gcc/analyzer/supergraph.cc:221
  /src/gcc/trunk/gcc/analyzer/supergraph.cc:240
  /src/gcc/trunk/gcc/analyzer/supergraph.h:106
  /src/gcc/trunk/gcc/analyzer/supergraph.h:126
  /src/gcc/trunk/gcc/analyzer/supergraph.h:132
  /src/gcc/trunk/gcc/analyzer/supergraph.h:138
  /src/gcc/trunk/gcc/analyzer/supergraph.h:144
  /src/gcc/trunk/gcc/analyzer/supergraph.h:163
  /src/gcc/trunk/gcc/auto-profile.c:1517
  /src/gcc/trunk/gcc/bb-reorder.c:467
  /src/gcc/trunk/gcc/bitmap.h:393
  /src/gcc/trunk/gcc/bitmap.h:532
  /src/gcc/trunk/gcc/bitmap.h:576
  /src/gcc/trunk/gcc/bitmap.h:579
  /src/gcc/trunk/gcc/caller-save.c:906
  /src/gcc/trunk/gcc/calls.c:1960
  /src/gcc/trunk/gcc/c/c-parser.c:4442
  /src/gcc/trunk/gcc/c-family/c-ada-spec.c:1905
  /src/gcc/trunk/gcc/c-family/c-attribs.c:3906
  /src/gcc/trunk/gcc/c-family/c-common.c:721
  /src/gcc/trunk/gcc/cfg.c:338
  /src/gcc/trunk/gcc/cfgcleanup.c:2143
  /src/gcc/trunk/gcc/cfgcleanup.c:2409
  /src/gcc/trunk/gcc/cfgloop.c:332
  /src/gcc/trunk/gcc/cfgloop.h:532
  /src/gcc/trunk/gcc/cfgloop.h:541
  /src/gcc/trunk/gcc/cfgrtl.c:1170
  /src/gcc/trunk/gcc/cfgrtl.c:4358
  /src/gcc/trunk/gcc/cfgrtl.c:443
  /src/gcc/trunk/gcc/cfgrtl.c:530
  /src/gcc/trunk/gcc/cgraphbuild.c:403
  /src/gcc/trunk/gcc/cgraph.c:1971
  /src/gcc/trunk/gcc/cgraph.c:2003
  /src/gcc/trunk/gcc/cgraph.c:3089
  /src/gcc/trunk/gcc/cgraph.c:3298
  /src/gcc/trunk/gcc/cgraph.c:3848
  /src/gcc/trunk/gcc/cgraph.c:3875
  /src/gcc/trunk/gcc/cgraphclones.c:186
  /src/gcc/trunk/gcc/cgraphclones.c:259
  /src/gcc/trunk/gcc/cgraph.h:1350
  /src/gcc/trunk/gcc/cgraph.h:1356
  /src/gcc/trunk/gcc/cgraph.h:2189
  

[Bug fortran/96556] [11.0 regression] ICE via segmentation violation

[juergen.reuter at desy dot de]

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

--- Comment #1 from Jürgen Reuter  ---
Created attachment 49036
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49036=edit
First reproducer

[Bug fortran/96556] New: [11.0 regression] ICE via segmentation violation

[juergen.reuter at desy dot de]

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

Bug ID: 96556
   Summary: [11.0 regression] ICE via segmentation violation
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

The attached code (I will shorten the reproducer soon) gives the following ICE
below. The offending commit should have taken place between Sunday Aug 9 and
now:
gfortran  -c polarizations.f90
f951: internal compiler error: Segmentation fault
0xe01a4f crash_signal
../../gcc/toplev.c:327
0x8bc210 gfc_sym_get_dummy_args(gfc_symbol*)
../../gcc/fortran/symbol.c:5239
0x960d46 doloop_contained_function_call
../../gcc/fortran/frontend-passes.c:2336
0x965b75 gfc_expr_walker(gfc_expr**, int (*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5188
0x968045 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5613
0x9699d0 doloop_code
../../gcc/fortran/frontend-passes.c:2619
0x967f79 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5298
0x9680df gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5621
0x9680df gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5621
0x9687f8 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5324
0x9680df gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int
(*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5621
0x9690fb doloop_warn
../../gcc/fortran/frontend-passes.c:3051
0x969120 doloop_warn
../../gcc/fortran/frontend-passes.c:3056
0x9695fa gfc_run_passes(gfc_namespace*)
../../gcc/fortran/frontend-passes.c:156
0x884d07 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17344
0x884d07 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17317
0x8777e1 gfc_parse_file()
../../gcc/fortran/parse.c:6488
0x8c90ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:71: recipe for target 'polarizations.o' failed

[Bug c++/96555] New: "template argument involves template parameter(s)" with dot or arrow operator in partial specialization

[arthur.j.odwyer at gmail dot com]

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

Bug ID: 96555
   Summary: "template argument involves template parameter(s)"
with dot or arrow operator in partial specialization
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

// https://godbolt.org/z/Kc98ea
struct A { int x; };
extern A a;
template struct B {};
template
struct B {};


:5:8: error: template argument '(int)sizeof (a.x)' involves template
parameter(s)
5 | struct B {};
  |^


GCC seems to have a problem only with expressions involving the dot operator
(e.g. `sizeof(a.x)`) and the arrow operator (e.g. `sizeof(p->x)`), but not any
other operators, which leads me to believe that the root cause here is related
to the root cause of bug 96215.

Grepbait: template argument involves template parameters

Same error message in different situations, all involving partial
specializations but none involving dot or arrow specifically: bug 67593, bug
83426, bug 90099

[Bug fortran/93671] gfortran 8-10 ICE on intrinsic assignment to allocatable derived-type component of coarray

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #3 from vehre at gcc dot gnu.org ---
Patch at https://gcc.gnu.org/pipermail/fortran/2020-August/054865.html

Waiting for review.

[Bug tree-optimization/96542] Failure to optimize simple code to a constant when storing part of the operation in a variable

[amacleod at redhat dot com]

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

--- Comment #6 from Andrew Macleod  ---
Likewise, for

unsigned
baz (unsigned int x)
{
  if (x >= 4) return 32;
  return (-1U >> x) * 16;
}


=== BB 2 
x_3(D)  unsigned int VARYING
_4  UNDEFINED
 :
if (x_3(D) > 3)
  goto ; [INV]
else
  goto ; [INV]

2->3  (T) x_3(D) :  unsigned int [4, +INF]
2->4  (F) x_3(D) :  unsigned int [0, 3]

=== BB 3 
_4  UNDEFINED
 :
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]


=== BB 4 
x_3(D)  unsigned int [0, 3]
 :
_1 = 4294967295 >> x_3(D);
_4 = _1 * 16;
_1 : unsigned int [536870911, +INF]

0x >> [0,3] is currently producing [0x2FFF, 0x]

again making operator_rshift capable of generating multi-ranges,

0x >> [0,3] should produce
[0x2FFF, 0x2FFF][0x4FFF, 0x4FFF][0x8FFF,
0x8FFF][0x, 0x] 

and then _4 = _1 *16 should automatically produce: [0xFFF0, 0xFFF0]
I think multiply does that today, if its given the proper input.




=== BB 5 
_4  unsigned int VARYING
 :
# _2 = PHI <32(3), _4(4)>
return _2;

And then this PHI will have the constant propagated and become:
# _2 = PHI <32(3), 0xFFF0(4)>
return _2

ANd given that, presumably phi-opt or maybe even VRPs simplfication will turn
that into the desired conditional once the constant is calculated.

[Bug libstdc++/94681] filesystem::sysmlink_status using stat instead of lstat when --disable-libstdcxx-filesystem-ts

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #5 from Christophe Lyon  ---
The commit r11-2633 broke the build of libstdc++ on aarch64-none-elf. My build
logs say:
/tmp/7968837_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:
In function 'std::filesystem::__cxx11::path std::filesystem::read_symlink(const
std::filesystem::__cxx11::path&, std::error_code&)':
/tmp/7968837_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:1178:9:
error: '::lstat' has not been declared; did you mean
'std::filesystem::__gnu_posix::lstat'?
 1178 |   if (::lstat(p.c_str(), ))
  | ^
  | std::filesystem::__gnu_posix::lstat
In file included from
/tmp/7968837_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/fs_ops.cc:58:
/tmp/7968837_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/c++17/../filesystem/ops-common.h:131:14:
note: 'std::filesystem::__gnu_posix::lstat' declared here
  131 |   inline int lstat(const char* path, stat_type* buffer)
  |  ^
make[5]: *** [Makefile:572: fs_ops.lo] Error 1
make[5]: Leaving directory
'/tmp/7968837_9.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/src/c++17'
make[4]: *** [Makefile:732: all-recursive] Error 1

[Bug ipa/96482] [10/11 Regression] Combination of -finline-small-functions and ipa-cp optimisations causes incorrect values being passed to a function since r279523

[yevh.kolesnikov at gmail dot com]

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

--- Comment #5 from Yevhenii Kolesnikov  ---
(In reply to Martin Liška from comment #3)
> Thank you for the report, I can take a look.
> Can you please provide steps how to build Mesa with -O3 and -flto?

mesa is configured with meson. LTO can be enabled with builtin option
-b_lto=true. Options can be supplied to the compiler with -Dc_args and
-Dcpp_args. So, to enable O3 it's -Dc_args="-O3" -Dcpp_args="-O3". You'll also
need to set -Dbuildtype=plain, or otherwise these options will be overwritten. 

So, the full build process will look like this:

meson \
-Dbuildtype=plain \
-Dvalgrind=false \
-Ddri-drivers=i965 \
-Dgallium-drivers=iris,swrast \
-Dvulkan-drivers= \
-Dgallium-omx="disabled" \
-Dplatforms=x11,drm,surfaceless \
-Dllvm=false \
-Db_lto=true \
-Dc_args="-g \
  -O3 \
  " \
-Dcpp_args="-g \
-O3 \
" \
--prefix=~/builds/mesa-bug \
./mesa-bug

ninja -C ./mesa-bug install

The aforementioned functions and assembly code then will be in
~/builds/mesa-bug/lib/dri/iris_dri.so

> About the addr_to_index function: am I right that unreachable is defined in
> your configuration as __builtin_unreachable?

To be precise, unreachable is defined like this:

#define unreachable(str)\
do {\
   assert(!str);\
   __builtin_unreachable(); \
} while (0)

I'm not sure why this one-time loop is necessary, to be honest.

> Can you please replace it with fprintf that prints the value?

The value of addr_format? It doesn't print anything, since this branch is never
hit. Moreover, it prevents addr_to_index from being inlined, so the crash goes
away. The value of addr_format in my case is 3, which corresponds to the
nir_address_format_32bit_index_offset enum. So, in my case, the first branch is
always hit.

[Bug tree-optimization/96542] Failure to optimize simple code to a constant when storing part of the operation in a variable

[amacleod at redhat dot com]

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

--- Comment #5 from Andrew Macleod  ---
I think this all goes away when multi-range is enabled.

The original testcase produces:
=== BB 2 
x_4(D)  unsigned int VARYING
 :
tmp_5 = x_4(D) != 0;
_1 = (int) tmp_5;
_2 = 255 >> _1;
_3 = (unsigned char) _2;
_6 = _3 * 2;
return _6;

_1 : int [0, 1]
_2 : int [127, 255]
_3 : unsigned char [127, +INF]


A number of the range-ops routines are simply inherited from the single range
codebase of value_range, and are not multi-range enabled yet.

In particular, rshift here.   with a tweak to operator_rshift, we can take

255 >> [0,1] and instead calculate 
_2 = [127,127][255,255]
which would make the results:

_1 : int [0, 1]
_2 : int [127, 127][255, 255]
_3 : unsigned char [127, 127] [255, 255]

Then when _6 is calculated as [127, 127][255, 255] * 2 , range-ops will
calculate the result to be [254, 254]


The whole thing will just fold away to return 254  (or -2 if you want to sign
it :-)

All we need to do is get the multi-range code enabled it's coming.

[Bug c++/96523] variable templates of constant types have incorrect linkage

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug target/83812] nvptx-run: error getting kernel result: operation not supported on global/shared address space

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
See PR 96494.

[Bug target/96494] [nvptx] Enable effective target sync_int_long

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
FTR, we could fix this by just mapping onto a nonatomic insn for .local (and
I'm not really sure why ptx doesn't).

But since we have generic pointers, we only known runtime whether something is
local (using isspacep), so that while that will help the standalone target be
more generic, it'll possibly make the offloading target slower and larger.

[Bug target/96494] [nvptx] Enable effective target sync_int_long

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
(In reply to Tom de Vries from comment #0)
> AFAICT, from the point of view of the PTX isa, there's no reason why we
> couldn't support this.
> 
> So, unless a testsuite run points to some problem, we should enable the
> sync_int_long for nvptx.

Well, I found a problem with test-case gcc/testsuite/gcc.dg/pr86314.c.

There we try to do an atomic insn on stack, and since stack is implemented as
.local, and the atom insn is not supported for .local, we run into:
...
 nvptx-run: error getting kernel result: operation not supported on
global/shared address space
...

Something like this would work:
...
$ git diff
diff --git a/gcc/testsuite/gcc.dg/pr86314.c b/gcc/testsuite/gcc.dg/pr86314.c
index 8962a3cf2ff..565fb02eee2 100644
--- a/gcc/testsuite/gcc.dg/pr86314.c
+++ b/gcc/testsuite/gcc.dg/pr86314.c
@@ -1,5 +1,5 @@
 // PR target/86314
-// { dg-do run { target sync_int_long } }
+// { dg-do run { target sync_int_long_stack } }
 // { dg-options "-O2" }

 __attribute__((noinline, noclone)) unsigned long
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index e79015b4d54..a870b1de275 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -7704,7 +7704,16 @@ proc check_effective_target_sync_int_long { } {
 || [istarget cris-*-*]
 || ([istarget sparc*-*-*] && [check_effective_target_sparc_v9])
 || ([istarget arc*-*-*] && [check_effective_target_arc_atomic])
-|| [check_effective_target_mips_llsc] }}]
+|| [check_effective_target_mips_llsc]
+|| [istarget nvptx*-*-*]
+}}]
+}
+
+proc check_effective_target_sync_int_long_stack { } {
+return [check_cached_effective_target sync_int_long_stack {
+  expr { ![istarget nvptx*-*-*]
+&& [check_effective_target_sync_int_long]   
+}}]
 }

 # Return 1 if the target supports atomic operations on "char" and "short".
...

[Bug tree-optimization/96548] [11 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:247 since r11-2574-g6aec53ee4f75a64c

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---
Here is another test case which demonstrates the fault:

int a, b, c, e;
int *d;
void f() {
  if (0) {
for (; b;) {
  c = f;
g:
  for (; e;)
;
}
c |= a ?: 1;
if (*d)
  d = e;
  }
  goto g;
}

Flag -O2 required.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

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

--- Comment #15 from Roger Wolff  ---
I marked it as "resolved', the system then told me to type a message and I did,
but then it had added the "FIXED" tag. Not my idea.

[Bug c/96554] -Wall does not include -Wnull-dereference

[R.E.Wolff at BitWizard dot nl]

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

--- Comment #4 from Roger Wolff  ---
Update: LTO messes with the warning. When LTO is enabled, the warning from
-Wnull-dreference is suppressed.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
(In reply to Roger Wolff from comment #11)
> Just FYI: I added  -Wnull-dereference to my makefile of my real project. It
> doesn't trigger a warning in my project when I revert to the buggy code. The
> compiler does detect and act upon the null dereference.

It will only warn when optimisations are performed, including the
-fdelete-null-pointer-checks optimisation. I would expect it to either not act
on the null dereference, or act and warn.

Please don't change status to FIXED when nothing was changed in GCC, let alone
fixed.

[Bug c/96554] -Wall does not include -Wnull-dereference

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

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

--- Comment #3 from Andreas Schwab  ---
*** Bug 96550 has been marked as a duplicate of this bug. ***

[Bug c/96550] gcc is smart in figuring out a non-returning function.

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #13 from Andreas Schwab  ---


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

[Bug c/96554] -Wall does not include -Wnull-dereference

[R.E.Wolff at BitWizard dot nl]

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

--- Comment #2 from Roger Wolff  ---
In my case it promotes a function I didn't declare as  into
one that  and thereby it caused 80% of my code to become
"dead". It'd be nice to differentiate between the case where a simple
optimization removes a few lines of code due to an extra null-check not being
reachable due to the trap  on the null dereference and the case where big
unexpected things start happening. 

Maybe the promotion of a function from "does return" to "does not return" is
something you might warn about. This satisfies the "you can easily modify the
code to silence the warning".

[Bug c/96540] gcc fails to build on Darwin 19.6.0

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #8 from Aldy Hernandez  ---
Fixed upstream.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

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

Roger Wolff  changed:

   What|Removed |Added

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

--- Comment #12 from Roger Wolff  ---
better description in: 96554

[Bug c++/96543] null check on template pointer parameter fails

[vlad at petric dot cc]

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

--- Comment #2 from Vlad Petric  ---
Got it, should I refile/change this bug?

[Bug c/96554] -Wall does not include -Wnull-dereference

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This warning is intentionally not enabled at -Wall, because it has too many
false positives (technically correct warnings, but about dead code).
See e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351#c35

[Bug testsuite/96519] [11 regression] new test case gcc.dg/ia64-sync-5.c fails

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu
   ||aarch64 arm
 CC||clyon at gcc dot gnu.org

--- Comment #1 from Christophe Lyon  ---
Seen also on aarch64 and arm

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

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

--- Comment #11 from Roger Wolff  ---
Just FYI: I added  -Wnull-dereference to my makefile of my real project. It
doesn't trigger a warning in my project when I revert to the buggy code. The
compiler does detect and act upon the null dereference.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

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

--- Comment #10 from Roger Wolff  ---
Technically correct.

[Bug c/96554] New: -Wall does not include -Wnull-dereference

[R.E.Wolff at BitWizard dot nl]

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

Bug ID: 96554
   Summary: -Wall does not include -Wnull-dereference
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: R.E.Wolff at BitWizard dot nl
  Target Milestone: ---

As reported in c/96550, the fact that -Wall didn't include -Wnull-dereference
cost me a lot of time in trying to figure out what the problem was with my
code. 

I add -Wall to get lots of warnings about potential bugs. if (a = 3) is an
example where a simple typo in the code leads to perfectly valid C, but such a
"high likelyhood of a bug" that a warning is warranted. 

Same here: I wrote a bug that caused the compiler to a) not warn me and b) do
unexpected things. I think the -Wnull-dreference is a valid warning to enable
with -Wall.

[Bug c/96540] gcc fails to build on Darwin 19.6.0

[juergen.reuter at desy dot de]

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

--- Comment #7 from Jürgen Reuter  ---
(In reply to Aldy Hernandez from comment #4)
> Does this patch fix the problem?
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551660.html

Yes, with that fix (as anticipated by you) build and bootstrap work.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Roger Wolff from comment #6)
> So, I've added "-Wall" to my Makefile to get ALL warnings,

It doesn't enable ALL warnings, as documented in the manual.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

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

--- Comment #8 from Roger Wolff  ---
Please, start to read what is written. Please.

[Bug libstdc++/94681] filesystem::sysmlink_status using stat instead of lstat when --disable-libstdcxx-filesystem-ts

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Only fixed on master so far.

[Bug libstdc++/94681] filesystem::sysmlink_status using stat instead of lstat when --disable-libstdcxx-filesystem-ts

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2633-g90f7636bf8df50940e0f749af60a6b374a8f09b4
Author: Jonathan Wakely 
Date:   Mon Aug 10 13:21:59 2020 +0100

libstdc++: Make C++17 ignore --disable-libstdcxx-filesystem-ts [PR 94681]

The configure switch should only affect the optional Filesystem TS, not
the std::filesystem features of C++17.

libstdc++-v3/ChangeLog:

PR libstdc++/94681
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Do not depend on
$enable_libstdcxx_filesystem_ts.
* configure: Regenerate.

[Bug c++/96553] New: ICE in unexpected expression ‘__alignof__ (auto:1)’ of kind alignof_expr

[haoxintu at gmail dot com]

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

Bug ID: 96553
   Summary: ICE in unexpected expression ‘__alignof__ (auto:1)’ of
kind alignof_expr
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

This code, reduced by C-Vise, makes GCC-trunk ICE and released versions
"confused by earlier errors, bailing out".

Input:
//small.cc
class Test{
Test  || ( alignas (auto) enum{});
};

Command:
g++ small.cc

Output:
small.cc:2:34: warning: use of ‘auto’ in parameter declaration only available
with ‘-fconcepts-ts’
2 | Test  || ( alignas (auto) enum{});
  |  ^~~~
small.cc:2:40: error: types may not be defined in parameter types
2 | Test  || ( alignas (auto) enum{});
  |^~~~
small.cc:2:45: internal compiler error: unexpected expression ‘__alignof__
(auto:1)’ of kind alignof_expr
2 | Test  || ( alignas (auto) enum{});
  | ^
0x8e014c cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6567
0x8e068f cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:6772
0x8e4aab maybe_constant_value(tree_node*, tree_node*, bool)
../../gcc/cp/constexpr.c:7045
0x95075b cp_check_const_attributes(tree_node*)
../../gcc/cp/decl2.c:1428
0x955b72 cp_check_const_attributes(tree_node*)
../../gcc/cp/decl2.c:1416
0x955b72 cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc/cp/decl2.c:1584
0x9f27a4 cp_parser_parameter_declaration_list
../../gcc/cp/parser.c:22725
0x9f2b21 cp_parser_parameter_declaration_clause
../../gcc/cp/parser.c:22622
0x9df4f1 cp_parser_direct_declarator
../../gcc/cp/parser.c:21299
0x9df4f1 cp_parser_declarator
../../gcc/cp/parser.c:21163
0x9df045 cp_parser_declarator
../../gcc/cp/parser.c:21141
0x9fe4ce cp_parser_member_declaration
../../gcc/cp/parser.c:25291
0x9d0ea8 cp_parser_member_specification_opt
../../gcc/cp/parser.c:24904
0x9d0ea8 cp_parser_class_specifier_1
../../gcc/cp/parser.c:24001
0x9d3143 cp_parser_class_specifier
../../gcc/cp/parser.c:24308
0x9d3143 cp_parser_type_specifier
../../gcc/cp/parser.c:17811
0x9d40be cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14436
0x9d4e71 cp_parser_simple_declaration
../../gcc/cp/parser.c:13690
0xa002fe cp_parser_declaration
../../gcc/cp/parser.c:13510
0xa009db cp_parser_translation_unit
../../gcc/cp/parser.c:4793
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

My GCC version is updated on 2020-08-08.

Thanks,
Haoxin

[Bug c++/96552] New: GCC accepts "alignas(auto)" in function parameter list

[haoxintu at gmail dot com]

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

Bug ID: 96552
   Summary: GCC accepts "alignas(auto)" in function parameter list
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

Following code is invalid I think, the "alignas" shouldn't be in function
parameter. I guess GCC only finds a "auto" in function parameter list rather
than "alignas(auto)", also "alignas(auto)" itself is invalid.

Code:
class Test{
Test  || (alignas(auto) int);
};

While Clang says "error: 'auto' not allowed here".

Every version from GCC-6.1 upwards behaves the same.

Thanks,
Haoxin

[Bug target/96551] New: [10 Regression] FAIL: gcc.target/i386/vectorize8.c (internal compiler error)

[hjl.tools at gmail dot com]

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

Bug ID: 96551
   Summary: [10 Regression] FAIL: gcc.target/i386/vectorize8.c
(internal compiler error)
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: crazylht at gmail dot com
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x86_64

ommit f098bc87dcae5646d11a351cfb55d0e1124c7f60
Author: liuhongt 
Date:   Mon Jul 20 10:13:58 2020 +0800

Using UNSPEC for vector compare to mask register.

For rtx like (eq:HI (V8SI 90) (V8SI 91)), cse will take it as a
boolean value and try to do some optimization. But it is not true for
vector compare, also other places in rtl passes hold the same
assumption.

caused:

FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]16[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]16[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]16[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]32[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]32[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]32[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]64[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]64[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]64[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]8[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]8[\t ] 6
FAIL: gcc.target/i386/pr92865-1.c scan-assembler-times vmovdq[au]8[\t ] 6
FAIL: gcc.target/i386/vectorize8.c (internal compiler error)
FAIL: gcc.target/i386/vectorize8.c (internal compiler error)
FAIL: gcc.target/i386/vectorize8.c (internal compiler error)
FAIL: gcc.target/i386/vectorize8.c (test for excess errors)
FAIL: gcc.target/i386/vectorize8.c (test for excess errors)
FAIL: gcc.target/i386/vectorize8.c (test for excess errors)

with

$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/vectorize8.c --target_board='unix{-m64\
-march=cascadelake,-m32\ -march=cascadelake}'"

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
The compiler can't diagnose this as an error (unless -Werror* is used), because
it is only an error if such code is ever called at runtime, which the compiler
can't determine at compile time.
That is why it is just a warning.
And, as an optimizing compiler, the compiler can and does optimize anything
that would be only reachable through that statement with UB.
This isn't an attempt to punish those who write broken code, but it actually
helps a lot in real-world code, something like that can happen frequently, but
usually in code that will not be actually encountered at runtime, just the
compiler can't prove that.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

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

--- Comment #6 from Roger Wolff  ---
So, I've added "-Wall" to my Makefile to get ALL warnings, giving me the
biggest chance of finding bugs through the compiler telling me you have a bug
on line X of file Y. 

So IMHO -Wnull-dereference should be part of -Wall. I'm not a compiler guy. I
just use the stuff. So now the question becomes: Why is that warning not part
of -Wall ?

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

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

--- Comment #5 from Roger Wolff  ---
Guys, The compiler found a bug in my code, but it didn't tell me. Like the if
(a = 3) situation, the compiler is correct when it compiles the code according
to the C rules. 

I like to compile my code with -Wall for this reason: 99% of the cases, the
compiler will find and warn about stupid stuff that's not a problem. But in
that 1% of the cases, the compiler will warn about something that's a bug that
would've taken lots of time to find.  SO when you get that one warning, you
have the compiler telling you: You have a bug on line X of your program. 

That's what could've happened here: I had a bug in my code, but didn't expect
the binary to suddenly go from 75k to 14k because of a bug.

Something like: 
Line 18: dereferencing NULL pointer is undefined behaviour. Assuming execution
stops here. 

would be a usable error message. 

This is actually one of those 1% of the cases where the warning COULD have been
given and finding the bug would've been seconds whereas without the warning
lots of time was wasted looking for the bug in the wrong places. 

This is not a bug per se, you can suggest workarounds for: "What if you want to
store stuff at address zero" all you want, but I had a bug and I've asked gcc
to issue warnings where I'm doing fishy stuff that might be a bug. And I didn't
get that warning. 

So this issue is not a bug in that the wrong code is generated, but an
enhancement request: Please issue that warning. 

All this is "not for me": I've now run into this issue, the bug in my project
has been fixed and for me it's on to the rest of the code. And I've been
subjected to this "way of gcc telling me there is a bug", so in the future, if
I make this mistake again, I'll not spend as much time on it as I did this
weekend. 

So I'm trying to make things easier for those others that might run into this
in the future.

[Bug rtl-optimization/96539] Unnecessary no-op copy with Os and tail call with struct argument

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2020-08-10
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Jakub Jelinek  ---
Created attachment 49035
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49035=edit
gcc11-pr96539.patch

Untested fix.  At GIMPLE we already optimize away memmove etc. calls with the
same destination as source, but for the arguments copying this didn't get
through GIMPLE memmove call, so the patch just does nothing at the RTL level
too.  For -O2 the copying was expanded piecewise and as such was later
optimized away when the generic code seed noop copying.

[Bug tree-optimization/96466] [11 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:122 with -Og -finline-functions-called-once -fno-tree-ccp

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
It's the same store as PR96453: copyprop can eliminate that to:

Folding statement: _3 = { 5 };
Queued stmt for removal.  Folds to: { 5 }
Folding statement: _4 = VEC_COND_EXPR <_3 > { 4441221374 }, { -1 }, { 0 }>;
gimple_simplified to _4 = { 0 };
Folded into: _4 = { 0 };

@Richi: Can we teach copyprop to fold constant expressions for VEC_COND_EXPRs
that have first argument equal to a constant?

[Bug target/96453] [11 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:167 with -Og -fno-early-inlining -fno-tree-ccp -mavx -mno-sse4.2

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
So the problem here is that we newly meet:

  _5 = { -1, -1 };
  _6 = VEC_COND_EXPR <_5, { -1, -1 }, { 0, 0 }>;

which we before the revision removed in copyprop6.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Version|unknown |9.3.1

--- Comment #4 from Jonathan Wakely  ---
And if you read the manual for the -Wnull-dereference warning you'll see it
also mentions -fdelete-null-pointer-checks, and if you read about that you
should find the solution you need.

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Roger Wolff from comment #0)
> So... without saying anything the compiler decided that my function will
> never return. It might be right about that (That's not true: This is on an
> embedded system and I can map RAM to address zero!) but then IMHO, a warning
> would be warranted. A function goes from not being declared volatile by me
> to being volatile (not returning). 
> 
> It's perfectly legal C code in there, but might not be what the user
> wanted Just like if (a = 3) ... I think a warning might be issued. 

GCC *does* warn:

null.c: In function ‘myfunc’:
null.c:19:11: warning: null pointer dereference [-Wnull-dereference]
   19 |   mt.t[0] = 1;
  |   ^~~

[Bug libstdc++/93904] LWG 561 not implemented: std::inserter overly generic

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Fixed in r11-2632

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
If FAIL is defined, your myfunc will always trigger undefined behavior if
called, and as such anything can happen.
Derefencing NULL is UB.
If you are on an embedded system where there is memory mapped, you can use
-fno-delete-null-pointer-checks (for some embedded targets it is even the
default).

[Bug c/96550] gcc is smart in figuring out a non-returning function.

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Does -fno-delete-null-pointer-checks help?

[Bug c/96550] New: gcc is smart in figuring out a non-returning function.

[R.E.Wolff at BitWizard dot nl]

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

Bug ID: 96550
   Summary: gcc is smart in figuring out a non-returning function.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: R.E.Wolff at BitWizard dot nl
  Target Milestone: ---

This is the small probgram that reproduces this: 
---
#include 

#define FAIL

struct test {
#ifdef FAIL
  char *t;
#else
  char t[8];
#endif
} ; 

extern void somefunc (struct test *t);

void myfunc (void) 
{
  struct test mt;
  memset (, 0, sizeof (mt));
  mt.t[0] = 1;
  somefunc ();
}
---
Here the struct was defined in another part of the code, and I'd guessed
(wrong) that the declaration was like in the FALSE branch of the IFDEF. As it
turns out the declaration was different. 

So what happens is that the compiler decides that I set the pointer to zero,
and that the assignment through that pointer WILL fail. 

So the generated assembly starts with: 
---
myfunc:
@ Function supports interworking.
@ Volatile: function does not return.
---

So... without saying anything the compiler decided that my function will never
return. It might be right about that (That's not true: This is on an embedded
system and I can map RAM to address zero!) but then IMHO, a warning would be
warranted. A function goes from not being declared volatile by me to being
volatile (not returning). 

It's perfectly legal C code in there, but might not be what the user wanted
Just like if (a = 3) ... I think a warning might be issued. 

Reproduced on: gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516
not reproduced on: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609
reproduced on (originally ran into): arm-none-eabi-gcc (GNU Arm Embedded
Toolchain 9-2020-q2-update) 9.3.1 20200408 (release)

[Bug libstdc++/95749] std::filesystem::file_size returns wrong size for large files on Windows

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed for 9.4 and 10.3, thanks for the report.

[Bug libstdc++/95749] std::filesystem::file_size returns wrong size for large files on Windows

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Also fixed on master by g:9939be5758b52ed2fe1a7e56b94ce6d0f4d81580 but I'm not
sure why that didn't get added here.

[Bug libstdc++/95749] std::filesystem::file_size returns wrong size for large files on Windows

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r9-8800-gcaac3ee7008286404323c4aa93ee0e1c4753c4c2
Author: Jonathan Wakely 
Date:   Mon Aug 10 11:10:26 2020 +0100

libstdc++: Use _wstat64 for Windows [PR 95749]

In order to handle large files on Windows we need to use stat API with
64-bit st_size member.

libstdc++-v3/ChangeLog:

PR libstdc++/95749
* src/filesystem/ops-common.h [_GLIBCXX_FILESYSTEM_IS_WINDOWS]
(stat_type): Change to __stat64.
(stat): Use _wstat64.

(cherry picked from commit 9939be5758b52ed2fe1a7e56b94ce6d0f4d81580)

[Bug libstdc++/95749] std::filesystem::file_size returns wrong size for large files on Windows

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8600-gb5cc5c95664347082100a504710f5ca0467306a5
Author: Jonathan Wakely 
Date:   Mon Aug 10 12:04:27 2020 +0100

libstdc++: Use _wstat64 for Windows [PR 95749]

In order to handle large files on Windows we need to use stat API with
64-bit st_size member.

libstdc++-v3/ChangeLog:

PR libstdc++/95749
* src/filesystem/ops-common.h [_GLIBCXX_FILESYSTEM_IS_WINDOWS]
(stat_type): Change to __stat64.
(stat): Use _wstat64.

(cherry picked from commit 9939be5758b52ed2fe1a7e56b94ce6d0f4d81580)

[Bug target/95235] Failure to properly optimize out register use in bit-twiddling code

[gabravier at gmail dot com]

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

Gabriel Ravier  changed:

   What|Removed |Added

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

--- Comment #2 from Gabriel Ravier  ---
Just rechecked and it looks like it was fixed at some point since I filed this
bug report.

[Bug tree-optimization/95433] Failure to completely optimize simple compare after operations

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Marc Glisse :

https://gcc.gnu.org/g:287522613d661b4c5ba8403b051eb470c1674cba

commit r11-2629-g287522613d661b4c5ba8403b051eb470c1674cba
Author: Marc Glisse 
Date:   Mon Aug 10 12:50:42 2020 +0200

Simplify X * C1 == C2 with wrapping overflow

Odd numbers are invertible in Z / 2^n Z, so X * C1 == C2 can be rewritten
as X == C2 * inv(C1) when overflow wraps.

mod_inv should probably be updated to better match the other wide_int
functions, but that's a separate issue.

2020-08-10  Marc Glisse  

PR tree-optimization/95433
* match.pd (X * C1 == C2): Handle wrapping overflow.
* expr.c (maybe_optimize_mod_cmp): Qualify call to mod_inv.
(mod_inv): Move...
* wide-int.cc (mod_inv): ... here.
* wide-int.h (mod_inv): Declare it.

* gcc.dg/tree-ssa/pr95433-2.c: New file.

[Bug tree-optimization/96542] Failure to optimize simple code to a constant when storing part of the operation in a variable

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
As for COND_EXPR, if we do it that way, it should be rather keyed on a range
with only two possible values in the range.

[Bug tree-optimization/96542] Failure to optimize simple code to a constant when storing part of the operation in a variable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com

--- Comment #3 from Jakub Jelinek  ---
(In reply to Marc Glisse from comment #2)
> > Or shall say VRP try harder if it sees [0, 1] ranges?
> 
> If a range has only 2 (or some other small number) values, try propagating
> each and see if some variables end up with the same value in both cases?

Maybe.  The question is if it should be done in forwprop, or say vrp or in the
ranger code (does that one do forward propagation)?
In any case, it should be limited to ranges with small number of values
(perhaps decided with a param) and also bound on how many immediate use stmts
it attempts to propagate it through.

[Bug c/96545] ICE in get_atomic_generic_size

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 49034
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49034=edit
gcc11-pr96545.patch

Untested fix.