date:20230628

[Bug tree-optimization/110474] New: Vect: the epilog vect loop should have small VF if the loop is unrolled during vectorization

2023-06-28 Thread hliu at amperecomputing dot com via Gcc-bugs

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

Bug ID: 110474
   Summary: Vect: the epilog vect loop should have small VF if the
loop is unrolled during vectorization
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hliu at amperecomputing dot com
  Target Milestone: ---

Hi, I'm trying to use tune loop unrolling during vectorization (see more:
tree-vect-loop.cc suggested_unroll_factor). I find the unrolling may hurt
performance as unrolling also increases the VF (vector factor) of epilog vect
loop.

For example:
int foo(short *A, char *B, int N) {
int sum = 0;
for (int i = 0; i < N; ++i) {
sum += A[i] * B[i];
}
return sum;
}


Compile it with "-O3 -mtune=neoverse-n2 -mcpu=neoverse-n1 --param
aarch64-vect-unroll-limit=2" (I'm using -mcpu n1 as I want to try a target
without SVE). GCC vectorization pass unrolls the loop by 2 and generates code
as following:

if N >= 32:
main vect loop ...

if N >= 16:   # This may hurt performance if N is small (e.g. 8)
epilog vect loop ...

epilog scalar code ...


If the loop is not unrolled (i.e. use "--param aarch64-vect-unroll-limit=1").
GCC generates code as following:

if N >= 16:
main vect loop ...

if N >= 8:
epilog vect loop ...

epilog scalar code ...


The runtime check is based on the VF of epilog vectorization. There is code in
tree-vect-loop.cc (line 2990) to choose epilog vect VF:
  /* If we're vectorizing an epilogue loop, the vectorized loop either needs
 to be able to handle fewer than VF scalars, or needs to have a lower VF
 than the main loop.  */
  if (LOOP_VINFO_EPILOGUE_P (loop_vinfo)
  && !LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo)
  && maybe_ge (LOOP_VINFO_VECT_FACTOR (loop_vinfo),
   LOOP_VINFO_VECT_FACTOR (orig_loop_vinfo)))
return opt_result::failure_at (vect_location,
   "Vectorization factor too high for"
   " epilogue loop.\n");

But it doesn't consider about the suggested_unroll_factor. So I'm thinking
about adding following code to unscale the orig_loop_vinfo's VF by
unroll_factor:
  unscaled_orig_vf = exact_div (LOOP_VINFO_VECT_FACTOR (orig_loop_vinfo),
orig_loop_vinfo->suggested_unroll_factor);

Is this reasonable?

[Bug target/110473] New: vec_convert for aarch64 seems to lower to something which should be improved

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 110473
   Summary: vec_convert for aarch64 seems to lower to something
which should be improved
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Take:
```
typedef unsigned int v4si __attribute__ ((vector_size (4*sizeof(int;
typedef unsigned short v4hi __attribute__ ((vector_size (4*sizeof(short;

v4si f(v4si a, v4si b)
{
  v4hi t = __builtin_convertvector (a, v4hi);
  v4si t1 = __builtin_convertvector (t, v4si);
  return t1;
}
```

This gets lowered in veclower21 to
```
  _6 = BIT_FIELD_REF <_5, 64, 0>;
  t_2 = _6;
  _7 = BIT_FIELD_REF ;
  _8 = (unsigned int) _7;
  _9 = BIT_FIELD_REF ;
  _10 = (unsigned int) _9;
  _11 = BIT_FIELD_REF ;
  _12 = (unsigned int) _11;
  _13 = BIT_FIELD_REF ;
  _14 = (unsigned int) _13;
  t1_3 = {_8, _10, _12, _14};
```

And then forwprop optimizes this to:
```
  _6 = BIT_FIELD_REF <_5, 64, 0>;
  t1_3 = (v4si) _6;
```

And then combine comes along and optimizes that to:
(insn 9 8 11 2 (set (reg:V8HI 98)
(vec_concat:V8HI (truncate:V4HI (reg:V4SI 102))
(const_vector:V4HI [
(const_int 0 [0]) repeated x4
]))) "/app/example.cpp":7:8 5467
{truncv4siv4hi2_vec_concatz_le}
 (expr_list:REG_DEAD (reg:V4SI 102)
(nil)))
(note 11 9 16 2 NOTE_INSN_DELETED)
(insn 16 11 17 2 (set (reg/i:V4SI 32 v0)
(sign_extend:V4SI (subreg:V4HI (reg:V8HI 98) 0)))
"/app/example.cpp":10:1 5459 {extendv4hiv4si2}
 (expr_list:REG_DEAD (reg:V8HI 98)
(nil)))

But the first one is basically just (truncate:V4HI (reg:V4SI 102)) (due to the
way the instruction works, the top parts is also zeros).
So we get in the end:
xtn v0.4h, v0.4s
sxtlv0.4s, v0.4h

Why couldn't vectlower could just do:
```
_6 = (v4hi)a_1(D);
t1_3 = (v4si) _6;
```
In the first place instead of depending on later optimizations (at least handle
the second part)?

note with the above lowering we might hit an issue in match.pd where it is
trying to turn that into t1_3 = t1_3 = {0x,0x,0x,0x} & _6;
(both because of TYPE_PRECISION and because it just uses wide_int_to_tree ...

[Bug tree-optimization/110461] [14 regression] ICE when building openh264 with new vector_type checking

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #10 from Andrew Pinski  ---
I audited match.pd and only one other sticks out but I can't get get it to
happen.
The other one should have happened with:
```
typedef int v4si __attribute__ ((vector_size (4*sizeof(int;
typedef short v4hi __attribute__ ((vector_size (4*sizeof(short;

v4si f(v4si a, v4si b)
{
  v4hi t = __builtin_convertvector (a, v4hi);
  v4si t1 = __builtin_convertvector (t, v4si);
  return t1;
}
```

But VEC_CONVERT gets lowered to something interesting (which I will put in a
different bug report).

[Bug tree-optimization/110449] Vect: use a small step to calculate the loop induction if the loop is unrolled during loop vectorization

2023-06-28 Thread hliu at amperecomputing dot com via Gcc-bugs

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

--- Comment #2 from Hao Liu  ---
That looks better than the currently generated code (it saves one "MOV"
instruction). Yes, it has the loop-carried dependency advantage. But it still
uses one more register for "8*step" (There may be a register pressure problem
for complicated code, not for this simple case). 

This is still a floating point precision problem. There is a PR84201 discussed
about the same problem for X86:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84201. The larger step makes the
floating point calculation result has larger gap compared to the original
scalar calculation result. E.g. The SPEC2017 fp benchmark 549.fotonik may
result in VE (Validation Error) after unrolling a loop of double: 
   319do ifreq = 1, tmppower%nofreq <-- HERE
   320  frequency(ifreq,ipower) = freq
   321  freq = freq + freqstep
   322end do

it uses 4*step for unrolled vectorization version other than the 2*step for
non-unrolled vectorization version. The SPEC fp result checks the "relative
tolerance" of the fp results and it is higher than the current standard (i.e.
the compare command line option of "--reltol 1e-10").

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

2023-06-28 Thread hjl.tools at gmail dot com via Gcc-bugs

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #55409|0   |1
is obsolete||

--- Comment #23 from H.J. Lu  ---
Created attachment 55424
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55424=edit
An updated patch

[Bug middle-end/110472] 60% slowdown with fwrapv when using openmp

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu

--- Comment #1 from Andrew Pinski  ---
I think it is just wrong iv-opt choices.

Works just fine on aarch64-linux-gnu too:
ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ~/upstream-gcc/bin/gcc t4.c -O2
-fopenmp
ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ./a.out ;echo
time: 15.191220
ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ~/upstream-gcc/bin/gcc t4.c -O2
-fopenmp -fwrapv
ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ./a.out ;echo
time: 18.854280
ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ./a.out ;echo
time: 16.705876
ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ~/upstream-gcc/bin/gcc t4.c -O2
-fopenmp
ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ./a.out ;echo
time: 17.491387
ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ./a.out ;echo
time: 17.519264

[Bug tree-optimization/110472] New: 60% slowdown with fwrapv when using openmp

2023-06-28 Thread ryanpholt at me dot com via Gcc-bugs

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

Bug ID: 110472
   Summary: 60% slowdown with fwrapv when using openmp
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryanpholt at me dot com
  Target Milestone: ---

Created attachment 55423
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55423=edit
Reproduction file

Compiling the attached example with -fwrapv inhibits some optimizations and 
results in a massive slowdown. It appears to be related to the use of OpenMP. I
know that fwrapv can result in slowdowns; however, I do not believe that it
needs to in this example.

In the loop nest below, gcc appears to believe the computations with the loop
induction variables (ex. 'i2 = i * 21504 + i1 * 96;') will overflow. However,
the code is looping over fixed size data and so I believe gcc should be able to
determine that overflow is not possible. Perhaps some range analysis stops
working across the openmp runtime boundary? The issue is fixed if I remove the
openmp pragma.

The issue is also fixed if I change the loop induction variables to be declared
as int64_t rather than int.

I also tried clang16 and did not observe the issue with fwrapv.

#pragma omp parallel for \
 num_threads(omp_get_max_threads()) \
 private(i1,u0,b_u0,i2,i3,i4,i5,i6,i7,i8,i10,i12,i14,i15) \
 firstprivate(r2)

  for (i = 0; i < 7; i++) {

for (i1 = 0; i1 < 7; i1++) {
  u0 = i * -32 + 222;
  if (u0 > 32) {
u0 = 32;
  }

  b_u0 = i1 * -32 + 222;
  if (b_u0 > 32) {
b_u0 = 32;
  }

  i2 = i * 21504 + i1 * 96;
  i3 = i * 227328 + (i1 << 10);
  for (i4 = 0; i4 < u0; i4++) {
for (i5 = 0; i5 < b_u0; i5++) {
  for (i6 = 0; i6 < 3; i6++) {
i7 = i5 + i6;
for (i8 = 0; i8 < 3; i8++) {
  for (i10 = 0; i10 < 3; i10++) {
i12 = i4 + i10;
for (i14 = 0; i14 < 32; i14++) {
  i15 = ((i3 + 7104 * i4) + (i5 << 5)) + i14;
  (r2)[i15] += ((float *)_0[0][0][0][0])[((i2 + 672 * i12) +
3 *
i7) + i8] * ((float *)&__constant_3x3x3x32xf32[0][0][0][0])
[((288 * i10 + 96 * i6) + (i8 << 5)) + i14];
}
  }
}
  }
}
  }
}
  }


Repro:
gcc -O3 -fopenmp -lpthread -fwrapv predict.i
./a.out

