[Bug tree-optimization/98868] [8/9/10/11 Regression] polyhedron rnflow.f90 regression since r8-2555-g344be1fd47d7d64e

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

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

--- Comment #2 from Richard Biener  ---
First of call I can reproduce no runtime difference on a Zen2 machine.

We do get a lot better ranges after the change (that was the purpose).  For
example

-_490: [-INF, +INF]
-_491: [-INF, 2147483646]
+_490: [-INF, 512]
+_491: [-INF, 511]
...
-_63: [-INF, +INF]
-_64: [-INF, 2147483646]
+_63: [2, +INF]
+_64: [1, 2147483646]

which means we likely get more jump threading done which may result in
code layout changes.  Moving the binaries to a zen1 machine does not
reproduce the issue either.  I can't see the specified jump in the graph
either.

[Bug ada/98879] New: gcc/ada/terminals.c:732: redundantAssignment ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 98879
   Summary: gcc/ada/terminals.c:732: redundantAssignment ?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

trunk.git/gcc/ada/terminals.c:732:10: style: Variable 'cpid' is reassigned a
value before the old one has been used. [redundantAssignment]

Source code is

bRet = ReadFile(process->w_outfd, buf, 8, &count, NULL);
if (bRet == FALSE) {
  cpid = -1;
}

dwRet = buf[0] | (buf[1] << 8) | (buf[2] << 16) | (buf[3] << 24);
if (dwRet != 0) {
  cpid = -1;
}

cpid = buf[4] | (buf[5] << 8) | (buf[6] << 16) | (buf[7] << 24);
process->pid = cpid;

Why bother setting cpid if it is ignored a few lines later ?

[Bug ada/98879] gcc/ada/terminals.c:732: redundantAssignment ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||charlet at gcc dot gnu.org

--- Comment #1 from David Binderman  ---
Adding author of code.

[Bug target/92665] [AArch64] low lanes select not optimized out for vmlal intrinsics

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to work||11.0

--- Comment #8 from ktkachov at gcc dot gnu.org ---
The issue in this bug report is that the "get low lane" operation should just
be a move rather than a vec_select so that it can be optimised away.
After g:e140f5fd3e235c5a37dc99b79f37a5ad4dc59064 GCC 11 does the right thing
for all testcases in this PR

So marking this as fixed.

[Bug target/95265] aarch64: suboptimal code generation for common neon intrinsic sequence involving shrn and mull

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

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

Bug 92665 Summary: [AArch64] low lanes select not optimized out for vmlal 
intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92665

   What|Removed |Added

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

[Bug rtl-optimization/98863] WRF with LTO consumes a lot of memory in split2 pass

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

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

--- Comment #12 from Richard Biener  ---
Wow, so the MIR problem starts with

static void
df_mir_alloc (bitmap all_blocks)
{   
...
  EXECUTE_IF_SET_IN_BITMAP (all_blocks, 0, bb_index, bi)
{
...
  bitmap_set_range (&bb_info->in, 0, DF_REG_SIZE (df));
  bitmap_set_range (&bb_info->out, 0, DF_REG_SIZE (df));

I'll see if I can apply the same trick I applied to tree PRE when it
had its "maximum set".

[Bug middle-end/98209] [8/9/10/11 Regression] printf failed with O1 or above

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

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #10)
> I think the *intrin.h example is not really relevant as their direct
> caller is very unlikely to differ in setting.

In bugfree code sure.
When writing code, because there are so many ISA extensions it is often the
case one attempts to use an intrinsic that requires other ISA flags, and rely
on the compiler to diagnose that.
So, if we e.g. wanted to redeclare always_inline as being inlinable to anything
regardless of target and optimize flags, we'd need to add another attribute and
stick it on all the intrinsic that would say but for these require it.
But, even for the _FORTIFY_SOURCE inlines, I'm not really sure we e.g. want to
inline them into -O0 functions, because fortification relies on -O1+.

[Bug rtl-optimization/98863] WRF with LTO consumes a lot of memory in split2 pass

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #13 from Richard Biener  ---
Mine.

[Bug tree-optimization/98868] [8/9/10/11 Regression] polyhedron rnflow.f90 regression since r8-2555-g344be1fd47d7d64e

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

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

--- Comment #3 from Martin Liška  ---
It's likely about a small loop alignment:

# Overhead  Command  Shared Object Symbol  
#   ...    
#
78.19%  a.outa.out [.] matsim_
17.00%  a.outa.out [.] evlrnf_

matsim_ hot place (with --show-total-period)

SLOW:

 8653282 :   4017cb: imul   $0x3243f6ad,%esi,%esi
 :genuni():
 :genuni = us231 * real (jsee)
   726254541 :   4017d1: vxorps %xmm0,%xmm0,%xmm0
 :jsee = jsee * jmul + jadd
   0 :   4017d5: add$0x1b0cb175,%esi
 :genuni = us231 * real (jsee)
   105853662 :   4017db: vcvtsi2ss %esi,%xmm0,%xmm0
   273371557 :   4017df: vmulss %xmm1,%xmm0,%xmm0
 :gentrs_():
 :do icls = icls1, ncls
   454049783 :   4017e3: cmp$0x,%edi
 2165881 :   4017e6: je 401970 
   0 :   4017ec: cmp$0x1,%edi
 1081799 :   4017ef: jne4017cb 
 2155914 :   4017f1: mov%r9,%rdx
 4307088 :   4017f4: mov%r8d,%ecx
   0 :   4017f7: jmp401811 
   0 :   4017f9: nopl   0x0(%rax)
  8624612913 :   401800: inc%ecx
42153493 :   401802: add$0x400,%rdx
   484044717 :   401809: cmp$0x101,%ecx
38933067 :   40180f: je 4017cb 

FAST:

45442445 :   4017c9: imul   $0x3243f6ad,%edx,%edx
 :genuni():
 :genuni = us231 * real (jsee)
 1076892 :   4017cf: vxorps %xmm0,%xmm0,%xmm0
 :jsee = jsee * jmul + jadd
 3245642 :   4017d3: add$0x1b0cb175,%edx
 :jsee = ibits(jsee, 0, 31)   !
Replacement
 1083699 :   4017d9: and$0x7fff,%edx
 :genuni = us231 * real (jsee)
   0 :   4017df: vcvtsi2ss %edx,%xmm0,%xmm0
76652291 :   4017e3: vmulss %xmm1,%xmm0,%xmm0
 :gentrs_():
 :do icls = icls1, ncls
   166631920 :   4017e7: cmp$0x,%edi
 3251886 :   4017ea: je 401970 
   0 :   4017f0: cmp$0x1,%edi
   0 :   4017f3: jne4017c9 
   0 :   4017f5: mov%r9,%rcx
   0 :   4017f8: mov%r8d,%esi
 1083364 :   4017fb: jmp401811 
   0 :   4017fd: nopl   (%rax)
  1099920836 :   401800: inc%esi
   209587136 :   401802: add$0x400,%rcx
   100391619 :   401809: cmp$0x101,%esi
69184337 :   40180f: je 4017c9 

For some reason the hottest "inc" instruction has in fast version ~10x smaller
number of cycles.
The instruction takes 20% of cycles in the slow version.

[Bug target/98877] [AArch64] Inefficient code generated for tbl NEON intrinsics

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||ktkachov at gcc dot gnu.org,
   ||tnfchris at gcc dot gnu.org
   Last reconfirmed||2021-01-29
 Status|UNCONFIRMED |NEW

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Confirmed. I think the whole moving in and out the structure modes (OImode,
XImode and friends) really hurts codegen at the RTL level.

[Bug target/91753] Bad register allocation of multi-register types

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #8 from ktkachov at gcc dot gnu.org ---
The issue with the many moves is still there, however for GCC 11 at least
they're hoisted outside the loop

[Bug c/98880] New: [10/11 Regression] assignment unexpectedly optimized away with -O

[gcc at jochen dot sprickerhof.de via Gcc-bugs]

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

Bug ID: 98880
   Summary: [10/11 Regression] assignment unexpectedly optimized
away with -O
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at jochen dot sprickerhof.de
  Target Milestone: ---

The following code:

#include 
#include 

struct sh_lq {
  ssize_t slh_first;
};

struct sh_le {
  ssize_t sle_next;
};

static void sh_l_discard(struct sh_lq *list) {
  struct sh_le *ele;

  ele = (struct sh_le *)((char *)list + list->slh_first);
  assert(ele->sle_next == -1);
}

int main() {
  struct sh_lq list;
  struct sh_le ele;

  ele.sle_next = -1;
  list.slh_first = (ssize_t)((char *)&ele - (char *)&list);

  sh_l_discard(&list);

  return 0;
}

compiled with gcc-10 -O fails on the assert(). It works fine with gcc-9 -O and
with gcc-10 without -O.

Tested with gcc -v:
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--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-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--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=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210110 (Debian 10.2.1-6)

Also tried with godbot: https://godbolt.org/z/xrKPj8 (without the static to
make the problem more visible)

This is extracted from:
https://sources.debian.org/src/db5.3/5.3.28+dfsg1-0.6/src/dbinc/shqueue.h/

[Bug c++/98841] wrong ‘operator=’ should return a reference to ‘*this’ [-Weffc++]

[o.mandel at menlosystems dot com via Gcc-bugs]

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

--- Comment #10 from Olaf Mandel  ---
Thank you, that was quick!

Though, didn't this miss the [end of stage 3 development][1] by 11 days?

[1]: 

[Bug c/98880] [10/11 Regression] assignment unexpectedly optimized away with -O

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This is invalid code.
In both C and C++ pointer subtraction is only defined if both pointers point
into the same object (including the end of it).

[Bug tree-optimization/98868] [8/9/10/11 Regression] polyhedron rnflow.f90 regression since r8-2555-g344be1fd47d7d64e

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #4 from rguenther at suse dot de  ---
On Fri, 29 Jan 2021, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98868
> 
> --- Comment #3 from Martin Liška  ---
> It's likely about a small loop alignment:
> 
> # Overhead  Command  Shared Object Symbol 
>  
> #   ...    
> 
> #
> 78.19%  a.outa.out [.] matsim_
> 17.00%  a.outa.out [.] evlrnf_
> 
> matsim_ hot place (with --show-total-period)
> 
> SLOW:
> 
>  8653282 :   4017cb: imul   $0x3243f6ad,%esi,%esi
>  :genuni():
>  :genuni = us231 * real (jsee)
>726254541 :   4017d1: vxorps %xmm0,%xmm0,%xmm0
>  :jsee = jsee * jmul + jadd
>0 :   4017d5: add$0x1b0cb175,%esi
>  :genuni = us231 * real (jsee)
>105853662 :   4017db: vcvtsi2ss %esi,%xmm0,%xmm0
>273371557 :   4017df: vmulss %xmm1,%xmm0,%xmm0
>  :gentrs_():
>  :do icls = icls1, ncls
>454049783 :   4017e3: cmp$0x,%edi
>  2165881 :   4017e6: je 401970 
>0 :   4017ec: cmp$0x1,%edi
>  1081799 :   4017ef: jne4017cb 
>  2155914 :   4017f1: mov%r9,%rdx
>  4307088 :   4017f4: mov%r8d,%ecx
>0 :   4017f7: jmp401811 
>0 :   4017f9: nopl   0x0(%rax)
>   8624612913 :   401800: inc%ecx
> 42153493 :   401802: add$0x400,%rdx
>484044717 :   401809: cmp$0x101,%ecx
> 38933067 :   40180f: je 4017cb 
> 
> FAST:
> 
> 45442445 :   4017c9: imul   $0x3243f6ad,%edx,%edx
>  :genuni():
>  :genuni = us231 * real (jsee)
>  1076892 :   4017cf: vxorps %xmm0,%xmm0,%xmm0
>  :jsee = jsee * jmul + jadd
>  3245642 :   4017d3: add$0x1b0cb175,%edx
>  :jsee = ibits(jsee, 0, 31)   !
> Replacement
>  1083699 :   4017d9: and$0x7fff,%edx
>  :genuni = us231 * real (jsee)
>0 :   4017df: vcvtsi2ss %edx,%xmm0,%xmm0
> 76652291 :   4017e3: vmulss %xmm1,%xmm0,%xmm0
>  :gentrs_():
>  :do icls = icls1, ncls
>166631920 :   4017e7: cmp$0x,%edi
>  3251886 :   4017ea: je 401970 
>0 :   4017f0: cmp$0x1,%edi
>0 :   4017f3: jne4017c9 
>0 :   4017f5: mov%r9,%rcx
>0 :   4017f8: mov%r8d,%esi
>  1083364 :   4017fb: jmp401811 
>0 :   4017fd: nopl   (%rax)
>   1099920836 :   401800: inc%esi
>209587136 :   401802: add$0x400,%rcx
>100391619 :   401809: cmp$0x101,%esi
> 69184337 :   40180f: je 4017c9 
> 
> For some reason the hottest "inc" instruction has in fast version ~10x smaller
> number of cycles.
> The instruction takes 20% of cycles in the slow version.

So we likely enter the loop at 401800 and I see the SLOW version
is slightly smaller overall (but only 3 bytes).  So might be some
uop cache or branch predictor aliasing issue in the uarch.  For
some reason we do not align the 40180f backedge jump destination.
The extra and in the FAST case is somewhat odd, but I suppose
we avoid some overflow condition on the conversion by masking
the sign bit?  Maybe the VRP change causes us to assume overflow
doesn't happen.

[Bug tree-optimization/98868] [8/9/10/11 Regression] polyhedron rnflow.f90 regression since r8-2555-g344be1fd47d7d64e

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

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

--- Comment #5 from Martin Liška  ---
So I can manually patch the slow version by adding:

  and$0x7fff,%esi

before:

vcvtsi2ss   %esi, %xmm0, %xmm0

and the speed is back ;)

