[Bug target/99754] [sse2] new _mm_loadu_si16 and _mm_loadu_si32 implemented incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99754 --- Comment #1 from Hongtao.liu --- Yes, __mm_set_epi32 will reverse order of parameters, Could you send out a patch for review?
[Bug fortran/99761] New: Warn flag for non-kind specified mixing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99761 Bug ID: 99761 Summary: Warn flag for non-kind specified mixing Product: gcc Version: fortran-dev Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nickpapior at gmail dot com Target Milestone: --- Some context here: https://github.com/j3-fortran/fortran_proposals/issues/201 The basic message is that users may forget to add kind specifications for constants which are assigned to higher precision values which then loses the extra bits. Simplest example: real(8), parameter :: pi = 3.14159265358979323846 which actually only stores the floating point value and store that in a double precision variable, thereby loosing precision. My proposal would be to add a flag which warns about misused kinds: program test real(8), parameter :: const = 1.4435435345345 real(8), parameter :: const2 = 1./3. real(8), parameter :: const3 = 1._4/4._4 print *, 1./3. * const end program test it would be nice if the above could be compiled with gfortran -Wpedantic-kind and something like this would be issued: 2 |real(8), parameter :: const = 1.4435435345345 1 Warning: Constant expression at (1) is in lower precision than variable. 3 |real(8), parameter :: const2 = 1./3. 1 Warning: Constant expression at (1) is in lower precision than variable. 3 |real(8), parameter :: const2 = 1./3. 1 Warning: Constant expression at (1) is in lower precision than variable. 5 |print *, 1./3. * const 1 2 Warning: Constant at (1) has lower precision than variable at (2) Line 4 is silently ignored due to explicit kind specification. I think such an enhancement would be extremely useful to hunt down mis-typed kind specifiers.
[Bug other/99763] New: c++filt crashes when demangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99763 Bug ID: 99763 Summary: c++filt crashes when demangling Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: bajinsheng at outlook dot com Target Milestone: --- the payload to trigger the crash The bug is about segment fault, which may be caused by endless loop. Source code repository: git://sourceware.org/git/binutils-gdb.git commit: 12af5ebd820425e8ad843a1dac687a2fffc4a2e3 Date: Tue Mar 23 00:00:07 2021 + Compiler: Clang-12 OS: Ubuntu 16.04.7 LTS The call stack of the bug: #0 0x004beff1 in demangle_path (rdm=rdm@entry=0x7ffe5ead2850, in_value=in_value@entry=1) at ./rust-demangle.c:664 #1 0x004bf4d8 in demangle_path (rdm=rdm@entry=0x7ffe5ead2850, in_value=in_value@entry=1) at ./rust-demangle.c:774 ……….. #52364 0x004bf4d8 in demangle_path (rdm=rdm@entry=0x7ffe5ead2850, in_value=in_value@entry=1) at ./rust-demangle.c:774 #52365 0x004bf4d8 in demangle_path (rdm=rdm@entry=0x7ffe5ead2850, in_value=in_value@entry=1) at ./rust-demangle.c:774 #52366 0x004be5f0 in rust_demangle_callback (mangled=, options=267, callback=, opaque=0x7ffe5ead28d0) at ./rust-demangle.c:1400 #52367 0x004bf8d2 in rust_demangle (mangled=0x7ffe5ead2850 "\302sq", options=1) at ./rust-demangle.c:1511 #52368 0x004a4a0d in cplus_demangle (mangled=0x7173c0 "_RB_R", options=267) at ./cplus-dem.c:166 I upload the payload to reproduce the bug: cat payload | ./c++filt
[Bug other/99762] c++filt crashes with specific inpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99762 Ba Jinsheng changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Ba Jinsheng --- The duplicate one. *** This bug has been marked as a duplicate of bug 99763 ***
[Bug other/99763] c++filt crashes when demangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99763 --- Comment #1 from Ba Jinsheng --- *** Bug 99762 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/99755] failure to fold a conditional that's a subset of another expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99755 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Blocks||85316 Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-25 --- Comment #1 from Richard Biener --- Confirmed. We have no good notion of predicate combinations, their "range" or how other ranges depend on predicates. It would be interesting to see how LLVM arrives at a folded f2(). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug other/99762] New: c++filt crashes with specific inpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99762 Bug ID: 99762 Summary: c++filt crashes with specific inpu Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: bajinsheng at outlook dot com Target Milestone: ---
[Bug target/96582] aarch64:ICE during GIMPLE pass: veclower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96582 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #3 from ktkachov at gcc dot gnu.org --- I don't see it ICEing with recent trunk anymore. Can this be closed?
[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99746 --- Comment #16 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:a29124d28253cdf603ba1977db2f09c9f233fea5 commit r11-7822-ga29124d28253cdf603ba1977db2f09c9f233fea5 Author: Richard Biener Date: Wed Mar 24 12:55:16 2021 +0100 tree-optimization/99746 - avoid confusing hybrid code This avoids confusing the hybrid vectorization code with SLP patterns by not marking SLP pattern covered stmts as patterns (they are marked as SLP patterns already). This means that loop vectorization will vectorize the scalar stmt rather than the SLP pattern stmt (which it can't anyway). 2021-03-24 Richard Biener PR tree-optimization/99746 * tree-vect-slp-patterns.c (complex_pattern::build): Do not mark the scalar stmt as patterned. Instead set up required things manually. * gfortran.dg/vect/pr99746.f90: New testcase.
[Bug tree-optimization/99746] [11 Regression] ICE in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99746 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Richard Biener --- Fixed.
[Bug target/99764] New: ICE in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99764
Bug ID: 99764
Summary: ICE in extract_insn, at recog.c:2770
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: arm-linux-gnueabi
The following fails:
$ cat bf16.c
void foo(__bf16 b) {}
$ arm-linux-gnueabi-gcc bf16.c -c -mcpu=cortex-m1.small-multiply
bf16.c: In function ‘foo’:
bf16.c:1:21: error: unrecognizable insn:
1 | void foo(__bf16 b) {}
| ^
(insn 3 2 4 2 (set (mem/c:BF (reg/f:SI 113) [1 b+0 S2 A16])
(reg:BF 0 r0 [ b ])) "bf16.c":1:20 -1
(nil))
during RTL pass: vregs
bf16.c:1:21: internal compiler error: in extract_insn, at recog.c:2770
0x5fea13 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/rtl-error.c:108
0x5fea2f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/rtl-error.c:116
0x5fdea6 extract_insn(rtx_insn*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/recog.c:2770
0x89833f instantiate_virtual_regs_in_insn
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/function.c:1609
0x89833f instantiate_virtual_regs
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/function.c:1983
0x89833f execute
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/function.c:2032
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/99765] New: Explicit dimension size declaration of pointer array allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99765 Bug ID: 99765 Summary: Explicit dimension size declaration of pointer array allowed Product: gcc Version: 4.8.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nickpapior at gmail dot com Target Milestone: --- A mishandling of variable declarations Consider this program: program test real, dimension(10), pointer :: a(:) => null() print *, associated(a) allocate(a(2)) print *, size(a) !print *, size(a(1)) ! obviously fails as a(1) is a scalar end program test It is ambiguous to determine the size of a. The programmer may think that after allocation one has 2x10 elements a(1:2)(1:10) however what is happening is that the dimension(10) attribute is completely ignored. I can't find anywhere in the standard mentioning that this way of definition is wrong, but I think it clearly shouldn't be allowed. I.e. it is unclear whether the user wants a(1:2)(1:10) or a(1:10)(1:2), in any case neither of the results are achieved. I found this bug in 4.8.4 and also in 9.3.0, so I assume it exists in all in between. A few more cases that resemble this: real, dimension(10), allocatable :: a(:) behaves exactly like with pointers. It is not well-defined and gets to the a(1:2) case. real, dimension(10), allocatable :: a(10) rightfully errors out on compilation with a somewhat unclear error message 3 | real, dimension(10) :: a(10) | 1 Error: Symbol ‘a’ at (1) already has basic type of REAL
[Bug target/96582] aarch64:ICE during GIMPLE pass: veclower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96582 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- I guess so.
[Bug other/99763] c++filt crashes when demangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99763 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-03-25 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #2 from Martin Liška --- We likely miss the payload, right?
[Bug target/99766] New: ICE: unable to generate reloads with SVE code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766
Bug ID: 99766
Summary: ICE: unable to generate reloads with SVE code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
#include
#include
typedef float b __attribute__((__mode__(HF)));
typedef struct {
b c;
b d;
} e;
int f;
e *g;
void l(int s) {
std::vector m(s);
for (; f;) {
auto a = &g[0];
for (int i;; ++i) {
int n = i;
auto o = &a[n];
auto p = &m[i];
float16_t q;
for (int k; k < s;)
for (int j; j < i; ++j) {
auto r = o;
for (k = 0; k < s; ++k)
p[k].c = r[k].c * r[k].d;
}
for (int k; k < s; ++k) {
p[k].c *= q;
p[k].d *= q;
}
}
}
}
With -std=c++17 -O3 -march=armv8.5-a+sve2 ICEs with:
ice.c: In function 'void l(int)':
ice.c:31:1: error: unable to generate reloads for:
31 | }
| ^
(insn 312 308 326 39 (set (subreg:VNx4SI (reg:VNx8HF 105 [ _17 ]) 0)
(unspec:VNx4SI [
(subreg:VNx4BI (reg:VNx16BI 365) 0)
(vec_duplicate:VNx4SI (mem/c:SI (plus:DI (reg/f:DI 64 sfp)
(const_int 272 [0x110])) [12 S4 A128]))
(const_vector:VNx4SI [
(const_int 0 [0])
])
] UNSPEC_SEL)) 4825 {sve_ld1rvnx4si}
(nil))
during RTL pass: reload
This seems to be very recent. A trunk from 23 March doesn't ICE
[Bug target/99766] [11 Regression] ICE: unable to generate reloads with SVE code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |11.0 Priority|P3 |P1 Known to work||10.2.1 Summary|ICE: unable to generate |[11 Regression] ICE: unable |reloads with SVE code |to generate reloads with ||SVE code Known to fail||11.0
[Bug fortran/99369] [10/11 Regression] ICE in gfc_resolve_expr, at fortran/resolve.c:7167
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99369 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:c884ac1e743dbaaa5eea89ef95d5b987e66a28cb commit r10-9542-gc884ac1e743dbaaa5eea89ef95d5b987e66a28cb Author: Tobias Burnus Date: Wed Mar 24 07:50:22 2021 +0100 Fortran: Extend buffer, use snprintf to avoid overflows [PR99369] gcc/fortran/ChangeLog: PR fortran/99369 * resolve.c (resolve_operator): Make 'msg' buffer larger and use snprintf. gcc/testsuite/ChangeLog: PR fortran/99369 * gfortran.dg/longnames.f90: New test. (cherry picked from commit b179026a5d9fcadadef6ca511933933672557495)
[Bug fortran/99369] [10/11 Regression] ICE in gfc_resolve_expr, at fortran/resolve.c:7167
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99369 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||burnus at gcc dot gnu.org --- Comment #7 from Tobias Burnus --- FIXED on mainline (GCC 11) and GCC 10. Thanks for the report!
[Bug target/99766] [11 Regression] ICE: unable to generate reloads with SVE code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766
Alex Coplan changed:
What|Removed |Added
Last reconfirmed||2021-03-25
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||acoplan at gcc dot gnu.org
--- Comment #1 from Alex Coplan ---
Confirmed. Here is a testcase without the includes:
typedef float a __attribute__((__mode__(HF)));
typedef struct {
a b;
a c;
} d;
int e;
d *f, *g;
__fp16 h;
void j() {
for (int i;; ++i) {
auto l = &f[i];
for (int k; k < e;) {
k = 0;
for (; k < e; ++k)
g[k].b = l[k].b * l[k].c;
}
for (int k; k < e; ++k) {
g[k].b *= h;
g[k].c *= h;
}
}
}
[Bug target/99766] [11 Regression] ICE: unable to generate reloads with SVE code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766 --- Comment #2 from Alex Coplan --- The above ICEs with just -O3 -march=armv8.2-a+sve.
[Bug other/99763] c++filt crashes when demangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99763 --- Comment #3 from Ba Jinsheng --- Created attachment 50471 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50471&action=edit the payload to trigger the crash
[Bug other/99763] c++filt crashes when demangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99763 --- Comment #4 from Ba Jinsheng --- (In reply to Martin Liška from comment #2) > We likely miss the payload, right? Uploaded
[Bug other/99763] c++filt crashes when demangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99763 --- Comment #5 from Martin Liška --- (In reply to Ba Jinsheng from comment #3) > Created attachment 50471 [details] > the payload to trigger the crash Is it a valid symbol name? How did you come up with the name?
[Bug other/99763] c++filt crashes when demangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99763 --- Comment #6 from Ba Jinsheng --- (In reply to Martin Liška from comment #5) > (In reply to Ba Jinsheng from comment #3) > > Created attachment 50471 [details] > > the payload to trigger the crash > > Is it a valid symbol name? How did you come up with the name? Should be not. I got this payload by fuzzing.
[Bug fortran/93660] Decl mismatch between fndecl TYPE and used arglist / ICE in ipa_simd_modify_function_body, at omp-simd-clone.c:993
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93660 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:3e34bdeaf3b9c294fa8a2b15d5efc866f377b264 commit r10-9543-g3e34bdeaf3b9c294fa8a2b15d5efc866f377b264 Author: Tobias Burnus Date: Tue Mar 23 15:45:36 2021 +0100 Fortran: Fix func decl mismatch [PR93660] gcc/fortran/ChangeLog: PR fortran/93660 * trans-decl.c (build_function_decl): Add comment; increment hidden_typelist for caf_token/caf_offset. * trans-types.c (gfc_get_function_type): Add comment; add missing caf_token/caf_offset args. gcc/testsuite/ChangeLog: PR fortran/93660 * gfortran.dg/gomp/declare-simd-coarray-lib.f90: New test. (cherry picked from commit 212f4988f37ccf788c8c72b1dc952980bc9be3b7)
[Bug other/99763] c++filt crashes when demangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99763 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #7 from Martin Liška --- > I got this payload by fuzzing. I see. It's unlikely we'll fix such cases, the name is complete garbage.
[Bug other/99763] c++filt crashes when demangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99763 Martin Liška changed: What|Removed |Added Status|WAITING |NEW
[Bug other/99763] c++filt crashes when demangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99763 --- Comment #8 from Ba Jinsheng --- (In reply to Martin Liška from comment #7) > > I got this payload by fuzzing. > > I see. It's unlikely we'll fix such cases, the name is complete garbage. Even it is an invalid symbol, the c++filt will crash. Shouldn't we handle these exceptions?
[Bug fortran/99761] Warn flag for non-kind specified mixing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99761 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Dominique d'Humieres --- Try -Wconversion-extra.
[Bug fortran/99761] Warn flag for non-kind specified mixing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99761 --- Comment #2 from Nick --- Amazing, years of using gfortran and you still find useful flags! Thanks!
[Bug target/99766] [11 Regression] ICE: unable to generate reloads with SVE code since r11-7807-gbe70bb5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766 Alex Coplan changed: What|Removed |Added Summary|[11 Regression] ICE: unable |[11 Regression] ICE: unable |to generate reloads with|to generate reloads with |SVE code|SVE code since ||r11-7807-gbe70bb5e CC||vmakarov at gcc dot gnu.org --- Comment #3 from Alex Coplan --- Started with r11-7807-gbe70bb5e4babdf9d3d33e8f4658452038407fa8e: commit be70bb5e4babdf9d3d33e8f4658452038407fa8e Author: Vladimir N. Makarov Date: Tue Mar 23 17:51:21 2021 -0400 [PR99581] Use relaxed memory for more aarch64 memory constraints The original patch for PR99581 resulted in GCC testsuite regression as some constraints were not declared as relaxed memory ones. This patch fixes this.
[Bug target/99767] New: [9/10/11 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:3360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99767
Bug ID: 99767
Summary: [9/10/11 Regression] ICE in expand_direct_optab_fn, at
internal-fn.c:3360
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
gcc-11.0.1-alpha20210321 snapshot (g:fc24ea2374259d401a46ce3526688b7e79d4cc13)
ICEs when compiling the following testcase w/ -march=armv8-a+sve -O1
-fno-tree-dce:
int __attribute__ ((simd))
foo (void)
{
int v = 1 / 0;
return 0;
}
% aarch64-linux-gnu-gcc-11.0.1 -march=armv8-a+sve -O1 -fno-tree-dce -w -c
yiptql8b.c
during RTL pass: expand
yiptql8b.c: In function 'foo.simdclone.1':
yiptql8b.c:4:7: internal compiler error: in expand_direct_optab_fn, at
internal-fn.c:3360
4 | int v = 1 / 0;
| ^
0x70a2a1 expand_direct_optab_fn
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/internal-fn.c:3360
0xa15697 expand_call_stmt
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/cfgexpand.c:2749
0xa15697 expand_gimple_stmt_1
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/cfgexpand.c:3844
0xa15697 expand_gimple_stmt
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/cfgexpand.c:4008
0xa1b41a expand_gimple_basic_block
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/cfgexpand.c:6045
0xa1cfbf execute
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210321/work/gcc-11-20210321/gcc/cfgexpand.c:6729
[Bug c++/99686] ICE when using both concepts and full specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686
--- Comment #3 from Steven Sun ---
@W E Brown: I got your idea. So are all uses like this ill-formed? This seems
unexpected for me. I would expect the complete specialization is full
specialization for both primary templates.
I also find facts that support your idea:
If I modify the full specialization to
template <>
void func (int&& arg){}
It compiles. See https://godbolt.org/z/fh9Mx7Krr
If I modify the full specialization to
template <>
void func (int&& arg){}
It produce the same ICE output as comment 1. See
https://godbolt.org/z/eMa5YcrrE
It looks like the compiler doesn't knows which primary template to specialize.
I look up in the C++20 standard, and did not find anything about 2 primary
templates exists.
The code in Comment 1 compiles for g++ 6.1 to 9.3, then breaks since 10.1 (all
under -std=c++17 -fconcepts).
In conclusion, this makes sences but I didn't see that coming. Anyway, I think
a possible improvement is make ICE to an error of "ambigous full
specialization". Or even better, a change in C++23 standard.
[Bug fortran/99765] Explicit dimension size declaration of pointer array allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99765 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-03-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- The standard says: C832 An array with the POINTER or ALLOCATABLE attribute shall have an array-spec that is a deferred-shape-spec-list. so I think real, dimension(10), pointer :: a(:) => null() and real, dimension(10), allocatable :: a(10) are invalid and shall give an error. Note that a(1:2)(1:10) looks like C syntax, a rank 2 array is a(1:2,1:10). The only case for valid fortran is for a being of type CHARACTER, a(1;2) being a slice and (1:10) a substring.
[Bug c/99768] New: [11 Regression] Bogus -Wuninitialized diagnostic with type punning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99768
Bug ID: 99768
Summary: [11 Regression] Bogus -Wuninitialized diagnostic with
type punning
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
For the following code (which has a strict aliasing violation):
float foo(unsigned v)
{
unsigned tmp = v;
float *f = (float *)(&tmp);
return *f;
}
at -O2 -Wall we warn that tmp is used uninitialized:
test.c: In function ‘foo’:
test.c:5:12: warning: ‘tmp’ is used uninitialized [-Wuninitialized]
5 | return *f;
|^~
test.c:3:14: note: ‘tmp’ declared here
3 | unsigned tmp = v;
| ^~~
but this is clearly bogus. Not sure if this is strictly considered a bug given
the strict aliasing problem, but thought it might be worth checking in any
case.
[Bug fortran/99765] Explicit dimension size declaration of pointer array allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99765 --- Comment #2 from Nick --- Thanks for finding that in the standard!
[Bug c++/99734] [modules] ICE in most_specialized_instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99734 --- Comment #2 from Alexander Lelyakin --- Not reproduced anymore. The first case has changed diagnostic to: wrong number of template arguments (1, should be 2) [99274] The second case has changed diagnostic to: non-template type ‘rebind_alloc’ used as a template [99735]
[Bug target/99767] [9/10/11 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:3360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99767
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.4
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2021-03-25
--- Comment #1 from Richard Biener ---
OMP lowering makes the dead division conditional and we produce and want to
expand
;; basic block 2, loop depth 0
;;pred: ENTRY
MEM [(int *)&mask.4] = mask.5_9(D);
vect__5.21_31 = .MASK_LOAD (&mask.4, 32B, { -1, -1, 0, 0, ... });
_5 = mask.4[0];
mask__26.22_33 = vect__5.21_31 != { 0, ... };
_26 = _5 != 0;
v_1 = .COND_DIV (_26, 1, 0, 1);
vec_mask_and_37 = mask__26.22_33 & { -1, -1, 0, 0, ... };
.MASK_STORE (&retval.3, 32B, vec_mask_and_37, { 0, ... });
vectp_mask.19_29 = &mask.4 + POLY_INT_CST [16, 16];
vectp_retval.23_36 = &retval.3 + POLY_INT_CST [16, 16];
_6 = VIEW_CONVERT_EXPR(retval.3);
return _6;
;;succ: EXIT
but that's still scalar, so sth forgot to "vectorize" it? Indeed when
returning 'v' we instead get
_26 = _5 != 0;
vec_mask_and_37 = mask__26.34_33 & { -1, -1, -1, -1, 0, 0, 0, 0, ... };
vect_v_1.35_38 = .COND_DIV (vec_mask_and_37, { 1, ... }, { 0, ... }, { 1, ...
});
.MASK_STORE (&retval.9, 32B, vec_mask_and_37, vect_v_1.35_38);
The .COND_DIV is generated by if-conversion which supposedly expects we
will vectorize it (or throw it away) but it doesn't ignore (as the vectorizer)
obviously dead stmts. So the bug is this disconnect between if-conversion
and vectorization.
[Bug target/99767] [9/10/11 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:3360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99767 Richard Biener changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code Priority|P3 |P2
[Bug target/99555] [OpenMP/nvptx] Execution-time hang for simple nested OpenMP 'target'/'parallel'/'task' constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555 --- Comment #2 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:d99111fd8e12deffdd9a965ce17e8a760d531ec3 commit r11-7824-gd99111fd8e12deffdd9a965ce17e8a760d531ec3 Author: Thomas Schwinge Date: Thu Mar 11 17:01:22 2021 +0100 Avoid OpenMP/nvptx execution-time hangs for simple nested OpenMP 'target'/'parallel'/'task' constructs [PR99555] ... awaiting proper resolution, of course. libgomp/ PR target/99555 * testsuite/lib/on_device_arch.c: New file. * testsuite/libgomp.c/pr99555-1.c: Likewise. * testsuite/libgomp.c-c++-common/task-detach-6.c: Until resolved, skip for nvptx offloading, with error status. * testsuite/libgomp.fortran/task-detach-6.f90: Likewise.
[Bug target/99758] ICE in setup_preferred_alternate_classes_for_new_pseudos, at ira.c:2772
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99758 Alex Coplan changed: What|Removed |Added CC||acoplan at gcc dot gnu.org, ||wilco at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-25 Ever confirmed|0 |1 --- Comment #1 from Alex Coplan --- Confirmed. Started with r7-1850-ge4bbb037670323fbc578b6bc68cfb5252f1bf0cc: commit e4bbb037670323fbc578b6bc68cfb5252f1bf0cc Author: Wilco Dijkstra Date: Wed Jul 6 13:17:23 2016 + This patch improves the accuracy of the Cortex-A53 integer scheduler...
[Bug c++/99769] New: [modules] internal compiler error: in tree_node, at cp/module.cc:9105 when compile module partitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99769
Bug ID: 99769
Summary: [modules] internal compiler error: in tree_node, at
cp/module.cc:9105 when compile module partitions
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: owt5008137 at live dot com
Target Milestone: ---
Compiling modules with partitions always failed.The commands and files to
reproduce this are below:
$ /opt/gcc-latest/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-latest/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc-latest/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/opt/gcc-latest --enable-languages=c,c++
--enable-libstdcxx-debug --disable-bootstrap --disable-multilib
--disable-libvtv --with-system-zlib --without-isl --enable-multiarch
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210321 (experimental) (GCC)
$ cat foo-types.ixx
module;
export module foo:types;
export class CDerived;
$ cat foo-test.ixx
module;
#include
#include
export module foo:test;
import :types;
export class Bar {
public:
virtual ~Bar() = default;
virtual void visit() {
std::cout << "Bar::visit -> "<< typeid(*this).name() << std::endl;
}
};
$ cat foo.ixx
module;
export module foo;
export import :types;
export import :test;
$ /opt/gcc-latest/bin/g++ -fmodules-ts -std=c++20 -x c++ -c foo-types.ixx -o
foo-types.o
$ /opt/gcc-latest/bin/g++ -fmodules-ts -std=c++20 -x c++ -c foo-test.ixx -o
foo-test.o
$ /opt/gcc-latest/bin/g++ -fmodules-ts -std=c++20 -x c++ -c foo.ixx -o foo.o
foo.ixx:3:8: internal compiler error: in tree_node, at cp/module.cc:9105
3 | export module foo;
|^~
0x8af602 trees_out::tree_node(tree_node*)
../../gcc/cp/module.cc:9105
0x8b0460 trees_out::core_vals(tree_node*)
../../gcc/cp/module.cc:5908
0x8b5009 trees_out::tree_node_vals(tree_node*)
../../gcc/cp/module.cc:7049
0x8b5009 trees_out::tree_value(tree_node*)
../../gcc/cp/module.cc:8936
0x8af522 trees_out::tree_node(tree_node*)
../../gcc/cp/module.cc:9134
0x8b0460 trees_out::core_vals(tree_node*)
../../gcc/cp/module.cc:5908
0x8b5009 trees_out::tree_node_vals(tree_node*)
../../gcc/cp/module.cc:7049
0x8b5009 trees_out::tree_value(tree_node*)
../../gcc/cp/module.cc:8936
0x8af522 trees_out::tree_node(tree_node*)
../../gcc/cp/module.cc:9134
0x8b0460 trees_out::core_vals(tree_node*)
../../gcc/cp/module.cc:5908
0x8b5009 trees_out::tree_node_vals(tree_node*)
../../gcc/cp/module.cc:7049
0x8b5009 trees_out::tree_value(tree_node*)
../../gcc/cp/module.cc:8936
0x8af522 trees_out::tree_node(tree_node*)
../../gcc/cp/module.cc:9134
0x8b0460 trees_out::core_vals(tree_node*)
../../gcc/cp/module.cc:5908
0x8b5009 trees_out::tree_node_vals(tree_node*)
../../gcc/cp/module.cc:7049
0x8b5009 trees_out::tree_value(tree_node*)
../../gcc/cp/module.cc:8936
0x8af522 trees_out::tree_node(tree_node*)
../../gcc/cp/module.cc:9134
0x8b0460 trees_out::core_vals(tree_node*)
../../gcc/cp/module.cc:5908
0x8b5009 trees_out::tree_node_vals(tree_node*)
../../gcc/cp/module.cc:7049
0x8b5009 trees_out::tree_value(tree_node*)
../../gcc/cp/module.cc:8936
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/99770] New: gcc gives warning being treated as error on arm platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99770 Bug ID: 99770 Summary: gcc gives warning being treated as error on arm platform Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: chauhann at synopsys dot com Target Milestone: --- I am trying to compile a file on aarch64 ARM platform but got error as follows: SCompile.cxx: In constructor ‘SValidityCheck::SValidityCheck()’: 2361 SCompile.cxx:544:60: error: passing NULL to non-pointer argument 1 of ‘std::unordered_set<_Value, _Hash, _Pred, _Alloc>::unordered_set(std::unord ered_set<_Value, _Hash, _Pred, _Alloc>::size_type, const hasher&, const key_equal&, const allocator_type&) [-Werror=conversion-null] cc1plus: all warnings being treated as errors However, this doesn't give any error or warning on linux64 and compiles just fine. Is this a bug in gcc on arm? gcc version being used here on both platform (linux64 and aarch64) is 7.3.
[Bug target/99758] ICE in setup_preferred_alternate_classes_for_new_pseudos, at ira.c:2772
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99758 --- Comment #2 from Wilco --- (In reply to Alex Coplan from comment #1) > Confirmed. Started with r7-1850-ge4bbb037670323fbc578b6bc68cfb5252f1bf0cc: > > commit e4bbb037670323fbc578b6bc68cfb5252f1bf0cc > Author: Wilco Dijkstra > Date: Wed Jul 6 13:17:23 2016 + > > This patch improves the accuracy of the Cortex-A53 integer scheduler... That's not related, all it does is expose a latent regalloc bug via different scheduling.
[Bug c++/99770] gcc gives warning being treated as error on arm platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99770 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2021-03-25 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Presumably you are using -Werror but we can't tell because you didn't provide any of the information you were asked to provide. As requested when creating a new bug, please read https://gcc.gnu.org/bugs/ Also, GCC 7 is no longer supported.
[Bug c++/99770] gcc gives warning being treated as error on arm platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99770 --- Comment #2 from Jonathan Wakely --- (In reply to Nishant Chauhan from comment #0) > Is this a bug in gcc on arm? No, the warning is correct. You are passing NULL where a size_t is expected. That's probably a bug in your code, you should fix it. I get a warning on x86_64-linux with GCC 7.5 (and with all later versions).
[Bug c/99768] [11 Regression] Bogus -Wuninitialized diagnostic with type punning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99768 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Blocks||24639 --- Comment #1 from Richard Biener --- I think the warning is correct - there is no valid initialization of a float entity in 'tmp' (in fact GCC removed the initialization from 'v'). It might be misleading but then what do you expect with invalid code? We could, in theory, do another walk to find an initialization with strict aliasing disabled and if we then find a candidate note that there are possible initializations (we won't be able to prove they are definite inits) but a violation of strict-aliasing might hide them. OTOH this would pop up a lot and likely confuse people to use -fno-strict-aliasing to simply hide the warning but not fix the missing initialization. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug c++/99686] ICE when using both concepts and full specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686 --- Comment #4 from W E Brown --- (In reply to Steven Sun from comment #3) > I would expect the complete specialization is full > specialization for both primary templates. No, any given explicit or partial specialization can be a specialization of only one primary template. (Suppose that two overloaded primary templates had different signatures. How then, in general, could both be specialized by any single explicit or partial specialization?) > ... > In conclusion, this makes sences but I didn't see that coming. Anyway, I > think a possible improvement is make ICE to an error of "ambigous full > specialization". Or even better, a change in C++23 standard. Given two or more very similar primary templates, C++ already specifies an algorithm (known as "partial* ordering") to determine which one is being specialized by a given explicit or partial specialization. Therefore, unless you can find some issue with that algorithm, I see no reason to propose any language change in this area; partial ordering has been part of C++ for several decades. (However, I speculate that your test cases may have exposed a bug in GCC's implementation of partial ordering, possibly just a failure to diagnose an ambiguous situation. I'm sure the GCC internals experts will provide proper diagnosis and remediation in due course.) * The algorithn is termed "partial" because there are cases that can't be decided and therefore result in an ill-formed program. If you'd like some further details on this topic, I can recommend my video 😊 https://www.youtube.com/watch?v=nfIX8yWlByY.
[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744 --- Comment #5 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:72982851d70dfbc547d83ed2bb45356b9ebe3ff0 commit r11-7825-g72982851d70dfbc547d83ed2bb45356b9ebe3ff0 Author: H.J. Lu Date: Tue Mar 23 20:04:58 2021 -0700 x86: Skip ISA check for always_inline in system headers For always_inline in system headers, we don't know if caller's ISAs are compatible with callee's ISAs until much later. Skip ISA check for always_inline in system headers if caller has target attribute. gcc/ PR target/98209 PR target/99744 * config/i386/i386.c (ix86_can_inline_p): Don't check ISA for always_inline in system headers. gcc/testsuite/ PR target/98209 PR target/99744 * gcc.target/i386/pr98209.c: New test. * gcc.target/i386/pr99744-1.c: Likewise. * gcc.target/i386/pr99744-2.c: Likewise.
[Bug middle-end/98209] [8/9/10/11 Regression] printf failed with O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98209 --- Comment #12 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:72982851d70dfbc547d83ed2bb45356b9ebe3ff0 commit r11-7825-g72982851d70dfbc547d83ed2bb45356b9ebe3ff0 Author: H.J. Lu Date: Tue Mar 23 20:04:58 2021 -0700 x86: Skip ISA check for always_inline in system headers For always_inline in system headers, we don't know if caller's ISAs are compatible with callee's ISAs until much later. Skip ISA check for always_inline in system headers if caller has target attribute. gcc/ PR target/98209 PR target/99744 * config/i386/i386.c (ix86_can_inline_p): Don't check ISA for always_inline in system headers. gcc/testsuite/ PR target/98209 PR target/99744 * gcc.target/i386/pr98209.c: New test. * gcc.target/i386/pr99744-1.c: Likewise. * gcc.target/i386/pr99744-2.c: Likewise.
[Bug c++/99565] [11 Regression] Bogus identical branches warning when returning references to union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99565 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:660eb7e9dee46ef1c986d5a4fa5cbd182b435518 commit r11-7826-g660eb7e9dee46ef1c986d5a4fa5cbd182b435518 Author: Jakub Jelinek Date: Thu Mar 25 11:33:35 2021 +0100 c-family: Fix up -Wduplicated-branches for union members [PR99565] Honza has fairly recently changed operand_equal_p to compare DECL_FIELD_OFFSET for COMPONENT_REFs when comparing addresses. As the first testcase in this patch shows, while that is very nice for optimizations, for the -Wduplicated-branches warning it causes regressions. Pedantically a union in both C and C++ has only one active member at a time, so using some other union member even if it has the same type is UB, so I think the warning shouldn't warn when it sees access to different fields that happen to have the same offset and should consider them different. In my first attempt to fix this I've keyed the old behavior on OEP_LEXICOGRAPHIC, but unfortunately that has various problems, the warning has a quick non-lexicographic compare in build_conditional_expr* and another lexicographic more expensive one later during genericization and turning the first one into lexicographic would mean wasting compile time on large conditionals. So, this patch instead introduces a new OEP_ flag and makes sure to pass it to operand_equal_p in all -Wduplicated-branches cases. The cvt.c changes are because on the other testcase we were warning with UNKNOWN_LOCATION, so the user wouldn't really know where the questionable code is. 2021-03-25 Jakub Jelinek PR c++/99565 * tree-core.h (enum operand_equal_flag): Add OEP_ADDRESS_OF_SAME_FIELD. * fold-const.c (operand_compare::operand_equal_p): Don't compare field offsets if OEP_ADDRESS_OF_SAME_FIELD. * c-warn.c (do_warn_duplicated_branches): Pass also OEP_ADDRESS_OF_SAME_FIELD to operand_equal_p. * c-typeck.c (build_conditional_expr): Pass OEP_ADDRESS_OF_SAME_FIELD to operand_equal_p. * call.c (build_conditional_expr_1): Pass OEP_ADDRESS_OF_SAME_FIELD to operand_equal_p. * cvt.c (convert_to_void): Preserve location_t on COND_EXPR or or COMPOUND_EXPR. * g++.dg/warn/Wduplicated-branches6.C: New test. * g++.dg/warn/Wduplicated-branches7.C: New test.
[Bug middle-end/98209] [8/9/10/11 Regression] printf failed with O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98209 H.J. Lu changed: What|Removed |Added Target Milestone|8.5 |11.0 --- Comment #13 from H.J. Lu --- Fixed for GCC 11 so far.
[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Status|NEW |RESOLVED --- Comment #6 from H.J. Lu --- Fixed for GCC 11.
[Bug libfortran/99740] floating point exception in rand() in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99740 --- Comment #3 from Paul A. Voytas --- I see what you mean--if i test for rand(0)=0.d0 I do get hist with gfortran on the EL7 machine. But it seems like there must still be something different from older versions. The info pages for rand() say "between 0 and 1" which I always took to be exclusive of the endpoints (of course there's machine precision). On CentOS6 with g77 when I run the above code I get no errors--even with 10x more attempts--and the test for rand(0)=0.d0 never is true. On that same CentOS6 machine with gfortran, code does show rand(0)=0.d0 cases (and the -log(rand(0)) returns +Infinity.
[Bug middle-end/98209] [8/9/10 Regression] printf failed with O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98209 Richard Biener changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] printf |printf failed with O1 or|failed with O1 or above |above | Target Milestone|11.0|8.5 Known to work||11.0
[Bug middle-end/41953] missing uninitialized warning (SRA,VOP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41953
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2009-11-06 10:02:19 |2021-3-25
--- Comment #5 from Richard Biener ---
Reconfirmed with -O2 -fno-tree-pre -fno-tree-sra or -O -fno-tree-sra.
Basically the IL not warning is
int f (const struct ExtentsBase & e1, int n)
{
struct ExtentsBase my_extents;
int _1;
int _7;
[local count: 1073741824]:
if (n_3(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
goto ; [100.00%]
[local count: 536870913]:
_1 = e1_5(D)->startx_;
my_extents.startx_ = _1;
[local count: 1073741824]:
_7 = my_extents.startx_;
my_extents ={v} {CLOBBER};
return _7;
}
while we for example warn for (PRE enabled):
int f (const struct ExtentsBase & e1, int n)
{
struct ExtentsBase my_extents;
int _1;
int pretmp_9;
int prephitmp_10;
[local count: 1073741824]:
if (n_3(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
pretmp_9 = my_extents.startx_;
goto ; [100.00%]
[local count: 536870913]:
_1 = e1_5(D)->startx_;
[local count: 1073741824]:
# prephitmp_10 = PHI
my_extents ={v} {CLOBBER};
return prephitmp_10;
[Bug tree-optimization/41898] GCC ignores restrict on array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41898 --- Comment #5 from Richard Biener --- Possibly related (implementation-wise) are ideas to handle array element contents field-sensitive but not elements, thus have for T p[10]; fields for members of 'T' but re-use the appropriate member for each array element of 'p'. This would support doing field-sensitive analysis for allocated storage and varinfo fields would "wrap around" the full variables size. One conservative subfield allocation strathegy for allocated storage is N pointers aligned to pointer alignment.
[Bug tree-optimization/99755] failure to fold a conditional that's a subset of another expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99755 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #2 from Andrew Macleod --- f2 and f4 are "similar" when I look at whats going on with these. The interesting bits are bb3 and bb4 === BB 3 i_9(D) int [2, +INF] j_10(D) int [3, +INF] Relational : (x_12 > i_9(D)) : x_12 = i_9(D) + 1; x_12 : int [3, +INF] === BB 4 Imports: i_9(D) j_10(D) Exports: _4 _5 _6 i_9(D) j_10(D) _4 : i_9(D)(I) _5 : j_10(D)(I) _6 : _4 _5 i_9(D)(I) j_10(D)(I) i_9(D) int VARYING j_10(D) int VARYING : # x_8 = PHI _4 = i_9(D) == 2; _5 = j_10(D) == 3; _6 = _4 & _5; if (_6 != 0) goto ; [INV] else goto ; [INV] x_8 : int [3, +INF] 4->5 (T) _4 : _Bool [1, 1] 4->5 (T) _5 : _Bool [1, 1] 4->5 (T) _6 : _Bool [1, 1] 4->5 (T) i_9(D) : int [2, 2] 4->5 (T) j_10(D) : int [3, 3] 4->7 (F) _6 : _Bool [0, 0] we have the ability to recompute stmts on edges when the dependencies change. This currently applies only to range-ops enabled stmts. An extension to PHIS and other non-range-ops is in the works. The gist being x_8 is directly dependant on x_11 and x_12. x_11 is undefined, so it boils down to a dependency on x_12. x_12 in turn is dependant on i_9 which is a modified export from this block. So when recomputation is extended to PHIS, we should be able to see that i_9 has changed on this edge, and reevaluate x_12 for that edge, x_12 = i_9 + 1 --> [2,2] + 1 == [3,3] and feeding that into a PHI recalculation for the edge producing x_8 = PHI and then we'd resolve x_8 = [3,3] on the true edge, and the desired fold should happen. The other issue is that when we do recalculations, we currently only go back one degree of dependency for the sake of compilation speed... x_8's direct dependencies are that one degree.. I have not done experiments on more than one degree, but it may make sense to look back one degree for phi arguemnts as well, which would then get cases like this. It may also make sense instead to adjust the phi optimization pass to utilize ranger to do a more in-depth analysis of argument ranges and their dependencies and get it there. I'll update this once I have enabled recomputation for phis, and have something more concrete.
[Bug middle-end/98209] [8/9/10 Regression] printf failed with O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98209 --- Comment #14 from H.J. Lu --- The fix was reverted by commit de00a7bda94910835012bc7150be53b460a5c8b6 Author: H.J. Lu Date: Thu Mar 25 06:57:37 2021 -0700 Revert "x86: Skip ISA check for always_inline in system headers" This reverts commit 72982851d70dfbc547d83ed2bb45356b9ebe3ff0.
[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from H.J. Lu --- The fix was reverted by commit de00a7bda94910835012bc7150be53b460a5c8b6 Author: H.J. Lu Date: Thu Mar 25 06:57:37 2021 -0700 Revert "x86: Skip ISA check for always_inline in system headers" This reverts commit 72982851d70dfbc547d83ed2bb45356b9ebe3ff0.
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #34 from Matt Thompson --- Iain, Apologies. I forgot about this. Seeing as I'm now using GNU 10.2.0 on my Macbook...I guess it's working. I currently do: ../gcc-10.2.0/configure --prefix=$HOME/installed/Core/gcc-gfortran/10.2.0 --enable-languages=c,c++,fortran --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk |& tee configure.log when I configure it which is much as you suggested. My guess is I worked with my admins nuking and restoring XCode until we got it right (or something, government laptops are fun, no sudo, lots of restrictions...). Thanks for your help, and I can't wait for 10.3 or 11.0 or whatever is next! N Note: I'm still on an Intel Mac, so I won't need to bother "Iain Sandoe, master of M1 GNU" about that for a while. :D
[Bug tree-optimization/19831] Missing DSE/malloc/free optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19831
--- Comment #20 from Richard Biener ---
The original cases are all fixed but what remains is us failing to elide
void f ()
{
void *p = __builtin_malloc (1);
if (!p)
__builtin_abort ();
__builtin_free (p);
}
if that's even desirable. Note that we mark the abort() call as necessary
since it has side-effects which is contrary to this expectation. If you
think of, say,
extern int alloc_fails;
extern int alloc_success;
void f ()
{
void *p = __builtin_malloc (1);
if (!p)
alloc_fails++;
else
alloc_success++;
__builtin_free (p);
}
then the question is really whether we may assume that malloc does not
return NULL. We can then avoid marking 'p' necessary on NULL checks
on malloc returned pointers and upon DCEing the malloc/free pair
replace the def of 'p' with a non-zero constant.
Related would be to play similar things with realloc - replace
void *p = realloc (q, n);
free (p);
with
free (q);
and
void *p = realloc (q, n);
if (p == q)
not_copied++;
free (p);
with
void *p = q;
if (p == q)
not_copied++;
free(q);
so here we'd not only have to deal with != NULL but other pointer equality
checks.
[Bug c/27214] The C frontend introduces undefined pointer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27214 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Richard Biener --- Fixed. That the POINTER_PLUS_EXPR is unsigned sizetype is a design decision, it is interpreted signed and thus there is no bad overflow. Yes, we should have used signed sizetype.
[Bug tree-optimization/27039] [4.1 Regression] Unable to determine # of iterations for a simple loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039 Bug 27039 depends on bug 27214, which changed state. Bug 27214 Summary: The C frontend introduces undefined pointer overflow https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27214 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/96582] aarch64:ICE during GIMPLE pass: veclower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96582 Alex Coplan changed: What|Removed |Added CC||acoplan at gcc dot gnu.org --- Comment #5 from Alex Coplan --- FWIW, the ICE was "fixed" with r11-4912-g46c705e70e078f6a1920d92e49042125d5e18495: commit 46c705e70e078f6a1920d92e49042125d5e18495 Author: Richard Sandiford Date: Wed Nov 11 11:42:46 2020 + aarch64: Support SVE comparisons for unpacked integers This patch adds support for comparing unpacked SVE integer vectors, such as byte elements stored in the bottom bytes of halfword containers. It also adds support for selects between unpacked SVE vectors (both integer and floating-point), since selects and compares are closely tied via the vcond optab interface. so not sure if the issue was really fixed or perhaps just hidden.
[Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #48 from seurer at gcc dot gnu.org ---
Just an FYI: the patch done for gcc 10 (trunk at the time I believe) fixed a
32-bit failure in experimental/memory_resource/new_delete_resource.cc on
powerpc64 32 bit testing. The failure still occurs with gcc 9.
make -k check RUNTESTFLAGS="--target_board=unix'{-m32}'
conformance.exp=experimental/memory_resource/new_delete_resource.cc"
FAIL: experimental/memory_resource/new_delete_resource.cc execution test
# of expected passes1
# of unexpected failures1
/home/seurer/gcc/git/gcc-9-test/libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc:125:
void test03(): Assertion 'aligned(p)' failed.
[Bug ipa/99751] [11 Regression] wrong code at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99751
--- Comment #6 from Martin Liška ---
Maybe a nicer names:
$ cat pr99751.c
int *ptr1 = 0, **ptr2 = &ptr1;
int *identity(int *p)
{
return p;
}
void store_to_c(int *p)
{
*ptr2 = identity(p);
}
int main()
{
int f;
store_to_c(&f);
if (ptr1 != &f)
__builtin_abort();
return 0;
}
[Bug target/99767] [9/10/11 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:3360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99767 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Yeah, I don't see a problem on the omp simd cloning side, one could write such code by hand too. The thing is the DCE disabling, ifcvt adds .COND_DIV on the to be vectorized loop copy only, but in the end the loop is vectorized but .COND_DIV is not because it is dead and the vectorizer supposedly only considers statements that are actually used. So, either the vectorizer should do something for the dead statements in the loop (whatever, including failing the vectorization, or vectorizing them too, ...), or ifcvt shouldn't add those for the dead statements, or we need to lower those ifns back into scalar statements at the end of vectorization, or be able to expand them even when scalar.
[Bug target/99766] [11 Regression] ICE: unable to generate reloads with SVE code since r11-7807-gbe70bb5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99766 --- Comment #4 from Vladimir Makarov --- (In reply to Alex Coplan from comment #2) > The above ICEs with just -O3 -march=armv8.2-a+sve. Thank you for reporting. I reproduced it тоо. I think соме constraint was not categorized rightly. It might be simply to find and to fix but it will need a lot of testing.
[Bug analyzer/99771] New: Analyzer diagnostics should not say ""
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99771 Bug ID: 99771 Summary: Analyzer diagnostics should not say "" Product: gcc Version: 11.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: --- Various analyzer diagnostics talk about ""; examples can be seen in the testsuite: data-model-10.c: *new_table->m_f = NULL; // "dereference of possibly-NULL ''" malloc-1.c (test_44): free (global_ptr); // "leak of ''" malloc-ipa-13.c: calls_free (f.m_p); //"passing freed pointer '' in call to 'calls_free' from 'test'" and IIRC I've seen these "in the wild" recently as well. We shouldn't emit "" to the end-user. Filing this bug to have a place to track fixing these.
[Bug analyzer/99771] Analyzer diagnostics should not say ""
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99771 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-25 Status|UNCONFIRMED |ASSIGNED
[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 --- Comment #12 from Martin Liška --- @doko: Can you please reduce objects and then .ii files needed to reproduce the issue?
[Bug target/99767] [9/10/11 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:3360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99767
--- Comment #3 from Jakub Jelinek ---
E.g. as
int a[1024], b[1024];
void
foo (void)
{
#pragma omp simd
for (int i = 0; i < 1024; i++)
if (b[i] > 23) {
a[i] = b[i] + 1;
int v = 1 / 0;
}
}
(omp simd is there only to convince it to vectorize it and not give up).
[Bug tree-optimization/96974] [10/11 Regression] ICE in vect_get_vector_types_for_stmt compiling for SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974 --- Comment #11 from CVS Commits --- The master branch has been updated by Stam Markianos-Wright : https://gcc.gnu.org/g:aac12084fc07319d5c8232c51dafa4e297bd5415 commit r11-7830-gaac12084fc07319d5c8232c51dafa4e297bd5415 Author: Stam Markianos-Wright Date: Thu Mar 25 15:29:41 2021 + tree-optimization/96974 - avoid ICE by replacing assert with standard failure Minor patch to add a graceful exit in the rare case where an invalid combination of TYPE_VECTOR_SUBPARTS for nunits_vectype and *stmt_vectype_out is reached in vect_get_vector_types_for_stmt. This resolves the ICE seen in PR tree-optimization/96974, however the issue of correctly handling this rare vectorization combination is left for a later patch. Bootstrapped and reg-tested on aarch64-linux-gnu. 2021-03-25 Stam Markianos-Wright gcc/ChangeLog: PR tree-optimization/96974 * tree-vect-stmts.c (vect_get_vector_types_for_stmt): Replace assert with graceful exit. gcc/testsuite/ChangeLog: PR tree-optimization/96974 * g++.target/aarch64/sve/pr96974.C: New test.
[Bug tree-optimization/96974] [10/11 Regression] ICE in vect_get_vector_types_for_stmt compiling for SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Stam Markianos-Wright : https://gcc.gnu.org/g:a1b4d742f180ff6f1e538e79e590065afe2cce6e commit r10-9545-ga1b4d742f180ff6f1e538e79e590065afe2cce6e Author: Stam Markianos-Wright Date: Thu Mar 25 15:31:17 2021 + tree-optimization/96974 - avoid ICE by replacing assert with standard failure Minor patch to add a graceful exit in the rare case where an invalid combination of TYPE_VECTOR_SUBPARTS for nunits_vectype and *stmt_vectype_out is reached in vect_get_vector_types_for_stmt. This resolves the ICE seen in PR tree-optimization/96974, however the issue of correctly handling this rare vectorization combination is left for a later patch. Bootstrapped and reg-tested on aarch64-linux-gnu. 2021-03-25 Stam Markianos-Wright gcc/ChangeLog: PR tree-optimization/96974 * tree-vect-stmts.c (vect_get_vector_types_for_stmt): Replace assert with graceful exit. gcc/testsuite/ChangeLog: PR tree-optimization/96974 * g++.target/aarch64/sve/pr96974.C: New test.
[Bug fortran/99765] Explicit dimension size declaration of pointer array allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99765 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus --- (In reply to Dominique d'Humieres from comment #1) > so I think > real, dimension(10), pointer :: a(:) => null() > and > real, dimension(10), allocatable :: a(10) > are invalid and shall give an error. I concur with the second example (violating the cited constraint), but the first one looks valid to me. In particular: F2018 has in 8.2 [92:1-3]): "The type declaration statement also specifies the attributes whose keywords appear in the attr-spec, except that the DIMENSION attribute can be specified or overridden for an entity by the appearance of array-spec in its entity-decl," Thus, unless I missed some example, this PR looks invalid to me.
[Bug target/99764] ICE in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99764 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I would expect this ICEs since r10-6020-g2e87b2f4121fe1d39edb76f4e492dfe327be6a1b when __bf16 support has been added, at least r11-1 already ICEs
[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 --- Comment #6 from Jakub Jelinek --- I did not know whether it is implementable (in VSX or in Altivec) for 32-bit targets etc., all I was suggesting was what to do if it is not implementable. If it is implementable, somebody familiar with VSX/Altivec should add the implementation, or we can temporarily use the patch that has been posted and get back to it later. Or if it is partly implementable (e.g. can be done in VSX and can't be done in Altivec, etc.), then the patch can still be used after amendments for what will and what will not work. Right now it is a P1 blocker because we ICE on something that worked perfectly fine (perhaps slower than it could) in GCC 10. So something needs to be done before GCC 11 and we have ~ a month left for that.
[Bug c++/98942] [C++23] Implement P1102R2 - Down with ()!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98942 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Marek Polacek --- Implemented in GCC 11.
[Bug c++/98940] Implement C++23 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940 Bug 98940 depends on bug 98942, which changed state. Bug 98942 Summary: [C++23] Implement P1102R2 - Down with ()! https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98942 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/99565] [11 Regression] Bogus identical branches warning when returning references to union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99565 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug middle-end/99768] [11 Regression] Bogus -Wuninitialized diagnostic with type punning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99768
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2021-03-25
Status|UNCONFIRMED |NEW
Component|c |middle-end
Ever confirmed|0 |1
CC||msebor at gcc dot gnu.org
--- Comment #2 from Martin Sebor ---
The -Wuninitialized was introduced in
g:b825a22890740f341eae566af27e18e528cd29a7. I don't think I meant for this to
be diagnosed so I suspect it's a bug in the new code. I see no basis in the IL
(below) to issue the warning. GCC should issue -Wstrict-aliasing instead (it
does but only at level 2).
float foo (unsigned int v)
{
float * f;
unsigned int tmp;
float _5;
:
tmp = v_2(D);
f_4 = &tmp;
_5 = *f_4;<< -Wuninitialized
tmp ={v} {CLOBBER};
return _5;
}
[Bug c++/95675] [8/9/10/11 Regression] internal compiler error: in build_over_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95675 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|8.5 |9.4 Status|ASSIGNED|RESOLVED --- Comment #11 from Jason Merrill --- Fixed for 9.4/10.3/11.
[Bug c++/99772] New: New built-ins for pointer comparisons that yield a total order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99772
Bug ID: 99772
Summary: New built-ins for pointer comparisons that yield a
total order
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 93628
Target Milestone: ---
[comparisons.general] says:
For templates less, greater, less_equal, and greater_equal, the specializations
for any pointer type yield a result consistent with the implementation-defined
strict total order over pointers (3.27).
We do:
_GLIBCXX14_CONSTEXPR bool
operator()(_Tp* __x, _Tp* __y) const _GLIBCXX_NOTHROW
{
#if __cplusplus >= 201402L
#ifdef _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED
if (__builtin_is_constant_evaluated())
#else
if (__builtin_constant_p(__x < __y))
#endif
return __x < __y;
#endif
return (__UINTPTR_TYPE__)__x < (__UINTPTR_TYPE__)__y;
}
The casts were added for PR libstdc++/78420 because GCC started to optimize
based on unspecified < comparisons. So we can't just use the built-in
comparisons.
Furthermore:
For template specializations less, greater, less_equal, and
greater_equal, if the call operator calls a built-in operator comparing
pointers, the call operator yields a result consistent with the
implementation-defined strict total order over pointers.
This one is harder, as we have to jump through several hoops to detect "if the
call operator calls a built-in operator comparing pointers", and if it does,
then use std::less to get a total order.
Then [comparisons.three.way] has another "if <=> ... resolve to a built-in
operator comparing pointers" and again requires a total order. And again in
[range.cmp].
Our current approach doesn't work for std::compare_three_way
std::ranges::equal_to with two types that are (or convert to) function pointers
(see PR 93628).
It would be faster to compile and (I assume) more reliable if we could just ask
the compiler to do the comparison and give a total order (so that the
middle-end doesn't optimize as though the result is unspecified).
I don't know exactly what the front-end support would look like. Maybe one
helper to check whether a given expression "resolves to a built-in operator
comparing pointers" and another to do the comparison to get a total order, but
I'm not sure that would solve PR 93628.
Maybe what we want is __builtin_less(x, y) and __builtin_equal_to(x, y) and
__builtin_compare_three_way(x, y) which evaluate xy
respectively, but guarantee a total order. If x for floating-point
types (PR 96526) which could presumably be subsumed by
__builtin_compare_three_way.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93628
[Bug 93628] ranges::equal_to doesn't work for types convertible to function
pointers
[Bug target/99773] New: ARM v8.1-m MVE interaction with -mfloat-abi not clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773
Bug ID: 99773
Summary: ARM v8.1-m MVE interaction with -mfloat-abi not clear
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
I noticed an unexpected linker error when compiling with
-march=armv8.1-m.main+mve -mfloat-abi=hard -mcpu=cortex-m55 -mthumb
error: /tmp/ccQvvmcJ.o uses VFP register arguments, ./XXX.exe does not
Using mve.fp instead of mve fixes that.
However, I'm used to -mfloat-abi=hard defining the eabi attribute:
Tag_ABI_VFP_args: VFP registers
Compiling
===
typedef int __attribute((vector_size(16))) v4si;
float g(float x, float y)
{
x += y;
return x;
}
v4si f(v4si x, v4si y)
{
return x + y;
}
===
with -O2 -march=armv8.1-m.main+mve -mfloat-abi=hard
generates for f:
vadd.i32 q0, q0, q1
bx lr
which uses the MVE registers for the parameters, but the object files does not
have the Tag_ABI_VFP_args: VFP registers attribute I would expect.
It does have
Tag_MVE_arch: MVE Integer only
is that enough?
Is the current behavior expected or is there a bug?
[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 --- Comment #7 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #6) > I did not know whether it is implementable (in VSX or in Altivec) for 32-bit > targets etc., all I was suggesting was what to do if it is not implementable. Yes. > If it is implementable, somebody familiar with VSX/Altivec should add the > implementation, or we can temporarily use the patch that has been posted and > get back to it later. I haven't seen a patch posted yet? > Or if it is partly implementable (e.g. can be done in > VSX and can't be done in Altivec, etc.), then the patch can still be used > after amendments for what will and what will not work. The only thing I am saying it should be massively easier to just implement it for -m32 as well, much easier than adding extra conditions (and unavoidably getting that wrong). > Right now it is a P1 blocker because we ICE on something that worked > perfectly fine (perhaps slower than it could) in GCC 10. So something needs > to be done before GCC 11 and we have ~ a month left for that. Yup. I'll review any patch that is sent (cc: me, so that I see it immediately, instead of after 3 to 6 weeks). Thanks, Segher
[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 --- Comment #8 from David Edelsohn --- Xionghu, please do not write "can't" when you mean "it's difficult" or "it hasn't been implemented" or "it's too inefficient" (such as moving the data through memory). Please be very precise in your explanations. I never wrote that there is no need variable vec_insert support for m32 build. Does LLVM generate good code for this operation in 32 bit mode? As Jakub said, this is a P1 blocker. We may want to fix this differently in the short term than the long term. We may want to TEMPORARILY avoid this situation for m32 configuration for the upcoming release but GCC should generate a better instruction sequence in the next release cycle.
[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||dje at gcc dot gnu.org Last reconfirmed||2021-03-25 Ever confirmed|0 |1 --- Comment #9 from David Edelsohn --- Confirmed.
[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773 --- Comment #1 from Richard Earnshaw --- -march=armv8.1-m.main+mve -mfloat-abi=hard should use the VFP registers for passing any FP arguments so the build attribute for Tag_ABI_VFP_args should be set to show that. It's true that soft-float routines will still be needed to do any FP operations in this case, but that doesn't affect the ABI at public interfaces.
[Bug target/99718] [11 regression] ICE in new test case gcc.target/powerpc/pr98914.c for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718 --- Comment #10 from Jakub Jelinek --- https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567215.html
[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773 Alex Coplan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-25 Ever confirmed|0 |1 --- Comment #2 from Alex Coplan --- Confirmed, then.
[Bug libfortran/99740] floating point exception in rand() in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99740 --- Comment #4 from Steve Kargl --- On Thu, Mar 25, 2021 at 12:52:53PM +, pvoytas at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99740 > > --- Comment #3 from Paul A. Voytas --- > I see what you mean--if i test for rand(0)=0.d0 I do get hist with gfortran on > the EL7 machine. > > But it seems like there must still be something different from older versions. > The info pages for rand() say "between 0 and 1" which I always took to be > exclusive of the endpoints (of course there's machine precision). On CentOS6 > with g77 when I run the above code I get no errors--even with 10x more > attempts--and the test for rand(0)=0.d0 never is true. On that same CentOS6 > machine with gfortran, code does show rand(0)=0.d0 cases (and the > -log(rand(0)) > returns +Infinity. > g77 has not been supported for nearly 1.5 decades (gcc-3.4.6 released on 6 Mar 2006). gfortran tries to provide some level of API compatibility with g77. I believe there has never been a commitment to provide bit-for-bit compatibility (especially for something like rand()). Having now looked at g77's rand() implementation, I see that it is a wrapper around the libc routine by the same name rand(3). The quality of implementation of libc's rand(3) certainly varies across operating systems. gfortran's rand() implements the classic Park and Miller LCG RNG with an internal range of [0, 2**31-1), which yields a random number in [0., 1.). You really want to switch to using random_number(). The internal generator used in it has an enormous period and very good statistical quality, and random_number() is specified by the actual Fortran standard.
[Bug tree-optimization/33802] bogus "is used uninitialized" (VOPs) (inlining)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||msebor at gcc dot gnu.org --- Comment #15 from Martin Sebor --- The original test cases don't compile for me and I don't see the warning for the test case in comment 13 with recent GCC (6 through 11). I'm having trouble pinpointing when it disappeared.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 33802, which changed state. Bug 33802 Summary: bogus "is used uninitialized" (VOPs) (inlining) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/31279] Uninitialized warning for call-by-reference arguments with known intent(in)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31279
Martin Sebor changed:
What|Removed |Added
Component|middle-end |fortran
--- Comment #7 from Martin Sebor ---
GCC added the attributes mentioned in comment #4 under the name access -- see
below. Getting the middle end to issue a warning for the cases described in
comment #0 should be a matter of the Fortran front end making use of the
attribute.
$ cat x.c && gcc -S -Wall x.c
__attribute__ ((access (read_only, 1))) void f (int*);
void g (void)
{
int x;
f (&x);
}
x.c: In function ‘g’:
x.c:6:3: warning: ‘x’ is used uninitialized [-Wuninitialized]
6 | f (&x);
| ^~
x.c:1:46: note: in a call to ‘f’ declared with attribute ‘access (read_only,
1)’ here
1 | __attribute__ ((access (read_only, 1))) void f (int*);
| ^
x.c:5:7: note: ‘x’ declared here
5 | int x;
| ^
[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773
--- Comment #3 from Christophe Lyon ---
I tried changing TARGET_HARD_FLOAT_SUB in arm.h to:
#define TARGET_HARD_FLOAT_SUB (arm_float_abi != ARM_FLOAT_ABI_SOFT\
&& (bitmap_bit_p (arm_active_target.isa, \
isa_bit_vfpv2) \
|| bitmap_bit_p (arm_active_target.isa, \
isa_bit_mve)) \
&& TARGET_32BIT)
but that has other implications, like enabing VFP patterns: for instance
mulsf3_vfp becomes enabled, leading to a failure when builing libgcc (vmul.f32
is generated for powisf2, but rejected by the assembler)
So maybe we just change the condition to emit the attributes in arm_file_start?
Something like:
if (! TARGET_SOFT_FLOAT || TARGET_HAVE_MVE)
{
if ((TARGET_HARD_FLOAT && TARGET_VFP_SINGLE) || TARGET_HAVE_MVE)
arm_emit_eabi_attribute ("Tag_ABI_HardFP_use", 27, 1);
if (TARGET_HARD_FLOAT_ABI || TARGET_HAVE_MVE)
arm_emit_eabi_attribute ("Tag_ABI_VFP_args", 28, 1);
}
but that does not look very clean
[Bug middle-end/36823] missing uninitialized warning (IPA, inlining)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36823 --- Comment #5 from Martin Sebor --- Bisection shows the -Wuninitialized at -O2 disappeared between r176911 and r176920. The likely candidate is r176918.
[Bug middle-end/95622] [11 Regression] force_output flag on a variable prevents optimization / regresses c-c++-common/goacc/kernels-alias-ipa-pta{-2,-4,}.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95622
--- Comment #8 from Tobias Burnus ---
I am not sure whether this is a sensible solution, but it fixes
the issue for c-c++-common/goacc/kernels-alias-ipa-pta-2.c ...
diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index 529ec3a5b80..c93e9b46d8d 100644
--- a/gcc/tree-ssa-structalias.c
+++ b/gcc/tree-ssa-structalias.c
@@ -8132,7 +8132,7 @@ refered_from_nonlocal_fn (struct cgraph_node *node, void
*data)
*nonlocal_p |= (node->used_from_other_partition
|| DECL_EXTERNAL (node->decl)
|| TREE_PUBLIC (node->decl)
- || node->force_output
+ || (node->force_output && !node->offloadable)
|| lookup_attribute ("noipa", DECL_ATTRIBUTES (node->decl)));
return false;
}
@@ -8195,7 +8195,7 @@ ipa_pta_execute (void)
bool nonlocal_p = (node->used_from_other_partition
|| DECL_EXTERNAL (node->decl)
|| TREE_PUBLIC (node->decl)
-|| node->force_output
+|| (node->force_output && !node->offloadable)
|| lookup_attribute ("noipa",
DECL_ATTRIBUTES (node->decl)));
node->call_for_symbol_thunks_and_aliases (refered_from_nonlocal_fn,
[Bug analyzer/99774] New: False positive from -Wanalyzer-malloc-leak in loop (qemu:libvhost-user.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99774
Bug ID: 99774
Summary: False positive from -Wanalyzer-malloc-leak in loop
(qemu:libvhost-user.c)
Product: gcc
Version: 11.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: ---
Created attachment 50472
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50472&action=edit
Reduced reproducer
I got a report about a false leak warning from the analyzer on some code in
qemu.
I'm attaching a reduced reproducer from qemu which triggers the issue:
$ ./xgcc -B. -S -fanalyzer ../../src/libvhost-user-1.c
../../src/libvhost-user-1.c: In function ‘vu_check_queue_inflights’:
../../src/libvhost-user-1.c:52:51: warning: leak of ‘*vq.resubmit_list’
[CWE-401] [-Wanalyzer-malloc-leak]
52 | vq->resubmit_list[vq->resubmit_num].index = i; /* { dg-bogus
"leak" } */
| ~~^~~
‘vu_check_queue_inflights’: events 1-11
|
| 44 | if (vq->inuse) {
| | ^
| | |
| | (1) following ‘true’ branch...
| 45 | vq->resubmit_list = calloc(vq->inuse,
sizeof(VuVirtqInflightDesc));
| |
~~
| | ||
| | |(2) ...to here
| | (3) allocated here
| 46 | if (!vq->resubmit_list) {
| |~
| ||
| |(4) assuming ‘*vq.resubmit_list’ is non-NULL
| |(5) following ‘false’ branch...
|..
| 50 | for (i = 0; i < vq->inflight->desc_num; i++) {
| | ~ ~~
| || |
| || (7) following ‘true’ branch...
| || (9) following ‘true’ branch...
| |(6) ...to here
| 51 | if (vq->inflight->desc[i].inflight) {
| |
| | |
| | (8) ...to here
| | (10) ...to here
| 52 | vq->resubmit_list[vq->resubmit_num].index = i; /* {
dg-bogus "leak" } */
| | ~
| | |
| | (11)
‘*vq.resubmit_list’ leaks here; was allocated at (3)
|
[Bug analyzer/99774] False positive from -Wanalyzer-malloc-leak in loop (qemu:libvhost-user.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99774 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-25 Status|UNCONFIRMED |ASSIGNED
