[Bug middle-end/95189] [9/10 Regression] memcmp being wrongly stripped like strcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 Davin McCall changed: What|Removed |Added CC||davmac at davmac dot org --- Comment #28 from Davin McCall --- Created attachment 49866 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49866=edit My backport of fix to 9.3.0 For the benefit of anyone that needs it, I've attached my own attempt to backport the fix directly to the 9.3.0 release (maybe it will apply against the current 9.4 branch, not sure, haven't tried). It seems to fix the issue but I'm not a GCC developer.
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 --- Comment #6 from Steve Kargl --- On Sat, Jan 02, 2021 at 04:12:27AM +, jvdelisle at charter dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 > > --- Comment #5 from Jerry DeLisle --- > Patch regresses several test cases. > I haven't regression tested the patch, but at least for the testcase in this PR the patch is correct. You can verify this by looking at -fdump-tree-original with and without the patch. The variable 'i' is never set and never used (unless you use -fcheck=all).
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 --- Comment #5 from Jerry DeLisle --- Patch regresses several test cases.
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #4 from Jerry DeLisle --- With gfortran version 11.0.0 20201227 $ gfc -fbounds-check pr98490.f90 $ $ ./a.out At line 15 of file pr98490.f90 Fortran runtime error: Substring out of bounds: lower bound (0) of 'text' is less than one After Steves patch: $ gfc -fbounds-check pr98490.f90 $ ./a.out Lorem ipsum Steve would you like me to commit for you? Regression testing now.
[Bug tree-optimization/98497] New: [Potential Perf regression] jne to hot branch instead je to cold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98497
Bug ID: 98497
Summary: [Potential Perf regression] jne to hot branch instead
je to cold
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
In the following code generated by gcc 10.2
```
.L2:
movups xmm3, XMMWORD PTR [rax]
add rax, 16
addps xmm0, xmm3
cmp rax, rdx
je .L6
jmp .L2
matrix_sum_column_major.cold:
.L6:
movaps xmm2, xmm0
# .
```
I think `jne .L2; jmp.L6` should be more efficient as it avoids one instruction
in the hot path.
c code:
```
float matrix_sum_column_major(float* x, int n) {
n = 32767;
float sum = 0;
for (int i = 0; i < n; i++)
for (int j = 0; j < n; j++)
sum += x[j * n + i];
return sum;
}
```
gcc -Ofast -floop-nest-optimize -o -
```
matrix_sum_column_major:
mov eax, 4294836212
lea rdx, [rdi+131056]
pxorxmm1, xmm1
lea rcx, [rdi+rax]
.L3:
mov rax, rdi
pxorxmm0, xmm0
.L2:
movups xmm3, XMMWORD PTR [rax]
add rax, 16
addps xmm0, xmm3
cmp rax, rdx
je .L6
jmp .L2
matrix_sum_column_major.cold:
.L6:
movaps xmm2, xmm0
addss xmm1, DWORD PTR [rax+8]
lea rdx, [rax+131068]
add rdi, 131068
movhlps xmm2, xmm0
addps xmm2, xmm0
movaps xmm0, xmm2
shufps xmm0, xmm2, 85
addps xmm0, xmm2
movss xmm2, DWORD PTR [rax+4]
addss xmm2, DWORD PTR [rax]
addss xmm1, xmm2
addss xmm1, xmm0
cmp rdx, rcx
jne .L3
movaps xmm0, xmm1
ret
```
Link to godbolt: https://gcc.godbolt.org/z/ac7YY1
[Bug fortran/96986] [8/9/10/11 Regression] Explicit interface required: volatile argument for ENTRY subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Priority|P5 |P4 Status|WAITING |NEW --- Comment #5 from kargl at gcc dot gnu.org --- The code is valid. Gfortran error message is bogus. The pertinent part of the Fortran standard is the last sentence here: If the ENTRY statement is in a subroutine subprogram, an additional subroutine is defined by that subprogram. The name of the subroutine is entry-name. The dummy arguments of the subroutine are those specified in the ENTRY statement The entry statement 'entry func_a()' in question has no dummy arguments. The portion of the Fortran standard quoted in comment #2 clearly does not apply. Also note that the requirement of an explicit interface comes if a programmer wants to call 'entry func_b(va)'. Thus, the following code is also conforming. subroutine bar(va) integer, volatile :: va va = 42 end subroutine bar program foo integer n interface subroutine bar(va) integer, volatile :: va end subroutine bar end interface call bar(n) print *, n end program foo
[Bug bootstrap/98493] [11 regression] bootstrap build fails in go part of build after r11-6371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98493 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Ian Lance Taylor --- This should be fixed now.
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Ian Lance Taylor --- This should be fixed now.
[Bug fortran/96986] [8/9/10/11 Regression] Explicit interface required: volatile argument for ENTRY subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Priority|P4 |P5 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Fritz Reese from comment #3) > The error message blames fun_a() while neither fun_a() nor its containing > subroutine volatile_test() have a VOLATILE dummy argument. Do you think > 15.4.2.2 still applies? The standard has: ! 15.6.2.1 General ! A procedure is defined by the initial SUBROUTINE or FUNCTION statement of a ! subprogram, and each ENTRY statement defines an additional procedure (15.6.2.6). ! 15.6.2.6 ENTRY statement ! An ENTRY statement permits a procedure reference to begin with a particular ! executable statement within the function or subroutine subprogram in which ! the ENTRY statement appears. !... ! If the ENTRY statement is in a subroutine subprogram, an additional subroutine ! is defined by that subprogram. ... So basically I think the error is correct. Nevertheless the error message is probably sub-optimal. Would you prefer it to refer to "volatile_test"? I personally do not use ENTRY in my own code, and I don't know how to properly write an explicit interface for a similar subroutine including its entries. The best solution would be the use of modules, which is what I do. Downgrading to P5 / diagnostic.
[Bug fortran/96986] [8/9/10/11 Regression] Explicit interface required: volatile argument for ENTRY subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986 --- Comment #3 from Fritz Reese --- (In reply to anlauf from comment #2) ... > So I'd say the code in comment#0 is invalid, although the compiler is not > required to diagnose this. > > If you agree, we will close the issue as INVALID. The error message blames fun_a() while neither fun_a() nor its containing subroutine volatile_test() have a VOLATILE dummy argument. Do you think 15.4.2.2 still applies?
[Bug fortran/89891] [meta-bug] Accessing memory in rejected statements or expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89891 Bug 89891 depends on bug 98263, which changed state. Bug 98263 Summary: valgrind error in gfc_find_derived_vtab https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98263 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/96381] gfc_find_vtab can use a character type typespec as a derived type (causing invalid access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96381 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #5 from anlauf at gcc dot gnu.org --- *** Bug 98263 has been marked as a duplicate of this bug. ***
[Bug fortran/98263] valgrind error in gfc_find_derived_vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98263 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from anlauf at gcc dot gnu.org --- This is fixed by the patch for PR96381. *** This bug has been marked as a duplicate of bug 96381 ***
[Bug fortran/96986] [8/9/10/11 Regression] Explicit interface required: volatile argument for ENTRY subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986 --- Comment #2 from anlauf at gcc dot gnu.org --- F2018 has: ! 15.4.2.2 Explicit interface ! Within the scope of a procedure identifier, the procedure shall have an ! explicit interface if it is not a statement function and ! (3) the procedure has a dummy argument that ! (a) has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE, ! or VOLATILE attribute, So I'd say the code in comment#0 is invalid, although the compiler is not required to diagnose this. If you agree, we will close the issue as INVALID.
[Bug rtl-optimization/97836] wrong code at -O1 on x86_64-pc-linux-gnu by r11-5029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97836 Jan Hubicka changed: What|Removed |Added Summary|[11 Regression] wrong code |wrong code at -O1 on |at -O1 on |x86_64-pc-linux-gnu by |x86_64-pc-linux-gnu by |r11-5029 |r11-5029| --- Comment #7 from Jan Hubicka --- It is no longer regression, I will look into defining EAF_UNUSED better next stage1.
[Bug go/98496] New: [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496
Bug ID: 98496
Summary: [11 Regression] bootstrap broken in libgo on i686-gnu
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: doko at debian dot org
CC: cmang at google dot com
Target Milestone: ---
seen with trunk 20210101
../../../src/libgo/go/runtime/os_gccgo.go:43:12: error: reference to undefined
name 'startupRandomData'
43 | if startupRandomData != nil {
|^
../../../src/libgo/go/runtime/os_gccgo.go:44:30: error: reference to undefined
name 'startupRandomData'
44 | n := copy(r, startupRandomData)
| ^
Makefile:2962: recipe for target 'runtime.lo' failed
[Bug fortran/96381] gfc_find_vtab can use a character type typespec as a derived type (causing invalid access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96381 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d816b0c144d15e6570eb5b124b9f3ccbe3d40082 commit r11-6405-gd816b0c144d15e6570eb5b124b9f3ccbe3d40082 Author: Harald Anlauf Date: Fri Jan 1 18:55:41 2021 +0100 PR fortran/96381 - invalid read in gfc_find_derived_vtab An invalid declaration of a CLASS instance can lead to an internal state with inconsistent attributes during parsing that needs to be handled with sufficient care when processing subsequent statements. Avoid a lookup of the vtab entry for such cases. gcc/fortran/ChangeLog: * class.c (gfc_find_vtab): Add check on attribute is_class.
[Bug libstdc++/98473] std::vector::insert(pos, first, last) doesn't compile for T which has a deleted assignment operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98473 --- Comment #2 from Borislav Stanimirov --- (In reply to Jonathan Wakely from comment #1) > To meet the requirements of the standard we would need to insert them at the > end and then use std::rotate to reposition them. Or, to save move assignments, first "make a hole" and then copy-construct b's in place (some destructors of moved-out objects) will have to be called. > > I see that libc++ has the same behaviour as libstdc++, which does make me > think the standard is wrong to require this (since it doesn't reflect > reality). I'll have to check the history of the standard. > I reported the same issue there too: https://bugs.llvm.org/show_bug.cgi?id=48619 > > This does compile and work on msvc, so a compile-time check for the > > copy-assignment code is possible. > > No, you can't check that at compile time. It's a dynamic condition. > Presumably MSVC uses std::rotate instead so no check is needed. You definitely can check whether the class has a copy assignment operator and then, based on that, choose either the current implementation or one which doesn't invoke it (rotate or other)
[Bug fortran/93794] [8/9/10/11 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93794 --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #6) > Hah! I am probably a week or two from getting to it. I have been working my > way through a backlog but have been held up for some days by unlimited > polymorphic issues: see > https://groups.google.com/u/1/g/comp.lang.fortran/c/Ybasfal3YC4 I will be > posting a interpretation query today. > > If you want to take this over, please do so. Please let me know because I > have put it in my active PRs spreadsheet. Hi Paul, now that I know you're so well organized, I'll leave that one to you. ;-) Just wanting to make sure this one does not miss another release date...
[Bug fortran/96381] gfc_find_vtab can use a character type typespec as a derived type (causing invalid access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96381 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-January/055509.html
[Bug c++/96746] Type Casting in template function should not be type-dependent if the type of the conversion result is not type-dependent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96746 Masamitsu MURASE changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Masamitsu MURASE --- Jonathan Wakely, Jakub Jelinek, Thank you very much for your explanation. I totally understand that both gcc and clang meet the C ++ specification. Let me mark this issue as "Resolved" and "Invalid". Regards, Murase
[Bug target/98495] X86 _mm_extract_pi16 incorrectly sign extends result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98495 H.J. Lu changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-January ||/562638.html Keywords||patch --- Comment #1 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562638.html
[Bug target/98495] X86 _mm_extract_pi16 incorrectly sign extends result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98495 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 CC||crazylht at gmail dot com, ||hjl.tools at gmail dot com, ||wwwhhhyyy333 at gmail dot com Last reconfirmed||2021-01-01 Status|UNCONFIRMED |NEW Target Milestone|--- |11.0
[Bug rtl-optimization/98438] Rather bad optimization of midpoint implementation for __int128 (and other types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438 Thomas Koenig changed: What|Removed |Added Status|WAITING |NEW Severity|normal |enhancement Keywords||ra Target Milestone|--- |11.0 Component|target |rtl-optimization --- Comment #6 from Thomas Koenig --- Thanks for the expanded test case. The assembly with gcc 8 for int is identical to that with trunk, for _int128 it is a bit longer, so this does not appear to be a regression. The 128-bit case looks like a problem with register allocation. Confirming, changing component, adding relevant keywords.
[Bug sanitizer/98206] UBSan: Casting from multiple inheritance base to derived class triggers undefined behavior sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98206 --- Comment #6 from Roland B --- Great! This also works well in the original (more complex) scenario (https://github.com/rbock/sqlpp11/issues/355).
[Bug fortran/93794] [8/9/10/11 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93794 --- Comment #6 from Paul Thomas --- (In reply to anlauf from comment #5) > > Paul, > > > > are you still working on this? > > Paul, > > this is still one of yours... Hi Harald, Hah! I am probably a week or two from getting to it. I have been working my way through a backlog but have been held up for some days by unlimited polymorphic issues: see https://groups.google.com/u/1/g/comp.lang.fortran/c/Ybasfal3YC4 I will be posting a interpretation query today. If you want to take this over, please do so. Please let me know because I have put it in my active PRs spreadsheet. Happy New Year to both of you Paul
[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381 Matthias Klose changed: What|Removed |Added CC||doko at debian dot org --- Comment #15 from Matthias Klose --- Jeff, this is a two-step build: First a build using the configure options in comment #9, then a second build using the just built compiler for the jit build with CONFARGS_JIT := \ $(filter-out --enable-languages=% \ --enable-libstdcxx-debug %bootstrap,\ $(CONFARGS)) \ --enable-languages=c++,jit \ --enable-host-shared \ --disable-bootstrap So maybe you can work around that by doing a bootstrap build for the second build, but that wouldn't solve the problem of having a miscompiled build from the first build?
[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381 --- Comment #14 from John Paul Adrian Glaubitz --- Quick update. The bug actually occurs with "--disable-bootstrap" which is how Matthias Klose configures gcc when building the gcc-snapshot package. Removing the configure flag makes the bootstrap succeed. So my guess is that the system compiler is miscompiling stage1 which then fails to build libstdc++ and only the stage2(3?) compiler works properly. Guess we can mark this PR as invalid then? PS: Happy New Year!