[Bug rtl-optimization/98144] REE needs 6GB DF memory when compiling insn-extract.c with RTL checking enabled

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

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

--- Comment #8 from Richard Biener  ---
So testing on recent trunk shows

> /usr/bin/time ~/install/gcc-11.0/usr/local/bin/g++ t.ii -O2 -S -o /dev/null
29.23user 1.21system 0:30.54elapsed 99%CPU (0avgtext+0avgdata
5933552maxresident)k
57448inputs+0outputs (68major+1644983minor)pagefaults 0swaps
> /usr/bin/time ~/install/gcc-11.0/usr/local/bin/g++ t.ii -O2 -S -o /dev/null 
> -fno-ree
32.17user 0.54system 0:33.12elapsed 98%CPU (0avgtext+0avgdata
1587864maxresident)k
0inputs+0outputs (0major+473366minor)pagefaults 0swaps

aka -free ups peak memory use by 4GB.  I'm testing a patch to teach it some
sanity:

> /usr/bin/time ~/install/gcc-test/usr/local/bin/g++ t.ii -O2 -S -o /dev/null   
>   
48.63user 0.36system 0:49.01elapsed 99%CPU (0avgtext+0avgdata
1707272maxresident)k
0inputs+0outputs (0major+462159minor)pagefaults 0swaps

with only a 100MB peak RSS penalty of -free.

