[Bug rtl-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #8 from Richard Biener  ---
So w/ -Ofast -march=znver2 I get a runtime of 130 seconds, when I add
-mtune-ctrl=^inter_unit_moves_from_vec,^inter_unit_moves_to_vec then
this improves to 114 seconds, with sink2 disabled I get 108 seconds
and with the tune-ctrl ontop I get 113 seconds.

Note that Zen2 is quite special in that it has the ability to handle
load/store from the stack by mapping it to a register, effectively
making them zero latency (zen3 lost this ability).

So while moves between GPRs and XMM might not be bad anymore _spilling_
to a GPR (and I suppose XMM, too) is still a bad idea and the stack
should be preferred.

Not sure if it's possible to do that though.

Doing the same experiment as above on a Zen3 machine would be nice, too.

[Bug rtl-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |rtl-optimization
 CC||vmakarov at gcc dot gnu.org
   Keywords||ra

--- Comment #7 from Richard Biener  ---
I see a lot more GPR <-> XMM moves in the 'after' case:

1035 :   401c8b: vaddsd %xmm1,%xmm0,%xmm0
1953 :   401c8f: vmovq  %rcx,%xmm1
 305 :   401c94: vaddsd %xmm8,%xmm1,%xmm1
3076 :   401c99: vmovq  %xmm0,%r14
 590 :   401c9e: vmovq  %r11,%xmm0
 267 :   401ca3: vmovq  %xmm1,%r8
 136 :   401ca8: vmovq  %rdx,%xmm1
 448 :   401cad: vaddsd %xmm1,%xmm0,%xmm1
1703 :   401cb1: vmovq  %xmm1,%r9   (*)
 834 :   401cb6: vmovq  %r8,%xmm1
1719 :   401cbb: vmovq  %r9,%xmm0   (*)
2782 :   401cc0: vaddsd %xmm0,%xmm1,%xmm1
   22135 :   401cc4: vmovsd %xmm1,%xmm1,%xmm0
1261 :   401cc8: vmovq  %r14,%xmm1
 646 :   401ccd: vaddsd %xmm0,%xmm1,%xmm0
   18136 :   401cd1: vaddsd %xmm2,%xmm5,%xmm1
 629 :   401cd5: vmovq  %xmm1,%r8
 142 :   401cda: vaddsd %xmm6,%xmm3,%xmm1
 177 :   401cde: vmovq  %xmm0,%r14
 288 :   401ce3: vmovq  %xmm1,%r9
 177 :   401ce8: vmovq  %r8,%xmm1
 174 :   401ced: vmovq  %r9,%xmm0

those look like RA / spilling artifacts and IIRC I saw Hongtao posting
patches in this area to regcprop I think?  The above is definitely
bad, for example (*) seems to swap %xmm0 and %xmm1 via %r9.

The function is LBM_performStreamCollide, the sinking pass does nothing wrong,
it moves unconditionally executed

-  _948 = _861 + _867;
-  _957 = _944 + _948;
-  _912 = _861 + _873;
...
-  _981 = _853 + _865;
-  _989 = _977 + _981;
-  _916 = _853 + _857;
-  _924 = _912 + _916;

into a conditionally executed block.  But that increases register pressure
by 5 FP regs (if I counted correctly) in that area.  So this would be the
usual issue of GIMPLE transforms not being register-pressure aware.

-fschedule-insn -fsched-pressure seems to be able to somewhat mitigate this
(though I think EBB scheduling cannot undo such movement).

In postreload I see transforms like

-(insn 466 410 411 7 (set (reg:DF 0 ax [530])
-(mem/u/c:DF (symbol_ref/u:DI ("*.LC10") [flags 0x2]) [0  S8 A64]))
"lbm.c":241:5 141 {*movdf_internal}
- (expr_list:REG_EQUAL (const_double:DF
9.9397449830464503247640095651149749755859375e-1
[0x0.fe751ce28ed5fp+0])
-(nil)))
-(insn 411 466 467 7 (set (reg:DF 25 xmm5 [orig:123 prephitmp_643 ] [123])
+(insn 411 410 467 7 (set (reg:DF 25 xmm5 [orig:123 prephitmp_643 ] [123])
 (reg:DF 0 ax [530])) "lbm.c":241:5 141 {*movdf_internal}
  (nil))

which seems like we could have reloaded %xmm5 from .LC10.  But the spilling
to GPRs seems to be present already after LRA and cprop_hardreg doesn't
do anything bad either.

The differences can be seen on trunk with -Ofast -march=znver2
[-fdisable-tree-sink2].

We have X86_TUNE_INTER_UNIT_MOVES_TO_VEC/X86_TUNE_INTER_UNIT_MOVES_FROM_VEC
and the interesting thing is that when I disable them I do see some
spilling to the stack but also quite some re-materialized constants
(loads from .LC* as seem from the opportunity above).

It might be interesting to benchmark with
-mtune-ctrl=^inter_unit_moves_from_vec,^inter_unit_moves_to_vec and find a way
to make costs in a way that IRA/LRA prefer re-materialization of constants
from the constant pool over spilling to GPRs (if that's possible at all -
Vlad?)

[Bug target/104256] New: ICE in validate_condition_mode, at config/rs6000/rs6000.cc:11354

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 104256
   Summary: ICE in validate_condition_mode, at
config/rs6000/rs6000.cc:11354
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu

gfortran 12.0.1 20220123 snapshot (g:2da90ad39bf8fa9ee287e040d1f4411cb7a2e7ed)
ICEs when compiling the following testcase, extracted from
gcc/testsuite/gfortran.dg/maxloc_2.f90, w/ -mcpu=power9 -O1
-fnon-call-exceptions:

  real :: a(2), nan
  real, allocatable :: c(:)
  integer :: ia(1)

  nan = 0.0
  nan = 0.0/nan

  a(:) = nan
  ia = maxloc (a)
  if (ia(1).ne.1) STOP 1

  allocate (c(1))
  c(:) = nan
  deallocate (c)
end

% powerpc-e300c3-linux-gnu-gfortran-12.0.1 -mcpu=power9 -O1
-fnon-call-exceptions -c juc3hqi9.f90
during RTL pass: ce2
juc3hqi9.f90:15:3:

   15 | end
  |   ^
internal compiler error: in validate_condition_mode, at
config/rs6000/rs6000.cc:11354
0x75420d validate_condition_mode(rtx_code, machine_mode)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/config/rs6000/rs6000.cc:11354
0x12b9b9c rs6000_generate_compare
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/config/rs6000/rs6000.cc:15153
0x12becb1 rs6000_emit_int_cmove(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/config/rs6000/rs6000.cc:16320
0x174b33c gen_movsicc(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/config/rs6000/rs6000.md:5360
0xdfc3a8 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/optabs.cc:7997
0xdfcb88 emit_conditional_move_1
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/optabs.cc:5034
0xdfcb88 emit_conditional_move_1
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/optabs.cc:4995
0xdfcc64 emit_conditional_move(rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*, machine_mode)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/optabs.cc:4984
0x1962646 noce_emit_cmove
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/ifcvt.cc:1759
0x19633e8 try_emit_cmove_seq
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/ifcvt.cc:3185
0x19650f9 noce_convert_multiple_sets_1
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/ifcvt.cc:3527
0x196b2c8 noce_convert_multiple_sets
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/ifcvt.cc:3281
0x196d68d noce_process_if_block
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/ifcvt.cc:3688
0x196d68d noce_find_if_block
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/ifcvt.cc:4442
0x196d68d find_if_header
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/ifcvt.cc:4647
0x196d68d if_convert
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/ifcvt.cc:5788
0x196eb5d execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/ifcvt.cc:5941

[Bug target/103771] [12 Regression] Missed vectorization under -mavx512f -mavx512vl after r12-5489

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #32 from Hongtao.liu  ---
A patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589168.html

[Bug rtl-optimization/104059] [12 Regression] cprop_hardreg propgates hard registers for mov instructions between different REG_CLASS without considering cost

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Hongtao.liu  ---
A patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589209.html

[Bug libstdc++/104161] Potential Security Vulnerability: remove_all and symbolic link

[jistone at redhat dot com via Gcc-bugs]

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

Josh Stone  changed:

   What|Removed |Added

 CC||jistone at redhat dot com

--- Comment #5 from Josh Stone  ---
You also need to use openat, because O_NOFOLLOW only affects the *trailing*
component of the path. That is, if we're removing "/base" and you're down to
"/base/foo/bar", I could change "/base/foo" to a symlink and then you'll open
"/other/bar".

[Bug libgcc/104253] libgcc missing __floatdiif

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Agreed.

[Bug libgcc/104253] libgcc missing __floatdiif

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #2 from joseph at codesourcery dot com  ---
I wouldn't expect any *if libgcc function names to be used, because "tf" 
libgcc names are supposed to refer to the ibm128 format and "kf" names are 
supposed to refer to the IEEE binary128 format, regardless of which format 
is actually TFmode inside the compiler.

Probably much the same issue as this bug: building

_Complex double ic __attribute__ ((mode (IC)));
void test_ic (void) { ic /= ic; ic *= ic; }

with -mabi=ieeelongdouble produces spurious __divic3 and __mulic3 
references (should be __divtc3 and __multc3).

[Bug libgcc/104253] libgcc missing __floatdiif

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

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

Michael Meissner  changed:

   What|Removed |Added

   Last reconfirmed||2022-01-26
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Michael Meissner  ---
In addition to __floatdiif not being in libgcc, if you build a recent trunk, it
exposes a second issue:

-ltcden3-lp5-> /home/meissner/fsf-install-ppc64le/trunk/bin/gcc -O2 pr-104253.c
during RTL pass: expand
pr-104253.c: In function ‘main’:
pr-104253.c:8:9: internal compiler error: in copy_to_mode_reg, at explow.cc:652
8 | printf("%a
%a\n",__builtin_unpack_ibm128(i,0),__builtin_unpack_ibm128(i,1));
  |
^~~
0x10408cab copy_to_mode_reg(machine_mode, rtx_def*)
/home/meissner/fsf-src/trunk/gcc/explow.cc:652
0x10f28837 rs6000_expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode,
int)
/home/meissner/fsf-src/trunk/gcc/config/rs6000/rs6000-call.cc:5834
0x1043811f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/meissner/fsf-src/trunk/gcc/expr.cc:11536
0x10446e7b store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/meissner/fsf-src/trunk/gcc/expr.cc:6087
0x1044af77 expand_assignment(tree_node*, tree_node*, bool)
/home/meissner/fsf-src/trunk/gcc/expr.cc:5819
0x10285cbb expand_call_stmt
/home/meissner/fsf-src/trunk/gcc/cfgexpand.cc:2829
0x10285cbb expand_gimple_stmt_1
/home/meissner/fsf-src/trunk/gcc/cfgexpand.cc:3864
0x10285cbb expand_gimple_stmt
/home/meissner/fsf-src/trunk/gcc/cfgexpand.cc:4028
0x1028dd93 expand_gimple_basic_block
/home/meissner/fsf-src/trunk/gcc/cfgexpand.cc:6069
0x1028ff27 execute
/home/meissner/fsf-src/trunk/gcc/cfgexpand.cc:6795
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++/104244] Crash compiling RonDB 22.01 on Oracle Linux 8 on ARM

[mikael at logicalclocks dot com via Gcc-bugs]

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

--- Comment #7 from mikael at logicalclocks dot com ---
Oracle Linux bug:
https://bugzilla.oracle.com/bugzilla/show_bug.cgi?id=17755

[Bug c++/104255] New: parsing trailing return type fails with parameter pack expansion when two parameter packs at present

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

Bug ID: 104255
   Summary: parsing trailing return type fails with parameter pack
expansion when two parameter packs at present
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickhuang99 at hotmail dot com
  Target Milestone: ---

The following template function causes error when we define trailing return
type which is identical to what function body actual returning
( https://www.godbolt.org/z/n3nbW785o ) 

template
constexpr size_t identity2(index_sequenceseq){
return N;
}
template
auto getSeq2(index_sequenceseq1, index_sequenceseq2)
// this trailing return type causing parsing error of parameter pack
->index_sequence<(identity2(seq2))...>;
{
return index_sequence<(identity2(seq2))...>{};
}


As a positive example against above, when "identity1" takes no parameter pack
as template argument, it works fine.

template
constexpr size_t identity1(){
return N;
}
template
auto getSeq1(index_sequenceindexes)
// trailing return type works, no need to define function body at all.
->index_sequence<(identity1())...>;


clang13/MSVC all work as expected.

[Bug c++/104244] Crash compiling RonDB 22.01 on Oracle Linux 8 on ARM

[mikael at logicalclocks dot com via Gcc-bugs]

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

--- Comment #6 from mikael at logicalclocks dot com ---
Hi,
Gather I could send the same bug info to Oracle as well.
Regarding the -save-temps to the failing command it is
a bit difficult since I simply run make which has its
make files created by CMake. I gather there is some method
to find out how to generate the actual commands, but it is
deeply hidden from normal developers these days, was easier
in the past.

[Bug web/104254] New: -freport-bug should be mentioned on https://gcc.gnu.org/bugs/

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

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

Bug ID: 104254
   Summary: -freport-bug should be mentioned on
https://gcc.gnu.org/bugs/
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Wile having -freport-bug is good, it is not mentioned on
https://gcc.gnu.org/bugs/ . Having it listed as another way of getting the
preprocessed source for an internal compiler error would be a good idea and
maybe even save some time for some users trying to find the preprocessed source
since it lists the file that needs to be attached in the error message.

[Bug c++/104244] Crash compiling RonDB 22.01 on Oracle Linux 8 on ARM

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

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

--- Comment #5 from Andrew Pinski  ---
Also since this is a compiler provided by Oracle, you should report the failure
to them.

[Bug c++/104244] Crash compiling RonDB 22.01 on Oracle Linux 8 on ARM

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

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

--- Comment #4 from Andrew Pinski  ---
Read https://gcc.gnu.org/bugs/ .
The simple answer is add -save-temps to the comannd line which is failing and
that should give you a preprocessed source. The other option you could try is
-freport-bug and that will output a line which says please attach a file to the
bug report, that file and compress it and attach that compressed file.

[Bug c++/104244] Crash compiling RonDB 22.01 on Oracle Linux 8 on ARM

[mikael at logicalclocks dot com via Gcc-bugs]

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

--- Comment #3 from mikael at logicalclocks dot com ---
Sorry, I am not an expert in GCC lingo, so plugin in the context
of GCC I don't know what it means. MySQL have lots of plugins, but
I assume this is not what you refer to.

Unfortunately I didn't gather the preprocessed source and don't
really know how to do it either. I gathered as much as I could.

But the problem is very repeatable, so should not be very difficult
to reproduce.

I used a VM in OCI with Oracle Linux 8.5 Cloud Developer version
where I installed as directed by CMake.

It does work with GCC 10.2.1 on the same OS I can mention although
I failed in downgrading, but I had it working on a different VM
which is a bit older and still had 10.2.1 installed.

Tried compiling on Ubuntu using 20.04 in OCI which is some version
of 10.3.0. This didn't fail in the same manner, instead it failed
in a missing symbol dlopen in 2.17 (presume it is GLIBC it refers to).

[Bug target/104253] New: libgcc missing __floatdiif

[murphyp at linux dot vnet.ibm.com via Gcc-bugs]

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

Bug ID: 104253
   Summary: libgcc missing __floatdiif
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: murphyp at linux dot vnet.ibm.com
CC: bergner at gcc dot gnu.org, meissner at gcc dot gnu.org
  Target Milestone: ---

When compiling something which uses the __ibm128 type, an instrinsic function
call is generated which is not satisfied at link time. E.g foo.c:

#include 
#include 

int main(int a, char **v)
{
long d = strtol(v[1],0,0);
__ibm128 i = d;
printf("%a
%a\n",__builtin_unpack_ibm128(i,0),__builtin_unpack_ibm128(i,1));
return 0;
}

gcc -O2 foo.c -o foo:
/usr/bin/ld: /tmp/ccuWW1m0.o: in function `main':
foo.c:(.text.startup+0x2c): undefined reference to `__floatdiif'
collect2: error: ld returned 1 exit status

This happens on a ppc64le machine running fedora rawhide, gcc -v:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64le-redhat-linux/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: ppc64le-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release
--enable-targets=powerpcle-linux --disable-multilib --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-gcc-major-version-only
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-12.0.1-20220118/obj-ppc64le-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-secureplt
--with-long-double-128 --with-long-double-format=ieee --with-cpu-32=power8
--with-tune-32=power8 --with-cpu-64=power8 --with-tune-64=power8
--build=ppc64le-redhat-linux --with-build-config=bootstrap-lto
--enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220118 (Red Hat 12.0.1-0) (GCC)

[Bug libfortran/104233] [12 regression] ieee/issignaling_fallback.h broke Solaris/SPARC bootstrap

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #9 from Francois-Xavier Coudert  ---
> It did indeed.  Thanks.

Great! Thanks for letting me know, and apologies for breaking the build in the
first place.

[Bug libfortran/104233] [12 regression] ieee/issignaling_fallback.h broke Solaris/SPARC bootstrap

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Francois-Xavier Coudert  ---
> Pushed the fix as logical after checking on aarch64-apple-darwin.
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8769f32b645eb08b9f07ec3171cc21c3420f8616
>
> Please let me know if this fixes SPARC/Solaris bootstrap.

It did indeed.  Thanks.

[Bug fortran/83700] [Meta-bug] Fortran Coarray issues

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

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

Bug 84787 Summary: ICEs: in decompose, at wide-int.h:933 with -default-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84787

   What|Removed |Added

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

[Bug fortran/32770] [Meta-bug] -fdefault-integer-8 issues

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

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

Bug 84787 Summary: ICEs: in decompose, at wide-int.h:933 with -default-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84787

   What|Removed |Added

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

[Bug fortran/84784] ICEs: verify_gimple failed with -fdefault-integer-8

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

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
*** Bug 84787 has been marked as a duplicate of this bug. ***

[Bug fortran/84787] ICEs: in decompose, at wide-int.h:933 with -default-integer-8

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from anlauf at gcc dot gnu.org ---
Likely fixed by the patch for pr84784 which also addresses this intrinsic.

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

[Bug fortran/104252] OpenMP array reduction support issue

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

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

--- Comment #2 from Andrew Pinski  ---
Note the C/C++ front-end do support this though:
int main(void)
{
const int n = 3;
int a[n]={};
int i, j, s, t;

  for (i = 0; i < n ; i++) {
t = 0;
#pragma omp parallel for reduction(+:a[i])
for(j = 0; j < n; j++)
 a[i]++;
  }

  s = 0;
  for(int t = 0; t < n; t++)
s += a[t];
  __builtin_printf("%d\n", s);
}

[Bug libstdc++/104251] std::reduce scrambles argument order for BinaryOp function call: Possible bug?

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Felix Köhler from comment #0)
> > you cannot expect to get passed the accumulator value as the first argument
> > to BinOp and the sequence value as the second argument.
> 
> This is correct, you cannot assume that.

The spec for std::accumulate is very precise:

  Computes its result by initializing the accumulator acc with the initial
  value init and then modifies it with acc = std::move(acc) + *i or
  acc = binary_op(std::move(acc), *i) for every iterator i in the range
  [first, last) in order.

It's guaranteed that the accumulator is the first arg, and the range element is
the second.

There is no such wording for std::reduce. That is intentional. Instead it is
defined in terms of GENERALIZED_SUM, defined in [numerics.defn]. The definition
is recursive and allows *both* arguments to the binary_op to be the results of
calling the binary_op. For example, for std::reduce(F, {1, 2, 3, 4), 10) the
result is:
binary_op(a, binary_op(b, c), binary_op(d, e)) where {a, b, c, d, e} is any
permutation of {1, 2, 3, 4, 10}.

[Bug target/104239] [12 Regression] immintrin.h or x86gprintrin.h headers can't be included

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

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

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

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

commit r12-6885-gfd5b0488ad5e4f29b65238e06a2d65b7de120235
Author: Jakub Jelinek 
Date:   Wed Jan 26 22:55:11 2022 +0100

rs6000: Fix up *intrin.h for C89 [PR104239]

When writing testcases for the previously posted patch, I have noticed
that 3 of the headers aren't valid C89 (I didn't have any dg-options
so -ansi -pedantic-errors was implied and these errors were reported).

The following patch fixes those, ok for trunk?

Note, as can be seen even in this patch, seems older rs6000/*intrin.h
headers uglify not just argument names (__A instead of A etc.), but also
automatic variable names and other local identifiers, while e.g.
emmintrin.h
or bmi2intrin.h clearly uglify only the argument names and not local
variables.  I think that should be fixed but don't have time for that
myself
(libstdc++ or e.g. the x86 headers uglify everything; this is so that one
can
 #define result a + b
 #include 
etc.).

2022-01-26  Jakub Jelinek  

PR target/104239
* config/rs6000/emmintrin.h (_mm_sad_epu8): Use __asm__ instead of
asm.
* config/rs6000/smmintrin.h (_mm_minpos_epu16): Declare iterator
before for loop instead of for init clause.
* config/rs6000/bmi2intrin.h (_pext_u64): Likewise.

* gcc.target/powerpc/pr104239-3.c: New test.

[Bug fortran/104252] OpenMP array reduction support issue

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-01-26
   Keywords||openmp, rejects-valid
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug libstdc++/104251] std::reduce scrambles argument order for BinaryOp function call: Possible bug?

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

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

--- Comment #3 from Jonathan Wakely  ---
The non-parallel version of std::reduce really only exists for completeness,
because the parallel overload (the one taking an execution policy argument)
exists, and so a non-parallel one was added too.

For the parallel version there are significant optimizations possible if the
"sum" can be done in any order, so it's an important algorithm for the parallel
case. For the serial case, it doesn't really need to exist (std::accumulate is
already good enough). But as I said, it's there for completeness because
there's no reason it can't be done serially.

[Bug libstdc++/104251] std::reduce scrambles argument order for BinaryOp function call: Possible bug?

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Felix Köhler from comment #0)
> a) the arguments with a non-default BinOp parameter seem to get scrambled,
> see attachment test01().
> 
> vector x={1,2,3,1};
> int sum;
> auto b=x.cbegin();
> auto e=x.cend();
> cout << reduce(b, e, 0, [](int sum, int i) {return sum+i+i;}) << "\t";
> 
> yields 14 for CLANG, 30 for GCC. Trace of the lambda function calls included
> in the attachment.

Both results are allowed by the standard.

> b) Even a simple double addition lambda function does not work, if the
> accumulator value requires a higher precision to hold the result, than can
> be stored in the type of the sequence to be reduced. See attachment
> test02(). This is probably not the intended behavior.
> 
> vectorbytes = {200, 201, 202, 203};
> cout << reduce(bytes.begin(), bytes.end(), 0L,
>[](long sum, unsigned char i) {return sum+i;});
> 
> yields the expected 806 for CLANG, GCC overflows and yields 38.

Technically, not an overflow, because unsigned types don't overflow. It's a
reduction modulo 255.

Both results are allowed by the standard.

> c) Using non-implicitely-convertible types for the accumulator and the
> reduced function is not supported in GCC, yet CLANG compiles and runs the
> following code just fine. See test03().
> 
> TLDR:
> vector numbers={"eins","dos", "three", "quatre"};
> cout << reduce(numbers.begin(), numbers.end(), 0L,
>[](size_t sum, string s) {return sum+s.size();}) << "\t";
> 
> CLANG counts 18 letters, GCC refuses compilation with an error message that
> the init value 0L cannot be converted into the sequence type of string.

GCC is correct. Clang is wrong.


> According to cppreference.com:
> "The behavior is non-deterministic if binary_op is not associative or not
> commutative. ... in other words, reduce behaves like std::accumulate except
> the elements of the range may be grouped and rearranged in arbitrary order."
> which seems to support the CLANG interpretation.

Eh? No it doesn't.

The standard is very clear:

Mandates: All of
— binary_op(init, *first),
— binary_op(*first, init),
— binary_op(init, init), and
— binary_op(*first, *first)
are convertible to T.

For your [](size_t, string) function that is clearly not met, and so the
implementation is *required* to give a diagnostic. If clang's libc++ compilers
it happily, that's a conformance bug in libc++.

> I'm not a language lawyer, GCC might be correct in assuming that the
> sequence MUST have the same type as the result of the reduce function and

GCC doesn't assume that though.

It's fine to use [](long i, long j) { return i + j; } to sum vector, for
example.

It's not fine to use [](char i, char j) { return i+j; } if the total won't fit
in a char, and since it's unspecified which order the arguments are passed to
the function, your examples are broken too. 

> you cannot expect to get passed the accumulator value as the first argument
> to BinOp and the sequence value as the second argument.

This is correct, you cannot assume that.

> However, this
> reduces std::reduce to a trivial SUM/PRODUCT function with a horrible
> interface and really evil implicit type-casting traps.

Only if you do silly things like try to use char to accumulate values that
overflow char.

> This seems to be a bug in either the libstdc++ implementation or the
> standard itself, please correct me, if I'm wrong.

You are wrong.

As Andrew said, the point is that the elements of the range can be passed to
the binary function in any order, which means you can process more than one
element per iteration of the loop.

If you want to process each element in order and have guarantees about the
arguments passed to the function, use std::accumulate.

If your function is associative and commutative, and you don't need the
guarantees or std::accumulate, you can use std::reduce. Otherwise, don't.

[Bug fortran/104252] New: OpenMP array reduction support issue

[longb at cray dot com via Gcc-bugs]

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

Bug ID: 104252
   Summary: OpenMP array reduction support issue
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

Created attachment 52299
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52299=edit
Source for test case.

For the attached test case source file:

> gfortran -fopenmp array-reduction-test.F90 
array-reduction-test.F90:26:37:

   26 |  !$omp parallel do reduction(+:a(i))
  | 1
Error: Syntax error in OpenMP variable list at (1)
array-reduction-test.F90:30:26:

   30 |  !$omp end parallel do
  |  1
Error: Unexpected !$OMP END PARALLEL DO statement at (1)


> gfortran -fopenmp -DARRAY_SECTION array-reduction-test.F90 
array-reduction-test.F90:18:37:

   18 |  !$omp parallel do reduction(+:a(i:1))
  | 1
Error: Syntax error in OpenMP variable list at (1)
array-reduction-test.F90:22:26:

   22 |  !$omp end parallel do
  |  1
Error: Unexpected !$OMP END PARALLEL DO statement at (1)

> gfortran -fopenmp -DFULL_ARRAY array-reduction-test.F90 

> gfortran --version
GNU Fortran (GCC) 11.2.0 20210728 (Cray Inc.)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Gfortran seems to be OK with a whole array in an OpenMP reduction clause, but
not with an array element or an array section.  Other compilers (ifort, for
example) accept all 3 forms.

[Bug target/104239] [12 Regression] immintrin.h or x86gprintrin.h headers can't be included

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

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

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

https://gcc.gnu.org/g:2bf8da684b712a16c67f3defc0dd97f175f8f4ad

commit r12-6884-g2bf8da684b712a16c67f3defc0dd97f175f8f4ad
Author: Jakub Jelinek 
Date:   Wed Jan 26 22:07:29 2022 +0100

rs6000: Fix up #include  or  [PR104239]

r12-4717-g7d37abedf58d66 added immintrin.h and x86gprintrin.h headers
to rs6000, these headers are on x86 standalone headers that various
programs include directly rather than including them through
.
Unfortunately, for that change the bmiintrin.h and bmi2intrin.h
headers haven't been adjusted, so the effect is that if one includes them
(without including also x86intrin.h first) #error will trigger.
Furthermore, when including such headers conditionally as some real-world
packages do, this means a regression.

The following patch fixes it and matches what the x86 bmi{,2}intrin.h
headers do.

2022-01-26  Jakub Jelinek  

PR target/104239
* config/rs6000/bmiintrin.h: Test _X86GPRINTRIN_H_INCLUDED instead
of
_X86INTRIN_H_INCLUDED and adjust #error wording.
* config/rs6000/bmi2intrin.h: Likewise.

* gcc.target/powerpc/pr104239-1.c: New test.
* gcc.target/powerpc/pr104239-2.c: New test.

[Bug fortran/84784] ICEs: verify_gimple failed with -fdefault-integer-8

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2022-January/057478.html

This fixes

gfortran.dg/team_change_1.f90
gfortran.dg/team_number_1.f90
gfortran.dg/popcnt_poppar_2.F90 (-m64, not supported with -m32)

I was unable to reproduce

gfortran.dg/coarray/sync_3.f90  (with -fcheck=all)
gfortran.dg/goacc/nested-function-1.f90

Could somebody else have a look at these and give details?
Especially which function or code triggers the error?

[Bug target/104239] [12 Regression] immintrin.h or x86gprintrin.h headers can't be included

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

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

--- Comment #2 from Marc Glisse  ---
Thanks for fixing that bug, but don't you still have issues with
NO_WARN_X86_INTRINSICS if you rely on __has_include for immintrin.h?

[Bug libstdc++/104251] std::reduce scrambles argument order for BinaryOp function call: Possible bug?

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

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

--- Comment #1 from Andrew Pinski  ---
(In reply to Felix Köhler from comment #0)
> According to cppreference.com:
> "The behavior is non-deterministic if binary_op is not associative or not
> commutative. ... in other words, reduce behaves like std::accumulate except
> the elements of the range may be grouped and rearranged in arbitrary order."
> which seems to support the CLANG interpretation.

I think you read this wrong. this wording says it supports both.

That is:
If we have 1,2,3,1:
it can be done as:
(1 op 2) op (3 op 1)
or
((1 op 2) op 3) op 1
Or really any order or grouping.

[Bug libstdc++/104251] New: std::reduce scrambles argument order for BinaryOp function call: Possible bug?

[felix.koehler at gmail dot com via Gcc-bugs]

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

Bug ID: 104251
   Summary: std::reduce scrambles argument order for BinaryOp
function call: Possible bug?
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix.koehler at gmail dot com
  Target Milestone: ---

Created attachment 52298
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52298=edit
Disable testcase test03 to compile with GCC

I experimented with std::reduce from the libstdc++ library and I get completely
different results for all slightly non-trivial cases comparing
CLANG-13.0.0/CLANG-HEAD-14.0.0 output vs GCC--10.2.0/11.1.0/HEAD 12.0.1
20220123 (experimental). (Using wandbox.org)

a) the arguments with a non-default BinOp parameter seem to get scrambled, see
attachment test01().

vector x={1,2,3,1};
int sum;
auto b=x.cbegin();
auto e=x.cend();
cout << reduce(b, e, 0, [](int sum, int i) {return sum+i+i;}) << "\t";

yields 14 for CLANG, 30 for GCC. Trace of the lambda function calls included in
the attachment.

b) Even a simple double addition lambda function does not work, if the
accumulator value requires a higher precision to hold the result, than can be
stored in the type of the sequence to be reduced. See attachment test02(). This
is probably not the intended behavior.

vectorbytes = {200, 201, 202, 203};
cout << reduce(bytes.begin(), bytes.end(), 0L,
   [](long sum, unsigned char i) {return sum+i;});

yields the expected 806 for CLANG, GCC overflows and yields 38.

c) Using non-implicitely-convertible types for the accumulator and the reduced
function is not supported in GCC, yet CLANG compiles and runs the following
code just fine. See test03().

TLDR:
vector numbers={"eins","dos", "three", "quatre"};
cout << reduce(numbers.begin(), numbers.end(), 0L,
   [](size_t sum, string s) {return sum+s.size();}) << "\t";

CLANG counts 18 letters, GCC refuses compilation with an error message that the
init value 0L cannot be converted into the sequence type of string.

According to cppreference.com:
"The behavior is non-deterministic if binary_op is not associative or not
commutative. ... in other words, reduce behaves like std::accumulate except the
elements of the range may be grouped and rearranged in arbitrary order." which
seems to support the CLANG interpretation.

I'm not a language lawyer, GCC might be correct in assuming that the sequence
MUST have the same type as the result of the reduce function and you cannot
expect to get passed the accumulator value as the first argument to BinOp and
the sequence value as the second argument. However, this reduces std::reduce to
a trivial SUM/PRODUCT function with a horrible interface and really evil
implicit type-casting traps. 

This seems to be a bug in either the libstdc++ implementation or the standard
itself, please correct me, if I'm wrong.

[Bug c++/103186] [11/12 Regression] ICE with lambda as default argument in template

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

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

Jason Merrill  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Status|NEW |ASSIGNED
Summary|[11/12 Regression] ICE with |[11/12 Regression] ICE with
   |lambdas as default since|lambda as default argument
   |r11-7965-g23be03a0f243a084  |in template

[Bug debug/104238] dwarf DW_AT_const_value causes overflow in readelf

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |MOVED

--- Comment #6 from Andrew Pinski  ---
Oh it was already filed to binutils:
https://sourceware.org/bugzilla/show_bug.cgi?id=26548

So closing as moved. It was fixed in binutils 2.35+.
Note there was more fixes in binutils 2.37 too:
https://sourceware.org/pipermail/binutils/2021-February/115407.html

[Bug c++/104206] [12 regression] test case c-c++-common/pr72747-2.c fails in r12-6821

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Fixed.

[Bug c++/101072] [12 Regression] ICE in build_target_expr_with_type, at cp/tree.c:845 since r11-5681-gd9288bd28e24c755

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

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

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

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

commit r12-6883-g9bf217920457f2e2d46b601f24721780a20a031b
Author: Jason Merrill 
Date:   Wed Jan 26 12:44:31 2022 -0500

c++: vector compound literal [PR104206]

My patch for PR101072 removed the specific VECTOR_TYPE handling here, which
broke pr72747-2.c on PPC; this patch restores it.

PR c++/104206
PR c++/101072

gcc/cp/ChangeLog:

* semantics.cc (finish_compound_literal): Restore VECTOR_TYPE
check.

[Bug c++/104206] [12 regression] test case c-c++-common/pr72747-2.c fails in r12-6821

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

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

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

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

commit r12-6883-g9bf217920457f2e2d46b601f24721780a20a031b
Author: Jason Merrill 
Date:   Wed Jan 26 12:44:31 2022 -0500

c++: vector compound literal [PR104206]

My patch for PR101072 removed the specific VECTOR_TYPE handling here, which
broke pr72747-2.c on PPC; this patch restores it.

PR c++/104206
PR c++/101072

gcc/cp/ChangeLog:

* semantics.cc (finish_compound_literal): Restore VECTOR_TYPE
check.

[Bug middle-end/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
  Component|c++ |middle-end
   Assignee|jason at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #7 from Jason Merrill  ---
This doesn't seem to be a C++ issue, unassigning myself.

[Bug target/104241] [12 Regression] trunk 20220126 RTL error on powerpc64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |WAITING

[Bug debug/104238] dwarf DW_AT_const_value causes overflow in readelf

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

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

--- Comment #5 from Jakub Jelinek  ---
binutils 2.35 readelf doesn't warn either, and neither 2.37.

[Bug target/104241] [12 Regression] trunk 20220126 RTL error on powerpc64-linux-gnu

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

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

--- Comment #4 from Jakub Jelinek  ---
Didn't r12-6877-g8bcf835e0a4e3334e1c60f314ae6917ba648bdde fix this?

[Bug target/104241] [12 Regression] trunk 20220126 RTL error on powerpc64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-01-26

[Bug bootstrap/104241] [12 Regression] trunk 20220126 RTL error on powerpc64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #3 from Andrew Pinski  ---
*** Bug 104249 has been marked as a duplicate of this bug. ***

[Bug target/104249] [12 regression] RTL failure with checks turned on after r12-6848

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 104241.

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

[Bug libstdc++/104242] [12 Regression] Class with constructor from std::any is not copyable

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-01-26
 Status|UNCONFIRMED |NEW

--- Comment #3 from Andrew Pinski  ---
Most likely caused by r12-4190.

Confirmed.

[Bug libstdc++/104242] [12 Regression] Class with constructor from std::any is not copyable

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

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

--- Comment #2 from Andrew Pinski  ---
Note Clang's error message might be more helpfull:
In file included from :2:
In file included from
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.1/../../../../include/c++/12.0.1/any:39:
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.1/../../../../include/c++/12.0.1/type_traits:168:14:
error: base class has incomplete type
: public __conditional_t<_B1::value, _B2, _B1>
  ~~~^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.1/../../../../include/c++/12.0.1/type_traits:2244:36:
note: in instantiation of template class
'std::__and_>,
std::is_copy_constructible>' requested here
using _Require = __enable_if_t<__and_<_Cond...>::value>;
   ^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.1/../../../../include/c++/12.0.1/any:188:19:
note: in instantiation of template type alias '_Require' requested here
  typename = _Require<__not_<__is_in_place_type<_VTp>>,
 ^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.1/../../../../include/c++/12.0.1/any:190:7:
note: in instantiation of default argument for 'any>' required here
  any(_Tp&& __value)
  ^~
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.1/../../../../include/c++/12.0.1/type_traits:971:54:
note: while substituting deduced template arguments into function template
'any' [with _Tp = const A &, _VTp = (no value), _Mgr = (no value), $3 = (no
value)]
: public __bool_constant<__is_constructible(_Tp, _Args...)>
 ^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.1/../../../../include/c++/12.0.1/type_traits:1003:14:
note: in instantiation of template class 'std::__is_constructible_impl' requested here
: public __is_constructible_impl<_Tp, const _Tp&>
 ^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.1/../../../../include/c++/12.0.1/type_traits:1010:14:
note: in instantiation of template class 'std::__is_copy_constructible_impl' requested here
: public __is_copy_constructible_impl<_Tp>
 ^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.1/../../../../include/c++/12.0.1/type_traits:3205:5:
note: in instantiation of template class 'std::is_copy_constructible'
requested here
is_copy_constructible<_Tp>::value;
^
:9:20: note: in instantiation of variable template specialization
'std::is_copy_constructible_v' requested here
static_assert(std::is_copy_constructible_v);
   ^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.1/../../../../include/c++/12.0.1/type_traits:1009:12:
note: definition of 'std::is_copy_constructible' is not complete until the
closing '}'
struct is_copy_constructible
   ^

[Bug c++/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329

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

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

--- Comment #6 from Jason Merrill  ---
(In reply to Jason Merrill from comment #5)
> It is surprising that we warn with a user-provided copy constructor and
> don't with a defaulted constructor.  It changes the code a bit because it
> means string_piece isn't trivially copyable, so we need to create a
> string_piece temporary for passing to to_stage instead of passing arg
> directly by bitwise copy, but I don't know why that would confuse the
> optimizers into thinking that _M_p might be uninitialized.

The diff of the GIMPLE is

@@ -40,10 +39,7 @@
 D$ = 1;
 try
   {
-string_piece::string_piece ($, );
-try
-  {
-_2 = to_stage ($);
+_2 = to_stage (arg);
 D$.stage = _2;
 D$ = 0;
 try
@@ -62,11 +58,6 @@
 D$ = {CLOBBER};
   }
   }
-finally
-  {
-D$ = {CLOBBER};
-  }
-  }
 catch
   {
 if (D$ != 0) goto ; else goto ;

[Bug c++/104244] Crash compiling RonDB 22.01 on Oracle Linux 8 on ARM

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

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

--- Comment #2 from Andrew Pinski  ---
Also please read the error message too:
// *** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins

// Please submit a full bug report,
// with preprocessed source if appropriate.
// See  for instructions.

[Bug c++/104244] Crash compiling RonDB 22.01 on Oracle Linux 8 on ARM

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2022-01-26

--- Comment #1 from Andrew Pinski  ---
Can you attach the preprocessed source as requested at
https://gcc.gnu.org/bugs/ ?

[Bug c++/104033] [12 regression] g++.dg/cpp0x/constexpr-compare2.C fails with excess errors after r12-6578

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

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

--- Comment #5 from Andrew Pinski  ---
>From Jakub in the other bug report:
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587856.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588689.html
I need to rewrite the patch according to the patch review and didn't find time
for that yet.

[Bug debug/104194] No way to distinguish IEEE and IBM long double in debug info

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

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

--- Comment #7 from Jakub Jelinek  ---
A temporary workaround now applied.
The dwarf-discuss thread seems to prefer using separate DW_ATE_* values instead
of DW_AT_precision/DW_AT_minimum_exponent, but hasn't converged yet.

[Bug c++/104033] [12 regression] g++.dg/cpp0x/constexpr-compare2.C fails with excess errors after r12-6578

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #4 from Andrew Pinski  ---
*** Bug 104246 has been marked as a duplicate of this bug. ***

[Bug c++/104246] FAIL: g++.dg/cpp0x/constexpr-compare2.C -std=c++20 (test for excess errors)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Andrew Pinski  ---
Oh and there was already a bug filed about this testcase too.
So this is a dup of bug 104033.

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

[Bug c++/104033] [12 regression] g++.dg/cpp0x/constexpr-compare2.C fails with excess errors after r12-6578

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-01-26

--- Comment #3 from Andrew Pinski  ---
.

[Bug c++/104226] [12 Regression] ICE in fold_vec_perm, at fold-const.cc:10483 since r12-6821-g053bcc97f4a59e3f

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug debug/104194] No way to distinguish IEEE and IBM long double in debug info

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

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

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

https://gcc.gnu.org/g:866d73019bd4d1804f7e09409322e6605b81780b

commit r12-6882-g866d73019bd4d1804f7e09409322e6605b81780b
Author: Jakub Jelinek 
Date:   Wed Jan 26 19:42:31 2022 +0100

dwarf2out: For ppc64le IEEE quad long double, emit DW_TAG_typedef to
_Float128 [PR104194]

On Mon, Jan 24, 2022 at 11:26:27PM +0100, Jakub Jelinek via Gcc-patches
wrote:
> Yet another short term solution might be not use DW_TAG_base_type
> for the IEEE quad long double, but instead pretend it is a DW_TAG_typedef
> with DW_AT_name "long double" to __float128 DW_TAG_base_type.
> I bet gdb would even handle it without any changes, but of course, it
would
> be larger than the other proposed changes.

Here it is implemented.

Testcases I've played with are e.g.:
__ibm128 a;
long double b;
_Complex long double c;

static __attribute__((noinline)) int
foo (long double d)
{
  long double e = d + 1.0L;
  return 0;
}

int
main ()
{
  a = 1.0;
  b = 2.0;
  c = 5.0 + 6.0i;
  return foo (7.0L);
}
and
  real(kind=16) :: a
  complex(kind=16) :: b
  a = 1.0
  b = 2.0
end

Printing the values of the variables works well,
p  or p  shows pointer to the correct type, just
ptype b or ptype c prints _Float128 instead of
long double or complex _Float128 instead of complex long double.
Even worse in fortran where obviously _Float128 or
complex _Float128 aren't valid types, but as GDB knows them by name,
it is just ptype that is weird.

2022-01-26  Jakub Jelinek  

PR debug/104194
* dwarf2out.cc (long_double_as_float128): New function.
(modified_type_die): For powerpc64le IEEE 754 quad long double
and complex long double emit those as DW_TAG_typedef to
_Float128 or complex _Float128 base type.

[Bug c++/104226] [12 Regression] ICE in fold_vec_perm, at fold-const.cc:10483 since r12-6821-g053bcc97f4a59e3f

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

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

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

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

commit r12-6881-gabea1c9a252ef7712ab800360e1e0e2697ee14f2
Author: Jakub Jelinek 
Date:   Wed Jan 26 19:40:29 2022 +0100

c++: Fix up handling of vector CONSTRUCTORs with vectors in it in
constexpr.cc [PR104226]

The middle-end uses sometimes VECTOR_TYPE CONSTRUCTORs that contain
some other VECTOR_TYPE elements in it (should be with compatible element
size and smaller number of elements, e.g. a V8SImode vector can be
constructed as { V4SImode_var_1, V4SImode_var_2 }), and expansion of
__builtin_shufflevector emits these early, so constexpr.cc can see those
too.
constexpr.cc already has special cases for NULL index which is typical
for VECTOR_TYPE CONSTRUCTORs, and for VECTOR_TYPE CONSTRUCTORs that
contain just scalar elts that works just fine - init_subob_ctx just
returns on non-aggregate elts and get_or_insert_ctor_field has
  if (TREE_CODE (type) == VECTOR_TYPE && index == NULL_TREE)
{
  CONSTRUCTOR_APPEND_ELT (CONSTRUCTOR_ELTS (ctor), index, NULL_TREE);
  return _ELTS (ctor)->last();
}
handling for it.  But for the vector in vector case init_subob_ctx would
try to create a sub-CONSTRUCTOR and even didn't handle the NULL index
case well, so instead of creating the sub-CONSTRUCTOR after the elts
already
in it overwrote the first one.  So
(V8SImode) { { 0, 0, 0, 0 }, { 0, 0, 0, 0 } }
became
(V8SImode) { 0, 0, 0, 0 }
The following patch fixes it by not forcing a sub-CONSTRUCTOR for this
vector in vector case.

2022-01-26  Jakub Jelinek  

PR c++/104226
* constexpr.cc (init_subob_ctx): For vector ctors containing
vector elements, ensure appending to the same ctor instead of
creating another one.

* g++.dg/cpp0x/constexpr-104226.C: New test.

[Bug c++/104245] abseil-cpp 20211102.0 fails with "internal compiler error"

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

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

--- Comment #4 from Andrew Pinski  ---
Well I can't reproduce it with the following cmake options:
cmake -DABSL_USE_EXTERNAL_GOOGLETEST=ON -DBUILD_TESTING=off
make

Also cmake projects are a pain to work with really.

[Bug target/104250] [i386] GCC may want to use 32-bit (I)DIV if it can for 64-bit operands

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug c++/104246] FAIL: g++.dg/cpp0x/constexpr-compare2.C -std=c++20 (test for excess errors)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587856.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588689.html
I need to rewrite the patch according to the patch review and didn't find time
for that yet.

[Bug c++/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329

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

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

--- Comment #5 from Jason Merrill  ---
(In reply to Sergei Trofimovich from comment #0)
>   input_files.emplace_back(Z{
>   arg.str(), // what is the lifetime of this temporary?

This prvalue initializes the 'name' member of the Z temporary, there is no
separate string temporary.

>   to_stage(arg), // why does this constructor matter?

My fix for PR66139 fixed EH in aggregate initialization so that if evaluation
of to_stage(arg) throws, we properly destroy the previously initialized 'name'
member.  That's the difference pinskia mentions.

It is surprising that we warn with a user-provided copy constructor and don't
with a defaulted constructor.  It changes the code a bit because it means
string_piece isn't trivially copyable, so we need to create a string_piece
temporary for passing to to_stage instead of passing arg directly by bitwise
copy, but I don't know why that would confuse the optimizers into thinking that
_M_p might be uninitialized.

[Bug c++/104246] FAIL: g++.dg/cpp0x/constexpr-compare2.C -std=c++20 (test for excess errors)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Host|hppa*-*-*   |
  Build|hppa*-*-*   |
 Target|hppa*-*-*   |
  Component|testsuite   |c++
   Keywords||wrong-code

--- Comment #1 from Andrew Pinski  ---
No this fails on all targets. There was some email about the testcase but I
can't remember what.

[Bug target/104250] New: [i386] GCC may want to use 32-bit (I)DIV if it can for 64-bit operands

[thiago at kde dot org via Gcc-bugs]

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

Bug ID: 104250
   Summary: [i386] GCC may want to use 32-bit (I)DIV if it can for
64-bit operands
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org
  Target Milestone: ---

In
long long f1(long long n, long long d)
{
return n / d;
}

GCC generates:

movq%rdi, %rax
cqto
idivq   %rsi
ret

Which is fine, except that the 64-bit IDIV instruction is significantly slower
than the 32-bit (I)DIV. In recent CPUs (such as PMC, SNC, WLC, GLC), that's 18
vs 14 cycles, but it was much worse in older CPUs. There's still a significant
difference for Atom cores, such as used in Alder Lake-E.

Clang generates:
movq%rdi, %rax
movq%rdi, %rcx
orq %rsi, %rcx
shrq$32, %rcx
je  .LBB0_1
cqto
idivq   %rsi
retq
.LBB0_1:
xorl%edx, %edx
divl%esi
retq

That is, it ORs the two operands and checks if any bit in the upper half is
set. If so, it performs the 64-bit division; otherwise, it performs the 32-bit
one.

References:
https://gcc.godbolt.org/z/385a3da8q
https://uops.info/html-instr/IDIV_R32.html
https://uops.info/html-instr/IDIV_R64.html

[Bug fortran/104127] [9/10/11/12 Regression] ICE in get_array_charlen, at fortran/trans-array.c:7244

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

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

commit r11-9516-gc3251374af4b82888b6be3eb9cfa6b0b3944907b
Author: Harald Anlauf 
Date:   Thu Jan 20 22:36:50 2022 +0100

Fortran: fix simplification of TRANSFER for zero-sized character array
result

gcc/fortran/ChangeLog:

PR fortran/104127
* simplify.c (gfc_simplify_transfer): Ensure that the result
typespec is set up for TRANSFER with MOLD of type CHARACTER
including character length even if the result is a zero-sized
array.

gcc/testsuite/ChangeLog:

PR fortran/104127
* gfortran.dg/transfer_simplify_11.f90: Fix logic.
* gfortran.dg/transfer_simplify_13.f90: New test.

(cherry picked from commit 6c1a93102b41a558f3ad49a7c66015257535c747)

[Bug target/100775] ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with -mthumb -fzero-call-used-regs=used

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

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

--- Comment #3 from qinzhao at gcc dot gnu.org ---
the following simple patch resolved the issue:

diff --git a/gcc/function.cc b/gcc/function.cc
index e1d2565f8d9..c8a77c9a624 100644
--- a/gcc/function.cc
+++ b/gcc/function.cc
@@ -5942,6 +5942,7 @@ gen_call_used_regs_seq (rtx_insn *ret, unsigned int
zero_regs_type)
   /* Update the data flow information.  */
   crtl->must_be_zero_on_return |= zeroed_hardregs;
   df_set_bb_dirty (EXIT_BLOCK_PTR_FOR_FN (cfun));
+  df_update_exit_block_uses ();
 }
 }

will test it.

[Bug target/104249] [12 regression] RTL failure with checks turned on after r12-6848

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Keywords||build, ice-checking,
   ||ice-on-valid-code

[Bug target/100775] ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with -mthumb -fzero-call-used-regs=used

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

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

--- Comment #2 from qinzhao at gcc dot gnu.org ---
This is a bug in pass_zero_call_used_regs, when updating df after the zeroing
sequence is added in the epilogue of the function, we should call
"df_update_exit_block_uses" to update the reg use info in the exit block to
include all the regs that have been zeroed.

I think that this is a very general issue, should be fixed into both gcc12 and
gcc11.

[Bug fortran/104227] [9/10/11 Regression] ICE virtual memory exhausted: Cannot allocate memory

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!

[Bug fortran/104227] [9/10/11 Regression] ICE virtual memory exhausted: Cannot allocate memory

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:200afb44967520c1c75a35f91c4a56b5e5fb65ff

commit r9-9928-g200afb44967520c1c75a35f91c4a56b5e5fb65ff
Author: Harald Anlauf 
Date:   Tue Jan 25 21:56:39 2022 +0100

Fortran: MOLD argument to TRANSFER intrinsic having storage size zero

gcc/fortran/ChangeLog:

PR fortran/104227
* check.c (gfc_calculate_transfer_sizes): Fix checking of arrays
passed as MOLD argument to the TRANSFER intrinsic for having
storage size zero.

gcc/testsuite/ChangeLog:

PR fortran/104227
* gfortran.dg/transfer_check_6.f90: New test.

(cherry picked from commit ec543c9833c2d9283c035cd8430849eb4ec04406)

[Bug fortran/104227] [9/10/11 Regression] ICE virtual memory exhausted: Cannot allocate memory

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:0646ff3e170b87050bad4448b89406e476f64496

commit r10-10421-g0646ff3e170b87050bad4448b89406e476f64496
Author: Harald Anlauf 
Date:   Tue Jan 25 21:56:39 2022 +0100

Fortran: MOLD argument to TRANSFER intrinsic having storage size zero

gcc/fortran/ChangeLog:

PR fortran/104227
* check.c (gfc_calculate_transfer_sizes): Fix checking of arrays
passed as MOLD argument to the TRANSFER intrinsic for having
storage size zero.

gcc/testsuite/ChangeLog:

PR fortran/104227
* gfortran.dg/transfer_check_6.f90: New test.

(cherry picked from commit ec543c9833c2d9283c035cd8430849eb4ec04406)

[Bug tree-optimization/101793] Incorrect -Wmaybe-uninitialized on an unreachable use at -O1

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
I'm not working on this anymore.

[Bug middle-end/95485] missing warning writing into function text

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

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|msebor at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW
 Blocks||87403

--- Comment #5 from Martin Sebor  ---
I'm not working on this anymore.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug middle-end/93848] missing -Warray-bounds warning for array subscript 1 is outside array bounds

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #15 from Martin Sebor  ---
The patch I submitted for this was never reviewed.  I'm not planning to pursue
it anymore.

[Bug debug/82738] [meta-bug] issues with the -Og optimization level

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

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

Bug 101529 Summary: [11 Regression] wrong code with __builtin_convertvector() 
and __builtin_shufflevector() at -Og caused by r11-2192
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101529

   What|Removed |Added

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

[Bug target/101529] [11 Regression] wrong code with __builtin_convertvector() and __builtin_shufflevector() at -Og caused by r11-2192

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
Fixed.

[Bug c++/69698] [meta-bug] flexible array members

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

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

Bug 91462 Summary: [9 Regression] missing -Warray-bounds writing to an empty 
flexible array member in a ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91462

   What|Removed |Added

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

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

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

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

Bug 91462 Summary: [9 Regression] missing -Warray-bounds writing to an empty 
flexible array member in a ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91462

   What|Removed |Added

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

[Bug middle-end/91462] [9 Regression] missing -Warray-bounds writing to an empty flexible array member in a ctor

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Fixed.

[Bug target/101529] [11 Regression] wrong code with __builtin_convertvector() and __builtin_shufflevector() at -Og caused by r11-2192

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

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

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

https://gcc.gnu.org/g:193e5ee46e5a4f0650dc1ccbdaec5d2e84f2a451

commit r11-9515-g193e5ee46e5a4f0650dc1ccbdaec5d2e84f2a451
Author: Andrew Pinski 
Date:   Sat Nov 6 06:29:13 2021 +

aarch64: [PR101529] Fix vector shuffle insertion expansion

The function aarch64_evpc_ins would reuse the target even though
it might be the same register as the two inputs.
Instead of checking to see if we can reuse the target, just use the
original input directly.

Committed as approved after bootstrapped and tested on
aarch64-linux-gnu with no regressions.
Note the testcases are not backported as __builtin_shufflevector
does not exist in GCC 11.

PR target/101529

gcc/ChangeLog:

* config/aarch64/aarch64.c (aarch64_evpc_ins): Don't use target
as an input, use original one.

(cherry picked from commit 52fa771758635d9c53cddb9116e5a66fae592230)

[Bug fortran/104212] ICE in transformational_result, at fortran/simplify.cc:466

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed.

[Bug fortran/104212] ICE in transformational_result, at fortran/simplify.cc:466

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

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

commit r11-9514-gf3c7cb5fb8ade6eb5583d429cb3e99f6fd5fca61
Author: Harald Anlauf 
Date:   Mon Jan 24 21:40:41 2022 +0100

Fortran: optional argument DIM for intrinsics NORM2, PARITY must be scalar

gcc/fortran/ChangeLog:

PR fortran/104212
* check.c (gfc_check_norm2): Check that optional argument DIM is
scalar.
(gfc_check_parity): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/104212
* gfortran.dg/argument_checking_26.f90: New test.

(cherry picked from commit 34e8dafb76240f69c729c11cfc8c8fc4f717bc17)

[Bug middle-end/90404] No warning on attempts to modify a const object

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Sebor  ---
I'm not working on this anymore.

[Bug middle-end/90043] Turn on -Winit-self by default for -Wuninitialized

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
I'm not working on this anymore.

[Bug c++/103984] [12 regression] Possible maybe-uninitialized false positive on shaderc-2021.0 since r12-6329

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c/85931] -Wsizeof-pointer-memaccess for strncpy with size of source

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Presumably fixed by r261515.

[Bug c/103360] [meta-bug] bogus/missing -Waddress

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

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

Bug 33925 Summary: [10/11 Regression] gcc -Waddress lost some useful warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33925

   What|Removed |Added

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

[Bug c++/33925] [10/11 Regression] gcc -Waddress lost some useful warnings

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #12 from Martin Sebor  ---
I'm not planning to backport the GCC 12 changes.

[Bug c/82914] 'struct __attribute__ ((aligned (N))) s' ignores 'aligned' attribute

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
I'm not working on this anymore.

[Bug middle-end/78391] g++ (any version) at O0 (for O1, O2, O3 is ok) doesn't warn when class members are used uninitialized.

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
This has been improved in GCC 12 but GCC still doesn't diagnose the original
test case at -O0.  It seems that it should be able to, either in the C++ front
end or even in the middle end.  I'm not working on this anymore.

[Bug c++/92944] [concepts] redefinition error when using constrained structure template inside namespace

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug driver/81358] libatomic not automatically linked with C11 code

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||mathieu.malaterre at gmail dot 
com

--- Comment #12 from Andrew Pinski  ---
*** Bug 104248 has been marked as a duplicate of this bug. ***

[Bug driver/104248] armel: C11 atomics requires to be linked with libatomic.a explicitly

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Andrew Pinski  ---
Dup of bug 81358.

Note riscv atomics are messed up too(there is a bug report for that).

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

[Bug fortran/104131] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3810

[gscfq--- via Gcc-bugs]

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

--- Comment #2 from G. Steinmetz  ---
And with a coarray :


$ cat zz1.f90
program p
   use iso_c_binding, only: c_intptr_t
   integer, parameter :: omp_event_handle_kind = c_intptr_t
   integer (kind=omp_event_handle_kind) :: x[*]
   !$omp task detach (x)
   !$omp end task
end


$ cat zz2.f90
program p
   use iso_c_binding, only: c_intptr_t
   integer, parameter :: omp_event_handle_kind = c_intptr_t
   integer (kind=omp_event_handle_kind) :: x[*]
   !$omp parallel master default (none)
  !$omp task detach (x)
  !$omp end task
   !$omp end parallel master
end


$ gfortran-12-20220123 -c zz1.f90 -fopenmp -fcoarray=single
zz1.f90:5:24:

5 |!$omp task detach (x)
  |^
internal compiler error: Segmentation fault
0xcc430f crash_signal
../../gcc/toplev.cc:322
0xa229da omp_add_variable
../../gcc/gimplify.cc:7200
0xa32f20 gimplify_scan_omp_clauses
../../gcc/gimplify.cc:10305
0xa267ce gimplify_omp_task
../../gcc/gimplify.cc:12122
0xa267ce gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:15454
0xa29b18 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7035
0xa2a071 gimplify_bind_expr
../../gcc/gimplify.cc:1427
0xa2745a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:15161
0xa29b18 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7035
0xa2ab9b gimplify_body(tree_node*, bool)
../../gcc/gimplify.cc:16206
0xa2afef gimplify_function_tree(tree_node*)
../../gcc/gimplify.cc:16360
0x8b26f7 cgraph_node::analyze()
../../gcc/cgraphunit.cc:675
0x8b50a7 analyze_functions
../../gcc/cgraphunit.cc:1240
0x8b5a6d symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2500

[Bug fortran/103474] ICE in simplify_cobound, at fortran/simplify.c:4415

[gscfq--- via Gcc-bugs]

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

--- Comment #2 from G. Steinmetz  ---
Additionally :


$ cat z3.f90
program p
   type t
  integer :: a
   end type
   class(t) :: x[:]
   if ( any(lcobound(x) < 1) ) stop
end


$ cat zz1.f90
program p
   type t
  integer :: a
   end type
   class(t), allocatable :: x[:]
   print *, lcobound(x%a)
end


$ cat zz2.f90
program p
   type t
  integer :: a(2)
   end type
   class(t), allocatable :: x[:]
   print *, lcobound(x%a)
end


$ gfortran-12-20220123 -c zz1.f90 -fcoarray=single   # release version
f951: internal compiler error: in simplify_cobound, at fortran/simplify.cc:4383
0x77ac55 simplify_cobound
../../gcc/fortran/simplify.cc:4383
0x70210a do_simplify
../../gcc/fortran/intrinsic.cc:4676
0x70cfea gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.cc:5055
0x761368 resolve_unknown_f
../../gcc/fortran/resolve.cc:2972
0x761368 resolve_function
../../gcc/fortran/resolve.cc:3329
0x761368 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7169
0x767754 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7136
0x767754 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.cc:11928
0x76610f gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.cc:10944
0x766468 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.cc:11918
0x768da7 resolve_codes
../../gcc/fortran/resolve.cc:17537
0x768e6e gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.cc:17572
0x751194 resolve_all_program_units
../../gcc/fortran/parse.cc:6586
0x751194 gfc_parse_file()
../../gcc/fortran/parse.cc:6842
0x79e86f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:216

[Bug middle-end/104075] bogus/missing -Wuse-after-free

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

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

Bug 104213 Summary: [12 Regression] bogus use-after-free in virtual dtor with 
-ffat-lto-objects on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104213

   What|Removed |Added

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

[Bug target/104213] [12 Regression] bogus use-after-free in virtual dtor with -ffat-lto-objects on ARM

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #14 from Marek Polacek  ---
Fixed.

[Bug fortran/101101] ICE in gfc_build_array_type, at fortran/trans-types.c:1391

[gscfq--- via Gcc-bugs]

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

--- Comment #2 from G. Steinmetz  ---
Alternatives :


$ cat zz1.f90
program p
   class(*), pointer :: x
   dimension :: x(:)
end


$ cat zz2.f90
program p
   class(*) :: x(:)
   pointer :: x
end


$ gfortran-12-20220123 -c zz1.f90
f951: internal compiler error: Segmentation fault
0xcc430f crash_signal
../../gcc/toplev.cc:322
0x672cc7 resolve_fl_var_and_proc
../../gcc/fortran/resolve.cc:12866
0x76ace6 resolve_fl_variable
../../gcc/fortran/resolve.cc:13012
0x76ace6 resolve_symbol
../../gcc/fortran/resolve.cc:16096
0x789642 do_traverse_symtree
../../gcc/fortran/symbol.cc:4174
0x76d9c4 resolve_types
../../gcc/fortran/resolve.cc:17455
0x768e5c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.cc:17570
0x751194 resolve_all_program_units
../../gcc/fortran/parse.cc:6586
0x751194 gfc_parse_file()
../../gcc/fortran/parse.cc:6842
0x79e86f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:216


$ gfortran-12-20220123 -c zz2.f90
zz2.f90:4:3:

4 | end
  |   1
internal compiler error: Segmentation fault
0xcc430f crash_signal
../../gcc/toplev.cc:322
0x6ee9b1 free_expr0
../../gcc/fortran/expr.cc:446
0x6eeb18 gfc_free_expr(gfc_expr*)
../../gcc/fortran/expr.cc:530
0x6b9fce gfc_free_array_spec(gfc_array_spec*)
../../gcc/fortran/array.cc:352
0x78fd1f free_components
../../gcc/fortran/symbol.cc:2606
0x78fd1f gfc_free_symbol(gfc_symbol*&)
../../gcc/fortran/symbol.cc:3078
0x78fe79 gfc_release_symbol(gfc_symbol*&)
../../gcc/fortran/symbol.cc:3127
0x78ff4e free_sym_tree
../../gcc/fortran/symbol.cc:3904
0x78ff3c free_sym_tree
../../gcc/fortran/symbol.cc:3901
0x78faf0 gfc_free_namespace(gfc_namespace*&)
../../gcc/fortran/symbol.cc:4043
0x790209 gfc_symbol_done_2()
../../gcc/fortran/symbol.cc:4105
0x728008 gfc_done_2()
../../gcc/fortran/misc.cc:382
0x751818 translate_all_program_units
../../gcc/fortran/parse.cc:6670
0x751818 gfc_parse_file()
../../gcc/fortran/parse.cc:6938
0x79e86f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:216