[Bug tree-optimization/94969] [8/9/10/11 Regression] Invalid loop distribution since r8-2390-gdfbddbeb1ca912c9

[amker at gcc dot gnu.org]

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

--- Comment #8 from bin cheng  ---
Root cause is in build_classic_dist_vector -> constant_access_functions which
adds unit distance vector only in case of constant access function.  It should
cover invariant cases.  Testing a patch.  Thanks

[Bug middle-end/66364] poor optimization of packed structs containing bitfields

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
there are some other bugs open that are similar to this; I am tired though so
I'll pull their numbers back up later...

[Bug target/77273] 1 << 31 is undefined in gcc/config/i386/cpuid.h:93

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #1 from Vittorio Zecca  ---
Fixed.

[Bug tree-optimization/94086] Missed optimization when converting a bitfield to an integer on x86-64

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
Possibly related to and/or a dup of bug 83784?

[Bug debug/61900] loc_descr_plus_const sanitizer runtime error in xgcc while building libgcc_s

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #3 from Vittorio Zecca  ---
Fixed.

[Bug debug/57933] function dwf_regno accesses dbx_register_map beyond its upper limit

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #1 from Vittorio Zecca  ---
Fixed.

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

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
Created attachment 48502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48502=edit
Assembly file on x86 with -O2 -funroll-loops

So, it seems the decisions made for unrolling are bad for this case
independent of architecture - the cold loop is also unrolled 15 times
on x86_64  with -funroll-loops.  The change to POWER just happened
to expose it.

The code on x86_64 looks like

# ../../../trunk/libgfortran/generated/in_pack_i4.c:76:   destptr =
xmallocarray (ssize, sizeof (GFC_INTEGER_4));
movq%rax, 152(%rsp) # tmp309, %sfp
# ../../../trunk/libgfortran/generated/in_pack_i4.c:78:   src =
source->base_addr;
movq0(%rbp), %rax   # source_42(D)->base_addr, src
# ../../../trunk/libgfortran/generated/in_pack_i4.c:82:   while (src)
testq   %rax, %rax  # src
je  .L1 #,
# ../../../trunk/libgfortran/generated/in_pack_i4.c:91:   while (count[n]
== extent[n])
movq416(%rsp), %r15 # extent, _68
# ../../../trunk/libgfortran/generated/in_pack_i4.c:108:   src +=
stride[n];
movq552(%rsp), %rdi # stride, _92
# ../../../trunk/libgfortran/generated/in_pack_i4.c:87:   src += stride0;
leaq0(,%rsi,4), %r12#, _13
# ../../../trunk/libgfortran/generated/in_pack_i4.c:108:   src +=
stride[n];
movq560(%rsp), %r14 # stride, _24
movq568(%rsp), %r13 # stride, _112
# ../../../trunk/libgfortran/generated/in_pack_i4.c:98:   src -=
stride[n] * extent[n];
imulq   %r15, %rsi  # _68, tmp225
# ../../../trunk/libgfortran/generated/in_pack_i4.c:91:   while (count[n]
== extent[n])
movq%r15, 16(%rsp)  # _68, %sfp
movq424(%rsp), %r15 # extent, _73
movq%rdi, %r10  # _92, tmp226
movq%r14, %r9   # _24, tmp228
movq288(%rsp), %rdx # count, count_I_lsm.8
movq296(%rsp), %rcx # count, count_I_lsm.29
# ../../../trunk/libgfortran/generated/in_pack_i4.c:98:   src -=
stride[n] * extent[n];
imulq   %r15, %rdi  # _73, tmp227
# ../../../trunk/libgfortran/generated/in_pack_i4.c:91:   while (count[n]
== extent[n])
movq%r15, 32(%rsp)  # _73, %sfp
movq432(%rsp), %r15 # extent, _14
subq%rsi, %r10  # tmp225, tmp226
movq320(%rsp), %r8  # count, count_I_lsm.35
movq304(%rsp), %rsi # count, count_I_lsm.31
# ../../../trunk/libgfortran/generated/in_pack_i4.c:98:   src -=
stride[n] * extent[n];
imulq   %r15, %r14  # _14, tmp229
leaq0(,%r10,4), %r11#, _78
movq%r13, %r10  # _112, tmp230
# ../../../trunk/libgfortran/generated/in_pack_i4.c:91:   while (count[n]
== extent[n])

... and so on.

[Bug testsuite/44791] data_3.f90 accesses uninitialized variable

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #2 from Vittorio Zecca  ---
Fixed.

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

[qrzhang at gatech dot edu]

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

Bug ID: 95045
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qrzhang at gatech dot edu
  Target Milestone: ---

Recent regression. Bisection points to g:283cb9ea6293e813e4


$ gcc-trunk -v
gcc version 11.0.0 20200510 (experimental) [master revision
4ae915cdbf0:8eedda9eef3:ef6394205d7bcab00dca01182d708ad5a6360a7b] (GCC)


$ gcc-trunk abc.c ; ./a.out
4


$ gcc-trunk -O3  abc.c ; ./a.out
0


$ cat abc.c
int a, c, f;
long b;
char d;
int e[3];
int g[9][3][2];
int main() {
  {
  h:
for (f = 0; f <= 5; f++) {
  b = 3;
  for (; b >= 0; b--) {
e[2] = d = 0;
for (; d <= 3; d++) {
  g[8][2][0] = e[1] = c = 0;
  for (; c <= 1; c++)
e[c + 1] = g[d + 5][2][c] = 4;
}
if (a)
  goto h;
  }
}
  }
  printf("%d\n", e[2]);
}

[Bug tree-optimization/83403] Missed register promotion opportunities in loop

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Xiong Hu Luo :

https://gcc.gnu.org/g:0447929f11e6a3e1b076841712b90a8b6bc7d33a

commit r11-259-g0447929f11e6a3e1b076841712b90a8b6bc7d33a
Author: Xionghu Luo 
Date:   Sun May 10 21:06:20 2020 -0500

Add handling of MULT_EXPR/PLUS_EXPR for wrapping overflow in affine
combination(PR83403)

Use determine_value_range to get value range info for fold convert
expressions
with internal operation PLUS_EXPR/MINUS_EXPR/MULT_EXPR when not overflow on
wrapping overflow inner type.  i.e.:

(long unsigned int)((unsigned int)n * 10 + 1)
=>
(long unsigned int)n * (long unsigned int)10 + (long unsigned int)1

With this patch for affine combination, load/store motion could detect
more address refs independency and promote some memory expressions to
registers within loop.

PS: Replace the previous "(T1)(X + CST) as (T1)X - (T1)(-CST))"
to "(T1)(X + CST) as (T1)X + (T1)(CST))" for wrapping overflow.

Bootstrap and regression tested pass on Power8-LE.

gcc/ChangeLog

2020-05-11  Xiong Hu Luo  

PR tree-optimization/83403
* tree-affine.c (expr_to_aff_combination): Replace SSA_NAME with
determine_value_range, Add fold conversion of MULT_EXPR, fix the
previous PLUS_EXPR.

gcc/testsuite/ChangeLog

2020-05-11  Xiong Hu Luo  

PR tree-optimization/83403
* gcc.dg/tree-ssa/pr83403-1.c: New test.
* gcc.dg/tree-ssa/pr83403-2.c: New test.
* gcc.dg/tree-ssa/pr83403.h: New header.

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

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #8 from Thomas Koenig  ---
The patch which caused the problem was

