[Bug tree-optimization/92712] [8/9 Regression] Performance regression with assumed values

[fxue at os dot amperecomputing.com]

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

Feng Xue  changed:

   What|Removed |Added

 CC||fxue at os dot 
amperecomputing.com

--- Comment #24 from Feng Xue  ---
If(In reply to Jakub Jelinek from comment #15)
> For
> A*B+A*C -> (B+C)*A
> the problematic cases are
> A==-1 and B > 0 and C==(max-B)+1 (i.e. when B+C overflows to min)
> or A==0 and B < 0 and C or A==0 and B > 0 and C>max-B
> (last two cases cover when B+C overflows)
> For
> A*B-A*C -> (B-C)*A
> the problematic cases are
> A==-1 and B > 0 and C==min+B (i.e. when B-C is min)
> or A==0 and B < -1 and C>B-min
> or A==0 and B >= 0 and C (last two cases cover when B-C overflows)
> Again, we perform the operation right now if A is not 0 and not -1 for
> certain.
> I guess we could handle those cases by using something like
> check_for_binary_op_overflow, except that for the case where A might be -1
> and plusminus equal to MINUS_EXPR we also need to make sure the result of
> B-C is known not to be min.

Another point: if B+-C can be folded to an existing gimple value, we might
deduce B+-C does not overflow?

[Bug target/96891] New: [AVX512] For vector compare to dest vector, avx512 vector compare could be lowered to avx version

[crazylht at gmail dot com]

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

Bug ID: 96891
   Summary: [AVX512] For vector compare to dest vector, avx512
vector compare could be lowered to avx version
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---
Target: x86_64-*-* i?86-*-*

cat test.cpp

---
typedef float v8sf __attribute__ ((vector_size (32)));
v8sf test4(v8sf a, v8sf b)
{
return a >= b;
}
---

gcc -O2 -mavx512f -mavx512vl -S 

---
test4:
vcmpps  k1, ymm1, ymm0, 2
vpternlogd  ymm0{k1}{z}, ymm0, ymm0, 0x81
ret
---

gcc -O2 -mavx

---
test4:
vcmplepsymm0, ymm1, ymm0
ret
---

Add peephole 2 handle this?

[Bug target/92923] __builtin_vec_xor() causes subregs to be used when not using V4SImode vectors

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Kewen Lin :

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

commit r9-8843-g8c18220564f8372f4d45ed1a4df3fc7f71928654
Author: Kewen Lin 
Date:   Tue Sep 1 21:12:32 2020 -0500

rs6000: Backport fixes for PR92923 and PR93136

This patch is to backport the fix for PR92923 and its sequent fix
for PR93136.  We found the builtin functions needlessly using
VIEW_CONVERT_EXPRs on their operands can probably cause remarkable
performance degradation especailly when they are used in the hotspot.
One typical case is
  ...github.com/antonblanchard/crc32-vpmsum/blob/master/vec_crc32.c
With this patch, the execution time can improve 47.81%.

Apart from the original fixes, this patch also gets two cases below
updated.  During the regression testing I found two cases failed due
to icf optimization able to be adopted with this patch, the function
bodies use tail calls, the expected assembly instructions are gone.

  gcc.target/powerpc/fold-vec-logical-ands-longlong.c
  gcc.target/powerpc/fold-vec-logical-ors-longlong.c

Bootstrapped/regtested on powerpc64{,le}-linux-gnu P8.

2019-12-30  Peter Bergner 

gcc/ChangeLog

PR target/92923
* config/rs6000/rs6000-builtin.def (VAND, VANDC, VNOR, VOR, VXOR):
Delete.
(EQV_V16QI_UNS, EQV_V8HI_UNS, EQV_V4SI_UNS, EQV_V2DI_UNS,
EQV_V1TI_UNS,
NAND_V16QI_UNS, NAND_V8HI_UNS, NAND_V4SI_UNS, NAND_V2DI_UNS,
NAND_V1TI_UNS, ORC_V16QI_UNS, ORC_V8HI_UNS, ORC_V4SI_UNS,
ORC_V2DI_UNS,
ORC_V1TI_UNS, VAND_V16QI_UNS, VAND_V16QI, VAND_V8HI_UNS, VAND_V8HI,
VAND_V4SI_UNS, VAND_V4SI, VAND_V2DI_UNS, VAND_V2DI, VAND_V4SF,
VAND_V2DF, VANDC_V16QI_UNS, VANDC_V16QI, VANDC_V8HI_UNS,
VANDC_V8HI,
VANDC_V4SI_UNS, VANDC_V4SI, VANDC_V2DI_UNS, VANDC_V2DI, VANDC_V4SF,
VANDC_V2DF, VNOR_V16QI_UNS, VNOR_V16QI, VNOR_V8HI_UNS, VNOR_V8HI,
VNOR_V4SI_UNS, VNOR_V4SI, VNOR_V2DI_UNS, VNOR_V2DI, VNOR_V4SF,
VNOR_V2DF, VOR_V16QI_UNS, VOR_V16QI, VOR_V8HI_UNS, VOR_V8HI,
VOR_V4SI_UNS, VOR_V4SI, VOR_V2DI_UNS, VOR_V2DI, VOR_V4SF, VOR_V2DF,
VXOR_V16QI_UNS, VXOR_V16QI, VXOR_V8HI_UNS, VXOR_V8HI,
VXOR_V4SI_UNS, VXOR_V4SI, VXOR_V2DI_UNS, VXOR_V2DI, VXOR_V4SF,
VXOR_V2DF): Add definitions.
* config/rs6000/rs6000-c.c (altivec_overloaded_builtins)
: Remove.
: Add
definitions.
: Change unsigned usages to use the new *_UNS
definition names.
* config/rs6000/rs6000.c
(rs6000_gimple_fold_builtin) : Use new definition names.
(builtin_function_type) : Handle
unsigned
builtins.

2019-12-30  Peter Bergner  
2020-02-08  Peter Bergner  

gcc/testsuite/ChangeLog

* gcc.target/powerpc/fold-vec-logical-ands-longlong.c: Adjust.
* gcc.target/powerpc/fold-vec-logical-ors-longlong.c: Likewise.

PR target/92923
* gcc.target/powerpc/pr92923-1.c: New test.
* gcc.target/powerpc/pr92923-2.c: Likewise.

PR target/93136
* gcc.dg/vmx/ops.c: Add -flax-vector-conversions to dg-options.
* gcc.target/powerpc/vsx-vector-6.h: Split tests into smaller
functions.
* gcc.target/powerpc/vsx-vector-6.p7.c: Adjust scan-assembler-times
regex directives.  Adjust expected instruction counts.
* gcc.target/powerpc/vsx-vector-6.p8.c: Likewise.
* gcc.target/powerpc/vsx-vector-6.p9.c: Likewise.

(cherry picked from commit 4559be2358020714ec7521c80589992716d23035)
(cherry picked from commit 4b39d801b2698d0f756231f6f8fa0be5a36f0c05)

[Bug target/93136] [10 regression] gcc.dg/vmx/ops.c and several other test break after r279772

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Kewen Lin :

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

commit r9-8843-g8c18220564f8372f4d45ed1a4df3fc7f71928654
Author: Kewen Lin 
Date:   Tue Sep 1 21:12:32 2020 -0500

rs6000: Backport fixes for PR92923 and PR93136

This patch is to backport the fix for PR92923 and its sequent fix
for PR93136.  We found the builtin functions needlessly using
VIEW_CONVERT_EXPRs on their operands can probably cause remarkable
performance degradation especailly when they are used in the hotspot.
One typical case is
  ...github.com/antonblanchard/crc32-vpmsum/blob/master/vec_crc32.c
With this patch, the execution time can improve 47.81%.

Apart from the original fixes, this patch also gets two cases below
updated.  During the regression testing I found two cases failed due
to icf optimization able to be adopted with this patch, the function
bodies use tail calls, the expected assembly instructions are gone.

  gcc.target/powerpc/fold-vec-logical-ands-longlong.c
  gcc.target/powerpc/fold-vec-logical-ors-longlong.c

Bootstrapped/regtested on powerpc64{,le}-linux-gnu P8.

2019-12-30  Peter Bergner 

gcc/ChangeLog

PR target/92923
* config/rs6000/rs6000-builtin.def (VAND, VANDC, VNOR, VOR, VXOR):
Delete.
(EQV_V16QI_UNS, EQV_V8HI_UNS, EQV_V4SI_UNS, EQV_V2DI_UNS,
EQV_V1TI_UNS,
NAND_V16QI_UNS, NAND_V8HI_UNS, NAND_V4SI_UNS, NAND_V2DI_UNS,
NAND_V1TI_UNS, ORC_V16QI_UNS, ORC_V8HI_UNS, ORC_V4SI_UNS,
ORC_V2DI_UNS,
ORC_V1TI_UNS, VAND_V16QI_UNS, VAND_V16QI, VAND_V8HI_UNS, VAND_V8HI,
VAND_V4SI_UNS, VAND_V4SI, VAND_V2DI_UNS, VAND_V2DI, VAND_V4SF,
VAND_V2DF, VANDC_V16QI_UNS, VANDC_V16QI, VANDC_V8HI_UNS,
VANDC_V8HI,
VANDC_V4SI_UNS, VANDC_V4SI, VANDC_V2DI_UNS, VANDC_V2DI, VANDC_V4SF,
VANDC_V2DF, VNOR_V16QI_UNS, VNOR_V16QI, VNOR_V8HI_UNS, VNOR_V8HI,
VNOR_V4SI_UNS, VNOR_V4SI, VNOR_V2DI_UNS, VNOR_V2DI, VNOR_V4SF,
VNOR_V2DF, VOR_V16QI_UNS, VOR_V16QI, VOR_V8HI_UNS, VOR_V8HI,
VOR_V4SI_UNS, VOR_V4SI, VOR_V2DI_UNS, VOR_V2DI, VOR_V4SF, VOR_V2DF,
VXOR_V16QI_UNS, VXOR_V16QI, VXOR_V8HI_UNS, VXOR_V8HI,
VXOR_V4SI_UNS, VXOR_V4SI, VXOR_V2DI_UNS, VXOR_V2DI, VXOR_V4SF,
VXOR_V2DF): Add definitions.
* config/rs6000/rs6000-c.c (altivec_overloaded_builtins)
: Remove.
: Add
definitions.
: Change unsigned usages to use the new *_UNS
definition names.
* config/rs6000/rs6000.c
(rs6000_gimple_fold_builtin) : Use new definition names.
(builtin_function_type) : Handle
unsigned
builtins.

2019-12-30  Peter Bergner  
2020-02-08  Peter Bergner  

gcc/testsuite/ChangeLog

* gcc.target/powerpc/fold-vec-logical-ands-longlong.c: Adjust.
* gcc.target/powerpc/fold-vec-logical-ors-longlong.c: Likewise.

PR target/92923
* gcc.target/powerpc/pr92923-1.c: New test.
* gcc.target/powerpc/pr92923-2.c: Likewise.

PR target/93136
* gcc.dg/vmx/ops.c: Add -flax-vector-conversions to dg-options.
* gcc.target/powerpc/vsx-vector-6.h: Split tests into smaller
functions.
* gcc.target/powerpc/vsx-vector-6.p7.c: Adjust scan-assembler-times
regex directives.  Adjust expected instruction counts.
* gcc.target/powerpc/vsx-vector-6.p8.c: Likewise.
* gcc.target/powerpc/vsx-vector-6.p9.c: Likewise.

(cherry picked from commit 4559be2358020714ec7521c80589992716d23035)
(cherry picked from commit 4b39d801b2698d0f756231f6f8fa0be5a36f0c05)

[Bug fortran/96890] New: Wrong answer with intrinsic IALL

[zhen...@compiler-dev.com]

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

Bug ID: 96890
   Summary: Wrong answer with intrinsic IALL
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhen...@compiler-dev.com
  Target Milestone: ---

I got wrong answer with iall, only when all 3 parameters ARRAY/DIM/MASK are all
present and the rank of array >1.

---test code---
program test_f90_intrinsics
  integer :: i, j, k
  integer, dimension(2) :: ia1
  integer, dimension(2,2) :: ia2
  integer, dimension(2,2,2) :: ia3
  integer, dimension(2,2,2,2) :: ia4
  logical, dimension(2) :: mask1
  logical, dimension(2, 2) :: mask2
  logical, dimension(2, 2, 2) :: mask3
  logical, dimension(2, 2, 2, 2) :: mask4

  data ia1 /  1,  2 /
  data ia2 /  1,  2,  3, 4 /
  data ia3 /  1,  2,  3, 4,  5,  6,  7, 8 /
  data ia4 /  1,  2,  3, 4,  5,  6,  7, 8, &
9, 10, 11, 12, 13, 14, 15, 16 /

  data mask1 / .true., .false. /
  data mask2 / .true., .false., .true., .false. /
  data mask3 / .true., .false., .true., .false., &
.true., .false., .true., .false. /
  data mask4 / .true., .false., .true., .false., &
.true., .false., .true., .false., .true., &
.false., .true., .false., .true., .false., &
.true., .false. /


  print *, '-test 1---'
  print *, iall(ia2, 2, mask2)

  print *, '-test 2---'
  print *, iall(ia3, 2, mask3)

  print *, '-test 3---'
  print *, iall(ia4, 2, mask4)

end
---

With gfortran I got wrong result:
-test 1---
  0   0
-test 2---
  0   0   0   0
-test 3---
  0   0   0   0   0   0
  0   0


The expected result(checked with ifort) should be:
-test 1---
   1   -1
-test 2---
   1   -15   -1
-test 3---
   1   -15   -19   -1
  13   -1

[Bug jit/96889] Reflection API accessible from the jit C API

[bouanto at zoho dot com]

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

--- Comment #1 from Antoni  ---
Created attachment 49173
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49173=edit
Patch with new functions

[Bug jit/96889] New: Reflection API accessible from the jit C API

[bouanto at zoho dot com]

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

Bug ID: 96889
   Summary: Reflection API accessible from the jit C API
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

Hi.
There are some functions that would be useful to have in the C API of libgccjit
like a function to get the number of parameters of a function or its return
type.
I'll send the patch very soon.

There are probably other reflection functions that would be useful as well:
I'll add them to the patch later.

[Bug tree-optimization/96888] Missing vectorization opportunity depending on integer type

[pmenon at cs dot cmu.edu]

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

--- Comment #1 from pmenon at cs dot cmu.edu ---
Correction: outer loop condition should read 'i < n'.

[Bug libstdc++/86419] codecvt::in() and out() incorrectly return ok in some cases.

[dmjpp at hotmail dot com]

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

--- Comment #5 from Dimitrij Mijoski  ---
I think I found where the bug lies. It lies in 

1. line 557 of the file c++11/codecvt.cc
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/c%2B%2B11/codecvt.cc;h=0311b15177d0439757e0347f7934b5a09b78f8e3;hb=HEAD#l557
.

  The return of the function utf16_in() should be:

  return from.size() ? codecvt_base::partial : codecvt_base::ok;

  The bug is triggered because the loop exists because t.size() is zero.
from.size() should be checked.

2. line 579 of the same file
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/c%2B%2B11/codecvt.cc;h=0311b15177d0439757e0347f7934b5a09b78f8e3;hb=HEAD#l579

 578 if (from.size() < 2)
 579   return codecvt_base::ok; // stop converting at this point

Should be

 578 if (from.size() < 2)
 579   return codecvt_base::partial; // stop converting at this
point

[Bug libstdc++/86419] codecvt::in() and out() incorrectly return ok in some cases.

[dmjpp at hotmail dot com]

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

Dimitrij Mijoski  changed:

   What|Removed |Added

Summary|codecvt::in() and out()|...>::in() and out()
   |incorrectly return partial  |incorrectly return ok in
   |in some cases.  |some cases.

--- Comment #4 from Dimitrij Mijoski  ---
I think i found where the bug lies. It lies in 

1. line 557 of the file c++11/codecvt.cc
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/c%2B%2B11/codecvt.cc;h=0311b15177d0439757e0347f7934b5a09b78f8e3;hb=HEAD#l557
.

  The return of the function utf16_in() should be:

  return from.size() ? codecvt_base::partial : codecvt_base::ok;

  The bug is triggered because the loop exists because t.size() is zero.
from.size() should be checked.

2.

[Bug tree-optimization/96888] New: Missing vectorization opportunity depending on integer type

[pmenon at cs dot cmu.edu]

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

Bug ID: 96888
   Summary: Missing vectorization opportunity depending on integer
type
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pmenon at cs dot cmu.edu
  Target Milestone: ---

The loop in the following test case isn't vectorized:

#include 
#include 

// Add x to each v[i] if bit 'i' is set in LSB-encoded bits.
void Test(int8_t *__restrict v, int8_t x, const uint64_t *bits, unsigned n) {
for (int i = 0, num_words=(n+64-1)/64; i , n; i++) {
const uint64_t word = bits[i];
for (int j = 0; j < 64; j++) {
v[i*64+j] += x * (bool)(word & (uint64_t(1)<:7:9: missed: couldn't vectorize loop
:7:9: missed: not vectorized: control flow in loop.
:8:27: missed: couldn't vectorize loop
:9:30: missed: not vectorized: relevant stmt not supported: _10 =
word_24 >> j_34;

However, changing one line (the one constructing the mask) from an explicit
uint64_t(1) to a plan 1U (which is not correct), we get auto-vectorization:

#include 
#include 

// Add x to each v[i] if bit 'i' is set in LSB-encoded bits.
void Test(int8_t *__restrict v, int8_t x, const uint64_t *bits, unsigned n) {
for (int i = 0, num_words=(n+64-1)/64; i , n; i++) {
const uint64_t word = bits[i];
for (int j = 0; j < 64; j++) {
v[i*64+j] += x * (bool)(word & (1<

[Bug c++/77841] a new expression of a char array cannot be initialized by a string literal

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2972-gb1c59b31ef7adc832405209e9e2a77212284abd7
Author: Marek Polacek 
Date:   Tue Sep 1 11:44:16 2020 -0400

c++: Allow new char[4]{"foo"} [PR77841]

Currently, we allow new char[]{"foo"}, but not new char[4]{"foo"}.
We should accept the latter too: [dcl.init.list]p3.3 says to treat
this as [dcl.init.string].

We were rejecting this code because we never called reshape_init before
the digest_init in build_new_1.  reshape_init handles [dcl.init.string]
by unwrapping the STRING_CST from its enclosing { }, and digest_init
assumes that reshape_init has been called for aggregates anyway, and an
array is an aggregate.

gcc/cp/ChangeLog:

PR c++/77841
* init.c (build_new_1): Call reshape_init.

gcc/testsuite/ChangeLog:

PR c++/77841
* g++.dg/cpp0x/initlist-new4.C: New test.

[Bug c++/96887] New: Excessive error output with member initializer list and array

[mpolacek at gcc dot gnu.org]

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

Bug ID: 96887
   Summary: Excessive error output with member initializer list
and array
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

struct A {
  A(char);
};

class B {
  const A ary[64];
  B (const A a[]) : ary{a} { }
};

generates 1 + 64 error messages:

array3.C:7:21: error: could not convert ‘()’
from ‘’ to ‘const A’
[...]

each for every element of ary.  We should only say that there's no viable
conversion from 'const A *' to 'const A'

[Bug c++/77841] a new expression of a char array cannot be initialized by a string literal

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
In C++20, this should also work:

new char[4](1,2,3,4);

[Bug libstdc++/71960] __glibcxx_assert and Debug Mode checks can't be used in constexpr functions

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2971-g10f51543bb81cc953792270b40a9c812049e8b4c
Author: Jonathan Wakely 
Date:   Tue Sep 1 20:52:26 2020 +0100

libstdc++: Add compile-time checks to__glibcxx_assert [PR 71960]

This change evaluates __glibcxx_assert checks unconditionally when a
function is being constant evaluated (when std::is_constant_evaluated()
is true). If the check fails, compilation will fail with an error.

If the function isn't being constant evaluated, the normal runtime check
will be done if enabled by _GLIBCXX_ASSERTIONS or _GLIBCXX_DEBUG, the
same as before.

Tangentially, the __glibcxx_assert and _GLIBCXX_PARALLEL_ASSERT macros
are changed to expand to 'do { } while (false)' when assertions are
disabled, instead of expanding to nothing. This avoids -Wempty-body
warnings when a disabled assertion is used in an 'if' or 'else'
statement e.g.

  if constexpr (/* precondition is testable */)
__glibcxx_assert(precondition);

a.C:9:27: warning: suggest braces around empty body in an âifâ
statement [-Wempty-body]
9 | __glibcxx_assert(precondition);
  |  ^

libstdc++-v3/ChangeLog:

PR libstdc++/71960
* include/bits/c++config (__glibcxx_assert_impl): Remove
do-while so that uses of the macro need to add it.
(__glibcxx_assert): Rename macro for runtime assertions
to __glibcxx_assert_2.
(__glibcxx_assert_1): Define macro for constexpr assertions.
(__glibcxx_assert): Define macro for constexpr and runtime
assertions.
* include/bits/range_access.h (ranges::advance): Remove
redundant precondition checks during constant evaluation.
* include/parallel/base.h (_GLIBCXX_PARALLEL_ASSERT): Always
use do-while in macro expansion.
* include/std/ranges (iota_view::iota_view(W, B)): Remove
redundant braces.

[Bug libfortran/96886] New: valgrind error with optional character argument of unknown length

[ajmay81 at googlemail dot com]

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

Bug ID: 96886
   Summary: valgrind error with optional character argument of
unknown length
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ajmay81 at googlemail dot com
  Target Milestone: ---

Looks like a regression between 10.1.0 and 10.2.0. test.f90:

module test_module
  implicit none
contains
  subroutine testsub0(propnam)
character(*), intent(in), optional :: propnam(*)
if(.not.present(propnam)) then
   stop 'property names not given'
else
   write(*,*) propnam(1)
endif
  end subroutine testsub0
end module test_module

program bug
  use test_module
  implicit none
  character(8) :: prop(1)
  prop(1)='POT'
  call testsub0(propnam=prop)
end program bug

bug> module load gcc/10.2.0
bug> gfortran test.f90 && valgrind ./a.out
==31524== Memcheck, a memory error detector
==31524== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==31524== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==31524== Command: ./a.out
==31524==
==31524== Conditional jump or move depends on uninitialised value(s)
==31524==at 0x400741: __test_module_MOD_testsub0 (in /home/andy/bug/a.out)
==31524==by 0x400825: MAIN__ (in /home/andy/bug/a.out)
==31524==by 0x40085C: main (in /home/andy/bug/a.out)
==31524== 
==31524== Conditional jump or move depends on uninitialised value(s)
==31524==at 0x400762: __test_module_MOD_testsub0 (in /home/andy/bug/a.out)
==31524==by 0x400825: MAIN__ (in /home/andy/bug/a.out)
==31524==by 0x40085C: main (in /home/andy/bug/a.out)
==31524== 
STOP property names not given
==31524== 
==31524== HEAP SUMMARY:
==31524== in use at exit: 0 bytes in 0 blocks
==31524==   total heap usage: 21 allocs, 21 frees, 13,584 bytes allocated
==31524==
==31524== All heap blocks were freed -- no leaks are possible
==31524== 
==31524== Use --track-origins=yes to see where uninitialised values come from
==31524== For lists of detected and suppressed errors, rerun with: -s
==31524== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

bug> module purge
bug> module load gcc/10.1.0 
bug> gfortran test.f90 && valgrind ./a.out
==31516== Memcheck, a memory error detector
==31516== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==31516== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==31516== Command: ./a.out
==31516== 
 POT 
==31516== 
==31516== HEAP SUMMARY:
==31516== in use at exit: 0 bytes in 0 blocks
==31516==   total heap usage: 21 allocs, 21 frees, 13,584 bytes allocated
==31516== 
==31516== All heap blocks were freed -- no leaks are possible
==31516== 
==31516== For lists of detected and suppressed errors, rerun with: -s
==31516== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[Bug target/96882] Wrong assembly code generated with arm-none-eabi-gcc -flto -mfloat-abi=hard options

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Target||arm

--- Comment #4 from Richard Earnshaw  ---
typedef struct {
  double m_a;
  double m_b;
  double m_c;
  double m_d;
} AtLeast32BytesObject;

static AtLeast32BytesObject __attribute__((noinline,noclone)) CalledFunction()
{
  AtLeast32BytesObject result = {1.1, 2.2, 3.3, 4.4};
  return result;
}

void __attribute__((noinline)) _start() {
  volatile AtLeast32BytesObject result = CalledFunction();
  while(1) {}
}

Will miscompile without needing LTO.

[Bug c++/96877] Erroneous warning when default initializing function pointer types defined using std::declval

[insertinterestingnamehere at gmail dot com]

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

--- Comment #4 from Ian Henriksen  
---
It's worth noting that, with g++

using function_type = void (*)(void*) noexcept;

actually works, but

typedef void(*function_type)(void*) noexcept;

does not. clang++ rejects both though.

[Bug c++/96877] Erroneous warning when default initializing function pointer types defined using std::declval

[insertinterestingnamehere at gmail dot com]

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

--- Comment #3 from Ian Henriksen  
---
The goal of doing it that way was get the exception specification onto the
pointer type in C++11 and C++14. The intent was to get the equivalent of

typedef void(*function_type)(void*) noexcept;

but with standards earlier than C++17.

[Bug target/96808] MMA built-in dies with incorrect sharing of tree nodes error

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

   Target Milestone|11.0|10.3

[Bug lto/94311] LTO produces line info entries with invalid line numbers

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
I think the problem is just we ran out of the locations.
We hit both
  if (start_location >= LINE_MAP_MAX_LOCATION)
/* We ran out of line map space.   */
start_location = 0;
in linemap_add and
overflowed:
  /* Remember we overflowed.  */
  set->highest_line = set->highest_location = LINE_MAP_MAX_LOCATION - 1;
  /* No column numbers!  */
  set->max_column_hint = 1;
  return 0;
in linemap_line_start.  While the latter is not that bad, we just get
UNKNOWN_LOCATION, the former is really bad, it just ignores whatever was before
and starts reusing those locations for something different.
Both of these spots are encountered once during this lto1 compilation, on a
total of 149763 linemap_add calls and 267678 linemap_line_start calls, so I'm
surprised that it got so quickly depleted.
Now, looking why it happens so quickly, I think because the line numbers in the
same file keep jumping back and forth extremely often, I see
#0  linemap_line_start (set=0x77ffb000, to_line=256, max_column_hint=17) at
../../libcpp/include/line-map.h:952
#1  0x00d50886 in lto_location_cache::apply_location_cache
(this=0x2dbb868) at ../../gcc/lto-streamer-in.c:191
#2  0x00d50de2 in stream_input_location_now (bp=,
data_in=0x2dbb840) at ../../gcc/lto-streamer-in.c:301
#3  0x0193d125 in input_gimple_stmt (tag=365, data_in=0x2dbb840,
ib=0x7fffcef0) at ../../gcc/gimple-streamer-in.c:111
#4  input_bb (ib=0x7fffcef0, tag=365, data_in=0x2dbb840, fn=0x7fffe7bd6630,
count_materialization_scale=)
at ../../gcc/gimple-streamer-in.c:283
and
#0  linemap_line_start (set=0x77ffb000, to_line=8483, max_column_hint=8) at
../../libcpp/include/line-map.h:952
#1  0x00d50886 in lto_location_cache::apply_location_cache
(this=0x2dbb868) at ../../gcc/lto-streamer-in.c:191
#2  0x00d50de2 in stream_input_location_now (bp=,
data_in=0x2dbb840) at ../../gcc/lto-streamer-in.c:301
#3  0x0193d125 in input_gimple_stmt (tag=365, data_in=0x2dbb840,
ib=0x7fffcef0) at ../../gcc/gimple-streamer-in.c:111
#4  input_bb (ib=0x7fffcef0, tag=365, data_in=0x2dbb840, fn=0x7fffe7bd6630,
count_materialization_scale=)
at ../../gcc/gimple-streamer-in.c:283
alternating all the time for quite a while (minor details on the exact to_line
numbers, but the important is going back and forth between 8NNN and 2NN
numbers).
Now, the backwards jumps result in the linemap_add calls too from (because
line_delta is negative), and when doing the big step forward, while line_delta
is large (larger than 8000).
  || (line_delta > 10
  && line_delta * map->m_column_and_range_bits > 1000)
is false as map->m_column_and_range_bits is 0, but one of the later condition
is true, so we add_map too, but then run into:
  /* Allocate the new line_map.  However, if the current map only has a
 single line we can sometimes just increase its column_bits instead. */
  if (line_delta < 0
  || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map)
  || SOURCE_COLUMN (map, highest) >= (1U << (column_bits - range_bits))
  || ( /* We can't reuse the map if the line offset is sufficiently
  large to cause overflow when computing location_t values.  */
  (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map))
  >= (((uint64_t) 1)
  << (CHAR_BIT * sizeof (linenum_type) - column_bits)))
  || range_bits < map->m_range_bits)
line_delta is > 8000, last_line is equal to ORDINARY_MAP_STARTING_LINE_NUMBER
(map), in the previous linemap_line_start we've called linemap_add because
line_delta was negative, column_bits and range_bits and SOURCE_COLUMN (map,
highest) are all 0 and to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map) is
that 8000-ish number, which is smaller than 1ULL << (8 * 4 - 0) which is 4G.

I think to resolve this we can do multiple things:
1) if possible avoid the stream_input_location_now on each gimple stmt,
that seems to be the killer.
The rationale is:
  /* Read location information.  Caching here makes no sense until streamer
 cache can handle the following gimple_set_block.  */
  gimple_set_location (stmt, stream_input_location_now (, data_in));

  /* Read lexical block reference.  */
  gimple_set_block (stmt, stream_read_tree (ib, data_in));
So perhaps have a way add the block to the location cache, and maybe also avoid
it on PHIs too?

And/or try to limit the to_line jumps much more if we are already at the no
column bits stage.
I can try to create a small testcase tomorrow...

[Bug target/96808] MMA built-in dies with incorrect sharing of tree nodes error

[bergner at gcc dot gnu.org]

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

--- Comment #2 from Peter Bergner  ---
Fixed on trunk.  I'll backport the fix to GCC 10 after a little burn in on
trunk.

[Bug target/96808] MMA built-in dies with incorrect sharing of tree nodes error

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Peter Bergner :

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

commit r11-2970-g8bc0f24d7a20d89383859907b875a26ce59dc6c8
Author: Peter Bergner 
Date:   Tue Sep 1 13:47:44 2020 -0500

rs6000: MMA built-in dies with incorrect sharing of tree nodes error

When we expand our MMA built-ins into gimple, we erroneously reused the
accumulator memory reference for both the source input value as well as
the destination output value.  This led to a tree sharing error.
The solution is to create separate memory references for the input
and output values.

2020-09-01  Peter Bergner  

gcc/
PR target/96808
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Do
not
reuse accumulator memory reference for source and destination
accesses.

gcc/testsuite/
PR target/96808
* gcc.target/powerpc/pr96808.c: New test.

[Bug c++/96877] Erroneous warning when default initializing function pointer types defined using std::declval

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Right. But I don't understand why you'd ever want decltype(std::declval())
because the result is always going to be T&& so if you know T, then you already
know the decltype.

[Bug sanitizer/96885] New: "member call on misaligned address" when calling a second base member through a pointer to member of derived class

[andrey.vihrov at gmail dot com]

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

Bug ID: 96885
   Summary: "member call on misaligned address" when calling a
second base member through a pointer to member of
derived class
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.vihrov at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Consider

struct Base
{
int x;
};

struct OtherBase
{
char c;

void foo() { }
};

struct Derived : Base, OtherBase
{
void *p;
};

int main()
{
Derived d;

void (Derived::*ptr)() = ::foo;

(d.*ptr)();
}

Compiling and running this with "gcc -fsanitize=undefined", the output is

x.cpp:24:13: runtime error: member call on misaligned address
0x7ffd9e0d5b14 for type 'struct Derived', which requires 8 byte alignment
0x7ffd9e0d5b14: note: pointer points here
  79 00 00 00 c8 7f 00 00  6d 72 08 9f 2c 56 00 00  14 72 08 9f 2c 56 00 00
 04 00 00 00 00 00 00 00
  ^ 

AFAICS, since foo() is a member of Derived through OtherBase, a member call
through void (Derived::*)() should be allowed.

gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)

