[Bug driver/106897] driver: support -gz=zstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106897
--- Comment #4 from Fangrui Song ---
Yes, the change will be straightforward, basically the files touched by the
pending https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597586.html
("[PATCH] Remove legacy -gz=zlib-gnu").
I sent it because I knew that we would need a new compression format, and some
cleanup would make the logic more maintainable.
[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652
Jakub Jelinek changed:
What|Removed |Added
Attachment #53557|0 |1
is obsolete||
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Last reconfirmed||2022-09-10
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #10 from Jakub Jelinek ---
Created attachment 53558
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53558&action=edit
gcc13-pr106652.patch
The other conversion better should use backend support if available, but
could be implemented in libgcc __truncsfbf2 or inline. I believe Intel docs
document it as
__bf16
__truncsfbf2 (_Float32 x)
{
unsigned int y;
memcpy (&y, &x, sizeof (y));
unsigned int z = x & 0x7fff;
unsigned short r;
__bf16 ret;
if (z < 0x80)
// Zero or denormal, flush to zero.
r = (x & 0x8000) >> 16;
else if (z < 0x7f80)
// Normal, round to nearest.
r = (x + 0x7fff + ((x >> 16) & 1)) >> 16;
else if (z == 0x7f80)
// Inf.
r = x >> 16;
else
// NaN.
r = (x >> 16) | (1 << 6);
memcpy (&ret, &r, sizeof (r));
return ret;
}
[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652 --- Comment #11 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #10) Ouch, sorry for lost start of the comment, this is full patch with even [conv.ics.rank]/4 changes and extended test coverage, just std::bfloat16_t support isn't in. And the above comment is about that support, where conversion from __bf16 to _Float32 can be done even in generic code just by shifting the bits up by 16.
[Bug middle-end/106892] [11/12 Regression] Wrong code at -O3 on x86_64-linux-gnu since r11-963-g80d6f89e78fc3b77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106892 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #12 from Mikael Pettersson --- (In reply to Richard Biener from comment #11) > PR tree-optimization/106722 Shouldn't that be 106892? > * tree-predcom.cc (ref_at_iteration): Do not associate the > constant part of the offset into the MEM_REF offset > operand, across a non-zero offset. > > * gcc.dg/torture/pr106892.c: New testcase.
[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383 Sergey Fedorov changed: What|Removed |Added CC||vital.had at gmail dot com --- Comment #20 from Sergey Fedorov --- I just got the same error when building OpenCoarrays on 10.6.8 for ppc32: /opt/local/var/macports/build/_opt_PPCRosettaPorts_science_OpenCoarrays/OpenCoarrays/work/OpenCoarrays-2.10.0/src/tests/integration/pde_solvers/coarrayBurgers/main.F90:3:20: 3 | use, intrinsic :: ieee_arithmetic, only : ieee_is_nan |1 Fatal Error: Cannot find an intrinsic module named 'ieee_arithmetic' at (1) compilation terminated. Error: command: `/opt/local/bin/mpif90-mpich-gcc12 -I/opt/local/var/macports/build/_opt_PPCRosettaPorts_science_OpenCoarrays/OpenCoarrays/work/build/include/OpenCoarrays-2.10.0_GNU-12.2.0 -fcoarray=lib -DGCC_GE_7 -DGCC_GE_8 -DHAVE_MPI -DMPI_WORKING_MODULE -DPREFIX_NAME=_gfortran_caf_ -I/opt/local/var/macports/build/_opt_PPCRosettaPorts_science_OpenCoarrays/OpenCoarrays/work/build/src/tests/integration/pde_solvers/coarrayBurgers/library -pipe -Os -m32 -mmacosx-version-min=10.6 -c /opt/local/var/macports/build/_opt_PPCRosettaPorts_science_OpenCoarrays/OpenCoarrays/work/OpenCoarrays-2.10.0/src/tests/integration/pde_solvers/coarrayBurgers/main.F90 -o CMakeFiles/coarray_burgers_pde.dir/main.F90.o` failed to compile.
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 Sergey Fedorov changed: What|Removed |Added CC||vital.had at gmail dot com --- Comment #17 from Sergey Fedorov --- The same failure happens on MacOS PPC with GCC12: /opt/local/var/macports/build/_opt_PPCRosettaPorts_science_OpenCoarrays/OpenCoarrays/work/OpenCoarrays-2.10.0/src/tests/integration/pde_solvers/coarrayBurgers/main.F90:3:20: 3 | use, intrinsic :: ieee_arithmetic, only : ieee_is_nan |1 Fatal Error: Cannot find an intrinsic module named 'ieee_arithmetic' at (1) compilation terminated. Error: command: `/opt/local/bin/mpif90-mpich-gcc12 -I/opt/local/var/macports/build/_opt_PPCRosettaPorts_science_OpenCoarrays/OpenCoarrays/work/build/include/OpenCoarrays-2.10.0_GNU-12.2.0 -fcoarray=lib -DGCC_GE_7 -DGCC_GE_8 -DHAVE_MPI -DMPI_WORKING_MODULE -DPREFIX_NAME=_gfortran_caf_ -I/opt/local/var/macports/build/_opt_PPCRosettaPorts_science_OpenCoarrays/OpenCoarrays/work/build/src/tests/integration/pde_solvers/coarrayBurgers/library -pipe -Os -m32 -mmacosx-version-min=10.6 -c /opt/local/var/macports/build/_opt_PPCRosettaPorts_science_OpenCoarrays/OpenCoarrays/work/OpenCoarrays-2.10.0/src/tests/integration/pde_solvers/coarrayBurgers/main.F90 -o CMakeFiles/coarray_burgers_pde.dir/main.F90.o` failed to compile.
[Bug c++/106901] New: False positive -Warray-bounds with -O2 or higher?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901
Bug ID: 106901
Summary: False positive -Warray-bounds with -O2 or higher?
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
Hi!
Here's some code snippet that I believe leads to a false positive for
Warray-bounds. It happens in trunk but not on GCC 12.2.
#include
bool bar(std::array const& vec,
std::size_t const size,
std::size_t const expected_size)
{
if (size < expected_size)
{
return false;
}
for (std::size_t i{expected_size}; i < size; ++i)
{
if (vec[i] != 0)
{
return false;
}
}
return true;
}
bool foo(std::array const& vec, std::size_t const size)
{
return bar(vec, size, 5);
}
In file included from :1:
In member function 'constexpr const std::array<_Tp, _Nm>::value_type&
std::array<_Tp, _Nm>::operator[](size_type) const [with _Tp = int; long
unsigned int _Nm = 5]',
inlined from 'bool bar(const std::array&, std::size_t,
std::size_t)' at :13:18,
inlined from 'bool foo(const std::array&, std::size_t)' at
:23:15:
/opt/compiler-explorer/gcc-trunk-20220910/include/c++/13.0.0/array:213:24:
warning: array subscript 5 is above array bounds of 'std::__array_traits::_Type' {aka 'const int [5]'} [-Warray-bounds]
213 | return _M_elems[__n];
|^
/opt/compiler-explorer/gcc-trunk-20220910/include/c++/13.0.0/array: In function
'bool foo(const std::array&, std::size_t)':
/opt/compiler-explorer/gcc-trunk-20220910/include/c++/13.0.0/array:109:55:
note: while referencing 'std::array::_M_elems'
109 | typename __array_traits<_Tp, _Nm>::_Type_M_elems;
| ^~~~
Example on Compiler Explorer:
https://godbolt.org/z/dKWdKrsTa
Since "size" is unknown to the compiler, it shouldn't be possible to tell with
certainty whether the loop is actually executed and therefore out-of-bounds
invoked.
Thanks!
[Bug c++/106901] False positive -Warray-bounds with -O2 or higher?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901 --- Comment #1 from Andrew Pinski --- Maybe I am reading the code wrong. But size will be >= 5 at the loop. So it will be executed. If size is >= 5. And that is what the warning is about.
[Bug c++/106901] False positive -Warray-bounds with -O2 or higher?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901 --- Comment #2 from Carlos Galvez --- If size == 5, expected_size == 5, then the loop is not executed, right?
[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652 --- Comment #12 from Jakub Jelinek --- Created attachment 53559 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53559&action=edit gcc13-pr106652-lib.patch Some unfinished library changes. Unfortunately, we seem to have a major problem with glibc. included from etc. on some arches does: # if __HAVE_FLOAT128 /* The type _Float128 exists only since GCC 7.0. */ # if !__GNUC_PREREQ (7, 0) || defined __cplusplus typedef __float128 _Float128; # endif ... #endif or typedef long double _Float128; etc. I'm afraid we'll need to fixincludes that and change in glibc. The question is to what exactly. I think with the compiler patch _Float are in C++ generally available as keyword but __STDCPP_FLOAT_T__ that the libstdc++ patch is using is only defined for C++23. The F or f literal suffixes pedwarn before C++23 but bet not in system headers, so glibc then could use those for C++ always for __GNUC_PREREQ (13, 0)?
[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652 Jakub Jelinek changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- grep finds these problematic spots: ./sysdeps/mips/ieee754/bits/floatn.h:typedef long double _Float128; ./sysdeps/ieee754/ldbl-128/bits/floatn.h:typedef long double _Float128; ./sysdeps/ia64/bits/floatn.h:typedef __float128 _Float128; ./sysdeps/powerpc/bits/floatn.h:typedef long double _Float128; ./sysdeps/powerpc/bits/floatn.h:typedef __float128 _Float128; ./sysdeps/x86/bits/floatn.h:typedef __float128 _Float128; ./bits/floatn-common.h:typedef float _Float16 __attribute__ ((__mode__ (__HF__))); ./bits/floatn-common.h:typedef float _Float32; ./bits/floatn-common.h:typedef long double _Float64; ./bits/floatn-common.h:typedef double _Float64;
[Bug c++/106901] False positive -Warray-bounds with -O2 or higher?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901 --- Comment #3 from Andrew Pinski --- Yes if size is 5, then yes it will not be executed. There is another bug about the wording of the warning. The warning is saying there might be an out of bounds due to the bounds of the loop is not bounded on the size of the array.
[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652 --- Comment #14 from Jakub Jelinek --- What I did in the patch is stop predefining __FLT32X_*__ macros etc. for C++ because C++ doesn't support those, so perhaps the if !__GNUC_PREREQ (7, 0) || defined __cplusplus conditions related to _Float (but not _Floatx) could be fixincluded or changed to if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && defined __FLT32_MANT_DIG__) or so (to differentiate between C++ doesn't have vs. has _Float keywords.
[Bug c++/106901] False positive -Warray-bounds with -O2 or higher?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901 --- Comment #4 from Carlos Galvez --- Makes sense! Would it make sense to classify this as "maybe-array-bounds" instead? Similar to "maybe-uninitialized" vs "uninitialized"
[Bug tree-optimization/106902] New: Program compiled with -O3 -fmfa produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 Bug ID: 106902 Summary: Program compiled with -O3 -fmfa produces different result Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jhllawrence963 at gmail dot com Target Milestone: --- Created attachment 53560 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53560&action=edit Sample C++ program Compiling the attached sample program with g++ -mfma -O3 and executing it leads to the wrong output starting with GCC version 11.1. The expected output is approximately 0.905017, but the actual output is -415762. GCC 10.4 and lower works as expected. Compiling with other optimization flags and -mno-fma works as expected too. About the program: It starts with an array of 1s, performs a local average for each element, then prints one result from the middle of the array. The algorithm has been reduced to remove code that is not needed to reproduce the bug, which is why the expected output is not exactly 1. The sample contains extra code which is not relevant to the bug, but removing them causes the bug to be not reproducible. The relevant parts have been commented with "FIXME". I'm not 100% certain, but there appears to be some loss of precision which gets compounded because the result of one loop iteration is used as an input to the next iterations. The program output becomes more incorrect as the input array size increases. GCC Version: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --with-build-config=bootstrap-lto --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (GCC)
[Bug target/106902] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 --- Comment #1 from Andrew Pinski --- Note -mfma should only increase the precision of doing a multiple and add in infinite precision before a rounding step. So if you depend on exactly rounding after each operation then you need to use -ffp-contract=off option.
[Bug tree-optimization/64992] More optimize opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com Status|ASSIGNED|RESOLVED Target Milestone|--- |13.0 Resolution|--- |FIXED --- Comment #13 from Roger Sayle --- This should now be fixed on mainline.
[Bug tree-optimization/98956] Failure to optimize out boolean left shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98956 Bug 98956 depends on bug 64992, which changed state. Bug 64992 Summary: More optimize opportunity https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64992 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/98956] Failure to optimize out boolean left shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98956 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||roger at nextmovesoftware dot com Target Milestone|--- |13.0 Resolution|--- |FIXED --- Comment #6 from Roger Sayle --- This should now be fixed on mainline.
[Bug tree-optimization/98954] ((X << CST0) & CST1) == 0 is not optimized to 0 == (X & (CST1 >> CST0))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98954 Roger Sayle changed: What|Removed |Added Target Milestone|--- |13.0 Status|ASSIGNED|RESOLVED CC||roger at nextmovesoftware dot com Resolution|--- |FIXED --- Comment #8 from Roger Sayle --- This should now be fixed on mainline.
