[Bug bootstrap/98412] libcody does not compile with older GCC versions

[nikhil.benesch at gmail dot com via Gcc-bugs]

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

Nikhil Benesch  changed:

   What|Removed |Added

 CC||nikhil.benesch at gmail dot com

--- Comment #9 from Nikhil Benesch  ---
Looks like the same fix needs to be applied to cp/module.cc. See
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562404.html.

[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool

[admin at levyhsu dot com via Gcc-bugs]

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

--- Comment #57 from Levy  ---
Thank you JiaWei for the CoreMark-Pro result.

Personally, I agree with Jim, since changing the split behaviour of try_combine
in the combine.c could affect other platforms, theoretically, we can fix it
with platform flag and UNITS_PER_WORD check or maybe Just skip over a
ZERO_EXTEND or SIGN_EXTEND before the general_operand check, but that seems
inconvenient.

Probably need more testing on all patches to see the differences in code size &
speed. Maybe after EEMBC results come out then decide what to proceed next.

[Bug c++/98416] POWER8: SIGILL handler does not restart properly after signal using GCC 10.2.1

[noloader at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Jeffrey Walton  ---
(In reply to Andrew Pinski from comment #2)
> This is invalid.
> The instruction which is failing is:
>   9c: f0 00 02 d0 xxspltib vs0,0
>
> Which is only valid in power9 and above.
> You need to mark CPU_ProbePower9 not to be compiled with -mcpu=power9, by
> using the target attribute.

I have to use it because I am using the POWER9 ISA.

[Bug c++/98416] POWER8: SIGILL handler does not restart properly after signal using GCC 10.2.1

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
This is invalid.
The instruction which is failing is:
  9c:   f0 00 02 d0 xxspltib vs0,0

Which is only valid in power9 and above.
You need to mark CPU_ProbePower9 not to be compiled with -mcpu=power9, by using
the target attribute.

[Bug go/98402] [11 Regression] libgo build broken on arm-linux-gnueabi

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #4 from Ian Lance Taylor  ---
This should be fixed now.

[Bug c++/98416] POWER8: SIGILL handler does not restart properly after signal using GCC 10.2.1

[noloader at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Jeffrey Walton  ---
Created attachment 49831
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49831=edit
Disassembly of ppc_power9.o

Created with 'objdump --disassemble ppc_power9.o | c++filt >
ppc_power9.disass'.

[Bug c++/85648] Name mangling using decltype omits namespace

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

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

--- Comment #3 from Jason Merrill  ---
Created attachment 49830
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49830=edit
Fix

This patch depends on the one for bug 67343, and similarly is waiting for the
resolution of ABI issue 38.

[Bug c++/67343] C++ mangler does not follow ABI for unresolved names in expressions

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

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

--- Comment #8 from Jason Merrill  ---
Created attachment 49829
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49829=edit
Follow-on patch

And this one fixes ->:: according to the current ABI, but also holding for the
issue resolution.

[Bug c++/67343] C++ mangler does not follow ABI for unresolved names in expressions

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

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

--- Comment #7 from Jason Merrill  ---
Created attachment 49828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49828=edit
WIP Fix

Here's my current patch for this bug, but I think I'm going to hold off on it
pending the resolution of ABI issue 38.

[Bug c++/67343] C++ mangler does not follow ABI for local names in expressions

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:58fb912c15175f144b8a4ab52a4880b84994

commit r11-6300-g58fb912c15175f144b8a4ab52a4880b84994
Author: Jason Merrill 
Date:   Mon Dec 21 17:36:25 2020 -0500

c++: Fix demangling of 

The ABI for unresolved scoped names on the RHS of . and -> used to be

  sr  

That changed years ago to something more complex, but G++ was never
updated.
This change was particularly incompatible for simple qualified-ids like
A::x, which were previously mangled as sr1A1x, and now sr1AE1x.

This obviously makes life hard for demanglers, which can't know whether to
consume that E or not.  To work around this, we now try demangling with the
newer ABI, and if that fails and we saw an "sr", try again with the older
ABI.

libiberty/ChangeLog:

PR c++/67343
* cp-demangle.h (struct d_info): Add unresolved_name_state.
* cp-demangle.c (d_prefix): Add subst parm.
(d_nested_name): Pass it.
(d_unresolved_name): Split out from...
(d_expression_1): ...here.
(d_demangle_callback): Maybe retry with old sr mangling.
* testsuite/demangle-expected: Add test.

[Bug bootstrap/98318] libcody breaks DragonFly bootstrap

[hliu at amperecomputing dot com via Gcc-bugs]

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

--- Comment #5 from Hao Liu  ---
Hi Nanthan,

We can still reprodcue this problem on CentOS 7 (X86) and CentOS 8.2 (AArch64).
We use last  GCC version of yesterday:108beb75da

The configure and build commands are (Bash is used):
$ ../gcc/configure --disable-bootstrap --disable-multilib
--enable-checking=release
$ make -j32
...
make[2]: *** No rule to make target '../libcody/libcody.a', needed by
'cc1-checksum.c'.  Stop.
make[2]: *** Waiting for unfinished jobs

Do you have any idea about how to fix this?

[Bug go/98402] [11 Regression] libgo build broken on arm-linux-gnueabi

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

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

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

https://gcc.gnu.org/g:03ea48ff27fd40b04b148f7006a02513a887ad0d

commit r11-6297-g03ea48ff27fd40b04b148f7006a02513a887ad0d
Author: Ian Lance Taylor 
Date:   Mon Dec 21 16:17:23 2020 -0800

Go frontend: ensure mpfr exponent range is large enough for Go

PR go/98402
* go-lang.c (go_langhook_init): Force MPFR exponent range to be
large enough to support Go constants.

[Bug c++/98353] [8/9/10 Regression] ICE in propagate_necessity, at tree-ssa-dce.c:1053 since r6-4886-gcda0a029f45d20f4

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression] ICE  |[8/9/10 Regression] ICE in
   |in propagate_necessity, at  |propagate_necessity, at
   |tree-ssa-dce.c:1053 since   |tree-ssa-dce.c:1053 since
   |r6-4886-gcda0a029f45d20f4   |r6-4886-gcda0a029f45d20f4

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

[Bug c++/98353] [8/9/10/11 Regression] ICE in propagate_necessity, at tree-ssa-dce.c:1053 since r6-4886-gcda0a029f45d20f4

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

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

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

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

commit r11-6295-ga477f1445b3093d01e68cd4c096c5776ad769e11
Author: Jakub Jelinek 
Date:   Tue Dec 22 00:01:34 2020 +0100

gimplify: Gimplify value in gimplify_init_ctor_eval_range [PR98353]

gimplify_init_ctor_eval_range wasn't gimplifying value, so if it wasn't
a gimple val, verification at the end of gimplification would ICE (or with
release checking some random pass later on would ICE or misbehave).

2020-12-21  Jakub Jelinek  

PR c++/98353
* gimplify.c (gimplify_init_ctor_eval_range): Gimplify value before
storing it into cref.

* g++.dg/opt/pr98353.C: New test.

[Bug c++/93480] Defaulted <=> doesn't expand array elements

[wjwray at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Will Wray  ---
Thanks Jakub;

I applied your patch to trunk and ran more test cases for
nested arrays (including zero-size in various positions),
union element type, base classes - all passed as expected.
I tried to grok the patch to look for problems - saw none.

In testing, a worse bug surfaced with defaulted operator==

The current bug was that defaulted <=> was deleted in the
presence of array members, so rel-ops fail to compile.

However, defaulted == is defined (on trunk) for array members
but appears to compare the pointer value of the decayed array
so == or != comparisons compile and give the wrong result
https://godbolt.org/z/Pbr9xr

Your patch fixes this bug also.

[Bug c++/98416] New: POWER8: SIGILL handler does not restart properly after signal using GCC 10.2.1

[noloader at gmail dot com via Gcc-bugs]

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

Bug ID: 98416
   Summary: POWER8: SIGILL handler does not restart properly after
signal using GCC 10.2.1
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

Created attachment 49827
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49827=edit
preprocessed ppc_power9.cpp

We are testing on GCC203 on the compile farm. GCC203 is a Debian POWER8 machine
with GCC 10.2.1.

The following code executes 'darn r3, 0;', which is a POWER9 instruction. It
causes a SIGILL, which is expected. However, when restarted from the setjump
the program SIGILLs again. The second SIGILL is not expected.

// https://github.com/weidai11/cryptopp/blob/master/ppc_power9.cpp#L42
// With the extra cruft removed...
bool CPU_ProbePower9()
{
// longjmp and clobber warnings. Volatile is required.
volatile int result = true;

volatile SigHandler oldHandler = signal(SIGILL, SigIllHandler);
if (oldHandler == SIG_ERR)
return false;

volatile sigset_t oldMask;
if (sigprocmask(0, NULLPTR, (sigset_t*)))
{
signal(SIGILL, oldHandler);
return false;
}

if (setjmp(s_jmpSIGILL))
result = false;  / <= SIGILL here! /
else
{
// This is "darn r3, 0". We had to move away from the instrinsic 
// because Clang and IBM XL C/C++ does not support the instrinsic.
#if __BIG_ENDIAN__
__asm__ __volatile__ (".byte 0x7c, 0x60, 0x05, 0xe6  \n" : : : "r3");
#else
__asm__ __volatile__ (".byte 0xe6, 0x05, 0x60, 0x7c  \n" : : : "r3");
#endif
result = true;
}

sigprocmask(SIG_SETMASK, (sigset_t*), NULLPTR);
signal(SIGILL, oldHandler);
return result;
}

Here's what it looks like under the debugger:

(gdb) r v
Starting program: /home/noloader/cryptopp/cryptest.exe v
...

### This one is expected. It is a feature probe. ###
Program received signal SIGILL, Illegal instruction.
CryptoPP::CPU_ProbePower9 () at ppc_power9.cpp:70
70  __asm__ __volatile__ (".byte 0x7c, 0x60, 0x05, 0xe6  \n" : : :
"r3");
(gdb) n
CryptoPP::SigIllHandler () at ppc_power9.cpp:35
35  longjmp(s_jmpSIGILL, 1);
(gdb) n

### This one is not expected. ###
Program received signal SIGILL, Illegal instruction.
CryptoPP::CPU_ProbePower9 () at ppc_power9.cpp:64
64  result = false;
(gdb) n

Program terminated with signal SIGILL, Illegal instruction.

=

> the complete command line that triggers the bug;
> the compiler output (error messages, warnings, etc.);

The compiler command invoked by make before and after are also shown. The
program is clean with -Wall, UBsan, Asan, etc.

g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -mcpu=power8 -c ppc_power8.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -mcpu=power9 -c ppc_power9.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -maltivec -c ppc_simd.cpp

=

> the preprocessed file (*.i*) that triggers the bug, generated by adding 
> -save-temps to the complete compilation command, or, in the case of a bug 
> report for the GNAT front end, a complete set of source files (see below).

Attached. The command used was:

g++ -save-temps -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -mcpu=power9 -c
ppc_power9.cpp

=

> the exact version of GCC;
> the system type;
> the options given when GCC was configured/built;

$ gcc --version
gcc (Debian 10.2.1-1) 10.2.1 20201207

$ lsb_release -a
Distributor ID: Debian
Description:Debian GNU/Linux bullseye/sid
Release:unstable
Codename:   sid

$ gcc -v 2>&1 | fold -w 80
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64-linux-gnu/10/lto-wrapper
Target: powerpc64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-1'
--with-
bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,
d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only
--program-suf
fix=-10 --program-prefix=powerpc64-linux-gnu- --enable-shared
--enable-linker-bu
ild-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
-
-libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-l
ibstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--en
able-gnu-unique-object --disable-libquadmath --disable-libquadmath-support
--ena
ble-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=r
elease --with-target-system-zlib=auto --enable-objc-gc=auto --enable-secureplt
-
-disable-softfloat --enable-targets=powerpc64-linux,powerpc-linux
--enable-multi
arch --disable-werror --with-long-double-128 --enable-multilib
--enable-checking
=release 

[Bug c/98397] C2X: pointers to arrays with qualifiers are now pointers to qualified types

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #1 from Martin Uecker  ---


PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562359.html

[Bug tree-optimization/98415] [11 Regression] GCC crashes on Linux kernel build after r11-6271-g69165332a914f1167c3077fa1f57afc64fd8a667

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

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

--- Comment #3 from Jakub Jelinek  ---
Can you reproduce with r11-6281-gd8aeee11af715507e61464d390f14e4f4fde61b0 or
later?

[Bug tree-optimization/98415] [11 Regression] GCC crashes on Linux kernel build after r11-6271-g69165332a914f1167c3077fa1f57afc64fd8a667

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

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

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

--- Comment #2 from Maxim Kuvyrkov  ---
Jakub, would you please take a look at this?

Let me know if you need any assistance in reproducing this.

[Bug tree-optimization/98415] [11 Regression] GCC crashes on Linux kernel build after r11-6271-g69165332a914f1167c3077fa1f57afc64fd8a667

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

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

--- Comment #1 from Maxim Kuvyrkov  ---
Created attachment 49826
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49826=edit
Reduced testcase

[Bug tree-optimization/98415] New: [11 Regression] GCC crashes on Linux kernel build after r11-6271-g69165332a914f1167c3077fa1f57afc64fd8a667

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

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

Bug ID: 98415
   Summary: [11 Regression] GCC crashes on Linux kernel build
after
r11-6271-g69165332a914f1167c3077fa1f57afc64fd8a667
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mkuvyrkov at gcc dot gnu.org
  Target Milestone: ---

GCC crashes building one of Linux kernel drivers after
r11-6271-g69165332a914f1167c3077fa1f57afc64fd8a667 at least for AArch64 and ARM
(likely, other architectures as well, but I didn't test).

Attached is a reduced (down from 3.5M!) testcase for GCC targeting
aarch64-linux-gnu.

Before r11-6271-g69165332a914f1167c3077fa1f57afc64fd8a667 cc1 cleanly compiles
the attached testcase:
$ ./cc1 channel.i -o channel.s -quiet -Wall -Wundef -Werror
-mstack-protector-guard=sysreg -mstack-protector-guard-reg=sp_el0
-mstack-protector-guard-offset=1344 -O2 -Wno-pointer-sign
-Wno-packed-not-aligned -fno-strict-aliasing

and after we get:

$ ./cc1 channel.i -o channel.s -quiet -Wall -Wundef -Werror
-mstack-protector-guard=sysreg -mstack-protector-guard-reg=sp_el0
-mstack-protector-guard-offset=1344 -O2 -Wno-pointer-sign
-Wno-packed-not-aligned -fno-strict-aliasing
free(): invalid next size (fast)
during GIMPLE pass: ccp
channel.i: In function ‘ak’:
channel.i:19:1: internal compiler error: Aborted
   19 | }
  | ^
0xf440b3 crash_signal
   
/home/maxim.kuvyrkov/tcwg_kernel/abe/snapshots/gcc.git~master/gcc/toplev.c:327
0xac0e4a ~dom_info
   
/home/maxim.kuvyrkov/tcwg_kernel/abe/snapshots/gcc.git~master/gcc/dominance.c:284
0xac2a5b calculate_dominance_info(cdi_direction)
   
/home/maxim.kuvyrkov/tcwg_kernel/abe/snapshots/gcc.git~master/gcc/dominance.c:733
0xf99929 cleanup_tree_cfg_noloop
   
/home/maxim.kuvyrkov/tcwg_kernel/abe/snapshots/gcc.git~master/gcc/tree-cfgcleanup.c:1086
0xf99929 cleanup_tree_cfg(unsigned int)
   
/home/maxim.kuvyrkov/tcwg_kernel/abe/snapshots/gcc.git~master/gcc/tree-cfgcleanup.c:1187
0xe5634c execute_function_todo
   
/home/maxim.kuvyrkov/tcwg_kernel/abe/snapshots/gcc.git~master/gcc/passes.c:2008
0xe5705e execute_todo
   
/home/maxim.kuvyrkov/tcwg_kernel/abe/snapshots/gcc.git~master/gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Interestingly, the original testcase crashes with a different backtrace:

00:18:04 realloc(): invalid next size
00:18:04 during GIMPLE pass: pre
00:18:04 drivers/net/wireless/broadcom/brcm80211/brcmsmac/channel.c: In
function ‘brcms_reg_notifier’:
00:18:04 drivers/net/wireless/broadcom/brcm80211/brcmsmac/channel.c:695:13:
internal compiler error: Aborted
00:18:04   695 | static void brcms_reg_notifier(struct wiphy *wiphy,
00:18:04   | ^~
00:18:04 0xd95a3f crash_signal
00:18:04   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/toplev.c:327
00:18:04 0x1adb9cc xrealloc
00:18:04   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/libiberty/xmalloc.c:179
00:18:04 0xf8772a void va_heap::reserve(vec*&, unsigned int, bool)
00:18:04   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/vec.h:290
00:18:04 0xf8772a vec::reserve(unsigned int,
bool)
00:18:04   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/vec.h:1778
00:18:04 0xf7ddd9 vec::safe_grow(unsigned int,
bool)
00:18:04   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/vec.h:1926
00:18:04 0xf7ddd9 vec::safe_grow_cleared(unsigned int, bool)
00:18:04   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/vec.h:1945
00:18:04 0xf7ddd9 add_to_value
00:18:04   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/tree-ssa-pre.c:715
00:18:04 0xf7edd7 phi_translate_1
00:18:04   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/tree-ssa-pre.c:1740
00:18:04 0xf7f7cf phi_translate
00:18:04   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/tree-ssa-pre.c:1807
00:18:04 0xf82aeb phi_translate_set
00:18:04   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/tree-ssa-pre.c:1852
00:18:04 0xf8305a compute_antic_aux
00:18:04   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/tree-ssa-pre.c:2192
00:18:04 0xf8305a compute_antic
00:18:04   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/tree-ssa-pre.c:2538
00:18:04 0xf8562b execute
00:18:04   

[Bug fortran/98411] [10/11] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||anlauf at gcc dot gnu.org

[Bug fortran/98411] [10/11] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-12-21

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

[Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

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

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

Patrick Palka  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-21
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

[Bug c++/98364] C++20 module global constructor emission

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #7 from cqwrteur  ---
Created attachment 49825
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49825=edit
header only naive version

g++ -o naive naive.cc -Ofast -std=c++20 -s -flto

compile both of them and compare assembly.

[Bug c++/98364] C++20 module global constructor emission

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #6 from cqwrteur  ---
(In reply to Nathan Sidwell from comment #2)
> Is this windows-specific? please privode preprocessed source and compilation
> command.

You need to just compile the code and then use objdump to view generated
assembly.

[Bug c++/98364] C++20 module global constructor emission

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #5 from cqwrteur  ---
(In reply to cqwrteur from comment #3)
> Created attachment 49824 [details]
> just compile them and link together to see assembly.

compilation command

g++ -o main main.cc hello.cc -Ofast -std=c++20 -flto -fmodules-ts

[Bug c++/98364] C++20 module global constructor emission

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #4 from cqwrteur  ---
(In reply to Nathan Sidwell from comment #2)
> Is this windows-specific? please privode preprocessed source and compilation
> command.

no

[Bug c++/98364] C++20 module global constructor emission

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #3 from cqwrteur  ---
Created attachment 49824
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49824=edit
just compile them and link together to see assembly.

[Bug c++/98364] C++20 module global constructor emission

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from Nathan Sidwell  ---
Is this windows-specific? please privode preprocessed source and compilation
command.

[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++

[mkrupcale at matthewkrupcale dot com via Gcc-bugs]

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

--- Comment #3 from Matthew Krupcale  ---
I now observe this failure in the following two circumstances building multilib
bootstrap GCC:
 - GCC 4.8.3 using GCC 10.2.1-9 on Fedora 33[1]

/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/./gcc/xgcc
-shared-libgcc
-B/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/./gcc
-nostdinc++
-L/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/src
-L/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/src/.libs
-B/usr/x86_64-redhat-linux/bin/ -B/usr/x86_64-redhat-linux/lib/ -isystem
/usr/x86_64-redhat-linux/include -isystem /usr/x86_64-redhat-linux/sys-include 
-m32 -x c++-header -nostdinc++ -O2 -g -grecord-gcc-switches -Wformat
-Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic
-fasynchronous-unwind-tables  -D_GNU_SOURCE  -m32
-I/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/include/x86_64-redhat-linux
-I/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/include
-I/builddir/build/BUILD/gcc-4.8.3-20140911/libstdc++-v3/libsupc++ -O2 -g
/builddir/build/BUILD/gcc-4.8.3-20140911/libstdc++-v3/include/precompiled/stdc++.h
-o x86_64-redhat-linux/bits/stdc++.h.gch/O2g.gch
/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/./gcc/cc1plus:
/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/src/.libs/libstdc++.so.6:
version `CXXABI_1.3.9' not found (required by
/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/./gcc/cc1plus)

 - GCC 8.2.1 using GCC 11.0.0-0.7 on Fedora 34[2]

/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/./gcc/xgcc
-shared-libgcc
-B/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/./gcc
-nostdinc++
-L/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/src
-L/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/src/.libs
-L/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/libsupc++/.libs
-B/usr/x86_64-redhat-linux/bin/ -B/usr/x86_64-redhat-linux/lib/ -isystem
/usr/x86_64-redhat-linux/include -isystem /usr/x86_64-redhat-linux/sys-include 
-m32 -x c++-header -nostdinc++ -O2 -g -grecord-gcc-switches -Wformat
-Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-D_GNU_SOURCE  -m32 
-I/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/include/x86_64-redhat-linux
-I/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/include
-I/builddir/build/BUILD/gcc-8.2.1-20181215/libstdc++-v3/libsupc++  -O2 -g
/builddir/build/BUILD/gcc-8.2.1-20181215/libstdc++-v3/include/precompiled/stdc++.h
-o x86_64-redhat-linux/bits/stdc++.h.gch/O2g.gch
/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/./gcc/cc1plus:
/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/src/.libs/libstdc++.so.6:
version `GLIBCXX_3.4.29' not found (required by
/builddir/build/BUILD/gcc-8.2.1-20181215/obj-x86_64-redhat-linux/./gcc/cc1plus)

Furthermore, the build is successful when applying the aforementioned patches
to their respective versions:
 - patched GCC 4.8.3 using GCC 10.2.1-9 on Fedora 33[3]
 - patched GCC 8.2.1 using GCC 11.0.0-0.7 on Fedora 34[4]

Thus, I can validate my remarks in comment 0 and comment 2 that this does not
only apply to GCC 4.8.3 but also to other (future) versions of GCC. In
particular, I have now successfully tested the GCC 8.2 patch of comment 1. It
took some time to demonstrate this because, for example, building unpatched GCC
8.2.1 is successful on F33 with GCC 10.2.1-9[2] but fails in this way on F34
with GCC 11.0.0-0.7[2].

As far as I can tell, this issue still applies to the latest GCC. That is,
stage1 host modules attempt to use the stage1 target libstdc++ when they should
instead use the build libstdc++.

[1] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc/build/1843629/
[2] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc-8/build/1843814/
[3] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc/build/1843525/
[4] https://copr.fedorainfracloud.org/coprs/mkrupcale/gcc-8/build/1843815/

[Bug c++/98386] C++20 module: file exists failure and success happen alternatively for windows.

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #10 from Nathan Sidwell  ---
e798f081925 2020-12-21 | c++: Windows rename [PR 98412]

[Bug c++/98386] C++20 module: file exists failure and success happen alternatively for windows.

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #9 from cqwrteur  ---
(In reply to Nathan Sidwell from comment #7)
> Please take your diatribes to /dev/null.  Are you able to test the patch?

fixed confirm

[Bug c++/98386] C++20 module: file exists failure and success happen alternatively for windows.

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #8 from cqwrteur  ---
(In reply to Nathan Sidwell from comment #7)
> Please take your diatribes to /dev/null.  Are you able to test the patch?

Wait a second. I am testing

[Bug c++/98386] C++20 module: file exists failure and success happen alternatively for windows.

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

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

--- Comment #7 from Nathan Sidwell  ---
Please take your diatribes to /dev/null.  Are you able to test the patch?

[Bug bootstrap/98412] libcody does not compile with older GCC versions

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #8 from Nathan Sidwell  ---
1467a5c5ab0 2020-12-21 | bootstrap: std:stoul non-portable [PR 98412]

[Bug c++/98386] C++20 module: file exists failure and success happen alternatively for windows.

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #6 from cqwrteur  ---
(In reply to Nathan Sidwell from comment #3)
> Hm does rename(2) fail on windows if the new name exists?  (in posix it
> replaces, otherwise there's gonna be a race condition)

well. tbh, on windows, the safest way to deal with filesystem is to use NT
syscalls. Or you will not be able to access at-series apis.

C++17 filesystem is a horrible mistake since every C++17 filesystem use case is
a TOCTOU

[Bug bootstrap/98412] libcody does not compile with older GCC versions

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

https://gcc.gnu.org/g:1467a5c5ab0dfbae3175b4a326467f939864dadb

commit r11-6289-g1467a5c5ab0dfbae3175b4a326467f939864dadb
Author: Nathan Sidwell 
Date:   Mon Dec 21 09:16:48 2020 -0800

bootstrap: std:stoul non-portable [PR 98412]

Fix some more system-specific issues.  Not everyone's C++11 is the same :(

PR bootstrap/98412
libcody/
* client.cc: Include cstdlib.
* server.cc: Include cstdlib.
gcc/cp/
* mapper-client.cc: INCLUDE_STRING, INCLUDE_VECTOR.
(module_client::open_module_client): Avoid std::stoul.
* mapper-resolver.cc: INCLUDE_STRING, INCLUDE_VECTOR.

[Bug c++/98386] C++20 module: file exists failure and success happen alternatively for windows.

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2020-12-21

[Bug c++/98386] C++20 module: file exists failure and success happen alternatively for windows.

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #5 from cqwrteur  ---
(In reply to Nathan Sidwell from comment #4)
> Created attachment 49823 [details]
> test patch
> 
> This does an unlink before the rename, and also adds more logging.  If it
> fails, please try with -fdump-lang-module added and provide that dump

unlink and rename is a TOCTOU security vulnerability. The correct method must
use openat and NtCreateFile.

[Bug bootstrap/98412] libcody does not compile with older GCC versions

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

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

--- Comment #6 from Eric Botcazou  ---
> Can you try this?  I guess we're finding the limitations of 'requires C++11'

Yes, this fixes all the compilation failures, thanks!

[Bug c++/98386] C++20 module: file exists failure and success happen alternatively for windows.

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

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

--- Comment #4 from Nathan Sidwell  ---
Created attachment 49823
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49823=edit
test patch

This does an unlink before the rename, and also adds more logging.  If it
fails, please try with -fdump-lang-module added and provide that dump

[Bug c++/98386] C++20 module: file exists failure and success happen alternatively for windows.

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

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

--- Comment #3 from Nathan Sidwell  ---
Hm does rename(2) fail on windows if the new name exists?  (in posix it
replaces, otherwise there's gonna be a race condition)

[Bug bootstrap/98412] libcody does not compile with older GCC versions

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

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

--- Comment #5 from Nathan Sidwell  ---
Created attachment 49822
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49822=edit
test patch

Can you try this?  I guess we're finding the limitations of 'requires C++11' :)

[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool

[jiawei at iscas dot ac.cn via Gcc-bugs]

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

--- Comment #56 from jiawei  ---
   Hi Kito,

   I test the performance data on qemu-riscv64, and compile the benchmark
   with riscv-unknown-linux-gnu-gcc -Os.
   All the modify is set in /coremark-pro/util/make/
   to change the toolchain and run env.

   I am also insterested about which part has changed due to the patch. I
   will try to find out the different.在 2020年12月21日 下午11:38，"kito at gcc
   dot gnu.org" 写道：

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

 --- Comment #55 from Kito Cheng  ---
 Hi jiawei:

 Thanks for the data, the performance changing for coremark-pro
 seems
 interesting, could you find which part generate different code
 after the patch?

 And I am curious what the platform you used for the performance
 data?

 --
 You are receiving this mail because:
 You are on the CC list for the bug.



   1. http://gnu.org

[Bug bootstrap/98412] libcody does not compile with older GCC versions

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-12-21
 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #4 from Eric Botcazou  ---
Another one:

/homes/botcazou/gcc-head/src/gcc/cp/mapper-client.cc: In static member function
'static module_client* module_client::open_module_client(location_t, const
char*, void (*)(const char*), const char*)':
/homes/botcazou/gcc-head/src/gcc/cp/mapper-client.cc:176:35: error: 'stoul' is
not a member of 'std'
fd_from = std::stoul (from, , 10);
   ^
/homes/botcazou/gcc-head/src/gcc/cp/mapper-client.cc:193:33: error: 'stoul' is
not a member of 'std'
fd_to = std::stoul (to, , 10);
 ^
gmake[3]: *** [cp/mapper-client.o] Error 1

[Bug bootstrap/98412] libcody does not compile with older GCC versions

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

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

--- Comment #3 from Eric Botcazou  ---
Thanks.  The next errors are:

/homes/botcazou/gcc-head/src/libcody/client.cc: In function 'Cody::Packet
Cody::ConnectResponse(std::vector >&)':
/homes/botcazou/gcc-head/src/libcody/client.cc:217:64: error: 'strtoul' was not
declared in this scope
   unsigned long val = strtoul (words[1].c_str (), , 10);
^
mv -f .deps/libz_a-trees.Tpo .deps/libz_a-trees.Po
/homes/botcazou/gcc-head/src/libcody/server.cc: In function 'unsigned int
Cody::ParseUnsigned(std::string&)':
/homes/botcazou/gcc-head/src/libcody/server.cc:164:55: error: 'strtoul' was not
declared in this scope
   unsigned long val = strtoul (str.c_str (), , 10);

and are fixed by adding

#include 

to both files.

[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool

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

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

--- Comment #55 from Kito Cheng  ---
Hi jiawei:

Thanks for the data, the performance changing for coremark-pro seems
interesting, could you find which part generate different code after the patch?

And I am curious what the platform you used for the performance data?

[Bug c++/98413] [11 Regression] ICE with placement new since r11-3827-g83685efd5fd1623c

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|ICE with placement new  |[11 Regression] ICE with
   ||placement new since
   ||r11-3827-g83685efd5fd1623c
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
   Priority|P3  |P1
 Ever confirmed|0   |1
   Last reconfirmed||2020-12-21
  Known to work||10.2.0
  Known to fail||11.0

--- Comment #2 from Martin Liška  ---
Confirmed, started with r11-3827-g83685efd5fd1623c.

[Bug c++/98413] ICE with placement new

[475647575 at qq dot com via Gcc-bugs]

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

--- Comment #1 from 欢乐的0403 <475647575 at qq dot com> ---
// A smaller example:
#include 
struct A{
int m;
};

A a;
void f(int A::*member_pointer)
{
new (&(a.*member_pointer)) int;
}
//https://godbolt.org/z/KhPq9e

[Bug bootstrap/98414] [11 Regression] UBSAN bootstrap is broken: ubsan/ubsan_type_hash_itanium.cpp:162: undefined reference to `__dynamic_cast'

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-12-21
 Ever confirmed|0   |1

[Bug bootstrap/98414] New: [11 Regression] UBSAN bootstrap is broken: ubsan/ubsan_type_hash_itanium.cpp:162: undefined reference to `__dynamic_cast'

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

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

Bug ID: 98414
   Summary: [11 Regression] UBSAN bootstrap is broken:
ubsan/ubsan_type_hash_itanium.cpp:162: undefined
reference to `__dynamic_cast'
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

The following fails:

/home/mliska/Programming/gcc/objdir/./prev-gcc/xg++
-B/home/mliska/Programming/gcc/objdir/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu

-I/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
 -I/home/mliska/Programming/gcc/libstdc++-v3/libsupc++
-L/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-no-pie   -g -O2 -fchecking=1 -fsanitize=undefined -DUBSAN_BOOTSTRAP  -DIN_GCC 
   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H
-static-libstdc++ -static-libgcc -fsanitize=undefined -static-libubsan
-DUBSAN_BOOTSTRAP
-B/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libsanitizer/
-B/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libsanitizer/ubsan/
-B/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libsanitizer/ubsan/.libs
  -o cc1plus \
  cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/class.o cp/constexpr.o
cp/constraint.o cp/coroutines.o cp/cp-gimplify.o cp/cp-objcp-common.o
cp/cp-ubsan.o cp/cvt.o cp/cxx-pretty-print.o cp/decl.o cp/decl2.o cp/dump.o
cp/error.o cp/except.o cp/expr.o cp/friend.o cp/init.o cp/lambda.o cp/lex.o
cp/logic.o cp/mangle.o cp/mapper-client.o cp/mapper-resolver.o cp/method.o
cp/module.o cp/name-lookup.o cp/optimize.o cp/parser.o cp/pt.o cp/ptree.o
cp/rtti.o cp/search.o cp/semantics.o cp/tree.o cp/typeck.o cp/typeck2.o
cp/vtable-class-hierarchy.o attribs.o incpath.o c-family/c-common.o
c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o
c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o
c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o
c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o
c-family/c-ada-spec.o c-family/c-ubsan.o c-family/known-headers.o
c-family/c-attribs.o c-family/c-warn.o c-family/c-spellcheck.o i386-c.o
glibc-c.o cc1plus-checksum.o libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libcody/libcody.a ../libdecnumber/libdecnumber.a
libcommon.a ../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a   -lmpc -lmpfr -lgmp
-rdynamic  -L./../zlib -lz 
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:
/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libsanitizer/ubsan/.libs/libubsan.a(ubsan_type_hash_itanium.o):
in function `findBaseAtOffset(__cxxabiv1::__class_type_info const*, long)':
/home/mliska/Programming/gcc/objdir/x86_64-pc-linux-gnu/libsanitizer/ubsan/../../../../libsanitizer/ubsan/ubsan_type_hash_itanium.cpp:162:
undefined reference to `__dynamic_cast'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:
/home/mliska/Programming/gcc/objdir/x86_64-pc-linux-gnu/libsanitizer/ubsan/../../../../libsanitizer/ubsan/ubsan_type_hash_itanium.cpp:166:
undefined reference to `typeinfo for __cxxabiv1::__vmi_class_type_info'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:
/home/mliska/Programming/gcc/objdir/x86_64-pc-linux-gnu/libsanitizer/ubsan/../../../../libsanitizer/ubsan/ubsan_type_hash_itanium.cpp:166:
undefined reference to `__dynamic_cast'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:
/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libsanitizer/ubsan/.libs/libubsan.a(ubsan_type_hash_itanium.o):
in function `isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*,
__cxxabiv1::__class_type_info const*, long)':
/home/mliska/Programming/gcc/objdir/x86_64-pc-linux-gnu/libsanitizer/ubsan/../../../../libsanitizer/ubsan/ubsan_type_hash_itanium.cpp:125:
undefined reference to `__dynamic_cast'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:

[Bug c++/98413] New: ICE with placement new

[475647575 at qq dot com via Gcc-bugs]

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

Bug ID: 98413
   Summary: ICE with placement new
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 475647575 at qq dot com
  Target Milestone: ---

// example program
#include 
struct A{
int m{};
};
template
void f(A *instance, T A::*member_pointer)
{
new (&(instance->*member_pointer)) T{0};
}

int main()
{
A a;
f(, ::m);
return 0;
}
---
error: 

: In instantiation of 'void f(A*, T A::*) [with T = int]':
:14:16:   required from here
:8:5: internal compiler error: tree check: expected integer_type or
enumeral_type or boolean_type or real_type or fixed_point_type, have
offset_type in get_offset_range, at builtins.c:5108
8 | new (&(instance->*member_pointer)) T{0};
  | ^~~
0x1cb9849 internal_error(char const*, ...)
???:0
0x673fd7 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
???:0
0xabc5d8 compute_objsize(tree_node*, int, access_ref*, range_query*)
???:0
0x7ee121 build_new(unsigned int, vec**,
tree_node*, tree_node*, vec**, int, int)
???:0
0x90fa2f instantiate_decl(tree_node*, bool, bool)
???:0
0x950f5b instantiate_pending_templates(int)
???:0
0x7c21b9 c_parse_final_cleanups()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
ASM generation compiler returned: 1


gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/gcc11/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --disable-multilib --prefix=/gcc11
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201217 (experimental) (GCC)
-
exact gcc commit used:
https://github.com/gcc-mirror/gcc/commit/6f8486523f61bf0aa476dfa4197d1e3b71a0a8f3

This bug can be re-producted in godbolt:
https://godbolt.org/z/TeTbET

[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool

[jiawei at iscas dot ac.cn via Gcc-bugs]

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

--- Comment #54 from jiawei  ---
Hi Jim.

I had finished the test on the benchmark Coremark-pro.And it shows that the
patch doesn't accidentally increase code size.

This test with the args "XCMD='-c4' certify-all", and the result shows follow:

WORKLOAD RESULTS TABLE(origin gcc-10.2.0 from upstream compiled with -mabi=lp64
-march=rv64imafdc)

 MultiCore SingleCore   
Workload Name (iter/s)   (iter/s)   
Scaling
--- -- --
--
cjpeg-rose7-preset  119.05  46.08  
2.58
core  1.10   0.28  
3.93
linear_alg-mid-100x100-sp35.19   8.92  
3.95
loops-all-mid-10k-sp  1.77   0.46  
3.85
nnet_test 1.69   0.51  
3.31
parser-125k  43.01  15.62  
2.75
radix2-big-64k  257.93  56.84  
4.54
sha-test156.25  57.80  
2.70
zip-test 81.63  26.32  
3.10

MARK RESULTS TABLE

Mark NameMultiCore SingleCore   
Scaling
--- -- --
--
CoreMark-PRO   2669.64 796.33  
3.35



WORKLOAD RESULTS TABLE(Add patch one -- Auto-extend Patch)

 MultiCore SingleCore   
Workload Name (iter/s)   (iter/s)   
Scaling
--- -- --
--
cjpeg-rose7-preset  131.58  45.87  
2.87
core  1.08   0.28  
3.86
linear_alg-mid-100x100-sp35.49   8.75  
4.06
loops-all-mid-10k-sp  1.75   0.46  
3.80
nnet_test 1.68   0.51  
3.29
parser-125k  54.05  15.62  
3.46
radix2-big-64k  257.80  65.57  
3.93
sha-test153.85  57.47  
2.68
zip-test 76.92  26.32  
2.92

MARK RESULTS TABLE

Mark NameMultiCore SingleCore   
Scaling
--- -- --
--
CoreMark-PRO   2737.52 806.42  
3.39



WORKLOAD RESULTS TABLE(Add all patches -- Auto-extend Patch & untested fix to
use instead of levy's combine.c patch)

 MultiCore SingleCore   
Workload Name (iter/s)   (iter/s)   
Scaling
--- -- --
--
cjpeg-rose7-preset  120.48  45.66  
2.64
core  1.08   0.28  
3.86
linear_alg-mid-100x100-sp35.61   8.77  
4.06
loops-all-mid-10k-sp  1.76   0.46  
3.83
nnet_test 1.68   0.51  
3.29
parser-125k  46.51  15.62  
2.98
radix2-big-64k  257.33  65.18  
3.95
sha-test153.85  57.47  
2.68
zip-test 83.33  26.32  
3.17

MARK RESULTS TABLE

Mark NameMultiCore SingleCore   
Scaling
--- -- --
--
CoreMark-PRO   2691.95 805.68  
3.34

The csibe test is still modifying,and will test after it works on
riscv-gnu-toolchain.

[Bug bootstrap/98318] libcody breaks DragonFly bootstrap

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-12-21
 Ever confirmed|0   |1

--- Comment #4 from Nathan Sidwell  ---
/data/gg/libcody/configure: CONFIG_FILES+= ./Makesub: not found
/data/gg/libcody/configure: CONFIG_FILES+= ./tests/Makesub: not found

I think your shell is not understanding += -- what shell are you using?

Might be fixed by:

6d972f5183d 2020-12-16 | libcody: More dashism [Nathan Sidwell]

can you update and try again?

[Bug bootstrap/98324] [11 Regression] bootstrap broken with a LTO build configured with --enable-default-pie

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

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

--- Comment #2 from Nathan Sidwell  ---
Created attachment 49821
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49821=edit
add pie

try this patch on top of:

626b63d63a2 2020-12-21 | libcody: Add ranlib

I could reproduce the error, and this is now working for me (with the patch)

[Bug c++/98409] Installing g++-mapper-server fails when cross compiling to Windows

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #6 from Nathan Sidwell  ---
Fixed
 e4043c636ce 2020-12-21 | c++tools: Fix exe suffix [PR 98409]

[Bug bootstrap/98412] libcody does not compile with older GCC versions

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Fixed 119d7478d1a

[Bug c++/98409] Installing g++-mapper-server fails when cross compiling to Windows

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

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

commit r11-6284-ge4043c636cef8d18074ce6865ed3271283f52bb5
Author: Nathan Sidwell 
Date:   Mon Dec 21 05:32:28 2020 -0800

c++tools: Fix exe suffix [PR 98409]

I had a thinko about variable case, and, coupled with Make's behaviour
of just consing up variables out of nothing, and linux not having an
executable extension, didn't notice.

PR other/98409
c++tools/
* Makefile.in: Fix exeext variable case.

[Bug c++/98410] Default constructor generation fails on abstract class with virtual base

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-12-21

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug c++/98409] Installing g++-mapper-server fails when cross compiling to Windows

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

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

--- Comment #4 from Nathan Sidwell  ---
It's me having a thinko about case sensitivity.

[Bug c++/98353] [8/9/10/11 Regression] ICE in propagate_necessity, at tree-ssa-dce.c:1053 since r6-4886-gcda0a029f45d20f4

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

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

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

Untested fix for the gimplifier.

[Bug c++/98353] [8/9/10/11 Regression] ICE in propagate_necessity, at tree-ssa-dce.c:1053 since r6-4886-gcda0a029f45d20f4

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11 Regression] ICE in |[8/9/10/11 Regression] ICE
   |propagate_necessity, at |in propagate_necessity, at
   |tree-ssa-dce.c:1053 since   |tree-ssa-dce.c:1053 since
   |r6-4886-gcda0a029f45d20f4   |r6-4886-gcda0a029f45d20f4
 Status|NEW |ASSIGNED
   Target Milestone|--- |8.5
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

[Bug bootstrap/98412] libcody does not compile with older GCC versions

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
We should support GCC 4.8 and later as the system compiler.

[Bug bootstrap/98412] New: libcody does not compile with older GCC versions

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

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

Bug ID: 98412
   Summary: libcody does not compile with older GCC versions
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ebotcazou at gcc dot gnu.org
  Target Milestone: ---

This fails in libcody:

g++ -std=c++11 -g -O -fno-enforce-eh-specs -fno-stack-protector
-fno-threadsafe-statics -fno-exceptions -fno-rtti
-fdebug-prefix-map=/homes/botcazou/gcc-head/src/libcody/= -W -Wall -include
config.h -I/homes/botcazou/gcc-head/src/libcody \
  -MMD -MP -MF buffer.d -c -o buffer.o
/homes/botcazou/gcc-head/src/libcody/buffer.cc
/homes/botcazou/gcc-head/src/libcody/buffer.cc: In member function 'void
Cody::Detail::MessageBuffer::AppendInteger(unsigned int)':
/homes/botcazou/gcc-head/src/libcody/buffer.cc:149:18: error: 'to_string' is
not a member of 'std'
   std::string v (std::to_string (u));
  ^
gmake[3]: *** [buffer.o] Error 1

It's with GCC 4.9.4 so not very old (< 5 years).

[Bug c++/98353] [9/10/11 Regression] ICE in propagate_necessity, at tree-ssa-dce.c:1053 since r6-4886-gcda0a029f45d20f4

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
On the FE side, I think this can be fixed with:
--- gcc/cp/init.c.jj2020-12-09 09:03:38.270054654 +0100
+++ gcc/cp/init.c   2020-12-21 13:05:33.137218177 +0100
@@ -187,7 +187,7 @@ build_zero_init_1 (tree type, tree nelts
   else if (NULLPTR_TYPE_P (type))
 init = build_int_cst (type, 0);
   else if (SCALAR_TYPE_P (type))
-init = fold (convert (type, integer_zero_node));
+init = cp_fold_rvalue (convert (type, integer_zero_node));
   else if (RECORD_OR_UNION_CODE_P (TREE_CODE (type)))
 {
   tree field;
It is unclear to me why it uses so arcane way of emitting zero constants, can't
just build_zero_cst (type); do that?, but if it has to, the complex types can't
be handled by simple fold as fold is not recursive, and convert emits
COMPLEX_EXPR with FLOAT_EXPR of 0 operands, so one needs to fold those operands
and only then fold the COMPLEX_EXPR.

I guess there is some bug on the gimplifier side too, it shouldn't ICE even
when such COMPLEX_EXPRs are not simplified.

[Bug c++/98348] GCC 10.2 AVX512 Mask regression from GCC 9

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Hongtao.liu  ---
(In reply to Jakub Jelinek from comment #11)
> I'm not sure about the knot changes, isn't that too risky at least at this
> point?
> I mean, can't we instead just match what knot emits?
> 
As indicated in
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552205.html, we support
bitwise operator for avx512 masks, so i believe the change is fine for GCC11,
but not suitable for GCC10. 

For backport convenience, I'll make a version that matches the knot.

> As for the new predicate, I think we should check CONST_DOUBLE_AS_FLOAT_P
> (op)
> before trying to do the lowpart_subreg, perhaps even check if the
> CONST_DOUBLE is NaN if it can be done cheaply before doing the more
> expensive lowpart_subreg.

Yes.

[Bug target/98399] x86: Awful code generation for shifting vectors

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #2)
> It's the problem of veclower
>

The root cause is missing expander of vashrv16qi, although x86 don't have
vector int8 shift instruction, it can be emulated by vector int16 shift.

[Bug target/98399] x86: Awful code generation for shifting vectors

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
It's the problem of veclower

test1.c.180t.veclower21
;; Function f (f, funcdef_no=0, decl_uid=3990, cgraph_uid=1, symbol_order=0)

U f (U u)
{
  vector(16) char _1;
  U _3;
  char _5;
  char _6;
  unsigned int _7;
  char _8;
  char _9;
  char _10;
  unsigned int _11;
  char _12;
  char _13;
  char _14;
  unsigned int _15;
  char _16;
  char _17;
  char _18;
  unsigned int _19;
  char _20;
  char _21;
  char _22;
  unsigned int _23;
  char _24;
  char _25;
  char _26;
  unsigned int _27;
  char _28;
  char _29;
  char _30;
  unsigned int _31;
  char _32;
  char _33;
  char _34;
  unsigned int _35;
  char _36;
  char _37;
  char _38;
  unsigned int _39;
  char _40;
  char _41;
  char _42;
  unsigned int _43;
  char _44;
  char _45;
  char _46;
  unsigned int _47;
  char _48;
  char _49;
  char _50;
  unsigned int _51;
  char _52;
  char _53;
  char _54;
  unsigned int _55;
  char _56;
  char _57;
  char _58;
  unsigned int _59;
  char _60;
  char _61;
  char _62;
  unsigned int _63;
  char _64;
  char _65;
  char _66;
  unsigned int _67;
  char _68;

   [local count: 1073741824]:
  _1 = u_2(D) & { 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 };
  _5 = BIT_FIELD_REF ;
  _6 = BIT_FIELD_REF <_1, 8, 0>;
  _7 = (unsigned int) _6;
  _8 = _5 >> _7;
  _9 = BIT_FIELD_REF ;
  _10 = BIT_FIELD_REF <_1, 8, 8>;
  _11 = (unsigned int) _10;
  _12 = _9 >> _11;
  _13 = BIT_FIELD_REF ;
  _14 = BIT_FIELD_REF <_1, 8, 16>;
  _15 = (unsigned int) _14;
  _16 = _13 >> _15;
  _17 = BIT_FIELD_REF ;
  _18 = BIT_FIELD_REF <_1, 8, 24>;
  _19 = (unsigned int) _18;
  _20 = _17 >> _19;
  _21 = BIT_FIELD_REF ;
  _22 = BIT_FIELD_REF <_1, 8, 32>;
  _23 = (unsigned int) _22;
  _24 = _21 >> _23;
  _25 = BIT_FIELD_REF ;
  _26 = BIT_FIELD_REF <_1, 8, 40>;
  _27 = (unsigned int) _26;
  _28 = _25 >> _27;
  _29 = BIT_FIELD_REF ;
  _30 = BIT_FIELD_REF <_1, 8, 48>;
  _31 = (unsigned int) _30;
  _32 = _29 >> _31;
  _33 = BIT_FIELD_REF ;
  _34 = BIT_FIELD_REF <_1, 8, 56>;
  _35 = (unsigned int) _34;
  _36 = _33 >> _35;
  _37 = BIT_FIELD_REF ;
  _38 = BIT_FIELD_REF <_1, 8, 64>;
  _39 = (unsigned int) _38;
  _40 = _37 >> _39;
  _41 = BIT_FIELD_REF ;
  _42 = BIT_FIELD_REF <_1, 8, 72>;
  _43 = (unsigned int) _42;
  _44 = _41 >> _43;
  _45 = BIT_FIELD_REF ;
  _46 = BIT_FIELD_REF <_1, 8, 80>;
  _47 = (unsigned int) _46;
  _48 = _45 >> _47;
  _49 = BIT_FIELD_REF ;
  _50 = BIT_FIELD_REF <_1, 8, 88>;
  _51 = (unsigned int) _50;
  _52 = _49 >> _51;
  _53 = BIT_FIELD_REF ;
  _54 = BIT_FIELD_REF <_1, 8, 96>;
  _55 = (unsigned int) _54;
  _56 = _53 >> _55;
  _57 = BIT_FIELD_REF ;
  _58 = BIT_FIELD_REF <_1, 8, 104>;
  _59 = (unsigned int) _58;
  _60 = _57 >> _59;
  _61 = BIT_FIELD_REF ;
  _62 = BIT_FIELD_REF <_1, 8, 112>;
  _63 = (unsigned int) _62;
  _64 = _61 >> _63;
  _65 = BIT_FIELD_REF ;
  _66 = BIT_FIELD_REF <_1, 8, 120>;
  _67 = (unsigned int) _66;
  _68 = _65 >> _67;
  _3 = {_8, _12, _16, _20, _24, _28, _32, _36, _40, _44, _48, _52, _56, _60,
_64, _68};
  return _3;

}

[Bug c++/98348] GCC 10.2 AVX512 Mask regression from GCC 9

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

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

--- Comment #11 from Jakub Jelinek  ---
I'm not sure about the knot changes, isn't that too risky at least at this
point?
I mean, can't we instead just match what knot emits?

As for the new predicate, I think we should check CONST_DOUBLE_AS_FLOAT_P (op)
before trying to do the lowpart_subreg, perhaps even check if the CONST_DOUBLE
is NaN if it can be done cheaply before doing the more expensive
lowpart_subreg.

[Bug c++/98348] GCC 10.2 AVX512 Mask regression from GCC 9

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Hongtao.liu  ---
Created attachment 49819
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49819=edit
Incremental to gcc11-pr99348.patch

Update patch.

[Bug fortran/98411] New: [10/11] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables

[vladimir.fuka at gmail dot com via Gcc-bugs]

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

Bug ID: 98411
   Summary: [10/11] Pointless: Array larger than
‘-fmax-stack-var-size=’, moved from stack to static
storage for main program variables
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.fuka at gmail dot com
  Target Milestone: ---

This program


program p
  dimension a(10)
  call random_number(a)
  print *,a
end

causes

static.f90:2:13:

2 |   dimension a(10)
  | 1
Warning: Array ‘a’ at (1) is larger than limit set by ‘-fmax-stack-var-size=’,
moved from stack to static storage. This makes the procedure unsafe when called
recursively, or concurrently from multiple threads. Consider using
‘-frecursive’, or increase the ‘-fmax-stack-var-size=’ limit, or change the
code to use an ALLOCATABLE array. [-Wsurprising]


This warning is pointless because there are no procedures in the code and main
program arrays are SAVE already. There is no point using -frecursive or doing
anything to the stack. It causes active harm by causing confusion
https://stackoverflow.com/questions/65384213/using-very-large-arrays-in-fortran-gfortran/65391732#65391732

[Bug c++/98348] GCC 10.2 AVX512 Mask regression from GCC 9

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Hongtao.liu  ---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 49806 [details]
> gcc11-pr98348.patch
> 
> So, if we go for GCC11 the way of pre-reload define_insn_and_split, this is
> some incremental untested progress on your patch (just the sse.md part of
> it).
> Changes:
> 1) it is undesirable to put SUBREGs on the SET_DEST side, as it prevents
> other optimizations later on
> 2) I don't see the point on the TARGET_AVX512BW ||, the insn in the end is
> plain AVX or AVX2 or SSE4* etc. one
> 3) handles also the const0 vector_all_ones order
> 4) for commutative cases allows any operand order, for others ensures the
> right

The bellow pattern should be equivilent to const0 vector_all_ones order, but
the generic part didn't simplify it, so i made a bit adjustment to those
patterns, also some changes in ix86_expand_sse_movcc to generate common NOT
operator instead of gen_knot which has UNSPEC_MASKOP inside, so the
combine can do the right thing.

Successfully matched this instruction:
(set (reg:V16QI 82 [  ])
(vec_merge:V16QI (const_vector:V16QI [
(const_int -1 [0x]) repeated x16
])
(const_vector:V16QI [
(const_int 0 [0]) repeated x16
])
(not:HI (unspec:HI [
(reg:V16QI 89)
(reg:V16QI 90)
(const_int 4 [0x4])
] UNSPEC_PCMP

> one of the operands is register
> 5) handles also the LE case by swapping the comparison operands
> 
> The patch doesn't handle the cases where based on the comparison one sets up
> floating vectors, as can be seen e.g. in:
> typedef float V128 __attribute__ ((vector_size(16)));
> typedef float V256 __attribute__ ((vector_size(32)));
> typedef float V512 __attribute__ ((vector_size(64)));
> 
> V128
> foo (V128 x)
> {
>   const union U { unsigned u; float f; } u = { -1U };
>   return x > 0.0f ? u.f : 0.0f;
> }
> 
> V256
> bar (V256 x)
> {
>   const union U { unsigned u; float f; } u = { -1U };
>   return x > 0.0f ? u.f : 0.0f;
> }

I'm adding a new predicate named float_vector_all_ones_operand and
corresponding define_insn_and_split to handle it.

Successfully matched this instruction:
(set (reg:V4SF 82 [  ])
(vec_merge:V4SF (mem/u/c:V4SF (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 
S16 A128])
(const_vector:V4SF [
(const_double:SF 0.0 [0x0.0p+0]) repeated x4
])
(unspec:QI [
(reg:V4SF 84)
(reg:V4SF 88)
(const_int 1 [0x1])
] UNSPEC_PCMP)))

[Bug rtl-optimization/98287] [10/11 Regression] ICE: in expand_expr_real_2, at expr.c:10000 with -O2 -fno-tree-ccp -fno-tree-forwprop

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #2 from Zdenek Sojka  ---
Created attachment 49818
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49818=edit
another testcase

$ x86_64-pc-linux-gnu-gcc -Og -fipa-cp another_testcase.c
during RTL pass: expand
another_testcase.c: In function 'bar.constprop':
another_testcase.c:7:23: internal compiler error: in expand_expr_real_2, at
expr.c:1
7 |   return v << (s & 3) >> (s & 3);
  |  ~^~
0x667803 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/repo/gcc-trunk/gcc/expr.c:1
0xc280cb expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.c:10201
0xaf2b5b expand_expr
/repo/gcc-trunk/gcc/expr.h:282
0xaf2b5b expand_return
/repo/gcc-trunk/gcc/cfgexpand.c:3764
0xaf2b5b expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.c:3873
0xaf2b5b expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:3999
0xaf80fb expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.c:6036
0xaf9c76 execute
/repo/gcc-trunk/gcc/cfgexpand.c:6720
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/98410] New: Default constructor generation fails on abstract class with virtual base

[thelordlucas at gmail dot com via Gcc-bugs]

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

Bug ID: 98410
   Summary: Default constructor generation fails on abstract class
with virtual base
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thelordlucas at gmail dot com
  Target Milestone: ---

Hi all,

The following code fails to compile on GCC > 7:

class Base {
int x;
public:
Base(int x): x{x} {}
virtual void f() = 0;
};

class Derived : public virtual Base  {
  public:
Derived() = default;
};

class Concrete: public Derived {
public:
Concrete(): Base{42} {}
void f() override {}
};

Link to code: https://godbolt.org/z/bn1EY6


It says that the Derived() constructor is deleted (error: use of deleted
function 'Derived::Derived()'). Using Derived() {}; it compiles file. 

As the user eerorika points out in
https://stackoverflow.com/questions/65287323/strange-default-empty-constructor-on-a-virtual-inheritance-behaviour-on-gcc
the constructor Derived() should not have been deleted, since it is also
abstract and doesn't fall in any default constructor deletion rule.

Maybe related, it yielded "internal compiler error: in
maybe_explain_implicit_delete, at cp/method.c:2671" if I add the noexcept to
the deleted constructor:

class Base {
int x;
public:
Base(int x): x{x} {}
virtual void f() = 0;
};

class Derived : public virtual Base  {
  public:
Derived() noexcept = default;
};

class Concrete: public Derived {
public:
Concrete(): Base{42} {}
void f() override {}
};

Link to code: https://godbolt.org/z/5fx8Ph

I tested clang trunk, and it compiles both versions.

Thanks!

[Bug c++/98409] Installing g++-mapper-server fails when cross compiling to Windows

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Ah, no weird at all.
It should have been
exeext = @EXEEXT@
instead, if @EXEEXT@ is what one wants to use.  For crosses, especially
canadian, bet the exeext needed is the host exeext, not sure which one
configure computes here.
E.g. gcc/Makefile.in has separate:
gcc/Makefile.in:exeext = @host_exeext@
gcc/Makefile.in:build_exeext = @build_exeext@

[Bug c++/98409] Installing g++-mapper-server fails when cross compiling to Windows

[markus.boeck02 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Markus Böck  ---
That is indeed weird.

At the top of the Makefile it says:
EXEEXT := .exe

and further down in the Makefile:

g++-mapper-server$(exeext): $(MAPPER.O) $(CODYLIB)
+$(CXX) $(LDFLAGS) -o $@ $^ $(VERSION.O) $(LIBIBERTY)

# copy to gcc dir so tests there can run
all::../gcc/g++-mapper-server$(exeext)

../gcc/g++-mapper-server$(exeext): g++-mapper-server$(exeext)
$(INSTALL) $< $@

install::
$(SHELL) $(srcdir)/../mkinstalldirs $(DESTDIR)$(libexecsubdir)
$(INSTALL_PROGRAM) g++-mapper-server$(exeext)
$(DESTDIR)$(libexecsubdir)

which seems correct to me?

Yet running make gives:

make[2]: Entering directory
'/mnt/c/GCC-Build-Array/gcc/build-target-x86_64/c++tools'  
  #
--enable-maintainer-mode to rebuild ../../c++tools/config.h.in, or make
MAINTAINER=touch   
x86_64-w64-mingw32-g++-10 -static-libstdc++
-static-libgcc -L/mnt/c/GCC-Build/NewestLinux/Libraries/lib
-Wl,--stack,12582912 -o g++-mapper-server server.o resolver.o
../libcody/libcody.a ../gcc/version.o ../libiberty/libiberty.a 
   
  /usr/bin/install -c
g++-mapper-server ../gcc/g++-mapper-server 
   
  /usr/bin/install: cannot stat 'g++-mapper-server': No such file or
directory  
   Makefile:97: recipe for target
'../gcc/g++-mapper-server' failed  
  
make[2]: *** [../gcc/g++-mapper-server] Error 1
   
  make[2]: Leaving directory
'/mnt/c/GCC-Build-Array/gcc/build-target-x86_64/c++tools'  
  
Makefile:11807: recipe for target 'all-c++tools' failed
   
  make[1]: *** [all-c++tools] Error 2  
   
make[1]: Leaving directory
'/mnt/c/GCC-Build-Array/gcc/build-target-x86_64'   
  
Makefile:980: recipe for target 'all' failed   
   
  make: *** [all] Error 2

I am using GNU Make 4.1 on an Ubuntu 18.04 WSL 1 Host in case that could be
important

[Bug rtl-optimization/98403] [11 Regression] ICE: in add_def, at rtl-ssa/accesses.cc:837 with -Og -march=goldmont -fPIC -fcse-follow-jumps -fipa-ra -mforce-indirect-call since r11-6188-g0b76990a9d75d9

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

[Bug c++/98409] Installing g++-mapper-server fails when cross compiling to Windows

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
That is weird,
$ grep mapper-server Makefile.in 
rm -f g++-mapper-server$(exeext)
all::g++-mapper-server$(exeext)
g++-mapper-server$(exeext): $(MAPPER.O) $(CODYLIB)
all::../gcc/g++-mapper-server$(exeext)
../gcc/g++-mapper-server$(exeext): g++-mapper-server$(exeext)
$(INSTALL_PROGRAM) g++-mapper-server$(exeext)
$(DESTDIR)$(libexecsubdir)

What is exeext set for you in c++tools/Makefile ?

[Bug fortran/98408] Character lengths for allocatable character arrays

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #1 from Paul Thomas  ---
Hi Thomas,

>From gfc_conv_intrinsic_sizeof:

  if (arg->ts.type == BT_CHARACTER)
byte_size = size_of_string_in_bytes (arg->ts.kind,
argse.string_length);
  else
{
  if (arg->rank == 0)
byte_size = TREE_TYPE (build_fold_indirect_ref_loc (input_location,
argse.expr));
  else
byte_size = gfc_get_element_type (TREE_TYPE (argse.expr));
  byte_size = fold_convert (gfc_array_index_type,
size_in_bytes (byte_size));
}
}

ie. characters are treated separately.

The problem is that gfc_get_element_type will come back with void* (or perhaps
void if TYPE_STRING_FLAG is not set) because of the cast in the allocation:
a.data = (void * restrict) __builtin_malloc (50);

which is what GFC_TYPE_ARRAY_DATAPTR_TYPE is coming back with.

I think that you will have to either interrogate the dtype for the element
length, use the span field or se->string_length if you know the kind.

Not so much a bug as a 'feature', I'm afraid.

Paul

[Bug c++/98409] New: Installing g++-mapper-server fails when cross compiling to Windows

[markus.boeck02 at gmail dot com via Gcc-bugs]

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

Bug ID: 98409
   Summary: Installing g++-mapper-server fails when cross
compiling to Windows
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus.boeck02 at gmail dot com
  Target Milestone: ---

Current version of trunk GCC (1b021bbd85a79c9d16c1359cbc23b608685dfd9f) fails
to compile when cross compiling GCC to Windows due to a install command trying
to install g++-mapper-server even though the file is named
g++-mapper-server.exe which does exist. 

 make:
/usr/bin/install: cannot stat 'g++-mapper-server': No such file or directory
make[2]: *** [../gcc/g++-mapper-server] Error 1
make[1]: *** [all-c++tools] Error 2
make[1]: *** Waiting for unfinished jobs

Configure comment used:
../configure --target=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--disable-bootstrap --enable-libstdcxx-debug --with-tune=znver1
--prefix=/mnt/c/GCC --with-sysroot=/mnt/c/GCC-Build/NewestLinux
--with-build-sysroot=/mnt/c/GCC-Build/NewestLinux --disable-libstdcxx-pch
--disable-multilib --enable-libgomp --with-cross-host
--with-libiconv-prefix=/mnt/c/GCC-Build/NewestLinux/Libraries
--disable-libstdcxx-verbose --enable-languages=c,c++,fortran,lto,objc,obj-c++
--disable-nls --disable-win32-registry --enable-shared --with-gnu-as
--with-gnu-ld --enable-threads=posix --program-suffix=-11
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-__cxa_atexit --enable-plugin --program-prefix=

[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1

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

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

--- Comment #21 from Jakub Jelinek  ---
Ah, missed that this isn't any artificial parm like in C++, so guess the
primary question is why the two class array dummy arguments share anything
between the two procedures.

[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1

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

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

--- Comment #20 from Dominique d'Humieres  ---
> It's my impression that the code compiles also with -O2
> or -O3, which might be an interim solution until this
> bug is fixed.

I only get a different ICE:

   19 |   subroutine fun1(this, a)
  | ^
internal compiler error: in set_parm_rtl, at cfgexpand.c:1401

[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1

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

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

--- Comment #19 from Jakub Jelinek  ---
Seems each function has properly its own this PARM_DECL, but the fun2 body
refers to the fun1 this PARM_DECL, which is invalid when fun2 is not nested in
fun1.

This wrong this PARM_DECL reference is added during:
#1  0x01909a57 in build1 (code=INDIRECT_REF, type=, node=)
at ../../gcc/tree.c:4786
#2  0x00ebcf48 in build1_loc (loc=91200, code=INDIRECT_REF,
type=, 
arg1=) at ../../gcc/tree.h:4382
#3  0x00f01746 in build_fold_indirect_ref_loc (loc=91200, t=) at ../../gcc/fold-const.c:15930
#4  0x00b6c166 in gfc_maybe_dereference_var (sym=0x38228a0,
var=, descriptor_only_p=false, 
is_classarray=false) at ../../gcc/fortran/trans-expr.c:2787
#5  0x00b6c97f in gfc_conv_variable (se=0x7fffd100, expr=0x37c0400)
at ../../gcc/fortran/trans-expr.c:2945
#6  0x00b80aa3 in gfc_conv_expr (se=0x7fffd100, expr=0x37c0400) at
../../gcc/fortran/trans-expr.c:8864
#7  0x00b80ba6 in gfc_conv_expr_val (se=0x7fffd100, expr=0x37c0400)
at ../../gcc/fortran/trans-expr.c:8909
#8  0x00b80c55 in gfc_conv_expr_type (se=0x7fffd100,
expr=0x37c0400, type=)
at ../../gcc/fortran/trans-expr.c:8923
#9  0x00b2dceb in gfc_trans_dummy_array_bias (sym=0x3822be0,
tmpdesc=, block=0x7fffd430)
at ../../gcc/fortran/trans-array.c:6753
#10 0x00b57286 in gfc_trans_deferred_vars (proc_sym=0x3821ac0,
block=0x7fffd430) at ../../gcc/fortran/trans-decl.c:4829
#11 0x00b5e212 in gfc_generate_function_code (ns=0x3825570) at
../../gcc/fortran/trans-decl.c:6984
#12 0x00b19f9e in gfc_generate_module_code (ns=0x381c790) at
../../gcc/fortran/trans.c:2319
The proc_sym in the gfc_trans_deferred_vars above is fun2.

Already in gfc_trans_deferred_vars'
6638  as = IS_CLASS_ARRAY (sym) ? CLASS_DATA (sym)->as : sym->as;

the CLASS_DATA (sym)->as
contains:
(gdb) p debug_tree (as->upper[0]->symtree->n.sym->backend_decl)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea216498 fields  context 
reference_to_this  chain >
unsigned restrict DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea216690>
readonly unsigned DI passed-by-reference pr92605.f90:17:17 size
 unit-size 
align:64 warn_if_not_align:0 context 
arg-type  chain >
i.e. the fun1's this PARM_DECL, even when this is during processing of fun2.

I don't know the class code in the fortran FE at all, but as has been said, one
can't just use PARM_DECLs of some other function except for nested functions,
so perhaps one need to use some magic sym that will translate to the this
parameter of the current method, or just detect uses of this symbol from other
method of the same class and replace it with the right one, whatever.

[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #18 from Jakub Jelinek  ---
#c0 started to ICE with r6-202-gf3b0bb7a560be0f05b09287401a10c4c4b12cfc6

[Bug tree-optimization/98393] [11 Regression] valgrind error for ./gcc.target/m68k/pr52573.c since r11-5928-gfc7b4248172561a9

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #9 from David Binderman  ---
Also from the testsuite, files 

./gcc.c-torture/execute/20040709-1.c
./gcc.dg/torture/pr98235.c
./gcc.dg/tree-ssa/loop-34.c

with -O3 show the same problem.

[Bug c++/98383] internal compiler error: in make_decl_rtl, at varasm.c:1342

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

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

--- Comment #4 from Jakub Jelinek  ---
Fixed for gcc 11 so far, queued for backporting.

[Bug c/98404] ldist might punt on too large expressions for detected patterns with -Os

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|Compiler emits unexpected   |ldist might punt on too
   |function call that may  |large expressions for
   |cause security problems |detected patterns with -Os
 Ever confirmed|0   |1
 CC||rguenth at gcc dot gnu.org
   Last reconfirmed||2020-12-21
 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #3 from Jakub Jelinek  ---
Well, for -Os I guess we should reopen this for the case where the expressions
needed for the detected patterns look too big.
ldist in this case turns the loop into:
  _34 = _3 + -1;
  _33 = (unsigned int) _34;
  _32 = (sizetype) _33;
  _35 = _32 * 8;
  _36 = _3 > 0 ? _35 : 0;
  _37 = (long unsigned int) nm_25;
  _38 = _37 * 8;
  _39 = (sizetype) _33;
  _40 = 1 - _39;
  _41 = _40 * 8;
  _42 = _3 > 0 ? _41 : 8;
  _43 = _38 + _42;
  _44 = p_20 + _43;
  _45 = (long unsigned int) nm_25;
  _46 = _45 * 8;
  _47 = (unsigned int) _34;
  _48 = (sizetype) _47;
  _49 = 1 - _48;
  _50 = _49 * 8;
  _51 = _3 > 0 ? _50 : 8;
  _52 = _46 + _51;
  _53 = _52 + 18446744073709551608;
  _54 = p_20 + _53;
  __builtin_memmove (_44, _54, _36);
and while some of it is optimized later, we still have:
  _4 = (long unsigned int) nm_25;
  _5 = _4 * 8;
  _6 = p_20 + _5;
  _33 = (unsigned int) nm_25;
  _32 = (sizetype) _33;
  _35 = _32 * 8;
  _36 = _3 > 0 ? _35 : 0;
  _40 = 1 - _32;
  _41 = _40 * 8;
  _42 = _3 > 0 ? _41 : 8;
  _43 = _5 + _42;
  _44 = p_20 + _43;
  _9 = _5 + 18446744073709551608;
  _53 = _9 + _42;
  _54 = p_20 + _53;
in *.optimized.

[Bug tree-optimization/98407] [11 Regression] ICE: Aborted (in constant_byte_string; free(): invalid pointer) since r11-6271-g69165332a914f116

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed, sorry.

[Bug tree-optimization/98407] [11 Regression] ICE: Aborted (in constant_byte_string; free(): invalid pointer) since r11-6271-g69165332a914f116

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

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

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

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

commit r11-6281-gd8aeee11af715507e61464d390f14e4f4fde61b0
Author: Jakub Jelinek 
Date:   Mon Dec 21 10:14:46 2020 +0100

fold-const: Fix up a buffer overflow in native_encode_initializer [PR98407]

For flexible array members we need to incrementally clear just from
ptr + total_bytes up to new ptr + total_bytes, but memset has been called
with the length from ptr, so was missing - total_bytes.  Additionally,
in this code off is guaranteed to be -1 and thus o 0, so don't bother
pretending
we could handle anything else, it would be more complicated than that.

2020-12-21  Jakub Jelinek  

PR tree-optimization/98407
* fold-const.c (native_encode_initializer): When handling flexible
array members, fix up computation of length for memset.  Also
remove
" - o" as o is always guaranteed to be 0 in this code path.

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

[Bug tree-optimization/98393] [11 Regression] valgrind error for ./gcc.target/m68k/pr52573.c since r11-5928-gfc7b4248172561a9

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

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

--- Comment #8 from Martin Liška  ---
Happens when:

(gdb) p node
$4 = (slp_tree) 0x0

[Bug tree-optimization/98407] [11 Regression] ICE: Aborted (in constant_byte_string; free(): invalid pointer) since r11-6271-g69165332a914f116

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Component|c   |tree-optimization
 Status|NEW |ASSIGNED

[Bug tree-optimization/98393] [11 Regression] valgrind error for ./gcc.target/m68k/pr52573.c since r11-5928-gfc7b4248172561a9

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Component|c   |tree-optimization
   Last reconfirmed||2020-12-21
 Status|UNCONFIRMED |NEW
  Known to fail||11.0
Summary|new valgrind error for  |[11 Regression] valgrind
   |./gcc.target/m68k/pr52573.c |error for
   ||./gcc.target/m68k/pr52573.c
   ||since
   ||r11-5928-gfc7b4248172561a9
  Known to work||10.2.0
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |11.0
Version|unknown |11.0

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

$ cat m68.i
struct {
  int : 12, : 11, k : 9;
  long l;
} sH;

int sH_3___trans_tmp_1, sH_3_i, sH_3_v;

unsigned sH_3_s;

void
sH_3() {
  char *p = (char *)
  sH_3_i = 0;
  for (; sH_3_i < sizeof(sH); ++sH_3_i) {
sH_3_s *= 515245;
sH_3___trans_tmp_1 = sH_3_s % 2048;
*p++ = sH_3___trans_tmp_1;
  }
  sH.k = sH_3_v;
}

$ ./xgcc -B. m68.i -c -O3
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:2486:16: runtime error: load
of value 80, which is not a valid value for type 'bool'
#0 0x2e89cbf in vect_build_slp_instance
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:2486
#1 0x2e8b237 in vect_analyze_slp_instance
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:2655
#2 0x2e8a0a2 in vect_build_slp_instance
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:2524
#3 0x2e8b237 in vect_analyze_slp_instance
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:2655
#4 0x2e8b4e5 in vect_analyze_slp(vec_info*, unsigned int)
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:2687
#5 0x2e9ac0c in vect_slp_analyze_bb_1
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:4507
#6 0x2e9b968 in vect_slp_region
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:4619
#7 0x2e9d7d1 in vect_slp_bbs
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:4767
#8 0x2e9e167 in vect_slp_function(function*)
/home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:4853
#9 0x2ee0503 in execute
/home/marxin/Programming/gcc2/gcc/tree-vectorizer.c:1449
#10 0x200b8a1 in execute_one_pass(opt_pass*)
/home/marxin/Programming/gcc2/gcc/passes.c:2567
#11 0x200c229 in execute_pass_list_1
/home/marxin/Programming/gcc2/gcc/passes.c:2656
#12 0x200c2de in execute_pass_list_1
/home/marxin/Programming/gcc2/gcc/passes.c:2657
#13 0x200c2de in execute_pass_list_1
/home/marxin/Programming/gcc2/gcc/passes.c:2657
#14 0x200c37c in execute_pass_list(function*, opt_pass*)
/home/marxin/Programming/gcc2/gcc/passes.c:2667
#15 0x10e5be7 in cgraph_node::expand()
/home/marxin/Programming/gcc2/gcc/cgraphunit.c:1829
#16 0x10e753f in expand_all_functions
/home/marxin/Programming/gcc2/gcc/cgraphunit.c:1997
#17 0x10e9669 in symbol_table::compile()
/home/marxin/Programming/gcc2/gcc/cgraphunit.c:2361
#18 0x10e9ff6 in symbol_table::finalize_compilation_unit()
/home/marxin/Programming/gcc2/gcc/cgraphunit.c:2542
#19 0x249ec80 in compile_file
/home/marxin/Programming/gcc2/gcc/toplev.c:482
#20 0x24a74c3 in do_compile /home/marxin/Programming/gcc2/gcc/toplev.c:2193
#21 0x24a7ac6 in toplev::main(int, char**)
/home/marxin/Programming/gcc2/gcc/toplev.c:2332
#22 0x5146fda in main /home/marxin/Programming/gcc2/gcc/main.c:39
#23 0x76d2a151 in __libc_start_main (/lib64/libc.so.6+0x28151)
#24 0xa0ba2d in _start (/dev/shm/objdir2/gcc/cc1+0xa0ba2d)

And yes, it started with r11-5928-gfc7b4248172561a9.

[Bug c/98407] [11 Regression] ICE: Aborted (in constant_byte_string; free(): invalid pointer) since r11-6271-g69165332a914f116

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
Summary|[11 Regression] ICE:|[11 Regression] ICE:
   |Aborted (in |Aborted (in
   |constant_byte_string;   |constant_byte_string;
   |free(): invalid pointer)|free(): invalid pointer)
   ||since
   ||r11-6271-g69165332a914f116
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Known to work||10.2.0
 Ever confirmed|0   |1
   Last reconfirmed||2020-12-21
  Known to fail||11.0
   Target Milestone|--- |11.0

--- Comment #1 from Martin Liška  ---
Started with r11-6271-g69165332a914f116. One can easily see that with valgrind.
Thanks for the report.

[Bug bootstrap/98318] libcody breaks DragonFly bootstrap

[hliu at amperecomputing dot com via Gcc-bugs]

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

Hao Liu  changed:

   What|Removed |Added

 CC||hliu at amperecomputing dot com

--- Comment #3 from Hao Liu  ---
We can reproduce the failure on CentOS. But Ubuntu can pass.

This failure is related to following files and code:

---
1. gcc/Makefile.in

CODYLIB = ../libcody/libcody.a
BACKEND = libbackend.a main.o libcommon-target.a libcommon.a \
$(CPPLIB) $(CODYLIB) $(LIBDECNUMBER)


2. gcc/gcc/c/Make-lang.in

cc1-checksum.c : build/genchecksum$(build_exeext) checksum-options \
$(C_OBJS) $(BACKEND) $(LIBDEPS) 
---

It should have some dependence problems, as "libcody.a" must be ready before
building cc1-checksum.c. But don't know how to fix this problem, as I'm not
farmiliar with Makefile :(

[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1

[drikosev at gmail dot com via Gcc-bugs]

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

Ev Drikos  changed:

   What|Removed |Added

 CC||drikosev at gmail dot com

--- Comment #17 from Ev Drikos  ---
Created attachment 49817
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49817=edit
module + driver

(In reply to Dominique d'Humieres from comment #12)
> The following test compiles (swapping fun1 and fun2):
> ...

Hello,

It's my impression that the code compiles also with -O2
or -O3, which might be an interim solution until this
bug is fixed.

Hope this helps,
Ev. Drikos

[Bug rtl-optimization/98403] [11 Regression] ICE: in add_def, at rtl-ssa/accesses.cc:837 with -Og -march=goldmont -fPIC -fcse-follow-jumps -fipa-ra -mforce-indirect-call since r11-6188-g0b76990a9d75d9

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
  Component|target  |rtl-optimization

[Bug target/98403] [11 Regression] ICE: in add_def, at rtl-ssa/accesses.cc:837 with -Og -march=goldmont -fPIC -fcse-follow-jumps -fipa-ra -mforce-indirect-call since r11-6188-g0b76990a9d75d97b

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[11 Regression] ICE: in |[11 Regression] ICE: in
   |add_def, at |add_def, at
   |rtl-ssa/accesses.cc:837 |rtl-ssa/accesses.cc:837
   |with -Og -march=goldmont|with -Og -march=goldmont
   |-fPIC -fcse-follow-jumps|-fPIC -fcse-follow-jumps
   |-fipa-ra|-fipa-ra
   |-mforce-indirect-call   |-mforce-indirect-call since
   ||r11-6188-g0b76990a9d75d97b
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-12-21
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||richard.sandiford at arm dot 
com

--- Comment #1 from Martin Liška  ---
Started with r11-6188-g0b76990a9d75d97b.

[Bug fortran/98408] New: Character lengths for allocatable character arrays

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

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

Bug ID: 98408
   Summary: Character lengths for allocatable character arrays
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Consider

program main
  character (len=:), allocatable :: a(:)
  allocate (character(len=10) :: a(5))
end program main

This yields (in the tree dump)

  D.3941 = (bitsizetype) (sizetype) NON_LVALUE_EXPR <.a> * 8;
  D.3942 = (sizetype) NON_LVALUE_EXPR <.a>;
  a.data = 0B;
  {
integer(kind=4) overflow.0;
logical(kind=4) not_prev_allocated.1;

.a = 10;

And later, if you use

size_in_bytes (gfc_get_element_type (TREE_TYPE(se->expr)))

you get an undefined variable.

Strange...

[Bug libgcc/98395] libgcc_s.so.1 almost 10x bigger in gcc-10.2 than gcc-9.2

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
I see on openSUSE Tumbleweed the following:

$ du -hs /usr/lib64/gcc/x86_64-suse-linux/9/libgcc.a
7.3M/usr/lib64/gcc/x86_64-suse-linux/9/libgcc.a
$ du -hs /usr/lib64/gcc/x86_64-suse-linux/10/libgcc.a
5.3M/usr/lib64/gcc/x86_64-suse-linux/10/libgcc.a