[Bug target/96883] -march=native on AWS aarch64 doesn't work (unknown extensions)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
You need a newer binutils really since aarch64 is still expanding at a rapid
rate.

[Bug c++/96884] Missing diagnostics when applying the member operator on this in class template

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
We give an error when you actually call f in an instance of V:

96884.C: In instantiation of ‘void V::f() [with T = int]’:
96884.C:14:9:   required from here
96884.C:7:16: error: request for member ‘a’ in ‘(V*)this’, which is of
pointer type ‘V*’ (maybe you meant to use ‘->’ ?)
7 |   this.a = 0;
  |   ~^

which is OK.

[Bug c++/96884] New: Missing diagnostics when applying the member operator on this in class template

[anders.granlund.0 at gmail dot com]

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

Bug ID: 96884
   Summary: Missing diagnostics when applying the member operator
on this in class template
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Program (main.cpp):

  template
  class V
  {
  int *a;
  void f()
  {
  this.a = 0;
  }
  };

  int main()
  {
  }

Compilation command line:

  g++ -std=c++17 -pedantic-errors main.cpp

Observed behaviour:

  No compilation errors.

Expected behaviour:

  Compilation error about incorrectly trying to use the member operator (.)
instead of (->) on the this keyword.

Note:

  clang++ gives the expected error message.