commit 6d099a76a0f6a040a3e678f2bce7fc69cc3257d8
Author: Jiufu Guo 
Date:   Mon Oct 28 05:23:24 2019 +

rs6000: Enable limited unrolling at -O2

In PR88760, there are a few disscussion about improve or tune unroller for
targets. And we would agree to enable unroller for small loops at O2 first.
And we could see performance improvement(~10%) for below code:
```
  subroutine foo (i, i1, block)
integer :: i, i1
integer :: block(9, 9, 9)
block(i:9,1,i1) = block(i:9,1,i1) - 10
  end subroutine foo

```
This kind of code occurs a few times in exchange2 benchmark.

Similar C code:
```
  for (i = 0; i < n; i++)
arr[i] = arr[i] - 10;
```

On powerpcle, for O2 , enable -funroll-loops and limit
PARAM_MAX_UNROLL_TIMES=2 and PARAM_MAX_UNROLLED_INSNS=20, we can see >2%
overall improvement for SPEC2017.

This patch is only for rs6000 in which we see visible performance
improvement.

gcc/
2019-10-25  Jiufu Guo  

PR tree-optimization/88760
* config/rs6000/rs6000-common.c (rs6000_option_optimization_table):
Enable -funroll-loops for -O2 and above.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Set
PARAM_MAX_UNROLL_TIMES to 2 and PARAM_MAX_UNROLLED_INSNS to 20, and
do not turn on web and rngreg implicitly, if the unroller is not
explicitly enabled.

gcc.testsuite/
2019-10-25  Jiufu Guo  

PR tree-optimization/88760
* gcc.target/powerpc/small-loop-unroll.c: New test.
* c-c++-common/tsan/thread_leak2.c: Update test.
* gcc.dg/pr59643.c: Update test.
* gcc.target/powerpc/loop_align.c: Update test.
* gcc.target/powerpc/ppc-fma-1.c: Update test.
* gcc.target/powerpc/ppc-fma-2.c: Update test.
* gcc.target/powerpc/ppc-fma-3.c: Update test.
* gcc.target/powerpc/ppc-fma-4.c: Update test.
* gcc.target/powerpc/pr78604.c: Update test.

From-SVN: r277501

So, this patch seems to have exposed a problem with the unrolling in
general, or with the parameters for POWER.

[Bug fortran/50551] Argumentless NULL() cannot be used with assumed-length dummy (r178939)

[zeccav at gmail dot com]

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

--- Comment #2 from Vittorio Zecca  ---
Still present at 10.1.1-1

