[Bug ipa/106158] IPA SRA ssa_name_only_returned_p is quadratic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106158 --- Comment #3 from Richard Biener --- it looks like the testcase no longer shows the issue(?) but the code in IPA SRA didn't really change here
[Bug tree-optimization/108440] rotate optimization may introduce new UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108440 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:05b9868b182bb9ed2013b39a0bc6297354a0db49 commit r13-5254-g05b9868b182bb9ed2013b39a0bc6297354a0db49 Author: Jakub Jelinek Date: Thu Jan 19 10:00:51 2023 +0100 forwprop: Further fixes for simplify_rotate [PR108440] As mentioned in the simplify_rotate comment, for e.g. ((T) ((T2) X << (Y & (B - 1 | ((T) ((T2) X >> ((-Y) & (B - 1 we already emit X r<< (Y & (B - 1)) as replacement. This PR is about the ((T) ((T2) X << Y)) OP ((T) ((T2) X >> (B - Y))) ((T) ((T2) X << (int) Y)) OP ((T) ((T2) X >> (int) (B - Y))) forms if T2 is wider than T. Unlike e.g. (X << Y) OP (X >> (B - Y)) which is valid just for Y in [1, B - 1], the above 2 forms are actually valid and do the rotates for Y in [0, B] - for Y 0 the X value is preserved by the left shift and right logical shift by B adds just zeros (but because the shift is in wider precision B is still valid shift count), while for Y equal to B X is preserved through the latter shift and the former adds just zeros. Now, it is unclear if we in the middle-end treat rotates with rotate count equal or larger than precision as UB or not, unlike shifts there are less reasons to do so, but e.g. expansion of X r<< Y if there is no rotate optab for the mode is emitted as (X << Y) | (((unsigned) X) >> ((-Y) & (B - 1))) and so with UB on Y == B. The following patch does multiple things: 1) for the above 2, asks the ranger if Y could be equal to B and if so, instead of using X r<< Y uses X r<< (Y & (B - 1)) 2) for the ((T) ((T2) X << Y)) | ((T) ((T2) X >> ((-Y) & (B - 1 ((T) ((T2) X << (int) Y)) | ((T) ((T2) X >> (int) ((-Y) & (B - 1 forms that were fixed 2 days ago it only punts if Y might be in the [B,B2-1] range but isn't known to be in the [0,B][2*B,2*B][3*B,3*B]... range. Because for Y which is a multiple of B but smaller than B2 it acts as a rotate too, left shift provides 0 and (-Y) & (B - 1) is 0 and so preserves X. Though, for the cases where Y is not known to be in [0,B-1] the patch also uses X r<< (Y & (B - 1)) rather than X r<< Y 3) as discussed with Aldy, instead of using global ranger it uses a pass specific copy but lazily created on first simplify_rotate that needs it; this e.g. handles rotate inside of if body where the guarding condition limits the shift count to some range which will not work with the global ranger (unless there is some SSA_NAME to attach the range to). Note, e.g. on x86 X r<< (Y & (B - 1)) and X r<< Y actually emit the same assembly because rotates work the same even for larger rotate counts, but that is handled only during combine. 2023-01-19 Jakub Jelinek PR tree-optimization/108440 * tree-ssa-forwprop.cc: Include gimple-range.h. (simplify_rotate): For the forms with T2 wider than T and shift counts of Y and B - Y add & (B - 1) masking for the rotate count if Y could be equal to B. For the forms with T2 wider than T and shift counts of Y and (-Y) & (B - 1), don't punt if range could be [B, B2], but only if range doesn't guarantee Y < B or Y = N * B. If range doesn't guarantee Y < B, also add & (B - 1) masking for the rotate count. Use lazily created pass specific ranger instead of get_global_range_query. (pass_forwprop::execute): Disable that ranger at the end of pass if it has been created. * c-c++-common/rotate-10.c: New test. * c-c++-common/rotate-11.c: New test.
[Bug middle-end/108300] `abort()` macro cause bootstrap failure on *-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300 --- Comment #16 from niXman --- (In reply to nightstrike from comment #15) > Someone on irc (jakub?) suggested just changing all of the aborts to > gcc_unreachable. Is that a viable option? I like that idea, I'm not sure it will be accepted...
[Bug tree-optimization/108440] rotate optimization may introduce new UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108440 --- Comment #9 from Jakub Jelinek --- Should be fixed on the trunk. Not sure about backports, the ranger related stuff might need to be simplified there.
[Bug target/101823] GCC generates the wrong string in the assembly code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101823
--- Comment #5 from bootmgr at 163 dot com ---
(In reply to niXman from comment #4)
> please provide the step-by-step instruction you used.
1. Extract binutils gcc mingw-w64 files to any where
Extract gmp mpfr mpc isl to gcc source directory
note: please make sure no subdirectories are included under
gcc-x.x.x/{gmp,mpfr,mpc,isl}.
these file can be found here
http://ftp.gnu.org/gnu/binutils/
http://ftp.gnu.org/gnu/gcc/
https://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/
https://gmplib.org/#DOWNLOAD
https://www.mpfr.org/mpfr-current/#download
https://www.multiprecision.org/mpc/download.html
https://libisl.sourceforge.io/
2. Clone the windows default manifest
(git://cygwin.com/git/cygwin-apps/windows-default-manifest.git)
3. These instructions are used to build cross toolchain and install to /mingw
(can be changed to other directory).
note: use "make -j$(nproc)" instead "make" to use more CPU cores.
1) Set PREFIX and PATH variables
export PREFIX=/mingw
export PATH=$PATH:$PREFIX/bin
note: if you are not root, please run "sudo mkdir /mingw && sudo chmod 777
/mingw"
2) chdir to gcc source directory and run "sed -i
's/${prefix}\/mingw\//${prefix}\//g' configure"
see also
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUILD#L155
3) Build binutils
../binutils-2.40/configure --disable-nls --disable-rpath --enable-64-bit-bfd
--enable-deterministic-archives --enable-install-libiberty
--target=x86_64-w64-mingw32 --prefix=$PREFIX
make && make install-strip
4) Install mingw-w64 headers
../mingw-w64-v10.0.0/mingw-w64-headers/configure --host=x86_64-w64-mingw32
--prefix=$PREFIX/x86_64-w64-mingw32
make && make install -j16
5) Build GCC core compiler
../gcc-12.2.0/configure --disable-multilib --disable-nls --disable-rpath
--disable-symvers --enable-languages=c,c++,lto --enable-mingw-wildcard
--enable-threads=posix --enable-libgomp --disable-libstdcxx-verbose
--enable-fully-dynamic-string --target=x86_64-w64-mingw32 --prefix=$PREFIX
make all-gcc && make install-strip-gcc
6) Build mingw-w64
../mingw-w64-v10.0.0/configure --enable-experimental --disable-lib32
--host=x86_64-w64-mingw32 --prefix=$PREFIX/x86_64-w64-mingw32
make && make install-strip
7) Build winpthreads (pthread support for windows)
../mingw-w64-v10.0.0/mingw-w64-libraries/winpthreads/configure
--host=x86_64-w64-mingw32 --prefix=$PREFIX/x86_64-w64-mingw32
8) Build windows default manifest
x86_64-w64-mingw32-windres -F pe-x86-64
./windows-default-manifest/default-manifest.rc -o
$PREFIX/x86_64-w64-mingw32/lib/default-manifest.o
note: this has the same effect as the following command
../windows-default-manifest/configure --host=x86_64-w64-mingw32
--prefix=$PREFIX/x86_64-w64-mingw32
make && make install
9) Build GCC compiler
chdir to build gcc directory and run "make && make install-strip"
4.Now we have a mingw-w64 cross toolchain (without zstd libiconv support)
So we can build canadian toolchain easily
1) Build binutils
../binutils-2.40/configure --disable-nls --disable-rpath --enable-64-bit-bfd
--enable-deterministic-archives --enable-install-libiberty
--host=x86_64-w64-mingw32 --prefix=$PREFIX
2) Build GCC
../gcc-12.2.0/configure --disable-multilib --disable-nls --disable-rpath
--disable-symvers --disable-win32-registry --enable-languages=c,c++,lto
--enable-mingw-wildcard --enable-threads=posix --enable-libgomp
--disable-libstdcxx-verbose --enable-fully-dynamic-string
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=$PREFIX
3) Build mingw-w64, winpthreads and windows default manifest
../mingw-w64-v10.0.0/configure --enable-experimental --disable-lib32
--host=x86_64-w64-mingw32 --prefix=$PREFIX
../mingw-w64-v10.0.0/mingw-w64-libraries/winpthreads/configure
--host=x86_64-w64-mingw32 --prefix=$PREFIX
x86_64-w64-mingw32-windres -F pe-x86-64
./windows-default-manifest/default-manifest.rc -o
install_dir/lib/default-manifest.o
[Bug target/101823] GCC generates the wrong string in the assembly code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101823 --- Comment #6 from bootmgr at 163 dot com --- (In reply to niXman from comment #3) > what GCC version was used on the host? $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --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 --enable-cet --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-11-xKiWfi/gcc-11-11.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-gcn/usr --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-serialization=2 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)
[Bug target/101823] GCC generates the wrong string in the assembly code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101823
--- Comment #7 from bootmgr at 163 dot com ---
(In reply to boot...@163.com from comment #5)
> (In reply to niXman from comment #4)
> > please provide the step-by-step instruction you used.
> 1. Extract binutils gcc mingw-w64 files to any where
> Extract gmp mpfr mpc isl to gcc source directory
> note: please make sure no subdirectories are included under
> gcc-x.x.x/{gmp,mpfr,mpc,isl}.
> these file can be found here
> http://ftp.gnu.org/gnu/binutils/
> http://ftp.gnu.org/gnu/gcc/
> https://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/
> https://gmplib.org/#DOWNLOAD
> https://www.mpfr.org/mpfr-current/#download
> https://www.multiprecision.org/mpc/download.html
> https://libisl.sourceforge.io/
>
> 2. Clone the windows default manifest
> (git://cygwin.com/git/cygwin-apps/windows-default-manifest.git)
>
> 3. These instructions are used to build cross toolchain and install to
> /mingw (can be changed to other directory).
> note: use "make -j$(nproc)" instead "make" to use more CPU cores.
>
> 1) Set PREFIX and PATH variables
>
> export PREFIX=/mingw
> export PATH=$PATH:$PREFIX/bin
> note: if you are not root, please run "sudo mkdir /mingw && sudo chmod 777
> /mingw"
>
> 2) chdir to gcc source directory and run "sed -i
> 's/${prefix}\/mingw\//${prefix}\//g' configure"
> see also
> https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/
> PKGBUILD#L155
>
> 3) Build binutils
> ../binutils-2.40/configure --disable-nls --disable-rpath --enable-64-bit-bfd
> --enable-deterministic-archives --enable-install-libiberty
> --target=x86_64-w64-mingw32 --prefix=$PREFIX
> make && make install-strip
>
> 4) Install mingw-w64 headers
> ../mingw-w64-v10.0.0/mingw-w64-headers/configure --host=x86_64-w64-mingw32
> --prefix=$PREFIX/x86_64-w64-mingw32
> make && make install -j16
>
> 5) Build GCC core compiler
> ../gcc-12.2.0/configure --disable-multilib --disable-nls --disable-rpath
> --disable-symvers --enable-languages=c,c++,lto --enable-mingw-wildcard
> --enable-threads=posix --enable-libgomp --disable-libstdcxx-verbose
> --enable-fully-dynamic-string --target=x86_64-w64-mingw32 --prefix=$PREFIX
> make all-gcc && make install-strip-gcc
>
> 6) Build mingw-w64
> ../mingw-w64-v10.0.0/configure --enable-experimental --disable-lib32
> --host=x86_64-w64-mingw32 --prefix=$PREFIX/x86_64-w64-mingw32
> make && make install-strip
>
> 7) Build winpthreads (pthread support for windows)
> ../mingw-w64-v10.0.0/mingw-w64-libraries/winpthreads/configure
> --host=x86_64-w64-mingw32 --prefix=$PREFIX/x86_64-w64-mingw32
>
> 8) Build windows default manifest
> x86_64-w64-mingw32-windres -F pe-x86-64
> ./windows-default-manifest/default-manifest.rc -o
> $PREFIX/x86_64-w64-mingw32/lib/default-manifest.o
> note: this has the same effect as the following command
> ../windows-default-manifest/configure --host=x86_64-w64-mingw32
> --prefix=$PREFIX/x86_64-w64-mingw32
> make && make install
>
> 9) Build GCC compiler
> chdir to build gcc directory and run "make && make install-strip"
>
> 4.Now we have a mingw-w64 cross toolchain (without zstd libiconv support)
> So we can build canadian toolchain easily
>
> 1) Build binutils
> ../binutils-2.40/configure --disable-nls --disable-rpath --enable-64-bit-bfd
> --enable-deterministic-archives --enable-install-libiberty
> --host=x86_64-w64-mingw32 --prefix=$PREFIX
>
> 2) Build GCC
> ../gcc-12.2.0/configure --disable-multilib --disable-nls --disable-rpath
> --disable-symvers --disable-win32-registry --enable-languages=c,c++,lto
> --enable-mingw-wildcard --enable-threads=posix --enable-libgomp
> --disable-libstdcxx-verbose --enable-fully-dynamic-string
> --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=$PREFIX
>
> 3) Build mingw-w64, winpthreads and windows default manifest
> ../mingw-w64-v10.0.0/configure --enable-experimental --disable-lib32
> --host=x86_64-w64-mingw32 --prefix=$PREFIX
> ../mingw-w64-v10.0.0/mingw-w64-libraries/winpthreads/configure
> --host=x86_64-w64-mingw32 --prefix=$PREFIX
> x86_64-w64-mingw32-windres -F pe-x86-64
> ./windows-default-manifest/default-manifest.rc -o
> install_dir/lib/default-manifest.o
After a lg compile, I get the same error on my Ubuntu WSL. but I think it
might be a problem with the WSL VM.
[Bug target/101823] GCC generates the wrong string in the assembly code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101823 --- Comment #8 from niXman --- (In reply to boot...@163.com from comment #7) > After a lg compile, I get the same error on my Ubuntu WSL. but I think > it might be a problem with the WSL VM. there is nothing unusual in your instruction except of WSL. try to rebuild it in linux host, or even on a real VM. because I've build a MinGW cross compiler many times but I've never seen anything like it.
[Bug ipa/94360] 6% run-time regression of 502.gcc_r against GCC 9 when compiled with -O2 and both PGO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94360 --- Comment #5 from Martin Jambor --- Well, if the current behavior is a good one (I have not looked at how size/performance trade-off works out) then I am also fine declaring this bug invalid.
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447 --- Comment #8 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #1) > This one started with r13-1933-g24012539ae3410174. > I think the problem is in: > > Folding statement: _3 = cmp1_10 & cmp2_11; > Not folded > Folding statement: if (_3 != 0) > Registering value_relation (x_8(D) <= y_9(D)) on (2->3) > Registering value_relation (x_8(D) >= y_9(D)) on (2->3) > Intersecting with existing (x_8(D) <= y_9(D)) to produce (x_8(D) == > y_9(D)) Updated. > and later > Folding statement: _1 = cmp1_10 | cmp2_11; > Relation adjustment: cmp1_10 and cmp2_11 combine to produce [irange] > _Bool [1, 1] > Queued stmt for removal. Folds to: 1 > > When NANs are honored, the above is not true for floating point comparisons. > x <= y and x >= y comparisons are signaling (if either operand is qNaN or > sNaN), x == y and x != y aren't (they only signal if either operand is > sNaN), and while *blink*. Woah. I did not know that. As Andrew mentions down thread, we had validate_relation() to verify whether a relation could be registered. So for example, given x == x, validate_relation() would be called at registration time and call the range-ops entry for EQ_EXPR, which would return false for this combo if x could be a NAN. For some forgotten reason, we forgot to call validate_relation() at the oracle's registry. My guess is that since we ignore the oracle's answers in frelop_early_resolve() (if !maybe_isnan) in each of the relational operators, it was no longer needed. Although for the testcase here, perhaps this would not have helped either. Is there anything in x_8 or y_9 that could be used indicate that we can't register these relations? : cmp1_10 = x_8(D) <= y_9(D); cmp2_11 = x_8(D) >= y_9(D); _3 = cmp1_10 & cmp2_11; if (_3 != 0) That is, when we see x_8 <= y_9, is there anything in either the range of x_8 or y_9 that would hint that we can't register the <= relation? I would have assumed that we could only register this relation if neither x_8 nor y_9 can have a NAN. Would this help? If this won't help, then perhaps the issue is in the oracle's relation intersection code. We would need a way to indicate that VREL_LE ^ VREL_GE is VREL_VARYING if the source operands may have a NAN (or some other fancy FP condition I don't understand ;-))?
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447 --- Comment #9 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #4) > I see fold_using_range::relation_fold_and_or > which sees relation1 VREL_LE and relation2 VREL_GE and !is_and, and because > of > relation_union (relation1, relation2) == VREL_VARYING fold it to 1. > But for floating point comparisons, LE | GE is not always true, it is true if > neither operand is NAN, otherwise false. Ah, it was the union not the intersect. So we need something here that would avoid resolving this to 1 if maybe_isnan() is true for either source operand.
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #10 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #9)
> (In reply to Jakub Jelinek from comment #4)
> > I see fold_using_range::relation_fold_and_or
> > which sees relation1 VREL_LE and relation2 VREL_GE and !is_and, and because
> > of
> > relation_union (relation1, relation2) == VREL_VARYING fold it to 1.
> > But for floating point comparisons, LE | GE is not always true, it is true
> > if
> > neither operand is NAN, otherwise false.
>
> Ah, it was the union not the intersect. So we need something here that
> would avoid resolving this to 1 if maybe_isnan() is true for either source
> operand.
One possibility would be to separate integral/pointer and floating point
relations,
use VREL_FP_LE etc. (and have more of them to cover even the extra ones).
Another would be based on whether it is a floating point relation or
integral/pointer relation use different relation_{intersect,union}, or pass
those functions a bool flag whether it is floating point or not (well, to be
precise, if NANs aren't honored, we can treat even floating point comparisons
as integral/pointer ones).
If we keep VREL_LE etc. for both floating point with NAN and other relations,
I'd think we should treat them as the floating point <= etc. comparisons with
their meaning for NANs operand if any. And then go through the intersect/union
tables and think about each case whether it holds even for NANs or not. I
assume most of the cases would be the same. Say <= intersected with >= is
really ==. But e.g. <= unioned with >= is not VREL_VARYING (the question is
what to return in that case though, VREL_LAST as some way to express
VREL_UNKNOWN?).
BTW, with the additions of VREL_PE*, the intersect/union tables grew quite a
lot but contain 0 (aka VREL_VARYING) in those extra slots. Does it make sense
to include VREL_PE* in those tables at all when it isn't really meaningful?
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447 --- Comment #11 from Aldy Hernandez --- Hmmm, I wonder if we could do this all in validate_relation like Andrew had planned. If NAN is a possibility in either x or y, then we could disallow any relation recording right off the bat, and avoid any special casing in union/intersect. Perhaps allow the != relation even if NAN?
[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108144 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|gaius at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- One issue is that for some reason for example libm2cor/Makefile.am has # Directory in which the compiler finds libraries etc. libsubdir = $(libdir)/gcc/$(target_alias)/$(version) # Used to install the shared libgcc. slibdir = @slibdir@ but the generated Makefile.in has those re-ordered to # Used to install the shared libgcc. slibdir = @slibdir@ ... # Directory in which the compiler finds libraries etc. libsubdir = $(libdir)/gcc/$(target_alias)/$(version) it looks like substitutes are re-ordered early here. But since at least inst_slibdir isn't used that should be harmless, inst_libdir doesn't suffer from this in the generated Makefile at least and I only see the version missing. Possibly because toolexeclibdir uses $(gcc_version) and not $(version). I'm testing replacing that with a canonical gcc_version everywhere.
[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108144 --- Comment #6 from Richard Biener --- Also honoring --with-gcc-major-version-only
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447 --- Comment #12 from Jakub Jelinek --- As a workaround in stage4, perhaps, but long term the relations make a lot of sense even for floating point with NANs. If you know <= relation between 2 vars and know the range of one of them, the other can be computed from it, ...
[Bug middle-end/108459] [OpenMP] ICE during GIMPLE pass: ompexp (segfault) in expand_omp_for_init_counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108459
--- Comment #1 from Jakub Jelinek ---
Slightly simplified:
void
foo (int x)
{
#pragma omp for collapse(2)
for (int i = 1; i <= 16; i++)
for (int j = i * x; j <= 16; j++)
;
}
Started with my r11-2537-g29e0ad452cdf001bcc commit, will have a look.
[Bug modula2/108462] New: duplicate install of static libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108462 Bug ID: 108462 Summary: duplicate install of static libraries Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- rguenther@ryzen:/tmp/obj> find ../install -name libm2cor.la ../install/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/libm2cor.la ../install/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/m2/m2cor/libm2cor.la ../install/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/32/m2/m2cor/libm2cor.la rguenther@ryzen:/tmp/obj> find ../install -name libm2cor.a ../install/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/libm2cor.a ../install/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/m2/m2cor/libm2cor.a ../install/lib64/gcc/x86_64-pc-linux-gnu/13.0.1/32/m2/m2cor/libm2cor.a both in ../13.0.1/ and ../13.0.1/m2/m2cor/ along .mod/.def files? They are installed via toolexeclib_LTLIBRARIES = libm2cor.la but in addition to that via install-data-local: force mkdir -p $(DESTDIR)$(inst_libdir)/$(MULTIDIR)$(M2LIBDIR) $(INSTALL_DATA) .libs/libm2cor.la $(DESTDIR)$(inst_libdir)/$(MULTIDIR)$(M2LIBDIR) chmod 644 $(DESTDIR)$(inst_libdir)/$(MULTIDIR)$(M2LIBDIR)libm2cor.la $(INSTALL_DATA) .libs/libm2cor.a $(DESTDIR)$(inst_libdir)/$(MULTIDIR)$(M2LIBDIR) chmod 644 $(DESTDIR)$(inst_libdir)/$(MULTIDIR)$(M2LIBDIR)libm2cor.a $(RANLIB) $(DESTDIR)$(inst_libdir)/$(MULTIDIR)$(M2LIBDIR)libm2cor.a why's that done? How could I check whether they are necessary or not?
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447 --- Comment #13 from rguenther at suse dot de --- On Thu, 19 Jan 2023, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447 > > --- Comment #12 from Jakub Jelinek --- > As a workaround in stage4, perhaps, but long term the relations make a lot of > sense even for floating point with NANs. If you know <= relation between 2 > vars and know the range of one of them, the other can be computed from it, ... I think it makes more sense to fix the relation combining code, maybe simply disable that for FP as a workaround?
[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746 --- Comment #21 from Segher Boessenkool --- As far as we (me, you; everybody) can tell it is fixed now. If one day we get a testcase showing it has in fact not been fixed, the problem is still there, we can reopen or link the testcases or etc.?
[Bug middle-end/108459] [OpenMP] ICE during GIMPLE pass: ompexp (segfault) in expand_omp_for_init_counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108459 --- Comment #2 from Jakub Jelinek --- --- gcc/omp-expand.cc.jj2023-01-02 09:32:49.399894958 +0100 +++ gcc/omp-expand.cc 2023-01-19 12:01:05.103410564 +0100 @@ -2003,8 +2003,8 @@ expand_omp_for_init_counts (struct omp_f t = fold_build2 (MINUS_EXPR, itype, unshare_expr (fd->loops[i].m2), unshare_expr (fd->loops[i].m1)); else if (fd->loops[i].m1) - t = fold_unary (NEGATE_EXPR, itype, - unshare_expr (fd->loops[i].m1)); + t = fold_build1 (NEGATE_EXPR, itype, +unshare_expr (fd->loops[i].m1)); else t = unshare_expr (fd->loops[i].m2); tree m2minusm1 fixes this, just need to play with testcases.
[Bug middle-end/108459] [OpenMP] ICE during GIMPLE pass: ompexp (segfault) in expand_omp_for_init_counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108459 --- Comment #3 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #2) > --- gcc/omp-expand.cc.jj 2023-01-02 09:32:49.399894958 +0100 > +++ gcc/omp-expand.cc 2023-01-19 12:01:05.103410564 +0100 > - t = fold_unary (NEGATE_EXPR, itype, > - unshare_expr (fd->loops[i].m1)); > + t = fold_build1 (NEGATE_EXPR, itype, > + unshare_expr (fd->loops[i].m1)); Confirmed - fold_unary only hands constants, fold_build1 calls the same but if it fails (i.e. "tem == NULL"), it calls then build1_loc (loc, code, type, op0 PASS_MEM_STAT); Question: Is the following needed or not? I have not fully followed whether "diff" and/or "ostep" could be a non-constant or not. At a glance, it looks as if a variable could be possible. --- a/gcc/omp-general.cc +++ b/gcc/omp-general.cc @@ -730,5 +730,4 @@ omp_extract_for_data (gomp_for *for_stmt, struct omp_for_data *fd, diff = fold_binary (TRUNC_DIV_EXPR, itype, - fold_unary (NEGATE_EXPR, itype, diff), - fold_unary (NEGATE_EXPR, itype, - ostep)); + build1 (NEGATE_EXPR, itype, diff), + build1 (NEGATE_EXPR, itype, ostep)); else
[Bug middle-end/108459] [OpenMP] ICE during GIMPLE pass: ompexp (segfault) in expand_omp_for_init_counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108459
--- Comment #4 from Jakub Jelinek ---
I think that ought to be fine.
There is
if (single_nonrect == -1
|| (loop->m1 && TREE_CODE (loop->m1) != INTEGER_CST)
|| (loop->m2 && TREE_CODE (loop->m2) != INTEGER_CST)
|| TREE_CODE (loop->n1) != INTEGER_CST
|| TREE_CODE (loop->n2) != INTEGER_CST
|| TREE_CODE (loop->step) != INTEGER_CST)
{
count = NULL_TREE;
continue;
}
some lines above that, after all, it is also using fold_binary rather than
fold_build2 etc. All that code is there to compute the constant number of
iterations and other helper values for non-rectangular loops with all constant
expressions.
[Bug middle-end/108459] [OpenMP] ICE during GIMPLE pass: ompexp (segfault) in expand_omp_for_init_counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108459 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2023-01-19 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #5 from Jakub Jelinek --- Created attachment 54305 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54305&action=edit gcc13-pr108459.patch Full untested patch.
[Bug rtl-optimization/108463] New: [13 Regression] ICE: in cselib_subst_to_values, at cselib.cc:2148 with -O2 -fsched2-use-superblocks -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463 Bug ID: 108463 Summary: [13 Regression] ICE: in cselib_subst_to_values, at cselib.cc:2148 with -O2 -fsched2-use-superblocks -g Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 54306 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54306&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 -fsched2-use-superblocks -g testcase.c testcase.c: In function 'foo': testcase.c:5:1: note: the ABI for passing parameters with 32-byte alignment has changed in GCC 4.6 5 | foo (V v) | ^~~ testcase.c:5:1: warning: AVX vector argument without AVX enabled changes the ABI [-Wpsabi] during RTL pass: sched2 testcase.c:9:1: internal compiler error: in cselib_subst_to_values, at cselib.cc:2148 9 | } | ^ 0x6ce4f5 cselib_subst_to_values(rtx_def*, machine_mode) /repo/gcc-trunk/gcc/cselib.cc:2148 0xf0fa26 cselib_subst_to_values(rtx_def*, machine_mode) /repo/gcc-trunk/gcc/cselib.cc:2193 0xf139dd cselib_subst_to_values_from_insn(rtx_def*, machine_mode, rtx_insn*) /repo/gcc-trunk/gcc/cselib.cc:2264 0x25c87c2 add_insn_mem_dependence /repo/gcc-trunk/gcc/sched-deps.cc:1741 0x25cd060 sched_analyze_2 /repo/gcc-trunk/gcc/sched-deps.cc:2688 0x25cd0e9 sched_analyze_2 /repo/gcc-trunk/gcc/sched-deps.cc:2806 0x25cdd3e sched_analyze_insn /repo/gcc-trunk/gcc/sched-deps.cc:2960 0x25d0595 deps_analyze_insn(deps_desc*, rtx_insn*) /repo/gcc-trunk/gcc/sched-deps.cc:3683 0x25d364e sched_analyze(deps_desc*, rtx_insn*, rtx_insn*) /repo/gcc-trunk/gcc/sched-deps.cc:3836 0x25d46d0 schedule_ebb(rtx_insn*, rtx_insn*, bool) /repo/gcc-trunk/gcc/sched-ebb.cc:505 0x25d4cc2 schedule_ebbs() /repo/gcc-trunk/gcc/sched-ebb.cc:655 0x137eb1c rest_of_handle_sched2 /repo/gcc-trunk/gcc/sched-rgn.cc:3749 0x137eb1c execute /repo/gcc-trunk/gcc/sched-rgn.cc:3890 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-5254-20230119100051-g05b9868b182-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r13-5254-20230119100051-g05b9868b182-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.1 20230119 (experimental) (GCC)
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447 --- Comment #14 from Aldy Hernandez --- (In reply to rguent...@suse.de from comment #13) > On Thu, 19 Jan 2023, jakub at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447 > > > > --- Comment #12 from Jakub Jelinek --- > > As a workaround in stage4, perhaps, but long term the relations make a lot > > of > > sense even for floating point with NANs. If you know <= relation between 2 > > vars and know the range of one of them, the other can be computed from it, > > ... > > I think it makes more sense to fix the relation combining code, maybe > simply disable that for FP as a workaround? Yeah, the combining code definitely needs some tweaks. Thinking out loud here... It looks like we ignore relations in the various relation fold_range() methods if NAN can be a possibility. See how frelop_early_resolve() only looks at the relation if the operands are !NAN. So perhaps this is why we never used validate_relation(). On the other hand, the op1_range methods *do* use the relations. For example, on EQ_EXPR (foperator_equal::op1_range), we clear NAN on the TRUE side because equality could never happen if there was a NAN present (regardless of VREL_*). On the FALSE side we set_nan() only if VREL_EQ. So we ignore the oracle's relations in fold_range() throughout, unless we're sure !NAN, and use the oracle from op1_range.
[Bug rtl-optimization/108463] [13 Regression] ICE: in cselib_subst_to_values, at cselib.cc:2148 with -O2 -fsched2-use-superblocks -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug rtl-optimization/108463] [13 Regression] ICE: in cselib_subst_to_values, at cselib.cc:2148 with -O2 -fsched2-use-superblocks -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-01-19 CC||aoliva at gcc dot gnu.org, ||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Priority|P3 |P1 --- Comment #1 from Jakub Jelinek --- Started with r13-5252-g3c99493bf39a7fef9213e
[Bug tree-optimization/108457] [13 Regression] tree-ssa-loop-niter.cc:2255:23: warning: variable 'mode' set but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108457 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Space between cast and mode. Though I think various other uses of these macros solve this by simply using SCALAR_INT_TYPE_MODE (utype) directly as argument to those macros rather than using a temporary variable.
[Bug tree-optimization/108457] [13 Regression] tree-ssa-loop-niter.cc:2255:23: warning: variable 'mode' set but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108457 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 54307 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54307&action=edit gcc13-pr108457.patch So I'd prefer this instead.
[Bug fortran/108435] [13 Regression] ICE in as_a, at is-a.h:242 since r13-142-g705bcedf6eae2d7c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108435 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Possibly dup of PR107424 or at least related to that.
[Bug bootstrap/107950] partial LTO linking of libbackend.a: gcc/gcc-rich-location.cc:207: undefined reference to `range_label_for_type_mismatch::get_text(unsigned int) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950 --- Comment #10 from Richard Biener --- I suppose a fix would be to provide a dummy implementation for range_label_for_type_mismatch::get_text in lto/, but I wonder how for example the fortran frontend avoids this issue? f951 has rich_location uses but no range_label_for_type_mismatch, it looks like range_label_for_* is used only from the C family frontends, so maybe another fix would be to move that class and implementation somewhere to c-family/?
[Bug modula2/108373] Update 'contrib/gcc_update:files_and_dependencies' for Modula-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108373 Gaius Mulley changed: What|Removed |Added Last reconfirmed||2023-01-19 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug other/108464] New: [13 Regression] Broken -fdebug-prefix-map since r13-3599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 Bug ID: 108464 Summary: [13 Regression] Broken -fdebug-prefix-map since r13-3599 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- Starting with r13-3599-ge5c15eb183f17e806ad -fdebug-prefix-map stopped working in some cases (breaks ccache testsuite among other things). Reproducer: mkdir -p foobar1/include foobar1/src echo 'int test;' > foobar1/include/test.h echo '#include ' > foobar1/src/test.c ln -sf foobar1 foobar2 cd foobar2 gcc -S -I include/ -fdebug-prefix-map=`pwd`= -g -dA src/test.c -o test.s; grep '\|foobar' test.s Before r13-3599, all the way back from r0-82686-gc8aea42ce2c691e4e8 when -fdebug-prefix-map= has been introduced, this prints (once or multiple times depending on exact version) and doesn't print any foobar strings. Even r13-3598 prints .long .LASF1 # DW_AT_comp_dir: "" .long .LASF1 # Directory Entry: 0: "" .string "" but starting with r13-3599 we print .long .LASF1 # DW_AT_comp_dir: "/home/jakub/foobar2" .long .LASF1 # Directory Entry: 0: "/home/jakub/foobar2" .string "/home/jakub/foobar2" instead, which is wrong because user asked for remapping of /home/jakub/foobar2 and it wasn't done.
[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Priority|P3 |P1 Target Milestone|--- |13.0 CC||law at gcc dot gnu.org, ||richard.purdie@linuxfoundat ||ion.org Ever confirmed|0 |1 Last reconfirmed||2023-01-19
[Bug tree-optimization/93444] [10/11 Regression] ssa-loop-im introduces unconditional use of uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93444 Richard Biener changed: What|Removed |Added Known to fail||12.2.0 Known to work||12.2.1, 13.0 Summary|[10/11/12/13 Regression]|[10/11 Regression] |ssa-loop-im introduces |ssa-loop-im introduces |unconditional use of|unconditional use of |uninitialized variable |uninitialized variable --- Comment #12 from Richard Biener --- This has been fixed with r13-4491-g44c8402d351605 on trunk and r12-8977-g812847a9d12c0b6 on the GCC 12 branch. It's unlikely going to be backported further.
[Bug ipa/95558] [10/11/12/13 Regression] Invalid IPA optimizations based on weak definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2020-06-09 00:00:00 |2023-1-19 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #16 from Richard Biener --- Re-confirmed. The bad attribute suggestion is also still there for the testcase in comment#1
[Bug ipa/103585] fatigue2 requires inlining of peridida to work well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585 --- Comment #14 from Martin Jambor --- Honza, what remains to be done here (if anything)?
[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 --- Comment #1 from Richard Purdie --- I can see why that would change behaviour with the patch :(. It is a tough dilemma since without the patch, files might have prefixes removed some of the time but not all the time, depending on whether they were accessed via a symlink (or similar) or not. It was effectively impossible to remap some prefix values meaning in some cases output files couldn't be build deterministically. One possible way to fix this issue might be to call realpath on DW_AT_comp_dir so that we're always working on canonicalized paths? I'm not sure if that would be acceptable or not, the challenge right now is that we're making comparisons against things which aren't always definitive.
[Bug tree-optimization/100061] [10/11 Regression] Comparison guarding undefined behaviour disappears
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100061 Richard Biener changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11 Regression] |Comparison guarding |Comparison guarding |undefined behaviour |undefined behaviour |disappears |disappears Known to fail||11.3.1 Known to work||12.1.0, 13.0 --- Comment #14 from Richard Biener --- Btw, eventually the refactoring done for PR105142 in r12-8012-gfc8d9e4497032d will help, at least the fixed problem is of similar nature. The original testcase seems fixed by this at least as we are no longer expanding the guarded c + 1.
[Bug modula2/108373] Update 'contrib/gcc_update:files_and_dependencies' for Modula-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108373 Gaius Mulley changed: What|Removed |Added CC||gaius at gcc dot gnu.org --- Comment #1 from Gaius Mulley --- Created attachment 54308 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54308&action=edit Proposed patch for contrb/gcc_update Here is a proposed patch adding the automatically generated files used by m2.
[Bug middle-end/105469] [10/11/12/13 Regression] "execution reached an unreachable program point" with -flto since r5-7027-g0b986c6ac777aa4e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105469 --- Comment #19 from Martin Jambor --- (In reply to Jakub Jelinek from comment #16) > Martin, is that a real fix for this or it just went latent? Not a fix, the bug mst be latent. But it is surprising so I'll have a look what happened too.
[Bug tree-optimization/102844] [10/11/12/13 Regression] DOM jump threading not copying block that became non-empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844 --- Comment #31 from Richard Biener --- The issue is still latent but cannot be reproduced on any maintained branch.
[Bug target/103100] [11/12/13 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100 --- Comment #13 from Richard Biener --- (In reply to Andrew Pinski from comment #10) > Updated patch submitted: > https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589254.html I think you need to ping your patches more aggressively ...
[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 --- Comment #2 from Jakub Jelinek --- Dunno about other uses of remap_filename, but for remap_debug_filename what that commit changed doesn't seem to be ever appropriate. Users pass often pass what they get from pwd to -fdebug-prefix-map=, and that is usually not the canonicalized path. And DW_AT_comp_dir was that same path as well and IMHO it would be a very bad idea to change that. Debug info contains relative paths in many cases, that also shouldn't be canonicalized, should be whatever user used in -I etc. options or #include paths etc. If one is mixing absolute paths and some are canonical and others aren't, one can use multiple -fdebug-prefix-map= options. But ignoring what user asked for is just wrong.
[Bug ipa/106158] IPA SRA ssa_name_only_returned_p is quadratic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106158 --- Comment #4 from Martin Jambor --- (In reply to Richard Biener from comment #3) > it looks like the testcase no longer shows the issue(?) but the code in IPA > SRA didn't really change here I have fixed quadratic behavior in ipa-param-manipulation.cc two weeks ago, so perhaps the real problem was there. ssa_name_only_returned_p is on my TODO list :-)
[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 --- Comment #3 from Richard Purdie --- (In reply to Jakub Jelinek from comment #2) > Dunno about other uses of remap_filename, but for remap_debug_filename what > that commit changed doesn't seem to be ever appropriate. I think it depends on your use case. For example if via debug-prefix-map you say you want: /somepath/somesources translated to /somewhere and then some code references ../somesources and ../../somesources from it's build tree, would you want the user to have to add mappings for those and any other combination some build system might end up generating due to it's source layout? > Users pass often > pass what they get from pwd to -fdebug-prefix-map=, and that is usually not > the canonicalized path. And DW_AT_comp_dir was that same path as well and > IMHO it would be a very bad idea to change that. Debug info contains > relative paths in many cases, that also shouldn't be canonicalized, should > be whatever user used in -I etc. options or #include paths etc. > If one is mixing absolute paths and some are canonical and others aren't, > one can use multiple -fdebug-prefix-map= options. But ignoring what user > asked for is just wrong. It can be argued that if you ask for my above example and it doesn't remap the relative accesses, it is also just wrong. I can say that with all the cross compiling we do (in Yocto Project), making this handle the corner cases improved our binary reproducibility quite significantly. gcc can revert the change but we'd just have to patch something in to handle this. Another possible option is to resolve both sides of the equation before deciding to remap or not (i.e. the directory in debug-prefix-map and the potential target)?
[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 --- Comment #4 from Jakub Jelinek --- Though, even for the other options the change doesn't seem to be a good idea as is. I think instead the syntax of those remapping options should be extended, so that for each of the pair one can choose the behavior which is wanted. Using the OLD=NEW syntax with the previous behavior, and some other to mark pairs where you want new behavior (dunno whether to mark those using say extra = at the end after NEW or whatever else). Then when populating file_prefix_map entries, one would record this non-canonicalizing vs. canonicalizing flag and in the latter case canonicalize the old_prefix path in the structure. remap_filename then would ideally lazily lrealpath when seeing first map entry with the bool flag indicating canonicalization.
[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108144 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:1cfaaa42296298ea2d2b22a93d3c8c17104e6cd3 commit r13-5255-g1cfaaa42296298ea2d2b22a93d3c8c17104e6cd3 Author: Richard Biener Date: Thu Jan 19 12:15:14 2023 +0100 modula2/108144 - fix --enable-version-specific-runtime-libs The following fixes --enable-version-specific-runtime-libs for the modula2 target libraries. The issue is that the install happens via for example toolexeclib_LTLIBRARIES = libm2cor.la and toolexeclibdir is set to $(toolexecdir)/$(gcc_version)$(MULTISUBDIR) but the Makefile.am do not define $(gcc_version) but instead $(version) which is used locally to define libsubdir. The fix is to consistently define and use $(gcc_version), also properly supporting --with-gcc-major-version-only PR modula2/108144 libgm2/ * configure.ac: Add GCC_BASE_VER. * configure: Re-generate. * Makefile.am: Use @get_gcc_base_ver@ for gcc_version. * libm2cor/Makefile.am: Likewise. Use gcc_version instead of version. * libm2iso/Makefile.am: Likewise. * libm2log/Makefile.am: Likewise. * libm2min/Makefile.am: Likewise. * libm2pim/Makefile.am: Likewise. * Makefile.in: Re-generate. * libm2cor/Makefile.in: Likewise. * libm2iso/Makefile.in: Likewise. * libm2log/Makefile.in: Likewise. * libm2min/Makefile.in: Likewise. * libm2pim/Makefile.in: Likewise.
[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108144 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- This particular issue should be fixed now.
[Bug c++/53932] [10/11/12/13 Regression] C++ reference variable to member of anonymous union in global is error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Keywords||wrong-code
--- Comment #6 from Richard Biener ---
The C++ frontend mangles union { int i; };
.local _ZL1i
.comm _ZL1i,4,4
but not the reference to the anonymous union member:
.globl r
.data
.align 8
.type r, @object
.size r, 8
r:
.quad i
they are even different decls:
i/3 (int i)
Type: variable
Body removed by symtab_remove_unreachable_nodes
Visibility: semantic_interposition artificial
References:
Referring: r/1 (addr)
Availability: not_available
Varpool flags:
r/1 (int& r)
Type: variable definition analyzed
Visibility: force_output externally_visible semantic_interposition no_reorder
asm_written public
Aux: @0x1
References: i/3 (addr)
Referring:
Availability: available
Varpool flags: initialized read-only const-value-known
_ZL1i/0 (_ZL1i)
Type: variable definition analyzed
Visibility: force_output semantic_interposition no_reorder
prevailing_def_ironly asm_written
Aux: @0x77ff3100
References:
Referring:
Availability: available
Varpool flags:
[Bug c++/53932] [10/11/12/13 Regression] C++ reference variable to member of anonymous union in global is error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932 Richard Biener changed: What|Removed |Added Keywords|assemble-failure| --- Comment #7 from Richard Biener --- clang produces r: .quad _Z1i so it seems that something goes wrong in the C++ frontend.
[Bug c++/83756] [10/11/12/13 Regression] gcc ICE in gimplify_expr on boost::call_once (-fms-extensions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83756 Richard Biener changed: What|Removed |Added Last reconfirmed|2021-12-02 00:00:00 |2023-1-19 --- Comment #17 from Richard Biener --- Re-confirmed. The gimplifier sees (gdb) p debug_tree (*expr_p) >> which supposedly is not to survive this long.
[Bug c++/97452] [coroutines] incorrect sequencing of await_resume() when multiple co_await expressions occur in a single statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97452 --- Comment #12 from David Ledger --- (In reply to David Ledger from comment #11) > This did not occur with GCC 10.2, it started in GCC 10.3: > > 10.3 (https://godbolt.org/z/jrdv31M17): > ``` > 0x15d1ed3 A > 0x15d1ed2 ~A > 0x15d1ed3 ~A > ``` > > 10.2 (https://godbolt.org/z/rrvKh9h6K): > ``` > 0x2322ed1 A > 0x2322ed1 ~A > ``` Please ignore, responded to incorrect thread.
[Bug c++/53932] [10/11/12/13 Regression] C++ reference variable to member of anonymous union in global is error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
It isn't just references:
static union { int i; };
int &r = i;
int s = i;
int *t = &i;
void
foo (int **p, int *q)
{
*p = &i;
*q = i;
}
Inside of the function or global constructor for s it works ok.
[Bug rtl-optimization/84345] [10/11/12/13 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84345 --- Comment #19 from Richard Biener --- As to comment#7 I agree, for some qsort comparators we probably do not care if the outcome is really sorted in the end and the issue with different qsort implementations producing differently sorted results is gone. Maybe for those we should have a separately named entry, skipping the verification? gcc_heuristic_sort_nocheck ()?
[Bug tree-optimization/85497] [10/11/12/13 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85497 Richard Biener changed: What|Removed |Added Target Milestone|10.5|8.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Richard Biener --- Let's close this one, we have a "duplicate" with another testcase for the scev-expr-size issues.
[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 Bug 59859 depends on bug 85497, which changed state. Bug 85497 Summary: [10/11/12/13 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85497 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug ipa/86905] [10/11/12/13 Regression] g++ ICE on valid code: verify_cgraph_node failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86905 Richard Biener changed: What|Removed |Added Last reconfirmed|2021-09-05 00:00:00 |2023-1-19 --- Comment #11 from Richard Biener --- re-confirmed
[Bug c++/86960] [10/11/12/13 Regression] ICE on specialization of member template with fixed parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86960 Richard Biener changed: What|Removed |Added Last reconfirmed|2018-08-14 00:00:00 |2023-1-19 --- Comment #14 from Richard Biener --- Re-confirmed.
[Bug tree-optimization/108457] [13 Regression] tree-ssa-loop-niter.cc:2255:23: warning: variable 'mode' set but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108457 --- Comment #5 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #3) > Space between cast and mode. > Though I think various other uses of these macros solve this by simply using > SCALAR_INT_TYPE_MODE (utype) directly as argument to those macros rather than > using a temporary variable. I am ok with that too. This was just a quick patch to try to help to get it unstuck ...
[Bug c++/86960] [10/11/12/13 Regression] ICE on specialization of member template with fixed parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86960 --- Comment #15 from Richard Biener --- Btw, clang rejects it: t.ii:8:15: error: non-type template parameter conflicts with previous non-type template parameter pack template ^ t.ii:3:19: note: previous non-type template parameter pack declared here template ^ t.ii:13:28: error: implicit instantiation of undefined template 'Outer::Inner' static_assert(Outer::Inner::value); ^ t.ii:4:12: note: template is declared here struct Inner; ^ 2 errors generated.
[Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380 since r12-5793-g689407ef916503b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108450 Martin Liška changed: What|Removed |Added Last reconfirmed||2023-01-19 Summary|[12/13 Regression] ICE in |[12/13 Regression] ICE in |sort_actual, at |sort_actual, at |fortran/intrinsic.cc:4380 |fortran/intrinsic.cc:4380 ||since ||r12-5793-g689407ef916503b2 CC||burnus at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r12-5793-g689407ef916503b2.
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2023-01-19 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- It's been there since Alexander's revision r13-4937-g012fdbc14233fbb4.
[Bug target/108411] [13 Regression] ICEs in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108411 --- Comment #1 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:a38c079248411ea9dc0610873b3366192315bfee commit r13-5256-ga38c079248411ea9dc0610873b3366192315bfee Author: Christophe Lyon Date: Mon Jan 16 17:48:25 2023 + aarch64: fix ICE in aarch64_layout_arg [PR108411] The previous patch added an assert which should not be applied to PST types (Pure Scalable Types) because alignment does not matter in this case. This patch moves the assert after the PST case is handled to avoid the ICE. PR target/108411 gcc/ * config/aarch64/aarch64.cc (aarch64_layout_arg): Improve comment. Move assert about alignment a bit later.
[Bug target/108411] [13 Regression] ICEs in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108411 --- Comment #2 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:74833b3165865a9373506f447720cf20f29c20c8 commit r13-5257-g74833b3165865a9373506f447720cf20f29c20c8 Author: Christophe Lyon Date: Tue Jan 17 13:10:10 2023 + aarch64: add -fno-stack-protector to some tests [PR108411] As discussed in the PR, these recently added tests fail when the testsuite is executed with -fstack-protector-strong. To avoid this, this patch adds -fno-stack-protector to dg-options. PR target/108411 gcc/testsuite * g++.target/aarch64/bitfield-abi-warning-align16-O2-extra.C: Add -fno-stack-protector. * g++.target/aarch64/bitfield-abi-warning-align16-O2.C: Likewise. * g++.target/aarch64/bitfield-abi-warning-align32-O2-extra.C: Likewise. * g++.target/aarch64/bitfield-abi-warning-align32-O2.C: Likewise. * g++.target/aarch64/bitfield-abi-warning-align8-O2.C: Likewise. * gcc.target/aarch64/bitfield-abi-warning-align16-O2-extra.c: Likewise. * gcc.target/aarch64/bitfield-abi-warning-align16-O2.c: Likewise. * gcc.target/aarch64/bitfield-abi-warning-align32-O2-extra.c: Likewise. * gcc.target/aarch64/bitfield-abi-warning-align32-O2.c: Likewise. * gcc.target/aarch64/bitfield-abi-warning-align8-O2.c: Likewise.
[Bug fortran/108453] [10/11/12/13 Regression] ICE in gfc_trans_use_stmts, at fortran/trans-decl.cc:5361 since r6-3704-g2b3f52a2d0fb22ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108453 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression] |ICE in gfc_trans_use_stmts, |ICE in gfc_trans_use_stmts, |at |at |fortran/trans-decl.cc:5361 |fortran/trans-decl.cc:5361 ||since ||r6-3704-g2b3f52a2d0fb22ba Last reconfirmed||2023-01-19 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||mikael at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r6-3704-g2b3f52a2d0fb22ba.
[Bug target/108411] [13 Regression] ICEs in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108411 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Christophe Lyon --- Fixed.
[Bug modula2/108462] duplicate install of static libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108462 Gaius Mulley changed: What|Removed |Added CC||gaius at gcc dot gnu.org --- Comment #1 from Gaius Mulley --- Created attachment 54309 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54309&action=edit script to run coroutine test cases To check whether they are necessary it should be possible to run the coroutine test cases. It will need adapting as the gcc-read-write and build are hard coded.
[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108144 Martin Liška changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #9 from Martin Liška --- With the Richi's patch, I still see an issue with 32-bit .so files: $ ~/Programming/gcc/configure --enable-languages=c,c++,m2 --prefix=/tmp/gcc --disable-libsanitizer --enable-valgrind-annotations --disable-bootstrap --with-system-zlib --with-gcc-major-version-only --enable-version-specific-runtime-libs $ make $ make install ... $ find . -name libm2cor.so ./x86_64-pc-linux-gnu/libgm2/libm2cor/.libs/libm2cor.so ./x86_64-pc-linux-gnu/32/libgm2/libm2cor/.libs/libm2cor.so while it's not installed into the destination folder: $ find /tmp/gcc -name libm2cor.so /tmp/gcc/lib64/gcc/x86_64-pc-linux-gnu/13/libm2cor.so while .a files are installed (apparently multiple times): $ find /tmp/gcc -name libm2cor.a /tmp/gcc/lib64/gcc/x86_64-pc-linux-gnu/13/libm2cor.a /tmp/gcc/lib64/gcc/x86_64-pc-linux-gnu/13/m2/m2cor/libm2cor.a /tmp/gcc/lib64/gcc/x86_64-pc-linux-gnu/13/32/m2/m2cor/libm2cor.a @Richi: Can you please take a look?
[Bug middle-end/108465] New: Optimize (a < b) == (b < a) to a == b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108465
Bug ID: 108465
Summary: Optimize (a < b) == (b < a) to a == b
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
For GCC 12 the following code with -O2:
int compare_eq(int a, int b) {
return ((a < b) == (b < a));
}
compiles into the following assembly:
compare_eq(int, int):
cmp edi, esi
setldl
setgal
cmp dl, al
seteal
movzx eax, al
ret
Which is suboptimal. More optimal assembly would be:
compare_eq(int, int):
xor eax, eax
cmp edi, esi
seteal
ret
Godbolt Playground: https://godbolt.org/z/4sfcTjjjb
Motivation: in generic C++ code the comparison is often done via a functor. The
algorithm is only allowed to use that functor:
if (__comp(a, b) == __comp(b, a)) {
return x;
} else if (__comp(b, a)) {
return y;
}
Because of that, with the inlined functor the comparison becomes ((a < b) == (b
< a))
[Bug tree-optimization/107881] (a <= b) == (b >= a) should be optimized to (a == b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107881 Andrew Pinski changed: What|Removed |Added CC||antoshkka at gmail dot com --- Comment #9 from Andrew Pinski --- *** Bug 108465 has been marked as a duplicate of this bug. ***
[Bug middle-end/108465] Optimize (a < b) == (b < a) to a == b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108465 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Almost Exact dup of bug 107881. *** This bug has been marked as a duplicate of bug 107881 ***
[Bug modula2/108462] duplicate install of static libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108462 --- Comment #2 from Gaius Mulley --- There should be archives in the different architecture directories as per normal. Accompanying these should be the library module source SYSTEM.def (which could vary depending upon architectural characteristics). The remaining sources are copies from the source tree. It certainly looks as if the source files in ../13.0.1 are unnecessary given the driver search path uses: -I ... 13.0.1/m2/m2pim-L ... 13.0.1/m2/m2pim I think the static archives and sources in 13.0.1 could be removed.
[Bug modula2/108373] Update 'contrib/gcc_update:files_and_dependencies' for Modula-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108373 --- Comment #2 from Gaius Mulley --- git pushed the attachment and propose that the PR is closed.
[Bug c/108466] New: inconsistent -Wmaybe-uninitialized warning location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108466
Bug ID: 108466
Summary: inconsistent -Wmaybe-uninitialized warning location
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
With gcc-12 (Debian 12.2.0-14) 12.2.0, the -Wmaybe-uninitialized warning
location depends on the declared type. This is inconsistent.
To reproduce, consider a tst.c file:
int f(void);
int g(void)
{
T a;
if (f())
a = f();
if (f())
return 0;
else
return a;
}
I get:
$ for i in int long; do echo; echo "Type $i"; gcc-12 -O2 -Wmaybe-uninitialized
-DT=$i -c tst.c; done
Type int
tst.c: In function ‘g’:
tst.c:11:12: warning: ‘a’ may be used uninitialized [-Wmaybe-uninitialized]
11 | return a;
|^
tst.c:4:5: note: ‘a’ was declared here
4 | T a;
| ^
Type long
tst.c: In function ‘g’:
tst.c:4:5: warning: ‘a’ may be used uninitialized [-Wmaybe-uninitialized]
4 | T a;
| ^
[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 --- Comment #5 from Richard Purdie --- (In reply to Jakub Jelinek from comment #4) > Though, even for the other options the change doesn't seem to be a good idea > as is. > I think instead the syntax of those remapping options should be extended, so > that for each of the pair one can choose the behavior which is wanted. > Using the OLD=NEW syntax > with the previous behavior, and some other to mark pairs where you want new > behavior > (dunno whether to mark those using say extra = at the end after NEW or > whatever else). > Then when populating file_prefix_map entries, one would record this > non-canonicalizing vs. canonicalizing flag and in the latter case > canonicalize the old_prefix path in the structure. > remap_filename then would ideally lazily lrealpath when seeing first map > entry with the bool flag indicating canonicalization. Having some way to enable the behaviour would be very valuable to the places we use prefix mapping so we could make that work FWIW.
[Bug modula2/108144] m2 does not respect --enable-version-specific-runtime-libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108144 --- Comment #10 from Jonathan Wakely --- Isn't --enable-version-specific-runtime-libs completely broken anyway? See PR 32415
[Bug middle-end/108448] GCC Elides Assignment to Pointer and memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448 --- Comment #8 from Gavin Howard --- Created attachment 54310 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54310&action=edit Amalgamation with License Header Not important for the bug, but I reuploaded the amalgamation with its proper license header. Sorry; need to do this for legal reasons.
[Bug middle-end/108448] GCC Elides Assignment to Pointer and memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448 --- Comment #9 from Gavin Howard --- > I suspect cmake didn't add -fno-strict-aliasing really. It did. I ran the build under `intercept-build` and looked at the `compile_commands.json` output. It had the `-fno-strict-aliasing` for every file. Anyway, I do not like your solution since it has a `void**`, the legality of which is dubious, but I tried it in `amal.c`, both with and without strict aliasing. (And I know it had `-fno-strict-aliasing` because I did the command-line by hand.) Both times still resulted in the failure. I even tried changing the `val_ptr` argument to be a `y_uchar*`, since that aliases everything, and it still failed, with and without strict aliasing.
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #15 from Jakub Jelinek ---
I went through the whole rr_{intersect,union}_table tables and I think just
--- gcc/value-relation.cc.jj2023-01-02 09:32:42.088000605 +0100
+++ gcc/value-relation.cc 2023-01-19 16:20:06.490126901 +0100
@@ -115,7 +115,7 @@ relation_kind rr_union_table[VREL_LAST][
{ VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING,
VREL_VARYING, VREL_VARYING, VREL_VARYING },
// VREL_UNDEFINED
- { VREL_VARYING, VREL_LT, VREL_LE, VREL_GT, VREL_GE, VREL_UNDEFINED,
+ { VREL_VARYING, VREL_UNDEFINED, VREL_LT, VREL_LE, VREL_GT, VREL_GE,
VREL_EQ, VREL_NE },
// VREL_LT
{ VREL_VARYING, VREL_LT, VREL_LT, VREL_LE, VREL_NE, VREL_VARYING, VREL_LE,
is really wrong for the integral/pointer relations (plus the question what to
do with the VREL_PE* relations and whether they need to be in the tables or
punted on by the caller somehow).
Now, when considering the relations in the fp with NAN meaning they have in
C/C++
(and assuming we don't try to replace say two actual comparisons in the IL with
one
with different exception behavior), the only relations in the tables which are
true for unordered operand(s) are VREL_VARYING and VREL_NE. Maybe I miss
something, but I can't think of an inappropriate intersection - VREL_VARYING
intersects anything is anything,
VREL_VARYING intersect VREL_VARYING is the only one that gives VREL_VARYING,
VREL_{VARYING,NE} intersect VREL_NE or vice versa the only one that gives
VREL_NE
and VREL_UNDEFINED returned only from intersections of anything and
VREL_UNDEFINED, or
LT/LE/GT/GE vs. each other where there is no overlap (but in that case neither
allows NANs), LT/GT vs. EQ (ditto) and EQ vs. NE (one relation doesn't allow
NAN but the other does, so they aren't allowed.
As for unions - LT U GT or vice versa is incorrectly NE, should be LAST or LTGT
or some other way how to express we can't express it. LT U GE or LE U GT or LE
U GE or vice versa are incorrectly VARYING, when they are together ORDERED (so
again, need some way how to express that). Can't find anything else wrong.
But unless we use VR_UNKNOWN or VR_LAST or whatever to stand for something we
really don't know how to handle, we'd need the various combinations that
tree.def has on top of the basics, LTGT, UNORDERED, ORDERED, UNLT, UNLE, UNGT,
UNGE and UNEQ.
[Bug tree-optimization/108467] New: false positive -Wmaybe-uninitialized warning at -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108467
Bug ID: 108467
Summary: false positive -Wmaybe-uninitialized warning at -O1 or
higher
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider the following code, derived from MPFR's sub1sp.c (where the issue
occurred since at least GCC 4.9.4 and the warning was silenced with the "sh =
sh" trick via an INITIALIZED() macro):
extern long emin;
extern long emax;
int f(void);
int g(void)
{
int sh, rb, sb;
if (f())
rb = sb = 0;
else
{
sh = f();
sb = f();
rb = f();
}
(0 >= emin && 0 <= emax) || (f(), __builtin_unreachable(), 0);
if (rb == 0 && sb == 0)
return 0;
else
return sh;
}
With gcc-12 (Debian 12.2.0-14) 12.2.0, I get:
$ gcc-12 -O2 -Wmaybe-uninitialized -c tst.c
tst.c: In function ‘g’:
tst.c:23:12: warning: ‘sh’ may be used uninitialized [-Wmaybe-uninitialized]
23 | return sh;
|^~
tst.c:8:7: note: ‘sh’ was declared here
8 | int sh, rb, sb;
| ^~
The warning also occurs at -O1 and -O3. It disappears if I slightly modify the
code.
Note: During the code reduction, I also got the warning, but with a different
location. However, the code was more complex, and I've already reported
PR108466 about a location issue (where the -Wmaybe-uninitialized is correct).
So I haven't reported an additional issue about the location.
[Bug tree-optimization/108467] false positive -Wmaybe-uninitialized warning at -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108467 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Known to fail||4.1.2 Last reconfirmed||2023-01-19 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- After normalization [USE]: _7 = PHI <0(13), sh_4(8)> is conditional on: ((NOT (_3 == 0)) AND (emax.3_2 >= 0) AND (emin.2_1 <= 0)) _3 = rb_5 | sb_6; if (_3 == 0) Confirmed.
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447 --- Comment #16 from Jakub Jelinek --- BTW, because both union and intersect are commutative, so perhaps we should have a self-test that verifies that. Guess that would catch the VREL_UNDEFINED line errors.
[Bug c++/53932] [10/11/12/13 Regression] C++ reference variable to member of anonymous union in global is error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932 --- Comment #9 from Jakub Jelinek --- So, the problem is that build_anon_union_vars builds artificial variables for the anon union members and they those VAR_DECLs have DECL_VALUE_EXPR set to the D.2763.i and similar COMPONENT_REFs. But VAR_DECLs with DECL_VALUE_EXPRs are only actually replaced with those DECL_VALUE_EXPR expressions during gimplification or regimplification (which explains why it works fine inside of code in functions or global constructors). Nothing replaces them in DECL_INITIAL expressions of statically initialized vars.
[Bug c++/108238] returns_nonnull attribute with auto return type fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108238
--- Comment #2 from Barnabás Pőcze ---
Here is a change that I believe might address this. It seems to work but I have
never done anything in gcc, so probably has shortcomings.
The error points to the return expression, like this:
asd2.cpp: In function ‘auto f2()’:
asd2.cpp:9:20: error: ‘returns_nonnull’ attribute on a function not returning
a pointer
9 | auto f2() { return 42; }
|^~
---
diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index 4667f6de311..50f5ad6b8f1 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -5761,8 +5761,9 @@ static tree
handle_returns_nonnull_attribute (tree *node, tree name, tree, int,
bool *no_add_attrs)
{
+ auto type_code = TREE_CODE (TREE_TYPE (*node));
// Even without a prototype we still have a return type we can check.
- if (TREE_CODE (TREE_TYPE (*node)) != POINTER_TYPE)
+ if (type_code != POINTER_TYPE && type_code != TEMPLATE_TYPE_PARM)
{
error ("%qE attribute on a function not returning a pointer", name);
*no_add_attrs = true;
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 1656d02d6d1..b3ae608b350 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -12305,6 +12305,10 @@ apply_deduced_return_type (tree fco, tree return_type)
if (return_type == error_mark_node)
return;
+ tree returns_nonnull = lookup_attribute("returns_nonnull", TYPE_ATTRIBUTES
(TREE_TYPE (fco)));
+ if (returns_nonnull && TREE_CODE (return_type) != POINTER_TYPE)
+error ("% attribute on a function not returning a
pointer");
+
if (DECL_CONV_FN_P (fco))
DECL_NAME (fco) = make_conv_op_name (return_type);
[Bug c++/53932] [10/11/12/13 Regression] C++ reference variable to member of anonymous union in global is error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- Created attachment 54311 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54311&action=edit gcc13-pr53932.patch Untested fix.
[Bug c++/108468] New: ICE in most_specialized_partial_spec/builtin_guide_p in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108468
Bug ID: 108468
Summary: ICE in most_specialized_partial_spec/builtin_guide_p
in C++20 mode
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ed at catmur dot uk
Target Milestone: ---
Since 11.1, the following ices in -std=c++20 and later:
template struct C { template static constexpr int x = 1; };
template template int C::x = 2;
int y = C<0>::x;
0x23ae54e internal_error(char const*, ...)
???:0
0xc5b614 deduction_guide_p(tree_node const*)
???:0
0xc5be2c builtin_guide_p(tree_node const*)
???:0
0xc82bdf most_specialized_partial_spec(tree_node*, int)
???:0
0xc83a76 instantiate_template(tree_node*, tree_node*, int)
???:0
0xc8c0d8 finish_template_variable(tree_node*, int)
???:0
0xcce05f finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
???:0
[Bug c++/108468] [11/12/13 Regression] ICE in most_specialized_partial_spec/builtin_guide_p in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108468 Marek Polacek changed: What|Removed |Added Target Milestone|--- |11.4 Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Priority|P3 |P2 Last reconfirmed||2023-01-19 Summary|ICE in |[11/12/13 Regression] ICE |most_specialized_partial_sp |in |ec/builtin_guide_p in C++20 |most_specialized_partial_sp |mode|ec/builtin_guide_p in C++20 ||mode Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed. Started with r11-1615-g6b161257f9f8c7: commit 6b161257f9f8c7a26b7d119ebc32cbbc54d2e508 Author: Jason Merrill Date: Mon Jun 22 15:44:45 2020 -0400 c++: Improve CTAD for aggregates [PR93976] P2082R1 adjusted the rules for class template argument deduction for an aggregate to better handle arrays and pack expansions.
[Bug testsuite/108469] New: FAIL: g++.dg/pr104869.C (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108469 Bug ID: 108469 Summary: FAIL: g++.dg/pr104869.C (test for excess errors) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../xg++ -B /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../ /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/pr104869.C -fdiagnostics-plain-output -nostdinc++ -I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -fvisibility=hidden -std=c++11 -L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/experimental/.libs -lm -o ./pr104869.exe ld: (Warning) Potential unresolved symbol "main": shared library reference is resolved to non-exported definition in file "/var/tmp//cc8TLIK5.o". 1 warnings. FAIL: g++.dg/pr104869.C (test for excess errors) Excess errors: ld: (Warning) Potential unresolved symbol "main": shared library reference is resolved to non-exported definition in file "/var/tmp//cc8TLIK5.o". 1 warnings.
[Bug fortran/108434] [12/13 Regression] ICE in class_allocatable, at fortran/expr.cc:5000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108434 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:117848f425a3c0eda85517b4bdaf2ebe3bc705c2 commit r13-5260-g117848f425a3c0eda85517b4bdaf2ebe3bc705c2 Author: Harald Anlauf Date: Wed Jan 18 22:13:29 2023 +0100 Fortran: error recovery for invalid CLASS component [PR108434] gcc/fortran/ChangeLog: PR fortran/108434 * expr.cc (class_allocatable): Prevent NULL pointer dereference or invalid read. (class_pointer): Likewise. gcc/testsuite/ChangeLog: PR fortran/108434 * gfortran.dg/pr108434.f90: New test.
[Bug analyzer/108455] -Wanalyzer-deref-before-check false positive seen in git pack-revindex.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108455 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:0d6f7b1dd62e9c9dccb0b9b673f9cc3238b7ea6d commit r13-5261-g0d6f7b1dd62e9c9dccb0b9b673f9cc3238b7ea6d Author: David Malcolm Date: Thu Jan 19 13:51:16 2023 -0500 analyzer: use dominator info in -Wanalyzer-deref-before-check [PR108455] My integration testing [1] of -fanalyzer in GCC 13 is showing a lot of diagnostics from the new -Wanalyzer-deref-before-check warning on real-world C projects, and most of these seem to be false positives. This patch updates the warning to make it much less likely to fire: - only intraprocedural cases are now reported - reject cases in which there are control flow paths to the check that didn't come through the dereference, by looking at BB dominator information. This fixes a false positive seen in git-2.39.0's pack-revindex.c: load_revindex_from_disk (PR analyzer/108455), in which a shared "cleanup:" section checks "data" for NULL, and depending on how much of the function is executed "data" might or might not have already been dereferenced. The counts of -Wanalyzer-deref-before-check diagnostics in [1] before/after this patch show this improvement: Known false positives:6 -> 0 (-6) Known true positives: 1 -> 1 Unclassified positives: 123 -> 63 (-60) [1] https://github.com/davidmalcolm/gcc-analyzer-integration-tests gcc/analyzer/ChangeLog: PR analyzer/108455 * analyzer.h (class checker_event): New forward decl. (class state_change_event): Indent. (class warning_event): New forward decl. * checker-event.cc (state_change_event::state_change_event): Add "enode" param. (warning_event::get_desc): Update for new param of evdesc::final_event ctor. * checker-event.h (state_change_event::state_change_event): Add "enode" param. (state_change_event::get_exploded_node): New accessor. (state_change_event::m_enode): New field. (warning_event::warning_event): New "enode" param. (warning_event::get_exploded_node): New accessor. (warning_event::m_enode): New field. * diagnostic-manager.cc (state_change_event_creator::on_global_state_change): Pass src_node to state_change_event ctor. (state_change_event_creator::on_state_change): Likewise. (null_assignment_sm_context::set_next_state): Pass NULL for new param of state_change_event ctor. * infinite-recursion.cc (infinite_recursion_diagnostic::add_final_event): Update for new param of warning_event ctor. * pending-diagnostic.cc (pending_diagnostic::add_final_event): Pass enode to warning_event ctor. * pending-diagnostic.h (evdesc::final_event): Add reference to warning_event. * sm-malloc.cc: Include "analyzer/checker-event.h" and "analyzer/exploded-graph.h". (deref_before_check::deref_before_check): Initialize new fields. (deref_before_check::emit): Reject warnings in which we were unable to determine the enodes of the dereference and the check. Reject warnings interprocedural warnings. Reject warnings in which the dereference doesn't dominate the check. (deref_before_check::describe_state_change): Set m_deref_enode. (deref_before_check::describe_final_event): Set m_check_enode. (deref_before_check::m_deref_enode): New field. (deref_before_check::m_check_enode): New field. gcc/testsuite/ChangeLog: PR analyzer/108455 * gcc.dg/analyzer/deref-before-check-1.c: Add test coverage involving dominance. * gcc.dg/analyzer/deref-before-check-pr108455-1.c: New test. * gcc.dg/analyzer/deref-before-check-pr108455-git-pack-revindex.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/108455] -Wanalyzer-deref-before-check false positive seen in git pack-revindex.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108455 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/102471] RFE: add support to analyzer testsuite for running SAMATE/SARD tests (e.g. Juliet Test Suite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102471 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |MOVED --- Comment #7 from David Malcolm --- Marking this one as RESOLVED MOVED, since I'm now doing this in: https://github.com/davidmalcolm/gcc-analyzer-integration-tests
[Bug c++/107797] "warning right operand of comma operator has no effect" for expressions with no comma operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107797 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Marek Polacek --- This seems to work: diff --git a/gcc/cp/cvt.cc b/gcc/cp/cvt.cc index 0cbfd8060cb..d1e34d7de1a 100644 --- a/gcc/cp/cvt.cc +++ b/gcc/cp/cvt.cc @@ -711,8 +711,11 @@ ocp_convert (tree type, tree expr, int convtype, int flags, return error_mark_node; if (e == TREE_OPERAND (expr, 1)) return expr; - return build2_loc (EXPR_LOCATION (expr), COMPOUND_EXPR, TREE_TYPE (e), -TREE_OPERAND (expr, 0), e); + e = build2_loc (EXPR_LOCATION (expr), COMPOUND_EXPR, TREE_TYPE (e), + TREE_OPERAND (expr, 0), e); + if (warning_suppressed_p (expr, OPT_Wunused_value)) + suppress_warning (e, OPT_Wunused_value); + return e; } complete_type (type); diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc index f816c474cef..52e96fbe590 100644 --- a/gcc/cp/init.cc +++ b/gcc/cp/init.cc @@ -3800,6 +3800,8 @@ build_new_1 (vec **placement, tree type, tree nelts, if (cookie_expr) rval = build2 (COMPOUND_EXPR, TREE_TYPE (rval), cookie_expr, rval); + suppress_warning (rval, OPT_Wunused_value); + if (rval == data_addr && TREE_CODE (alloc_expr) == TARGET_EXPR) /* If we don't have an initializer or a cookie, strip the TARGET_EXPR and return the call (which doesn't need to be adjusted). */
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #17 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #15)
> I went through the whole rr_{intersect,union}_table tables and I think just
> --- gcc/value-relation.cc.jj 2023-01-02 09:32:42.088000605 +0100
> +++ gcc/value-relation.cc 2023-01-19 16:20:06.490126901 +0100
> @@ -115,7 +115,7 @@ relation_kind rr_union_table[VREL_LAST][
>{ VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING,
> VREL_VARYING, VREL_VARYING, VREL_VARYING },
> // VREL_UNDEFINED
> - { VREL_VARYING, VREL_LT, VREL_LE, VREL_GT, VREL_GE, VREL_UNDEFINED,
> + { VREL_VARYING, VREL_UNDEFINED, VREL_LT, VREL_LE, VREL_GT, VREL_GE,
> VREL_EQ, VREL_NE },
> // VREL_LT
>{ VREL_VARYING, VREL_LT, VREL_LT, VREL_LE, VREL_NE, VREL_VARYING, VREL_LE,
> is really wrong for the integral/pointer relations (plus the question what
> to do with the VREL_PE* relations and whether they need to be in the tables
> or punted on by the caller somehow).
THat was my conclusions as well.
As for the PE's.. it seemed easier just to leave the partial equivalences
there as the table only grows from 64 to 144 entries, and in the grand scheme
seemed easier than trying to add runtime checks for relation kind ranges just
to avoid those few extra words.
Besides, if we ever end up with x != y when there is a partial equivalence, we
may also be able to conclude x > y or something else.. just left the window
open for exploration.
>
> Now, when considering the relations in the fp with NAN meaning they have in
> C/C++
> (and assuming we don't try to replace say two actual comparisons in the IL
> with one
> with different exception behavior), the only relations in the tables which
> are true for unordered operand(s) are VREL_VARYING and VREL_NE. Maybe I
> miss something, but I can't think of an inappropriate intersection -
> VREL_VARYING intersects anything is anything,
> VREL_VARYING intersect VREL_VARYING is the only one that gives VREL_VARYING,
> VREL_{VARYING,NE} intersect VREL_NE or vice versa the only one that gives
> VREL_NE
> and VREL_UNDEFINED returned only from intersections of anything and
> VREL_UNDEFINED, or
> LT/LE/GT/GE vs. each other where there is no overlap (but in that case
> neither allows NANs), LT/GT vs. EQ (ditto) and EQ vs. NE (one relation
> doesn't allow NAN but the other does, so they aren't allowed.
> As for unions - LT U GT or vice versa is incorrectly NE, should be LAST or
> LTGT or some other way how to express we can't express it. LT U GE or LE U
> GT or LE U GE or vice versa are incorrectly VARYING, when they are together
> ORDERED (so again, need some way how to express that). Can't find anything
> else wrong.
> But unless we use VR_UNKNOWN or VR_LAST or whatever to stand for something
> we really don't know how to handle, we'd need the various combinations that
> tree.def has on top of the basics, LTGT, UNORDERED, ORDERED, UNLT, UNLE,
> UNGT, UNGE and UNEQ.
For this release, I wouldn't want to add too much extra stuff. Im inclined to
handle this pretty much where the problems arise as I think it is fairly
localized.
For the next release, I'm inclined to enhance the oracle and relations such
that any range class can specify its own relation sets.. so irange (and most
others) would use a set which implements what we have, and we could introduce a
floating point relation set which includes something like "<>" and "<=>" and we
can work out what that looks like to cover exactly what we need to model.
That way we can model slight behaviour changes more easily.
[Bug middle-end/108459] [OpenMP] ICE during GIMPLE pass: ompexp (segfault) in expand_omp_for_init_counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108459 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:46644ec99cb355845b23bb1d02775c057ed8ee88 commit r13-5262-g46644ec99cb355845b23bb1d02775c057ed8ee88 Author: Jakub Jelinek Date: Thu Jan 19 21:00:08 2023 +0100 openmp: Fix up OpenMP expansion of non-rectangular loops [PR108459] expand_omp_for_init_counts was using for the case where collapse(2) inner loop has init expression dependent on non-constant multiple of the outer iterator and the condition upper bound expression doesn't depend on the outer iterator fold_unary (NEGATE_EXPR, ...). This will just return NULL if it can't be folded, we need fold_build1 instead. 2023-01-19 Jakub Jelinek PR middle-end/108459 * omp-expand.cc (expand_omp_for_init_counts): Use fold_build1 rather than fold_unary for NEGATE_EXPR. * testsuite/libgomp.c/pr108459.c: New test.
[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447 --- Comment #18 from Andrew Macleod --- Created attachment 54312 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54312&action=edit possible patch The only place I think it matters is in set_one_relation. THis is the central point where we add a new relation, and search for any relations leading to this point. If we find one, then we perform an intersection and register the result. If we also check for floating point operands, and see a LT, LE, GT, or GE involved in the intersection, and the result is EQ or NE, this patch simply doesn't register the new relation so combining <= and >= will simply leave the relation as <= instead of producing == Its not incorrect, just not exact.. but we have no way of representing the exact result yet. I think this is the only place we really use intersection, and the oracle does not use union for anything. We never merge incoming results that way.. we simply search the dominators rather than create new relations for merge points. THis probably needs to be checked in the path oracle too.. I dont think there are any other combinations of relations that will cause a problem?
[Bug middle-end/108459] [OpenMP] ICE during GIMPLE pass: ompexp (segfault) in expand_omp_for_init_counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108459 --- Comment #7 from Jakub Jelinek --- Fixed on the trunk, will backport later.
[Bug ipa/108470] New: Missing documentation for alternate uses of __attribute__((noinline))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108470 Bug ID: 108470 Summary: Missing documentation for alternate uses of __attribute__((noinline)) Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: rth at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- The noinline attribute affects decisions made by ipa-split.cc and ipa-icf.cc that are not immediately obvious. At least the ipa-split choice affects code correctness for QEMU (in that we expect __builtin_return_address to be used in very specific contexts, and the transformation done by ipa-split invalidates that). Using noinline on the affected functions prevents the ipa-split optimization and restores functionality. It would be nice to document the effect, so that the workaround is not affected in future gcc versions.