[Bug lto/94311] LTO produces line info entries with invalid line numbers

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
When I put a breakpoint on ../../libcpp/line-map.c:1737 with xloc.line > 4
(i.e. near end of linemap_expand_location after xloc.line is set), I see
(gdb) p/x line_table->highest_line
$16 = 0x66e48c7c
(gdb) p/x line_table->highest_location
$17 = 0x66e48c7c
(gdb) p/x loc
$18 = 0x6894a440
in the caller during final notice_source_line -> insn_location ->
expand_location.
I guess I should use -fdump-ipa-cp-lineno to catch it earlier than during
final, anyway, having loc higher than highest_location seems very wrong.

[Bug fortran/96859] Wrong answer with intrinsic merge_bits

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl  ---
On Tue, Sep 01, 2020 at 03:20:20PM +, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859
> 
> --- Comment #9 from Jakub Jelinek  ---
> I've read that.  But I think in this case it is an obvious bug (just, what 
> I've
> missed in the patch, there is another copy of the same bug in another 
> routine).
> The
>   /* Clear first bit.  */
>   if (kind == 1 || kind == 4 || kind == 16)
> {
>   if (buf[0] == '4')
> buf[0] = '0';
>   else if (buf[0] == '5')
> buf[0] = '1';
>   else if (buf[0] == '6')
> buf[0] = '2';
>   else if (buf[0] == '7')
> buf[0] = '3';
> }
> part looks correct, for kind 1, 4 and 16 the calculated len times 3 is 1 
> larger
> than the number of bits it needs, so the above ensures that the first digit is
> 0-3 even if it is 4-7 by subtracting 4.
> But the:
>   /* Clear first two bits.  */
>   else
> {
>   if (buf[0] == '4' || buf[0] == '6')
> buf[0] = '0';
>   else if (buf[0] == '5' || buf[0] == '7')
> buf[0] = '1';
> }
> which is needed for kind 2 and 8, when he calculated len times 3 is 2 larger
> than the number of bits it needs, is only correct for digits 0-1 an 4-7, for
> which it ensures the digit is 0 if it is even and 1 if it is odd.  But 2 and 3
> are kept as is, while they don't fit into 1 bit.
> 

