[Bug middle-end/98183] [8/9/10/11 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98183 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cc9b9c0b68233d38a26f7acd68cc5f9a8fc4d994 commit r11-5956-gcc9b9c0b68233d38a26f7acd68cc5f9a8fc4d994 Author: Jakub Jelinek Date: Sat Dec 12 08:36:02 2020 +0100 openmp, openacc: Fix up handling of data regions [PR98183] While the data regions (target data and OpenACC counterparts) aren't standalone directives, unlike most other OpenMP/OpenACC constructs we allow (apparently as an extension) exceptions and goto out of the block. During gimplification we place an *end* call into a finally block so that it is reached even on exceptions or goto out etc.). During omplower pass we then add paired #pragma omp return for them, but due to the exceptions because the region is not SESE we can end up with #pragma omp return appearing only conditionally in the CFG etc., which the ompexp pass can't handle. For the ompexp pass, we actually don't care about the end part or about target data nesting, so we can treat it as standalone directive. 2020-12-12 Jakub Jelinek PR middle-end/98183 * omp-low.c (lower_omp_target): Don't add OMP_RETURN for data regions. * omp-expand.c (expand_omp_target): Don't try to remove OMP_RETURN for data regions. (build_omp_regions_1, omp_make_gimple_edges): Don't expect OMP_RETURN for data regions. * gcc.dg/gomp/pr98183.c: New test. * gcc.dg/goacc/pr98183.c: New test.
[Bug libgcc/98251] New: libgcc on 32-bit soft-float ARM narrows -NaN incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98251
Bug ID: 98251
Summary: libgcc on 32-bit soft-float ARM narrows -NaN
incorrectly
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: bbarenblat at gmail dot com
Target Milestone: ---
Created attachment 49749
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49749&action=edit
preprocessed minimal example
On 32-bit ARM without hardware floating point, libgcc narrows a negative NaN
double to a positive NaN float. However, GCC's optimizer assumes that narrowing
conversions preserve sign even in the presence of NaN:
$ cat float.c
#include
extern int printf(const char* format, ...);
static const char* pm(double d) {
return signbit(d) ? "-" : "+";
}
int main(void) {
double d = copysign(nan(""), -1.0);
float f = d;
printf("d is %sNaN; f is %sNaN\n", pm(d), pm(f));
}
$ gcc -O0 -o float float.c -lm
$ ./float
d is -NaN; f is +NaN
$ gcc -O1 -o float float.c -lm
$ ./float
d is -NaN; f is -NaN
Examining the assembly from the second invocation shows that GCC has optimized
out the entire computation. In the first invocation, however, the compiled
calls into libgcc, and libgcc/config/arm/ieee754-df.S:1475 always narrows NaNs
to +NaN:
3: @ chech for NAN
mvnsr3, r2, asr #21
bne 5f @ simple overflow
orrsr3, xl, xh, lsl #12
do_it ne, tt
movne r0, #0x7f00
orrne r0, r0, #0x00c0
RETc(ne)@ return NAN
I've attached the preprocessed version of float.c. Output of 'gcc -v':
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/10/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-1'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=arm-linux-gnueabi- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libitm --disable-libquadmath
--disable-libquadmath-support --enable-plugin --enable-default-pie
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-sjlj-exceptions --with-arch=armv5te --with-float=soft
--disable-werror --enable-checking=release --build=arm-linux-gnueabi
--host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20201207 (Debian 10.2.1-1)
[Bug c/98250] Wrong code path with -O1 and signed overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98250 --- Comment #2 from Jakub Jelinek --- After UB anything can happen, just don't invoke UB in your programs. Please read e.g. https://blog.regehr.org/archives/213
[Bug c/98250] Wrong code path with -O1 and signed overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98250 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- signed overflow is undefined so you are invoking undefined behavior. There is nothing to do here.
[Bug c/98250] New: Wrong code path with -O1 and signed overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98250
Bug ID: 98250
Summary: Wrong code path with -O1 and signed overflow
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stransky.peter at googlemail dot com
Target Milestone: ---
Wrong code path after signed overflow in gcc-10 and optimization > O1.
Problem seems to be introduced somewhere between gcc-6 and gcc-8.
#include
void foo(int n) {
if (n > 0)
{
++n;
printf("n=%d\n", n);
if(n > 0) {
printf("Should not get here.\n");
}
}
}
int main() {
foo(0x7fff);
return 0;
}
g++ issue.cc -o issue && ./issue
n=-2147483648
g++ issue.cc -o issue -O1 && ./issue
n=-2147483648
Should not get here.
[Bug c++/98249] New: Improper ADL on the `arg` in `new (arg) T`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98249
Bug ID: 98249
Summary: Improper ADL on the `arg` in `new (arg) T`
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/xavfej
#include
struct Incomplete;
template struct Holder { T t; };
Holder *p;
void test() {
::new (p) int;
new (p) int;
}
In an "ADL call," the compiler needs to compute the associated types of
`Holder`, which means it needs to complete that type in order to
check for friend declarations. In a "non-ADL call" (such as a qualified call),
the compiler does NOT need to complete `Holder`. Since completing
`Holder` produces a hard error, we can detect the difference
between an ADL and a non-ADL call.
All other compilers use "non-ADL calls" for both `::new (p) int` and `new (p)
int`: they don't attempt to complete the incomplete type. GCC uses "ADL calls"
for both, which means it hard-errors on both lines.
I'm not sure what the Standard has to say about this, but GCC disagrees with
all of Clang/MSVC/ICC, so I think GCC ought to change.
(Detected while testing libc++ patch https://reviews.llvm.org/D92884)
[Bug fortran/98017] [8/9/10/11 Regression] Suspected regression (relative to 7.5) using PACK in iolist since r8-4151-g6c6bde30706c29ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on master for gcc-11, and backported to 10-branch, as well as 9- and 8-branches with minor adjustment. Closing. Thanks for the report!
[Bug fortran/98017] [8/9/10/11 Regression] Suspected regression (relative to 7.5) using PACK in iolist since r8-4151-g6c6bde30706c29ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017 --- Comment #9 from CVS Commits --- The releases/gcc-8 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:56f83e64e179f2ff5bb4161db076d7e6ae1c0a3f commit r8-10675-g56f83e64e179f2ff5bb4161db076d7e6ae1c0a3f Author: Harald Anlauf Date: Sun Nov 29 23:23:16 2020 +0100 PR fortran/98017 - Suspected regression using PACK When substituting a parameter variable of type character, the character length was reset to 1. Fix this by copying the length. gcc/fortran/ChangeLog: * expr.c (simplify_parameter_variable): Fix up character length after copying an array-valued expression. gcc/testsuite/ChangeLog: * gfortran.dg/pr98017.f90: New test. (cherry picked from commit bb67ad5cff58a707aaae645d4f45a913d8511c86)
[Bug fortran/98017] [8/9/10/11 Regression] Suspected regression (relative to 7.5) using PACK in iolist since r8-4151-g6c6bde30706c29ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:342be4dce16630575e2de21dbeec4baaed7a143a commit r9-9109-g342be4dce16630575e2de21dbeec4baaed7a143a Author: Harald Anlauf Date: Sun Nov 29 23:23:16 2020 +0100 PR fortran/98017 - Suspected regression using PACK When substituting a parameter variable of type character, the character length was reset to 1. Fix this by copying the length. gcc/fortran/ChangeLog: * expr.c (simplify_parameter_variable): Fix up character length after copying an array-valued expression. gcc/testsuite/ChangeLog: * gfortran.dg/pr98017.f90: New test. (cherry picked from commit bb67ad5cff58a707aaae645d4f45a913d8511c86)
[Bug middle-end/98227] [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'constructor' in get_section, at varasm.c:297 on riscv64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98227 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #4 from Jim Wilson --- This should already be fixed. I ran into the same problem in my testing and committed a patch today that HJ helpfully pointed at. I don't test ada builds normally. I can try that to verify.
[Bug libstdc++/97600] [ranges] satisfaction value of range affected by prior use of basic_istream_view::begin()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97600 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:9324f7a25c7161a813bfae6cc2d180784b165740 commit r11-5954-g9324f7a25c7161a813bfae6cc2d180784b165740 Author: Jason Merrill Date: Fri Dec 11 14:37:09 2020 -0500 c++: Avoid considering some conversion ops [PR97600] Patrick's earlier patch to check convertibility before constraints for conversion ops wasn't suitable because checking convertibility can also lead to unwanted instantiations, but it occurs to me that there's a smaller check we can do to avoid doing normal consideration of the conversion ops in this case: since we're in the middle of a user-defined conversion, we can exclude from consideration any conversion ops that return a type that would need an additional user-defined conversion to reach the desired type: namely, a type that differs in class-ness from the desired type. [temp.inst]/9 allows optimizations like this: "If the function selected by overload resolution can be determined without instantiating a class template definition, it is unspecified whether that instantiation actually takes place." gcc/cp/ChangeLog: PR libstdc++/97600 * call.c (build_user_type_conversion_1): Avoid considering conversion functions that return a clearly unsuitable type. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-conv3.C: New test.
[Bug middle-end/98183] [8/9/10/11 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98183 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Jakub Jelinek --- Created attachment 49748 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49748&action=edit gcc11-pr98183.patch The problem is that the data regions allow exceptions to be thrown, so #pragma omp region for it is problematic. But I think we do everything for the end of the region by putting the end calls into finally during gimplification and so we should just treat those regions post omp-lowering as standalone directives like e.g. target update is.
[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326 --- Comment #21 from rguenther at suse dot de --- On December 11, 2020 6:51:05 PM GMT+01:00, "segher at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326 > >--- Comment #20 from Segher Boessenkool --- >Yes, that is clear... But we have ***double*** x in that example even, >as the declared type of the parameter, so converting that to float is >almost certainly a bad idea? OH... Most definitely.
[Bug middle-end/98183] [8/9/10/11 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98183 Jakub Jelinek changed: What|Removed |Added Keywords||openmp Summary|[9/10/11 Regression] ICE in |[8/9/10/11 Regression] ICE |expand_gimple_stmt_1, at|in expand_gimple_stmt_1, at |cfgexpand.c:3972|cfgexpand.c:3972 Component|c |middle-end --- Comment #5 from Jakub Jelinek --- The openmp testcase started ICEing already in 4.9.
[Bug c/98183] [9/10/11 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98183
--- Comment #4 from Jakub Jelinek ---
And corresponding OpenMP -fopenmp -fexceptions -O0:
void bar ();
int x, y;
void
foo (void)
{
#pragma omp target data map(tofrom: x)
{
#pragma omp target data map(tofrom: y)
bar ();
}
}
ICEs too.
[Bug c/98183] [9/10/11 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98183
--- Comment #3 from Jakub Jelinek ---
Reduced testcase:
void bar (void);
void
foo (void)
{
#pragma acc data
{
#pragma acc host_data
bar ();
}
}
[Bug c/98183] [9/10/11 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98183 --- Comment #2 from Jakub Jelinek --- With these options one of the #pragma omp return statements is not removed from the IL, which must be done during the ompexp pass.
[Bug target/98248] [11 Regression] SVE: Wrong code with -O3 -msve-vector-bits=256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98248 Alex Coplan changed: What|Removed |Added Target Milestone|--- |11.0 CC||rsandifo at gcc dot gnu.org Target||aarch64 Known to fail||11.0 Keywords||wrong-code
[Bug target/98248] New: [11 Regression] SVE: Wrong code with -O3 -msve-vector-bits=256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98248
Bug ID: 98248
Summary: [11 Regression] SVE: Wrong code with -O3
-msve-vector-bits=256
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
AArch64 GCC miscompiles the following testcase:
unsigned long long b;
_Bool a;
unsigned char c[3][22];
unsigned char (*h)[22] = c;
int j;
void aa(unsigned long long *n, int o) { *n ^= o; }
int main() {
for (long e = 0; e < 3; ++e)
for (long d = 0; d < 22; ++d)
c[e][d] = 7;
for (int d = 0; d < 2; d += 4)
for (char g = 0; g < 14; g += 4)
for (int i = 0; i < 12; i += 1)
if (~j)
a = h[d][4];
aa(&b, a);
if (b != 1)
__builtin_abort();
}
at -O3 -march=armv8.2-a+sve -msve-vector-bits=256 since
r11-4912-g46c705e70e078f6a1920d92e49042125d5e18495.
[Bug fortran/98053] Add Fortran tests for behavior from environment variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98053 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P5 Last reconfirmed||2020-12-11 Status|UNCONFIRMED |NEW
[Bug fortran/97723] type bound ASSIGNMENT(=) within select rank block wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug fortran/97694] ICE with optional assumed rank class(*) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug fortran/35718] deallocating non-allocated pointer target does not fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35718 Dominique d'Humieres changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug bootstrap/98188] [11 Regression] ICE in decompose, at wide-int.h:984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98188 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Jakub Jelinek --- Should be fixed now.
[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326 --- Comment #20 from Segher Boessenkool --- Yes, that is clear... But we have ***double*** x in that example even, as the declared type of the parameter, so converting that to float is almost certainly a bad idea?
[Bug tree-optimization/91257] Compile-time and memory-hog hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91257 --- Comment #14 from Rogério de Souza Moraes --- Created attachment 49747 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49747&action=edit File which all the 'try' macros are taken out to separate routines, for build performance improvement
[Bug tree-optimization/91257] Compile-time and memory-hog hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91257 --- Comment #13 from Rogério de Souza Moraes --- Created attachment 49746 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49746&action=edit File that reproduces the current structure and has performance issues.
[Bug tree-optimization/91257] Compile-time and memory-hog hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91257 Rogério de Souza Moraes changed: What|Removed |Added CC||rogerio.souza at gmail dot com --- Comment #12 from Rogério de Souza Moraes --- Hi Richard, first, thank you for the great work improving the GCC performance. The R&D team which I am working with provided two test cases, they show that it was possible to reduce the build time by taking out the block containing setjmp/longjmp to a separate routine, which is only called from the original routine. Both attached files, example_base.c and example_routines.c, are generated in a very similar way, but in example_routines.c, all the 'try' macros are taken out to separate routines. The compilation times: example_base.c: v4.8.3 - 0m1.096s v6.3.0 - 0m16.017s v9.3.0 - 0m26.829s example_routines.c v4.8.3 - 0m0.955s v6.3.0 - 0m1.205s v9.3.0 - 0m1.617s Is this approach ok to improve the build performance? Even if this approach is OK, there are still details unclear to us, and some might be not even known: - Should we worry about inlining? Can we hint this to compiles, or should we make sure it's avoided (by using routine pointers, for example)? - Can we assume that routine call (with all low-level work like copying data on the stack etc.) is the only runtime performance price for this approach? - Is having many small routines instead of a few very large is universally good, or there are cases when it by itself can cause a problem? We appreciate very much any feedback. Best regards, -- Rogerio
[Bug fortran/68778] [F03] Missing default initialization of finalized derived types type(C_PTR) component in subroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68778 --- Comment #7 from Dominique d'Humieres --- I see the valgrind errors in comment 4 up to r241883 (2016-11-06). From r241924 (2016-11-07) up to r265319 (2018-10-19) I don't see them anymore but a lot of MacOS related libraries. Finally after r265571 (2018-10-28) valgrind doesn't report any error as well as 7.4.1, 8.3.1, 9.2.1, 10.0.0, and 11.0.0.
[Bug target/97827] bootstrap error building the amdgcn-amdhsa offload compiler with LLVM 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Tobias Burnus --- FIXED in LLVM 'main' in commit 1deff4009e0ae661b03682901bf6932297ce7ea1 → https://reviews.llvm.org/D92052 + https://bugs.llvm.org/show_bug.cgi?id=48201 Close as WONTFIX on the GCC side. I try to get it backported to LLVM 11.0.1 or, failing that, LLVM 11.0.2. Thanks Matthias for pointing out the issue.
[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092 --- Comment #10 from Andrea Corallo --- "acoplan at gcc dot gnu.org via Gcc-bugs" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092 > > --- Comment #9 from Alex Coplan --- > Thanks for fixing this Andrea! FWIW I can reproduce the ICE with the same > testcase and options on the head of the GCC 10 branch (contrary to my first > message). Hi Alex, I'll test the patch also on gcc-10 then so we can have it there too (it should apply). Thanks for checking! Andrea
Re: [Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c
"acoplan at gcc dot gnu.org via Gcc-bugs" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092 > > --- Comment #9 from Alex Coplan --- > Thanks for fixing this Andrea! FWIW I can reproduce the ICE with the same > testcase and options on the head of the GCC 10 branch (contrary to my first > message). Hi Alex, I'll test the patch also on gcc-10 then so we can have it there too (it should apply). Thanks for checking! Andrea
[Bug tree-optimization/96685] Failure to optimize not+sub to add+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96685 --- Comment #6 from Jakub Jelinek --- Created attachment 49745 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49745&action=edit gcc11-pr96685.patch Updated patch.
[Bug c/98247] New: gcc analyzer does not detect Flexible Array Member misuse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98247
Bug ID: 98247
Summary: gcc analyzer does not detect Flexible Array Member
misuse
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vince.a.bridgers at gmail dot com
Target Milestone: ---
This is more of a query than a bug at this point (or possible "feature
enhancement request"). This initial request follows a similar (but different)
issue filed against clang, see https://bugs.llvm.org/show_bug.cgi?id=48136.
The modified reproducer is shown below. While I understand generally the
compiler cannot know how large a FAM is allocated to be, the question becomes
is there some way gcc analysis can track a beyond bounds memory access at
static analysis time and flag the below case as suspicious? Perhaps this can be
done by constraining the idiom, and indeed that is what some reliable and
secure programming standards do when this matters. Perhaps this is already
covered by gcc, and if so my apologies for missing it - feel free to close this
an invalid with explanation. If there's way to address this already in gcc 11
(or beyond) I'm interested in understanding this.
Thanks
$ gcc --version
gcc (GCC) 11.0.0 20200516 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -fanalyzer fam.c
$ # no output, interpreted to mean no errors found.
#include
#include
struct str {
size_t len;
char data[];
};
int main(void)
{
struct str *str = malloc(sizeof(str) + 10);
if (str) {
str->len = 10;
memset(str->data, 'x', 10);
free(str);
}
return 0;
}
[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092 --- Comment #9 from Alex Coplan --- Thanks for fixing this Andrea! FWIW I can reproduce the ICE with the same testcase and options on the head of the GCC 10 branch (contrary to my first message).
[Bug c++/95768] [11 Regression] -march=sandybridge -O2 -Wall crashes as 'during GIMPLE pass: uninit ... Segmentation fault'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95768 --- Comment #7 from Martin Sebor --- Sort of. Richard has some objections that we never resolved but but I'm still planning to dust it off and resubmit it in some form for GCC 11 with the corresponding C front end changes.
[Bug target/98146] [11 Regression] section type conflict when "used" attribute is applied to decl with specific section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98146 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-12-11 URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-Decembe ||r/561332.html Status|UNCONFIRMED |NEW Keywords||patch
[Bug target/98146] [11 Regression] section type conflict when "used" attribute is applied to decl with specific section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98146 H.J. Lu changed: What|Removed |Added CC||mkuvyrkov at gcc dot gnu.org --- Comment #2 from H.J. Lu --- *** Bug 98246 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/98246] [11 Regression] Linux kernel build fails after 6fbec038f7a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98246 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from H.J. Lu --- Dup *** This bug has been marked as a duplicate of bug 98146 ***
[Bug tree-optimization/96272] Failure to optimize overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96272 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Jakub Jelinek --- Created attachment 49744 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49744&action=edit gcc11-pr96272.patch Untested fix. The addition is then CSEd by RTL PRE, and the reason why we don't emit a conditional move is something in the CE. Though it is a question if we want to use a conditional move, generally predicting overflows don't happen is a good idea and so the overflow case should be pretty cold.
[Bug rtl-optimization/98246] [11 Regression] Linux kernel build fails after 6fbec038f7a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98246 Maxim Kuvyrkov changed: What|Removed |Added CC||mkuvyrkov at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot com --- Comment #1 from Maxim Kuvyrkov --- H.J., would you please take a look? Please let me know if you need assistance with reproducing this. Thanks!
[Bug rtl-optimization/98246] New: [11 Regression] Linux kernel build fails after 6fbec038f7a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98246 Bug ID: 98246 Summary: [11 Regression] Linux kernel build fails after 6fbec038f7a7 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: mkuvyrkov at gcc dot gnu.org Target Milestone: --- Linux kernel build fails at least for AArch64 and armhf after commit 6fbec038f7a7ddf29f074943611b53210d17c40c Author: H.J. Lu Date: Mon Feb 3 11:55:43 2020 -0800 Use SHF_GNU_RETAIN to preserve symbol definitions The error is: 00:04:49 In file included from ./include/linux/serial_sci.h:6, 00:04:49 from drivers/tty/serial/sh-sci.c:42: 00:04:49 ./include/linux/compiler-gcc.h:47:45: error: ‘__UNIQUE_ID___earlycon_hscif362’ causes a section type conflict with ‘banner’ 00:04:4947 | #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__) 00:04:49 | ^~~~ This likely also happens on other architectures. To reproduce a vanilla aarch64-linux-gnu stage1 cross compiler and any recent Linux version is sufficient. Compiler build log: https://ci.linaro.org/job/tcwg_kernel-gnu-bisect-gnu-master-aarch64-mainline-defconfig/24/artifact/artifacts/build-first_bad/04-build_abe-stage1/console.log/*view*/ Kernel build log: https://ci.linaro.org/job/tcwg_kernel-gnu-bisect-gnu-master-aarch64-mainline-defconfig/24/artifact/artifacts/build-first_bad/05-build_linux/console.log/*view*/
[Bug target/98219] User-interrupt return pop corrupt RIP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98219 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from H.J. Lu --- Fixed for GCC 11.
[Bug target/98219] User-interrupt return pop corrupt RIP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98219 --- Comment #9 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:078c7498908d9b74caff34d12099b5c85470e277 commit r11-5939-g078c7498908d9b74caff34d12099b5c85470e277 Author: H.J. Lu Date: Wed Dec 9 18:14:24 2020 -0800 x86: Update user interrupt handler stack frame User interrupt handler stack frame is similar to exception interrupt handler stack frame. Instead of error code, the second argument is user interrupt request register vector. gcc/ PR target/98219 * config/i386/uintrintrin.h (__uintr_frame): Remove uirrv. gcc/testsuite/ PR target/98219 * gcc.dg/guality/pr98219-1.c: New test. * gcc.dg/guality/pr98219-2.c: Likewise. * gcc.dg/torture/pr98219-1.c: Likewise. * gcc.dg/torture/pr98219-2.c: Likewise. * gcc.target/i386/uintr-2.c: Scan "add[lq] $8, %[er]sp". (uword_t): New. (foo): Add a uword_t argument. (UINTR_hanlder): Likewise. * gcc.target/i386/uintr-3.c: Scan "add[lq] $8, %[er]sp". (uword_t): New. (UINTR_hanlder): Add a uword_t argument. * gcc.target/i386/uintr-4.c (uword_t): New. (UINTR_hanlder): Add a uword_t argument. * gcc.target/i386/uintr-5.c (uword_t): New. (UINTR_hanlder): Add a uword_t argument.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 78173, which changed state. Bug 78173 Summary: Hard error subtracting pointers to incomplete type in SFINAE context https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78173 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/78173] Hard error subtracting pointers to incomplete type in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78173 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|10.3|11.0 --- Comment #6 from Patrick Palka --- Fixed for GCC 11
[Bug c++/78173] Hard error subtracting pointers to incomplete type in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78173 --- Comment #5 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:958d42abdf1a1936d290aab126cebd6bb4a52361 commit r11-5936-g958d42abdf1a1936d290aab126cebd6bb4a52361 Author: Patrick Palka Date: Fri Dec 11 09:40:58 2020 -0500 c++: missing SFINAE with pointer subtraction [PR78173] This fixes a missed SFINAE when subtracting pointers to an incomplete type. gcc/cp/ChangeLog: PR c++/78173 * typeck.c (pointer_diff): Use complete_type_or_maybe_complain instead of complete_type_or_else. gcc/testsuite/ChangeLog: PR c++/78173 * g++.dg/cpp2a/concepts-pr78173.C: New test.
[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #19 from Richard Biener ---
(In reply to Segher Boessenkool from comment #18)
> Why is it correct to convert the double x to single precision here?!
For
float foo(float f, float x, float y) {
return (fabs(f)*x+y);
}
it is not unless when using FMA intermediate _overflow_ is also "ignored"
(as opposed to just performing one rounding step and thus requiring one bit
more precision).
Note that the set of inputs where it is errorneous (producing +-Inf rather than
a finite number) is small and thus it might fall into the realms of
-funsafe-math-optimizations (even a 1 ulp change can make a big difference
when in the divisor for example).
These kind of FP "optimizations" are always tricky.
[Bug fortran/97723] type bound ASSIGNMENT(=) within select rank block wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723 --- Comment #4 from Paul Thomas --- Please see PR97694 for a patch that fixes both PRs at once. Paul
[Bug fortran/97694] ICE with optional assumed rank class(*) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- I guess that it's mine :-) Paul
[Bug tree-optimization/96685] Failure to optimize not+sub to add+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96685 --- Comment #5 from Jakub Jelinek --- Ok, so for GENERIC it seems to be the associate: in fold_binary_loc that converts ~x + y created by this patch into (y - x) + 1, and we don't have an equivalent for that in GIMPLE. So, shall I restrict this match.pd optimization to #if GIMPLE only, or shall I canonicalize not to ~x + y but to (y - x) + 1, or should we implement the associate: optimization on GIMPLE? I guess the last one might be too much in stage3. I guess the middle option wouldn't help for the testcase in the patch, because we wouldn't canonicalize ~x + y to (y - x) + 1 and the first option would not consider ~x + y or ~(x - y) equivalent to user-written (y - x) + 1.
[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326 --- Comment #18 from Segher Boessenkool --- Why is it correct to convert the double x to single precision here?!
[Bug fortran/97694] ICE with optional assumed rank class(*) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #3 from Paul Thomas ---
Created attachment 49743
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49743&action=edit
Fix for this PR and PR97723
This regtests and fixes both PRs
Paul
select_rank_5.f90:
! { dg-do run }
!
! Test the fixes for PR97723 and PR97694.
!
! Contributed by Martin
!
module mod
implicit none
private
public cssel
contains
function cssel(x) result(s)
character(len=:), allocatable :: s
class(*), dimension(..), optional, intent(in) :: x
if (present(x)) then
select rank (x)
rank (0)
s = '0' ! PR97723: ‘assign’ at (1) is not a function
! PR97694: ICE in trans-stmt.c(trans_associate_var)
rank (1)
s = '1' ! PR97723: ‘assign’ at (1) is not a function
rank default
s = '?' ! PR97723: ‘assign’ at (1) is not a function
end select
else
s = '-'
end if
end function cssel
end module mod
program classstar_rank
use mod
implicit none
integer :: x
real, dimension(1:3) :: y
logical, dimension(1:2,1:2) :: z
if (any ([cssel(x),cssel(y),cssel(z),cssel()] .ne. ['0','1','?','-'])) stop 1
end program classstar_rank
[Bug tree-optimization/96685] Failure to optimize not+sub to add+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96685
--- Comment #4 from Jakub Jelinek ---
Though, there is some canonicalization problem GENERIC vs. GIMPLE:
unsigned
f1 (unsigned x, unsigned y)
{
unsigned int r = (x - y);
return ~r;
}
unsigned
f2 (unsigned x, unsigned y)
{
unsigned int r = ~(x - y);
return r;
}
unsigned
f3 (unsigned x)
{
unsigned int r = (x - 23);
return ~r;
}
unsigned
f4 (unsigned x)
{
unsigned int r = ~(x - 23);
return r;
}
int
f5 (int x, int y)
{
int r = (x - y);
return ~r;
}
int
f6 (int x, int y)
{
int r = ~(x - y);
return r;
}
int
f7 (int x)
{
int r = (x - 23);
return ~r;
}
int
f8 (int x)
{
int r = ~(x - 23);
return r;
}
Before the above patch, the above testcase emitted:
subl%esi, %edi
movl%edi, %eax
notl%eax
for f1/f2/f5/f6 and
leal-23(%rdi), %eax
notl%eax
for f3/f4/f7/f8.
With the patch it emits:
notl%edi
leal(%rdi,%rsi), %eax
for f1/f5/f6,
subl%edi, %esi
leal-1(%rsi), %eax
for f2,
notl%edi
leal23(%rdi), %eax
for f3/f7,
movl$22, %eax
subl%edi, %eax
for f4/f8.
[Bug tree-optimization/96685] Failure to optimize not+sub to add+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96685 --- Comment #3 from Jakub Jelinek --- Created attachment 49742 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49742&action=edit gcc11-pr96685.patch Untested fix.
[Bug testsuite/98245] [11 Regression] gcc.dg/vect/bb-slp-46.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98245 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Summary|gcc.dg/vect/bb-slp-46.c |[11 Regression] |FAILs |gcc.dg/vect/bb-slp-46.c ||FAILs Component|tree-optimization |testsuite Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-12-11 --- Comment #2 from Richard Biener --- Mine.
[Bug tree-optimization/98244] gcc.dg/vect/vect-live-6.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98244 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/98244] gcc.dg/vect/vect-live-6.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98244 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ab231af9ccd61b9b05ad35c04a79b32343904209 commit r11-5933-gab231af9ccd61b9b05ad35c04a79b32343904209 Author: Richard Biener Date: Fri Dec 11 13:45:55 2020 +0100 testsuite/98244 - amend gcc.dg/vect/vect-live-6.c Committed. 2020-12-11 Richard Biener PR testsuite/98244 * gcc.dg/vect/vect-live-6.c: Require vect_condition.
[Bug tree-optimization/98244] gcc.dg/vect/vect-live-6.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98244 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-12-11 Status|UNCONFIRMED |ASSIGNED
[Bug tree-optimization/98245] gcc.dg/vect/bb-slp-46.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98245 --- Comment #1 from Rainer Orth --- Created attachment 49741 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49741&action=edit 32-bit sparc-sun-solaris2.11 bb-slp-46.c.244t.optimized
[Bug tree-optimization/98245] gcc.dg/vect/bb-slp-46.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98245 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98245] New: gcc.dg/vect/bb-slp-46.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98245 Bug ID: 98245 Summary: gcc.dg/vect/bb-slp-46.c FAILs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 The gcc.dg/vect/bb-slp-46.c test FAIL on 32 and 64-bit sparc since the beginning: FAIL: gcc.dg/vect/bb-slp-46.c -flto -ffat-lto-objects scan-tree-dump-times optimized " + " 3 FAIL: gcc.dg/vect/bb-slp-46.c scan-tree-dump-times optimized " + " 3 Dump attached.
[Bug tree-optimization/98244] gcc.dg/vect/vect-live-6.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98244 --- Comment #1 from Rainer Orth --- Created attachment 49740 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49740&action=edit 32-bit sparc-sun-solaris2.11 vect-live-6.c.166t.vect
[Bug tree-optimization/98244] gcc.dg/vect/vect-live-6.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98244 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98244] New: gcc.dg/vect/vect-live-6.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98244 Bug ID: 98244 Summary: gcc.dg/vect/vect-live-6.c FAILs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 The gcc.dg/vect/vect-live-6.c test FAILs on sparc from the beginning: +FAIL: gcc.dg/vect/vect-live-6.c -flto -ffat-lto-objects scan-tree-dump vect "vectorized 1 loops" +FAIL: gcc.dg/vect/vect-live-6.c scan-tree-dump vect "vectorized 1 loops" Dump attached.
[Bug libstdc++/98226] Slow std::countr_one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226 Oleg Zaikin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #13 from Oleg Zaikin --- countr_one() should be used where it suits better.
[Bug tree-optimization/98243] gcc.dg/gomp/simd-2.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98243 --- Comment #1 from Rainer Orth --- Created attachment 49739 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49739&action=edit 32-bit sparc-sun-solaris2.11 simd-2.c.166t.vect
[Bug testsuite/98242] gcc.dg/vect/bb-slp-subgroups-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98242 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Richard Biener --- Fixed.
[Bug testsuite/98242] gcc.dg/vect/bb-slp-subgroups-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98242 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4b488a2e695b6868cfb69c65b8e2943ea31c335c commit r11-5932-g4b488a2e695b6868cfb69c65b8e2943ea31c335c Author: Richard Biener Date: Fri Dec 11 13:31:24 2020 +0100 testsuite/98242 - amend gcc.dg/vect/bb-slp-subgroups-3.c Committed. 2020-12-11 Richard Biener PR testsuite/98242 * gcc.dg/vect/bb-slp-subgroups-3.c: Require vect_int_mult.
[Bug tree-optimization/98243] gcc.dg/gomp/simd-2.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98243 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98243] New: gcc.dg/gomp/simd-2.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98243 Bug ID: 98243 Summary: gcc.dg/gomp/simd-2.c etc. FAIL Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 The new gcc.dg/gomp/simd-2.c and gcc.dg/gomp/simd-3.c tests FAIL on 32 and 64-bit sparc from the beginning: FAIL: gcc.dg/gomp/simd-2.c scan-tree-dump-times vect "vectorized [1-9][0-9]* loops in function" 5 FAIL: gcc.dg/gomp/simd-3.c scan-tree-dump-times vect "vectorized [1-9][0-9]* loops in function" 5 Dump attached.
[Bug testsuite/98242] gcc.dg/vect/bb-slp-subgroups-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98242 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-12-11 Status|UNCONFIRMED |ASSIGNED Component|tree-optimization |testsuite
[Bug tree-optimization/98242] gcc.dg/vect/bb-slp-subgroups-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98242 --- Comment #1 from Rainer Orth --- Created attachment 49738 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49738&action=edit 32-bit sparc-sun-solaris2.11 bb-slp-subgroups-3.c.178t.slp2
[Bug tree-optimization/98242] gcc.dg/vect/bb-slp-subgroups-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98242 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98242] New: gcc.dg/vect/bb-slp-subgroups-3.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98242 Bug ID: 98242 Summary: gcc.dg/vect/bb-slp-subgroups-3.c FAILs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 The new gcc.dg/vect/bb-slp-subgroups-3.c test FAILs on 32 and 64-bit SPARC: FAIL: gcc.dg/vect/bb-slp-subgroups-3.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "optimized: basic block" 2 FAIL: gcc.dg/vect/bb-slp-subgroups-3.c scan-tree-dump-times slp2 "optimized: basic block" 2 Dump attached.
[Bug testsuite/98240] [11 Regression] gcc.dg/vect/pr97678.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98240 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug testsuite/98240] [11 Regression] gcc.dg/vect/pr97678.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98240 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:0fc3bf781d15a9fa260395bd72472224f42e3ce1 commit r11-5931-g0fc3bf781d15a9fa260395bd72472224f42e3ce1 Author: Richard Biener Date: Fri Dec 11 13:23:21 2020 +0100 testsuite/98240 - amend gcc.dg/vect/pr97678.c Committed. 2020-12-11 Richard Biener PR testsuite/98240 * gcc.dg/vect/pr97678.c: Require vect_int_mult and vect_pack_trunc.
[Bug tree-optimization/96685] Failure to optimize not+sub to add+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96685 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I guess ~x + y as canonical form has another advantage, that + is commutative while - is not.
[Bug testsuite/98241] [11 regression] gcc.dg/pr78973.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98241 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug testsuite/98240] [11 Regression] gcc.dg/vect/pr97678.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98240 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Summary|gcc.dg/vect/pr97678.c FAILs |[11 Regression] ||gcc.dg/vect/pr97678.c FAILs Ever confirmed|0 |1 Component|tree-optimization |testsuite Last reconfirmed||2020-12-11 --- Comment #2 from Richard Biener --- OK, one reason is likely the required integer multiplication? The dump shows patterns used for that and those fail to SLP. And then we have note: ==> examining statement: _1 = (short unsigned int) i_29; missed: conversion not supported by target. so sparc doesn't support V2SI to V4HI packing. So we need both vect_int_mult and vect_pack_trunc.
[Bug testsuite/98241] New: [11 regression] gcc.dg/pr78973.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98241 Bug ID: 98241 Summary: [11 regression] gcc.dg/pr78973.c XPASSes Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- Between 20201020 (5d53ec27015b916640171e891870adf2c6fdfd4c) and 20201021 (c8f795cac6a1325bc6bcba3f47b7d04cb790400c), gcc.dg/pr78973.c began to XPASS: XPASS: gcc.dg/pr78973.c pr79073 (test for warnings, line 12) I'm seeing this on 32-bit Solaris/sparc and x86 as well as 32-bit Linux/x86. I suspect the xfail can just go?
[Bug libstdc++/98226] Slow std::countr_one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226 --- Comment #12 from Oleg Zaikin --- (In reply to Alexander Monakov from comment #10) > But why you are trying to use a more complex branchy expression in C++17 > mode when you already have a more efficient expression as a "fallback"? > > Note that a cheaper way is available: > > return (x+1) & ~x; > > (though gcc can optimize '(y ^ x) & y' you have to the same machine code) Thank you! We will try it.
[Bug ipa/98237] gcc-dg-lto-modref-3-01.exe etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98237 --- Comment #1 from Rainer Orth --- It's not just the scans that fail: FAIL: gcc.dg/lto/modref-3 c_lto_modref-3_0.o-c_lto_modref-3_1.o execute -O2 -flto-partition=max -fdump-ipa-modref -fno-ipa-sra -fno-ipa-cp -flto FAIL: gcc.dg/lto/modref-4 c_lto_modref-4_0.o-c_lto_modref-4_1.o execute -O2 -flto-partition=max -fdump-ipa-modref -fno-ipa-sra -flto
[Bug libstdc++/98226] Slow std::countr_one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226 --- Comment #11 from Oleg Zaikin --- (In reply to Jonathan Wakely from comment #8) > That needs to be investigated, but it's a problem with the compiler. It has > nothing to do with countr_one being implemented using countr_zero (as shown > by the same problem being present when calling __builtin_ctz directly). Thank you for the detailed clarification!
[Bug testsuite/98239] [11 Regression] gcc.dg/vect/bb-slp-69.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98239 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- And fixed.
[Bug tree-optimization/97494] [11 regression] several vector test case failures starting with r11-3966
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97494 Rainer Orth changed: What|Removed |Added Build|powerpc64*-linux-gnu| Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu, ||sparc-sun-solaris2.11 CC||ro at gcc dot gnu.org Host|powerpc64*-linux-gnu| --- Comment #3 from Rainer Orth --- Also seen on 32 and 64-bit sparc.
[Bug testsuite/98239] [11 Regression] gcc.dg/vect/bb-slp-69.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98239 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:955af69b7376ebd05051c02455d71c90258f5e24 commit r11-5930-g955af69b7376ebd05051c02455d71c90258f5e24 Author: Richard Biener Date: Fri Dec 11 13:13:28 2020 +0100 testsuite/98239 - require vect_condition for gcc.dg/vect/bb-slp-69.c Committed. 2020-12-11 Richard Biener PR testsuite/98239 * gcc.dg/vect/bb-slp-69.c: Require vect_condition.
[Bug tree-optimization/98240] gcc.dg/vect/pr97678.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98240 --- Comment #1 from Rainer Orth --- Created attachment 49737 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49737&action=edit 32-bit sparc-sun-solaris2.11 pr97678.c.166t.vect
[Bug testsuite/98239] [11 Regression] gcc.dg/vect/bb-slp-69.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98239 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Summary|gcc.dg/vect/bb-slp-69.c |[11 Regression] |FAILs |gcc.dg/vect/bb-slp-69.c ||FAILs Last reconfirmed||2020-12-11 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Component|tree-optimization |testsuite --- Comment #2 from Richard Biener --- Guess vect_int doesn't guarantee a way to do VnQImode != 0 ? 1 : 0 I see vect_condition where sparc is not part of.
[Bug tree-optimization/98240] gcc.dg/vect/pr97678.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98240 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98240] New: gcc.dg/vect/pr97678.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98240 Bug ID: 98240 Summary: gcc.dg/vect/pr97678.c FAILs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11, armeb-none-linux-gnueabihf The new gcc.dg/vect/pr97678.c tests FAILs on 32 and 64-bit SPARC: FAIL: gcc.dg/vect/pr97678.c -flto -ffat-lto-objects scan-tree-dump vect "vectorizing stmts using SLP" FAIL: gcc.dg/vect/pr97678.c scan-tree-dump vect "vectorizing stmts using SLP" There are reports for armeb on gcc-testresults, too. Dump attached.
[Bug tree-optimization/98239] gcc.dg/vect/bb-slp-69.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98239 --- Comment #1 from Rainer Orth --- Created attachment 49736 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49736&action=edit 32-bit sparc-sun-solaris2.11 bb-slp-69.c.178t.slp2
[Bug tree-optimization/98239] gcc.dg/vect/bb-slp-69.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98239 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98239] New: gcc.dg/vect/bb-slp-69.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98239 Bug ID: 98239 Summary: gcc.dg/vect/bb-slp-69.c FAILs Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11 The new gcc.dg/vect/bb-slp-69.c tests FAILs on 32 and 64-bit sparc: FAIL: gcc.dg/vect/bb-slp-69.c -flto -ffat-lto-objects scan-tree-dump slp2 "transform load" FAIL: gcc.dg/vect/bb-slp-69.c scan-tree-dump slp2 "transform load" Dump attached.
[Bug middle-end/98227] [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'constructor' in get_section, at varasm.c:297 on riscv64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98227 --- Comment #3 from H.J. Lu --- Please try: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561484.html
[Bug tree-optimization/98238] gcc.dg/vect/vect-cost-model-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98238 --- Comment #1 from Rainer Orth --- Created attachment 49735 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49735&action=edit 32-bit sparc-sun-solaris2.11 vect-cost-model-1.c.166t.vect
[Bug tree-optimization/98238] gcc.dg/vect/vect-cost-model-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98238 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/98238] New: gcc.dg/vect/vect-cost-model-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98238 Bug ID: 98238 Summary: gcc.dg/vect/vect-cost-model-1.c etc. FAIL Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rsandifo at gcc dot gnu.org Target Milestone: --- Target: sparc*-*-solaris2.11, ia64-suse-linux-gnu, armeb-none-linux-gnueabihf, powerpc-apple-darwin9 Several of the the new vect-cost-model-?.c tests FAIL on several targets: FAIL: gcc.dg/vect/vect-cost-model-1.c -flto -ffat-lto-objects scan-tree-dump vect "LOOP VECTORIZED" FAIL: gcc.dg/vect/vect-cost-model-1.c scan-tree-dump vect "LOOP VECTORIZED" FAIL: gcc.dg/vect/vect-cost-model-3.c -flto -ffat-lto-objects scan-tree-dump vect "LOOP VECTORIZED" FAIL: gcc.dg/vect/vect-cost-model-3.c scan-tree-dump vect "LOOP VECTORIZED" FAIL: gcc.dg/vect/vect-cost-model-5.c -flto -ffat-lto-objects scan-tree-dump vect "LOOP VECTORIZED" FAIL: gcc.dg/vect/vect-cost-model-5.c scan-tree-dump vect "LOOP VECTORIZED" I'm seeing this on 32 and 64-bit Solaris/sparc, but gcc-testresults postings show several other affected targets.
[Bug ipa/98237] gcc-dg-lto-modref-3-01.exe etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98237 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug ipa/98237] New: gcc-dg-lto-modref-3-01.exe etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98237 Bug ID: 98237 Summary: gcc-dg-lto-modref-3-01.exe etc. FAIL Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Two new ipa-modref tests FAIL since they were installed: FAIL: gcc-dg-lto-modref-3-01.exe scan-wpa-ipa-dump modref "parm 1 flags: nodirectescape" FAIL: gcc-dg-lto-modref-4-01.exe scan-wpa-ipa-dump modref "parm 1 flags: nodirectescape" I'm seeing this on Solaris/sparc and x86, there are also gcc-testresults reports for hppa64-hp-hpux11.11. However, this is not an OS issue at all: on Solaris with GNU ld, the tests PASS, while they FAIL on x86_64-pc-linux-gnu with --disable-lto-plugin.