[Bug fortran/50410] [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #38 from Vittorio Zecca  ---
Fixed in 10.1.1.
Closing the issue.

[Bug fortran/33056] [Meta-bug] Data - statement related bugs

[zeccav at gmail dot com]

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

Bug 50410 Summary: [8/9/10/11 Regression] ICE in record_reference, pointer 
variable in data statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

   What|Removed |Added

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

[Bug fortran/50410] [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement

[zeccav at gmail dot com]

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

--- Comment #37 from Vittorio Zecca  ---
Fixed in 10.1.1.

[Bug target/79636] [8/9/10/11 Regression] ICE in assign_by_spills, at lra-assigns.c:1457

[zeccav at gmail dot com]

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

--- Comment #9 from Vittorio Zecca  ---
This issue has been fixed long ago.
It should be closed.

[Bug analyzer/95007] RFE: -fanalyzer should complain about writes to string literals

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=95000,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=61579
   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
You don't even need the analyzer for this; -Wwrite-strings already catches it:

$ /usr/local/bin/gcc -c -Wall -Wextra -Wwrite-strings 95007.c
95007.c: In function 'test':
95007.c:3:12: warning: initialization discards 'const' qualifier from pointer
target type [-Wdiscarded-qualifiers]
3 |  char *s = "foo";
  |^
$

If you edit the source code to make 's' const to fix the -Wdiscarded-qualifiers
warning, you then get this error instead:

$ /usr/local/bin/gcc -c -Wall -Wextra -Wwrite-strings 95007.c
95007.c: In function 'test':
95007.c:4:7: error: assignment of read-only location '*s'
4 |  s[0] = 'g';
  |   ^
$

Although, I guess it is true that there are some drawbacks to using
-Wwrite-strings, for example those described in bug 61579, so maybe having a
separate analyzer warning for this could still be useful...

[Bug libbacktrace/88745] Darwin lacks an implementation for libbacktrace

[egallager at gcc dot gnu.org]

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

--- Comment #13 from Eric Gallager  ---
(In reply to Ian Lance Taylor from comment #12)
> Fixed.

Thanks, I backported the changeset to the (old) copy of libbacktrace I keep in
my fork of gdb and it only took a few tweaks to get it to compile. Now to see
if it actually works once I update gcc...

[Bug target/81319] ICE in output_operand_lossage at final.c

[zeccav at gmail dot com]

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

--- Comment #3 from Vittorio Zecca  ---
This issue has been fixed in gcc 10.1.1-1.

[Bug target/91518] [9 Regression] segfault when run CPU2006 465.tonto since r263875

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Xiong Hu Luo
:

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

commit r9-8583-gb8da02efe62611a9f173c699a76010de5b916d33
Author: Xionghu Luo 
Date:   Sun May 10 20:27:38 2020 -0500

rs6000: Don't use HARD_FRAME_POINTER_REGNUM if it's not live in
pro_and_epilogue (PR91518)

Backport from master.

This bug is exposed by FRE refactor of r263875.  Comparing the fre
dump file shows no obvious change of the segment fault function proves
it to be a target issue.
frame_pointer_needed is set to true in reload pass setup_can_eliminate,
but regs_ever_live[31] is false, pro_and_epilogue uses it without live
check causing CPU2006 465.tonto segment fault of loading from invalid
addresses due to r31 not saved/restored.  Thus, add
HARD_FRAME_POINTER_REGNUM
live check with frame_pointer_needed_indeed when generating
pro_and_epilogue
instructions.

gcc/ChangeLog

2020-05-11  Xiong Hu Luo  

Backport from master.
2020-04-27  Xiong Hu Luo  

PR target/91518
* config/rs6000/rs6000.c (frame_pointer_needed_indeed):
New variable.
(rs6000_emit_prologue_components):
Check with frame_pointer_needed_indeed.
(rs6000_emit_epilogue_components): Likewise.
(rs6000_emit_prologue): Likewise.
(rs6000_emit_epilogue): Set frame_pointer_needed_indeed.

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

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
271r.ce2 dump has

;; bb 0 artificial_defs: { d2(0){ }d5(1){ }d8(2){ }d9(6){ }d17(7){ }d34(16){
}d44(19){ }d47(20){ }d50(21){ }d53(22){ }d66(28){ }d69(29){ }d72(30){ }}
;; bb 0 artificial_uses: { }
;; lr  in85
;; lr  use
;; lr  def   0 [ax] 1 [dx] 2 [cx] 6 [bp] 7 [sp] 16 [argp] 19 [frame] 20
[xmm0] 21 [xmm1] 22 [xmm2] 28 [mm0] 29 [mm1] 30 [mm2]
;; live  in 
;; live  gen 0 [ax] 1 [dx] 2 [cx] 6 [bp] 7 [sp] 16 [argp] 19 [frame] 20
[xmm0] 21 [xmm1] 22 [xmm2] 28 [mm0] 29 [mm1] 30 [mm2]
;; live  kill
;; lr  out   6 [bp] 7 [sp] 16 [argp] 19 [frame] 85
;; live  out 6 [bp] 7 [sp] 16 [argp] 19 [frame]
...
;; bb 2 artificial_defs: { }
;; bb 2 artificial_uses: { u0(6){ }u1(7){ }u2(16){ }u3(19){ }}
;; lr  in6 [bp] 7 [sp] 16 [argp] 19 [frame] 85
;; lr  use   6 [bp] 7 [sp] 16 [argp] 19 [frame]
;; lr  def   0 [ax] 1 [dx] 2 [cx] 7 [sp] 8 [st] 9 [st(1)] 10 [st(2)] 11
[st(3)] 12 [st(4)] 13 [st(5)] 14 [st(6)] 15 [st(7)] 17 [flags] 18 [fpsr] 20
[xmm0] 21 [xmm1] 22 [xmm2] 23 [xmm3] 24 [xmm4] 25 [xmm5] 26 [xmm6] 27 [xmm7] 28
[mm0] 29 [mm1] 30 [mm2] 31 [mm3] 32 [mm4] 33 [mm5] 34 [mm6] 35 [mm7] 36 [r8] 37
[r9] 38 [r10] 39 [r11] 40 [r12] 41 [r13] 42 [r14] 43 [r15] 44 [xmm8] 45 [xmm9]
46 [xmm10] 47 [xmm11] 48 [xmm12] 49 [xmm13] 50 [xmm14] 51 [xmm15] 52 [xmm16] 53
[xmm17] 54 [xmm18] 55 [xmm19] 56 [xmm20] 57 [xmm21] 58 [xmm22] 59 [xmm23] 60
[xmm24] 61 [xmm25] 62 [xmm26] 63 [xmm27] 64 [xmm28] 65 [xmm29] 66 [xmm30] 67
[xmm31] 68 [k0] 69 [k1] 70 [k2] 71 [k3] 72 [k4] 73 [k5] 74 [k6] 75 [k7] 88
;; live  in  6 [bp] 7 [sp] 16 [argp] 19 [frame]
;; live  gen 0 [ax] 7 [sp] 17 [flags] 88
;; live  kill17 [flags]
;; lr  out   6 [bp] 7 [sp] 16 [argp] 19 [frame] 85
;; live  out 6 [bp] 7 [sp] 16 [argp] 19 [frame]

Since IRA has

 /* DF_LIVE can't be used in the register allocator, too many other
 parts of the compiler depend on using the "classic" liveness
 interpretation of the DF_LR problem.  See PR38711.
 Remove the problem, so that we don't spend time updating it in
 any of the df_analyze() calls during IRA/LRA.  */
  if (optimize > 1) 
df_remove_problem (df_live);
  gcc_checking_assert (df_live == NULL);

setjmp_vars_warning uses DF_LR info and gets the wrong result.

Why is DF_LR info so way off? Reg 85 isn't live at function entry
nor at BB 2 exit.

[Bug c++/95036] [9/10/11 Regression] ICE with variadic type/nttp template templates

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/95036] [9/10/11 Regression] ICE with variadic type/nttp template templates

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r9-6853-g17838af989014f5e90e3a7ab4e519d495c03e726

namespace a {
template  struct c { static constexpr int d = b; };
template  using f = e;
template  struct g;
template  struct array;
} // namespace a
template  class h> struct i {
  template  class, class = void> struct n;
  template  struct n : a::c {};
  template  class k, class = a::f::d>> void function();
};
template  class... l> struct derived : i... {
  using i::function...;
};
int main() {
  derived m;
  m.function();
}

[Bug c++/95036] [9/10/11 Regression] ICE with variadic type/nttp template templates

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |9.4
   Last reconfirmed||2020-05-11
Summary|ICE with variadic type/nttp |[9/10/11 Regression] ICE
   |template templates  |with variadic type/nttp
   ||template templates
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/95022] ICE: expected integer_cst, have call_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Marek Polacek  ---
Thanks for the report.  This is actually PR94955 for which I've posted a patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545263.html

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

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||john at mcfarlane dot name

--- Comment #4 from Marek Polacek  ---
*** Bug 95022 has been marked as a duplicate of this bug. ***

[Bug c/95044] New: -Wreturn-local-addr false alarm in GCC 10.1.0 (regression)

[eggert at cs dot ucla.edu]

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

Bug ID: 95044
   Summary: -Wreturn-local-addr false alarm in GCC 10.1.0
(regression)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 48501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48501=edit
Illustrate the -Wreturn-local-addr bug.

I ran into this problem when compiling GNU Emacs master with GCC 10.1.0 x86-64,
which I built from source on RHEL 7.7.

Compile the attached program u.c with:

gcc -S -Wreturn-local-addr -O2 u.c

The output is:

u.c: In function 'careadlinkat':
cc1: warning: function may return address of local variable
[-Wreturn-local-add\
r]
u.c:7:8: note: declared here
7 |   char stack_buf[1024];
  |^


It's obviously impossible for the function to return that address. This false
alarm is not generated by GCC 9.3.0, so this is a regression.

There are really two bugs here:

1. GCC is ignoring the '#pragma GCC diagnostic ignored "-Wreturn-local-addr"'
and is outputting the diagnostic anyway.

2. GCC should not issue a diagnostic even if the pragma is absent, as it's
obviously impossible for the function to return the address of stack_buf.

Both bugs are new to GCC 10.1.0; they do not occur with GCC 9.3.0.

[Bug c++/91867] Internal compiler error in simple for(auto) loop when using -std=c++11 with -fconcepts

[me at myrrec dot space]

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

me at myrrec dot space changed:

   What|Removed |Added

 CC||me at myrrec dot space

--- Comment #3 from me at myrrec dot space ---
Also confirmed with -std=c++17 and -std=c++2a

main.cpp--
int main(){ 
  for (bool e : {true, false});
}
-

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

[noloader at gmail dot com]

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

Bug ID: 95043
   Summary: GCC 10 Analyzer and false positive on 'memcpy(dest,
src, count);'
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

Created attachment 48500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48500=edit
Preprocessed source file idea.ii

Hi Everyone,

I'm trying out the analyzer on a C++ project. I'm working on Fedora 32 with GCC
10.

  $ gcc --version
  gcc (GCC) 10.0.1 20200430 (Red Hat 10.0.1-0.14)

Here's what I am seeing:

|  527 |  if (src && dest)
|  |  ~~
|  |  |
|  |  (9) ...to here
|  |  (10) following ‘true’ branch...
|  528 |   memcpy(dest, src, count);
|  |   
|  |   | |
|  |   | (12) argument 1 (‘dest’) NULL where non-null expected

Here's the source file:
https://github.com/weidai11/cryptopp/blob/master/misc.h#L506. And the function
(with extra noise omitted):

inline void memcpy_s(void *dest, size_t sizeInBytes, const void *src, size_t
count)
{
if (count > sizeInBytes)
throw InvalidArgument("memcpy_s: buffer overflow");

if (src && dest)
memcpy(dest, src, count);
}