It is certainly possible I have/had an off-by-one in handwritten
conversions I was doing; in particular, I don't often work with
octal numbers.

[Bug c++/96877] Erroneous warning when default initializing function pointer types defined using std::declval

[insertinterestingnamehere at gmail dot com]

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

Ian Henriksen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Ian Henriksen  
---
Actually this is my mistake. std::declval returns by reference, so this is
actually a reference type and the compiler is right to warn about the bad
initialization. In this case the correct thing to do is to remove the reference
after getting the type from decltype.

[Bug fortran/96859] Wrong answer with intrinsic merge_bits

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
I've read that.  But I think in this case it is an obvious bug (just, what I've
missed in the patch, there is another copy of the same bug in another routine).
The
  /* Clear first bit.  */
  if (kind == 1 || kind == 4 || kind == 16)
{
  if (buf[0] == '4')
buf[0] = '0';
  else if (buf[0] == '5')
buf[0] = '1';
  else if (buf[0] == '6')
buf[0] = '2';
  else if (buf[0] == '7')
buf[0] = '3';
}
part looks correct, for kind 1, 4 and 16 the calculated len times 3 is 1 larger
than the number of bits it needs, so the above ensures that the first digit is
0-3 even if it is 4-7 by subtracting 4.
But the:
  /* Clear first two bits.  */
  else
{
  if (buf[0] == '4' || buf[0] == '6')
buf[0] = '0';
  else if (buf[0] == '5' || buf[0] == '7')
buf[0] = '1';
}
which is needed for kind 2 and 8, when he calculated len times 3 is 2 larger
than the number of bits it needs, is only correct for digits 0-1 an 4-7, for
which it ensures the digit is 0 if it is even and 1 if it is odd.  But 2 and 3
are kept as is, while they don't fit into 1 bit.

[Bug analyzer/96792] Analyzer assumes pointer is NULL, even though pointer was dereferenced earlier

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

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

[Bug fortran/96859] Wrong answer with intrinsic merge_bits

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Tue, Sep 01, 2020 at 12:52:49PM +, jakub at gcc dot gnu.org wrote:
> 
> --- Comment #5 from Jakub Jelinek  ---
> I think this boils down to:
> program foo
>   print *, int(o'1234567',2), int(o'1234567',4)
> end program foo
> I believe ifort prints
> 14711 342391
> while gfortran prints
> -18057 342391
> Since 01234567 in C is 0x53977, after that is cast to 16-bit integer that
> should be 0x3977 and thus 14711.
> 

The Fortran standard states how the BOZ string of bits
is padded or truncated if it contains too few or too
many bits.  See F2018, 16.3.3.  Also no that the 
handling of the sign bit is processor dependent.

--
Steve

[Bug lto/94311] LTO produces line info entries with invalid line numbers

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Ok, reproduced with last night's trunk too.
/home/jakub/src/gcc/obj68i/usr/local/bin/lto-dump -dump-body=dis_ESC_0F3A__VEX
-dump-level=lineno libvex_amd64_linux_a-guest_amd64_toIR.o 2>&1 | grep
'toIR.c:[0-9][0-9][0-9][0-9][0-9][0-9]'
prints nothing, so the LTO bytecode looks ok (largest lineno in that file below
33000 or so).
E.g. I see
   [local count: 456515]:
  [priv/guest_amd64_toIR.c:2248:0] _3193 = [priv/guest_amd64_toIR.c:2248:0]
xmm_names[_356];
  [priv/guest_amd64_toIR.c:25336:0] # DEBUG xmmreg => NULL
  [priv/guest_amd64_toIR.c:25336:0] vex_printf
([priv/guest_amd64_toIR.c:25336:0] "vcvtsd2ss %s,%s,%s\n", _3193, _3194,
_3195);
  goto ; [100.00%]

   [local count: 691966]:
  [priv/guest_amd64_toIR.c:25339:0] addr_2000 = disAMode
([priv/guest_amd64_toIR.c:25339:0] , vbi_925(D), pfx_922(D), delta_919,
[priv/guest_amd64_toIR.c:25339:0] _buf, 0);
  [priv/guest_amd64_toIR.c:25339:0] # DEBUG addr => addr_2000
  [priv/guest_amd64_toIR.c:25340:0] # DEBUG tmp => addr_2000
  [priv/guest_amd64_toIR.c:258:0] _3197 = IRExpr_RdTmp (addr_2000);
in the lto-dump, but when I look at -fdump-ipa-cp-lineno from the memcheck
-flto link, I see in memcheck-amd64-linux.ltrans0.ltrans.076i.cp
   [local count: 456515]:
  [priv/guest_amd64_toIR.c:47085:0] _1627 = [priv/guest_amd64_toIR.c:47085:0]
xmm_names[_1626];
  [priv/guest_amd64_toIR.c:47086:0] # DEBUG xmmreg => NULL
  [priv/guest_amd64_toIR.c:47086:0] vex_printf
([priv/guest_amd64_toIR.c:47086:0] "vcvtsd2ss %s,%s,%s\n", _1627, _1625,
_1623);
  goto ; [100.00%]

   [local count: 691966]:
  [priv/guest_amd64_toIR.c:47089:0] addr_1628 = disAMode
([priv/guest_amd64_toIR.c:47089:0] , vbi_15(D), pfx_9(D), delta_6,
[priv/guest_amd64_toIR.c:47089:0] _buf, 0);
  [priv/guest_amd64_toIR.c:47089:0] # DEBUG addr => addr_1628
  [priv/guest_amd64_toIR.c:47090:0] # DEBUG tmp => addr_1628
  [priv/guest_amd64_toIR.c:95985:0] _1629 = IRExpr_RdTmp (addr_1628);
So it looks like most of the line number are just totally bogus.

[Bug c/96882] Wrong assembly code generated with arm-none-eabi-gcc -flto -mfloat-abi=hard options

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Richard Earnshaw  ---
LTO seems to be getting confused as to the ABI.  Investigating...

In the mean time, the only work-around I can think of is to remove -flto from
your build.

[Bug analyzer/96792] Analyzer assumes pointer is NULL, even though pointer was dereferenced earlier

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:49bfbf18c0bb9d83934f0ce765dc031ebfbda38e

commit r11-2968-g49bfbf18c0bb9d83934f0ce765dc031ebfbda38e
Author: David Malcolm 
Date:   Thu Aug 27 07:42:27 2020 -0400

analyzer: fix false NULL deref warning after previous deref [PR96792]

gcc/analyzer/ChangeLog:
PR analyzer/96792
* region-model.cc (region_model::deref_rvalue): Add the constraint
that PTR_SVAL is non-NULL.

gcc/testsuite/ChangeLog:
PR analyzer/96792
* gcc.dg/analyzer/pr96792.c: New test.

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

[clyon at gcc dot gnu.org]

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

--- Comment #27 from Christophe Lyon  ---
Created attachment 49172
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49172=edit
a32/a64 intrinsics not supported by the aarch32/arm target

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

[clyon at gcc dot gnu.org]

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

--- Comment #26 from Christophe Lyon  ---
Created attachment 49171
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49171=edit
v7 intrinsics not supported by the aarch32/arm target

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

[clyon at gcc dot gnu.org]

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

--- Comment #25 from Christophe Lyon  ---
Created attachment 49170
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49170=edit
a64 intrinsics not supported by the aarch64 target

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

[clyon at gcc dot gnu.org]

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

--- Comment #23 from Christophe Lyon  ---
Created attachment 49168
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49168=edit
v7 intrinsics not supported by the aarch64 target

Update 2020-09-01

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

[clyon at gcc dot gnu.org]

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

--- Comment #24 from Christophe Lyon  ---
Created attachment 49169
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49169=edit
a32/a64 intrinsics not supported by the aarch64 target

[Bug fortran/95398] ICE on invalid code

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from markeggleston at gcc dot gnu.org ---
Committed to master and backported to gcc-10.

[Bug fortran/95398] ICE on invalid code

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:84b14e9cd4e05c926a75e8e97ee57dbd3350e752

commit r10-8697-g84b14e9cd4e05c926a75e8e97ee57dbd3350e752
Author: Mark Eggleston 
Date:   Mon Jun 1 08:15:31 2020 +0100

Fortran  : ICE on invalid code PR95398

The CLASS_DATA macro is used to shorten the code accessing the derived
components of an expressions type specification.  If the type is not
BT_CLASS the derived pointer is NULL resulting in an ICE.  To avoid
dereferencing a NULL pointer the type should be BT_CLASS.

