[Bug target/100378] [9/10/11/12 Regression] arm64: lsl + asr used instead of sxth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100378
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-05-02
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Trying 2 -> 6:
2: r94:DI=r96:DI
REG_DEAD r96:DI
6: r95:SI=sign_extend(r94:DI#0)
REG_DEAD r94:DI
Failed to match this instruction:
(set (reg:SI 95 [ s ])
(ashiftrt:SI (subreg:SI (ashift:DI (reg:DI 96)
(const_int 16 [0x10])) 0)
(const_int 16 [0x10])))
So what is happening is now combine is inserting an extra mov from x0 to a new
register 96 and when it does the combine, it does it badly not into what it was
before:
(insn 6 3 11 2 (set (reg:SI 95 [ s ])
(sign_extend:SI (subreg:HI (reg/v:DI 94 [ s ]) 0))) "t8877.c":6:37 111
{*extendhisi2_aarch64}
(expr_list:REG_DEAD (reg/v:DI 94 [ s ])
(nil)))
Confirmed. I thought there was a dup of this bug somewhere but I cannot find
it.
[Bug jit/100380] Segfault when using inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380 --- Comment #2 from Antoni --- Created attachment 50731 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50731=edit Working code So, the segfault seems to happen when creating the variable after creating the extended asm expression. Here's a working version of the code.
[Bug target/100378] [9/10/11/12 Regression] arm64: lsl + asr used instead of sxth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100378 Andrew Pinski changed: What|Removed |Added Summary|[Regression 9/10/11/12] |[9/10/11/12 Regression] |arm64: lsl + asr used |arm64: lsl + asr used |instead of sxth |instead of sxth Target Milestone|--- |12.0 Keywords||missed-optimization
[Bug sanitizer/100379] cyclades.h is removed from linux kernel header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379 --- Comment #1 from Andrew Pinski --- Please also report this upstream.
[Bug jit/100380] Segfault when using inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380 Antoni changed: What|Removed |Added Attachment #50729|0 |1 is obsolete|| --- Comment #1 from Antoni --- Created attachment 50730 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50730=edit Fixed reproducer
[Bug jit/100380] New: Segfault when using inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380 Bug ID: 100380 Summary: Segfault when using inline asm Product: gcc Version: 10.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Created attachment 50729 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50729=edit Reproducer for the bug Hi. The attached example produce a segfault when trying to compile code using inline assembly. Thanks.
[Bug sanitizer/100379] New: cyclades.h is removed from linux kernel header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379 Bug ID: 100379 Summary: cyclades.h is removed from linux kernel header files Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- https://lkml.org/lkml/2021/3/2/153 ../../../../../../gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:134:10: fatal error: linux/cyclades.h: No such file or directory 134 | #include | ^~ compilation terminated.
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #8 from Linus Torvalds --- (In reply to Alexander Monakov from comment #7) > > Most likely the issue is that sout/sfrom are misaligned at runtime, while > the vectorized code somewhere relies on them being sufficiently aligned for > a 'short'. They absolutely are. And we build the kernel with -Wno-strict-aliasing exactly to make sure the compiler doesn't think that "oh, I can make aliasing decisions based on type information". Because we have those kinds of issues all over, and we know which architectures support unaligned loads etc, and all the tricks with "memcpy()" and unions make for entirely unreadable code. So please fix the aliasing logic to not be type-based when people explicitly tell you not to do that. Linus
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #7 from Alexander Monakov --- The github issue has a more relevant code quote: #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS <-- this is enabled for ARCv2 279:PUP(sout) = PUP(sfrom); #else PUP(sout) = UP_UNALIGNED(sfrom); #endif Most likely the issue is that sout/sfrom are misaligned at runtime, while the vectorized code somewhere relies on them being sufficiently aligned for a 'short'. It is unsafe to dereference a misaligned pointer. The pointed-to-type must have reduced alignment: typedef unsigned short u16_u __attribute__((aligned(1))); u16_u *sout = ... u16_u *sfrom = (void *)(from - OFF); (without -ffreestanding, memcpy/memmove is a portable way to express a misaligned access) https://trust-in-soft.com/blog/2020/04/06/gcc-always-assumes-aligned-pointer-accesses/
[Bug libstdc++/100238] [11/12 Regression] Link failure in debug libstdc++ on MinGW due to atomicitiy.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100238 Jonathan Wakely changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #5 from Jonathan Wakely --- N.B. the "FIXED" status means gcc was fixed, which wasn't the case here (there was nothing to fix).
[Bug target/100375] [12 Regression] trunk 20210501 ftbfs for nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100375 --- Comment #4 from Jonathan Wakely --- constructing pair using (0, 0) is non-standard. The point of r12-220 was to deprecate it, so it warns. Apparently I didn't manage to do that correctly. I'll look into that, but if you want to initialize a pointer when templates are involved (which is the case for std::pair's constructors) then don't use 0.
[Bug libstdc++/100376] __gnu_cxx::stdio_filebuf does not work correctly on windows for GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100376 --- Comment #3 from cqwrteur --- i understand what's going on here. It is because std::filebuf in libstdc++ has a __c_lock data member which is before the __c_file. However, libstdc++ on windows does not support threading. A lot of people including me was using GCC with MCF gthread. The __gthread_lock_t in mcf gthread leads a different abi compared to nomarl version of libstdc++. The solution is that we need to provide win32 threading with libstdc++ by ourselves with win32 apis. Or if people are using different threading libraries, we get an ABI breaking.
[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334 --- Comment #6 from Thomas Rodgers --- Created attachment 50728 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50728=edit Fix wrong thread getting notification I am testing this patch
[Bug rtl-optimization/100377] needless stack adjustment when passing struct in register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100377 --- Comment #2 from Andrew Pinski --- OTOH, things seems OK on ppc64: and x86_64: Because both of those have redzones in their stack ABI.
[Bug rtl-optimization/100377] needless stack adjustment when passing struct in register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100377 Andrew Pinski changed: What|Removed |Added Depends on||94173, 90216 Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- (In reply to Luc Van Oostenryck from comment #0) > > Note: similar PRs exist but reported for x86_64 only Not true. PR 94173, PR 90216. I thought there was one which I filed which is much older than those but I can't find it. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90216 [Bug 90216] Stack Pointer decrementing even when not loading extra data to stack. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94173 [Bug 94173] [RISCV] Superfluous stackpointer manipulation
[Bug c++/100288] [11/12 Regression] g++-11 internal error and fails to precompile a concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100288
--- Comment #4 from Frank B. Brokken ---
Dear ppalka at gcc dot gnu.org, you wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100288
>
> Patrick Palka changed:
>
>What|Removed |Added
>
>Keywords||ice-on-invalid-code
>See Also||https://gcc.gnu.org/bugzill
>||a/show_bug.cgi?id=99599
>
> --- Comment #3 from Patrick Palka ---
> Agreed, the testcase looks invalid much like PR99599. One workaround for
> avoiding the constraint recursion here would be to change the signature of
>
> template
> inline void operator<<(CSVTabIns &, Type const )
>
> to something like
>
> template > U, OstreamInsertable
> Type>
> inline void operator<<(U &, Type const )
>
> so that the constraint OstreamInsertable is checked on this overload
> only
> if the first argument to << has the expected type.
>
> --
> You are receiving this mail because:
> You reported the bug.
Hi Patrick,
Thanks for your e-mail.
Since (AFAICS) you directly and only sent your e-mail to me I'm wondering
whether you want me to comment on your e-mail. It's getting kind of late here,
but I could send a more extensive reply tomorrow. Let me know if that's what
you want.
I tried your suggestion, and it seems to solve the issue. But at the same time
it puzzles me why
template
inline void operator<<(CSVTabIns &, Type const )
{}
won't be instantiated for FMT in
inline void operator<<(CSVTabIns , FMT::FMTHline hline)
{
tab << (*hline)(1); // insert hline in the next column
}
when FMT defines FMTHline as 'typedef FMT (*FMTHline)(unsigned)' and
std::ostream <<(std::ostream , FMT const )
is declared. I would have expected that
tab << (*hline)(1); // insert hline in the next column
would cause the compiler to instantiate
template
inline void operator<<(CSVTabIns &, Type const )
{}
for Type = FMT.
Maybe I'm missing something here? And it's also not something that caused the
compiler's internal error.
[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334 Thomas Rodgers changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-01 Status|UNCONFIRMED |ASSIGNED
[Bug rtl-optimization/100378] New: [Regression 9/10/11/12] arm64: lsl + asr used instead of sxth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100378
Bug ID: 100378
Summary: [Regression 9/10/11/12] arm64: lsl + asr used instead
of sxth
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: luc.vanoostenryck at gmail dot com
Target Milestone: ---
Created attachment 50727
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50727=edit
testcase
On arm64, when compiling with optimization, for example with -O2,
the following code:
struct sh {
short a;
short b;
short y[2];
};
int fooh(struct sh s) { return s.a; }
produces the following assembly code since GCC9.x:
fooh:
lsl x0, x0, 16
asr w0, w0, 16
ret
but with GCC8.x and before it produces the shorter:
fooh(sh):
sxthw0, w0
ret
See https://gcc.godbolt.org/z/YrW7E3cro
[Bug libstdc++/100376] __gnu_cxx::stdio_filebuf does not work correctly on windows for GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100376 --- Comment #2 from cqwrteur --- (In reply to cqwrteur from comment #1) > What thing very wierd is that the code runs correctly under wine but > incorrect on windows, even it is the same program. > > D:\hg\fast_io\.tmp\vdso>g++ -o test test.cc -Ofast -std=c++20 -s -flto > -march=native -I../../include > > D:\hg\fast_io\.tmp\vdso>test > 3 > 0 > > D:\hg\fast_io\.tmp\vdso>g++ -o test test.cc -Ofast -std=c++20 -s -flto > -march=native -I../../include -static > > D:\hg\fast_io\.tmp\vdso> > D:\hg\fast_io\.tmp\vdso>test > 3 > 3 > > It looks this is an issue with libstdc++.dll's abi?? maybe I missed > something here? Oh. i understand what is happening here. I installed too many versions of libstdc++.dll, they conflict with each other. Does windows have a version checker for dlls like Linux does?
[Bug rtl-optimization/100377] New: needless stack adjustment when passing struct in register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100377
Bug ID: 100377
Summary: needless stack adjustment when passing struct in
register
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: luc.vanoostenryck at gmail dot com
Target Milestone: ---
Created attachment 50726
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50726=edit
testcases
When compiling with optimization for example -O2), the following code:
struct sb {
signed char a;
char b;
short y[3];
};
struct ub {
unsigned char a;
char b;
short y[3];
};
int fsb(struct sb s) { return s.a; }
int fub(struct ub s) { return s.a; }
produces the following assembly code on arm64:
fsb:
sub sp, sp, #16
sxtbw0, w0
add sp, sp, 16
ret
fub:
sub sp, sp, #16
and w0, w0, 255
add sp, sp, 16
ret
the following on mips64:
fsb:
daddiu $sp,$sp,-16
dsll$2,$4,56
dsra$2,$2,56
j $31
daddiu $sp,$sp,16
fub:
daddiu $sp,$sp,-16
andi$2,$4,0xff
j $31
daddiu $sp,$sp,16
the following on riscv64:
fsb:
addisp,sp,-16
sllia0,a0,24
sraia0,a0,24
addisp,sp,16
jr ra
fub:
addisp,sp,-16
andia0,a0,0xff
addisp,sp,16
jr ra
OTOH, things seems OK on ppc64:
fsb:
extsb 3,3
blr
fub:
rlwinm 3,3,0,0xff
blr
and x86_64:
fsb:
movsx eax, dil
ret
fub:
movzx eax, dil
ret
Similar problems happen on 32-bit platforms too.
For example on arm32, the following code:
struct ub32 {
unsigned char a;
char b;
short y[1];
};
int fub32(struct ub32 s) { return s.a; }
produces:
fub32:
sub sp, sp, #8
uxtbr0, r0
add sp, sp, #8
bx lr
All these seem to happen on all versions.
See https://gcc.godbolt.org/z/x9zc1EnYn
Note: similar PRs exist but reported for x86_64 only
[Bug libstdc++/100376] __gnu_cxx::stdio_filebuf does not work correctly on windows for GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100376 --- Comment #1 from cqwrteur --- What thing very wierd is that the code runs correctly under wine but incorrect on windows, even it is the same program. D:\hg\fast_io\.tmp\vdso>g++ -o test test.cc -Ofast -std=c++20 -s -flto -march=native -I../../include D:\hg\fast_io\.tmp\vdso>test 3 0 D:\hg\fast_io\.tmp\vdso>g++ -o test test.cc -Ofast -std=c++20 -s -flto -march=native -I../../include -static D:\hg\fast_io\.tmp\vdso> D:\hg\fast_io\.tmp\vdso>test 3 3 It looks this is an issue with libstdc++.dll's abi?? maybe I missed something here?
[Bug libstdc++/100376] New: __gnu_cxx::stdio_filebuf does not work correctly on windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100376
Bug ID: 100376
Summary: __gnu_cxx::stdio_filebuf does not work correctly on
windows
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: unlvsur at live dot com
Target Milestone: ---
fast_io::posix_file pf("a.txt",fast_io::open_mode::out);
println(pf.fd);
__gnu_cxx::stdio_filebuf sb(pf.release(),std::ios::out);//pf.release()
returns file descriptor and release it
println(sb.fd());//this is wierd
//output:
3
0
Same program running on Linux
//output:
3
3
Same test for FILE*
fast_io::c_file cf("a.txt",fast_io::open_mode::out);
println(cf.fp);
__gnu_cxx::stdio_filebuf sb(cf.fp,std::ios::out);
println(sb.file());//this is weird
//output1:
0x7ffc035dfa90
0x0236101e0700
//output2:
0x7ffc035dfa90
0x020ce4bb0700
Same program running on Linux
0x017502a0
0x017502a0
[Bug c++/95291] ICE in resolve_args at gcc/cp/call.c:4482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95291 Patrick Palka changed: What|Removed |Added CC||janpmoeller at gmx dot de --- Comment #11 from Patrick Palka --- *** Bug 97749 has been marked as a duplicate of this bug. ***
[Bug c++/97749] ICE: Segmentation Fault on C++20 NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97749 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Patrick Palka --- We accept this testcase after r12-100, and it's not significantly different from the other testcases, so let's call this a dup of PR95291. *** This bug has been marked as a duplicate of bug 95291 ***
[Bug c++/99683] Deduction failure when using CTAD of CNTTP inside a deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99683 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |11.2 Resolution|--- |FIXED --- Comment #5 from Patrick Palka --- Fixed for GCC 11.2 and 12.
[Bug c++/99200] __PRETTY_FUNCTION__ used as template parameter causes internal compiler error (segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99200 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED CC||ppalka at gcc dot gnu.org Target Milestone|--- |11.2 Status|NEW |RESOLVED --- Comment #9 from Patrick Palka --- Fixed for GCC 11.2 and 12.
[Bug c++/95291] ICE in resolve_args at gcc/cp/call.c:4482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95291 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.2 --- Comment #10 from Patrick Palka --- Fixed for GCC 11.2 and 12.
[Bug c++/89565] [C++2a] ICE on template instantiating user defined non-type template from template value member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89565 Patrick Palka changed: What|Removed |Added Target Milestone|--- |11.2 Resolution|--- |FIXED Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org --- Comment #7 from Patrick Palka --- Fixed for GCC 11.2 and 12.
[Bug c++/89565] [C++2a] ICE on template instantiating user defined non-type template from template value member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89565 Bug 89565 depends on bug 93383, which changed state. Bug 93383 Summary: ICE on accessing field of a structure which is non-type template parameter, -std=c++2a https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93383 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/93383] ICE on accessing field of a structure which is non-type template parameter, -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93383 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.2 --- Comment #15 from Patrick Palka --- Fixed for GCC 11.2 and 12.
[Bug fortran/86206] ICE in gfc_resolve_forall, at fortran/resolve.c:9989
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86206 --- Comment #6 from anlauf at gcc dot gnu.org --- I agree that there is a strange bookkeeping issue. Swapping the order of the two functions in comment#0 makes the ICE go away. Printing forall_save, nvar, total_var in gfc_resolve_forall may give a clue what makes the difference.
[Bug c++/100288] [11/12 Regression] g++-11 internal error and fails to precompile a concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100288 Patrick Palka changed: What|Removed |Added Keywords||ice-on-invalid-code See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99599 --- Comment #3 from Patrick Palka --- Agreed, the testcase looks invalid much like PR99599. One workaround for avoiding the constraint recursion here would be to change the signature of template inline void operator<<(CSVTabIns &, Type const ) to something like template > U, OstreamInsertable Type> inline void operator<<(U &, Type const ) so that the constraint OstreamInsertable is checked on this overload only if the first argument to << has the expected type.
[Bug c++/99599] [11/12 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599 --- Comment #6 from Patrick Palka --- FWIW, one workaround for this kind of constraint looping is to encode the non-dependent conversion as a constraint. For this particular testcase, this would mean changing the signature of template auto invoke_tag(bar_tag, T it); to template T, fooable U> auto invoke_tag(T, U it);
[Bug target/100375] [12 Regression] trunk 20210501 ftbfs for nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100375 --- Comment #3 from Jakub Jelinek --- typedef struct basic_block_def *basic_block; typedef std::pair pseudo_node_t; So pseudo_node_t (nullptr, 0); or pseudo_node_t (NULL, 0); (given #ifdef __cplusplus #undef NULL #define NULL nullptr #endif )?
[Bug target/100375] [12 Regression] trunk 20210501 ftbfs for nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100375 --- Comment #2 from Jonathan Wakely --- What type is pseudo_node_t? If the pair members are pointers, use nullptr not 0.
[Bug target/100375] [12 Regression] trunk 20210501 ftbfs for nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100375 --- Comment #1 from Jakub Jelinek --- r12-220-gd96db15967e78d7cecea3b1cf3169ceb924678ac ?
[Bug target/100375] New: [12 Regression] trunk 20210501 ftbfs for nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100375 Bug ID: 100375 Summary: [12 Regression] trunk 20210501 ftbfs for nvptx-none Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- trunk 20210501 ftbfs for nvptx-none, trying to build the offload compiler with the just built trunk 20210501 x86_64-linux-gnu host build. ../../src-nvptx/gcc/config/nvptx/nvptx.c: In function 'void nvptx_sese_pseudo(basic_block, bb_sese*, int, int, vec*, size_t)': ../../src-nvptx/gcc/config/nvptx/nvptx.c:3754:42: error: call of overloaded 'pair(int, int)' is ambiguous 3754 | node_back = pseudo_node_t (0, 0); | ^ In file included from /packages/gcc/snap/gcc-snapshot-20210501/build/x86_64-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:64, from /packages/gcc/snap/gcc-snapshot-20210501/build/x86_64-linux-gnu/libstdc++-v3/include/bits/char_traits.h:39, from /packages/gcc/snap/gcc-snapshot-20210501/build/x86_64-linux-gnu/libstdc++-v3/include/ios:40, from /packages/gcc/snap/gcc-snapshot-20210501/build/x86_64-linux-gnu/libstdc++-v3/include/istream:38, from /packages/gcc/snap/gcc-snapshot-20210501/build/x86_64-linux-gnu/libstdc++-v3/include/sstream:38,
[Bug middle-end/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 Andi Kleen changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #12 from Andi Kleen --- It looks to me separate bugs are mixed together here. For example I looked at the preallocate_pmd warning again and I don't think there is any union there. Also I noticed that when I replace the *foo[N] with **foo it disappears. So I think that is something different. So there seem to be instances where such warnings happen without union members. Perhaps that one (and perhaps some others) need to be reanalyzed. I also looked at the intel_pm.c and I think that one is a real kernel bug, where the field accessed is really too small. I'll submit a patch for that.
[Bug c++/95486] ICE for alias CTAD with non-dependent argument and constrained constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95486 --- Comment #13 from Johel Ernesto Guerrero Peña --- You're right. I thought they were compiling against GCC trunk.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #56 from abebeos at lazaridis dot com --- Oh, Mr. Glaubitz, thank you for your opinion. It is you very personal choice to ignore "integration work" and label "reuse of existent results" as "copy". I assume this does not reflect on policies of your employer (physik.fu-berlin.de), because academia would not work without reuse & attribution. Lets see what other backers have to say, my efforts are clearly documented. Note to readers: Mr. Glaubitz is the same person which completely(!) ignored all my efforts subjecting this issue, e.g. talking like I do not exist (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c45). It is the same person who blocks(!) me on github projects, just for replying to users asking for info. He's a bit allergic to my individuality, I guess.
[Bug c++/100374] New: Type-constraints of member function templates should not be substituted into during implicit instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100374
Bug ID: 100374
Summary: Type-constraints of member function templates should
not be substituted into during implicit instantiation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
template
concept C = true;
template
struct Foo
{
template U>
void bar()
{
}
};
Foo f;
GCC trunk with -std=c++20 produces:
: In instantiation of 'struct Foo':
:13:12: required from here
:8:8: error: 'float' is not a class, struct, or union type
8 | void bar()
|^~~
[temp.inst]/17 says that type-constraints like C should
not be substituted into during the implicit instantiation of the declaration of
Foo::bar:
The type-constraints and requires-clause of a template specialization or member
function are not instantiated along with the specialization or function itself,
even for a member function of a local class; substitution into the atomic
constraints formed from them is instead performed as specified in
[temp.constr.decl] and [temp.constr.atomic] when determining whether the
constraints are satisfied or as specified in [temp.constr.decl] when comparing
declarations.
[Bug libstdc++/100238] [11/12 Regression] Link failure in debug libstdc++ on MinGW due to atomicitiy.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100238 Markus Böck changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #4 from Markus Böck --- Clean build fixed this. Closing
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #55 from John Paul Adrian Glaubitz --- (In reply to abebeos from comment #54) > Now, there is a strange tendency within this project to completely ignore my > work on this issue/bounty and my person, see e.g. here: You have no claim in this whole effort. You just tried to copy someone else's work.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #54 from abebeos at lazaridis dot com --- Bounty Claim: Please not that "saaadhu"s patch was "shelved". I integrated a validation-setup and tested several existent solutions, and identified during the "reuse existent work" phase of my work "saaadhus" patch as the best one of two patches (pipcet beeing the other one): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35 saaadhu continued the work at some point. My overall effort is described in summary here: https://github.com/abebeos/avr-gnu/blob/master/doc/README.md The test-setup which led to the validation of saaadhu result is here: https://github.com/abebeos/avr-gnu Now, there is a strange tendency within this project to completely ignore my work on this issue/bounty and my person, see e.g. here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c45 Very sad, the very very basic rule of "correct attribution" (within OSS and academia) seems to be non-existent. Not to talk about the behavior agains "worker" (because I'm a simple worker in the context here, working to get some income). Additionally, saaadhu never replied to private email, even not to the last one: " Hi there! It looks like bountysource has no functionality to split bounties, so we would need to agree to a way of processing the split. Are you ok with splitting the bounty 50/50? One possible process: - We tell the backers that we agreed - I claim the bounty - I get the amount granted on bountysource (this can take up to 2 weeks, because of the veto period and the many backers), - I file a bounty with 50% of the amount (around $3000) which you can claim nearly immediately. This way we avoid the payout delays (sometimes a week or more until money arrives on paypal), and all backers can see within a day that we've done the split. Please let me know if you have another suggestion. " correction: around $3500 - The flow within this ticket here shows clearly that i contributed significantly(!) to the fulfillment of this bounty, having invested multiple weeks. Backers may choose to ignore that fact. Or the may not.
[Bug target/97865] libtool needs to be updated for Darwin20.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #31 from CVS Commits --- The releases/gcc-9 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:3d29d0d630caac54dbcc6c3fb961258a011a30fc commit r9-9497-g3d29d0d630caac54dbcc6c3fb961258a011a30fc Author: Iain Sandoe Date: Wed Nov 18 10:06:03 2020 + Darwin : Update libtool and dependencies for Darwin20 [PR97865] The change in major version (and the increment from Darwin19 to 20) caused libtool tests to fail which resulted in incorrect build settings for shared libraries. We take this opportunity to sort out the shared undefined symbols state rather than propagating the current unsound behaviour into a new rev. This change means that we default to the case that missing symbols are considered an error, and if one wants to allow this intentionally, the confiuration for that case should be set appropriately. Three existing cases need undefined dynamic lookup: libitm, where there is already a configuration mechanism to add the flags. libcc1, where we add simple configuration to add the flags for Darwin. libsanitizer, where we can add to the existing extra flags. Backported from 1352bc88a0525743c952197fb2db6e4f8c091cde and 5dc998933e7aa737f4a45a8a2885d42d5288d51a libcc1/ChangeLog: PR target/97865 * Makefile.am: Add dynamic_lookup to LD flags for Darwin. * configure.ac: Test for Darwin host and set a flag. * Makefile.in: Regenerate. * configure: Regenerate. libitm/ChangeLog: PR target/97865 * configure.tgt: Add dynamic_lookup to XLDFLAGS for Darwin. * configure: Regenerate. libsanitizer/ChangeLog: PR target/97865 * configure.tgt: Add dynamic_lookup to EXTRA_CXXFLAGS for Darwin. * configure: Regenerate. ChangeLog: PR target/97865 * libtool.m4: Update handling of Darwin platform link flags for Darwin20. gcc/ChangeLog: PR target/97865 * configure: Regenerate. libatomic/ChangeLog: PR target/97865 * configure: Regenerate. libbacktrace/ChangeLog: PR target/97865 * configure: Regenerate. libffi/ChangeLog: PR target/97865 * configure: Regenerate. libgfortran/ChangeLog: PR target/97865 * configure: Regenerate. libgomp/ChangeLog: PR target/97865 * configure: Regenerate. libhsail-rt/ChangeLog: PR target/97865 * configure: Regenerate. libobjc/ChangeLog: PR target/97865 * configure: Regenerate. libphobos/ChangeLog: PR target/97865 * configure: Regenerate. libquadmath/ChangeLog: PR target/97865 * configure: Regenerate. libssp/ChangeLog: PR target/97865 * configure: Regenerate. libstdc++-v3/ChangeLog: PR target/97865 * configure: Regenerate. libvtv/ChangeLog: PR target/97865 * configure: Regenerate. zlib/ChangeLog: PR target/97865 * configure: Regenerate. Co-Authored-By: Jakub Jelinek
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #36 from CVS Commits --- The releases/gcc-9 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:6cfcaa4609ee3e3557ddf50fda00fdf9a5fc07e4 commit r9-9492-g6cfcaa4609ee3e3557ddf50fda00fdf9a5fc07e4 Author: Iain Sandoe Date: Mon Jan 18 20:09:10 2021 + dwarf2unwind : Force the CFA after remember/restore pairs [44107/48097]. This address one of the more long-standing and serious regressions for Darwin. GCC emits unwind code by default on the assumption that the unwinder will be (of have the same capability) as the one in the current libgcc_s. For Darwin platforms, this is not the case - some of them are based on the libgcc_s from GCC-4.2.1 and some are using the unwinder provided by libunwind (part of the LLVM project). The latter implementation has gradually adopted a section that deals with GNU unwind. The most serious problem for some of the platform versions is in handling DW_CFA_remember/restore_state pairs. The DWARF description talks about these in terms of saving/restoring register rows; this is what GCC originally did (and is what the unwinders do for the Darwin versions based on libgcc_s). However, in r118068, this was changed so that not only the registers but also the current frame address expression were saved. The unwind code assumes that the unwinder will do this; some of Darwin's unwinders do not, leading to lockups etc. To date, the only solution has been to replace the system libgcc_s with a newer one which is not a viable solution for many end-users (since that means overwritting the one provided with the system installation). The fix here provides a target hook that allows the target to specify that the CFA should be reinstated after a DW_CFA_restore. This fixes the issue (and also the closed WONTFIX of 44107). (As a matter of record, it also fixes reported Java issues if backported to GCC-5). gcc/ChangeLog: PR target/44107 PR target/48097 * config/darwin-protos.h (darwin_should_restore_cfa_state): New. * config/darwin.c (darwin_should_restore_cfa_state): New. * config/darwin.h (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New. * doc/tm.texi: Regenerated. * doc/tm.texi.in: Document TARGET_ASM_SHOULD_RESTORE_CFA_STATE. * dwarf2cfi.c (connect_traces): If the target requests, restore the CFA expression after a DW_CFA_restore. * target.def (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New hook. (cherry picked from commit 491d5b3cf8216f9285a67aa213b9a66b0035137b)
[Bug target/48097] gcc sometimes generates code that uses the buggy libgcc_s unwinder on darwin (originally exposed by Throw_2 failures in libjava testsuite under Xcode 4.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #20 from CVS Commits --- The releases/gcc-9 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:6cfcaa4609ee3e3557ddf50fda00fdf9a5fc07e4 commit r9-9492-g6cfcaa4609ee3e3557ddf50fda00fdf9a5fc07e4 Author: Iain Sandoe Date: Mon Jan 18 20:09:10 2021 + dwarf2unwind : Force the CFA after remember/restore pairs [44107/48097]. This address one of the more long-standing and serious regressions for Darwin. GCC emits unwind code by default on the assumption that the unwinder will be (of have the same capability) as the one in the current libgcc_s. For Darwin platforms, this is not the case - some of them are based on the libgcc_s from GCC-4.2.1 and some are using the unwinder provided by libunwind (part of the LLVM project). The latter implementation has gradually adopted a section that deals with GNU unwind. The most serious problem for some of the platform versions is in handling DW_CFA_remember/restore_state pairs. The DWARF description talks about these in terms of saving/restoring register rows; this is what GCC originally did (and is what the unwinders do for the Darwin versions based on libgcc_s). However, in r118068, this was changed so that not only the registers but also the current frame address expression were saved. The unwind code assumes that the unwinder will do this; some of Darwin's unwinders do not, leading to lockups etc. To date, the only solution has been to replace the system libgcc_s with a newer one which is not a viable solution for many end-users (since that means overwritting the one provided with the system installation). The fix here provides a target hook that allows the target to specify that the CFA should be reinstated after a DW_CFA_restore. This fixes the issue (and also the closed WONTFIX of 44107). (As a matter of record, it also fixes reported Java issues if backported to GCC-5). gcc/ChangeLog: PR target/44107 PR target/48097 * config/darwin-protos.h (darwin_should_restore_cfa_state): New. * config/darwin.c (darwin_should_restore_cfa_state): New. * config/darwin.h (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New. * doc/tm.texi: Regenerated. * doc/tm.texi.in: Document TARGET_ASM_SHOULD_RESTORE_CFA_STATE. * dwarf2cfi.c (connect_traces): If the target requests, restore the CFA expression after a DW_CFA_restore. * target.def (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New hook. (cherry picked from commit 491d5b3cf8216f9285a67aa213b9a66b0035137b)
[Bug bootstrap/100373] [12 Regression] Darwin, Compare-debug fail after r12-248-gb58dc0b803057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373 Iain Sandoe changed: What|Removed |Added Keywords||build Target||x86_64-darwin Last reconfirmed||2021-05-01 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug bootstrap/100373] New: [12 Regression] Darwin, Compare-debug fail after r12-248-gb58dc0b803057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373 Bug ID: 100373 Summary: [12 Regression] Darwin, Compare-debug fail after r12-248-gb58dc0b803057 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- Created attachment 50725 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50725=edit tarball with asm, objects and obj dumps. Exactly which cases fail seems to depend on the CPU in use and the OS version. For modern CPUs (xeon w, core i5 Skylake) the fail seems to be quite reliably in mpfr (which I build in tree). For older corei7 machines on Darwin16, I've seen also gcc/gcc.o as mismatched. I did a run with -save-temps -dp (asm attached). this is on x86_64-darwin20, but the problem is seen on x86_64-darwin* AFAICT. Backing out r12-248-gb58dc0b803057 allows bootstrap to succeed. attached: stage2-mpfr/src/gmp_op.o.stripped stage2-mpfr/src/gmp_op.o stage2-mpfr/src/gmp_op.s s2.txt == objdump -d -r stage2-mpfr/src/gmp_op.o.stripped >s2.txt stage3-mpfr/src/gmp_op.o.stripped stage3-mpfr/src/gmp_op.o stage3-mpfr/src/gmp_op.s s3.txt == objdump -d -r stage3-mpfr/src/gmp_op.o.stripped >s3.txt
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 Mark O'Donovan changed: What|Removed |Added CC||shiftee at posteo dot net --- Comment #53 from Mark O'Donovan --- As one of the BountySource contributors I received a notification about the claim today by user saadhu. The claim looks legit and I will approve but it could save lots of people having to validate the claim themselves if some senior person could give it their blessing. Thanks to all involved
[Bug c++/100372] New: ICE with variadic template template, internal compiler error: in strip_typedefs, at cp/tree.c:1544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100372 Bug ID: 100372 Summary: ICE with variadic template template, internal compiler error: in strip_typedefs, at cp/tree.c:1544 Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mcs at ifam dot uni-hannover.de Target Milestone: --- Created attachment 50724 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50724=edit File contains: command line, compiler output, preprocessed sources Minimal testcase with empty main(). Templates compile with 9.1.0 and 10.1.0 and work correctly in production code. Attachment contains all necessary information in a single text file. This is my first bug report; I apologize if the formatting is inconvenient.
[Bug fortran/100371] New: Fortran asynchronous I/O: ASAN (memory leak) + TASN (potential dead lock) warning with libgomp.fortran/async_io_*.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100371 Bug ID: 100371 Summary: Fortran asynchronous I/O: ASAN (memory leak) + TASN (potential dead lock) warning with libgomp.fortran/async_io_*.f90 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jb at gcc dot gnu.org, jvdelisle at gcc dot gnu.org Depends on: 100352 Target Milestone: --- Follow up to PR100352 Shows up in GCC 10 and mainline/12 when running libgomp.fortran/async_io_*.f90 with "gfortran -fopenmp" and ... (A) -fsanitize=thread WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=2980290) Mutex M25 acquired here while holding mutex M24 in main thread: #2 insert_unit ../../../repos/gcc/libgfortran/io/unit.c:244 LOCK (>lock); Mutex M24 previously acquired by the same thread here: #2 get_gfc_unit ../../../repos/gcc/libgfortran/io/unit.c:332 LOCK (_lock); Mutex M24 acquired here while holding mutex M25 in main thread: #2 close_unit_1 ../../../repos/gcc/libgfortran/io/unit.c:734 LOCK (_lock) Mutex M25 previously acquired by the same thread here: #2 get_gfc_unit ../../../repos/gcc/libgfortran/io/unit.c:380 TRYLOCK (>lock) * * * (B) -fsanitize=address / -fsanitize=leak * Direct leak of 80 byte(s) in 1 object(s) allocated from: #1 0x7ff684a15c54 in _gfortrani_enqueue_done_id ../../../repos/gcc/libgfortran/io/async.c:289 which is: enqueue_done_id (async_unit *au, enum aio_do type) ... transfer_queue *tq = calloc (sizeof (transfer_queue), 1); ... au->tail->next = tq; and should get freed in async_io (void *arg) which looks okay. * And I see a bunch of: #1 0x7f3da3491bb8 in _gfortrani_xmalloc ../../../repos/gcc/libgfortran/runtime/memory.c:38 (xmalloc is used throughout libgfortran/io/*.c) (C) On the other hand, valgrind shows: All heap blocks were freed -- no leaks are possible thus (B) might be a false positive. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100352 [Bug 100352] [11/12 Regression] libgomp.fortran/async_io_1.f90 -O0 execution test
[Bug c++/100370] New: [11.1.0 regression] Incorrect warning for placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100370
Bug ID: 100370
Summary: [11.1.0 regression] Incorrect warning for placement
new
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: foldy at rmki dot kfki.hu
Target Milestone: ---
With g++ 11.1.0:
tmp> cat test.cc
#include
int main()
{
struct s1 { int iv[4]; };
struct s2 { union { char* cp; int* ip; }; };
s2 b;
b.ip=new int[8];
new (b.ip+4) s1;
}
tmp> g++ -c test.cc
test.cc: In function 'int main()':
test.cc:10:12: warning: placement new constructing an object of type
'main()::s1' and size '16' in a region of type 'main()::s2' and size '0'
[-Wplacement-new=]
10 | new (b.ip+4) s1;
|^~
test.cc:8:6: note: at offset 16 from 'b' declared here
8 | s2 b;
| ^
g++ 10.2.1 is OK.
[Bug libgomp/100352] [11/12 Regression] libgomp.fortran/async_io_1.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100352 Tobias Burnus changed: What|Removed |Added Last reconfirmed||2021-05-01 Target Milestone|--- |11.2 Summary|libgomp.fortran/async_io_1. |[11/12 Regression] |f90 -O0 execution test |libgomp.fortran/async_io_1. ||f90 -O0 execution test Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #6 from Tobias Burnus --- For debugging, it helps: (a) to compile with -fsanitize=address,undefined or (here) -fsanitize=thread (b) to comment '#undef DEBUG_ASYNC' in libgfortran/io/async.h Issue introduced for PR99529 in r11-7647-ga6e9633ccb593937fceec67fafc2afe5d518d735 Patch: diff --git a/libgfortran/io/async.c b/libgfortran/io/async.c index d216ace1947..247008ca801 100644 --- a/libgfortran/io/async.c +++ b/libgfortran/io/async.c @@ -120 +120 @@ async_io (void *arg) - st_write_done_worker (au->pdt); + st_write_done_worker (au->pdt, false); @@ -126 +126 @@ async_io (void *arg) - st_read_done_worker (au->pdt); + st_read_done_worker (au->pdt, false); diff --git a/libgfortran/io/io.h b/libgfortran/io/io.h index e0007c6bfe5..3355bc2fd8d 100644 --- a/libgfortran/io/io.h +++ b/libgfortran/io/io.h @@ -1086 +1086 @@ extern void -st_write_done_worker (st_parameter_dt *); +st_write_done_worker (st_parameter_dt *, bool); @@ -1090 +1090 @@ extern void -st_read_done_worker (st_parameter_dt *); +st_read_done_worker (st_parameter_dt *, bool); diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c index 71a935652e3..36e35b48cd3 100644 --- a/libgfortran/io/transfer.c +++ b/libgfortran/io/transfer.c @@ -4340 +4340 @@ void -st_read_done_worker (st_parameter_dt *dtp) +st_read_done_worker (st_parameter_dt *dtp, bool unlock) @@ -4370 +4370,2 @@ st_read_done_worker (st_parameter_dt *dtp) - unlock_unit (dtp->u.p.current_unit); + if (unlock) + unlock_unit (dtp->u.p.current_unit); @@ -4397 +4398 @@ st_read_done (st_parameter_dt *dtp) - st_read_done_worker (dtp); /* Calls unlock_unit. */ + st_read_done_worker (dtp, true); /* Calls unlock_unit. */ @@ -4415 +4416 @@ void -st_write_done_worker (st_parameter_dt *dtp) +st_write_done_worker (st_parameter_dt *dtp, bool unlock) @@ -4466 +4467,2 @@ st_write_done_worker (st_parameter_dt *dtp) - unlock_unit (dtp->u.p.current_unit); + if (unlock) + unlock_unit (dtp->u.p.current_unit); @@ -4499 +4501 @@ st_write_done (st_parameter_dt *dtp) - st_write_done_worker (dtp); /* Calls unlock_unit. */ + st_write_done_worker (dtp, true); /* Calls unlock_unit. */
[Bug bootstrap/100350] [12 Regression] x86-64→PowerPC bootstrap fails since r12-228: error: '__LIBGCC_KF_MIN__' undeclared in expansion of macro 'RMIN'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100350 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tobias Burnus --- Close as FIXED.
[Bug target/100369] New: crash after error in gcc.target/aarch64/simd/vgetq_lane_s64_indices_1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100369 Bug ID: 100369 Summary: crash after error in gcc.target/aarch64/simd/vgetq_lane_s64_indices_1.c Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- For the source code file gcc.target/aarch64/simd/vgetq_lane_s64_indices_1.c, gcc trunk says: /home/pi/gcc/results.20210429/lib/gcc/arm-linux-gnueabihf/12.0.0/include/arm_neon.h:6313:10: error: lane -1 out of range 0 - 1 6313 | return (int64_t)__builtin_neon_vget_lanev2di (__a, __b); | ^~~~ during RTL pass: expand /home/pi/gcc/results.20210429/lib/gcc/arm-linux-gnueabihf/12.0.0/include/arm_neon.h: In function 'test_vgetq_lane_s64_before': /home/pi/gcc/results.20210429/lib/gcc/arm-linux-gnueabihf/12.0.0/include/arm_neon.h:6313:10: internal compiler error: in gen_neon_vget_lanev2di, at config/arm/neon.md:3372 0x1309813 gen_neon_vget_lanev2di(rtx_def*, rtx_def*, rtx_def*) ../../trunk/gcc/config/arm/neon.md:3372 The first error is good, but the internal compiler error isn't. There might be a better way to handle a lane number out of range than crashing.