I have not been able to reproduce this with a reproducer. The reproducer shown
below fails to tickle the issue.

Attached is the preprocessed source file with the problem, idea.ii.tar.gz.

==

The reproducer shown below fails to reproduce the issue.

$ cat test.cxx
#include 
#include 
#include 
#include 

inline void
my_memcpy(void* dest, size_t sizeInBytes, const void* src, size_t count)
{
if (count > sizeInBytes)
throw std::runtime_error("Overflow");

if(dest && src)
memcpy(dest, src, count);
}

int main(int argc, char* argv[])
{
char buf[16];
my_memcpy(NULL, 16, argv[0], strlen(argv[0]));
return 0;
}

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

[asolokha at gmx dot com]

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

Bug ID: 95042
   Summary: ICE in can_merge_p, at analyzer/region-model.cc:2053
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.1.0-RC-20200430 ICEs when compiling the following testcase w/ -O1
-fanalyzer:

class kz {
public:
  kz ();

private:
  int yu;
};

const kz vl;
kz ax;

void
c1 (bool va, bool ze)
{
  kz ny, fb = vl;

  if (va)
{
  if (ze)
ny = vl;

  fb = ny;
}

  ax = fb;
}

% g++-10.1.0 -O1 -fanalyzer -c qjxbb0xt.cpp
during IPA pass: analyzer
qjxbb0xt.cpp: In function 'void c1(bool, bool)':
qjxbb0xt.cpp:22:10: internal compiler error: in can_merge_p, at
analyzer/region-model.cc:2053
   22 |   fb = ny;
  |   ~~~^~~~
0x7e1592 ana::map_region::can_merge_p(ana::map_region const*, ana::map_region
const*, ana::map_region*, ana::region_id, ana::model_merger*)
   
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/analyzer/region-model.cc:2053
0x13714a2 ana::map_region::can_merge_p(ana::map_region const*, ana::map_region
const*, ana::map_region*, ana::region_id, ana::model_merger*)
   
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/analyzer/region-model.cc:2085
0x1371a5f ana::stack_region::can_merge_p(ana::stack_region const*,
ana::stack_region const*, ana::model_merger*)
   
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/analyzer/region-model.cc:2904
0x1371dfc ana::stack_region::can_merge_p(ana::stack_region const*,
ana::stack_region const*, ana::model_merger*)
   
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/vec.h:1411
0x1371dfc ana::root_region::can_merge_p(ana::root_region const*,
ana::root_region const*, ana::root_region*, ana::model_merger*)
   
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/analyzer/region-model.cc:3311
0x1371f42 ana::region_model::can_merge_with_p(ana::region_model const&,
ana::region_model*, ana::svalue_id_merger_mapping*) const
   
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/analyzer/region-model.cc:6823
0x135f09e ana::program_state::can_merge_with_p(ana::program_state const&,
ana::extrinsic_state const&, ana::program_state*) const
   
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/analyzer/program-state.cc:1011
0x134d1db ana::exploded_graph::get_or_create_node(ana::program_point const&,
ana::program_state const&, ana::state_change*)
   
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/analyzer/engine.cc:1970
0x1350b42 ana::exploded_graph::process_node(ana::exploded_node*)
   
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/analyzer/engine.cc:2547
0x135131a ana::exploded_graph::process_worklist()
   
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/analyzer/engine.cc:2348
0x1351a4b ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/analyzer/engine.cc:4029
0x135261c ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/analyzer/engine.cc:4097
0x13471b8 execute
   
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/analyzer/analyzer-pass.cc:84

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

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #1 from David Binderman  ---
I see this bug also. Another C test case is available on request.

[Bug debug/95041] New: gdb does not prints variables inside an equivalence statement in a module

[fmolina2b at gmail dot com]

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

Bug ID: 95041
   Summary: gdb does not prints variables inside an equivalence
statement in a module
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fmolina2b at gmail dot com
  Target Milestone: ---

Created attachment 48499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48499=edit
Source files and temps

I found impossible to watch variables declared in equivalence statements in a
module. I could not find anything similar in bugzilla. Here follows an example
from win 10 using gcc 9.20 from equation.com, the most recent version of
gfortran that I could find (see below for linux)
***

c:\test>copy con m.f90
program m
use mod1
real*8 a
k=3.0
a=f(5d0)
print *,a,k,y(1)
read(*,*)
end program
^Z

c:\test>copy con mod1.f90
module mod1
real*8 y(10)
real*8 k
equivalence (y(1),k)
contains
real*8 function f(x)
real*8 x
y(1)=1d0
f=x**2
return
end function
end module
^Z

c:\test>gfortran -v
Built by Equation Solution .
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=c:/gcc/bin/../libexec/gcc/i686-pc-mingw32/9.2.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-9.2.0-mingw/configure --host=i686-pc-mingw32
--build=x86_64-unknown-linux-gnu --target=i686-pc-mingw32
--prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/9.2.0
--with-gcc --with-gnu-as --with-gnu-ld
--with-cloog=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/cloog
--with-gmp=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gmp
--with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr
--with-mpc=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpc
--with-diagnostics-color=auto --enable-cloog-backend=isl
--with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_32/gcc/9-20190310
--disable-shared --disable-nls --disable-tls --disable-libgcc2
--disable-win32-registry --enable-build-with-cxx --enable-libquadmath-support
--enable-libquadmath --enable-languages=c,c++,fortran --disable-checking
--enable-libgomp --enable-threads=win32 --enable-lto --enable-static
--enable-shared=lto-plugin --enable-plugins --enable-ld=yes
Thread model: win32
gcc version 9.2.0 (GCC)

c:\test>gfortran mod1.f90 m.f90 -g -save-temps

c:\test>a
   25.0001.1.  

c:\test>gdb a.exe
This binary was built by Equation Solution .
GNU gdb (GDB) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.exe...done.
(gdb) b 7
Breakpoint 1 at 0x4015e1: file m.f90, line 7.
(gdb) r
Starting program: c:\test\a.exe
[New Thread 9712.0x1318]
warning: Can not parse XML library list; XML support was disabled at compile
time
   25.0001.1.  

Breakpoint 1, m () at m.f90:7
7   read(*,*)
(gdb) p k

c:\test>
**
gdb crashes silently. The same happens trying to print y or y(1)
Commenting out the equivalence statement in mod1.f90 gdb behaves correctly
**
[snip]
Reading symbols from a.exe...done.
(gdb) b 7
Breakpoint 1 at 0x4015e1: file m.f90, line 7.
(gdb) r
Starting program: c:\test\a.exe
[New Thread 8444.0x30b4]
warning: Can not parse XML library list; XML support was disabled at compile
time
   25.0003.1.  

Breakpoint 1, m () at m.f90:7
7   read(*,*)
(gdb) p k
$1 = 3
(gdb) p y
$2 = (1, 0, 0, 0, 0, 0, 0, 0, 0, 0)
(gdb)
**
However, gdb is rather old (7.16)
Doing the same text with gcc 8.4.0 in Mageia Linux with gdb 8.2.8 I got:
***
[fer@localhost test]$ gdb a.out 
GNU gdb (GDB) 8.2-8.mga7 (Mageia release 7)
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

[Bug target/81319] ICE in output_operand_lossage at final.c

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Arseny Solokha  ---
This is a duplicate of PR92469.