[Bug ada/98879] gcc/ada/terminals.c:732: redundantAssignment ?

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug debug/98331] [8/9/10/11 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845 since r8-5479-g67a8d7199fe4e474

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

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

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

https://gcc.gnu.org/g:9c445c07cda60488d7a5458b070356e05e7b2e09

commit r11-6969-g9c445c07cda60488d7a5458b070356e05e7b2e09
Author: Jakub Jelinek 
Date:   Fri Jan 29 10:30:09 2021 +0100

expand: Fix up find_bb_boundaries [PR98331]

When expansion emits some control flow insns etc. inside of a former GIMPLE
basic block, find_bb_boundaries needs to split it into multiple basic
blocks.
The code needs to ignore debug insns in decisions how many splits to do or
where in between some non-debug insns the split should be done, but it can
decide where to put debug insns if they can be kept and otherwise throws
them away (they can't stay outside of basic blocks).
On the following testcase, we end up in the bb from expander with
control flow insn
debug insns
barrier
some other insn
(the some other insn is effectively dead after __builtin_unreachable and
we'll optimize that out later).
Without debug insns, we'd do the split when encountering some other insn
and split after PREV_INSN (some other insn), i.e. after barrier (and the
splitting code then moves the barrier in between basic blocks).
But if there are debug insns, we actually split before the first debug insn
that appeared after the control flow insn, so after control flow insn,
and get a basic block that starts with debug insns and then has a barrier
in the middle that nothing moves it out of the bb.  This leads to ICEs and
even if it wouldn't, different behavior from -g0.
The reason for treating debug insns that way is a different case, e.g.
control flow insn
debug insns
some other insn
or even
control flow insn
barrier
debug insns
some other insn
where splitting before the first such debug insn allows us to keep them
while otherwise we would have to drop them on the floor, and in those
situations we behave the same with -g0 and -g.

So, the following patch fixes it by resetting debug_insn not just when
splitting the blocks (it is set only after seeing a control flow insn and
before splitting for it if needed), but also when seeing a barrier,
which effectively means we always throw away debug insns after a control
flow insn and before following barrier if any, but there is no way around
that, control flow insn must be the last in the bb (BB_END) and BARRIER
after it, debug insns aren't allowed outside of bb.
We still handle the other cases fine (when there is no barrier or when
debug insns appear only after the barrier).

2021-01-29  Jakub Jelinek  

PR debug/98331
* cfgbuild.c (find_bb_boundaries): Reset debug_insn when seeing
a BARRIER.

* gcc.dg/pr98331.c: New test.

[Bug debug/98331] [8/9/10 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845 since r8-5479-g67a8d7199fe4e474

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression] ICE  |[8/9/10 Regression] ICE in
   |in haifa_luid_for_non_insn, |haifa_luid_for_non_insn, at
   |at haifa-sched.c:7845 since |haifa-sched.c:7845 since
   |r8-5479-g67a8d7199fe4e474   |r8-5479-g67a8d7199fe4e474

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/98559] test PR

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

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

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

https://gcc.gnu.org/g:0bad948a0d5c26587517d52e253ce03a1f15cb62

commit r10-5886-g0bad948a0d5c26587517d52e253ce03a1f15cb62
Author: Martin Liska 
Date:   Fri Jan 29 10:33:06 2021 +0100

Commit test case for PR 98559.

gcc/testsuite/ChangeLog:

PR fortran/98559
* gfortran.dg/elemental_assignment_1.f90: New test.

[Bug tree-optimization/98868] [8/9/10/11 Regression] polyhedron rnflow.f90 regression since r8-2555-g344be1fd47d7d64e

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

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

--- Comment #6 from Richard Biener  ---
Ah, so I have polyhedron11 and remember patching:

!CRAY - The following multiply must be done with 64 bits (not 46 bits)
!   The algoritm depends on the overflow characteristics of
!   a 32 or 64 bit multiply.
  jsee_long = jsee;
  jsee_long = jsee_long * jmul + jadd
  jsee = jsee_long;

see ~gcctest/spectests/c++bench/pb11/rnflow.patch which IIRC else caused
miscompiles at some point due to undefined overflow.  Might explain why
I can't reproduce the issue.

[Bug c/98880] [10/11 Regression] assignment unexpectedly optimized away with -O

[gcc at jochen dot sprickerhof.de via Gcc-bugs]

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

Jochen Sprickerhof  changed:

   What|Removed |Added

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

--- Comment #2 from Jochen Sprickerhof  ---
Thanks for the quick reply! Closing.

[Bug tree-optimization/98868] [8/9/10/11 Regression] polyhedron rnflow.f90 regression since r8-2555-g344be1fd47d7d64e

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from Richard Biener  ---
dup even.

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

[Bug regression/71231] [7 Regression]: 300% runtime increase for rnflow

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #20 from Richard Biener  ---
*** Bug 98868 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/98863] WRF with LTO consumes a lot of memory in split2 pass

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

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

--- Comment #14 from Richard Biener  ---
Created attachment 50079
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50079&action=edit
patch I am testing

Maybe you can produce updated mem-report with this patch?

[Bug rtl-optimization/98863] WRF with LTO consumes a lot of memory in split2 pass

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

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

--- Comment #15 from Martin Liška  ---
(In reply to Richard Biener from comment #14)
> Created attachment 50079 [details]
> patch I am testing
> 
> Maybe you can produce updated mem-report with this patch?

I'm testing the patch with my plotting script.

[Bug c++/98881] New: [modules] internal compiler error: in tpl_parms_fini, at cp/module.cc:9933

[pilarlatiesa at gmail dot com via Gcc-bugs]

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

Bug ID: 98881
   Summary: [modules] internal compiler error: in tpl_parms_fini,
at cp/module.cc:9933
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pilarlatiesa at gmail dot com
  Target Milestone: ---

$ /home/pililatiesa/GCC-11/bin/g++ -v

Using built-in specs.
COLLECT_GCC=/home/pililatiesa/GCC-11/bin/g++
COLLECT_LTO_WRAPPER=/home/pililatiesa/GCC-11/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper.exe
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-master/configure --prefix=/home/pililatiesa/GCC-11
--enable-languages=c++ --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20210129 (experimental) (GCC)


$ cat Expresion.ixx

export module Expr;

template 
class TExprSistema;

template 
class TExprBase {};

export
template typename T>
class TExprBase>
{
public:
  template typename U>
  TExprSistema, U>
  inline operator ==(TExprBase> const &rhs) const noexcept
{ return {*this, rhs}; }
};

export
template
class TExprSistema: public TExprBase>
{
private:
  TExprBase const &lhs;
  TExprBase const &rhs;

public:
  inline TExprSistema(TExprBase const &lhs_, TExprBase const &rhs_)
noexcept :
lhs(lhs_), rhs(rhs_) {}
};

$ /home/pililatiesa/GCC-11/bin/g++ -fmodules-ts -x c++ -std=c++20 Expresion.ixx
-o foo
Expresion.ixx:2:8: internal compiler error: in tpl_parms_fini, at
cp/module.cc:9933
2 | export module Expr;
  |^~

Expresion.ixx:2:8: internal compiler error: Aborted
g++: internal compiler error: Aborted signal terminated program cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug rtl-optimization/98863] WRF with LTO consumes a lot of memory in split2 pass

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

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

--- Comment #16 from Martin Liška  ---
(In reply to Martin Liška from comment #15)
> (In reply to Richard Biener from comment #14)
> > Created attachment 50079 [details]
> > patch I am testing
> > 
> > Maybe you can produce updated mem-report with this patch?
> 
> I'm testing the patch with my plotting script.

And yes, it's fixed now:
https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/cb7df4d0b7ef88dfa4ef8cdea0a82fbe6444e553/wrf-fixed.svg

Kudos!

[Bug rtl-optimization/98863] WRF with LTO consumes a lot of memory in split2 pass

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #17 from rguenther at suse dot de  ---
On Fri, 29 Jan 2021, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
> 
> --- Comment #16 from Martin Liška  ---
> (In reply to Martin Liška from comment #15)
> > (In reply to Richard Biener from comment #14)
> > > Created attachment 50079 [details]
> > > patch I am testing
> > > 
> > > Maybe you can produce updated mem-report with this patch?
> > 
> > I'm testing the patch with my plotting script.
> 
> And yes, it's fixed now:
> https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/cb7df4d0b7ef88dfa4ef8cdea0a82fbe6444e553/wrf-fixed.svg
> 
> Kudos!

Nice.  There's still short peaks, one to 11GB, would be interesting
to see what pass causes those as well (the smaller ones are likely
easier to analyze, possibly caused by the same pass).

Now waiting for the patch to be approved.

[Bug tree-optimization/98514] ICE in insert_operand_rank

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed for 10.3+ and 11+.

[Bug target/98849] [11 Regression] ICE in expand_shift_1, at expmed.c:2658 since g:7432f255b70811dafaf325d9403

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

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

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

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

commit r11-6970-ge7429bc9d60c0cb9809a8040bb63dbb9390f40f1
Author: Jakub Jelinek 
Date:   Fri Jan 29 11:54:22 2021 +0100

arm: Fix up -mcpu=iwmmxt ICEs [PR98849]

The
https://gcc.gnu.org/r11-6707-g7432f255b70811dafaf325d94036ac580891de69
https://gcc.gnu.org/r11-6708-gbfab355012ca0f5219da8beb04f2fdaf757d34b7
changes moved the vashl/vashr/vlshr expanders from neon.md to vec-common.md
and changed their condition from TARGET_NEON to ARM_HAVE__ARITH,
so that they apply also for TARGET_HAVE_MVE.  But, the
ARM_HAVE__ARITH
macros are sometimes true also for TARGET_REALLY_IWMMXT, which at least
from quick skimming of former iwmmxt*.md doesn't have such instructions,
so it seems incorrect to enable them for iwmmxt.  Furthermore, even if it
had them, iwmmxt doesn't support any way to broadcast values in those
modes (vec_duplicate and vec_init optabs) and the middle end relies on
if the vector x vector shift/rotate patterns are supported it can emit
vector x scalar shift/rotate by broadcasting the shift amount to a vector.

As the TARGET_NEON vs. TARGET_REALLY_IWMMXT vs. TARGET_HAVE_MVE never seem
to be enabled together, I think we can just write it the following way.

Note, seems iwmmxt actually does support vector x scalar shifts, but
doesn't
really enable the optabs that would tell the middle-end code that it does
(and neon and mve don't seem to support those).  I'll defer that to anybody
that cares about iwmmxt (if any).

2021-01-29  Jakub Jelinek  

PR target/98849
* config/arm/vec-common.md (mve_vshlq_,
vashl3, vashr3, vlshr3): Add
&& !TARGET_REALLY_IWMMXT to conditions.

* gcc.c-torture/compile/pr98849.c: New test.

[Bug c++/98882] New: ICE in in cpp_directive_only_process on empty translation unit

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 98882
   Summary: ICE in in cpp_directive_only_process on empty
translation unit
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

I get an internal compiler error when preprocessing with -fdirectives-only an
empty translation unit:

touch test.cxx
g++ -std=c++2a -E -fdirectives-only -o test.ii test.cxx

test.cxx:1: internal compiler error: in cpp_directive_only_process, at
libcpp/lex.c:4323
0x2c09263 cpp_directive_only_process(cpp_reader*, void*, void (*)(cpp_reader*,
CPP_DO_task, void*, ...))
../../gcc/libcpp/lex.c:4323
0xf11c8e scan_translation_unit_directives_only
../../gcc/gcc/c-family/c-ppoutput.c:402
0xf11158 preprocess_file(cpp_reader*)
../../gcc/gcc/c-family/c-ppoutput.c:100
0xf0b6e4 c_common_init()
../../gcc/gcc/c-family/c-opts.c:1188
0xbe4d7b cxx_init()
../../gcc/gcc/cp/lex.c:332
0x1805e47 lang_dependent_init
../../gcc/gcc/toplev.c:1881
0x18066f9 do_compile
../../gcc/gcc/toplev.c:2178

This is new in GCC 11.

[Bug tree-optimization/97627] [9/10/11 Regression] loop end condition missing - endless loop with -fPIC

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

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

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

https://gcc.gnu.org/g:3976b2701b826569ffcd90877d94095def507e3f

commit r10-9310-g3976b2701b826569ffcd90877d94095def507e3f
Author: Richard Biener 
Date:   Fri Jan 29 11:17:42 2021 +0100

tree-optimization/97627 - Avoid computing niters for fake edges

This avoids computing niters information for fake edges.

2021-01-29  Bin Cheng  
Richard Biener  

PR tree-optimization/97627
* tree-ssa-loop-niter.c (number_of_iterations_exit_assumptions):
Do not analyze fake edges.

* g++.dg/pr97627.C: New testcase.

[Bug rtl-optimization/98144] REE needs 6GB DF memory when compiling insn-extract.c with RTL checking enabled

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

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

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

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

commit r11-6971-ga8c455bafdefdab0a7b8cdbcdb116c0086bae05e
Author: Richard Biener 
Date:   Fri Jan 29 10:23:40 2021 +0100

rtl-optimization/98144 - tame REE memory usage

This changes the REE dataflow to change the explicit all-ones
starting solution to be implicit via a visited flag, removing
the need to initially start with fully populated bitmaps for
all basic-blocks.  That reduces peak memory use when compiling
the RTL checking enabled insn-extract.c testcase from PR98144
from 6GB to less than 2GB.

2021-01-29  Richard Biener  

PR rtl-optimization/98144
* df.h (df_mir_bb_info): Add con_visited member.
* df-problems.c (df_mir_alloc): Initialize con_visited,
do not fully populate IN and OUT.
(df_mir_reset): Likewise.
(df_mir_confluence_0): Set con_visited.
(df_mir_confluence_n): Properly handle implicitely
fully populated IN and OUT as designated by con_visited
and update con_visited accordingly.

[Bug rtl-optimization/80930] REE pass causes high memory usage via df_mir_alloc() with ASAN+UBSAN turned on

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #3 from Richard Biener  ---
duping, fixed on trunk sofar.

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

[Bug rtl-optimization/98144] REE needs 6GB DF memory when compiling insn-extract.c with RTL checking enabled

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

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

--- Comment #10 from Richard Biener  ---
*** Bug 80930 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/98863] WRF with LTO consumes a lot of memory in split2 pass

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

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

Bug 80930 Summary: REE pass causes high memory usage via df_mir_alloc() with 
ASAN+UBSAN turned on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80930

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug target/98849] [11 Regression] ICE in expand_shift_1, at expmed.c:2658 since g:7432f255b70811dafaf325d9403

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/98863] WRF with LTO consumes a lot of memory in REE pass

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|WRF with LTO consumes a lot |WRF with LTO consumes a lot
   |of memory in split2 pass|of memory in REE pass

--- Comment #18 from Richard Biener  ---
REE issue fixed on trunk, leaving open for eventual further analysis.

[Bug rtl-optimization/98144] REE needs 6GB DF memory when compiling insn-extract.c with RTL checking enabled

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||11.0

--- Comment #11 from Richard Biener  ---
Fixed on trunk, planning to do backports after a while.

[Bug rtl-optimization/80960] [8/9/10 Regression] Huge memory use when compiling a very large test case

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||11.0
Summary|[8/9/10/11 Regression] Huge |[8/9/10 Regression] Huge
   |memory use when compiling a |memory use when compiling a
   |very large test case|very large test case

--- Comment #28 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/97627] [9 Regression] loop end condition missing - endless loop with -fPIC

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|amker at gcc dot gnu.org   |rguenth at gcc dot 
gnu.org
Summary|[9/10/11 Regression] loop   |[9 Regression] loop end
   |end condition missing - |condition missing - endless
   |endless loop with -fPIC |loop with -fPIC
  Known to work||10.2.1, 11.0
 Status|NEW |ASSIGNED

--- Comment #14 from Richard Biener  ---
Mine for the last backport.

[Bug tree-optimization/97627] [9 Regression] loop end condition missing - endless loop with -fPIC

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

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

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

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

commit r11-6972-gf4e426f7bd7df279cb7aaecd91d273d9b7db338d
Author: Richard Biener 
Date:   Fri Jan 29 11:17:42 2021 +0100

tree-optimization/97627 - Avoid computing niters for fake edges

This avoids computing niters information for fake edges.

2021-01-29  Bin Cheng  
Richard Biener  

PR tree-optimization/97627
* tree-ssa-loop-niter.c (number_of_iterations_exit_assumptions):
Do not analyze fake edges.

* g++.dg/pr97627.C: New testcase.

[Bug fortran/98883] New: Module variable not initialized with -finit-real

[jellby at yahoo dot com via Gcc-bugs]

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

Bug ID: 98883
   Summary: Module variable not initialized with -finit-real
   Product: gcc
   Version: 7.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jellby at yahoo dot com
  Target Milestone: ---

I use -finit-real=nan hoping to catch some uninitialized variables, but
apparently variables in a module are not obeying this flag and are initialized
to something else (zero?):

!=
module foo
implicit none
real :: bar
end module foo

program test
use foo
implicit none
real :: w
write(6,*) w
w = bar
write(6,*) w
end program test
!=

$ gfortran -finit-real=nan a.f90 && ./a.out 
  NaN
   0.

So, the first printout shows the unitialized w, correctly set to NaN. The
second printout should be the variable in the module, which is zero for some
reason.

[Bug c++/98884] New: Implement empty struct optimisations on ARM

[david at westcontrol dot com via Gcc-bugs]

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

Bug ID: 98884
   Summary: Implement empty struct optimisations on ARM
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david at westcontrol dot com
  Target Milestone: ---

Empty "tag" structs (or classes) are useful for strong typing, function
options, and so on.  The rules of C++ require these to have a non-zero size (so
that addresses of different instances are valid and distinct), but they contain
no significant data.  Ideally, therefore, the compiler will not generate code
that sets values or copies values when passing around such types. 
Unfortunately, that is not quite the case.

Consider these two examples, with foo1 creating a tag type, and foo2 passing it
on:

struct Tag {
friend Tag make_tag();
private:
Tag() {}
};

Tag make_tag() { 
return Tag{}; 
};

void needs_tag(Tag);

void foo1(void) {
Tag t = make_tag();
needs_tag(t);
}


struct Tag1 {};
struct Tag2 {};
struct Tag3 {};
struct Tag4 {};
struct Tag5 {};

void needs_tags(int x, Tag1 t1, Tag2 t2, Tag3 t3, Tag4 t4, Tag5 t5);

void foo2(Tag1 t1, Tag2 t2, Tag3 t3, Tag4 t4, Tag5 t5)
{
needs_tags(12345, t1, t2, t3, t4, t5);
}


(Here is a godbolt link for convenience: )

On x86, since gcc 8, this has been quite efficient (this is all with -O2):

make_tag():
xor eax, eax
ret
foo1():
jmp needs_tag(Tag)
foo2(Tag1, Tag2, Tag3, Tag4, Tag5):
mov edi, 12345
jmp needs_tags(int, Tag1, Tag2, Tag3, Tag4, Tag5)

The contents of the tag instances are basically ignored.  The exception is on
"make_tag", where the return is given the value 0 unnecessarily.

But on ARM it is a different matter.  This is for the Cortex-M4:


make_tag():
mov r0, #0
bx  lr
foo1():
mov r0, #0
b   needs_tag(Tag)
foo2(Tag1, Tag2, Tag3, Tag4, Tag5):
push{lr}
sub sp, sp, #12
mov r2, #0
mov r3, r2
strbr2, [sp, #4]
strbr2, [sp]
mov r1, r2
movwr0, #12345
bl  needs_tags(int, Tag1, Tag2, Tag3, Tag4, Tag5)
add sp, sp, #12
ldr pc, [sp], #4

The needless register and stack allocations, initialisations and copying mean
that this technique has a significant overhead for something that should really
"disappear in the compilation".

The x86 port manages this well.  Is it possible to get such optimisations into
the ARM port too?


Oh, and for comparison, clang with the same options (-std=c++17 -Wall -Wextra
-O2 -mcpu=cortex-m4) gives:

make_tag():
bx  lr
foo1():
b   needs_tag(Tag)
foo2(Tag1, Tag2, Tag3, Tag4, Tag5):
movwr0, #12345
b   needs_tags(int, Tag1, Tag2, Tag3, Tag4, Tag5)

[Bug c++/98885] New: [modules] forward declaration of classes prevent them from being exported at the point of actual declaration

[pilarlatiesa at gmail dot com via Gcc-bugs]

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

Bug ID: 98885
   Summary: [modules] forward declaration of classes prevent them
from being exported at the point of actual declaration
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pilarlatiesa at gmail dot com
  Target Milestone: ---

$ /home/pililatiesa/GCC-11/bin/g++ -v

Using built-in specs.
COLLECT_GCC=/home/pililatiesa/GCC-11/bin/g++
COLLECT_LTO_WRAPPER=/home/pililatiesa/GCC-11/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-master/configure --prefix=/home/pililatiesa/GCC-11
--enable-languages=c++ --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20210129 (experimental) (GCC)


$ cat A.cpp

export module A;

class A; // forward declaration

export class A {}; // actual declaration


$ cat main.cpp

import A;

int main()
{
  A a;

  return 0;
}


$ /home/pililatiesa/GCC-11/bin/g++ -fmodules-ts A.cpp main.cpp -o foo
main.cpp: In function ‘int main()’:
main.cpp:6:3: error: ‘A’ was not declared in this scope
6 |   A a;
  |   ^


It can be worked around by typing "export" in the forward declaration as well.

Not sure this is a bug, but it that's the specified behaviour, I’d say it’s
very counter-intuitive. For example, this won’t work:

$ cat A.cpp

export module A;

class B;

export
class A
{
  void
  f(B const &) const;
};

$ cat B.cpp

export module B;

class A;

export
class B
{
  void
  f(A const &) const;
};

$ cat A-impl.cpp

module A;

import B;

void
A::f(B const &) const {}

$ cat B-impl.cpp

module B;

import A;

void
B::f(A const &) const {}

[Bug fortran/98883] Module variable not initialized with -finit-real

[dominiq at lps dot ens.fr via Gcc-bugs]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
   Last reconfirmed||2021-01-29
   Priority|P3  |P4

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

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

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

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #6 from Tobias Burnus  ---
(In reply to anlauf from comment #5)
> With r11-6917, I do not get any failures for the testcases in this PR.
[...]
> z2.f90 works with 9.3.1, 10.2.1, and master.

> Does anybody know when this was fixed?  Close the PR, add a testcase?

It fails here with gcc-9 (of Ubuntu) which was updated on 08 Aug 2020. Only
glancing at the GCC 9 log files:

I think the patch
https://gcc.gnu.org/g:9db58db5b3986531475968dd383f13a3f925d7ae for PR 96100 and
PR 96101 fixes the issue, but I did not do any regression testing.

[Bug middle-end/98753] -Wfree-nonheap-object on unreachable code with -O0

[boris at kolpackov dot net via Gcc-bugs]

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

Boris Kolpackov  changed:

   What|Removed |Added

 CC||boris at kolpackov dot net

--- Comment #11 from Boris Kolpackov  ---
I believe I am encountering a similar false positive so I will attach the test
cases to this bug (but let me know if I should instead attach them to 54202 or
create a new bug). The attached test.cxx is a cleaned-up original code while
test-simplified.cxx is its further simplified version (thanks to Matthew
Krupcale for coming up with both):

g++ -O1 -c test.cxx 

In member function ‘void small_allocator::deallocate(void*,
std::size_t) [with T = f()::expr; long unsigned int N = 1; B =
small_allocator_buffer]’,
inlined from ‘std::vector<_Tp, _Alloc>::pointer std::vector<_Tp,
_Alloc>::_M_allocate_and_copy(std::vector<_Tp, _Alloc>::size_type,
_ForwardIterator, _ForwardIterator) [with _ForwardIterator = const f()::expr*;
_Tp = f()::expr; _Alloc = small_allocator >]’ at
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/bits/alloc_traits.h:341:23,
inlined from ‘void std::vector<_Tp, _Alloc>::reserve(std::vector<_Tp,
_Alloc>::size_type) [with _Tp = f()::expr; _Alloc = small_allocator >]’ at
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/bits/vector.tcc:85:36,
inlined from ‘void small_vector::reserve(std::size_t) [with T =
f()::expr; long unsigned int N = 1]’ at test.cxx:234:26,
inlined from ‘small_vector::small_vector() [with T = f()::expr; long
unsigned int N = 1]’ at test.cxx:163:15,
inlined from ‘void f()’ at test.cxx:1472:27:
test.cxx:121:27: warning: ‘void operator delete(void*)’ called on unallocated
object ‘exprs’ [-Wfree-nonheap-object]

[Bug middle-end/98753] -Wfree-nonheap-object on unreachable code with -O0

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #12 from Boris Kolpackov  ---
Created attachment 50080
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50080&action=edit
Reproducer test.cxx

[Bug middle-end/98753] -Wfree-nonheap-object on unreachable code with -O0

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #13 from Boris Kolpackov  ---
Created attachment 50081
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50081&action=edit
Reproducer test-simplified.cxx

[Bug c++/98882] ICE in in cpp_directive_only_process on empty translation unit

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Started with r11-206-gb224c3763e018e8bdd0047b3eb283992fb655ce0

[Bug middle-end/98753] -Wfree-nonheap-object on unreachable code with -O0

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #14 from Boris Kolpackov  ---
If this cannot be fixed for 11 (and judging by the age of 54202 I feel it's not
likely), perhaps it makes sense not to enable this warning by default? Now that
C++ operator delete() is covered by this check (see bug 57111), it's reasonable
to expect more false positives like these.

[Bug rtl-optimization/98863] WRF with LTO consumes a lot of memory in REE pass

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

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

--- Comment #19 from Martin Liška  ---
The other peak at ~12 GB is in:

679s: current pass = cprop (261)
{'ltrans': {'memory': 1.6539268493652344, 'cpu': 6.24375}}
{'ltrans': {'memory': 1.6539268493652344, 'cpu': 6.24375}}
{'ltrans': {'memory': 4.188739776611328, 'cpu': 6.24375}}
{'ltrans': {'memory': 4.480541229248047, 'cpu': 6.24375}}
{'ltrans': {'memory': 4.480541229248047, 'cpu': 6.1875}}
{'ltrans': {'memory': 4.480541229248047, 'cpu': 6.30625}}
{'ltrans': {'memory': 4.480541229248047, 'cpu': 6.24375}}
{'ltrans': {'memory': 4.480541229248047, 'cpu': 6.24375}}
...
{'ltrans': {'memory': 9.175521850585938, 'cpu': 6.24375}}
{'ltrans': {'memory': 9.6334228515625, 'cpu': 6.3}}
{'ltrans': {'memory': 9.737640380859375, 'cpu': 6.2375}}

[Bug target/98884] Implement empty struct optimisations on ARM

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|c++ |target
 Target||arm

--- Comment #1 from Jonathan Wakely  ---
IIRC x86_64 had to change how empty structs are passed, to make C++ consistent
with the x86_64 psABI as used by C (and it wasn't a trivial change to get
right).

If the ARM ABI requires stack space for them then that's unavoidable, but
they're just padding bytes so leaving that stack space uninitialized should be
OK.

Reassigning to the arm target.

[Bug target/82150] Produces a branch prefetch which causes a hang

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

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

Richard Earnshaw  changed:

   What|Removed |Added

   Last reconfirmed||2021-01-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #16 from Richard Earnshaw  ---
What's the erratum number?

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

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

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #7 from Tobias Burnus  ---
(In reply to Bill Long from comment #4)
> Original submitter is looking for a fix version for this issue. Any
> predictions?

I think the problem is to understand the Fortran standard legalize.

In F2018, I see:
'An IMPORT, NONE statement in a scoping unit specifies that no entities in the
host scoping unit are accessible by host association in that scoping unit. This
is the default for an interface body for an external or dummy procedure'

This sounds as if test.f90 (rejected) and test1.f90 (accepted) should both be
rejected as there is not IMPORT.

While both variants of test2.f90, which use IMPORT, should be accepted (which
gfortran does).

 * * *

If I read the bug correctly, it is about accepting 'test.f90' (→ rejects valid)

But if I read the F2018 standard correctly, it sounds as if 'test1.f90' should
be rejected (→ accepts invalid).

Bill, can you help with the spec reading?

[Bug c++/58354] variadic template ambiguous

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.2
   Keywords||rejects-valid
 CC||jason at gcc dot gnu.org

--- Comment #3 from Jonathan Wakely  ---
Fixed by r11-1571 and r10-8343: Refinements to "more constrained".

Jason, was the change to tsubst_pack_expansion a drive-by fix that resolved
this bug?

* pt.c (tsubst_pack_expansion): Fix getting a type parameter
pack.


The rest of the commit is related to constrained functions, which aren't
relevant here.

Should we add this testcase before closing the bug?

[Bug tree-optimization/97627] [9 Regression] loop end condition missing - endless loop with -fPIC

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

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

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

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

commit r9-9211-ga7e6e7a9299208e5aa3d805d502370d59f92b8b5
Author: Richard Biener 
Date:   Fri Jan 29 11:17:42 2021 +0100

tree-optimization/97627 - Avoid computing niters for fake edges

This avoids computing niters information for fake edges.

2021-01-29  Bin Cheng  
Richard Biener  

PR tree-optimization/97627
* tree-ssa-loop-niter.c (number_of_iterations_exit_assumptions):
Do not analyze fake edges.

* g++.dg/pr97627.C: New testcase.

(cherry picked from commit 3976b2701b826569ffcd90877d94095def507e3f)

[Bug tree-optimization/97627] [9 Regression] loop end condition missing - endless loop with -fPIC

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to work||9.3.1
  Known to fail||9.3.0

--- Comment #17 from Richard Biener  ---
Fixed everywhere.

[Bug target/98884] Implement empty struct optimisations on ARM

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |11.0
   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug c++/98882] [11 Regression] ICE in in cpp_directive_only_process on empty translation unit

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

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

--- Comment #2 from Jakub Jelinek  ---
It isn't just on empty files, but on any files that don't end with newline.

I believe the
  /* Files always end in a newline.  We rely on this for
 character peeking safety.  */
  gcc_assert (buffer->rlimit[-1] == '\n');
assert is just wrong.
It isn't buffer->rlimit[-1] that should be '\n', it is actually
buffer->rlimit[0] that should be end of line terminator, buffer->rlimit[-1] is
the last character of the buffer, so whatever is in the buffer (and empty files
have buffer->cur == buffer->rlimit and thus have even nothing there at all so
rlimit[-1] access is invalid).

Another problem is though that even buffer->rlimit[0] == '\n' is not
guaranteed.

libcpp/charset.c has:

  /* If the file is using old-school Mac line endings (\r only),
 terminate with another \r, not an \n, so that we do not mistake
 the \r\n sequence for a single DOS line ending and erroneously
 issue the "No newline at end of file" diagnostic.  */
  if (to.len && to.text[to.len - 1] == '\r')
to.text[to.len] = '\r';
  else
to.text[to.len] = '\n';

So, I think we can assert that buffer->rlimit[0] == '\n' || buffer->rlimit[0]
== '\r' and in the
case '\r': /* MAC line ending, or Windows \r\n  */
  if (*pos == '\n')
pos++;
  /* FALLTHROUGH */
and
  else if (*pos == '\r')
{
  if (pos[1] == '\n')
pos++;
  pos++;
  goto next_line;
}
  goto dflt;
and
  case '\r':
if (*pos == '\n')
  pos++;
(twice) cases unfortunately need to compare pos against limit.

[Bug demangler/98886] New: stack overflow in cxxfilt, demangle_type, rust-demangle.c:854

[featherrain26 at gmail dot com via Gcc-bugs]

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

Bug ID: 98886
   Summary: stack overflow in cxxfilt, demangle_type,
rust-demangle.c:854
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: featherrain26 at gmail dot com
  Target Milestone: ---

Created attachment 50082
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50082&action=edit
POC

Hi, there.

There is a stack overflow in the newest version(2eda57ef) of cxxfilt,
rust-demangle.c:854 related to path demangling, which directly causes a
segmentation fault.

To reproduce, run
cxxfilt < poc

Here is the trace reported by ASAN:
==61128==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc223e6fa8 (pc
0x00970f57 bp 0x0005 sp 0x7ffc223e6f80 T0)
 #0 0x970f56 in demangle_type ../../libiberty/rust-demangle.c:854
 #1 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #2 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #3 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #4 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #5 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #6 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #7 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #8 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #9 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #10 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #11 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #12 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #13 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #14 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #15 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #16 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #17 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #18 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #19 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #20 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #21 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #22 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #23 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #24 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #25 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #26 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #27 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #28 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #29 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #30 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #31 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #32 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #33 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #34 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #35 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #36 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #37 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #38 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #39 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #40 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #41 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #42 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #43 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #44 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #45 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #46 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #47 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #48 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #49 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #50 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #51 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #52 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #53 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #54 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #55 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
 #56 0x971873 in demangle_ty

[Bug c/98887] New: stack overflow in cxxfilt, str_buf_append, rust-demangle.c:1490

[featherrain26 at gmail dot com via Gcc-bugs]

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

Bug ID: 98887
   Summary: stack overflow in cxxfilt, str_buf_append,
rust-demangle.c:1490
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: featherrain26 at gmail dot com
  Target Milestone: ---

Created attachment 50083
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50083&action=edit
POC

Hi, there.

There is a stack overflow in the newest version(2eda57ef) of cxxfilt,
rust-demangle.c:671 related to path demangling, which directly causes a
segmentation fault.

To reproduce, run
cxxfilt < poc

Here is the trace reported by ASAN:
==7714==ERROR: AddressSanitizer: stack-overflow on address 0x7ffe0bb3fcb8 (pc
0x7f67c626a62f bp 0x7ffe0bb40530 sp 0x7ffe0bb3fcc0 T0)
#0 0x7f67c626a62e in __asan_memcpy
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x8c62e)
#1 0x96a295 in memcpy /usr/include/x86_64-linux-gnu/bits/string3.h:53
#2 0x96a295 in str_buf_append ../../libiberty/rust-demangle.c:1490
#3 0x96a295 in str_buf_demangle_callback
../../libiberty/rust-demangle.c:1497
#4 0x977cc9 in print_str ../../libiberty/rust-demangle.c:273
#5 0x977cc9 in demangle_path ../../libiberty/rust-demangle.c:746
#6 0x971699 in demangle_type ../../libiberty/rust-demangle.c:1031
#7 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
#8 0x97709c in demangle_path ../../libiberty/rust-demangle.c:747
#9 0x971699 in demangle_type ../../libiberty/rust-demangle.c:1031
#10 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
#11 0x97709c in demangle_path ../../libiberty/rust-demangle.c:747
#12 0x971699 in demangle_type ../../libiberty/rust-demangle.c:1031
#13 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
#14 0x97709c in demangle_path ../../libiberty/rust-demangle.c:747
#15 0x971699 in demangle_type ../../libiberty/rust-demangle.c:1031
#16 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
#17 0x97709c in demangle_path ../../libiberty/rust-demangle.c:747
#18 0x971699 in demangle_type ../../libiberty/rust-demangle.c:1031
#19 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
#20 0x97709c in demangle_path ../../libiberty/rust-demangle.c:747
#21 0x971699 in demangle_type ../../libiberty/rust-demangle.c:1031
#22 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
#23 0x97709c in demangle_path ../../libiberty/rust-demangle.c:747
#24 0x971699 in demangle_type ../../libiberty/rust-demangle.c:1031
#25 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
#26 0x97709c in demangle_path ../../libiberty/rust-demangle.c:747
#27 0x971699 in demangle_type ../../libiberty/rust-demangle.c:1031
#28 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
#29 0x97709c in demangle_path ../../libiberty/rust-demangle.c:747
#30 0x971699 in demangle_type ../../libiberty/rust-demangle.c:1031
#31 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
#32 0x97709c in demangle_path ../../libiberty/rust-demangle.c:747
#33 0x971699 in demangle_type ../../libiberty/rust-demangle.c:1031
#34 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
#35 0x97709c in demangle_path ../../libiberty/rust-demangle.c:747
#36 0x971699 in demangle_type ../../libiberty/rust-demangle.c:1031
#37 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
#38 0x97709c in demangle_path ../../libiberty/rust-demangle.c:747
#39 0x971699 in demangle_type ../../libiberty/rust-demangle.c:1031
#40 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
#41 0x97709c in demangle_path ../../libiberty/rust-demangle.c:747
#42 0x971699 in demangle_type ../../libiberty/rust-demangle.c:1031
#43 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
#44 0x97709c in demangle_path ../../libiberty/rust-demangle.c:747
#45 0x971699 in demangle_type ../../libiberty/rust-demangle.c:1031
#46 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
#47 0x97709c in demangle_path ../../libiberty/rust-demangle.c:747
#48 0x971699 in demangle_type ../../libiberty/rust-demangle.c:1031
#49 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
#50 0x97709c in demangle_path ../../libiberty/rust-demangle.c:747
#51 0x971699 in demangle_type ../../libiberty/rust-demangle.c:1031
#52 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
#53 0x97709c in demangle_path ../../libiberty/rust-demangle.c:747
#54 0x971699 in demangle_type ../../libiberty/rust-demangle.c:1031
#55 0x971873 in demangle_type ../../libiberty/rust-demangle.c:1024
#56 0x97709c in demangle_path ../../libiberty/rust-demangle.c:747
#57 0x9

[Bug c/98888] New: stack overflow in cxxfilt, demangle_path, rust-demangle.c:674

[featherrain26 at gmail dot com via Gcc-bugs]

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

Bug ID: 9
   Summary: stack overflow in cxxfilt, demangle_path,
rust-demangle.c:674
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: featherrain26 at gmail dot com
  Target Milestone: ---

Created attachment 50084
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50084&action=edit
POC

Hi, there.

There is a stack overflow in the newest version(2eda57ef) of cxxfilt,
rust-demangle.c:671 related to path demangling, which directly causes a
segmentation fault.

To reproduce, run
cxxfilt < poc

Here is the trace reported by ASAN:
==77000==ERROR: AddressSanitizer: stack-overflow on address 0x7ffcbc105fd0 (pc
0x009767ed bp 0x7ffcbc903130 sp 0x7ffcbc105f90 T0)
#0 0x9767ec in demangle_path ../../libiberty/rust-demangle.c:671
#1 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#2 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#3 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#4 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#5 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#6 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#7 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#8 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#9 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#10 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#11 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#12 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#13 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#14 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#15 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#16 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#17 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#18 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#19 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#20 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#21 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#22 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#23 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#24 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#25 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#26 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#27 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#28 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#29 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#30 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#31 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#32 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#33 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#34 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#35 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#36 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#37 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#38 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#39 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#40 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#41 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#42 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#43 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#44 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#45 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#46 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#47 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#48 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#49 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#50 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#51 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#52 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#53 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#54 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#55 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#56 0x977862 in demangle_path ../../libiberty/rust-demangle.c:774
#57 0x977202 in demangle_path ../../libiberty/rust-demangle.c:756
#58 0x9

[Bug demangler/98889] New: stack overflow in cxxfilt, peek, rust-demangle.c:85

[featherrain26 at gmail dot com via Gcc-bugs]

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

Bug ID: 98889
   Summary: stack overflow in cxxfilt, peek, rust-demangle.c:85
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: featherrain26 at gmail dot com
  Target Milestone: ---

Created attachment 50085
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50085&action=edit
POC

Hi, there.

There is a stack overflow in the newest version(2eda57ef) of cxxfilt,
rust-demangle.c:85 related to path demangling, which directly causes a
segmentation fault.

To reproduce, run
cxxfilt < poc

Here is the trace reported by ASAN:
ASAN:SIGSEGV
=
==52498==ERROR: AddressSanitizer: stack-overflow on address 0x7ffeeb551ff8 (pc
0x009768c0 bp 0x7ffeebd4f8b0 sp 0x7ffeeb551ff8 T0)
#0 0x9768bf in peek ../../libiberty/rust-demangle.c:85
#1 0x9768bf in next ../../libiberty/rust-demangle.c:105
#2 0x9768bf in demangle_path ../../libiberty/rust-demangle.c:674

SUMMARY: AddressSanitizer: stack-overflow ../../libiberty/rust-demangle.c:85
peek
==52498==ABORTING

[Bug c/91128] Incomplete fix of heap overflow in cp-demangle.c

[featherrain26 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Shadow HUANG  ---
I just download the binutils from the website and use the compilation procedure
mentioned to create the binary.

[Bug tree-optimization/98855] [11 Regression] botan XTEA is 100% slower on znver2 since r11-4428-g4a369d199bf2f34e

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-01-29

--- Comment #3 from Martin Liška  ---
So it's still there after the fix for PR98845.

I briefly looked at src/lib/block/xtea/xtea.cpp:

one can isolate the one problematic SLP:
-fdbg-cnt=vect_slp:4-4

build/include/botan/loadstor.h:470:15: note: Basic block will be vectorized
using SLP
build/include/botan/loadstor.h:470:15: note: Vectorizing SLP tree:
build/include/botan/loadstor.h:470:15: note: node 0x2cabac0 (max_nunits=4,
refcnt=1)
build/include/botan/loadstor.h:470:15: note: op template: MEM 
[(char * {ref-all})_66] = _133;
build/include/botan/loadstor.h:470:15: note:stmt 0 MEM 
[(char * {ref-all})_66] = _133;
build/include/botan/loadstor.h:470:15: note:stmt 1 MEM 
[(char * {ref-all})_66 + 4B] = _134;
build/include/botan/loadstor.h:470:15: note:stmt 2 MEM 
[(char * {ref-all})_66 + 8B] = _135;
build/include/botan/loadstor.h:470:15: note:stmt 3 MEM 
[(char * {ref-all})_66 + 12B] = _136;
build/include/botan/loadstor.h:470:15: note:stmt 4 MEM 
[(char * {ref-all})_66 + 16B] = _137;
build/include/botan/loadstor.h:470:15: note:stmt 5 MEM 
[(char * {ref-all})_66 + 20B] = _138;
build/include/botan/loadstor.h:470:15: note:stmt 6 MEM 
[(char * {ref-all})_66 + 24B] = _139;
build/include/botan/loadstor.h:470:15: note:stmt 7 MEM 
[(char * {ref-all})_66 + 28B] = _140;
build/include/botan/loadstor.h:470:15: note:children 0x2cabb40
build/include/botan/loadstor.h:470:15: note: node 0x2cabb40 (max_nunits=4,
refcnt=1)
build/include/botan/loadstor.h:470:15: note: op template: _133 =
__builtin_bswap32 (_92);
build/include/botan/loadstor.h:470:15: note:stmt 0 _133 = __builtin_bswap32
(_92);
build/include/botan/loadstor.h:470:15: note:stmt 1 _134 = __builtin_bswap32
(_592);
build/include/botan/loadstor.h:470:15: note:stmt 2 _135 = __builtin_bswap32
(_90);
build/include/botan/loadstor.h:470:15: note:stmt 3 _136 = __builtin_bswap32
(_591);
build/include/botan/loadstor.h:470:15: note:stmt 4 _137 = __builtin_bswap32
(_594);
build/include/botan/loadstor.h:470:15: note:stmt 5 _138 = __builtin_bswap32
(_590);
build/include/botan/loadstor.h:470:15: note:stmt 6 _139 = __builtin_bswap32
(_593);
build/include/botan/loadstor.h:470:15: note:stmt 7 _140 = __builtin_bswap32
(_589);
build/include/botan/loadstor.h:470:15: note:children 0x2cabbc0
build/include/botan/loadstor.h:470:15: note: node 0x2cabbc0 (max_nunits=4,
refcnt=1)
build/include/botan/loadstor.h:470:15: note: op template: _92 = PHI <_14(17)>
build/include/botan/loadstor.h:470:15: note:stmt 0 _92 = PHI <_14(17)>
build/include/botan/loadstor.h:470:15: note:stmt 1 _592 = PHI <_46(17)>
build/include/botan/loadstor.h:470:15: note:stmt 2 _90 = PHI <_23(17)>
build/include/botan/loadstor.h:470:15: note:stmt 3 _591 = PHI <_52(17)>
build/include/botan/loadstor.h:470:15: note:stmt 4 _594 = PHI <_31(17)>
build/include/botan/loadstor.h:470:15: note:stmt 5 _590 = PHI <_58(17)>
build/include/botan/loadstor.h:470:15: note:stmt 6 _593 = PHI <_37(17)>
build/include/botan/loadstor.h:470:15: note:stmt 7 _589 = PHI <_64(17)>
build/include/botan/loadstor.h:470:15: note:children 0x2cabc40
build/include/botan/loadstor.h:470:15: note: node 0x2cabc40 (max_nunits=4,
refcnt=2)
build/include/botan/loadstor.h:470:15: note: op template: _14 = _13 + L0_224;
build/include/botan/loadstor.h:470:15: note:stmt 0 _14 = _13 + L0_224;
build/include/botan/loadstor.h:470:15: note:stmt 1 _46 = _45 + R0_225;
build/include/botan/loadstor.h:470:15: note:stmt 2 _23 = _22 + L1_226;
build/include/botan/loadstor.h:470:15: note:stmt 3 _52 = _51 + R1_227;
build/include/botan/loadstor.h:470:15: note:stmt 4 _31 = _30 + L2_228;
build/include/botan/loadstor.h:470:15: note:stmt 5 _58 = _57 + R2_229;
build/include/botan/loadstor.h:470:15: note:stmt 6 _37 = _36 + L3_230;
build/include/botan/loadstor.h:470:15: note:stmt 7 _64 = _63 + R3_231;
build/include/botan/loadstor.h:470:15: note:children 0x2cabcc0 0x2cabdc0
build/include/botan/loadstor.h:470:15: note: node 0x2cabcc0 (max_nunits=4,
refcnt=1)
build/include/botan/loadstor.h:470:15: note: op template: _13 = _9 ^ _12;
build/include/botan/loadstor.h:470:15: note:stmt 0 _13 = _9 ^ _12;
build/include/botan/loadstor.h:470:15: note:stmt 1 _45 = _41 ^ _44;
build/include/botan/loadstor.h:470:15: note:stmt 2 _22 = _12 ^ _18;
build/include/botan/loadstor.h:470:15: note:stmt 3 _51 = _44 ^ _50;
build/include/botan/loadstor.h:470:15: note:stmt 4 _30 = _12 ^ _27;
build/include/botan/loadstor.h:470:15: note:stmt 5 _57 = _44 ^ _56;
build/include/botan/loadstor.h:470:15: 

[Bug rtl-optimization/98863] WRF with LTO consumes a lot of memory in REE pass

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

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

--- Comment #20 from Richard Biener  ---
OK, so that's guarded with gcse_or_cprop_is_too_expensive which doesn't trigger
but I see it allocating

  alloc_cprop_mem (last_basic_block_for_fn (cfun),
   set_hash_table.n_elems);

which does 4 times sbitmap_vector_alloc (n_blocks, n_sets) which consumes
n_blocks * n_sets / 2 bytes of memory.  gcse_or_cprop_is_too_expensive
uses n_basic_blocks_for_fn but stores the result in an int which quite
likely overflows here, defeating the limitation (eh).  Will fix / test.

[Bug c++/98881] [modules] internal compiler error: in tpl_parms_fini, at cp/module.cc:9933

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

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

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #21 from Tobias Burnus  ---
(In reply to Bill Long from comment #19)
> On an ia64 Intel target that does not support x87 floating point, it seems
> that having IEEE_SUPPORT_DATATYPE (1._10)  return .true. is as error.  If
> that is fixed, will the rest of the issue fall into place?

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgfortran/ieee/ieee_arithmetic.F90#l1353
has:

#ifdef HAVE_GFC_REAL_10
SUPPORTMACRO(IEEE_SUPPORT_DATATYPE,10,.true.)
#endif

This could be unconditionally set to .false. The question is whether that makes
sense or not – or rather what condition needs to be fulfilled to have it set to
true or false.

(Likewise for all ieee_* functions, handled either in the library file or in
the compiler itself, like simplify_ieee_selected_real_kind.)

 * * *

Regarding REAL KIND=10, we have
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/fortran/trans-types.c#l463

  /* Let the kind equal the precision divided by 8, rounding up.  Again,
 this insulates the programmer from the underlying byte size.

 Also, it effectively deals with IEEE extended formats.  There, the
 total size of the type may equal 16, but it's got 6 bytes of padding
 and the increased size can get in the way of a real IEEE quad format
 which may also be supported by the target.

 We round up so as to handle IA-64 __floatreg (RFmode), which is an
 82 bit type.  Not to be confused with __float80 (XFmode), which is
 an 80 bit type also supported by IA-64.  So XFmode should come out
 to be kind=10, and RFmode should come out to be kind=11.  Egads.  */

  kind = (GET_MODE_PRECISION (mode) + 7) / 8;

[Bug c++/19377] Using declaration in "private" part causes "protected" diagnostic

[anthonysharp15 at gmail dot com via Gcc-bugs]

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

Anthony Sharp  changed:

   What|Removed |Added

 CC||anthonysharp15 at gmail dot com

--- Comment #14 from Anthony Sharp  ---
I believe I accidentally fixed this in my recent PR17314 patch. These testcases
now correctly say "private" instead of protected/inaccessible etc. 

However, I had not anticipated the use of the "using" keyword whilst making
that patch, which means that the place where the error diagnostic points to in
terms of where it was declared private is slightly inaccurate. I will start
working on a patch for this.

[Bug target/82150] Produces a branch prefetch which causes a hang

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

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #17 from Richard Earnshaw  ---
OK, I've found the erratum number, it's 720247; but it's specific to the
11MPcore and is fixed in r2p1 silicon.

The erratum workaround description states that there is *no* robust software
fix when the MMU is disabled.  Some hardware fixes on your platform might be
possible, but are off-topic here.  Also, using r2p1 silicon fixes the problem.

Either way, there's nothing we can do in GCC to address this, given the nature
of the problem.

[Bug target/98884] Implement empty struct optimisations on ARM

[david at westcontrol dot com via Gcc-bugs]

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

--- Comment #2 from David Brown  ---
Yes, ABI issues were my initial thought too.  If so, then optimising away the
assignments while leaving the stack manipulation (and possibly register
allocations) in place would still be a significant improvement.

However, I note that clang has no problem with generating ideal code here for
the ARM - it is not bothered by the ABI.  There could be several reasons for
that.  Perhaps the clang folk got the ABI wrong and the optimisation is not
valid for the ARM EABI.  Maybe the EABI used on the "arm (none)" target doesn't
specify these details, meaning the optimisation is valid there even if it is
not valid on "arm (linux)" targets.  I don't know the details of the ABIs well
enough to answer.

If it is an ABI issue, then I'd be quite happy with an ARM-specific flag to
enable an variation on the ABI that lets the compiler skip empty types
entirely.  When compiling for the Cortex-M devices, you rarely link much to
pre-compiled code (other than the C library) and it's usually fine to break
standards a bit to get more optimal code (like using "-ffast-math").

It would of course be best to have a general solution that works for all ARM
users (and ideally other targets too) without needing a flag.

[Bug preprocessor/98882] [11 Regression] ICE in in cpp_directive_only_process on empty translation unit

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Actually, I think it is only the assert that is problematic.
If the code isn't upset of pos in certain cases being bumped to buffer->rlimit
+ 1 (which can happen even with the \n termination of buffers, e.g. if file
ends up with backslash), then the \r handling cases are all but one about the
\r
being still before the limit and so either rlimit[0] will be '\n' and we can
safely read it, or it will be '\r' and again we can read it (it just won't be
'\n').  The harder case is backslash, after which we check for newline (ok) or
cr or cr + newline.  But, if rlimit > cur && rlimit[-1] == '\\', then rlimit[0]
must be '\n' not '\r' (as '\r' is only added if rlimit[-1] == '\r'), so we
never access rlimit[1].

[Bug c++/17314] Error message wrongly shows declared rather than inherited access

[anthonysharp15 at gmail dot com via Gcc-bugs]

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

--- Comment #26 from Anthony Sharp  ---
Fixed. It seems the issue to do with the virtual class constructors is a
duplicate of 55120 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55120).

[Bug target/98884] Implement empty struct optimisations on ARM

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||ktkachov at gcc dot gnu.org,
   ||rearnsha at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
If GCC and Clang are ABI incompatible on this, then one of the two compilers is
buggy.  So, it is needed to look at the EABI and find out which case it is.

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

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

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

Paul Thomas  changed:

   What|Removed |Added

 Status|WAITING |REOPENED
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #7 from Paul Thomas  ---
(In reply to Tobias Burnus from comment #6)
> (In reply to anlauf from comment #5)
> > With r11-6917, I do not get any failures for the testcases in this PR.
> [...]
> > z2.f90 works with 9.3.1, 10.2.1, and master.
> 
> > Does anybody know when this was fixed?  Close the PR, add a testcase?
> 
> It fails here with gcc-9 (of Ubuntu) which was updated on 08 Aug 2020. Only
> glancing at the GCC 9 log files:
> 
> I think the patch
> https://gcc.gnu.org/g:9db58db5b3986531475968dd383f13a3f925d7ae for PR 96100
> and PR 96101 fixes the issue, but I did not do any regression testing.

The patch for PRs 96100/101 was backported to 9-branch on 28th December.

Both testcases run fine with 9-branch now. They even give the intended result
:-)

Before closing, I will add a testcase to master. I have taken the PR and
reopened it.

Cheers

Paul

[Bug c++/55120] Inaccessible virtual base constructor does not prevent generation of default constructor

[anthonysharp15 at gmail dot com via Gcc-bugs]

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

Anthony Sharp  changed:

   What|Removed |Added

 CC||anthonysharp15 at gmail dot com

--- Comment #8 from Anthony Sharp  ---
This issue was mentioned in pr17314 and Jason got verification from the C++
standards committee that it was expected behaviour that inaccessible virtual
constructors (or whatever one calls it - I'm not too clued up on the lingo)
should not work (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314).

As Jason says, a class with a virtual private base can't be derived from
(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#7).

In fact, it seems that it is even the case that a public virtual base can't be
derived from (see pr17314 discussion - especially comment 17).

The latest version of the Visual Studio compiler gives the following warnings
when you attempt to derive from a private OR a public virtual base:

warning C4594: class 'cclass' can never be instantiated - indirect virtual base
class 'aclass' is inaccessible
message : 'aclass' is a private base class of 'bclass'
warning C4624: 'cclass': destructor was implicitly defined as deleted

GCC should generate a warning for this.

[Bug target/98884] Implement empty struct optimisations on ARM

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

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

--- Comment #4 from Jakub Jelinek  ---
Note, for ABI compatibility or incompatibility it might be better to check what
happens when some argument is passed after the empty structs.  Because at least
in some ABIs one could get away with just pretending the stack slots (or
registers) are there even when they aren't actually allocated on the stack, but
one would need to have guarantees the callee e.g. will never modify those stack
slots (in most ABIs the call argument stack slot are owned by the callee).

[Bug rtl-optimization/98863] WRF with LTO consumes a lot of memory in REE, CPROP, PRE and LRA passes

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|missed-optimization |memory-hog, ra
Summary|WRF with LTO consumes a lot |WRF with LTO consumes a lot
   |of memory in REE pass   |of memory in REE, CPROP,
   ||PRE and LRA passes

--- Comment #21 from Richard Biener  ---
With that fixed ltrans34 runs into a 7GB peak in LRA.  It does use lra_simple_p
but that alone doesn't help.

[Bug rtl-optimization/98863] WRF with LTO consumes a lot of memory in REE, CPROP, PRE and LRA passes

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

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

--- Comment #22 from Martin Liška  ---
There are other smaller spikes I can see:

663s: current pass = cse1 (259)
{'ltrans': {'memory': 1.5744667053222656, 'cpu': 6.24375}}
{'ltrans': {'memory': 1.5744667053222656, 'cpu': 6.24375}}
{'ltrans': {'memory': 2.4257125854492188, 'cpu': 6.30625}}
{'ltrans': {'memory': 3.3943252563476562, 'cpu': 6.24375}}
{'ltrans': {'memory': 4.317256927490234, 'cpu': 6.24375}}
{'ltrans': {'memory': 5.229209899902344, 'cpu': 6.24375}}
{'ltrans': {'memory': 6.062725067138672, 'cpu': 6.24375}}
{'ltrans': {'memory': 6.596076965332031, 'cpu': 6.24375}}
{'ltrans': {'memory': 6.596076965332031, 'cpu': 6.24375}}
{'ltrans': {'memory': 6.596076965332031, 'cpu': 6.30625}}
...
1020s: current pass = cprop (277)
{'ltrans': {'memory': 1.7144355773925781, 'cpu': 6.24375}}
{'ltrans': {'memory': 1.7144355773925781, 'cpu': 6.24375}}
{'ltrans': {'memory': 1.7144355773925781, 'cpu': 6.24375}}
{'ltrans': {'memory': 1.7144355773925781, 'cpu': 6.24375}}
{'ltrans': {'memory': 1.7144355773925781, 'cpu': 6.30625}}
{'ltrans': {'memory': 2.1491661071777344, 'cpu': 6.24375}}
{'ltrans': {'memory': 4.545764923095703, 'cpu': 6.24375}}
{'ltrans': {'memory': 5.894496917724609, 'cpu': 6.24375}}
{'ltrans': {'memory': 6.246974945068359, 'cpu': 6.30625}}
{'ltrans': {'memory': 6.279705047607422, 'cpu': 6.1875}}
...
1055s: current pass = dse1 (280)
{'ltrans': {'memory': 1.7354316711425781, 'cpu': 6.3125}}
{'ltrans': {'memory': 1.7354316711425781, 'cpu': 6.24375}}
{'ltrans': {'memory': 1.7354316711425781, 'cpu': 6.25}}
{'ltrans': {'memory': 1.7354316711425781, 'cpu': 6.25}}
{'ltrans': {'memory': 1.7354316711425781, 'cpu': 6.25}}
{'ltrans': {'memory': 1.9871711730957031, 'cpu': 6.25}}
{'ltrans': {'memory': 2.9451065063476562, 'cpu': 6.25}}
{'ltrans': {'memory': 3.904376983642578, 'cpu': 6.1875}}
{'ltrans': {'memory': 4.7339630126953125, 'cpu': 6.30625}}
{'ltrans': {'memory': 5.61910400391, 'cpu': 6.1875}}
{'ltrans': {'memory': 6.43743896484375, 'cpu': 6.3125}}
{'ltrans': {'memory': 6.7246246337890625, 'cpu': 6.25}}
{'ltrans': {'memory': 6.7246246337890625, 'cpu': 6.25}}
{'ltrans': {'memory': 6.488391876220703, 'cpu': 6.24375}}
...
1096s: current pass = combine (285)
{'ltrans': {'memory': 1.7870025634765625, 'cpu': 6.24375}}
 {GC released 6144k madv_dontneed 2460k} {GC 421M -> 294M}{'ltrans': {'memory':
1.7791824340820312, 'cpu': 6.30625}}
{'ltrans': {'memory': 1.7791824340820312, 'cpu': 6.1875}}
{'ltrans': {'memory': 1.7791824340820312, 'cpu': 6.30625}}
{'ltrans': {'memory': 1.7791824340820312, 'cpu': 6.25}}
{'ltrans': {'memory': 1.7791824340820312, 'cpu': 6.24375}}
{'ltrans': {'memory': 1.7791824340820312, 'cpu': 6.24375}}
{'ltrans': {'memory': 3.4982643127441406, 'cpu': 6.24375}}
{'ltrans': {'memory': 5.336437225341797, 'cpu': 6.18125}}
{'ltrans': {'memory': 5.823863983154297, 'cpu': 6.30625}}
{'ltrans': {'memory': 5.903423309326172, 'cpu': 6.24375}}
...

[Bug c++/55120] Inaccessible virtual base constructor does not prevent generation of default constructor

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

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Nick Krempel from comment #0)
> The following code should fail to compile but does not:
> 
> struct V {};
> struct B : private virtual V {};
> struct D : B {};
> 
> int main() {
>   D d;
> }
> 
> According to N3376 section 12.1 paragraph 5, the defaulted default
> constructor for D should be defined as deleted, as the default constructor
> for the virtual base V is inaccessible from D.

MSVC rejects this example, GCC, Clang and EDG accept it.

Oddly, Clang rejects it if ~V is user provided:

struct V { ~V() {} };
struct B : private virtual V {};
struct D : B {};
D d;

I have no idea why that makes a difference. GCC and EDG still accept that.

Clang doesn't care if V() is user provided, it will use it either way. It will
use ~V() if it's defined as deleted on its first declaration. It only rejects
it if ~V() is user provided.

I still don't know what the correct behaviour is.

[Bug rtl-optimization/98863] WRF with LTO consumes a lot of memory in REE, CPROP, PRE and LRA passes

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

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

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

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

commit r11-6973-gcb52e59e33845152cef6f9042a142a246e9447f6
Author: Richard Biener 
Date:   Fri Jan 29 13:25:49 2021 +0100

rtl-optimization/98863 - fix PRE/CPROP memory usage check

This fixes overflow of the memory usage estimate in turn failing
to disable itself on WRF with LTO, causing a few GBs worth of
memory peak.

2021-01-29  Richard Biener  

PR rtl-optimization/98863
* gcse.c (gcse_or_cprop_is_too_expensive): Use unsigned
HOST_WIDE_INT for the memory estimate.

[Bug c++/55120] Inaccessible virtual base constructor does not prevent generation of default constructor

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||richard-gccbugzilla@metafoo
   ||.co.uk
   Keywords||accepts-invalid
   Last reconfirmed||2021-01-29

--- Comment #10 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #9)
> I still don't know what the correct behaviour is.

My comment crossed with Anthony's, but he confirms that the code is invalid, so
confirming as accepts-invalid.

It looks like Clang has a bug with the inaccessible constructor too, and
strangely inconsistent handling of the inaccessible destructor.

[Bug c++/17314] Error message wrongly shows declared rather than inherited access

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |11.0
 Status|NEW |RESOLVED

--- Comment #27 from Jonathan Wakely  ---
Fixed by r11-6880, thanks!

[Bug c++/98881] [modules] internal compiler error: in tpl_parms_fini, at cp/module.cc:9933

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/98885] [modules] forward declaration of classes prevent them from being exported at the point of actual declaration

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

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

Nathan Sidwell  changed:

   What|Removed |Added

   Keywords|rejects-valid   |accepts-invalid
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-01-29
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org

--- Comment #1 from Nathan Sidwell  ---
This is ill-formed.  an exported entity must be so-declared on its first
declaration.

A diagnostic is missing on the definition of the class.

[Bug rtl-optimization/98863] WRF with LTO consumes a lot of memory in REE, CPROP, PRE and LRA passes

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

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

--- Comment #24 from Richard Biener  ---
Created attachment 50087
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50087&action=edit
updated time and memory report

This is updated -f{time,mem}-report (with --enable-gather-detailed-mem-stats)
for ltrans34.o

[Bug fortran/98890] New: ICE on reference to module function

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

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

Bug ID: 98890
   Summary: ICE on reference to module function
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

gfortran ICEs on the following testcase:

module foo
contains
  real function bar(x)
real :: x(2,2)
bar=baz*x(1,1)
  end function bar  
  real function baz(x)
real :: x(2,2)
baz=x(1,1)
  end function baz  
end module foo

Doesn't say anything even with implicit none, so maybe it is ok that baz lookup
gives the module function rather than a local variable, but shouldn't something
complain that it refers to the module function in an invalid way (rather than
say calling it)?  Originally this was reported due to a typo (the baz* should
have been bar* ).
If baz returns some incompatible type such as integer, then an error is
diagnosed.

[Bug rtl-optimization/98782] IRA artificially creating spills due to BB frequencies

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

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

--- Comment #2 from Tamar Christina  ---
Just an update on what I know so far.

There seems to be no symmetry between the growth of the memory costs vs that of
the caller saved registers.

In the case of the memory costs, the actual memory cost in the back end is
multiplied by the BB frequencies.
The total allocation frequency and memory costs for the memory is a sum of all
the usages of the register in
a live range/BB.

In the case of the example above the reg we're interested in is reg 104.

create_insn_allocnos you can see that the memory costs for the register and the
total frequencies grow as follows:

Bad:

   ALLOCNO_FREQ 10, REF_FREQ_BB 10
   ALLOCNO_FREQ 485, REF_FREQ_BB 485
   ALLOCNO_FREQ 989, REF_FREQ_BB 504

Good:

   ALLOCNO_FREQ 10, REF_FREQ_BB 10  
   ALLOCNO_FREQ 495, REF_FREQ_BB 495
   ALLOCNO_FREQ 990, REF_FREQ_BB 495

Notice that in the bad case your total final frequency is actually lower.

The costs are created by BB_FREQ * mem-cost in the backend. In the case of
AArch64 that's
BB_FREQ * 4.

So what we end up within cost calculations in scan_one_insn in ira-costs is:

Bad:

  add-cost 40, mem-cost 40
  add-cost 1940, mem-cost 1940
  add-cost 2016, mem-cost 3956

Good:

  add-cost 40, mem-cost 40
  add-cost 1980, mem-cost 1980
  add-cost 1980, mem-cost 3960

Counter-intuitively this means having a higher probability for the BB gets you
a lower frequency which in turn seems to give you a lower cost for memory
operations.

Finally this gets topped off somewhere with another small amount (10 * memcost,
where 10 looks like to be the ratio between BB_FREQ_MAX / REG_FREQ_MAX)
which result in the costs for regiisters that can be seen during an IRA dump.

Bad:

a5(r104,l0) costs: GENERAL_REGS:0,0 FP_LO8_REGS:50,4995 FP_LO_REGS:50,4995
FP_REGS:50,4995 POINTER_AND_FP_REGS:50,4995 MEM:40,3996

Good:

a5(r104,l0) costs: GENERAL_REGS:0,0 FP_LO8_REGS:50,5000 FP_LO_REGS:50,5000
FP_REGS:50,5000 POINTER_AND_FP_REGS:50,5000 MEM:40,4000

So overall a change of 0.1% in probability caused a decrease of 0.1 %
(BB_FREQ_MAX / REG_FREQ_MAX) * memcost.

Now, based on the above the base costs of using GENERAL_REGS for both of the
above are 0.

But in ira_tune_allocno_costs IRA applies a penalty to the costs of the
register if it's live across a call in the same BB.
This penalty is applied using the CALL_FREQ.

Bad:

  CALL_FREQ 504, FREQ_FROM_BB 504

Good:

  CALL_FREQ 495, FREQ_FROM_BB 495

So the BB_FREQ went down, but the CALL_FREQ went up in the Bad/Good case.

The BB_FREQ went down 1, but the CALL_FREQ went up 9.

The penalty that is applied is CALL_FREQ * ().
So in our case it's CALL_FREQ * (4 + 4).

So we end up with:

Bad:

   ira_memory_move_cost[0] 4, ira_memory_move_cost[1] 4
   cost 4032, reg-cost 4032
   CALL_FREQ 504, ALLOCANO_FREQ 999

Good:

   ira_memory_move_cost[0] 4, ira_memory_move_cost[1] 4  
   cost 3960, reg-cost 3960  
   CALL_FREQ 495, ALLOCANO_FREQ 1000 

Which gives us a final cost of:

Bad:

   Memory: 3956
   Register: 4032

Good:

   Memory: 3960
   Register: 3960

This is all to say, the penalty grows far quicker than BB frequency.
Tiny changes in BB frequencies have a large effect on it.

This is why RA ends up thinking it's cheaper to go through memory.  It is
trying to apply a penalty to the registers to prevent their use, which is
understandable but what isn't clear to me is that it doesn't take into account
whether the instruction is in a loop.  It can be far cheaper to spill at the
call site instead.

ira_tune_allocno_costs does have a callback hook

  IRA_HARD_REGNO_ADD_COST_MULTIPLIER

that targets can use to tweak the penalty being applied to the registers that
are live through a call. The annoying thing about the hook is that values you
give it are weighted by BB_FREQ and not CALL_FREQ.  So you're not given enough
information to be able to strike a balance between the growth of the CALL_FREQ
and the BB_FREQ.

It's done using

cost += ((ira_memory_move_cost[mode][rclass][0]
  + ira_memory_move_cost[mode][rclass][1])
 * ALLOCNO_FREQ (a)
 * IRA_HARD_REGNO_ADD_COST_MULTIPLIER (regno) / 2);

I have attempted to provide a backend-hook in AArch64 that applies an inverse
penalty to caller-saved registers.  But because I am not given frequency
information I can only give a constant penalty back, which means it's clearly
incorrect as it's specifically tuning for a loop in Exchange2.

Using this hook I was able to only regain about 40% of the regression with no
losses in SPECINT CPU2017.

But I think the ratio between the growth of the costs and the penalty is off. 
This is evident by that the regression exists on multiple targets.

[Bug rtl-optimization/98863] WRF with LTO consumes a lot of memory in REE, CPROP, PRE and LRA passes

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

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

Martin Liška  changed:

   What|Removed |Added

  Attachment #50072|0   |1
is obsolete||

--- Comment #25 from Martin Liška  ---
Created attachment 50088
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50088&action=edit
Current CPU/memory usage for master

[Bug fortran/98890] ICE on reference to module function

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

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

--- Comment #1 from Jakub Jelinek  ---
Seems the ICE is quite long, seems before around (+- 25 revisions) r137400
gfortran ICEd in the FE:
internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:483
and after that it ICEs in gimple verification, as the multiplication has
operand with invalid type.

[Bug c++/98885] [modules] forward declaration of classes prevent them from being exported at the point of actual declaration

[pilarlatiesa at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Pilar Latiesa  ---
(In reply to Nathan Sidwell from comment #1)
> This is ill-formed.  an exported entity must be so-declared on its first
> declaration.
> 
> A diagnostic is missing on the definition of the class.

I see. Thanks.

What about the second testcase? How a pattern like that is supposed to be
modularized?

[Bug analyzer/98447] incorrect -Wanalyzer-shift-count-overflow warning

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #5 from Vincent Lefèvre  ---
This is still failing (trunk). The test on godbolt:
https://godbolt.org/z/Yx7b1d

[Bug c++/98885] [modules] forward declaration of classes prevent them from being exported at the point of actual declaration

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

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

--- Comment #3 from Nathan Sidwell  ---
module partitions are probably what you want for such mutually dependent types.

[Bug c++/98459] [8/9/10/11 Regression] ICE in linemap_position_for_line_and_column, at libcpp/line-map.c:923 since r6-6901-g876217ae71cf0b34

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
David, could you please have a look at this?  Thanks.

[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||cltang at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-01-29
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r7-6598-g02889d23ee3b02854dff203dd87b9a25e30b61b4

[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533

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

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

--- Comment #2 from Jakub Jelinek  ---
Doesn't ICE if the conditions match the iteration direction, the way it is
written it will never iterate, and if it would iterate (say int i = 0; i > -3;
i++) it would be invalid OpenACC.  Doesn't ICE for int i = 0; i < -3; i++) that
never iterates and has the comparison in the corresponding direction to the
step.