2020-09-01  Steven G. Kargl  

gcc/fortran

PR fortran/95398
* resolve.c (resolve_select_type): Add check for BT_CLASS
type before using the CLASS_DATA macro which will have a
NULL pointer to derive components if it isn't BT_CLASS.

2020-09-01  Mark Eggleston  

gcc/testsuite

PR fortran/95398
* gfortran.dg/pr95398.f90: New test.

(cherry picked from commit 3d137b75febd1a4ad70bcc64e0f79198f5571b86)

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

[clyon at gcc dot gnu.org]

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

--- Comment #22 from Christophe Lyon  ---
Applying the recipe from comment #6, the current list of duplicates is:
New ones:
  2 vcmla_laneq_f16
  2 vcmla_rot180_laneq_f16
  2 vcmla_rot270_laneq_f16
  2 vcmla_rot90_laneq_f16

Known, expected (see comment #15):
  2 vshll_high_n_s16
  2 vshll_high_n_s32
  2 vshll_high_n_s8
  2 vshll_high_n_u16
  2 vshll_high_n_u32
  2 vshll_high_n_u8
  2 vshll_n_s16
  2 vshll_n_s32
  2 vshll_n_s8
  2 vshll_n_u16
  2 vshll_n_u32
  2 vshll_n_u8

[Bug target/96883] New: -march=native on AWS aarch64 doesn't work (unknown extensions)

[matthew.thompson at nasa dot gov]

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

Bug ID: 96883
   Summary: -march=native on AWS aarch64 doesn't work (unknown
extensions)
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthew.thompson at nasa dot gov
  Target Milestone: ---

All,

I've recently been experimenting on the Graviton2 processors on AWS and
encountered a possible bug. Namely, -march=native doesn't seem to work:

$ gcc -march=native -O3 test.c
Assembler messages:
Error: unknown architectural extension `sb+ssbs'
Error: unrecognized option -march=armv8.2-a+crypto+fp16+rcpc+dotprod+sb+ssbs

This sort of looks like a duplicate(-ish) of Bugs 88530 and 89508, but those
are closed, so perhaps not.

Of course, my dumb test file isn't needed as the usual help=target shows this
as well:

$ gcc -march=native -Q --help=target
The following options are target specific:
  -mabi=lp64
  -march=  
armv8.2-a+crypto+fp16+rcpc+dotprod+sb+ssbs
  -mbig-endian  [disabled]
  -mbionic  [disabled]
  -mbranch-protection=
  -mcmodel= small
  -mcpu=
  -mfix-cortex-a53-835769   [enabled]
  -mfix-cortex-a53-843419   [enabled]
  -mgeneral-regs-only   [disabled]
  -mglibc   [enabled]
  -mlittle-endian   [enabled]
  -mlow-precision-div   [disabled]
  -mlow-precision-recip-sqrt[disabled]
  -mlow-precision-sqrt  [disabled]
  -mmusl[disabled]
  -momit-leaf-frame-pointer [enabled]
  -moutline-atomics [enabled]
  -moverride=
  -mpc-relative-literal-loads   [enabled]
  -msign-return-address=none
  -mstack-protector-guard-offset=
  -mstack-protector-guard-reg=
  -mstack-protector-guard=  global
  -mstrict-align[disabled]
  -msve-vector-bits=scalable
  -mtls-dialect=desc
  -mtls-size=   [default]
  -mtrack-speculation   [disabled]
  -mtune=
  -muclibc  [disabled]
  -mverbose-cost-dump   [disabled]

  Known AArch64 ABIs (for use with the -mabi= option):
ilp32 lp64

  Supported AArch64 return address signing scope (for use with
-msign-return-address= option):
all non-leaf none

  The code model option names for -mcmodel:
large small tiny

  Valid arguments to -mstack-protector-guard=:
global sysreg

  The possible SVE vector lengths:
1024 128 2048 256 512 scalable

  The possible TLS dialects:
desc trad

Assembler messages:
Error: unknown architectural extension `sb+ssbs'
Error: unrecognized option -march=armv8.2-a+crypto+fp16+rcpc+dotprod+sb+ssbs

While I'm not sure it matters, I was on a c6g.4xlarge instance. (Which I think
is Neoverse N1, but I'm not too sure and the mcpu/mtune above don't print it,
so maybe not.)

Also, per guidelines:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/ubuntu/GCC/10.2.0/libexec/gcc/aarch64-unknown-linux-gnu/10.2.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../gcc-10.2.0/configure --prefix=/home/ubuntu/GCC/10.2.0
--disable-multilib --enable-languages=c,c++,fortran
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)

[Bug c/96882] Wrong assembly code generated with arm-none-eabi-gcc -flto -mfloat-abi=hard options

[emilie.feral at numworks dot com]

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

--- Comment #2 from emilie.feral at numworks dot com ---
Here they are:

arm-none-eabi-gcc -v
•[master]
Using built-in specs.
COLLECT_GCC=/Applications/ARM/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/Applications/ARM/bin/../lib/gcc/arm-none-eabi/9.3.1/lto-wrapper
Target: arm-none-eabi
Configured with:
/tmp/jenkins-GCC-9-pipeline-200_20200521_1590053285/src/gcc/configure
--target=arm-none-eabi
--prefix=/tmp/jenkins-GCC-9-pipeline-200_20200521_1590053285/install-native
--libexecdir=/tmp/jenkins-GCC-9-pipeline-200_20200521_1590053285/install-native/lib
--infodir=/tmp/jenkins-GCC-9-pipeline-200_20200521_1590053285/install-native/share/doc/gcc-arm-none-eabi/info
--mandir=/tmp/jenkins-GCC-9-pipeline-200_20200521_1590053285/install-native/share/doc/gcc-arm-none-eabi/man
--htmldir=/tmp/jenkins-GCC-9-pipeline-200_20200521_1590053285/install-native/share/doc/gcc-arm-none-eabi/html
--pdfdir=/tmp/jenkins-GCC-9-pipeline-200_20200521_1590053285/install-native/share/doc/gcc-arm-none-eabi/pdf
--enable-languages=c,c++ --enable-plugins --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath
--disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib
--with-headers=yes --with-python-dir=share/gcc-arm-none-eabi
--with-sysroot=/tmp/jenkins-GCC-9-pipeline-200_20200521_1590053285/install-native/arm-none-eabi
--build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10
--with-gmp=/tmp/jenkins-GCC-9-pipeline-200_20200521_1590053285/build-native/host-libs/usr
--with-mpfr=/tmp/jenkins-GCC-9-pipeline-200_20200521_1590053285/build-native/host-libs/usr
--with-mpc=/tmp/jenkins-GCC-9-pipeline-200_20200521_1590053285/build-native/host-libs/usr
--with-isl=/tmp/jenkins-GCC-9-pipeline-200_20200521_1590053285/build-native/host-libs/usr
--with-libelf=/tmp/jenkins-GCC-9-pipeline-200_20200521_1590053285/build-native/host-libs/usr
--with-host-libstdcxx='-static-libgcc -Wl,-lstdc++ -lm' --with-pkgversion='GNU
Arm Embedded Toolchain 9-2020-q2-update'
--with-multilib-list=rmprofile,aprofile
Thread model: single
gcc version 9.3.1 20200408 (release) (GNU Arm Embedded Toolchain
9-2020-q2-update)

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

[clyon at gcc dot gnu.org]

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

--- Comment #21 from Christophe Lyon  ---
Created attachment 49167
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49167=edit
Full list of intrinsics documented for a64

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

[clyon at gcc dot gnu.org]

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

--- Comment #20 from Christophe Lyon  ---
Created attachment 49166
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49166=edit
Full list of intrinsics documented for a32/a64

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

[clyon at gcc dot gnu.org]

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

--- Comment #19 from Christophe Lyon  ---
Created attachment 49165
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49165=edit
Full list of intrinsics documented for v7/a32/a64

[Bug fortran/96859] Wrong answer with intrinsic merge_bits

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Full untested patch.

[Bug c/96882] Wrong assembly code generated with arm-none-eabi-gcc -flto -mfloat-abi=hard options

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-09-01

--- Comment #1 from Richard Earnshaw  ---
We need to see the configuration information.  What is the output of "gcc -v"
for your compiler?

[Bug debug/82202] Missing debug information in LTO/offload compilation

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
I fixed this for GCC 10, can you re-check?

[Bug fortran/95352] ICE on select rank with assumed-size selector and lbound intrinsic

[jrfsousa at gmail dot com]

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

José Rui Faustino de Sousa  changed:

   What|Removed |Added

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

--- Comment #8 from José Rui Faustino de Sousa  ---
Fixed by:

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

[Bug fortran/96728] Fatal Error: Reading module inquiry functions on assumed-rank

[jrfsousa at gmail dot com]

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

José Rui Faustino de Sousa  changed:

   What|Removed |Added

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

--- Comment #5 from José Rui Faustino de Sousa  ---
Fixed by:

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

[Bug fortran/96727] ICE with character length specified using specification function on assumed-rank array

[jrfsousa at gmail dot com]

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

José Rui Faustino de Sousa  changed:

   What|Removed |Added

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

--- Comment #4 from José Rui Faustino de Sousa  ---
Fixed by:

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

[Bug fortran/96726] ICE with user defined specification function on assumed-rank array

[jrfsousa at gmail dot com]

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

José Rui Faustino de Sousa  changed:

   What|Removed |Added

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

--- Comment #4 from José Rui Faustino de Sousa  ---
Fixed by:

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

[Bug fortran/96859] Wrong answer with intrinsic merge_bits

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Untested fix:
--- gcc/fortran/check.c.jj  2020-08-24 10:00:01.424256990 +0200
+++ gcc/fortran/check.c 2020-09-01 15:06:45.428938642 +0200
@@ -429,9 +429,9 @@ gfc_boz2int (gfc_expr *x, int kind)
   /* Clear first two bits.  */
   else
{
- if (buf[0] == '4' || buf[0] == '6')
+ if (buf[0] == '2' || buf[0] == '4' || buf[0] == '6')
buf[0] = '0';
- else if (buf[0] == '5' || buf[0] == '7')
+ else if (buf[0] == '3' || buf[0] == '5' || buf[0] == '7')
buf[0] = '1';
}
 }

[Bug fortran/94110] Passing an assumed-size to an assumed-shape argument should be rejected

[jrfsousa at gmail dot com]

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

José Rui Faustino de Sousa  changed:

   What|Removed |Added

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

--- Comment #4 from José Rui Faustino de Sousa  ---
Fixed by:

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

[Bug c/96882] New: Wrong assembly code generated with arm-none-eabi-gcc -flto -mfloat-abi=hard options

[emilie.feral at numworks dot com]

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

Bug ID: 96882
   Summary: Wrong assembly code generated with arm-none-eabi-gcc
-flto -mfloat-abi=hard options
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: emilie.feral at numworks dot com
  Target Milestone: ---

Created attachment 49163
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49163=edit
preprocessed file triggering the bug

Hi,

When compiling the following code:

//