(Remove the -fwrapv to observe a major speedup)



Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210110 (Debian 10.2.1-6) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-fopenmp' '-fwrapv'
'-mtune=generic' '-march=x86-64' '-pthread'
 /usr/lib/gcc/x86_64-linux-gnu/10/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu
-D_REENTRANT main.c -mtune=generic -march=x86-64 -fopenmp -fwrapv -O3
-fpch-preprocess -fasynchronous-unwind-tables -o main.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/10/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/10/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-fopenmp'

[Bug rtl-optimization/110237] gcc.dg/torture/pr58955-2.c is miscompiled by RTL scheduling after reload

2023-06-28 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #25 from CVS Commits  ---
The releases/gcc-13 branch has been updated by hongtao Liu
:

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

commit r13-7500-g8b059560146a93e5174262fef25e8b1aa39bb879
Author: liuhongt 
Date:   Mon Jun 26 21:07:09 2023 +0800

Refine maskstore patterns with UNSPEC_MASKMOV.

Similar like r14-2070-gc79476da46728e

If mem_addr points to a memory region with less than whole vector size
bytes of accessible memory and k is a mask that would prevent reading
the inaccessible bytes from mem_addr, add UNSPEC_MASKMOV to prevent
it to be transformed to any other whole memory access instructions.

gcc/ChangeLog:

PR rtl-optimization/110237
* config/i386/sse.md (_store_mask): Refine with
UNSPEC_MASKMOV.
(maskstore_store_mask): New define_insn, it's renamed
from original _store_mask.

[Bug target/110309] Wrong code for masked load expansion

2023-06-28 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-13 branch has been updated by hongtao Liu
:

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

commit r13-7499-gecc1af1f5b2c0fbcfa8840c79aa6102d413850b2
Author: liuhongt 
Date:   Tue Jun 20 15:41:00 2023 +0800

Refine maskloadmn pattern with UNSPEC_MASKLOAD.

If mem_addr points to a memory region with less than whole vector size
bytes of accessible memory and k is a mask that would prevent reading
the inaccessible bytes from mem_addr, add UNSPEC_MASKLOAD to prevent
it to be transformed to vpblendd.

gcc/ChangeLog:

PR target/110309
* config/i386/sse.md (maskload):
Refine pattern with UNSPEC_MASKLOAD.
(maskload): Ditto.
(*_load_mask): Extend mode iterator to
VI12HFBF_AVX512VL.
(*_load): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr110309.c: New test.

[Bug rtl-optimization/110237] gcc.dg/torture/pr58955-2.c is miscompiled by RTL scheduling after reload

2023-06-28 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #24 from CVS Commits  ---
The releases/gcc-12 branch has been updated by hongtao Liu
:

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

commit r12-9743-ga435939ba7e5e489a422071014f943c1a577bfe6
Author: liuhongt 
Date:   Mon Jun 26 21:07:09 2023 +0800

Refine maskstore patterns with UNSPEC_MASKMOV.

Similar like r14-2070-gc79476da46728e

If mem_addr points to a memory region with less than whole vector size
bytes of accessible memory and k is a mask that would prevent reading
the inaccessible bytes from mem_addr, add UNSPEC_MASKMOV to prevent
it to be transformed to any other whole memory access instructions.

gcc/ChangeLog:

PR rtl-optimization/110237
* config/i386/sse.md (_store_mask): Refine with
UNSPEC_MASKMOV.
(maskstore_store_mask): New define_insn, it's renamed
from original _store_mask.

[Bug target/110309] Wrong code for masked load expansion

2023-06-28 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by hongtao Liu
:

https://gcc.gnu.org/g:1f5591a9578b8cacda9d4c73a25d93598d68e028

commit r12-9742-g1f5591a9578b8cacda9d4c73a25d93598d68e028
Author: liuhongt 
Date:   Tue Jun 20 15:41:00 2023 +0800

Refine maskloadmn pattern with UNSPEC_MASKLOAD.

If mem_addr points to a memory region with less than whole vector size
bytes of accessible memory and k is a mask that would prevent reading
the inaccessible bytes from mem_addr, add UNSPEC_MASKLOAD to prevent
it to be transformed to vpblendd.

gcc/ChangeLog:

PR target/110309
* config/i386/sse.md (maskload):
Refine pattern with UNSPEC_MASKLOAD.
(maskload): Ditto.
(*_load_mask): Extend mode iterator to
VI12HF_AVX512VL.
(*_load): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr110309.c: New test.

[Bug rtl-optimization/110237] gcc.dg/torture/pr58955-2.c is miscompiled by RTL scheduling after reload

2023-06-28 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #23 from CVS Commits  ---
The releases/gcc-11 branch has been updated by hongtao Liu
:

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

commit r11-10884-gad1a3da97f7c4a85778f91b235a8d936bb1c829b
Author: liuhongt 
Date:   Mon Jun 26 21:07:09 2023 +0800

Refine maskstore patterns with UNSPEC_MASKMOV.

Similar like r14-2070-gc79476da46728e

If mem_addr points to a memory region with less than whole vector size
bytes of accessible memory and k is a mask that would prevent reading
the inaccessible bytes from mem_addr, add UNSPEC_MASKMOV to prevent
it to be transformed to any other whole memory access instructions.

gcc/ChangeLog:

PR rtl-optimization/110237
* config/i386/sse.md (_store_mask): Refine with
UNSPEC_MASKMOV.
(maskstore_store_mask): New define_insn, it's renamed
from original _store_mask.

[Bug target/110309] Wrong code for masked load expansion

2023-06-28 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by hongtao Liu
:

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

commit r11-10883-gf59565f5dc2cdb5ac5a0b2b75404a36771232f86
Author: liuhongt 
Date:   Tue Jun 20 15:41:00 2023 +0800

Refine maskloadmn pattern with UNSPEC_MASKLOAD.

If mem_addr points to a memory region with less than whole vector size
bytes of accessible memory and k is a mask that would prevent reading
the inaccessible bytes from mem_addr, add UNSPEC_MASKLOAD to prevent
it to be transformed to vpblendd.

gcc/ChangeLog:

PR target/110309
* config/i386/sse.md (maskload):
Refine pattern with UNSPEC_MASKLOAD.
(maskload): Ditto.

[Bug c++/110468] [12/13/14 regression] Internal compiler error in nothrow_spec_p

2023-06-28 Thread gococobu at 7art dot org via Gcc-bugs

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

--- Comment #11 from gococobu at 7art dot org ---
Thank you very much for your work, Andrew. I'll remove the files from the
posted URL now.

[Bug c++/110468] [12/13/14 regression] Internal compiler error in nothrow_spec_p

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||10.4.0, 11.4.0
   Target Milestone|--- |12.4
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed|2023-06-28 00:00:00 |2023-06-29
  Known to fail||12.1.0, 12.3.0, 13.1.0,
   ||14.0

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

Note in the reduced testcase, m needs to be a template, variant needs to be a
template but not depedent and hh::value needs to be a value depedent.
Also note it works with -std=c++11 .

Slightly more reduced, changing `hh::value` to just `T>0` as mentioned it
just needs to be value depedent:
```
template  struct variant {
  variant() noexcept(T>0) {}
};
template  
struct m {
  variant<1> def{};
};
struct v {
  v(m<1>);
};
v t = {{}};
```

[Bug c++/110468] [12/13/14 regression] Internal compiler error in nothrow_spec_p

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #9 from Andrew Pinski  ---
Created attachment 55422
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55422=edit
Reduced testcase

Attached is the reduced testcase (which was modified back to be valid).

[Bug jit/110466] jit.dg FAILs on ppc64le

2023-06-28 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from David Malcolm  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > (In reply to David Malcolm from comment #3)
> > > 
> > >   Reading symbols from
> > > /home/dmalcolm/build/gcc/testsuite/jit4/jit-debuginfo.o...Dwarf Error: 
> > > wrong
> > > version in compilation unit header (is 5, should be 2, 3, or 4) [in module
> > > /home/dmalcolm/build/gcc/testsuite/jit4/jit-debuginfo.o]
> > > 
> > > though I'm not sure if that's the cause of the error.
> > 
> > Those look depedenent on the binutils version that is in use. I suspect if
> > there is a newer version of binutils installed, it would just work. Dwarf5
> > was added to binutils version 2.35.2 . Though maybe it is finding the wrong
> > readelf ...
> 
> Or rather it is gdb that is complaining and a newer gdb version is needed.

Yeah; I think the gdb version is too old.

Adding the following patch turns this into an "unsupported" (on this host, at
least):

diff --git a/gcc/testsuite/jit.dg/jit.exp b/gcc/testsuite/jit.dg/jit.exp
index 3568dbb..8bf7e51 100644
--- a/gcc/testsuite/jit.dg/jit.exp
+++ b/gcc/testsuite/jit.dg/jit.exp
@@ -440,6 +440,10 @@ proc jit-check-debug-info { obj_file cmds match } {
 send $cmd
 }
 expect {
+   -re "Dwarf Error: wrong version in compilation unit header" {
+   set testcase [testname-for-summary]
+   unsupported "$testcase: gdb does not support dwarf version"
+   }
 -re $match { pass OK }
 default { fail FAIL }
 }

I'll try the combination of these patches on my regular x86_64 workstation...

[Bug tree-optimization/110461] [14 regression] ICE when building openh264 with new vector_type checking

2023-06-28 Thread seurer at gcc dot gnu.org via Gcc-bugs

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #9 from seurer at gcc dot gnu.org ---
I am seeing probably the same error with one gcc test case and it started with 

g:fe48f2651334bc4d96b6df6b2bb6b29fcb732a83, r14-2150-gfe48f2651334bc

as that wasn't mentioned here that I saw.

make  -k check-gcc RUNTESTFLAGS="compile.exp=gcc.c-torture/compile/pr46883.c"
FAIL: gcc.c-torture/compile/pr46883.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error: tree check:
expected none of vector_type, have vector_type in vect_recog_rotate_pattern, at
tree-vect-patterns.cc:3634)
FAIL: gcc.c-torture/compile/pr46883.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gcc.c-torture/compile/pr46883.c   -O3 -g  (internal compiler error: tree
check: expected none of vector_type, have vector_type in
vect_recog_rotate_pattern, at tree-vect-patterns.cc:3634)
FAIL: gcc.c-torture/compile/pr46883.c   -O3 -g  (test for excess errors)
# of expected passes6
# of unexpected failures4

spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ -fdiagnostics-plain-output -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions -w
-c -o pr46883.o
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.c-torture/compile/pr46883.c
during GIMPLE pass: slp
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.c-torture/compile/pr46883.c: In
function 'bar':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.c-torture/compile/pr46883.c:1:6:
internal compiler error: tree check: expected none of vector_type, have
vector_type in vect_recog_rotate_pattern, at tree-vect-patterns.cc:3634
0x10291b5f tree_not_check_failed(tree_node const*, char const*, int, char
const*, ...)
/home/seurer/gcc/git/gcc-test/gcc/tree.cc:8936
0x11b9f833 tree_not_check(tree_node*, char const*, int, char const*, tree_code)
/home/seurer/gcc/git/gcc-test/gcc/tree.h:3581
0x11b9f833 vect_recog_rotate_pattern
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-patterns.cc:3634
0x11b9cdeb vect_pattern_recog_1
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-patterns.cc:6834
0x11ba5387 vect_pattern_recog(vec_info*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-patterns.cc:6991
0x110a001f vect_slp_analyze_bb_1
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:7353
0x110a001f vect_slp_region
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:7462
0x110a2733 vect_slp_bbs
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:7653
0x110a2b7b vect_slp_function(function*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:7754
0x110b1b73 execute
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1529

[Bug tree-optimization/110461] [14 regression] ICE when building openh264 with new vector_type checking

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from Andrew Pinski  ---
(In reply to David Binderman from comment #7)
> I get something similar with -O1 -march=znver1. 
> 
> The problem seems to have started in the last couple of days:

Yes it is exactly the same issue. Also it started with r14-2150-gfe48f2651334bc
(which just added the extra checking to make sure TYPE_PRECISION was not being
used for vector types).

[Bug driver/110408] [13/14 Regression] gcc 13 crashes with %rename in specs

2023-06-28 Thread brjd_epdjq36 at kygur dot com via Gcc-bugs

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

Brjd  changed:

   What|Removed |Added

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

--- Comment #2 from Brjd  ---
Please ignore it. I test it more and find out that it is my misunderstanding
that I can make it the default specs if I use the %rename option. However, the
compiler is not designed in this way.

Please tell if there are other options. AFAIK currently there are two options
to change the specs behavior. 

First, I can override only a part of the specs file with the %rename option.
The shortage here is that it is not the default and I should invoke it manually
every time by the -specs=/path-to-my-specs-file.

The second way is a rebuild of the GCC or changes in the whole specs file. This
is the way I can set the default without invoking in the command line
-specs=/path-to-my-specs-file.

I do the first one and that causes the error since I use the GCC without
-specs. The compiler simply replaces the whole specs with my custom overriding
specs and fails.

[Bug tree-optimization/110461] [14 regression] ICE when building openh264 with new vector_type checking

2023-06-28 Thread dcb314 at hotmail dot com via Gcc-bugs

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #7 from David Binderman  ---
I get something similar with -O1 -march=znver1. 

The problem seems to have started in the last couple of days:

../results.20230626.asan.ubsan/bin/gcc
../results.20230628.asan.ubsan/bin/gcc
during GIMPLE pass: fre
buildData/keep/in.14426.c: In function ‘func_63’:
buildData/keep/in.14426.c:465:18: internal compiler error: tree check: expected
none of vector_type, have vector_type in gimple_simplify_144, at
gimple-match-3.cc:1027
0x11656f9 tree_not_check_failed(tree_node const*, char const*, int, char
const*, ...)
../../trunk.year/gcc/tree.cc:8936
0x1dc7c8b gimple_simplify_144(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node*, tree_node**, tree_code)
/home/dcb38/gcc/working/gcc/gimple-match-3.cc:1027

[Bug target/110144] cris-unknown-elf cross build fails with ICE if RTL checking is enabled

2023-06-28 Thread hp at gcc dot gnu.org via Gcc-bugs

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

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

--- Comment #3 from Hans-Peter Nilsson  ---
JFTR, the committed patch, passed a "full" regtest for cris-elf with
--enable-checking=yes,rtl, not just for --enable-languages=c.

[Bug jit/110466] jit.dg FAILs on ppc64le

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to David Malcolm from comment #3)
> > 
> >   Reading symbols from
> > /home/dmalcolm/build/gcc/testsuite/jit4/jit-debuginfo.o...Dwarf Error: wrong
> > version in compilation unit header (is 5, should be 2, 3, or 4) [in module
> > /home/dmalcolm/build/gcc/testsuite/jit4/jit-debuginfo.o]
> > 
> > though I'm not sure if that's the cause of the error.
> 
> Those look depedenent on the binutils version that is in use. I suspect if
> there is a newer version of binutils installed, it would just work. Dwarf5
> was added to binutils version 2.35.2 . Though maybe it is finding the wrong
> readelf ...

Or rather it is gdb that is complaining and a newer gdb version is needed.

[Bug jit/110466] jit.dg FAILs on ppc64le

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Andrew Pinski  ---
(In reply to David Malcolm from comment #3)
> 
>   Reading symbols from
> /home/dmalcolm/build/gcc/testsuite/jit4/jit-debuginfo.o...Dwarf Error: wrong
> version in compilation unit header (is 5, should be 2, 3, or 4) [in module
> /home/dmalcolm/build/gcc/testsuite/jit4/jit-debuginfo.o]
> 
> though I'm not sure if that's the cause of the error.

Those look depedenent on the binutils version that is in use. I suspect if
there is a newer version of binutils installed, it would just work. Dwarf5 was
added to binutils version 2.35.2 . Though maybe it is finding the wrong readelf
...

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

2023-06-28 Thread xry111 at gcc dot gnu.org via Gcc-bugs

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

--- Comment #22 from Xi Ruoyao  ---
(In reply to H.J. Lu from comment #19)

> Do you have a testcase?

Attached.

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

2023-06-28 Thread xry111 at gcc dot gnu.org via Gcc-bugs

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

--- Comment #21 from Xi Ruoyao  ---
Created attachment 55421
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55421=edit
test case broken by draft patch (at -O2 -mavx2 -mtune=haswell)

[Bug jit/110466] jit.dg FAILs on ppc64le

2023-06-28 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from David Malcolm  ---
With the above fix, the remaining failures are:

FAIL: FAIL
FAIL: FAIL
FAIL: FAIL

which are from testdebuginfo.c; I see:

  Reading symbols from
/home/dmalcolm/build/gcc/testsuite/jit4/jit-debuginfo.o...Dwarf Error: wrong
version in compilation unit header (is 5, should be 2, 3, or 4) [in module
/home/dmalcolm/build/gcc/testsuite/jit4/jit-debuginfo.o]

though I'm not sure if that's the cause of the error.

[Bug c++/78632] Produce warning when a derived class shadows a field of the base class with `-Wshadow`

2023-06-28 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Marek Polacek  ---
Looks like clang++ has -Wshadow-field for this.

[Bug tree-optimization/103680] Jump threading and switch corrupts profile

2023-06-28 Thread hubicka at gcc dot gnu.org via Gcc-bugs

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

--- Comment #9 from Jan Hubicka  ---
bug 25623 comment #1 is different since __builtin_abort makes initial guessed
profile inconsistent with the correlated conditionals.

That is reason why I added explicit __builtin_expect_with_probability to make
the profile consistent. This is bug that got in after one of several threading
rewrites.

[Bug tree-optimization/25623] jump threading/cfg cleanup messes up "incoming counts" for some BBs

2023-06-28 Thread hubicka at gcc dot gnu.org via Gcc-bugs

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #9 from Jan Hubicka  ---
In this testcase:

void rs6000_emit_move (int mode, int t, int tt)
{
  if (t == 1)
if (mode != 2)
  t = ();
  if (t == 1)
if (mode != 2)
__builtin_abort ();
}

The profile update can not go right.  

At the branch prediction time, the first two conditionals are predicted with
some probability close to 50% since the branch predictor can not derive much
about them.

However the last conditional is predicted with very small probability since it
calls 0.  Then the call to () gets higher frequency than call to
__builtin_abort.

Later we discover by jump threading that builtin_abort happens iff the call of
(), so the profile was inconsistent from start, just not in obvious way.
update_bb_profile_for_threading should print out reason into dump file.

[Bug d/110471] New: d: Don't generate code that throws exceptions when compiling with `-fno-exceptions'

2023-06-28 Thread ibuclaw at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 110471
   Summary: d: Don't generate code that throws exceptions when
compiling with `-fno-exceptions'
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gcc dot gnu.org
  Target Milestone: ---

The predefined version conditions D_ModuleInfo, D_Exceptions, and D_TypeInfo
were added in r9-7112.  However individual feature flags do not turn off these
versions.

For example. this should succeed compilation.

// { dg-options "-fno-exceptions" }
version (D_Exceptions)
static assert(false);  // expected to never trigger.

[Bug rtl-optimization/110470] New: Test gcc.c-torture/execute/pr105613.c ICEs in prepare_cmp_insn on s390x with -march=z14

2023-06-28 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 110470
   Summary: Test gcc.c-torture/execute/pr105613.c ICEs in
prepare_cmp_insn on s390x with -march=z14
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Take gcc.c-torture/execute/pr105613.c:

$ ./cc1 -quiet pr105613.c -Iinclude -march=z13
$ ./cc1 -quiet pr105613.c -Iinclude -march=z14
during RTL pass: expand
pr105613.c: In function ‘foo’:
pr105613.c:9:10: internal compiler error: in prepare_cmp_insn, at
optabs.cc:4609
9 |   *r = v != 0;
  |~~^~~~
0x6c59a6 prepare_cmp_insn
/home/mpolacek/src/gcc/gcc/optabs.cc:4609
0xd2055f emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, tree_node*, rtx_def*, profile_probability)
/home/mpolacek/src/gcc/gcc/optabs.cc:4824
0x9fbed9 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int, tree_node*,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, profile_probability)
/home/mpolacek/src/gcc/gcc/dojump.cc:1238
0x9fd63a do_jump
/home/mpolacek/src/gcc/gcc/dojump.cc:620
0xaa22d7 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/mpolacek/src/gcc/gcc/expr.cc:10274
0x988a40 expand_gimple_stmt_1
/home/mpolacek/src/gcc/gcc/cfgexpand.cc:3983
0x988a40 expand_gimple_stmt
/home/mpolacek/src/gcc/gcc/cfgexpand.cc:4044
0x98d9a6 expand_gimple_basic_block
/home/mpolacek/src/gcc/gcc/cfgexpand.cc:6096
0x98f447 execute
/home/mpolacek/src/gcc/gcc/cfgexpand.cc:6831

[Bug target/110144] cris-unknown-elf cross build fails with ICE if RTL checking is enabled

2023-06-28 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Hans-Peter Nilsson :

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

commit r14-2173-gc15905da939fd5cf6ccc3f19f3ab273525f34f98
Author: Hans-Peter Nilsson 
Date:   Wed Jun 28 03:01:08 2023 +0200

CRIS: Don't apply PATTERN to insn before validation (PR 110144)

Oops.  The validation was there, but PATTERN was applied
before that.  Noticeable only with rtl-checking (for example
as in the report: "--enable-checking=yes,rtl") as this
statement was only a (one of many) straggling olde-C
declare-and-initialize-at-beginning-of-block thing.

PR target/110144
* config/cris/cris.cc (cris_postdbr_cmpelim): Don't apply PATTERN
to insn before validating it.

[Bug c++/110468] internal compiler error in nothrow_spec_p (g++ > 11)

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from Andrew Pinski  ---
(In reply to gococobu from comment #7)
> Being a newbie, I don't want to add too much noise to this... but the ICE
> doesn't appear when `multivar def` doesn't have any initializer. If assigned
> (or with brace enclosed init), it does crash, even if done explicitly (i.e.
> ` = boost::variant()`).

No that gives a hint of what might be going on internally. In fact the
backtrace inside the compiler does have references to nsdmi even.

[Bug c++/110468] internal compiler error in nothrow_spec_p (g++ > 11)

2023-06-28 Thread gococobu at 7art dot org via Gcc-bugs

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

--- Comment #7 from gococobu at 7art dot org ---
Being a newbie, I don't want to add too much noise to this... but the ICE
doesn't appear when `multivar def` doesn't have any initializer. If assigned
(or with brace enclosed init), it does crash, even if done explicitly (i.e. ` =
boost::variant()`).

[Bug ipa/110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming

2023-06-28 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #17 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

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

commit r14-2172-gd88fd2e1d0720e6f892da9ff48e9a301a7ad0ad4
Author: Jan Hubicka 
Date:   Wed Jun 28 23:05:28 2023 +0200

Enable early inlining into always_inline functions

Early inliner currently skips always_inline functions and moreover we
ignore
calls from always_inline in ipa_reverse_postorder.  This leads to disabling
most of propagation done using early optimization that is quite bad when
early inline functions are not leaf functions, which is now quite common
in libstdc++.

This patch instead of fully disabling the inline checks calls in callee.
I am quite conservative about what can be inlined as this patch is bit
touchy anyway.  To avoid problems with always_inline being optimized
after early inline I extended inline_always_inline_functions to lazilly
compute fnsummary when needed.

gcc/ChangeLog:

PR middle-end/110334
* ipa-fnsummary.h (ipa_fn_summary): Add
safe_to_inline_to_always_inline.
* ipa-inline.cc (can_early_inline_edge_p): ICE
if SSA is not built; do cycle checking for
always_inline functions.
(inline_always_inline_functions): Be recrusive;
watch for cycles; do not updat overall summary.
(early_inliner): Do not give up on always_inlines.
* ipa-utils.cc (ipa_reverse_postorder): Do not skip
always inlines.

gcc/testsuite/ChangeLog:

PR middle-end/110334
* g++.dg/opt/pr66119.C: Disable early inlining.
* gcc.c-torture/compile/pr110334.c: New test.
* gcc.dg/tree-ssa/pr110334.c: New test.

[Bug jit/110466] jit.dg FAILs on ppc64le

2023-06-28 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs

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

David Malcolm  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-28
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from David Malcolm  ---
Confirmed (on cfarm 112)

I was able to get test-expressions.c to fully pass on that box with this
further change:

diff --git a/gcc/testsuite/jit.dg/test-expressions.c
b/gcc/testsuite/jit.dg/test-expressions.c
index de6022f..2337b01 100644
--- a/gcc/testsuite/jit.dg/test-expressions.c
+++ b/gcc/testsuite/jit.dg/test-expressions.c
@@ -417,7 +417,7 @@ static void run_test_of_comparison(gcc_jit_context *ctxt,
 const char *expected)
 {
   gcc_jit_type *vec_type =
-gcc_jit_type_get_vector (type, 4);
+gcc_jit_type_get_vector (type, 2);

   CHECK_STRING_VALUE (
 make_test_of_comparison (ctxt,

[Bug c++/110468] internal compiler error in nothrow_spec_p (g++ > 11)

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED

[Bug c++/110468] internal compiler error in nothrow_spec_p (g++ > 11)

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Andrew Pinski  ---
(In reply to gococobu from comment #4)
> Sure, I uploaded it to https://x0x.pw/gcc_bug_110468/
> 
> I think the code throwing the ICE is correct... but can't really attest to
> it.
> 
> Please tell me if you need something else.

Thanks, I can reproduce the ICE, I am reducing it now.

In file included from src/client/actions/action.cpp:166:
./src/include/params/parvar_import.hpp: At global scope:
./src/include/params/parvar_import.hpp:35:13: internal compiler error: in
nothrow_spec_p, at cp/except.cc:1199
0xea1209 nothrow_spec_p(tree_node const*)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/except.cc:1199
0xd00e2c set_flags_from_callee(tree_node*)
/home/apinski/src/upstream-gcc-git/gcc/gcc/cp/call.cc:341

[Bug c++/110468] internal compiler error in nothrow_spec_p (g++ > 11)

2023-06-28 Thread gococobu at 7art dot org via Gcc-bugs

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

--- Comment #5 from gococobu at 7art dot org ---
(by the code being correct I mean in terms of standards, best practices, etc...
it definitely does compile in gcc++ 10.2 and 11.0)

[Bug tree-optimization/110252] [14 Regression] Wrong code at -O2/3/s on x86_64-linux-gnu

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #9 from Andrew Pinski  ---
Another testcase (from PR 110446):
```
unsigned int a = 1387579096U;
void sinkandcheck(unsigned b) __attribute__((noipa));
void sinkandcheck(unsigned b)
{
if (a != b)
__builtin_abort();
}
int main() {
a = 1 < (~a) ? 1 : (~a);
sinkandcheck(1);
return 0;
}
```

[Bug c++/110468] internal compiler error in nothrow_spec_p (g++ > 11)

2023-06-28 Thread gococobu at 7art dot org via Gcc-bugs

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

--- Comment #4 from gococobu at 7art dot org ---
Sure, I uploaded it to https://x0x.pw/gcc_bug_110468/

I think the code throwing the ICE is correct... but can't really attest to it.

Please tell me if you need something else.

[Bug tree-optimization/110252] [14 Regression] Wrong code at -O2/3/s on x86_64-linux-gnu

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jwzeng at nuaa dot edu.cn

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

[Bug tree-optimization/110446] [14 Regression] Wrong code at -O1/2/3/s on x86_64-pc-linux-gnu

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 110252.

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

[Bug c++/110468] internal compiler error in nothrow_spec_p (g++ > 11)

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Andrew Pinski  ---
(In reply to gococobu from comment #2)
> Thanks for your reply. Even compressed, it is too big for bugzilla (1.5M
> .xz, 2.1M .gzip)
> 
> Maybe you can close this bug, and I'll resubmit when/if I get a smaller
> testcase for this specific bug? (right now, I'm just trying to go around it)

Is there a place where you can place the compressed temporary and I can have a
go at reducing it.

[Bug target/104124] Poor optimization for vector splat DW with small consts

2023-06-28 Thread munroesj at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Steven Munroe  ---
Thanks

[Bug testsuite/110469] New: Test gcc.dg/sms-compare-debug-1.c fails on s390x

2023-06-28 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 110469
   Summary: Test gcc.dg/sms-compare-debug-1.c fails on s390x
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Taking testsuite/gcc.dg/sms-compare-debug-1.c, this works:

$ ./xgcc -B. -S sms-compare-debug-1.c -O2 -fcompare-debug -fmodulo-sched
--param sms-min-sc=1 -march=z900

but e.g. with z13:

$ ./xgcc -B. -S sms-compare-debug-1.c -O2 -fcompare-debug -fmodulo-sched
--param sms-min-sc=1 -march=z13
xgcc: error: sms-compare-debug-1.c: ‘-fcompare-debug’ failure

[Bug fortran/110360] ABI issue with character,value dummy argument

2023-06-28 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

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

https://gcc.gnu.org/g:8736d6b14a4dfdfb58c80ccd398981b0fb5d00aa

commit r14-2171-g8736d6b14a4dfdfb58c80ccd398981b0fb5d00aa
Author: Harald Anlauf 
Date:   Wed Jun 28 22:16:18 2023 +0200

Fortran: ABI for scalar CHARACTER(LEN=1),VALUE dummy argument [PR110360]

gcc/fortran/ChangeLog:

PR fortran/110360
* trans-expr.cc (gfc_conv_procedure_call): For non-constant string
argument passed to CHARACTER(LEN=1),VALUE dummy, ensure proper
dereferencing and truncation of string to length 1.

gcc/testsuite/ChangeLog:

PR fortran/110360
* gfortran.dg/value_9.f90: Add tests for intermediate regression.

[Bug c++/110468] internal compiler error in nothrow_spec_p (g++ > 11)

2023-06-28 Thread gococobu at 7art dot org via Gcc-bugs

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

--- Comment #2 from gococobu at 7art dot org ---
Thanks for your reply. Even compressed, it is too big for bugzilla (1.5M .xz,
2.1M .gzip)

Maybe you can close this bug, and I'll resubmit when/if I get a smaller
testcase for this specific bug? (right now, I'm just trying to go around it)

[Bug tree-optimization/110449] Vect: use a small step to calculate the loop induction if the loop is unrolled during loop vectorization

2023-06-28 Thread rsandifo at gcc dot gnu.org via Gcc-bugs

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Interesting idea!  But I think the ideal thing here would be
to do the 8*step after the store:

.L2:
add v29.4s, v31.4s, v28.4s  # += 4*step
stp q31, q29, [x0]
add v31.4s, v31.4s, v27.4s  # += 8*step
add x0, x0, 32
cmp x1, x0
bne .L2

This has the advantage that the loop-carried dependency
is only one ADD instruction deep, rather than 2 ADDs deep.

I haven't looked how easy it would be to do though…

[Bug c++/110468] internal compiler error in nothrow_spec_p (g++ > 11)

2023-06-28 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-28
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
Version|og12 (devel/omp/gcc-12) |14.0
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Marek Polacek  ---
Please gzip/xz the .ii file and attach it here.  Without it, we can't do
anything.

(You can try .)

[Bug fortran/110360] ABI issue with character,value dummy argument

2023-06-28 Thread mikael at gcc dot gnu.org via Gcc-bugs

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

--- Comment #23 from Mikael Morin  ---
(In reply to anlauf from comment #22)
> Created attachment 55418 [details]
> Slighty revised version of 3rd patch
> 
> I've looked at gfc_conv_string_parameter, which I was not aware of.
> This can be used for a more readable patch.
> 
Looks good.

> It appears one could even use the revised part for constant arguments, too.
> However, this changes the tree-dump for gfortran.dg/bind_c_usage_13.f03
> slightly in two places, implying the need for an adjustment of the pattern.
> As I am not entirely sure whether the result of that change is correct,
> I refrained from using that version.
> 
OK, let's play it safe.

> (The partial output from Power BE appears to suggest that constant argument
> is still right.)
> 
> Mikael: do you want to test on Power, or shall I proceed?

Sorry, still can't login at the moment.
Reading the account creation message again, I may need to wait "a few days".
So please proceed.

[Bug c++/67491] [meta-bug] concepts issues

2023-06-28 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Bug 89442 Summary: [concepts] missing "wrong number of template arguments" 
error in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89442

   What|Removed |Added

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

[Bug c++/89442] [concepts] missing "wrong number of template arguments" error in requires-clause

2023-06-28 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Target Milestone|--- |14.0
 CC||ppalka at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 14

[Bug c++/89442] [concepts] missing "wrong number of template arguments" error in requires-clause

2023-06-28 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:4cf64d9cc2faf4001f037a50a350abd0f95f3e29

commit r14-2170-g4cf64d9cc2faf4001f037a50a350abd0f95f3e29
Author: Patrick Palka 
Date:   Wed Jun 28 15:43:33 2023 -0400

c++: ahead of time variable template-id coercion [PR89442]

This patch makes us coerce the arguments of a variable template-id ahead
of time, as we do for class template-ids, which causes us to immediately
diagnose template parm/arg kind mismatches and arity mismatches.

Unfortunately this causes a regression in cpp1z/constexpr-if20.C: coercing
the variable template-id m ahead of time means we strip it of
typedefs, yielding m::q, typename C::q>, but in this
stripped form we're directly using 'i' and so we expect to have captured
it.  This is a variable template version of PR107437.

PR c++/89442
PR c++/107437

gcc/cp/ChangeLog:

* cp-tree.h (lookup_template_variable): Add complain parameter.
* parser.cc (cp_parser_template_id): Pass tf_warning_or_error
to lookup_template_variable.
* pt.cc (lookup_template_variable): Add complain parameter.
Coerce template arguments here ...
(finish_template_variable): ... instead of here.
(lookup_and_finish_template_variable): Check for error_mark_node
result from lookup_template_variable.
(tsubst_copy) : Pass complain to
lookup_template_variable.
(instantiate_template): Use build2 instead of
lookup_template_variable to build a TEMPLATE_ID_EXPR
for most_specialized_partial_spec.

gcc/testsuite/ChangeLog:

* g++.dg/cpp/pr64127.C: Expect "expected unqualified-id at end
of input" error.
* g++.dg/cpp0x/alias-decl-ttp1.C: Fix template parameter/argument
kind mismatch for variable template has_P_match_V.
* g++.dg/cpp1y/pr72759.C: Expect "template argument 1 is invalid"
error.
* g++.dg/cpp1z/constexpr-if20.C: XFAIL test due to bogus "'i' is
not captured" error.
* g++.dg/cpp1z/noexcept-type21.C: Fix arity of variable template d.
* g++.dg/diagnostic/not-a-function-template-1.C: Add default
template argument to variable template A so that A<> is valid.
* g++.dg/parse/error56.C: Don't expect "ISO C++ forbids
declaration with no type" error.
* g++.dg/parse/template30.C: Don't expect "parse error in
template argument list" error.
* g++.dg/cpp1y/var-templ82.C: New test.

[Bug c++/107437] nested generic lambdas fail requiring unneded captures

2023-06-28 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:4cf64d9cc2faf4001f037a50a350abd0f95f3e29

commit r14-2170-g4cf64d9cc2faf4001f037a50a350abd0f95f3e29
Author: Patrick Palka 
Date:   Wed Jun 28 15:43:33 2023 -0400

c++: ahead of time variable template-id coercion [PR89442]

This patch makes us coerce the arguments of a variable template-id ahead
of time, as we do for class template-ids, which causes us to immediately
diagnose template parm/arg kind mismatches and arity mismatches.

Unfortunately this causes a regression in cpp1z/constexpr-if20.C: coercing
the variable template-id m ahead of time means we strip it of
typedefs, yielding m::q, typename C::q>, but in this
stripped form we're directly using 'i' and so we expect to have captured
it.  This is a variable template version of PR107437.

PR c++/89442
PR c++/107437

gcc/cp/ChangeLog:

* cp-tree.h (lookup_template_variable): Add complain parameter.
* parser.cc (cp_parser_template_id): Pass tf_warning_or_error
to lookup_template_variable.
* pt.cc (lookup_template_variable): Add complain parameter.
Coerce template arguments here ...
(finish_template_variable): ... instead of here.
(lookup_and_finish_template_variable): Check for error_mark_node
result from lookup_template_variable.
(tsubst_copy) : Pass complain to
lookup_template_variable.
(instantiate_template): Use build2 instead of
lookup_template_variable to build a TEMPLATE_ID_EXPR
for most_specialized_partial_spec.

gcc/testsuite/ChangeLog:

* g++.dg/cpp/pr64127.C: Expect "expected unqualified-id at end
of input" error.
* g++.dg/cpp0x/alias-decl-ttp1.C: Fix template parameter/argument
kind mismatch for variable template has_P_match_V.
* g++.dg/cpp1y/pr72759.C: Expect "template argument 1 is invalid"
error.
* g++.dg/cpp1z/constexpr-if20.C: XFAIL test due to bogus "'i' is
not captured" error.
* g++.dg/cpp1z/noexcept-type21.C: Fix arity of variable template d.
* g++.dg/diagnostic/not-a-function-template-1.C: Add default
template argument to variable template A so that A<> is valid.
* g++.dg/parse/error56.C: Don't expect "ISO C++ forbids
declaration with no type" error.
* g++.dg/parse/template30.C: Don't expect "parse error in
template argument list" error.
* g++.dg/cpp1y/var-templ82.C: New test.

[Bug c++/110468] New: internal compiler error in nothrow_spec_p (g++ > 11)

2023-06-28 Thread gococobu at 7art dot org via Gcc-bugs

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

Bug ID: 110468
   Summary: internal compiler error in nothrow_spec_p (g++ > 11)
   Product: gcc
   Version: og12 (devel/omp/gcc-12)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gococobu at 7art dot org
  Target Milestone: ---

Created attachment 55420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55420=edit
Command line, stack trace

Compiled without problems until g++ v12, v13.

Internal compiler error when using an alias of a boost::variant inside a struct
template.

Attached command line and stack trace (the problem is that it's not a small
codebase, can't attach the preprocessed code, it's 16M).

First time filing a bug, I hope I'm following the guidelines. I don't think
it's a duplicate of any I can see (although it might be connected).

[Bug bootstrap/110467] Bootstrap with Ada enabled fails with --enable-host-pie

2023-06-28 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Marek Polacek  ---
Further context:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622981.html

[Bug bootstrap/110467] New: Bootstrap with Ada enabled fails with --enable-host-pie

2023-06-28 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 110467
   Summary: Bootstrap with Ada enabled fails with
--enable-host-pie
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Since r14-2132:

commit 4a48a38fa99f067b8f3a3d1a5dc7a1e602db351f
Author: Eric Botcazou 
Date:   Wed Jun 21 18:19:36 2023 +0200

ada: Fix build of GNAT tools

gcc configured with e.g.

.../gcc/configure --enable-languages=all --prefix=`pwd` --enable-checking=yes
--with-gnu-ld --with-gnu-as --disable-libsanitizer --disable-bootstrap
--enable-host-pie

fails:

/usr/bin/ld: b_gnatl.o: relocation R_X86_64_32S against `.rodata' can not be
used when making a PIE object; recompile with -fPIE
/usr/bin/ld: gnatlink.o: relocation R_X86_64_32 against `.rodata.str1.1' can
not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: a-except.o: relocation R_X86_64_32S against `.rodata' can not be
used when making a PIE object; recompile with -fPIE
/usr/bin/ld: ali.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be
used when making a PIE object; recompile with -fPIE
/usr/bin/ld: butil.o: relocation R_X86_64_32S against `.rodata' can not be used
when making a PIE object; recompile with -fPIE
/usr/bin/ld: casing.o: relocation R_X86_64_32S against symbol
`csets__identifier_char' can not be used when making a PIE object; recompile
with -fPIE
/usr/bin/ld: csets.o: relocation R_X86_64_32S against `.rodata' can not be used
when making a PIE object; recompile with -fPIE
/usr/bin/ld: debug.o: relocation R_X86_64_32S against `.rodata' can not be used
when making a PIE object; recompile with -fPIE
/usr/bin/ld: fmap.o: relocation R_X86_64_32S against `.bss' can not be used
when making a PIE object; recompile with -fPIE
/usr/bin/ld: fname.o: relocation R_X86_64_32 against `.rodata' can not be used
when making a PIE object; recompile with -fPIE
/usr/bin/ld: gnatvsn.o: relocation R_X86_64_32S against symbol
`gnat_version_string' can not be used when making a PIE object; recompile with
-fPIE
/usr/bin/ld: hostparm.o: relocation R_X86_64_32 against `.rodata.str1.1' can
not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: i-c.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be
used when making a PIE object; recompile with -fPIE
/usr/bin/ld: i-cstrin.o: relocation R_X86_64_32 against `.rodata.str1.1' can
not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: namet.o: relocation R_X86_64_32S against `.rodata' can not be used
when making a PIE object; recompile with -fPIE
/usr/bin/ld: opt.o: relocation R_X86_64_32S against `.rodata' can not be used
when making a PIE object; recompile with -fPIE
/usr/bin/ld: osint.o: relocation R_X86_64_32 against `.rodata' can not be used
when making a PIE object; recompile with -fPIE
/usr/bin/ld: output.o: relocation R_X86_64_32 against `.rodata.str1.1' can not
be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: s-exctab.o: relocation R_X86_64_32S against symbol
`system__exception_table__htable' can not be used when making a PIE object;
recompile with -fPIE
/usr/bin/ld: s-secsta.o: relocation R_X86_64_32 against `.rodata.str1.1' can
not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: snames.o: relocation R_X86_64_32 against `.rodata.str1.8' can not
be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: stylesw.o: relocation R_X86_64_32 against `.rodata.str1.1' can not
be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: switch.o: relocation R_X86_64_32 against `.rodata' can not be used
when making a PIE object; recompile with -fPIE
/usr/bin/ld: targparm.o: relocation R_X86_64_32S against symbol
`namet__global_name_buffer' can not be used when making a PIE object; recompile
with -fPIE
/usr/bin/ld: types.o: relocation R_X86_64_32 against `.rodata.str1.1' can not
be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: validsw.o: relocation R_X86_64_32S against `.rodata' can not be
used when making a PIE object; recompile with -fPIE
/usr/bin/ld: widechar.o: relocation R_X86_64_32 against `.rodata' can not be
used when making a PIE object; recompile with -fPIE

[Bug tree-optimization/110460] [14 Regression] ft32 ICE on 931110-1.c with new TYPE_PRECISION checking

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |14.0

[Bug jit/110466] jit.dg FAILs on ppc64le

2023-06-28 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Marek Polacek  ---
The problem is that the patch above uses __vector which is wrong on Power. 
However, with my patch:

--- a/gcc/testsuite/jit.dg/test-expressions.c
+++ b/gcc/testsuite/jit.dg/test-expressions.c
@@ -560,17 +560,17 @@ verify_comparisons (gcc_jit_result *result)
   CHECK_VALUE (test_COMPARISON_GE_on_int (1, 2), 0);
   CHECK_VALUE (test_COMPARISON_GE_on_int (2, 1), 1);

-  typedef int __vector __attribute__ ((__vector_size__ (sizeof(int) * 2)));
-  typedef __vector (*test_vec_fn) (__vector, __vector);
+  typedef int v2si __attribute__ ((__vector_size__ (sizeof(int) * 2)));
+  typedef v2si (*test_vec_fn) (v2si, v2si);

-  __vector zero_zero = {0, 0};
-  __vector zero_one = {0, 1};
-  __vector one_zero = {1, 0};
+  v2si zero_zero = {0, 0};
+  v2si zero_one = {0, 1};
+  v2si one_zero = {1, 0};

-  __vector true_true = {-1, -1};
-  __vector false_true = {0, -1};
-  __vector true_false = {-1, 0};
-  __vector false_false = {0, 0};
+  v2si true_true = {-1, -1};
+  v2si false_true = {0, -1};
+  v2si true_false = {-1, 0};
+  v2si false_false = {0, 0};

   test_vec_fn test_COMPARISON_EQ_on_vec_int =
 (test_vec_fn)gcc_jit_result_get_code (result,
@@ -615,7 +615,7 @@ verify_comparisons (gcc_jit_result *result)
   CHECK_VECTOR_VALUE (2, test_COMPARISON_GE_on_vec_int (zero_one, one_zero),
false_true);

   typedef float __vector_f __attribute__ ((__vector_size__ (sizeof(float) *
2)));
-  typedef __vector (*test_vec_f_fn) (__vector_f, __vector_f);
+  typedef v2si (*test_vec_f_fn) (__vector_f, __vector_f);

   __vector_f zero_zero_f = {0, 0};
   __vector_f zero_one_f = {0, 1};

I see FAILs like

Running /home/polacek/src/gcc/gcc/testsuite/jit.dg/jit.exp ... 
FAIL: test-combination.c.exe iteration 1 of 5: verify_comparisons: actual:
test_COMPARISON_EQ_on_vec_int (zero_zero, zero_zero) != expected: true_true
(position 0)
FAIL: test-combination.c.exe killed: 7835 exp8 0 0 CHILDKILLED SIGABRT SIGABRT
FAIL: FAIL
FAIL: FAIL
FAIL: FAIL
FAIL: test-expressions.c.exe iteration 1 of 5: verify_comparisons: actual:
test_COMPARISON_EQ_on_vec_int (zero_zero, zero_zero) != expected: true_true
(position 0)
FAIL: test-expressions.c.exe killed: 10718 exp12 0 0 CHILDKILLED SIGABRT
SIGABRT
FAIL: test-threads.c.exe: verify_comparisons: actual:
test_COMPARISON_EQ_on_vec_int (zero_zero, zero_zero) != expected: true_true
(position 0)
FAIL: test-threads.c.exe killed: 12273 exp12 0 0 CHILDKILLED SIGABRT SIGABRT

and I don't know what that means.

[Bug jit/110466] New: jit.dg FAILs on ppc64le

2023-06-28 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 110466
   Summary: jit.dg FAILs on ppc64le
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

On ppc64le:

$ make check RUNTESTFLAGS=jit.exp

Running /home/polacek/src/gcc/gcc/testsuite/jit.dg/jit.exp ... 
FAIL: jit.dg/test-combination.c, initial compilation
FAIL: FAIL
FAIL: FAIL
FAIL: FAIL
FAIL: jit.dg/test-expressions.c, initial compilation
FAIL: jit.dg/test-threads.c, initial compilation

=== jit Summary === 

# of expected passes6632
# of unexpected failures6
# of unsupported tests  4
make[1]: Leaving directory `/home/polacek/x/trunk/gcc'

I suspect that's so since

commit d2e782cb99c3116c389d6a9565678c4ffe26
Author: Antoni Boucher 
Date:   Sun Nov 20 10:22:53 2022 -0500

libgccjit: Fix float vector comparison

[Bug tree-optimization/110458] -Warray-bounds=2 new false positive

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
The problem is ldist does:

  arr1_8 = [(struct data *)arrayOut_7(D)].arr1;
  __builtin_memset (arr1_8, 0, 32);

(which is kinda of correct).

I think there are other bug related to this similar thing ...

[Bug tree-optimization/110461] [14 regression] ICE when building openh264 with new vector_type checking

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

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

[Bug tree-optimization/110465] [14 regression] ICE when building openssl with new vector_type checking

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Same issue as PR 110461 .

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

[Bug tree-optimization/110465] New: [14 regression] ICE when building openssl with new vector_type checking

2023-06-28 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 110465
   Summary: [14 regression] ICE when building openssl with new
vector_type checking
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55419
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55419=edit
libcrypto-lib-rc5_enc.i

amd64 this time ;)

`gcc -c libcrypto-lib-rc5_enc.i -O2 -march=x86-64-v2` is enough to repro.

```
x86_64-gentoo-linux-musl-gcc  -I. -Iinclude -Iproviders/common/include
-Iproviders/implementations/include -I../openssl-3.1.1
-I../openssl-3.1.1/include -I../openssl-3.1.1/providers/common/include
-I../openssl-3.1.1/providers/implementations/include  -DAES_ASM -DBSAES_ASM
-DCMLL_ASM -DECP_NISTZ256_ASM -DGHASH_ASM -DKECCAK1600_ASM -DMD5_ASM
-DOPENSSL_BN_ASM_GF2m -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
-DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DPOLY1305_ASM -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DX25519_ASM -fPIC -pthread -m64
-Wa,--noexecstack -O2 -pipe -march=native -fdiagnostics-color=always
-frecord-gcc-switches -fno-strict-aliasing -Wa,--noexecstack
-DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/etc/ssl\""
-DENGINESDIR="\"/usr/lib/engines-3\"" -DMODULESDIR="\"/usr/lib/ossl-modules\""
-DOPENSSL_BUILDING_OPENSSL -DNDEBUG  -MMD -MF
crypto/rc5/libcrypto-lib-rc5_enc.d.tmp -MT crypto/rc5/libcrypto-lib-rc5_enc.o
-c -o crypto/rc5/libcrypto-lib-rc5_enc.o ../openssl-3.1.1/crypto/rc5/rc5_enc.c
during GIMPLE pass: ccp
../openssl-3.1.1/crypto/rc5/rc5_enc.c: In function 'RC5_32_cbc_encrypt':
../openssl-3.1.1/crypto/rc5/rc5_enc.c:20:6: internal compiler error: tree
check: expected none of vector_type, have vector_type in gimple_simplify_144,
at gimple-match-3.cc:1027
   20 | void RC5_32_cbc_encrypt(const unsigned char *in, unsigned char *out,
  |  ^~
0x556c8ddc26d5 tree_not_check_failed(tree_node const*, char const*, int, char
const*, ...)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree.cc:8936
0x556c8e35d4a2 tree_not_check(tree_node*, char const*, int, char const*,
tree_code)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree.h:3581
0x556c8e35d4a2 gimple_simplify_144(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node*, tree_node**, tree_code)
   
/usr/src/debug/sys-devel/gcc-14.0.0./build/gcc/gimple-match-3.cc:1027
0x556c8fd5720a gimple_simplify_BIT_XOR_EXPR(gimple_match_op*, gimple**,
tree_node* (*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./build/gcc/gimple-match-2.cc:9569
0x556c8f196bce gimple_resimplify2
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/gimple-match-exports.cc:967
0x556c8f197301 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/gimple-match-exports.cc:834
0x556c8e71bc25 gimple_fold_stmt_to_constant_1(gimple*, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/gimple-fold.cc:7472
0x556c8ec06e5a ccp_fold
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-ssa-ccp.cc:1289
0x556c8ec06e5a evaluate_stmt
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-ssa-ccp.cc:
0x556c8ec0895d visit_assignment
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-ssa-ccp.cc:2856
0x556c8ecc0b6a ssa_propagation_engine::simulate_stmt(gimple*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-ssa-propagate.cc:221
0x556c8ecc0eaa ssa_propagation_engine::simulate_block(basic_block_def*)
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-ssa-propagate.cc:328
0x556c8ecc1413 ssa_propagation_engine::ssa_propagate()
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-ssa-propagate.cc:478
0x556c8ebffc9c do_ssa_ccp
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-ssa-ccp.cc:2975
0x556c8ebffc9c execute
   
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-ssa-ccp.cc:3021
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
make[1]: *** [Makefile:13261: crypto/rc5/libcrypto-lib-rc5_enc.o] Error 1
```

```
gcc (Gentoo Hardened 14.0.0 p, commit 6cb33e2f39e289ec4f25f845d8153053147c5c49)
14

[Bug d/106977] [13/14 regression] d21 dies with SIGBUS on 32-bit Darwin

2023-06-28 Thread ibuclaw at gcc dot gnu.org via Gcc-bugs

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

--- Comment #34 from ibuclaw at gcc dot gnu.org ---
I think this should be fixed now.  I'll let @Iain Sandoe confirm, as there are
likely other fixes he has relating to the testsuite.

[Bug fortran/110360] ABI issue with character,value dummy argument

2023-06-28 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

--- Comment #22 from anlauf at gcc dot gnu.org ---
Created attachment 55418
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55418=edit
Slighty revised version of 3rd patch

I've looked at gfc_conv_string_parameter, which I was not aware of.
This can be used for a more readable patch.

It appears one could even use the revised part for constant arguments, too.
However, this changes the tree-dump for gfortran.dg/bind_c_usage_13.f03
slightly in two places, implying the need for an adjustment of the pattern.
As I am not entirely sure whether the result of that change is correct,
I refrained from using that version.

(The partial output from Power BE appears to suggest that constant argument
is still right.)

Mikael: do you want to test on Power, or shall I proceed?
I will extend the testcase to cover the failures from comment#17.

[Bug target/110406] d: Wrong code-gen returning POD structs by value

2023-06-28 Thread ibuclaw at gcc dot gnu.org via Gcc-bugs

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #16 from ibuclaw at gcc dot gnu.org ---
Fixed and backported problem specific to the D front-end.  There's another part
to this in pr102027, but I don't think this should be kept open waiting for it.

[Bug d/106977] [13/14 regression] d21 dies with SIGBUS on 32-bit Darwin

2023-06-28 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #33 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Iain Buclaw
:

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

commit r13-7496-gf2eeda5652438fe783d4e3878139481a1b8606b6
Author: Iain Buclaw 
Date:   Wed Jun 28 18:30:31 2023 +0200

d: Fix wrong code-gen when returning structs by value.

Since r13-1104, structs have have compute_record_mode called too early
on them, causing them to return differently depending on the order that
types are generated in, and whether there are forward references.

This patch moves the call to compute_record_mode into its own function,
and calls it after all fields have been given a size.

PR d/106977
PR target/110406

gcc/d/ChangeLog:

* types.cc (finish_aggregate_mode): New function.
(finish_incomplete_fields): Call finish_aggregate_mode.
(finish_aggregate_type): Replace call to compute_record_mode with
finish_aggregate_mode.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr110406.d: New test.

(cherry picked from commit c201cd3be0d9ab887fafb0c33a9fc287c405c21c)

[Bug target/110406] d: Wrong code-gen returning POD structs by value

2023-06-28 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #15 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Iain Buclaw
:

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

commit r13-7496-gf2eeda5652438fe783d4e3878139481a1b8606b6
Author: Iain Buclaw 
Date:   Wed Jun 28 18:30:31 2023 +0200

d: Fix wrong code-gen when returning structs by value.

Since r13-1104, structs have have compute_record_mode called too early
on them, causing them to return differently depending on the order that
types are generated in, and whether there are forward references.

This patch moves the call to compute_record_mode into its own function,
and calls it after all fields have been given a size.

PR d/106977
PR target/110406

gcc/d/ChangeLog:

* types.cc (finish_aggregate_mode): New function.
(finish_incomplete_fields): Call finish_aggregate_mode.
(finish_aggregate_type): Replace call to compute_record_mode with
finish_aggregate_mode.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr110406.d: New test.

(cherry picked from commit c201cd3be0d9ab887fafb0c33a9fc287c405c21c)

[Bug c++/110175] [GCC][Crash] GCC Crash on valid code

2023-06-28 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Keywords|c++-lambda  |
 CC||ppalka at gcc dot gnu.org

[Bug libstdc++/110462] [14 regression] Build failure with musl-1.2.4 (filesystem/ops-common.h:377:5: error: 'off64_t' was not declared in this scope; did you mean 'off_t'?)

2023-06-28 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #10 from Sam James  ---
(In reply to Jonathan Wakely from comment #9)
> It seems we should be using loff_t here.

For the benefit of the bug:
https://lore.kernel.org/linux-man/add1e27e-e10c-e70d-ed5e-85bb0d4d4...@cs.ucla.edu/T/#me942a9ccc53dc5b00b2fab58f493632c143326df.

[Bug c/110453] gcc accepts redefinition of global variable without initializer

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Andrew Pinski  ---
This is called a tentative declaration.

A simplified definition of this can be found at
https://en.cppreference.com/w/c/language/extern

(with the references to the C standard on the bottom of the page).

[Bug analyzer/110455] [14 Regression] tree check: expected none of vector_type, have vector_type in get_gassign_result, at analyzer/region-model.cc:870 with -fanalyzer[14 Regression] ICE:

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-checking
Summary|tree check: expected none   |[14 Regression] tree check:
   |of vector_type, have|expected none of
   |vector_type in  |vector_type, have
   |get_gassign_result, at  |vector_type in
   |analyzer/region-model.cc:87 |get_gassign_result, at
   |0 with -fanalyzer[14|analyzer/region-model.cc:87
   |Regression] ICE:|0 with -fanalyzer[14
   ||Regression] ICE:
   Target Milestone|--- |14.0

[Bug c/110454] [14 Regression] ICE: tree check: expected none of vector_type, have vector_type in convert_argument, at c/c-typeck.cc:3388 with -Wtraditional-conversion

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |14.0

[Bug driver/110408] [13/14 Regression] gcc 13 crashes with %rename in specs

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|gcc 13 crashes with %rename |[13/14 Regression] gcc 13
   |in specs|crashes with %rename in
   ||specs
   Target Milestone|--- |13.2
   Keywords||needs-bisection

[Bug d/106977] [13/14 regression] d21 dies with SIGBUS on 32-bit Darwin

2023-06-28 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #32 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r14-2169-gc201cd3be0d9ab887fafb0c33a9fc287c405c21c
Author: Iain Buclaw 
Date:   Wed Jun 28 18:30:31 2023 +0200

d: Fix wrong code-gen when returning structs by value.

Since r13-1104, structs have have compute_record_mode called too early
on them, causing them to return differently depending on the order that
types are generated in, and whether there are forward references.

This patch moves the call to compute_record_mode into its own function,
and calls it after all fields have been given a size.

PR d/106977
PR target/110406

gcc/d/ChangeLog:

* types.cc (finish_aggregate_mode): New function.
(finish_incomplete_fields): Call finish_aggregate_mode.
(finish_aggregate_type): Replace call to compute_record_mode with
finish_aggregate_mode.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr110406.d: New test.

[Bug target/110406] d: Wrong code-gen returning POD structs by value

2023-06-28 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r14-2169-gc201cd3be0d9ab887fafb0c33a9fc287c405c21c
Author: Iain Buclaw 
Date:   Wed Jun 28 18:30:31 2023 +0200

d: Fix wrong code-gen when returning structs by value.

Since r13-1104, structs have have compute_record_mode called too early
on them, causing them to return differently depending on the order that
types are generated in, and whether there are forward references.

This patch moves the call to compute_record_mode into its own function,
and calls it after all fields have been given a size.

PR d/106977
PR target/110406

gcc/d/ChangeLog:

* types.cc (finish_aggregate_mode): New function.
(finish_incomplete_fields): Call finish_aggregate_mode.
(finish_aggregate_type): Replace call to compute_record_mode with
finish_aggregate_mode.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr110406.d: New test.

[Bug c++/110464] New: Improve -Wdiv-by-zero

2023-06-28 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 110464
   Summary: Improve -Wdiv-by-zero
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

int
f0 ()
{
  constexpr int e = 0;
  if (e != 0)
return 10 / e; // { dg-bogus "division" }
  return 0;
}

int
f1 ()
{
  constexpr int e = 0;
  goto foo;
  if (e != 0)
foo:
return 10 / e; // { dg-warning "division" }
  return 0;
}

int
f2 ()
{
  constexpr int e = 0;
  switch (e)
{
case 0:
  return 10 / e; // { dg-warning "division" }
default:
  return 0;
}
}

int
f3 ()
{
  constexpr int e = 0;
  switch (e)
{
case 1:
  return 10 / e; // { dg-bogus "division" }
default:
  return 0;
}
}

$ xclang++ -c u.C
u.C:17:15: warning: division by zero is undefined [-Wdivision-by-zero]
   17 | return 10 / e; // { dg-warning "division" }
  |   ^ ~
u.C:28:17: warning: division by zero is undefined [-Wdivision-by-zero]
   28 |   return 10 / e; // { dg-warning "division" }
  | ^ ~
2 warnings generated.

$ xg++ -c u.C
u.C: In function ‘int f0()’:
u.C:6:15: warning: division by zero [-Wdiv-by-zero]
6 | return 10 / e; // { dg-bogus "division" }
  |~~~^~~
u.C: In function ‘int f1()’:
u.C:17:15: warning: division by zero [-Wdiv-by-zero]
   17 | return 10 / e; // { dg-warning "division" }
  |~~~^~~
u.C: In function ‘int f2()’:
u.C:28:17: warning: division by zero [-Wdiv-by-zero]
   28 |   return 10 / e; // { dg-warning "division" }
  |  ~~~^~~
u.C: In function ‘int f3()’:
u.C:41:17: warning: division by zero [-Wdiv-by-zero]
   41 |   return 10 / e; // { dg-bogus "division" }
  |  ~~~^~~

[Bug middle-end/110459] Trivial on stack variable was not optimized away

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Last reconfirmed||2023-06-28
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed, there might be a dup of this linked to PR 101926 .

[Bug libstdc++/110462] [14 regression] Build failure with musl-1.2.4 (filesystem/ops-common.h:377:5: error: 'off64_t' was not declared in this scope; did you mean 'off_t'?)

2023-06-28 Thread redi at gcc dot gnu.org via Gcc-bugs

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

--- Comment #9 from Jonathan Wakely  ---
It seems we should be using loff_t here.

[Bug tree-optimization/110461] [14 regression] ICE when building openh264 with new vector_type checking

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Andrew Pinski  ---
Here is a better testcase which fails even at -O1 and does not depend on the
vectorizer:
```
typedef int v4si __attribute__ ((vector_size (4*sizeof(int;
typedef short v4hi __attribute__ ((vector_size (4*sizeof(short;

v4hi f(v4hi a, v4hi b)
{
auto t = __builtin_convertvector (a, v4si);
auto t1 = __builtin_convertvector (b, v4si);
t ^= t1;
return __builtin_convertvector (t, v4hi);
}
```

[Bug tree-optimization/110461] [14 regression] ICE when building openh264 with new vector_type checking

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #4 from Andrew Pinski  ---
Yes it is that pattern, specifically :
/* Try to fold (type) X op CST -> (type) (X op ((type-x) CST))
   when profitable.
   For bitwise binary operations apply operand conversions to the
   binary operation result instead of to the operands.  This allows
   to combine successive conversions and bitwise binary operations.
   We combine the above two cases by using a conditional convert.  */
(for bitop (bit_and bit_ior bit_xor)
 (simplify
  (bitop (convert@2 @0) (convert?@3 @1))
  (if (((TREE_CODE (@1) == INTEGER_CST
 && INTEGRAL_TYPE_P (TREE_TYPE (@0))
 && (int_fits_type_p (@1, TREE_TYPE (@0))
 || tree_nop_conversion_p (TREE_TYPE (@0), type)))
|| types_match (@0, @1))
   && !POINTER_TYPE_P (TREE_TYPE (@0))
   && TREE_CODE (TREE_TYPE (@0)) != OFFSET_TYPE
   /* ???  This transform conflicts with fold-const.cc doing
  Convert (T)(x & c) into (T)x & (T)c, if c is an integer
  constants (if x has signed type, the sign bit cannot be set
  in c).  This folds extension into the BIT_AND_EXPR.
  Restrict it to GIMPLE to avoid endless recursions.  */
   && (bitop != BIT_AND_EXPR || GIMPLE)
   && (/* That's a good idea if the conversion widens the operand, thus
  after hoisting the conversion the operation will be narrower.
  It is also a good if the conversion is a nop as moves the
  conversion to one side; allowing for combining of the
conversions.  */
   TYPE_PRECISION (TREE_TYPE (@0)) < TYPE_PRECISION (type)
   /* The conversion check for being a nop can only be done at the
gimple
  level as fold_binary has some re-association code which can
conflict
  with this if there is a "constant" which is not a full
INTEGER_CST.  */
   || (GIMPLE && TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION
(type))

Those 2 above TYPE_PRECISION .

[Bug tree-optimization/110461] [14 regression] ICE when building openh264 with new vector_type checking

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-06-28

--- Comment #3 from Andrew Pinski  ---
Slightly different reduced testcase:
```
void WelsQuantFour4x4Max_c(short *pDct, int *iSign1) {
  for (int k = 0; k < 4; k++) {
int iSign = iSign1[k];
for (int i = 0; i < 16; i++) {
  short t = (iSign ^ (int)pDct[i]) >> 16;
  pDct[i] = (iSign ^ (int)t);
}
pDct += 16;
  }
}

```

[Bug tree-optimization/110461] [14 regression] ICE when building openh264 with new vector_type checking

2023-06-28 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Sam James  ---
Created attachment 55417
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55417=edit
reduced.ii

[Bug c++/110463] [13/14 Regression] Mutable subobject is usable in a constant expression

2023-06-28 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |13.2
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
  Known to fail||13.1.0, 14.0
 Ever confirmed|0   |1
   Keywords||accepts-invalid
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=92505
   Last reconfirmed||2023-06-28
Summary|Mutable subobject is usable |[13/14 Regression] Mutable
   |in a constant expression|subobject is usable in a
   ||constant expression
 CC||ppalka at gcc dot gnu.org
  Known to work||12.3.0

--- Comment #1 from Patrick Palka  ---
Confirmed, started with r13-2701-g7107ea6fb933f1

[Bug libstdc++/110462] [14 regression] Build failure with musl-1.2.4 (filesystem/ops-common.h:377:5: error: 'off64_t' was not declared in this scope; did you mean 'off_t'?)

2023-06-28 Thread redi at gcc dot gnu.org via Gcc-bugs

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-06-28
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |14.0
 Ever confirmed|0   |1

--- Comment #8 from Jonathan Wakely  ---
(In reply to Sam James from comment #3)
> Looks like we already AC_SYS_LARGEFILE in libstdc++-v3/configure.ac, so this
> should be as simple as just using off_t instead?

Ah but the filesystem sources include  which means
off_t is 64-bit here.

I'll test this:

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index efc27aa493e..43dd80abc15 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -5160,7 +5160,7 @@ dnl
   linux*)
GCC_TRY_COMPILE_OR_LINK(
  [#include ],
- [copy_file_range(1, nullptr, 2, nullptr, 1, 0);],
+ [copy_file_range(1, (off_t*)nullptr, 2, (off_t*)nullptr, 1, 0);],
  [glibcxx_cv_copy_file_range=yes],
  [glibcxx_cv_copy_file_range=no])
;;
diff --git a/libstdc++-v3/src/filesystem/ops-common.h
b/libstdc++-v3/src/filesystem/ops-common.h
index f04bbc66d7d..e04cb4010d7 100644
--- a/libstdc++-v3/src/filesystem/ops-common.h
+++ b/libstdc++-v3/src/filesystem/ops-common.h
@@ -374,7 +374,9 @@ _GLIBCXX_BEGIN_NAMESPACE_FILESYSTEM
return false;
   }
 size_t bytes_left = length;
-off64_t off_in = 0, off_out = 0;
+// copy_file_range wants off64_t* args, but libc might only define off_t.
+static_assert(sizeof(off_t) == sizeof(int64_t), "off_t is 64-bit");
+off_t off_in = 0, off_out = 0;
 ssize_t bytes_copied;
 do
   {

[Bug c/102989] Implement C2x's n2763 (_BitInt)

2023-06-28 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #55392|0   |1
is obsolete||

--- Comment #71 from Jakub Jelinek  ---
Created attachment 55416
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55416=edit
gcc14-bitint-wip.patch

Updated patch which handles newly arbitrary shits and debug info.

[Bug libstdc++/110462] [14 regression] Build failure with musl-1.2.4 (filesystem/ops-common.h:377:5: error: 'off64_t' was not declared in this scope; did you mean 'off_t'?)

2023-06-28 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from Sam James  ---
Oh, duh, it's libstdc++. I'm not sure there's an alternative to typedefing it
then.

[Bug libstdc++/110462] [14 regression] Build failure with musl-1.2.4 (filesystem/ops-common.h:377:5: error: 'off64_t' was not declared in this scope; did you mean 'off_t'?)

2023-06-28 Thread redi at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Sam James from comment #4)
> On musl, off_t and friends are always 64-bit (i.e. it's natively LFS, no
> need for largefile source functions/types). In musl-1.2.4, they dropped the
> typedefs.

But that doesn't help write portable code where off_t might not be 64-bit, and
we need to use off64_t as the correct type to pass to the function.

[Bug c++/110463] New: Mutable subobject is usable in a constant expression

2023-06-28 Thread fchelnokov at gmail dot com via Gcc-bugs

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

Bug ID: 110463
   Summary: Mutable subobject is usable in a constant expression
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

The following program is invalid per
https://timsong-cpp.github.io/cppwp/n4861/expr.const#4.8 (An object or
reference is usable in constant expressions if it is ... a non-mutable
subobject)

struct U {
mutable int x = 2;
};

int main() {
constexpr U u{};
u.x = 1;
static_assert( u.x == 2 ); // must fail, but ok in GCC
}

but GCC accepts it. Online demo: https://gcc.godbolt.org/z/n8MYzhbad

[Bug libstdc++/110462] [14 regression] Build failure with musl-1.2.4 (filesystem/ops-common.h:377:5: error: 'off64_t' was not declared in this scope; did you mean 'off_t'?)

2023-06-28 Thread redi at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Jonathan Wakely  ---
This would "fix" it, but only by disabling copy_file_range use with musl:

--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -5160,7 +5160,7 @@ dnl
   linux*)
GCC_TRY_COMPILE_OR_LINK(
  [#include ],
- [copy_file_range(1, nullptr, 2, nullptr, 1, 0);],
+ [copy_file_range(1, (off64_t*)nullptr, 2, (off64_t*)nullptr, 1, 0);],
  [glibcxx_cv_copy_file_range=yes],
  [glibcxx_cv_copy_file_range=no])
;;


It would be better to figure out how to use it.

[Bug libstdc++/110462] [14 regression] Build failure with musl-1.2.4 (filesystem/ops-common.h:377:5: error: 'off64_t' was not declared in this scope; did you mean 'off_t'?)

2023-06-28 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Sam James  ---
(In reply to Jonathan Wakely from comment #2)
> The system call is defined in terms of off64_t. What type does musl use for
> copy_file_range(2)?

/usr/include/unistd.h:197:ssize_t copy_file_range(int, off_t *, int, off_t *,
size_t, unsigned);

On musl, off_t and friends are always 64-bit (i.e. it's natively LFS, no need
for largefile source functions/types). In musl-1.2.4, they dropped the
typedefs.

[Bug libstdc++/110462] [14 regression] Build failure with musl-1.2.4 (filesystem/ops-common.h:377:5: error: 'off64_t' was not declared in this scope; did you mean 'off_t'?)

2023-06-28 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Sam James  ---
Looks like we already AC_SYS_LARGEFILE in libstdc++-v3/configure.ac, so this
should be as simple as just using off_t instead?

[Bug libstdc++/110462] [14 regression] Build failure with musl-1.2.4 (filesystem/ops-common.h:377:5: error: 'off64_t' was not declared in this scope; did you mean 'off_t'?)

2023-06-28 Thread redi at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Jonathan Wakely  ---
The system call is defined in terms of off64_t. What type does musl use for
copy_file_range(2)?

[Bug libstdc++/110462] [14 regression] Build failure with musl-1.2.4 (filesystem/ops-common.h:377:5: error: 'off64_t' was not declared in this scope; did you mean 'off_t'?)

2023-06-28 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Sam James  ---
Created attachment 55415
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55415=edit
build.log.xz

[Bug libstdc++/110462] New: [14 regression] Build failure with musl-1.2.4 (filesystem/ops-common.h:377:5: error: 'off64_t' was not declared in this scope; did you mean 'off_t'?)

2023-06-28 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 110462
   Summary: [14 regression] Build failure with musl-1.2.4
(filesystem/ops-common.h:377:5: error: 'off64_t' was
not declared in this scope; did you mean 'off_t'?)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

See PR109533. Pretty sure this was caused by r14-1569-gd87caacf8e2df5.

```
In file included from
/var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libstdc++-v3/src/c++17/fs_ops.cc:63:
/var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libstdc++-v3/src/c++17/../filesystem/ops-common.h:
In function 'bool std::filesystem::copy_file_copy_file_range(int, int,
std::size_t)':
/var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libstdc++-v3/src/c++17/../filesystem/ops-common.h:377:5:
error: 'off64_t' was not declared in this scope; did you mean 'off_t'?
  377 | off64_t off_in = 0, off_out = 0;
  | ^~~
  | off_t
/var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libstdc++-v3/src/c++17/../filesystem/ops-common.h:381:50:
error: 'off_in' was not declared in this scope; did you mean 'fd_in'?
  381 | bytes_copied = ::copy_file_range(fd_in, _in, fd_out,
_out,
  |  ^~
  |  fd_in
/var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libstdc++-v3/src/c++17/../filesystem/ops-common.h:381:67:
error: 'off_out' was not declared in this scope; did you mean 'fd_out'?
  381 | bytes_copied = ::copy_file_range(fd_in, _in, fd_out,
_out,
  |  
^~~
  |  
fd_out
make[6]: *** [Makefile:587: fs_ops.lo] Error 1
```

[Bug tree-optimization/110461] [14 regression] ICE when building openh264 with new vector_type checking

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Keywords||ice-on-valid-code

[Bug tree-optimization/110461] [14 regression] ICE when building openh264 with new vector_type checking

2023-06-28 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Andrew Pinski  ---
I think it is:
/* Try to fold (type) X op CST -> (type) (X op ((type-x) CST))

1 2 >

1 - 100 of 199 matches

Mail list logo