[Bug fortran/95038] Not treating function result name as a variable.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||kargl at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Priority|P3  |P4
   Last reconfirmed||2020-05-10

--- Comment #2 from kargl at gcc dot gnu.org ---
This patch allows test.f90 to compile.  test1.f90 and test2.f90 compile for me.
 The question on whether IMPORT is needed or not is for someone else to ponder.

Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 280157)
+++ gcc/fortran/check.c (working copy)
@@ -3375,7 +3375,8 @@ gfc_check_kind (gfc_expr *x)
 gfc_current_intrinsic, >where);
   return false;
 }
-  if (x->ts.type == BT_PROCEDURE)
+  if (x->ts.type == BT_PROCEDURE
+  && !(x->symtree && x->symtree->n.sym->attr.function))
 {
   gfc_error ("%qs argument of %qs intrinsic at %L must be a data entity",
 gfc_current_intrinsic_arg[0]->name, gfc_current_intrinsic,
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c  (revision 280157)
+++ gcc/fortran/simplify.c  (working copy)
@@ -3969,7 +3969,11 @@ gfc_simplify_ishftc (gfc_expr *e, gfc_expr *s, gfc_exp
 gfc_expr *
 gfc_simplify_kind (gfc_expr *e)
 {
-  return gfc_get_int_expr (gfc_default_integer_kind, NULL, e->ts.kind);
+  int knd = e->ts.kind;
+  if (e->ts.type == BT_PROCEDURE
+  && e->symtree && e->symtree->n.sym->attr.function)
+knd = e->symtree->n.sym->ts.kind;
+  return gfc_get_int_expr (gfc_default_integer_kind, NULL, knd);
 }

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

[roland.illig at gmx dot de]

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

Bug ID: 95040
   Summary: typo in common.opt: manging
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

That should probably be "mangling" instead of "manging".

[Bug analyzer/95039] New: GCC 10 Analyzer and ‘‘result_decl’ not supported by dump_expr

[noloader at gmail dot com]

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

Bug ID: 95039
   Summary: GCC 10 Analyzer and ‘‘result_decl’ not supported by
dump_expr
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

Created attachment 48498
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48498=edit
Preprocessed source file ecp.ii

Hi Everyone,

I'm trying out the analyzer on a C++ project. I'm working on Fedora 32 with GCC
10.

  $ gcc --version
  gcc (GCC) 10.0.1 20200430 (Red Hat 10.0.1-0.14)

Here's what I am seeing:

‘std::_Vector_base >::_M_allocate’
   |..
   |  346 |  return __n != 0 ? _Tr::allocate(_M_impl, __n) : pointer();
   |  | ~~
   |  |  |   |
   |  |  |  
(5) ...to here
   |  |  |  
(6) ‘‘result_decl’ not supported by dump_expr’ is NULL
   |  |  (4) following ‘false’ branch (when ‘__n ==
0’)...

The odd thing (to me) is, std::allocate related functions seem to be analyzed
as returning NULL. But in C++ a failed allocation throws, it does not return
NULL.

It is fairly easy to duplicate with live code. Unfortunately, I am not sure
what is needed for a reproducer based on the error message. (I tired to
duplicate with a toy example using std::vector, but no joy). It can be
duplicated with live code using:

  $ git clone https://github.com/weidai11/cryptopp.git
  $ cd cryptopp
  $ CXXFLAGS="-DNDEBUG -g2 -O3 -fanalyzer -save-temps" make ecp.o
  ...
  

Attached is the output with a -save-temps.

This may be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034.

==

In file included from ecp.h:10,
 from ecp.cpp:7:
integer.h: In static member function ‘static void std::_Destroy_aux<
>::__destroy(_ForwardIterator, _ForwardIterator) [with _ForwardIterator =
CryptoPP::WindowSlider*; bool  = false]’:
integer.h:49:20: warning: dereference of NULL ‘__first’ [CWE-690]
[-Wanalyzer-null-dereference]
   49 | class CRYPTOPP_DLL Integer : private InitializeInteger, public
ASN1Object
  |^~~
  ‘std::vector<_Tp, _Alloc>::pointer std::vector<_Tp,
_Alloc>::_M_allocate_and_copy(std::vector<_Tp, _Alloc>::size_type,
_ForwardIterator, _ForwardIterator) [with _ForwardIterator = const
CryptoPP::WindowSlider*; _Tp = CryptoPP::WindowSlider; _Alloc =
std::allocator]’: events 1-2
|
|/usr/include/c++/10/bits/stl_vector.h:1508:2:
| 1508 |  _M_allocate_and_copy(size_type __n,
|  |  ^~~~
|  |  |
|  |  (1) entry to
‘std::vector::_M_allocate_and_copy’
|..
| 1511 |pointer __result = this->_M_allocate(__n);
|  |   ~~
|  ||
|  |(2) calling
‘std::_Vector_base >::_M_allocate’ from
‘std::vector::_M_allocate_and_copy’
|
+--> ‘std::_Vector_base<_Tp, _Alloc>::pointer std::_Vector_base<_Tp,
_Alloc>::_M_allocate(std::size_t) [with _Tp = CryptoPP::WindowSlider; _Alloc =
std::allocator]’: events 3-6
   |
   |  343 |   _M_allocate(size_t __n)
   |  |   ^~~
   |  |   |
   |  |   (3) entry to
‘std::_Vector_base >::_M_allocate’
   |..
   |  346 |  return __n != 0 ? _Tr::allocate(_M_impl, __n) : pointer();
   |  | ~~
   |  |  |   |
   |  |  |  
(5) ...to here
   |  |  |  
(6) ‘‘result_decl’ not supported by dump_expr’ is NULL
   |  |  (4) following ‘false’ branch (when ‘__n ==
0’)...
   |
<--+
|
  ‘std::vector<_Tp, _Alloc>::pointer std::vector<_Tp,
_Alloc>::_M_allocate_and_copy(std::vector<_Tp, _Alloc>::size_type,
_ForwardIterator, _ForwardIterator) [with _ForwardIterator = const
CryptoPP::WindowSlider*; _Tp = CryptoPP::WindowSlider; _Alloc =
std::allocator]’: event 7
|
| 1511 |pointer __result = this->_M_allocate(__n);
|  |   ~^
|  ||
|  |(7) return of NULL to
‘std::vector::_M_allocate_and_copy’ from ‘std::_Vector_base >::_M_allocate’
|
  ‘std::vector<_Tp, _Alloc>::pointer 

[Bug fortran/93499] ICE in gfc_zero_size_array, at fortran/arith.c:1686

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC 11.

Thanks for the report!

[Bug fortran/93499] ICE in gfc_zero_size_array, at fortran/arith.c:1686

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:92ed82367e7ccf5e031e9cb7c653c14a2d64ca89

commit r11-255-g92ed82367e7ccf5e031e9cb7c653c14a2d64ca89
Author: Harald Anlauf 
Date:   Sun May 10 19:46:06 2020 +0200

PR fortran/93499 - ICE on division by zero in declaration statements

Division by zero in declaration statements could sometimes
generate NULL pointers being passed around that lead to ICEs.

2020-05-10  Harald Anlauf  

gcc/fortran/
PR fortran/93499
* arith.c (gfc_divide): Catch division by zero.
(eval_intrinsic_f3): Safeguard for NULL operands.

gcc/testsuite/
PR fortran/93499
* gfortran.dg/pr93499.f90: New test.

[Bug fortran/95037] gfortran fails to compile a simple subroutine, issues an opaque message

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||kargl at gcc dot gnu.org
   Last reconfirmed||2020-05-10
 Status|UNCONFIRMED |NEW
   Priority|P3  |P4

--- Comment #1 from kargl at gcc dot gnu.org ---
Do not dereference a NULL pointer.  Patch against svn r280157.

Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 280157)
+++ gcc/fortran/check.c (working copy)
@@ -6600,10 +6600,10 @@ gfc_check_random_seed (gfc_expr *size, gfc_expr *put, 

   if (gfc_array_size (put, _size)
  && mpz_get_ui (put_size) < seed_size)
-   gfc_error ("Size of %qs argument of %qs intrinsic at %L "
+   gfc_error ("Size of %qs argument of %qs intrinsic at %C "
   "too small (%i/%i)",
   gfc_current_intrinsic_arg[1]->name, gfc_current_intrinsic,
-  where, (int) mpz_get_ui (put_size), seed_size);
+  (int) mpz_get_ui (put_size), seed_size);
 }

   if (get != NULL)
@@ -6632,10 +6632,10 @@ gfc_check_random_seed (gfc_expr *size, gfc_expr *put, 

if (gfc_array_size (get, _size)
   && mpz_get_ui (get_size) < seed_size)
-   gfc_error ("Size of %qs argument of %qs intrinsic at %L "
+   gfc_error ("Size of %qs argument of %qs intrinsic at %C "
   "too small (%i/%i)",
   gfc_current_intrinsic_arg[2]->name, gfc_current_intrinsic,
-  where, (int) mpz_get_ui (get_size), seed_size);
+  (int) mpz_get_ui (get_size), seed_size);
 }

   /* RANDOM_SEED may not have more than one non-optional argument.  */

[Bug fortran/95038] Not treating function result name as a variable.

[longb at cray dot com]

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

--- Comment #1 from Bill Long  ---
Note that for the greatly simplified test case

> cat test3.f90
  real(4) function x (a)
real(kind(x)) a(:)
print *, kind(x)
  end function x

gfortran compiles with no error.  So maybe the issue boils down to the
selection  of the error message in the original test case.

[Bug c++/95003] coroutines: Wrong code for some reference capture cases.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
:

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

commit r10-8127-gf09d898296c02d023ec51489fd233075ac553fd4
Author: Iain Sandoe 
Date:   Sun May 10 14:20:13 2020 +0100

coroutines: Update TREE_SIDE_EFFECTS on inserted bind exprs.

There are several places where we insert bind expressions while
making the coroutine AST transforms.  These should be marked as
having side-effects where relevant, which had been omitted.  This
leads to at least one failure in the cppcoros test suite, where a loop
body is dropped in gimplification because it is not marked.

gcc/cp/ChangeLog:

2020-05-10  Iain Sandoe  

Backported from mainline
2020-05-08  Iain Sandoe  

PR c++/95003
* coroutines.cc (build_actor_fn): Ensure that bind scopes
are marked as having side-effects where necessary.
(replace_statement_captures): Likewise.
(morph_fn_to_coro): Likewise.

gcc/testsuite/ChangeLog:

2020-05-10  Iain Sandoe  

Backported from mainline
2020-05-08  Iain Sandoe  

PR c++/95003
* g++.dg/coroutines/torture/pr95003.C: New test.

[Bug fortran/95038] New: Not treating function result name as a variable.

[longb at cray dot com]

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

Bug ID: 95038
   Summary: Not treating function result name as a variable.
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

Original test case from user:

> cat test.f90

  real(4) function x (a)

  real(kind(x)) a(:)

  interface if1

subroutine sub (a)

  real(kind(x)) a(:)

end subroutine sub

  end interface if1

  x = 0

  end function x



> cat test1.f90

function x (a) result(res)

  real(4) :: res

  real(kind(res)) a(:)

 interface if1

subroutine sub (a)

  real(kind(res)) a(:)

 end subroutine sub

  end interface if1

   res = 0

end function x


Second alternate test case:

> cat test2.f90

  real(4) function x (a)

  real(kind(x)) a(:)

  interface if1

subroutine sub (a)
  import :: x
  real(kind(x)) a(:)

end subroutine sub

  end interface if1

  x = 0

  end function x


Second alternate test case:

> cat test2.f90
  real(4) function x (a)
  real(kind(x)) a(:)
  interface if1
 subroutine sub (a)
   import :: x
  real(kind(x)) a(:)
end subroutine sub
  end interface if1
  x = 0
  end function x

The  original test.f90 and test1.f90 arguable need an IMPORT statement in the
interface.   

However:

> gfortran -c test2.f90
> gfortran -c test1.f90
> gfortran -c test.f90
test.f90:5:28:

5 |   real(kind(x)) a(:)
  |1
Error: 'x' argument of 'kind' intrinsic at (1) must be a data entity

test2 (the one with the IMPORT) compiles.  But test1, without an IMPORT, fails
to compile.  

It seems that gfortran is failing to recognize that the function name, when no
RESULT clause is specified , is the name of a local variable.

[Bug tree-optimization/94969] [8/9/10/11 Regression] Invalid loop distribution since r8-2390-gdfbddbeb1ca912c9

[amker at gcc dot gnu.org]

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

--- Comment #7 from bin cheng  ---
(In reply to Richard Biener from comment #5)
> So I think the issue is not dependence testing but loop distribution
> accepting a
> zero dependence distance as OK.  Of course dependence analysis is quite
> useless
> here since the accesses are to the same location in every iteration.
> 
> Bin, maybe you can share your thoughts on this issue?
> 
> The testcase doesn't need bitfields - those just disable the cost model
> which otherwise prevents the distribution.
> 
> diff --git a/gcc/tree-loop-distribution.c b/gcc/tree-loop-distribution.c
> index 44423215332..ac272d63c3d 100644
> --- a/gcc/tree-loop-distribution.c
> +++ b/gcc/tree-loop-distribution.c
> @@ -2852,6 +2852,7 @@ loop_distribution::finalize_partitions (class loop
> *loop,
>/* Don't distribute current loop into too many loops given we don't have
>   memory stream cost model.  Be even more conservative in case of loop
>   nest distribution.  */
> +#if 0
>if ((same_type_p && num_builtin == 0
> && (loop->inner == NULL || num_normal != 2 || num_partial_memset !=
> 1))
>|| (loop->inner != NULL
> @@ -2867,6 +2868,7 @@ loop_distribution::finalize_partitions (class loop
> *loop,
> }
>partitions->truncate (1);
>  }
> +#endif
>  
>/* Fuse memset builtins if possible.  */
>if (partitions->length () > 1)
> 
> 
> makes the testcase miscompiled even with the : 7 and : 2 commented, so plain
> 
> struct S {
>   signed m;
>   signed e;
> };

I think there is something wrong in data dependence analysis, however,
Richard's change just exposed it.  
Given below loop and data refs:

for (...) {
  array[loop_invariant] = x;  // ref1
  array[loop_invariant] ^= 1; // ref2
}
There are both output dependence for ref2(iteration i) -> ref1 (iteration i +
1), and for ref1(iteration i) -> ref2(iteration i).

It seems to me now the first one is missing.  Will dig deeper.

[Bug fortran/95037] New: gfortran fails to compile a simple subroutine, issues an opaque message

[longb at cray dot com]

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

Bug ID: 95037
   Summary: gfortran fails to compile a simple subroutine, issues
an opaque message
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

> cat  test.f90
subroutine my_random_seed_v (size, put, get)
integer, optional :: size
integer, optional :: put(1)
integer, optional :: get(1)
call random_seed (size, put, get)
end subroutine my_random_seed_v

Works with Cray compiler:

> ftn -c test.f90
> module swap PrgEnv-cray PrgEnv-gnu

Fails with gfortran:

> gfortran -c test.f90

(null):0: confused by earlier errors, bailing out
> gfortran --version
GNU Fortran (GCC) 9.3.0 20200312 (Cray Inc.)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Original user was "confused" by the message, especially since there were no
"earlier errors" output.

[Bug c++/95036] New: ICE with variadic type/nttp template templates

[vince.rev at gmail dot com]

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

Bug ID: 95036
   Summary: ICE with variadic type/nttp template templates
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vince.rev at gmail dot com
  Target Milestone: ---

Created attachment 48497
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48497=edit
ICE with variadic type/nttp template templates

The following code in std=c++17 (I couldn't make it smaller because I don't
know where the bug is coming from) compiles correctly with gcc 7 and 8, but
fails with gcc 9 and 10. Link to godbolt: https://godbolt.org/z/x_66lB


#include 
#include 
#include 

template  class Template>
struct base {
template  class, class = void>
struct is_same_template: std::false_type {};
template 
struct is_same_template: std::true_type {};
template <
template  class X,
class = std::enable_if_t::value>
>
constexpr void function() const noexcept {};
};

template  class... Templates>
struct derived: base... {
using base::function...;
};

int main(int, char**) {
derived x;
x.function();
}


The error message is :

gcc-ice-2020-05-10.cpp: In substitution of 'template > class X, class> constexpr void
base::function >() const
[with X = std::array;  = ]':
gcc-ice-2020-05-10.cpp:25:28:   required from here
gcc-ice-2020-05-10.cpp:10:12: internal compiler error: in tsubst, at
cp/pt.c:14592
   10 | struct is_same_template: std::true_type {};
  |^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

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

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Assignee|iains at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #5 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #4)
> (In reply to Rainer Orth from comment #3)
> > I'm seeing them too on both sparc-sun-solaris2.11 and i386-pc-solaris2.11.
> > 
> > My immediate suspicion would be that they are due to Nathan's patch:
> > 
> > [C++] EOF has a location
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545409.html


> > obj-c++.dg/syntax-error-10.mm:1: error: expected identifier at end of input
> > 
> > i.e. the column number got lost.

> yeah, my tests were just a few revisions before that patch - at r11-235 I
> see these on Darwin too, and it seems to be a case for fixing the tests.

hmm maybe that's a diagnostics regression with the dangling colon (without the
colon it would seem reasonable).

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

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org

--- Comment #4 from Iain Sandoe  ---
(In reply to Rainer Orth from comment #3)
> I'm seeing them too on both sparc-sun-solaris2.11 and i386-pc-solaris2.11.
> 
> My immediate suspicion would be that they are due to Nathan's patch:
> 
> [C++] EOF has a location
> https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545409.html
> 
> Two of the source files (syntax-error-[89].mm lack a newline at EOF), and in
> all
> cases the message changed from
> 
> obj-c++.dg/syntax-error-10.mm:1:1: error: expected identifier at end of input
> 
> to
> 
> obj-c++.dg/syntax-error-10.mm:1: error: expected identifier at end of input
> 
> i.e. the column number got lost.

yeah, my tests were just a few revisions before that patch - at r11-235 I see
these on Darwin too, and it seems to be a case for fixing the tests.

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

[ro at gcc dot gnu.org]

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

Bug ID: 95035
   Summary: [11 regression] gnat.dg/sso/p10.adb FAILs
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc-sun-solaris2.11
Target: sparc-sun-solaris2.11
 Build: sparc-sun-solaris2.11

Between 20200508 (a229f9b3737062c6e853879be6683f3f3e4a6661) and 20200510
(4ae915cdbf0d8aec5bf4db9a6b37306e84f99766), gnat.dg/sso/p10.adb started to FAIL
on Solaris/SPARC (both 32 and 64-bit):

+FAIL: gnat.dg/sso/p10.adb   -O0  output pattern test
+FAIL: gnat.dg/sso/p10.adb   -O1 -fno-inline  output pattern test
+FAIL: gnat.dg/sso/p10.adb   -O2  output pattern test
+FAIL: gnat.dg/sso/p10.adb   -O3 -finline-functions  output pattern test
+FAIL: gnat.dg/sso/p10.adb   -Og -g  output pattern test
+FAIL: gnat.dg/sso/p10.adb   -Os  output pattern test
+FAIL: gnat.dg/sso/q10.adb   -O0  output pattern test
+FAIL: gnat.dg/sso/q10.adb   -O1 -fno-inline  output pattern test
+FAIL: gnat.dg/sso/q10.adb   -O2  output pattern test
+FAIL: gnat.dg/sso/q10.adb   -O3 -finline-functions  output pattern test
+FAIL: gnat.dg/sso/q10.adb   -Og -g  output pattern test
+FAIL: gnat.dg/sso/q10.adb   -Os  output pattern test
+FAIL: gnat.dg/sso/t10.adb   -O0  output pattern test
+FAIL: gnat.dg/sso/t10.adb   -O1 -fno-inline  output pattern test
+FAIL: gnat.dg/sso/t10.adb   -O2  output pattern test
+FAIL: gnat.dg/sso/t10.adb   -O3 -finline-functions  output pattern test
+FAIL: gnat.dg/sso/t10.adb   -Og -g  output pattern test
+FAIL: gnat.dg/sso/t10.adb   -Os  output pattern test

Output was:
My_R1: 78 56 34 12
My_R2: 78 56 34 12
Local_R1 : 78 56 34 12
Local_R2 : 78 56 34 12
Local_R1 : 78 56 34 12
Local_R2 : 78 56 34 12
Local_R1 : 78 56 34 12
Local_R2 : 78 56 34 12

Should match:
My_R1: 78 56 34 12.*
My_R2: 12 34 56 78.*
Local_R1 : 78 56 34 12.*
Local_R2 : 12 34 56 78.*
Local_R1 : 78 56 34 12.*
Local_R2 : 12 34 56 78.*
Local_R1 : 78 56 34 12.*
Local_R2 : 12 34 56 78.*

Looks like an endianess issue.

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

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

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

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-05-10
   Target Milestone|--- |11.0
 CC||nathan at gcc dot gnu.org,
   ||ro at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
Version|10.0|11.0

--- Comment #3 from Rainer Orth  ---
I'm seeing them too on both sparc-sun-solaris2.11 and i386-pc-solaris2.11.

My immediate suspicion would be that they are due to Nathan's patch:

[C++] EOF has a location
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545409.html

Two of the source files (syntax-error-[89].mm lack a newline at EOF), and in
all
cases the message changed from

obj-c++.dg/syntax-error-10.mm:1:1: error: expected identifier at end of input

to

obj-c++.dg/syntax-error-10.mm:1: error: expected identifier at end of input

i.e. the column number got lost.

[Bug tree-optimization/95034] New: Pattern for xor not converted to xor

[gabravier at gmail dot com]

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

Bug ID: 95034
   Summary: Pattern for xor not converted to xor
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

bool combine(bool a, bool b)
{
return (a || b) && !(a && b);
}

This can be converted to `a ^ b`. LLVM does this transformation, but GCC does
not.

[Bug c++/80711] warn on non-const accessor member functions

[dcb314 at hotmail dot com]

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

--- Comment #13 from David Binderman  ---
(In reply to Jonathan Wakely from comment #12)
> Might as well just start the right version and skip that first approximation.

It sounds to me like you are somewhat keen to implement.
Feel free to go right ahead. 

I'd be glad to help with some testing of the new feature.
Do you plan a test driven development, perhaps ?

[Bug c++/80711] warn on non-const accessor member functions

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
A first approximation that is implemented in the wrong part of the compiler,
using the wrong logic, giving the wrong answers, is not a step in the right
direction because it would need to be completely redone. Might as well just
start the right version and skip that first approximation.

[Bug c++/80711] warn on non-const accessor member functions

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
I would expect no false positives for a warning like this.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
I can fix it, it comes from ASAN code which rewrites a param with a local
variable.

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

[marxin at gcc dot gnu.org]

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

Bug ID: 95033
   Summary: [11 Regression] ICE in set_parm_rtl, at
cfgexpand.c:1310 since r11-165-geb72dc663e9070b2
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
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, rguenth at gcc dot gnu.org
  Target Milestone: ---

I see the following ICE:

$ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41123.c
-fsanitize=kernel-address -O2 --param=asan-stack=1 -c
during RTL pass: expand
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41123.c: In function ‘f1’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr41123.c:9:1: internal
compiler error: in set_parm_rtl, at cfgexpand.c:1310
9 | f1 (float _Complex x)
  | ^~
0x62cffa set_parm_rtl(tree_node*, rtx_def*)
../../gcc/cfgexpand.c:1310
0xb1081f assign_parm_setup_reg
../../gcc/function.c:3377
0xb12742 assign_parms
../../gcc/function.c:3683
0xb14ca2 expand_function_start(tree_node*)
../../gcc/function.c:5126
0x99f739 execute
../../gcc/cfgexpand.c:6459

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-10
   Target Milestone|--- |11.0
 Ever confirmed|0   |1

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

[marxin at gcc dot gnu.org]

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

Bug ID: 95032
   Summary: [11 Regression] ICE in extract_insn, at recog.c:2294
since r11-187-g98329e3f5b85acc50d
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: ppc64le-linux-gnu

The following is causing trouble:

$ /dev/shm/gcc-objdir-bisect/gcc/xgcc -B/dev/shm/gcc-objdir-bisect/gcc
/home/marxin/Programming/gcc2/gcc/testsuite/gcc.dg/pr94292.c -c -mfuture
/home/marxin/Programming/gcc2/gcc/testsuite/gcc.dg/pr94292.c: In function
‘foo’:
/home/marxin/Programming/gcc2/gcc/testsuite/gcc.dg/pr94292.c:13:1: error:
unrecognizable insn:
   13 | }
  | ^
(insn 19 18 20 2 (set (reg:DI 137)
(if_then_else:DI (eq (reg:CCUNS 138)
(const_int 0 [0]))
(const_int 0 [0])
(reg:DI 139)))
"/home/marxin/Programming/gcc2/gcc/testsuite/gcc.dg/pr94292.c":11:11 -1
 (nil))
during RTL pass: vregs
/home/marxin/Programming/gcc2/gcc/testsuite/gcc.dg/pr94292.c:13:1: internal
compiler error: in extract_insn, at recog.c:2294
0x8dca29 ???
../sysdeps/x86_64/start.S:120
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ /dev/shm/gcc-objdir-bisect/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/dev/shm/gcc-objdir-bisect/gcc/xgcc
Target: ppc64le-linux-gnu
Configured with: /home/marxin/Programming/gcc2/configure
--enable-languages=c,c++,fortran --disable-bootstrap --disable-libsanitizer
--target=ppc64le-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200507 (experimental) (GCC)

[Bug libbacktrace/95012] [mingw/gcc10.1] mmapio.c:69:14: error: implicit declaration of function ‘getpagesize’

[xantares09 at hotmail dot com]

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

--- Comment #3 from xantares09 at hotmail dot com ---
mingw does not define getpagesize as far as I can tell with:
$ grep -nr getpagesize /usr/i686-w64-mingw32/include/

but gcc seems to detect it (9.x and 10.x):
checking for getpagesize... (cached) yes

maybe it relies on its own provided getpagesize function:
gcc/system.h:479:#if defined (HAVE_DECL_GETPAGESIZE) && !HAVE_DECL_GETPAGESIZE
gcc/system.h:480:extern int getpagesize (void);

[Bug c++/94569] alignas(object) with a weaker (smaller) alignment than the alignas(type) of it's type compiles, inconsistent with the C++ standard

[sinbal2l at gmail dot com]

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

--- Comment #5 from Inbal Levi  ---
Stumbled across another rule which might be relevant here is:

[basic.align/1]

[...] An object type imposes an alignment requirement on every object of that
type; stricter alignment can be requested using the alignment specifier
(9.12.2).

Inherited from the C standard, which results in an error for the following
code:

#include 
typedef struct U U;
struct U {
} __attribute__((aligned (32))); 

int main() {
_Alignas(16) U my_u; // alignas(obj) of a weaker alignment than the
type.
}

https://godbolt.org/z/tdEJgo

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

[noloader at gmail dot com]

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

Bug ID: 95031
   Summary: GCC 10 Analyzer and fatal error: Terminated signal
terminated program cc1plus
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

Created attachment 48496
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48496=edit
Preprocessed source file dll.ii

Hi Everyone,

I'm trying out the analyzer on a C++ project. I'm working on Fedora 32 with GCC
10.

  $ gcc --version
  gcc (GCC) 10.0.1 20200430 (Red Hat 10.0.1-0.14)

Here's what I am seeing:

  g++ -fPIC -pthread -pipe -DNDEBUG -g2 -O3 -fanalyzer -c dll.cpp
  g++: fatal error: Terminated signal terminated program cc1plus
  compilation terminated.
  make: *** [GNUmakefile:1693: dll.o] Error 1

It is fairly easy to duplicate with live code. Unfortunately, I am not sure
what is needed for a reproducer based on the error message. It can be
duplicated with live code using:

  $ git clone https://github.com/weidai11/cryptopp.git
  $ cd cryptopp
  $ CXXFLAGS="-DNDEBUG -g2 -O3 -fanalyzer" make dll.o
  ...
  g++: fatal error: Terminated signal terminated program cc1plus
  compilation terminated.

Attached is the output with a -save-temps. If someone would kindly provide
instructions, then I would be happy to troubleshot it further.

The file dll.cpp is a real bastard. It includes a lot of template classes. Its
sole purpose is to instantiate a bunch of template classes so the object file
has concrete objects in it. I would not be surprised if some sort of resource
exhaustion was occurring.