[Bug tree-optimization/104214] [12 regression] gcc.dg/vect/pr81196.c fails after r12-6844
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104214 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |12.0 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-01-25 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Also visible on x86_64 with -mavx2.
[Bug tree-optimization/104215] bogus -Wuse-after-free=3 due to forwprop moving a pointer test after realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104215
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #1 from Richard Biener ---
A use of the pointer value (not dereferencing it) after releasing the storage
it points to is perfectly valid, so I don't see how that could be considered an
error. Esp. for equality compares which can compare pointers to distinct
objects. Esp. also because 'q' may be equal to 'r', so
void *r = __builtin_realloc (q, 7);
if (r == q)
{
...
}
would also be diagnosed? IMHO -Wuse-after-free needs to be fixed here.
[Bug libstdc++/104217] [12 Regression] gcc-12-20220123 failure to build on Cygwin due to lack of secure_getenv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104217 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #7 from Richard Biener --- what Andrew said - either libstdc++ should provide a prototype or check for one.
[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342 --- Comment #8 from martin --- Seems to work fine with current master. Not even valgrind complains.
[Bug fortran/103039] Segfault with openmp block within a select type block since r12-1016-g0e3b3b77e13cac76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039 --- Comment #4 from martin --- Is there any chance of fixing this regression (in particular the associate block variant) till gfortran-12 release? Having an openmp block within an associate block should not be that uncommon in modern code, right?
[Bug fortran/87448] ICE at trans-expr:3417 in allocate statement with type signature using an associated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87448 --- Comment #3 from martin --- With gfortran-12, the ICE is gone, but the produced error message does not look right. mod.f90:12:25: 12 |associate(l => len(cs)) | 1 Error: Symbol ‘l’ at (1) has no IMPLICIT type
[Bug rtl-optimization/104209] [9/10/11/12 Regression] gcc.dg/torture/pr20314-2.c ICE with -m32 -fPIC in lra_split_hard_reg_for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104209 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- I think it started with r5-4065-gbcb21886b9ea0c38.
[Bug fortran/104210] [11/12 Regression] ICE in gfc_zero_size_array, at fortran/arith.cc:1685 since r11-1814-gcc9a9229285a26ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104210 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Summary|[11/12 Regression] ICE in |[11/12 Regression] ICE in |gfc_zero_size_array, at |gfc_zero_size_array, at |fortran/arith.cc:1685 |fortran/arith.cc:1685 since ||r11-1814-gcc9a9229285a26ac Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-25 CC||marxin at gcc dot gnu.org, ||tkoenig at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r11-1814-gcc9a9229285a26ac.
[Bug tree-optimization/104214] [12 regression] gcc.dg/vect/pr81196.c fails after r12-6844
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104214 --- Comment #2 from Richard Biener --- So PR81196 is exactly the bug the code in niter analysis was added for. We have for (;p
[Bug fortran/100961] Intrinsic function as value to a class(*) assumed rank argument fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100961 --- Comment #4 from martin --- In contrast to gfortran-11, with current master I do not see any errors or segfaults (not even with valgrind) anymore. Seems to have been fixed.
[Bug target/104219] New: riscv64-elf cross compiler build fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104219 Bug ID: 104219 Summary: riscv64-elf cross compiler build fails Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: kito at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux-gnu [ 20s] + ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c --enable-checking=release --disable-werror --with-gxx-include-dir=/usr/include/c++/12 --enable-ssp --disable-libssp --disable-libvtv --enable-cet=auto --disable-libcc1 --disable-plugin --with-bugurl=https://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux' --with-slibdir=/usr/riscv64-suse-linux/sys-root/lib64 --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-12 --program-prefix=riscv64-elf- --target=riscv64-elf --disable-nls --with-sysroot=/usr/riscv64-suse-linux/sys-root --with-build-sysroot=/usr/riscv64-suse-linux/sys-root --with-build-time-tools=/usr/riscv64-suse-linux/bin --with-newlib --disable-gcov --disable-multilib --disable-libsanitizer --build=x86_64-suse-linux --host=x86_64-suse-linux fails due to: [ 204s] checking for suffix of object files... configure: error: in `/home/abuild/rpmbuild/BUILD/gcc-12.0.1+git191254/obj-x86_64-suse-linux/riscv64-elf/libgcc': [ 204s] configure: error: cannot compute suffix of object files: cannot compile [ 204s] See `config.log' for more details Assembler messages: Error: cannot find default versions of the ISA extension `zicsr' configure:3808: $? = 1 configure: failed program was: for: as --version GNU assembler (GNU Binutils; openSUSE Tumbleweed) 2.37.2022-5 Likely started with g:ca2bbb88f999f4d3cc40e89bc1aba712505dd598.
[Bug target/104219] riscv64-elf cross compiler build fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104219 Andrew Pinski changed: What|Removed |Added Keywords||build, documentation --- Comment #1 from Andrew Pinski --- My bet is just the documentation needs ro be updated for a newer binutils version. Riscv is still too new really.
[Bug tree-optimization/102583] [x86] Failure to optimize 32-byte integer vector conversion to 16-byte float vector properly when converting upper part with -mavx2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102583
--- Comment #3 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #2)
> Simplify
> _4 = VEC_PERM_EXPR <_1, _1, { 4, 5, 6, 7, 4, 5, 6, 7 }>;
> _5 = BIT_FIELD_REF <_4, 128, 0>;
>
> to
>
> _5 = BIT_FIELD_REF <_1, 128, 128>;
>
> in match.pd?
maybe forwprop this
15 _1 = *srcp_7(D);
16 _2 = BIT_FIELD_REF <_1, 32, 128>;
17 _3 = BIT_FIELD_REF <_1, 32, 160>;
18 _4 = BIT_FIELD_REF <_1, 32, 192>;
19 _5 = BIT_FIELD_REF <_1, 32, 224>;
20 b_9 = {_2, _3, _4, _5};
directly into
b_9 = BIT_FIELD_REF <*srcp_7, 128, 128>;
[Bug fortran/103039] [12 Regression] Segfault with openmp block within a select type block since r12-1016-g0e3b3b77e13cac76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039 Jakub Jelinek changed: What|Removed |Added Summary|Segfault with openmp block |[12 Regression] Segfault |within a select type block |with openmp block within a |since |select type block since |r12-1016-g0e3b3b77e13cac76 |r12-1016-g0e3b3b77e13cac76 Target Milestone|--- |12.0
[Bug fortran/104220] New: [12 Regression] Build fail: libgfortran/ieee/issignaling_fallback.h:140:21: error: token "=" is not valid in preprocessor expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104220 Bug ID: 104220 Summary: [12 Regression] Build fail: libgfortran/ieee/issignaling_fallback.h:140:21: error: token "=" is not valid in preprocessor expressions Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: fxcoudert at gcc dot gnu.org Target Milestone: --- Target: powerpc64le-linux-gnu Build: powerpc64le-linux-gnu powerpc64le-linux-gnu now fails as follows, it did build yesterday. Namely: gcc-mainline/libgfortran/ieee/issignaling_fallback.h:140:21: error: token "=" is not valid in preprocessor expressions 140 | #elif (__LDBL_DIG__ = 33) && __LDBL_IS_IEC_60559__ | ^ gcc-mainline/libgfortran/ieee/issignaling_fallback.h: In function '__issignalingl': gcc-mainline/libgfortran/ieee/issignaling_fallback.h:177:29: warning: unused parameter 'x' [-Wunused-parameter] 177 | __issignalingl (long double x) | ^ Makefile:7313: recipe for target 'ieee_helper.lo' failed make[3]: *** [ieee_helper.lo] Error 1 Probable caused by the commit: commit e89d0befe3ec3238fca6de2cb078eb403b8c7e99 Author: Francois-Xavier Coudert AuthorDate: Mon Jan 17 12:46:48 2022 +0100 CommitDate: Mon Jan 24 23:16:16 2022 +0100 Fortran: provide a fallback implementation of issignaling For targets with IEEE support but without the issignaling macro in libc (currently, everywhere except glibc), this allows us to provide a fallback implementation. In order to keep the code in ieee_helper.c relatively readable, I've put that new implementation in a separate file, issignaling_fallback.h. libgfortran/ChangeLog: * ieee/issignaling_fallback.h: New file. * ieee/ieee_helper.c: Include issignaling_fallback.h when target does not define issignaling macro. gcc/testsuite/ChangeLog: * gfortran.dg/ieee/signaling_1.f90: Do not require issignaling. * gfortran.dg/ieee/signaling_2.f90: Add comment. * gfortran.dg/ieee/signaling_3.f90: New test.
[Bug fortran/104220] [12 Regression] Build fail: libgfortran/ieee/issignaling_fallback.h:140:21: error: token "=" is not valid in preprocessor expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104220 --- Comment #1 from Tobias Burnus --- Testing now: --- a/libgfortran/ieee/issignaling_fallback.h +++ b/libgfortran/ieee/issignaling_fallback.h @@ -140 +140 @@ __issignalingl (long double x) -#elif (__LDBL_DIG__ = 33) && __LDBL_IS_IEC_60559__ +#elif (__LDBL_DIG__ == 33) && __LDBL_IS_IEC_60559__
[Bug libstdc++/104217] [12 Regression] gcc-12-20220123 failure to build on Cygwin due to lack of secure_getenv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104217 --- Comment #8 from Jonathan Wakely --- It does check for it
[Bug regression/103997] [12 Regression] gcc.target/i386/pr88531-??.c scan-assembler-times FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997 --- Comment #12 from avieira at gcc dot gnu.org --- Right and did you happen to see a perf increase on these benchmarks with any of the patches I mentioned the hash of in the previous comment? Just to explain a bit further what I think is going on. Before my initial patches the epilogue loop analysis would start at the mode_i + 1 of the first loop, in other others, the next mode in the list of modes. After the patch (1) we started this from mode_i = 1, so the first mode after VOIDmode, this caused some ICEs if the target didn't add any, not sure about your targets, but that was fixed in (2). In patch (3) Kewen added a fix to my check for potential use of partial vectors, to check the param_vect_partial_vector_usage since that can disable partial vector even if the target supports them. So I suspect that either of these 3 patches inadvertently changed the vectorization strategy for the epilogue of some loop(s) in these benchmarks. So when I commited patch (4) f4ca0a53be18dfc7162fd5dcc1e73c4203805e14, the vectorization strategy went back to what it was previously. If this is indeed what happened then the regression you are seeing is just an indication that the original vectorization strategy was sub-optimal. This is something that should be looked at in separate and looked at as an optimization, probably by improving the cost modelling of the vectorizer for your target. Patch 1) commit d3ff7420e941931d32ce2e332e7968fe67ba20af Author: Andre Vieira Date: Thu Dec 2 14:34:15 2021 + [vect] Re-analyze all modes for epilogues Patch 2) commit 016bd7523131b645bca5b5530c81ab5149922743 Author: Andre Vieira Date: Tue Jan 11 15:52:59 2022 + [vect] PR103971, PR103977: Fix epilogue mode selection for autodetect only Patch 3) commit 6d51a9c6447bace21f860e70aed13c6cd90971bd Author: Kewen Lin Date: Fri Jan 14 07:02:10 2022 -0600 vect: Check partial vector param for supports_partial_vectors [PR104015] Patch 4) commit f4ca0a53be18dfc7162fd5dcc1e73c4203805e14 Author: Andre Vieira Date: Wed Jan 19 14:11:32 2022 + vect: Fix epilogue mode skipping
[Bug libstdc++/104217] [12 Regression] gcc-12-20220123 failure to build on Cygwin due to lack of secure_getenv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104217 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-01-25 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #9 from Jonathan Wakely --- Oh, I see... Autoconf doesn't work as it should. Sigh.
[Bug tree-optimization/104214] [12 regression] gcc.dg/vect/pr81196.c fails after r12-6844
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104214 --- Comment #3 from Richard Biener --- So it looks like we registered q_4(D) != 2147483647 && p_3(D) != -2147483648 as assumptions as we set no_overflow to false before using (delta + step - 1) / step for niter in number_of_iterations_lt. So for the fixed cases it seems that some earlier transforms use the adjusted IVs under wrong assumptions. A way out would be to register the no overflow assumptions earlier. Oh, and for pointers we kept the no overflow guarantee, making the relational compare transform always valid - possibly because of reasoning that relational compares in C invoke undefined behavior when they compare two distinct objects and object addresses not wrapping around (ignoring maybe the special case of one-after-the-object being wrapped). So the testcase which uses pointers can possibly be fixed by re-instantiating that. As said, further improvements might involve doing sth like registering assumptions earlier and to make that possible for LE also, turn LE to LT earlier as well.
[Bug tree-optimization/104214] [12 regression] gcc.dg/vect/pr81196.c fails after r12-6844
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104214 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Blocks||100740 Keywords||missed-optimization Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100740 [Bug 100740] [9/10/11 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r9-4145-ga81e2c6240655f60
[Bug sanitizer/101476] AddressSanitizer check failed, points out a (potentially) non-existing stack error and pthread_cancel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476 --- Comment #13 from Stas Sergeev --- Found another problem. https://github.com/gcc-mirror/gcc/blob/master/libsanitizer/asan/asan_posix.cpp#L53 The comment above that line talks about SS_AUTODISARM, but the line itself does not account for any flags. In a mean time, linux returns SS_DISABLE in combination with flags, like SS_AUTODISARM. So the "!=" check should not be used. My app probes for SS_AUTODISARM by trying to set it, and after that, asan breaks. This is quite cludgy though. Should the check be changed to if (!(signal_stack.ss_flags & SS_DISABLE)) or maybe linux should not return any flags together with SS_DISABLE? man page talks "strange things" on that subject.
[Bug fortran/104220] [12 Regression] Build fail: libgfortran/ieee/issignaling_fallback.h:140:21: error: token "=" is not valid in preprocessor expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104220 Francois-Xavier Coudert changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-01-25 Status|UNCONFIRMED |NEW --- Comment #2 from Francois-Xavier Coudert --- Pushed: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0d56eb93aa6e58328fbf679a4839bfaef5c05f5c
[Bug target/99932] OpenACC/nvptx offloading execution regressions starting with CUDA 11.2-era Nvidia Driver 460.27.04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932
--- Comment #11 from Tom de Vries ---
(In reply to Tom de Vries from comment #10)
> Rerunning the entire testsuite though shows that the non-32-vector-length
> test-cases are still failing.
Minimal example:
...
int
main (void)
{
#pragma acc parallel num_workers (2) vector_length (64)
{
#pragma acc loop worker
for (unsigned int i = 0; i < 2; i++)
#pragma acc loop vector
for (unsigned int j = 0; j < 64; j++)
;
}
return 0;
}
...
[Bug tree-optimization/104214] [12 regression] gcc.dg/vect/pr81196.c fails after r12-6844
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104214
--- Comment #4 from Richard Biener ---
variant testcase that was vectorized before but is not now where we cannot use
simple pointer relational compare reasoning:
int a[1024];
void __attribute__((noipa))
foo (int p, int q)
{
int i = 0;
for (; p < q; ++p, --q)
a[i++] = 1;
}
int main()
{
foo (__INT_MAX__ - 1, __INT_MAX__);
if (a[0] != 1 || a[1] != 0)
__builtin_abort ();
return 0;
}
[Bug target/99932] OpenACC/nvptx offloading execution regressions starting with CUDA 11.2-era Nvidia Driver 460.27.04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932 --- Comment #12 from Tom de Vries --- Created attachment 52285 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52285&action=edit Cuda reproducer non-32 vector length [ On T400, driver version 470.94 ] NVCC SASS: ... $ ./do.sh NVCC SASS, ptxas=-O0: + /home/vries/cuda/11.5.1/bin/nvcc vector-length-64.cu -arch=compute_75 -code=sm_75 -Xptxas -O0 + ./a.out NVCC SASS, ptxas=-O1: + /home/vries/cuda/11.5.1/bin/nvcc vector-length-64.cu -arch=compute_75 -code=sm_75 -Xptxas -O1 + ./a.out ... Driver SASS: ... $ ./do.sh DRIVER SASS, ptxas=-O0: + /home/vries/cuda/11.4.3/bin/nvcc vector-length-64.cu -arch=compute_75 -Xptxas -O0 + ./a.out DRIVER SASS, ptxas=-O1: + /home/vries/cuda/11.4.3/bin/nvcc vector-length-64.cu -arch=compute_75 -Xptxas -O1 + ./a.out ...
[Bug regression/103997] [12 Regression] gcc.target/i386/pr88531-??.c scan-assembler-times FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Richard Biener --- The change will basically re-enable epilogue vectorization which was disabled before on accident. At least for exchange I know it will not benefit from that because of low iteration counts that are not statically known. So the result was to be expected. Btw, this bug is now fixed.
[Bug tree-optimization/103998] [12 Regression] Recent vectorizer testsuite regressions on x86 since r12-6420 and r12-6523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103998 Bug 103998 depends on bug 103997, which changed state. Bug 103997 Summary: [12 Regression] gcc.target/i386/pr88531-??.c scan-assembler-times FAILs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/104058] [12 Regression] 6-7% x264_r regression with -march=native -Ofast -funroll-loops -flto on x86 since r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104058 Bug 104058 depends on bug 103997, which changed state. Bug 103997 Summary: [12 Regression] gcc.target/i386/pr88531-??.c scan-assembler-times FAILs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/104220] [12 Regression] Build fail: libgfortran/ieee/issignaling_fallback.h:140:21: error: token "=" is not valid in preprocessor expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104220 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |12.0 --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/103998] [12 Regression] Recent vectorizer testsuite regressions on x86 since r12-6420 and r12-6523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103998 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- I believe all are fixed now.
[Bug libgcc/104207] [12 Regression] Crash in _Unwind_Find_FDE if object lacks unwind information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104207 --- Comment #2 from Florian Weimer --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589177.html
[Bug libgcc/104207] [12 Regression] Crash in _Unwind_Find_FDE if object lacks unwind information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104207 --- Comment #3 from CVS Commits --- The master branch has been updated by Florian Weimer : https://gcc.gnu.org/g:ab2a2457780d224343ce05e7d8e2964c6a47fd83 commit r12-6857-gab2a2457780d224343ce05e7d8e2964c6a47fd83 Author: Florian Weimer Date: Tue Jan 25 12:09:56 2022 +0100 libgcc: Fix _Unwind_Find_FDE for missing unwind data with glibc 2.35 _dl_find_object returns success even if no unwind information has been found, and dlfo_eh_frame is NULL. libgcc/ChangeLog: PR libgcc/104207 * unwind-dw2-fde-dip.c (_Unwind_Find_FDE): Add NULL check.
[Bug libgcc/104207] [12 Regression] Crash in _Unwind_Find_FDE if object lacks unwind information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104207 Florian Weimer changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Florian Weimer --- Fixed.
[Bug c++/104221] New: member functions defined in separate files of classes declared in module partitions won't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104221
Bug ID: 104221
Summary: member functions defined in separate files of classes
declared in module partitions won't compile
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: f.b.brokken at rug dot nl
Target Milestone: ---
The following source file (full.cc) compiles OK:
-
export module mod:partition;
export class Data
{
int d_value = 10;
public:
int value() const;
};
int Data::value() const
{
return d_value;
}
void fun();
-
The function fun() can be implemented in a separate file, and also compiles OK
(fun.cc):
-
module;
#include
module mod:partition;
using namespace std;
void fun()
{
cout << "hi\n";
}
-
When implementing int Data::value() const in a separate file a compilation
error results.
Here's the modified module interface file (partition.cc):
-
export module mod:partition;
export class Data
{
int d_value = 10;
public:
int value() const;
};
void fun();
-
and the source defining int Data::value() (value.cc):
module mod:partition;
int Data::value() const
{
return d_value;
}
The function void fun() compiles OK.
When compiling
g++ --std=c++20 -Wall -Wextra -fno-strict-aliasing -fwrapv -c -fmodules-ts \
partition.cc fun.cc value.cc
using g++-12 on an updated Debian linux system
(g++ (Debian 12-20211217-1) 12.0.0 20211217 (experimental) [master
r12-6027-g774269aa4b9] the compiler reports:
--
value.cc:3:5: error: ‘Data’ has not been declared
3 | int Data::value() const
| ^~~~
value.cc:3:19: error: non-member function ‘int value()’ cannot have
cv-qualifier
3 | int Data::value() const
| ^
value.cc: In function ‘int value()’:
value.cc:5:12: error: ‘d_value’ was not declared in this scope; did you mean
‘value’?
5 | return d_value;
|^~~
|value
value.cc: At global scope:
value.cc:1:1: warning: not writing module ‘mod:partition’ due to errors
1 | module mod:partition;
| ^~
--
If any additional information is required, please let me know.
Kind regards,
Frank.
[Bug tree-optimization/104214] [12 regression] gcc.dg/vect/pr81196.c fails after r12-6844
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104214 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:2e211a02290f3b3533b56c593fc7b95edb8593b0 commit r12-6858-g2e211a02290f3b3533b56c593fc7b95edb8593b0 Author: Richard Biener Date: Tue Jan 25 11:55:28 2022 +0100 tree-optimization/104214 - amend PR100740 fix for pointer compares When we have a pointer relational compare we have stronger guarantees about overflow, in particular rewriting BASE0 + STEP0 cmp BASE1 + STEP1 as BASE0 + STEP0 - STEP1 cmp BASE1 is always valid and the new IV0 does not overflow. The patch basically reverts the previous change when pointers are involved, keeping only the more conservative handling for equality compares which can involve comparing different object addresses. 2022-01-25 Richard Biener PR tree-optimization/104214 * tree-ssa-loop-niter.cc (number_of_iterations_cond): Use stronger guarantees for relational pointer compares when rewriting BASE0 + STEP0 cmp BASE1 + STEP1 as BASE0 + STEP0 - STEP1 cmp BASE1. * gcc.dg/vect/pr81196-2.c: New variant testcase only requiring vect_int.
[Bug sanitizer/101476] AddressSanitizer check failed, points out a (potentially) non-existing stack error and pthread_cancel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476 --- Comment #14 from Martin Liška --- (In reply to Stas Sergeev from comment #13) > Found another problem. > https://github.com/gcc-mirror/gcc/blob/master/libsanitizer/asan/asan_posix. > cpp#L53 > The comment above that line talks about > SS_AUTODISARM, but the line itself does > not account for any flags. In a mean time, > linux returns SS_DISABLE in combination > with flags, like SS_AUTODISARM. So the > "!=" check should not be used. > > My app probes for SS_AUTODISARM by trying > to set it, and after that, asan breaks. > This is quite cludgy though. > Should the check be changed to > if (!(signal_stack.ss_flags & SS_DISABLE)) > or maybe linux should not return any flags > together with SS_DISABLE? > man page talks "strange things" on that subject. Please report to upstream as well.
[Bug sanitizer/101476] AddressSanitizer check failed, points out a (potentially) non-existing stack error and pthread_cancel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476 --- Comment #15 from Stas Sergeev --- (In reply to Martin Liška from comment #14) > Please report to upstream as well. I'd like some guidance on how should that be addressed, because that will allow to specify the upstream. I am not entirely sure that linux is doing the right thing, and I am not sure man page even makes sense saying that: --- The old_ss.ss_flags may return either of the following values: SS_ONSTACK SS_DISABLE SS_AUTODISARM --- ... because what I see is the return of "SS_DISABLE|SS_AUTODISARM", which is what I write to flags for probing. This is cludgy. Does anyone know what fix should that get?
[Bug libstdc++/104222] New: std::basic_string::resize_and_overwrite passes an unexpected value to user's callable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104222
Bug ID: 104222
Summary: std::basic_string::resize_and_overwrite passes an
unexpected value to user's callable
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: space.mission at yandex dot ru
Target Milestone: ---
TOPIC:
A bug in std::basic_string::resize_and_overwrite, N4901 / P1072R10.
DESCRIPTION:
A value `n` passed to std::basic_string::resize_and_overwrite(n, op) MAY
NOT be equal (in some circumstances) to the value passed to the user's callable
`op`, despite what is implied in [string.capacity] N4901, p.785.
EXPECTED BEHAVIOR:
A value `n` passed to std::basic_string::resize_and_overwrite(n, op) shall
ALWAYS be equal to the value passed to the user's callable `op`.
COMPILER VERSION:
"x86-64 gcc (trunk) - now is 12.0.1" on godbolt.org
HOW to reproduce: [https://godbolt.org/z/j9K6zYq83]
g++ -std=c++2b (... other options are irrelevant)
#include
#include
int main() {
std::string s(30, '_');
s.resize_and_overwrite(40, [](char*, int n) {
// assert( n == 60 ); // Passes, but should not!
assert( n == 40 ); // Fails, but should not!!
return n;
});
}
Prints: /example.cpp:7: main()::: Assertion `n == 40'
failed.
NOTE:
libc++ passes the assertion `assert( n == 40 )' in the code snippet above
if executed as "clang++ -std=c++2b -stdlib=libc++". See
[https://godbolt.org/z/1YET3csh4].
NOTE:
Existing tests in
[libstdc++-v3/testsuite/21_strings/basic_string/capacity/char/resize_and_overwrite.cc],
e.g. test01(), test03() do NOT catch this bug because the condition for it to
happen is not met.
DETAILS:
If the value `n` passed to s.resize_and_overwrite(n, op) is such that the
inequality `s.capacity() < n < 2 * s.capacity()` holds, the value __n that is
passed to user's _Operation op(char*, __n) NOT equals to `n`, but equals to the
new capacity (after extension of the internal string's buffer to that new
capacity).
ANALYSIS:
See _M_create(size_type&, size_type): the first param is ref (in-out) for a
new capacity. The call to it in "basic_string.tcc" is: _M_create(__n,
__capacity). This call modifies the __n, IFF __capacity < __n < 2 * __capacity.
Otherwise __n stays unmodified (it is still used as a parameter for the new
capacity, but in such case the new capacity becomes equal to __n) and the
problem does not occur.
FIXING PATCH:
Just add an additional variable (e.g. __new_capacity) to prevent changing
the __n by _M_create) in
[https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/include/bits/basic_string.tcc]
Relative to
[https://github.com/gcc-mirror/gcc/blob/0d56eb93aa6e58328fbf679a4839bfaef5c05f5c/libstdc%2B%2B-v3/include/bits/basic_string.tcc#L565]:
...
resize_and_overwrite(size_type __n, _Operation __op)
{
const size_type __capacity = capacity();
_CharT* __p;
if (__n > __capacity)
{
-- __p = _M_create(__n, __capacity);
++ auto __new_capacity = __n;
++ __p = _M_create(__new_capacity, __capacity);
this->_S_copy(__p, _M_data(), length()); // exclude trailing
null
#if __cpp_lib_is_constant_evaluated
if (std::is_constant_evaluated())
traits_type::assign(__p + length(), __n - length(),
_CharT());
#endif
_M_dispose();
_M_data(__p);
-- _M_capacity(__n);
++ _M_capacity(__new_capacity);
}
...
NEW TEST:
for
[https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/testsuite/21_strings/basic_string/capacity/char/resize_and_overwrite.cc]
// To catch the bug the value n ("resize to <= n") should satisfy:
// current_capacity < n < 2*current_capacity,
std::string s(30, '_'); // size == capacity == 30
s.resize_and_overwrite(40, [](char*, int n) { // resize to <= 40
VERIFY( n == 40 );// capacity now == 2*30
return n;
});
REFERENCES:
[http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1072r10.html]
P1072R10 - basic_string::resize_and_overwrite
[Bug libstdc++/104222] std::basic_string::resize_and_overwrite passes an unexpected value to user's callable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104222 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2022-01-25 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- IIRC I did this intentionally, to allow the callback to use the true capacity. But I agree it's non-conforming.
[Bug target/104219] riscv64-elf cross compiler build fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104219 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-01-25 Ever confirmed|0 |1 --- Comment #2 from Kito Cheng --- That's definitely cause by the ISA spec bumping, I tested with binutils trunk but didn't test with 2.37. Let me fix that to make sure GCC work with older binutils release.
[Bug fortran/104220] [12 Regression] Build fail: libgfortran/ieee/issignaling_fallback.h:140:21: error: token "=" is not valid in preprocessor expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104220 --- Comment #4 from Tobias Burnus --- Compiles now but all three testcase fail at execution time with: (1) gfortran.dg/ieee/signaling_1.f90 (+ exit code 44): Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG STOP 300 (2) gfortran.dg/ieee/signaling_2.f90 (+ exit code 100) and (3) gfortran.dg/ieee/signaling_3.f90 (+ exit code 100): Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG STOP 100
[Bug rtl-optimization/104198] [12 regression] ifcvf change breaks 64-bit SPARC bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104198 --- Comment #9 from rdapp at linux dot ibm.com --- I believe I know what's happening and it's indeed something that could also happen on other targets. I did not anticipate backends re-creating the initial condition for the case when we pass it a cc comparison. The SPARC backend does this, using a (now) already overwritten value for comparison. Other targets could also do this but maybe do not currently but it would always lead to wrong code. Not yet sure about a proper solution. Since we go over the insns twice anyway we could check the created sequences for overlap with the condition again and mark them. In the second iteration we would make sure to not overwrite the condition unless there is no insn later that uses it. Hope to come up with something testable by today.
[Bug target/104219] riscv64-elf cross compiler build fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104219 --- Comment #3 from Kito Cheng --- Patch posted to mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589225.html
[Bug libstdc++/104223] New: GCC unable to inline trivial functions passed to views::filter and transform unless lifted into types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104223
Bug ID: 104223
Summary: GCC unable to inline trivial functions passed to
views::filter and transform unless lifted into types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
I'm not sure if this is an issue with the optimizer or the way that the library
code is written, or some combination of the two, but the end result seems
unfortunate. with() and without() are logically the same function, the only
difference is that with() lifts the function pointers into types using a
templated lambda variable, while without() just passes the function names
directly to the library. It seems interesting that the optimizer knows that
they are "constant enough" to emit direct rather than indirect calls to t() and
f(), however, it isn't constant enough to inline those calls.
https://godbolt.org/z/EqWzzh916
Flags: -std=c++2b -O3
Reproduces on at least 11.2 and trunk
#include
namespace views = std::views;
void trace() noexcept;
inline int f(int i) {
trace();
return i;
}
inline bool t(int) { return true; }
// for some reason gcc needs this in order to inline f() and t()
template
auto typify = [] (int i) { return f(i); };
void with() {
for (auto&& x : views::single(1) | views::transform(typify) |
views::filter(typify)) {}
}
void without() {
for (auto&& x : views::single(1) | views::transform(f) | views::filter(t))
{}
}
with():
sub rsp, 8
calltrace()
add rsp, 8
jmp trace()
without():
sub rsp, 8
mov edi, 1
callf(int)
mov edi, eax
callt(int)
testal, al
jne .L10
add rsp, 8
ret
.L10:
mov edi, 1
add rsp, 8
jmp f(int)
[Bug fortran/104220] [12 Regression] Build fail: libgfortran/ieee/issignaling_fallback.h:140:21: error: token "=" is not valid in preprocessor expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104220 Francois-Xavier Coudert changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|NEW --- Comment #5 from Francois-Xavier Coudert --- Is this a "double double" long double? If so, is it fixed by the patch at https://gcc.gnu.org/pipermail/fortran/2022-January/057454.html ?
[Bug testsuite/70230] 11 test regressions when building GCC 6 with --enable-default-ssp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70230 Allan McRae changed: What|Removed |Added CC||allan at archlinux dot org --- Comment #5 from Allan McRae --- Created attachment 52286 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52286&action=edit Fix testsuite issues with --enable-default-ssp Add -fno-stack-protector to dg-options where needed. Fixes the following testsuite failures from adding --enable-default-ssp to configure: FAIL: gcc.dg/asan/use-after-scope-4.c -O0 execution test FAIL: gcc.dg/stack-usage-1.c scan-stack-usage foo\\t(256|264)\\tstatic FAIL: gcc.dg/superblock.c scan-rtl-dump-times sched2 "ADVANCING TO" 2 FAIL: gcc.target/i386/avx-vzeroupper-17.c scan-assembler-times avx_vzeroupper 1 FAIL: gcc.target/i386/cleanup-1.c execution test FAIL: gcc.target/i386/cleanup-2.c execution test FAIL: gcc.target/i386/interrupt-redzone-1.c scan-assembler-not \\tcld FAIL: gcc.target/i386/interrupt-redzone-2.c scan-assembler-not \\tcld FAIL: gcc.target/i386/pr79793-1.c scan-assembler-times add[lq][\\t ]*\$400,[\\t ]*%[re]sp 1 FAIL: gcc.target/i386/pr79793-1.c scan-assembler-times fxsave64[\\t ]*-120(%[re]sp) 1 FAIL: gcc.target/i386/pr79793-1.c scan-assembler-times sub[lq][\\t ]*\$400,[\\t ]*%[re]sp 1 FAIL: gcc.target/i386/pr79793-2.c scan-assembler-times add[lq][\\t ]*\$400,[\\t ]*%[re]sp 1 FAIL: gcc.target/i386/pr79793-2.c scan-assembler-times fxsave64[\\t ]*-120(%[re]sp) 1 FAIL: gcc.target/i386/pr79793-2.c scan-assembler-times sub[lq][\\t ]*\$392,[\\t ]*%[re]sp 1 FAIL: gcc.target/i386/shrink_wrap_1.c scan-rtl-dump pro_and_epilogue "Performing shrink-wrapping" FAIL: gcc.target/i386/stack-check-11.c scan-assembler-times or[ql] 3 FAIL: gcc.target/i386/stack-check-11.c scan-assembler-times sub[ql] 4 FAIL: gcc.target/i386/stack-check-18.c scan-assembler-times or[ql] 1 FAIL: gcc.target/i386/stack-check-19.c scan-assembler-times (?:je|jne) 3 FAIL: gcc.target/i386/stack-check-19.c scan-assembler-times or[ql] 2 FAIL: gcc.target/i386/sw-1.c scan-rtl-dump pro_and_epilogue "Performing shrink-wrapping" FAIL: gcc.target/i386/stackalign/pr88483-1.c -mno-stackrealign scan-assembler-not (sub|add)(l|q)[t ]*\$[0-9]*,[t ]*%[re]?sp FAIL: gcc.target/i386/stackalign/pr88483-1.c -mno-stackrealign scan-assembler-not and[lq]?[^n]*-[0-9]+,[^n]*sp FAIL: gcc.target/i386/stackalign/pr88483-1.c -mstackrealign scan-assembler-not (sub|add)(l|q)[t ]*\$[0-9]*,[t ]*%[re]?sp FAIL: gcc.target/i386/stackalign/pr88483-1.c -mstackrealign scan-assembler-not and[lq]?[^n]*-[0-9]+,[^n]*sp FAIL: gcc.target/i386/stackalign/pr88483-2.c -mno-stackrealign scan-assembler-not and[lq]?[^n]*-[0-9]+,[^n]*sp FAIL: gcc.target/i386/stackalign/pr88483-2.c -mstackrealign scan-assembler-not and[lq]?[^n]*-[0-9]+,[^n]*sp
[Bug rtl-optimization/102478] [9/10 Regression] during RTL pass: ce3: ICE: in gen_reg_rtx, at emit-rtl.c:1167 with -O2 -fno-if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102478 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10 Regression] during |during RTL pass: ce3: ICE: |RTL pass: ce3: ICE: in |in gen_reg_rtx, at |gen_reg_rtx, at |emit-rtl.c:1167 with -O2|emit-rtl.c:1167 with -O2 |-fno-if-conversion |-fno-if-conversion --- Comment #6 from Jakub Jelinek --- Fixed on the trunk and for 11.3+ so far.
[Bug testsuite/70150] Additonal test failures with --enable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150
Allan McRae changed:
What|Removed |Added
CC||allan at archlinux dot org
--- Comment #25 from Allan McRae ---
Created attachment 52287
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52287&action=edit
Fix testsuite issues with --enable-default-pie
The following failure are seen in gcc-11.2 when building with
--enable-default-pie:
FAIL: gcc.target/i386/cet-sjlj-6a.c scan-assembler-times movq\\t.*buf+8 1
FAIL: gcc.target/i386/cet-sjlj-6a.c scan-assembler-times subq\\tbuf+8 1
FAIL: gcc.target/i386/cet-sjlj-6b.c scan-assembler-times movq\\t.*buf+16 1
FAIL: gcc.target/i386/cet-sjlj-6b.c scan-assembler-times subq\\tbuf+16 1
FAIL: gcc.target/i386/fentryname3.c scan-assembler 0x0f, 0x1f, 0x44, 0x00, 0x00
FAIL: gcc.target/i386/pr24414.c (test for excess errors)
FAIL: gcc.target/i386/pr93492-3.c scan-assembler
\\t.cfi_startproc\\n\\tendbr(32|64)\\n.*.LPFE1:\\n\\tnop\\n1:\\tcall\\t__fentry__\\n\\tret\\n
FAIL: gcc.target/i386/pr93492-5.c scan-assembler
\\t.cfi_startproc\\n.*.LPFE1:\\n\\tnop\\n1:\\tcall\\t__fentry__\\n\\tret\\n
FAIL: gcc.target/i386/pr98482-1.c scan-assembler movabsq\\t\$__fentry__,
%r10\\n\\tcall\\t*%r10
Adding -no-pie to dg-options only fixed pr24414.c. For the rest I added a "{
target { ! pie_enabled } }" to the failing tests, which may or may not be the
proper solution...
[Bug target/104172] [9/10/11/12 Regression] ppc64le mangling ICE with -flto -ffat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104172 --- Comment #16 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:79b0091b13eb7dce0294407d9bd78750df10180d commit r11-9510-g79b0091b13eb7dce0294407d9bd78750df10180d Author: Jakub Jelinek Date: Tue Jan 25 05:49:05 2022 +0100 rs6000: Remove GCC 8.1 U10__float128 mangling compatibility [PR104172] In GCC 7.x and earlier, while it had -mabi=ieeelongdouble option, that option was undocumented and unsupported. In GCC 8.1 that option got documented and -mabi=ieeelongdouble long double started to be mangled as U10__float128. In GCC 9 and backported to before 8.2 release, that mangling changed to u9__ieee128 and a support for emitting compatibility mangling aliases have been added. Unfortunately, as mentioned in the PR, those don't really work well in many cases, the free_lang_data pass throws away important trees, so e.g. with -flto -ffat-lto-objects the compiler often ICEs on templates that involve IEEE quad long double arguments etc. because the mangling was done too late (at final time). Furthermore, lto1's mangler is not the C++ mangler, so with -flto it would often emit as "mangled identifiers" something that wasn't a valid assembler identifier, e.g. operator+ etc. While it is possible to do such mangling earlier, e.g. at the same time when the C++ FE emits its mangling aliases and untested proof of concept is in the PR, there seems to be agreement that we shouldn't bother with this ABI compatibility with something that probably nobody really used. GCC 8.2 already uses the new mangling, it was just a few months, but more importantly, libstdc++ support for IEEE quad long double on powerpc64le-linux was only added in GCC 11, and glibc support for that some weeks after 8.2 got released. So, the following patch just drops those aliases. 2022-01-25 Jakub Jelinek PR target/104172 gcc/ * config/rs6000/rs6000-internal.h (rs6000_passes_ieee128): Don't declare. * config/rs6000/rs6000.c (rs6000_passes_ieee128, ieee128_mangling_gcc_8_1): Remove. (TARGET_ASM_GLOBALIZE_DECL_NAME): Don't redefine. (rs6000_mangle_type): Return "u9__ieee128" instead of ieee128_mangling_gcc_8_1 ? "U10__float128" : "u9__ieee128". (rs6000_globalize_decl_name): Remove. * config/rs6000/rs6000-call.c (init_cumulative_args, rs6000_function_arg_advance_1): Don't set rs6000_passes_ieee128. (cherry picked from commit f4ee27d3262fc4fc3e5d3535f195fdcf87d7ec77)
[Bug analyzer/104224] New: Testcases for analyzer "uninit" from fedora-devel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104224
Bug ID: 104224
Summary: Testcases for analyzer "uninit" from fedora-devel
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Steve Grubb posted some test cases for detecting uninit bvehavior to Fedora's
development list here:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/S75EUIQ5Y3MXNXVPFFX4XHE7CW3SKULU/
("Re: Uninitialized variables and F37")
I'm filing this bug as a reminder to add the cases to the regression test
suite, and to fix any false positives/negatives.
[Bug analyzer/104224] Testcases for analyzer "uninit" from fedora-devel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104224 --- Comment #1 from David Malcolm --- gcc trunk with -fanalyzer: https://godbolt.org/z/T17TbqYdx
[Bug fortran/104220] [12 Regression] Build fail: libgfortran/ieee/issignaling_fallback.h:140:21: error: token "=" is not valid in preprocessor expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104220 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Tobias Burnus --- (In reply to Francois-Xavier Coudert from comment #5) > Is this a "double double" long double? If so, is it fixed by the patch at > https://gcc.gnu.org/pipermail/fortran/2022-January/057454.html ? Yes, Jakub's patch does help, i.e. it is fixed by: commit 480caa1f4ab1f138435239d67ffe3126c5e27b2b "libfortran: Provide fallback __issignalingl for IBM extended long double" -> close as FIXED. The only ieee/ testcase that still fails is gfortran.dg/ieee/large_2.f90, but that FAIL is not new -> PR67531
[Bug libstdc++/65343] unexpected exception thrown during destruction of static object in debug mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65343 Marc Poulhiès changed: What|Removed |Added CC||poulhies at adacore dot com --- Comment #3 from Marc Poulhiès --- Hi ! It looks like we are seeing this issue using vxworks7 on gcc-11. The test "/testsuite/21_strings/basic_string/requirements/citerators.cc" has been updated since gcc-10 to use __gnu_debug::string: 8<8<-8<-8<-8<-8<-- commit 50bb46e4d2543f2a78f97feddcde27e42639dae1 Author: François Dumont Date: Fri Mar 5 18:50:22 2021 +0100 libstdc++: Fix and complete __gnu_debug::basic_string implementation 8<8<-8<-8<-8<-8<-- Currently, the mutexes are created when __gnu_internal::get_mutex() is first called, during the construction of " __gnu_test::citerator<__gnu_debug::string> dtest1;" in main(). #0 __gnu_cxx::__mutex::__mutex (this=0x801a80c0 <__gnu_internal::get_mutex(unsigned char)::m>) at ...libstdc++-v3/include/ext/concurrence.h:132 #1 0x80043188 in __gnu_internal::M::M (this=0x801a80c0 <__gnu_internal::get_mutex(unsigned char)::m>) at .../libstdc++-v3/src/c++11/shared_ptr.cc:38 #2 0x80043268 in __gnu_internal::get_mutex (i=5 '\005') at .../libstdc++-v3/src/c++11/shared_ptr.cc:39 ... #14 0x85b8 in main () at .../libstdc++-v3/testsuite/21_strings/basic_string/requirements/citerators.cc:29 On vxworks, __GTHREAD_MUTEX_INIT is not defined, so a destructor is defined for the __mutex object (include/ext/concurrence.h:136) and registered with __cxa_atexit. #0 __cxa_atexit (fn=0x800431ac <__tcf_0(void*)>, data=0x0, dso_handle=0x801a5d40) at cxa_atexit.c:215 #1 0x80043290 in __gnu_internal::get_mutex (i=5 '\005') at .../libstdc++-v3/src/c++11/shared_ptr.cc:39 #2 0x80010710 in (anonymous namespace)::get_safe_base_mutex (address=0x801a7f28 <__gnu_test::citerator<__gnu_debug::basic_string, std::allocator > >::_S_container>) at .../libstdc++-v3/src/c++11/debug.cc:66 Then, when main() returns, these mutexes' destructors are called, which on vxworks call semDestroy() that invalidate the mutexes. #0 __gnu_internal::M::~M (this=0x801a8480 <__gnu_internal::get_mutex(unsigned char)::m+960>, __in_chrg=) at .../libstdc++-v3/src/c++11/shared_ptr.cc:38 #1 0x800431e0 in __tcf_0 () at .../libstdc++-v3/src/c++11/shared_ptr.cc:39 #2 0x800f4ae4 in __cxa_finalize (dso_handle=0x0) at cxa_atexit.c:222 #3 0x800f4cac in __do_atexit_work () at cxa_atexit.c:229 #4 0x800ff274 in exit (status=0) at vxexit.c:49 #5 0x81d8 in _start () A later destructor for the _S_container object then tries to lock the destroyed and now invalid mutexes, leading to an error. #0 __gnu_cxx::__mutex::lock (this=0x801a8200 <__gnu_internal::get_mutex(unsigned char)::m+320>) at .../libstdc++-v3/include/ext/concurrence.h:149 #1 0x8b1c in __gnu_cxx::__scoped_lock::__scoped_lock (this=0x600e68, __name=...) at ...p/libstdc++-v3/include/ext/concurrence.h:241 #2 0x800109c4 in __gnu_debug::_Safe_sequence_base::_M_detach_all (this=0x801a7f28 <__gnu_test::citerator<__gnu_debug::basic_string, std::allocator > >::_S_container>) at .../libstdc++-v3/src/c++11/debug.cc:255 ... #7 0x800f4ae4 in __cxa_finalize (dso_handle=0x0) at cxa_atexit.c:222 #8 0x800f4cac in __do_atexit_work () at cxa_atexit.c:229 #9 0x800ff274 in exit (status=0) at vxexit.c:49 #10 0x81d8 in _start () Forcing a call to get_mutex() earlier during the _Safe_sequence_base ctor forces the mutex destructor to be called in the correct order, but does not seem like a very robust workaround.
[Bug target/99932] OpenACC/nvptx offloading execution regressions starting with CUDA 11.2-era Nvidia Driver 460.27.04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932 --- Comment #13 from Tom de Vries --- (In reply to Tom de Vries from comment #10) > [ FTR, T400, driver 470.94 ] > > Interestingly, changing the default ptx version to 6.3 makes the minimal > test-case pass, as well as the full parallel-dims.c > > The only code changes are shfl -> shfl.sync and vote -> vote.sync. > It seems another change is required. Starting with 6.0, bar.sync maps onto barrier.sync.aligned, where the aligned means that "all threads in CTA will execute the same barrier instruction. In conditionally executed code, an aligned barrier instruction should only be used if it is known that all threads in CTA evaluate the condition identically, otherwise behavior is undefined." It's not fully clear what is meant with "the same barrier instruction" or "condition", but in the case of vector_length > 32, we use: ... bar.sync %r67,64; ... where %r67 is a barrier number, 1 for worker 0 and 2 for worker 1 in case of 2 workers. It may well be that it's invalid to use bar.sync for this, and we should use barrier.sync instead. But then there's an isa note: ... Note: For .target sm_6x or below, 1. barrier instruction without .aligned modifier is equivalent to .aligned variant and has the same restrictions as of .aligned variant. ... which seems to imply that we get back barrier.sync.aligned behaviour for sm_6x and earlier, which would again break vector_length > 32.
[Bug c++/104225] New: accepts-invalid new expression that uses deleted implicit default constructor of class specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104225
Bug ID: 104225
Summary: accepts-invalid new expression that uses deleted
implicit default constructor of class specialization
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
The following testcase compiles without error, but should be rejected because
it uses B's deleted default constructor:
class A { ~A(); };
template class B { A f = 1; };
int main() {
new B;
}
[Bug c++/104225] [9/10/11/12 Regression] accepts-invalid new expression that uses deleted implicit default constructor of class specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104225 Patrick Palka changed: What|Removed |Added Last reconfirmed||2022-01-25 Ever confirmed|0 |1 CC||jason at gcc dot gnu.org Known to work||8.5.0 Summary|accepts-invalid new |[9/10/11/12 Regression] |expression that uses|accepts-invalid new |deleted implicit default|expression that uses |constructor of class|deleted implicit default |specialization |constructor of class ||specialization Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101532 Target Milestone|--- |9.5 Keywords||accepts-invalid Known to fail||10.3.0, 11.2.0, 12.0, 9.4.0 --- Comment #1 from Patrick Palka --- Started with r9-6097.
[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342 sandra at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from sandra at gcc dot gnu.org --- Marking this as fixed.
[Bug middle-end/104226] New: ICE in fold_vec_perm, at fold-const.cc:10483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104226 Bug ID: 104226 Summary: ICE in fold_vec_perm, at fold-const.cc:10483 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: x86_64-unknown-linux-gnu g++ 12.0.0 20220123 snapshot (g:2da90ad39bf8fa9ee287e040d1f4411cb7a2e7ed) ICEs when compiling gcc/testsuite/gcc.target/i386/pr101046.c: % x86_64-unknown-linux-gnu-g++-12.0.1 -c gcc/testsuite/gcc.target/i386/pr101046.c gcc/testsuite/gcc.target/i386/pr101046.c: In function 'U foo()': gcc/testsuite/gcc.target/i386/pr101046.c:14:74: internal compiler error: in fold_vec_perm, at fold-const.cc:10483 14 |5, 5, 0, 2), U); | ^ 0x798fe8 fold_vec_perm(tree_node*, tree_node*, tree_node*, vec_perm_indices const&) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/fold-const.cc:10483 0x18cd579 generic_simplify_VEC_PERM_EXPR /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/build/gcc/generic-match.cc:90825 0xe33f7b fold_ternary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*, tree_node*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/fold-const.cc:12777 0x995083 cxx_eval_trinary_expression /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/cp/constexpr.cc:5472 0x985798 cxx_eval_constant_expression /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/cp/constexpr.cc:7119 0x98df9e cxx_eval_internal_function /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/cp/constexpr.cc:1839 0x98238e cxx_eval_call_expression /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/cp/constexpr.cc:2395 0x985647 cxx_eval_constant_expression /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/cp/constexpr.cc:6627 0x988743 cxx_eval_outermost_constant_expr /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/cp/constexpr.cc:7700 0x98d54e maybe_constant_value(tree_node*, tree_node*, bool) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/cp/constexpr.cc:7994 0xa2548b fold_for_warn(tree_node*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/cp/expr.cc:416 0xbc6e08 maybe_warn_about_returning_address_of_local /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/cp/typeck.cc:10067 0xbc6e08 check_return_expr(tree_node*, bool*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/cp/typeck.cc:10730 0xb6fbde finish_return_stmt(tree_node*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/cp/semantics.cc:1195 0xace69c cp_parser_jump_statement /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/cp/parser.cc:14313 0xace69c cp_parser_statement /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/cp/parser.cc:12318 0xacf34d cp_parser_statement_seq_opt /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/cp/parser.cc:12856 0xacf427 cp_parser_compound_statement /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/cp/parser.cc:12808 0xaeffd5 cp_parser_function_body /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/cp/parser.cc:25052 0xaeffd5 cp_parser_ctor_initializer_opt_and_function_body /var/tmp/portage/sys-devel/gcc-12.0.1_p20220123/work/gcc-12-20220123/gcc/cp/parser.cc:25103
[Bug fortran/103970] Multi-image co_broadcast of derived type with allocatable components fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103970 Andre Vehreschild changed: What|Removed |Added CC||vehre at gcc dot gnu.org Last reconfirmed||2022-01-25 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug fortran/103970] Multi-image co_broadcast of derived type with allocatable components fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103970 Andre Vehreschild changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #1 from Andre Vehreschild --- Bugfix at: https://gcc.gnu.org/pipermail/fortran/2022-January/057459.html Waiting for review/ok.
[Bug middle-end/104226] ICE in fold_vec_perm, at fold-const.cc:10483 since r12-6821-g053bcc97f4a59e3f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104226 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-01-25 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|ICE in fold_vec_perm, at|ICE in fold_vec_perm, at |fold-const.cc:10483 |fold-const.cc:10483 since ||r12-6821-g053bcc97f4a59e3f Priority|P3 |P1 Status|UNCONFIRMED |NEW Target Milestone|--- |12.0 --- Comment #1 from Martin Liška --- Started with r12-6821-g053bcc97f4a59e3f.
[Bug ipa/104223] GCC unable to inline trivial functions passed to views::filter and transform unless lifted into types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104223 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- There are other bugs which have a similar issue where we figure out the function call late but then don't have another inlining pass.
[Bug libstdc++/65343] unexpected exception thrown during destruction of static object in debug mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65343 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-01-25 --- Comment #4 from Eric Botcazou --- Right, this is problematic on VxWorks and Windows at least.
[Bug bootstrap/67102] Parallel build fails in libffi/configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67102
--- Comment #6 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:aeac414923aa1e87986c7fc6f9b921d89a9b86cf
commit r12-6861-gaeac414923aa1e87986c7fc6f9b921d89a9b86cf
Author: Thomas Schwinge
Date: Tue Jan 25 18:44:02 2022 +0100
Revert "Fix PR 67102: Add libstdc++ dependancy to libffi" [PR67102]
This reverts commit db1a65d9364fe72c2fff65fb2dec051728b6f3fa.
On 2021-09-17T01:01:39-0700, Andrew Pinski via Gcc-patches
wrote:
> On Fri, Sep 17, 2021 at 12:46 AM Thomas Schwinge
wrote:
>> On 2021-09-15T13:56:37-0700, apinski--- via Gcc-patches
wrote:
>> > The error message is obvious -funconfigured-libstdc++-v3 is used
>> > on the g++ command line. So we just add the dependancy.
>>
>> > --- a/Makefile.def
>> > +++ b/Makefile.def
>> > @@ -592,6 +592,7 @@ dependencies = { module=configure-target-fastjar;
on=configure-target-zlib; };
>> > dependencies = { module=all-target-fastjar; on=all-target-zlib; };
>> > dependencies = { module=configure-target-libgo;
on=configure-target-libffi; };
>> > dependencies = { module=configure-target-libgo;
on=all-target-libstdc++-v3; };
>> > +dependencies = { module=configure-target-libffi;
on=all-target-libstdc++-v3; };
>> > dependencies = { module=all-target-libgo; on=all-target-libbacktrace;
};
>> > dependencies = { module=all-target-libgo; on=all-target-libffi; };
>> > dependencies = { module=all-target-libgo; on=all-target-libatomic; };
>>
>> I'm confused, because given that this 'Makefile.def' change only has the
>> following effect:
>>
>> > --- a/Makefile.in
>> > +++ b/Makefile.in
>> > @@ -61261,6 +61261,7 @@ all-bison: maybe-all-intl
>> > all-flex: maybe-all-intl
>> > all-m4: maybe-all-intl
>> > configure-target-libgo: maybe-all-target-libstdc++-v3
>> > +configure-target-libffi: maybe-all-target-libstdc++-v3
>> > configure-target-liboffloadmic: maybe-configure-target-libgomp
>> > all-target-liboffloadmic: maybe-all-target-libgomp
>> > configure-target-newlib: maybe-all-binutils
>>
>> ... isn't that actually a no-op, because we already had such a
dependency
>> listed? Now twice:
>>
>> $ grep -n -F 'configure-target-libffi:
maybe-all-target-libstdc++-v3' -- Makefile.in
>> 61264:configure-target-libffi: maybe-all-target-libstdc++-v3
>> 61372:configure-target-libffi: maybe-all-target-libstdc++-v3
>>
>> Compared to the existing one, the one you've added is additionally
>> restricted by '@unless gcc-bootstrap'.
>>
>> I noticed this as I remembered that on our og[...] development branches
>> we have a patch in the opposite direction: get rid of this dependency
via
>> removing 'lang_env_dependencies = { module=libffi; cxx=true; };' from
>> 'Makefile.def'. See
>>
>> "Disable libstdc++ dependency for libffi". (Maciej CCed in case you
have
>> any further thoughts on that.)
>
> Oh, I see what happened now, the old bug was actually fixed by r6-5415
> which added cxx=true.
> So yes my patch is actually not needed and can be reverted.
> I tried to look to see if there was a dependency was there but for
> some reason I did not see it.
[Bug fortran/104227] New: [9/10/11/12 Regression] ICE virtual memory exhausted: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104227 Bug ID: 104227 Summary: [9/10/11/12 Regression] ICE virtual memory exhausted: Cannot allocate memory Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to r8, changed between 20190208 and 20190308 : (follow-up of pr101514) $ cat z1.f90 program p type t end type type(t) :: x(2) print *, transfer(1, x) end $ cat z2.f90 program p type t end type type(t) :: x(2) x = transfer(1, x) end $ gfortran-12-20220123 -c z1.f90 virtual memory exhausted: Cannot allocate memory $ gfortran-12-20220123 -c z2.f90 GNU MP: Cannot allocate memory (size=8) f951: internal compiler error: Aborted mmap: Cannot allocate memory $ gfortran-12-20220123-chk -c z1.f90 # ulimits set GNU MP: Cannot allocate memory (size=8) f951: out of memory allocating 139 bytes after a total of 1494507520 bytes
[Bug fortran/104228] New: [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104228 Bug ID: 104228 Summary: [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to r8 : $ cat z1.f90 program p character(:), save, allocatable :: x(:) call s contains subroutine s associate (y => x) y = [x] end associate end end $ cat z2.f90 program p character(:), allocatable :: x(:) call s contains subroutine s associate (y => x) y = [x] end associate end end $ gfortran-12-20220123 -c z1.f90 -fsanitize=address during RTL pass: no-opt dfinit z1.f90:3:9: 3 |call s | ^ internal compiler error: Segmentation fault 0xe6bd5f crash_signal ../../gcc/toplev.cc:322 0x98c58f df_install_ref ../../gcc/df-scan.cc:2294 0x98c707 df_install_refs ../../gcc/df-scan.cc:2375 0x98c87e df_refs_add_to_chains ../../gcc/df-scan.cc:2429 0x994b75 df_bb_refs_record(int, bool) ../../gcc/df-scan.cc:3351 0x9951a4 df_scan_blocks() ../../gcc/df-scan.cc:588 0x97df85 rest_of_handle_df_initialize ../../gcc/df-core.cc:715 0x97df85 execute ../../gcc/df-core.cc:747 ... or other backtraces
[Bug fortran/100275] ICE in gfc_build_null_descriptor, at fortran/trans-array.c:417
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100275 --- Comment #2 from G. Steinmetz --- Seems to be fixed.
[Bug fortran/104229] New: ICE in gfc_build_null_descriptor, at fortran/trans-array.cc:536
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104229 Bug ID: 104229 Summary: ICE in gfc_build_null_descriptor, at fortran/trans-array.cc:536 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : (follow-up of pr100275) $ cat z1.f90 module m type t end type class(t), allocatable :: z target :: z(2) end $ gfortran-12-20220123 -c z1.f90 z1.f90:6:3: 6 | end | 1 internal compiler error: in gfc_build_null_descriptor, at fortran/trans-array.cc:536 0x7a81e9 gfc_build_null_descriptor(tree_node*) ../../gcc/fortran/trans-array.cc:536 0x7e9ac7 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.cc:8374 0x7caf5b gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.cc:1944 0x7cdd78 gfc_create_module_variable ../../gcc/fortran/trans-decl.cc:5244 0x789642 do_traverse_symtree ../../gcc/fortran/symbol.cc:4174 0x7ce57b gfc_generate_module_vars(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:5743 0x7a5ee4 gfc_generate_module_code(gfc_namespace*) ../../gcc/fortran/trans.cc:2309 0x75143f translate_all_program_units ../../gcc/fortran/parse.cc:6638 0x75143f gfc_parse_file() ../../gcc/fortran/parse.cc:6938 0x79e86f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug tree-optimization/104215] bogus -Wuse-after-free=3 due to forwprop moving a pointer test after realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104215 --- Comment #2 from Martin Sebor --- The use in your example is undefined in C (as is any other use of an indeterminate pointer value). C++ made using pointers made it implementation-defined a few years ago while still allowing for it to crash, which is still effectively undefined. The warning for your example (equality) only triggers at level 3 (which is not the default in -Wall) to accommodate the C++ decision.
[Bug tree-optimization/104215] bogus -Wuse-after-free=3 due to forwprop moving a pointer test after realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104215 --- Comment #3 from Martin Sebor --- I meant to say "C++ made it implementation-defined to use a pointer made indeterminate by the pointee's lifetime having ended."
[Bug c++/93740] Template base classes parametrized by pointer-to-member are amibiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93740
--- Comment #5 from m.cencora at gmail dot com ---
I think I was able to narrow it down to the true root cause. Following fails in
all gcc versions that supports C++11 and newer:
struct foo
{
void baz();
void bar();
};
static_assert(&foo::baz != &foo::bar, "");
You may ask why I think so, because when we compile following code with
-std=c++17 in gcc6.x, gcc7.x or gcc8.x:
struct foo
{
void baz();
void bar();
};
constexpr auto foo_baz()
{
return &foo::baz;
}
constexpr auto foo_bar()
{
return &foo::bar;
}
template
struct member_fun_ptr;
using member_foo_baz = member_fun_ptr;
using member_foo_bar = member_fun_ptr;
we get following errors:
:20:48: error: 'void (foo::*)(){foo::baz, 0}' is not a valid template
argument for type 'void (foo::*)()'
using member_foo_baz = member_fun_ptr;
^
:20:48: note: it must be a pointer-to-member of the form '&X::Y'
:21:48: error: 'void (foo::*)(){foo::bar, 0}' is not a valid template
argument for type 'void (foo::*)()'
using member_foo_bar = member_fun_ptr;
which indicates that both &foo::baz and &foo::bar both have value '0' in
compile time, which is certainly not correct (and that is most likely why we
get "ambiguous base class" error in the example from comment#1).
[Bug fortran/100275] ICE in gfc_build_null_descriptor, at fortran/trans-array.c:417
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100275 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from anlauf at gcc dot gnu.org --- Looks very much like a duplicate of pr67804. *** This bug has been marked as a duplicate of bug 67804 ***
[Bug fortran/67804] ICE on data initialization of type(character) with wrong data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67804 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||gs...@t-online.de --- Comment #8 from anlauf at gcc dot gnu.org --- *** Bug 100275 has been marked as a duplicate of this bug. ***
[Bug sanitizer/101476] AddressSanitizer check failed, points out a (potentially) non-existing stack error and pthread_cancel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476
--- Comment #16 from Stas Sergeev ---
I think I'll propose to apply something like this to linux kernel:
diff --git a/kernel/signal.c b/kernel/signal.c
index 6f3476dc7873..0549212a8dd6 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -4153,6 +4153,7 @@ do_sigaltstack (const stack_t *ss, stack_t *oss, unsigned
long sp,
if (ss_mode == SS_DISABLE) {
ss_size = 0;
ss_sp = NULL;
+ ss_flags = SS_DISABLE;
} else {
if (unlikely(ss_size < min_ss_size))
ret = -ENOMEM;
[Bug tree-optimization/104215] bogus -Wuse-after-free=3 due to forwprop moving a pointer test after realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104215 --- Comment #4 from rguenther at suse dot de --- > Am 25.01.2022 um 19:20 schrieb msebor at gcc dot gnu.org > : > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104215 > > --- Comment #3 from Martin Sebor --- > I meant to say "C++ made it implementation-defined to use a pointer made > indeterminate by the pointee's lifetime having ended." I’m sure „use“ is too weak defined here. Also reallocate only conditionally ends the pointees lifetime since it can return NULL or the same pointer. > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug middle-end/104226] [12 Regression] ICE in fold_vec_perm, at fold-const.cc:10483 since r12-6821-g053bcc97f4a59e3f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104226 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org CC||jakub at gcc dot gnu.org
[Bug c++/104230] New: Non-type template arguments of reference and pointer type fail when initialized by pointer to member operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104230
Bug ID: 104230
Summary: Non-type template arguments of reference and pointer
type fail when initialized by pointer to member
operator
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at socialhacker dot com
Target Milestone: ---
I believe that GCC incorrectly rejects non-type template arguments of pointer
and reference type that were generated by using the pointer to member operator.
My reading of "P1907R1: Inconsistencies with non-type template parameters" [1]
makes me think that these uses should be acceptable. In particular the change
to "13.4.2 [temp.arg.nontype] paragraph 2" moves the restriction of passing a
reference to a subobject so that it only applies to subobjects of already
disallowed values (temporaries, string literals ...). And it looks like that's
working when using direct member access operators, but not when using pointer
to member operators. And nothing there seems to indicate how the reference or
pointer is generated, so presumably any valid constant expression that
generates a valid pointer or reference should be acceptable.
Below is a simple test case that fails on both the trunk [2] and 11.2 [3]
versions on compiler explorer.
struct T { int a; int b; } t;
template struct U {};
U<&t.a> u1;
U<&t.b> u2;
U<(&(t.*(&T::a)))> u3; // Interestingly doesn't fail, good?
U<(&(t.*(&T::b)))> u4; // Fails, shouldn't fail in C++20 I believe
template struct V {};
V v1;
V v2;
V<(t.*(&T::a))> v3; // Fails, shouldn't fail in C++20 I believe
V<(t.*(&T::b))> v4; // Fails, shouldn't fail in C++20 I believe
Both compiler version produce the same output when run with `--std=c++20
-Wall`:
:8:18: error: '(((int*)(& t)) + 4)' is not a valid template
argument for 'int*' because it is not the address of a variable
8 | U<(&(t.*(&T::b)))> u4;
| ^
:14:15: error: '&(int&)(& t)' is not a valid template argument of
type 'int&' because '(int&)(& t)' is not a variable
14 | V<(t.*(&T::a))> v3;
| ^
:15:15: error: '&(((int&)(& t)) + 4)' is not a valid template
argument of type 'int&' because '(((int&)(& t)) + 4)' is not a variable
15 | V<(t.*(&T::b))> v4;
| ^
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1907r1.html
[2] gcc version 12.0.1 20220125 (experimental)
(Compiler-Explorer-Build-gcc-bb99171b9b0f01a46bfca2d3cbd52fc6faf6cbaa-binutils-2.36.1)
[3] gcc version 11.2.0 (Compiler-Explorer-Build-gcc--binutils-2.36.1)
[Bug c++/59950] [9/10/11/12 Regression] Bogus diagnostic "taking address of temporary" taking address of trivial no-op assignment to temporary with empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59950 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:fe5cee6f62a0b229d9d51616b7490331d39b5ddd commit r12-6862-gfe5cee6f62a0b229d9d51616b7490331d39b5ddd Author: Jason Merrill Date: Mon Jan 24 00:01:40 2022 -0500 c++: assignment to temporary [PR59950] Given build_this of a TARGET_EXPR, cp_build_fold_indirect_ref returns the TARGET_EXPR. But that's the wrong value category for the result of the defaulted class assignment operator, which returns an lvalue, so we need to actually build the INDIRECT_REF. PR c++/59950 gcc/cp/ChangeLog: * call.cc (build_over_call): Use cp_build_indirect_ref. gcc/testsuite/ChangeLog: * g++.dg/init/assign2.C: New test.
[Bug c++/59950] [9/10/11 Regression] Bogus diagnostic "taking address of temporary" taking address of trivial no-op assignment to temporary with empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59950 Jason Merrill changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10/11 Regression] Bogus |Bogus diagnostic "taking|diagnostic "taking address |address of temporary" |of temporary" taking |taking address of trivial |address of trivial no-op |no-op assignment to |assignment to temporary |temporary with empty class |with empty class --- Comment #6 from Jason Merrill --- Fixed for GCC 12 so far.
[Bug fortran/67804] ICE on data initialization of type(character) with wrong data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67804 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:21551a4af1be07d7b98221639ec1bd18106c1f80 commit r10-10418-g21551a4af1be07d7b98221639ec1bd18106c1f80 Author: Harald Anlauf Date: Wed Jan 12 21:24:49 2022 +0100 Fortran: fix error recovery on bad structure constructor in DATA statement gcc/fortran/ChangeLog: PR fortran/67804 * primary.c (gfc_match_structure_constructor): Recover from errors that occurred while checking for a valid structure constructor in a DATA statement. gcc/testsuite/ChangeLog: PR fortran/67804 * gfortran.dg/pr93604.f90: Adjust to changed diagnostics. * gfortran.dg/pr67804.f90: New test. (cherry picked from commit 0b8464365b15ac108cd1d00d5bc56d229c1340de)
[Bug fortran/101762] ICE with "Every subscript of the target specification must be a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101762 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:a5f7e0838e1573f4cc33a6f2c70c60187d7a63af commit r10-10419-ga5f7e0838e1573f4cc33a6f2c70c60187d7a63af Author: Harald Anlauf Date: Sun Jan 9 22:08:14 2022 +0100 Fortran: reject invalid non-constant pointer initialization targets gcc/fortran/ChangeLog: PR fortran/101762 * expr.c (gfc_check_pointer_assign): For pointer initialization targets, check that subscripts and substring indices in specifications are constant expressions. gcc/testsuite/ChangeLog: PR fortran/101762 * gfortran.dg/pr101762.f90: New test. (cherry picked from commit 2e63128306ff93d8f53119137dd6c28b2defac94)
[Bug fortran/67804] ICE on data initialization of type(character) with wrong data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67804 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |10.4 --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11- and 10-branch. Trying to back further shows an unexpected failure during regtesting. Not worth investigating, thus closing. Thanks for the report!
[Bug fortran/33056] [Meta-bug] Data - statement related bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056 Bug 33056 depends on bug 67804, which changed state. Bug 67804 Summary: ICE on data initialization of type(character) with wrong data https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67804 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/101762] ICE with "Every subscript of the target specification must be a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101762 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |10.4 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11- and 10-branch. Backporting further is probably not necessary. Closing. Thanks for the report!
[Bug c++/104225] [9/10/11/12 Regression] accepts-invalid new expression that uses deleted implicit default constructor of class specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104225 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:bc90dd0ecf02e11d47d1af7f627e2e2acaa40106 commit r12-6863-gbc90dd0ecf02e11d47d1af7f627e2e2acaa40106 Author: Patrick Palka Date: Tue Jan 25 15:04:49 2022 -0500 c++: deleted fn and noexcept inst [PR101532, PR104225] Here when attempting to use B's implicitly deleted default constructor, mark_used rightfully returns false, but for the wrong reason: it tries to instantiate the synthesized noexcept specifier which then only silently fails because get_defaulted_eh_spec suppresses diagnostics for deleted functions. This lack of diagnostics causes us to crash on the first testcase below (thanks to the assert in finish_expr_stmt), and silently accept the second testcase. To fix this, this patch makes mark_used avoid attempting to instantiate the noexcept specifier of a deleted function, so that we'll instead directly reject (and diagnose) the function due to its deletedness. PR c++/101532 PR c++/104225 gcc/cp/ChangeLog: * decl2.cc (mark_used): Don't consider maybe_instantiate_noexcept on a deleted function. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-template21.C: New test. * g++.dg/cpp0x/nsdmi-template21a.C: New test.
[Bug c++/101532] [12 Regression] ICE in finish_expr_stmt, at cp/semantics.c:859
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101532 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:bc90dd0ecf02e11d47d1af7f627e2e2acaa40106 commit r12-6863-gbc90dd0ecf02e11d47d1af7f627e2e2acaa40106 Author: Patrick Palka Date: Tue Jan 25 15:04:49 2022 -0500 c++: deleted fn and noexcept inst [PR101532, PR104225] Here when attempting to use B's implicitly deleted default constructor, mark_used rightfully returns false, but for the wrong reason: it tries to instantiate the synthesized noexcept specifier which then only silently fails because get_defaulted_eh_spec suppresses diagnostics for deleted functions. This lack of diagnostics causes us to crash on the first testcase below (thanks to the assert in finish_expr_stmt), and silently accept the second testcase. To fix this, this patch makes mark_used avoid attempting to instantiate the noexcept specifier of a deleted function, so that we'll instead directly reject (and diagnose) the function due to its deletedness. PR c++/101532 PR c++/104225 gcc/cp/ChangeLog: * decl2.cc (mark_used): Don't consider maybe_instantiate_noexcept on a deleted function. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-template21.C: New test. * g++.dg/cpp0x/nsdmi-template21a.C: New test.
[Bug preprocessor/96391] [10 Regression] ICE in linemap_compare_locations on "CONST VOID" in large C++ files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #27 from Michael Cronenworth --- I can also say that gcc 11 has fixed this. Thanks. I'm happy to close as I will not be using 10.x anymore.
[Bug c++/104225] [9/10/11/12 Regression] accepts-invalid new expression that uses deleted implicit default constructor of class specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104225 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Patrick Palka --- Fixed.
[Bug c++/101532] [12 Regression] ICE in finish_expr_stmt, at cp/semantics.c:859
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101532 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Patrick Palka --- Fixed.
[Bug c++/104225] [9/10/11 Regression] accepts-invalid new expression that uses deleted implicit default constructor of class specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104225 Patrick Palka changed: What|Removed |Added Status|RESOLVED|NEW Summary|[9/10/11/12 Regression] |[9/10/11 Regression] |accepts-invalid new |accepts-invalid new |expression that uses|expression that uses |deleted implicit default|deleted implicit default |constructor of class|constructor of class |specialization |specialization Resolution|FIXED |--- --- Comment #4 from Patrick Palka --- (In reply to Patrick Palka from comment #3) > Fixed. ... for GCC 12 so far.
[Bug target/104213] [12 Regression] bogus use-after-free in virtual dtor with -ffat-lto-objects on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104213
--- Comment #12 from Marek Polacek ---
Removing the COMPARISON_CLASS_P check regresses uninit-pr74762.C. So how about
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 22d3dd1e2ad..6534a7fd320 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -17315,6 +17315,7 @@ finish_constructor_body (void)
add_stmt (build_stmt (input_location, LABEL_EXPR, cdtor_label));
val = DECL_ARGUMENTS (current_function_decl);
+ suppress_warning (val, OPT_Wuse_after_free);
val = build2 (MODIFY_EXPR, TREE_TYPE (val),
DECL_RESULT (current_function_decl), val);
/* Return the address of the object. */
@@ -17408,6 +17409,7 @@ finish_destructor_body (void)
tree val;
val = DECL_ARGUMENTS (current_function_decl);
+ suppress_warning (val, OPT_Wuse_after_free);
val = build2 (MODIFY_EXPR, TREE_TYPE (val),
DECL_RESULT (current_function_decl), val);
/* Return the address of the object. */
diff --git a/gcc/cp/optimize.cc b/gcc/cp/optimize.cc
index 4ad3f1dc9aa..13ab8b7361e 100644
--- a/gcc/cp/optimize.cc
+++ b/gcc/cp/optimize.cc
@@ -166,6 +166,7 @@ build_delete_destructor_body (tree delete_dtor, tree
complete_dtor)
if (targetm.cxx.cdtor_returns_this ())
{
tree val = DECL_ARGUMENTS (delete_dtor);
+ suppress_warning (val, OPT_Wuse_after_free);
val = build2 (MODIFY_EXPR, TREE_TYPE (val),
DECL_RESULT (delete_dtor), val);
add_stmt (build_stmt (0, RETURN_EXPR, val));
diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
index 8bc33eeb6fa..f39092ec416 100644
--- a/gcc/gimple-ssa-warn-access.cc
+++ b/gcc/gimple-ssa-warn-access.cc
@@ -3880,9 +3880,19 @@ pass_waccess::warn_invalid_pointer (tree ref, gimple
*use_stmt,
bool maybe, bool equality /* = false */)
{
/* Avoid printing the unhelpful "" in the diagnostics. */
- if (ref && TREE_CODE (ref) == SSA_NAME
- && (!SSA_NAME_VAR (ref) || DECL_ARTIFICIAL (SSA_NAME_VAR (ref
-ref = NULL_TREE;
+ if (ref && TREE_CODE (ref) == SSA_NAME)
+{
+ tree var = SSA_NAME_VAR (ref);
+ if (!var)
+ ref = NULL_TREE;
+ else if (DECL_ARTIFICIAL (var))
+ {
+ /* Don't warn for cases like when a cdtor returns 'this' on ARM. */
+ if (warning_suppressed_p (var, OPT_Wuse_after_free))
+ return;
+ ref = NULL_TREE;
+ }
+}
location_t use_loc = gimple_location (use_stmt);
if (use_loc == UNKNOWN_LOCATION)
I guess I can test & post it.
[Bug fortran/104212] ICE in transformational_result, at fortran/simplify.cc:466
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104212 --- Comment #3 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:34e8dafb76240f69c729c11cfc8c8fc4f717bc17 commit r12-6864-g34e8dafb76240f69c729c11cfc8c8fc4f717bc17 Author: Harald Anlauf Date: Mon Jan 24 21:40:41 2022 +0100 Fortran: optional argument DIM for intrinsics NORM2, PARITY must be scalar gcc/fortran/ChangeLog: PR fortran/104212 * check.cc (gfc_check_norm2): Check that optional argument DIM is scalar. (gfc_check_parity): Likewise. gcc/testsuite/ChangeLog: PR fortran/104212 * gfortran.dg/argument_checking_26.f90: New test.
[Bug ipa/104187] Call site specific attribute to control inliner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104187 --- Comment #5 from Dávid Bolvanský --- So you prefer eg. g = a[i] - [[gnu::always_inline]] foo(x, y) + 2 * bar(); over g = a[i] - __builtin_always_inline(foo(x, y)) + 2 * bar(); ? What is your proposed syntax?
[Bug c++/104231] New: private ignored in non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104231
Bug ID: 104231
Summary: private ignored in non-type template parameter
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: f.heckenb...@fh-soft.de
Target Milestone: ---
% cat test.cpp
class A
{
struct B
{
constexpr B (int) { }
void error () const { throw 0; }
};
};
template void foo () { s.error (); }
int main ()
{
foo <0> ();
}
% g++ -std=c++20 test.cpp
% ./a.out
terminate called after throwing an instance of 'int'
Aborted
Being a private member of A, B should not be accessible.
The exception thrown is just to prove that a B object is indeed constructed.
[Bug middle-end/104232] New: spurious -Wuse-after-free after conditional free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104232
Bug ID: 104232
Summary: spurious -Wuse-after-free after conditional free
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The test case below was reduced from
https://bugzilla.redhat.com/show_bug.cgi?id=2043195 (it's been greatly
simplified). It shows a false positive caused by the warning's overly
simplistic PHI handling: the warning warns on any PHI use with an operand
that's been passed to free in a block that dominates the use.
$ cat rhbz2043195.c && gcc -O2 -S -Wall -fdump-tree-waccess3=/dev/stdout
rhbz2043195.c
static inline void freep (void *p)
{
__builtin_free (*(void**)p);
}
char *f (void);
int g (void)
{
__attribute__ ((__cleanup__ (freep))) char *s = 0, *t = 0;
t = f ();
if (!t)
return 0;
s = f ();
return 1;
}
;; Function g (g, funcdef_no=1, decl_uid=1984, cgraph_uid=2, symbol_order=1)
In function ‘freep’,
inlined from ‘g’ at rhbz2043195.c:10:47:
rhbz2043195.c:3:3: warning: pointer ‘s’ used after ‘__builtin_free’
[-Wuse-after-free]
3 | __builtin_free (*(void**)p);
| ^~~
In function ‘freep’,
inlined from ‘g’ at rhbz2043195.c:10:55:
rhbz2043195.c:3:3: note: call to ‘__builtin_free’ here
3 | __builtin_free (*(void**)p);
| ^~~
pointer_query counters:
index cache size: 21
index entries: 3
access cache size: 6
access entries: 3
hits: 1
misses: 3
failures: 0
max_depth: 3
int g ()
{
char * s;
char * _1;
char * _2;
int _3;
[local count: 1073741824]:
_1 = f ();
if (_1 == 0B)
goto ; [30.95%]
else
goto ; [69.05%]
[local count: 741418729]:
_2 = f ();
[local count: 1073741824]:
# _3 = PHI <0(2), 1(3)>
# s_10 = PHI <_1(2), _2(3)>
__builtin_free (_1);
__builtin_free (s_10);
return _3;
}
[Bug middle-end/104232] [12 Regression] spurious -Wuse-after-free after conditional free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104232 Martin Sebor changed: What|Removed |Added Blocks||104075 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Keywords||diagnostic Last reconfirmed||2022-01-25 URL||https://bugzilla.redhat.com ||/show_bug.cgi?id=2043195 Summary|spurious -Wuse-after-free |[12 Regression] spurious |after conditional free |-Wuse-after-free after ||conditional free Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075 [Bug 104075] bogus/missing -Wuse-after-free
[Bug libstdc++/104191] Incorrect max_size() for node-based containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104191 --- Comment #2 from frankhb1989 at gmail dot com --- (In reply to Jonathan Wakely from comment #1) > (In reply to frankhb1989 from comment #0) > > and it should be solely determined by the internal node count type. > > What is the internal node count type? You mean the size_type? That would be > wrong, because there's no way you can create > numeric_limits::max() nodes, as each node requires tens of bytes. > For the current std::list implementation with _GLIBCXX_USE_CXX11_ABI enabled, it is the type of _List_node_header::_M_size, which is explicitly declared as std::size_t. Otherwise, it is the size_type. Both are effectively size_t. Allocating such many nodes are generally impossible to succeed with usual allocators, but what if allocators with fancy pointers which can point to objects allocated out of the main memory in the usual flat address space (e.g. via Microsoft Windows's address windowing extensions)? There is one more related problem: can the allocator's size_type greater than size_t? If so, the implementations of max_size() are immediately more flawed due to the truncation of allocator's size_type to container's size_type (size_t), e.g. when the allocator's max_size() is implemented by default in the allocator traits (since the fix of LWG 2466). As per https://stackoverflow.com/a/12499353, the standard used to allow such size_type. But I then found the referenced wording are invalidated by the side effects of the changes in LWG 2384 and P0593R6. I'm not confident they are intentional. > I agree using the allocator's max_size() is wrong, but it doesn't really > matter because all max_size() functions on containers and allocators are > useless in practice. This is true for most user code. But it still seems too easy to break, as the case shows. Further, it exposes some internal consistency in the implementation. MSVC's std::list checks the size and throw std::length_error in the insertion to avoid the inconsistency. I don't think such cost should be introduced here. The simplest fix is just to return numeric_limits::max() in container's max_size()... well, only if PR 78448 is not taken into account. It catastrophically blocks the way of this simple fix. Perhaps there could be an LWG issue to propose changes on the definitions of size() and max_size() to get rid of the range limit of difference_type at least for containers not requiring contiguous memory (and [container.requirements.general]/5 kicks in instead)... then the simple fix can be applied.
[Bug middle-end/104232] [12 Regression] spurious -Wuse-after-free after conditional free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104232 Martin Sebor changed: What|Removed |Added URL|https://bugzilla.redhat.com |https://bugzilla.redhat.com |/show_bug.cgi?id=2043195|/show_bug.cgi?id=2043915 --- Comment #1 from Martin Sebor --- The correct URL is https://bugzilla.redhat.com/show_bug.cgi?id=2043915
[Bug fortran/104227] [9/10/11/12 Regression] ICE virtual memory exhausted: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104227
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC||anlauf at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-01-25
--- Comment #1 from anlauf at gcc dot gnu.org ---
Obvious fix:
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 4fa05ee7e9b..d6c6767ae9e 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -6151,7 +6151,7 @@ gfc_calculate_transfer_sizes (gfc_expr *source, gfc_expr
*mold, gfc_expr *size,
* If SIZE is present, the result is an array of rank one and size SIZE.
*/
if (result_elt_size == 0 && *source_size > 0 && !size
- && mold->expr_type == EXPR_ARRAY)
+ && (mold->expr_type == EXPR_ARRAY || mold->rank))
{
gfc_error ("% argument of % intrinsic at %L is an "
"array and shall not have storage size 0 when % "