typedef struct {
  double m_a;
  double m_b;
  double m_c;
  double m_d;
} AtLeast32BytesObject;

AtLeast32BytesObject __attribute__((noinline)) CalledFunction() {
  AtLeast32BytesObject result = {1.1, 2.2, 3.3, 4.4};
  return result;
}

void __attribute__((noinline)) _start() {
  volatile AtLeast32BytesObject result = CalledFunction();
  while(1) {}
}

//

with "arm-none-eabi-gcc -Os -flto -mthumb -mfloat-abi=hard -mcpu=cortex-m4
-ffreestanding -nostdlib -lgcc", the assembly instructions emitted for the
symbol "CalledFunction" use callee-save registers r4-r7 to store the result of
the CalledFunction procedure (cf following disassemble function addresses range
0x805e-0x806e). The registers r4-r7 are overwritten when leaving the
subroutine (since they're callee-save registers) leading to a corrupted result
from "CalledFunction" (cf following disassemble function at address
0x8072).

Dump of assembler code for function CalledFunction:
   0x8000 <+0>: push {r4, r5, r6, r7, lr}
   0x8002 <+2>: ldr r5, [pc, #112] ; (0x8074 )
   0x8004 <+4>: ldmia r5!, {r0, r1, r2, r3}
   0x8006 <+6>: sub sp, #132 ; 0x84
   0x8008 <+8>: add r4, sp, #64 ; 0x40
   0x800a <+10>: stmia r4!, {r0, r1, r2, r3}
   0x800c <+12>: ldmia.w r5, {r0, r1, r2, r3}
   0x8010 <+16>: add r5, sp, #64 ; 0x40
   0x8012 <+18>: stmia.w r4, {r0, r1, r2, r3}
   0x8016 <+22>: ldmia r5!, {r0, r1, r2, r3}
   0x8018 <+24>: add r4, sp, #96 ; 0x60
   0x801a <+26>: stmia r4!, {r0, r1, r2, r3}
   0x801c <+28>: ldmia.w r5, {r0, r1, r2, r3}
   0x8020 <+32>: stmia.w r4, {r0, r1, r2, r3}
   0x8024 <+36>: ldr r3, [sp, #96] ; 0x60
   0x8026 <+38>: str r3, [sp, #0]
   0x8028 <+40>: ldr r3, [sp, #100] ; 0x64
   0x802a <+42>: str r3, [sp, #4]
   0x802c <+44>: ldr r3, [sp, #104] ; 0x68
   0x802e <+46>: str r3, [sp, #8]
   0x8030 <+48>: ldr r3, [sp, #108] ; 0x6c
   0x8032 <+50>: str r3, [sp, #12]
   0x8034 <+52>: ldr r3, [sp, #112] ; 0x70
   0x8036 <+54>: str r3, [sp, #16]
   0x8038 <+56>: ldr r3, [sp, #116] ; 0x74
   0x803a <+58>: ldr r7, [sp, #124] ; 0x7c
   0x803c <+60>: str r3, [sp, #20]
   0x803e <+62>: ldr r3, [sp, #120] ; 0x78
   0x8040 <+64>: strd r3, r7, [sp, #24]
   0x8044 <+68>: ldr r3, [sp, #0]
   0x8046 <+70>: str r3, [sp, #32]
   0x8048 <+72>: ldr r3, [sp, #4]
   0x804a <+74>: str r3, [sp, #36] ; 0x24
   0x804c <+76>: ldr r3, [sp, #8]
   0x804e <+78>: str r3, [sp, #40] ; 0x28
   0x8050 <+80>: ldr r3, [sp, #12]
   0x8052 <+82>: str r3, [sp, #44] ; 0x2c
   0x8054 <+84>: ldr r3, [sp, #16]
   0x8056 <+86>: str r3, [sp, #48] ; 0x30
   0x8058 <+88>: ldr r3, [sp, #20]
   0x805a <+90>: str r3, [sp, #52] ; 0x34
   0x805c <+92>: ldr r3, [sp, #24]
   0x805e <+94>: strd r3, r7, [sp, #56] ; 0x38 // HERE, we store
   0x8062 <+98>: ldrd r0, r1, [sp, #32] // the result
   0x8066 <+102>: ldrd r2, r3, [sp, #40] ; 0x28 // in r0-r7
   0x806a <+106>: ldrd r4, r5, [sp, #48] ; 0x30 //
   0x806e <+110>: ldr r6, [sp, #56] ; 0x38 //
   0x8070 <+112>: add sp, #132 ; 0x84
   0x8072 <+114>: pop {r4, r5, r6, r7, pc} // HERE, we overwrite r4-r7
   0x8074 <+116>: strh r0, [r5, #4]
   0x8076 <+118>: movs r0, r0
End of assembler dump.

I attach to this report the "main.i" containing the previous preprocessed code.

The toolchain version is arm-none-eabi-gcc (GNU Arm Embedded Toolchain
9-2020-q2-update) 9.3.1 20200408 (release).
It was from the binary package gcc-arm-none-eabi-9-2020-q2-update-mac.pkg
downloaded from
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads.
The host machine is a MacBook Pro with Catalina version 10.15.4 (19E287).

The command lines I used are:

arm-none-eabi-gcc main.c -Os -flto -mthumb -mfloat-abi=hard -mcpu=cortex-m4
-ffreestanding -nostdlib -lgcc -save-temps -o a.elf

arm-none-eabi-gdb -batch -ex 'file a.elf' -ex 'disassemble CalledFunction'

Thanks for your help,
Émilie

[Bug fortran/96859] Wrong answer with intrinsic merge_bits

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Status|WAITING |NEW

--- Comment #5 from Jakub Jelinek  ---
I think this boils down to:
program foo
  print *, int(o'1234567',2), int(o'1234567',4)
end program foo
I believe ifort prints
14711 342391
while gfortran prints
-18057 342391
Since 01234567 in C is 0x53977, after that is cast to 16-bit integer that
should be 0x3977 and thus 14711.

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

[clyon at gcc dot gnu.org]

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

--- Comment #18 from Christophe Lyon  ---
The list at
https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics
has a new format (the list is split in 146 pages, I couldn't find how to get
the list on a single page). So I used 'lynx' to download all the pages in a
text format, which I am attaching now.

[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics

[clyon at gcc dot gnu.org]

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

--- Comment #17 from Christophe Lyon  ---
Created attachment 49162
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49162=edit
Full Neon intrinsics list as of 2020-09-01.

Full Neon intrinsics list as of 2020-09-01.

[Bug fortran/96859] Wrong answer with intrinsic merge_bits

[zhen...@compiler-dev.com]

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

--- Comment #4 from zhen...@compiler-dev.com ---
(In reply to kargl from comment #2)
> gfortran appears to be correct.  Writing an actual program with your
> examples, I have
> 
> program foo
>print '(I0,1X,I0)', &
>&  merge_bits(32767_2,o'1234567',32767_2), &
>&  ior(iand(32767_2,32767_2),iand(o'1234567',not(32767_2)))
> 
>print '(I0,1X,I0)', &
>&  merge_bits(o'1234567',32767_2,o'1234567'), &
>&
> ior(iand(o'1234567',int(o'1234567',2)),iand(32767_2,not(int(o'1234567',2
> 
>print '(I0,1X,I0)', &
>&  merge_bits(32767_2,o'1234567',b'010101'), &
>&  ior(iand(32767_2,b'010101'),iand(o'1234567', not(int(b'010101',2
> 
>print '(I0,1X,I0)', &
>&  merge_bits(32767_2,o'1234567',z'12345678'), &
>&  ior(iand(32767_2,z'12345678'), iand(o'1234567',not(int(
> z'12345678',2
> end program foo

I compiled your code with gfortran-10, getting result:
-1 -1
-1 -1
-18057 -18057
-129 -129


The right one should be:
32767 32767
32767 32767
14711 14711
32639 32639

[Bug fortran/96859] Wrong answer with intrinsic merge_bits

[zhen...@compiler-dev.com]

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

--- Comment #3 from zhen...@compiler-dev.com ---
(In reply to Dominique d'Humieres from comment #1)
> What results do you expect?

merge_bits(32767_2, o'1234567', 32767_2)
merge_bits(o'1234567', 32767_2, o'1234567')
merge_bits(32767_2, o'1234567', b'010101')
merge_bits(32767_2, o'1234567', z'12345678')


The four corresponding results should be:
32767
32767
14711
32639

I checked the Fortran 2008 standard and confirmed the results with hand
calculation.

[Bug lto/94311] LTO produces line info entries with invalid line numbers

[mark at gcc dot gnu.org]

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

--- Comment #8 from Mark Wielaard  ---
Note that VEX/priv/guest_arm64_toIR.c is fairly big (1.2M):
$ wc VEX/priv/guest_amd64_toIR.c
  32655  127564 1189783 VEX/priv/guest_amd64_toIR.c
(but still less than 2^15 lines)

[Bug lto/94311] LTO produces line info entries with invalid line numbers

[mark at gcc dot gnu.org]

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

--- Comment #7 from Mark Wielaard  ---
Note that the above is in ./install/lib/valgrind/memcheck-amd64-linux

Which has .debug_line entries like:

  [0x00098404]  Set is_stmt to 0
  [0x00098405]  Advance PC by constant 17 to 0x5809993c
  [0x00098406]  Special opcode 103: advance Address by 7 to 0x58099943 and Line 
by 0 to 13372
  [0x00098407]  Set is_stmt to 1
  [0x00098408]  Advance Line by 23257547 to 23270919
  [0x0009840d]  Special opcode 145: advance Address by 10 to 0x5809994d and
Line by 0 to 23270919
  [0x0009840e]  Advance Line by 58034 to 23328953
  [0x00098412]  Special opcode 117: advance Address by 8 to 0x58099955 and Line
by 0 to 23328953
  [0x00098413]  Advance Line by 75462 to 23404415
  [0x00098417]  Special opcode 131: advance Address by 9 to 0x5809995e and Line
by 0 to 23404415
  [0x00098418]  Advance Line by -23388426 to 15989
  [0x0009841d]  Special opcode 187: advance Address by 13 to 0x5809996b and
Line by 0 to 15989

with readelf --debug-dump=decodedline we see:

priv/guest_amd64_toIR.c:
guest_amd64_toIR.c  1505  0x580998b8   
   x
guest_amd64_toIR.c 23769  0x580998d8   
   x
guest_amd64_toIR.c 10611  0x580998f1   
   x
guest_amd64_toIR.c 10611  0x580998f8
guest_amd64_toIR.c 10610  0x580998f8   1   
   x
guest_amd64_toIR.c 24067  0x58099900   
   x
guest_amd64_toIR.c 24067  0x58099900   1
guest_amd64_toIR.c 13368  0x58099917   
   x
guest_amd64_toIR.c 13368  0x5809991e
guest_amd64_toIR.c 14968  0x5809991e   1   
   x
guest_amd64_toIR.c 13368  0x58099926   
   x
guest_amd64_toIR.c 13368  0x5809992b
guest_amd64_toIR.c 13372  0x5809992b   1   
   x
guest_amd64_toIR.c 13372  0x58099943
guest_amd64_toIR.c  23270919  0x5809994d   
   x
guest_amd64_toIR.c  23328953  0x58099955   
   x
guest_amd64_toIR.c  23404415  0x5809995e   
   x
guest_amd64_toIR.c 15989  0x5809996b   
   x
guest_amd64_toIR.c 15989  0x58099970
guest_amd64_toIR.c 15055  0x58099970   1   
   x
guest_amd64_toIR.c  1254  0x5809997d   
   x
guest_amd64_toIR.c  1253  0x58099980   
   x
guest_amd64_toIR.c   226  0x58099982   
   x
guest_amd64_toIR.c   226  0x58099987
guest_amd64_toIR.c 14316  0x58099987   1   
   x
guest_amd64_toIR.c   226  0x5809998c   
   x
guest_amd64_toIR.c   226  0x5803
guest_amd64_toIR.c 14316  0x5803   1   
   x
guest_amd64_toIR.c 14315  0x5806   
   x
guest_amd64_toIR.c 14316  0x5809   
   x
guest_amd64_toIR.c   226  0x580c   
   x
guest_amd64_toIR.c   226  0x580999a0
guest_amd64_toIR.c 14316  0x580999a0   1   
   x
guest_amd64_toIR.c 14316  0x580999a2
guest_amd64_toIR.c   226  0x580999a2   1   
   x
guest_amd64_toIR.c   226  0x580999a7
guest_amd64_toIR.c   226  0x580999b4
guest_amd64_toIR.c   226  0x580999c5
guest_amd64_toIR.c   226  0x580999ca
guest_amd64_toIR.c   226  0x580999d7
guest_amd64_toIR.c   226  0x580999dc
guest_amd64_toIR.c  5664  0x580999dc   1   
   x
guest_amd64_toIR.c   226  0x580999e0   
   x
guest_amd64_toIR.c   226  0x580999e4
guest_amd64_toIR.c  5664  0x580999e4   1   
   x

[Bug middle-end/90597] [9/10/11 Regression] FAIL: gcc.dg/attr-vector_size.c (internal compiler error)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

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

commit r11-2965-gb61eaa25b0812a5996024e0ddb3535dde5a89c88
Author: Roger Sayle 
Date:   Tue Sep 1 12:03:21 2020 +0100

PR middle-end/90597: gcc_assert ICE in layout_type

This patch fixes the default implementation of TARGET_VECTOR_ALIGNMENT,
known as default_vector_alignment, using the same logic as my earlier
nvptx patch, as the ICE caused by TYPE_SIZE(type) being zero during
error handling in gcc.dg/attr-vector_size.c is common among backends,
and is known in bugzilla as PR middle-end/90597, apparently a recent
regression.

2020-09-01  Roger Sayle  

gcc/ChangeLog:
PR middle-end/90597
* targhooks.c (default_vector_alignment): Return at least the
GET_MODE_ALIGNMENT for the type's mode.

[Bug c++/96878] Failed class template argument deduction in unevaluated, parenthesized context

[sbergman at redhat dot com]

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

--- Comment #1 from Stephan Bergmann  ---
A similar failure happens with typeid (but where the parentheses are not
redundant), and I naively assume it's the same underlying issue:

> $ cat test.cc
> #include 
> template struct S { S(char const (& s)[N]); };
> void f() { (void) typeid (S("")); }

> $ g++ -std=c++17 -fsyntax-only test.cc
> test.cc: In function ‘void f()’:
> test.cc:3:27: error: missing template arguments after ‘S<...auto...>’
> 3 | void f() { (void) typeid (S("")); }
>   |   ^
> test.cc:2:24: note: ‘template struct S’ declared here
> 2 | template struct S { S(char const (& s)[N]); };
>   |^

[Bug tree-optimization/96722] [8/9 Regression] Clobbers on NULL since r8-1519

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8/9 Regression] Clobbers
   |Clobbers on NULL since  |on NULL since r8-1519
   |r8-1519 |

--- Comment #11 from Jakub Jelinek  ---
CDDCE part moved to PR96881.  This bug tracks the path isolation, which is now
fixed for 10.3+ and 11.1+.

[Bug tree-optimization/96881] [8/9/10/11 Regression] Clobbers on NULL vs. DCE since r8-1519

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
This PR should cover the CDDCE part of PR96722, e.g. as mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96722#c6

[Bug tree-optimization/96881] New: [8/9/10/11 Regression] Clobbers on NULL vs. DCE since r8-1519

[jakub at gcc dot gnu.org]

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

Bug ID: 96881
   Summary: [8/9/10/11 Regression] Clobbers on NULL vs. DCE since
r8-1519
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, marxin at gcc dot gnu.org,
rguenth at gcc dot gnu.org, slyfox at gcc dot gnu.org,
unassigned at gcc dot gnu.org, webrown.cpp at gmail dot com
Depends on: 96717, 96722
Blocks: 96721
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #96722 +++

struct S { int s; ~S () {} };

void
foo (S *a)
{
  if (a)
return;
  a->~S ();
}

int
main ()
{
  S s;
  foo ();
}

is miscompiled, since r249450 aka
r8-1519-ge59a1c22fb249388e82b4fd004f33615abe36d2e at -O2.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96717
[Bug 96717] -flifetime-dse=2 breaks webkit-gtk-2.28.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96721
[Bug 96721] [11 Regression] pseudo-destructor calls on pointers since r11-2238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96722
[Bug 96722] [8/9/10/11 Regression] Clobbers on NULL since r8-1519

[Bug lto/94311] LTO produces line info entries with invalid line numbers

[mark at gcc dot gnu.org]

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

--- Comment #6 from Mark Wielaard  ---
(In reply to Mark Wielaard from comment #5)
> I can no longer replicate the issue of the bad line numbers with gcc (GCC)
> 10.1.1 20200507 (Red Hat 10.1.1-1) on fedora 32. With either 3.15.0 or
> current valgrind git.

Note that current valgrind git hides these warnings:

commit 5920eb0c4302015f3648354e4f9c059f899194b7
Author: Philippe Waroquiers 
Date:   Tue Feb 18 21:35:44 2020 +0100

Improve line info tracing, in particular when using lto.

With gcc 9 and --enable-lto, we now have spurious warnings telling
that the line information in the debug info has huge line numbers,
greater than the (valgrind) maximum of 2^20.

These spurious warnings make that all tests are failing.

This change modifies the tracing/debugging of the line info to:
  * disable by default the warning for line info greater than 2^20.
When using -d, such warnings are however still shown (once).
  * allow to see all such warnings, when using at least -d -d -d -d

And I am able to replicate with valgrind git on Fedora 32 with gcc (GCC) 10.2.1
20200723 (Red Hat 10.2.1-1) gcc-10.2.1-1.fc32.x86_64

 $ { ./autogen.sh; ./configure --prefix=`pwd`/install --enable-only64bit
--enable-lto; make -j8 install; } >& build.log
 $ ./install/bin/valgrind -d date 2>&1 | grep info\ entry
==110351== warning: Can't handle line info entry with line number 23270919
greater than 1048575
==110351== warning: Can't handle inlined call info entry with line number
23270918 greater than 1048575

[Bug fortran/95398] ICE on invalid code

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2964-g3d137b75febd1a4ad70bcc64e0f79198f5571b86
Author: Mark Eggleston 
Date:   Mon Jun 1 08:15:31 2020 +0100

Fortran  : ICE on invalid code PR95398

The CLASS_DATA macro is used to shorten the code accessing the derived
components of an expressions type specification.  If the type is not
BT_CLASS the derived pointer is NULL resulting in an ICE.  To avoid
dereferencing a NULL pointer the type should be BT_CLASS.

2020-09-01  Steven G. Kargl  

gcc/fortran

PR fortran/95398
* resolve.c (resolve_select_type): Add check for BT_CLASS
type before using the CLASS_DATA macro which will have a
NULL pointer to derive components if it isn't BT_CLASS.

2020-09-01  Mark Eggleston  

gcc/testsuite

PR fortran/95398
* gfortran.dg/pr95398.f90: New test.

[Bug rtl-optimization/96812] gcc.dg/torture/pr90328.c FAILs with -fno-ivopts

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2963-gd6a05b494b4b714e996a5ca09c5a4a1c41dbd648
Author: Richard Biener 
Date:   Thu Aug 27 14:21:33 2020 +0200

rtl-optimization/96812 - remap dependence info on RTL loop unrolling

This carries over the PR87609 fix also to RTL loop unrolling.  The
gcc.dg/torture/pr90328.c testcase otherwise is miscompiled with
the tree-ssa-address.c hunk (or alternatively with -fno-ivopts
on master).  I've tried to find the correct abstraction and
adjusted two other duplicate_insn_chain users for which I do not
have testcases.  There may be other insn-chain copying routines
that could be affected but hopefully most appropriately go through
CFG hooks.

2020-08-27  Richard Biener  

PR rtl-optimization/96812
* tree-ssa-address.c (copy_ref_info): Also copy dependence info.
* cfgrtl.h (duplicate_insn_chain): Adjust prototype.
* cfgrtl.c (duplicate_insn_chain): Remap dependence info
if requested.
(cfg_layout_duplicate_bb): Make sure we remap dependence info.
* modulo-sched.c (duplicate_insns_of_cycles): Remap dependence
info.
(generate_prolog_epilog): Adjust.
* config/c6x/c6x.c (hwloop_optimize): Remap dependence info.

[Bug rtl-optimization/96812] gcc.dg/torture/pr90328.c FAILs with -fno-ivopts

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/94301] Missed vector-vector CTOR / permute simplification

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Testcase

typedef double v1df __attribute__((vector_size(8)));
typedef double v2df __attribute__((vector_size(16)));
typedef long v2di __attribute__((vector_size(16)));

v2df __GIMPLE(ssa) foo (v1df x, v1df z)
{
  v2df y;

  __BB(2):
   y_2 = _Literal (v2df) { x_1(D), _Literal (v1df) { 0.0 } };
  y_3 = _Literal (v2df) { z_4(D), _Literal (v1df) { 0.0 } };
  y_5 = __VEC_PERM (y_2, y_3, _Literal (v2di) { 0l, 2l });
  y_6 = __VEC_PERM (y_5, y_5, _Literal (v2di) { 0l, 0l });
  return y_6;
}


> ./cc1 -quiet t.c -fgimple -O
during RTL pass: expand
t.c: In function 'foo':
t.c:5:20: internal compiler error: in require, at machmode.h:293
5 | v2df __GIMPLE(ssa) foo (v1df x, v1df z)
  |^~~
0xb84809 opt_mode::require() const
/home/rguenther/src/gcc2/gcc/machmode.h:293
0xd5da8c store_integral_bit_field
/home/rguenther/src/gcc2/gcc/expmed.c:1006
0xd5d2fe store_bit_field_1
/home/rguenther/src/gcc2/gcc/expmed.c:873


works with -O0.  With -O we expand from

  y_2 = {x_1(D), { 0.0 }};
  y_4 = BIT_INSERT_EXPR ;
  y_5 = VEC_PERM_EXPR ;
  return y_5;

and the issue is that 'value' is

(mem/c:BLK (plus:DI (reg/f:DI 76 virtual-incoming-args)
(const_int 8 [0x8])) [1 z+0 S8 A64])

because V1DF isn't a supported vector mode on x86_64 and vector lowering
doesn't do anything to it either.  Eventually V1m types should fall back to
the component mode transparently.  ABI-wise we seem to pass V1DF on the
stack ...

So the "simple" patch

diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
index bde6fa22b58..90fc34e5a2c 100644
--- a/gcc/stor-layout.c
+++ b/gcc/stor-layout.c
@@ -512,6 +512,10 @@ mode_for_vector (scalar_mode innermode, poly_uint64
nunits)
return mode;
 }

+  /* For single-element vectors, map it to the component mode.  */
+  if (known_eq (nunits, 1))
+return innermode;
+
   return opt_machine_mode ();
 }


not only fixes the ICE and generates optimal code but also changes the ABI...

[Bug c++/96880] undefined reference to `__dynamic_cast' when compiling with -fsanitize=vptr and -static

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The problem is that lang_specific_driver adds -lstdc++ -lm before the generic
code adds -lubsan.
If you link normally (dynamically), it will work just fine.
Or you can always add -lubsan -lstdc++
Not sure how to fix this properly, the C++ lang_specific_driver doesn't see the
-lubsan option that is only added later on and where exactly in the arguments
-lstdc++ ends up is not something gcc.c can predict.

[Bug tree-optimization/96597] valgrind error in do_hoist_insertion during O3 build

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8696-gc863dec102e0a636b99100639f523d084aafce4e
Author: Martin Liska 
Date:   Thu Aug 13 13:05:12 2020 +0200

Add missing vn_reference_t::punned initialization

gcc/ChangeLog:

PR tree-optimization/96597
* tree-ssa-sccvn.c (vn_reference_lookup_call): Add missing
initialization of ::punned.
(vn_reference_insert): Use consistently false instead of 0.
(vn_reference_insert_pieces): Likewise.

(cherry picked from commit adc646b10c7168c3c95373ee9321e3760fc4c5f1)

[Bug tree-optimization/88240] [8/9/10 Regression] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:7442a775817db6065b8eed4d9d9f57611c7d09aa

commit r10-8695-g7442a775817db6065b8eed4d9d9f57611c7d09aa
Author: Richard Biener 
Date:   Tue Aug 4 14:10:45 2020 +0200

tree-optimization/88240 - stopgap for floating point code-hoisting issues

This adds a stopgap measure to avoid performing code-hoisting
on mixed type loads when the load we'd insert in the hoisting
position would be a floating point one.  This is because certain
targets (hello x87) cannot perform floating point loads without
possibly altering the bit representation and thus cannot be used
in place of integral loads.

2020-08-04  Richard Biener  

PR tree-optimization/88240
* tree-ssa-sccvn.h (vn_reference_s::punned): New flag.
* tree-ssa-sccvn.c (vn_reference_insert): Initialize punned.
(vn_reference_insert_pieces): Likewise.
(visit_reference_op_call): Likewise.
(visit_reference_op_load): Track whether a ref was punned.
* tree-ssa-pre.c (do_hoist_insertion): Refuse to perform hoist
insertion on punned floating point loads.

* gcc.target/i386/pr88240.c: New testcase.

(cherry picked from commit 1af5cdd77985daf76130f527deac425c43df9f49)

[Bug c++/96880] New: undefined reference to `__dynamic_cast' when compiling with -fsanitize=vptr and -static

[fakepaper56 at gmail dot com]

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

Bug ID: 96880
   Summary: undefined reference to `__dynamic_cast' when compiling
with -fsanitize=vptr and -static
   Product: gcc
   Version: 7.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fakepaper56 at gmail dot com
  Target Milestone: ---

I compiled the following code with '-fsanitize=vptr -static'.But I had error
message '-fsanitize=vptr -static'

struct A {
  virtual ~A() {};
};

int main() { A a; }

Enviorment:
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu

Compiled option:
g++ vptr.i -fsanitize=vptr -static

Output error:
/usr/lib/gcc/x86_64-linux-gnu/7/libubsan.a(ubsan_type_hash_itanium.o): In
function `isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*,
__cxxabiv1::__class_type_info const*, long)':
(.text+0x52): undefined reference to `__dynamic_cast'
(.text+0x5e): undefined reference to `typeinfo for
__cxxabiv1::__vmi_class_type_info'
(.text+0x6b): undefined reference to `__dynamic_cast'
/usr/lib/gcc/x86_64-linux-gnu/7/libubsan.a(ubsan_type_hash_itanium.o): In
function `findBaseAtOffset(__cxxabiv1::__class_type_info const*, long)':
(.text+0x151): undefined reference to `__dynamic_cast'
(.text+0x15d): undefined reference to `typeinfo for
__cxxabiv1::__vmi_class_type_info'
(.text+0x16a): undefined reference to `__dynamic_cast'
/usr/lib/gcc/x86_64-linux-gnu/7/libubsan.a(ubsan_type_hash_itanium.o): In
function `__ubsan::checkDynamicType(void*, void*, unsigned long)':
(.text+0x293): undefined reference to `__dynamic_cast'
collect2: error: ld returned 1 exit status

[Bug target/96879] [11 Regresssion] ICE in native_encode_rtx, at simplify-rtx.c:6482

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Version|10.0|11.0
   Target Milestone|--- |11.0

[Bug target/96879] [11 Regresssion] ICE in native_encode_rtx, at simplify-rtx.c:6482

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This is an aarch64 backend bug (I needed -fno-section-anchors to trigger
though).
aarch64_expand_mov_immediate has:
case SYMBOL_FORCE_TO_MEM:
  if (const_offset != 0
  && targetm.cannot_force_const_mem (int_mode, imm))
{
  gcc_assert (can_create_pseudo_p ());
  base = aarch64_force_temporary (int_mode, dest, base);
  aarch64_add_offset (int_mode, dest, base, const_offset,
  NULL_RTX, NULL_RTX, false);
  return;
}

  mem = force_const_mem (ptr_mode, imm);
  gcc_assert (mem);
and is called with int_mode DImode and imm is a DImode SYMBOL_REF.  As ptr_mode
is SImode, the call to force_const_mem is invalid:
/* Given a constant rtx X, make (or find) a memory constant for its value
   and return a MEM rtx to refer to it in memory.  IN_MODE is the mode
   of X.  */
In particular, IN_MODE is not the mode of X in this case (the reason for the
mode is only for the case of VOIDmode constants).
So, either force_const_mem should be called with lowpart_subreg of imm if
ptr_mode != int_mode, or it should be called with int_mode instead of ptr_mode
and then the later ZERO_EXTEND should not be done.
As it seems before my constant pool optimizations such bogus constant pool
entry assembled into .word the_immediate, doing a lowpart subreg is probably
the right way to go.
So perhaps:
--- gcc/config/aarch64/aarch64.c.jj 2020-08-24 10:00:01.299258763 +0200
+++ gcc/config/aarch64/aarch64.c2020-09-01 10:34:50.096468522 +0200
@@ -5131,6 +5131,7 @@ aarch64_expand_mov_immediate (rtx dest,
  return;
}

+ imm = lowpart_subreg (ptr_mode, imm, int_mode);
  mem = force_const_mem (ptr_mode, imm);
  gcc_assert (mem);

except I don't know if it will handle the (const:DI (symbol_ref:DI whatever)
(const_int 32)) case properly.
Also, few lines above this the targetm.cannot_force_const_mem call using
int_mode rather than ptr_mode when it later uses ptr_mode is kind of weird.

[Bug lto/95604] LTO doesn't pick up -fcf-protection flag for the link step

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #7 from Richard Biener  ---
What's the state of this bug?  IIRC we reverted on the branch and fixed things
up on trunk.

[Bug c++/96867] [11 Regression] ICE: tree check: expected parm_decl, have var_decl in handle_omp_array_sections_1, at cp/semantics.c:5086 since r11-2849

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/96722] [8/9/10/11 Regression] Clobbers on NULL since r8-1519

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #9)
> The path isolation bug fixed for 10.3+/11+.  Keeping open for the DCE issue.

Hmm, for easier tracking I'd use a separate bug for this.

[Bug debug/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
  Known to fail||10.2.0
  Known to work||10.2.1

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

[Bug c++/96867] [11 Regression] ICE: tree check: expected parm_decl, have var_decl in handle_omp_array_sections_1, at cp/semantics.c:5086 since r11-2849

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2962-ga37b0cccf4965f13006d2928f57a71e46e341cf8
Author: Jakub Jelinek 
Date:   Tue Sep 1 09:17:58 2020 +0200

openmp: Check for PARM_DECL before using C_ARRAY_PARAMETER or
DECL_ARRAY_PARAMETER_P [PR96867]

The C++ macro performs a PARM_DECL_CHECK, so will ICE if not tested on a
PARM_DECL,
C_ARRAY_PARAMETER doesn't, but probably should, otherwise it is testing
e.g.
C_DECL_VARIABLE_SIZE on VAR_DECLs.

2020-09-01  Jakub Jelinek  

PR c++/96867
* c-typeck.c (handle_omp_array_sections_1): Test C_ARRAY_PARAMETER
only on PARM_DECLs.

* semantics.c (handle_omp_array_sections_1): Test
DECL_ARRAY_PARAMETER_P only on PARM_DECLs.

* c-c++-common/gomp/pr96867.c: New test.

[Bug target/96879] New: [11 Regresssion] ICE in native_encode_rtx, at simplify-rtx.c:6482

[marxin at gcc dot gnu.org]

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

Bug ID: 96879
   Summary: [11 Regresssion] ICE in native_encode_rtx, at
simplify-rtx.c:6482
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: ktkachov at gcc dot gnu.org, rsandifo at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-linux-gnu

Must be a recent regression:

aarch64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/g++.old-deja/g++.other/crash11.C
-mabi=ilp32 -O1 -c
/home/marxin/Programming/gcc/gcc/testsuite/g++.old-deja/g++.other/crash11.C:21:30:
internal compiler error: in native_encode_rtx, at simplify-rtx.c:6482
   21 | template struct string ;
  |  ^
0x67af49 native_encode_rtx(machine_mode, rtx_def*, vec&, unsigned int, unsigned int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/simplify-rtx.c:6482
0xf3ecea optimize_constant_pool
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/varasm.c:4324
0xf43928 output_shared_constant_pool()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/varasm.c:4431
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/96878] New: Failed class template argument deduction in unevaluated, parenthesized context

[sbergman at redhat dot com]

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

Bug ID: 96878
   Summary: Failed class template argument deduction in
unevaluated, parenthesized context
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with recent GCC 11 trunk and with gcc-c++-10.2.1-1.fc32.x86_64:

> $ cat test.cc
> template struct S { S(char const (& s)[N]); };
> auto n = sizeof (S(""));

> $ g++ -std=c++17 -fsyntax-only test.cc
> test.cc:2:18: error: missing template arguments after ‘S<...auto...>’
> 2 | auto n = sizeof (S(""));
>   |  ^
> test.cc:1:24: note: ‘template struct S’ declared here
> 1 | template struct S { S(char const (& s)[N]); };
>   |^

If you change `sizeof (S(""))` to `sizeof S("")`, compilation succeeds.