[Bug target/100461] [11/12 Regression] mingw build broken due to change of rdtsc implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461 --- Comment #4 from Daniel Starke --- Created attachment 50772 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50772=edit rdtsc.c Please find attached the mingw-w64 file.
[Bug target/82735] _mm256_zeroupper does not invalidate previously computed registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735 --- Comment #16 from Hongtao.liu --- (In reply to Hongtao.liu from comment #15) > (In reply to Hongtao.liu from comment #14) > > (In reply to Hongtao.liu from comment #12) > > > (In reply to Jakub Jelinek from comment #10) > > > > Last touched in PR99563. > > > > I guess for the explicit user vzeroupper we need to add the > > > > clobbers/sets > > > > earlier than in the vzeroupper pass, but ideally in a way that doesn't > > > > force > > > > save/restore of registers that aren't really needed in the function. > > > > > > Yes, if we want to add the clobbers/sets earlier(than CSE1), vzeroupper > > > pass > > > should be able to remove those unnecessary clobbers/sets. > > > > Correct typo, add the clobbers/sets earlier(than RA) > > I'm trying to add a post_reload splitter to add CLOBBERS of xmm to > vzeroupper so that LRA knows vzeroupper will kill those xmm registers, then > in pass_vzeroupper, transform those CLOBBERS to SET (xmm, xmm), it will > benifit post_reload CSE which allow lower 128bits to cross vzeroupper, then > in post_reload split2, drop those SETs, it's safe since there's no CSE > between split2 and split3, problem is there's no update for data flow info > between split2 and pro_and_epilog which mean even i manually drop those > SETS, xmm6-xmm15 are still marked as used which causes redudant save and > restore under 64-bit MSabi. > > I'm thinking of adding a target_hook for updating df info just in the > begenning of pass_pro_and_epilogue, the default behavior of the target_hook > is doing nothing , and in i386 backend, df_analyse is called only under > TARGET_AVX && cfun->machine->has_explicit_vzeroupper. Oh, regs_ever_live isn't recomputed, that's why even i manually drop those SETs is post_reload splitter, but xmm6 to xmm15 is still marked as live. /* After reload, some ports add certain bits to regs_ever_live so this cannot be reset. */
[Bug c++/100465] Overloading operator+= and including filesystem causes conflicting overload compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100465 --- Comment #1 from Ramchandra Apte --- (In reply to Ramchandra Apte from comment #0) > Created attachment 50771 [details] > Minimal example > > Adding an templated function overload for operator+= and including > causes a compilation error about conflicting overloads. The > code works on GCC versions <= 9.3 but does not work on GCC versions after > that. The code works on MSVC and Clang, so I believe this is a compiler bug. > I'm not sure, but I don't think the internal code of ought to > be seeing the overload in the global namespace. > > See attached error.cpp for minimal example. > > (Godbolt for error.cpp: https://godbolt.org/z/ccPvqf9K9 ) Note that the code works with Clang with libstdc++, so I believe this is a frontend bug.
[Bug c++/100465] New: Overloading operator+= and including filesystem causes conflicting overload compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100465 Bug ID: 100465 Summary: Overloading operator+= and including filesystem causes conflicting overload compilation error Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ramkapte at gmail dot com Target Milestone: --- Created attachment 50771 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50771=edit Minimal example which cau Adding an templated function overload for operator+= and including causes a compilation error about conflicting overloads. The code works on GCC versions <= 9.3 but does not work on GCC versions after that. The code works on MSVC and Clang, so I believe this is a compiler bug. I'm not sure, but I don't think the internal code of ought to be seeing the overload in the global namespace. See attached error.cpp for minimal example. (Godbolt for error.cpp: https://godbolt.org/z/ccPvqf9K9 )
[Bug target/98348] [10 Regression] GCC 10.2 AVX512 Mask regression from GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98348 --- Comment #22 from Hongtao.liu --- (In reply to Dávid Bolvanský from comment #20) > Some small regression (missed opportunity to use vptestnmd): > > Current trunk > > compare(unsigned int __vector(16)): > vpxor xmm1, xmm1, xmm1 > vpcmpd k0, zmm0, zmm1, 0 > vpmovm2d zmm0, k0 > ret > > GCC 9.2 > > compare(unsigned int __vector(16)): > vptestnmd k0, zmm0, zmm0 > vpmovm2d zmm0, k0 > ret > > > https://gcc.godbolt.org/z/5vK68jM3r A patch is posed at https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568210.html
[Bug target/94680] Missed optimization with __builtin_shuffle and zero vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94680 --- Comment #5 from Hongtao.liu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568571.html
[Bug target/99908] SIMD: negating logical + if_else has a suboptimal codegen.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99908 --- Comment #4 from Hongtao.liu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568785.html
[Bug target/100310] [AVX512] Missing support for v{,p}expand* instructions that w/o mask operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100310 --- Comment #1 from Hongtao.liu --- a patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-April/569248.html
[Bug middle-end/100267] gcc -O2 for avx512 instrincts generates extra warnings and less optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100267 --- Comment #6 from Hongtao.liu --- a patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-April/569248.html
[Bug preprocessor/100435] oddity in hash table use in libcpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100435 --- Comment #2 from Tom Tromey --- (In reply to Richard Biener from comment #1) > I think it's just an omission and indeed a bug. I can write a patch easily enough, but I don't have a good way to test it.
[Bug tree-optimization/100464] [11/12 Regression] emitted binary code changes when -g is enabled at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100464 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Component|c |tree-optimization Ever confirmed|0 |1 Summary|emitted binary code changes |[11/12 Regression] emitted |when -g is enabled at -O3 |binary code changes when -g ||is enabled at -O3 Last reconfirmed||2021-05-06 Status|UNCONFIRMED |NEW Version|unknown |12.0 Target Milestone|--- |11.2 Known to work||7.5.0 Known to fail||11.0 --- Comment #1 from Andrew Pinski --- Confirmed, the problem shows up in lim2.
[Bug preprocessor/97604] Bad digit separators accepted in pp-numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97604 Joseph S. Myers changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |12.0 --- Comment #2 from Joseph S. Myers --- Fixed for GCC 12.
[Bug c++/83873] adjacent digit separators are accepted in the exponent-part of floating-point literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83873 Joseph S. Myers changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Status|NEW |RESOLVED --- Comment #3 from Joseph S. Myers --- Fixed for GCC 12.
[Bug preprocessor/97604] Bad digit separators accepted in pp-numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97604 --- Comment #1 from CVS Commits --- The master branch has been updated by Joseph Myers : https://gcc.gnu.org/g:8f51cf38bb9628546effe66c070188d10f80b5ca commit r12-580-g8f51cf38bb9628546effe66c070188d10f80b5ca Author: Joseph Myers Date: Thu May 6 23:20:35 2021 + preprocessor: Fix pp-number lexing of digit separators [PR83873, PR97604] When the preprocessor lexes preprocessing numbers in lex_number, it accepts digit separators in more cases than actually permitted in pp-numbers by the standard syntax. One thing this accepts is adjacent digit separators; there is some code to reject those later, but as noted in bug 83873 it fails to cover the case of adjacent digit separators within a floating-point exponent. Accepting adjacent digit separators only results in a missing diagnostic, not in valid code being rejected or being accepted with incorrect semantics, because the correct lexing in such a case would have '' start the following preprocessing tokens, and no valid preprocessing token starts '' while ' isn't valid on its own as a preprocessing token either. So this patch fixes that case by moving the error for adjacent digit separators to lex_number (allowing a more specific diagnostic than if '' were excluded from the pp-number completely). Other cases inappropriately accepted involve digit separators before '.', 'e+', 'e-', 'p+' or 'p-' (or corresponding uppercase variants). In those cases, as shown by the test digit-sep-pp-number.C added, this can result in valid code being wrongly rejected as a result of too many characters being included in the pp-number. So this case is fixed by terminating the pp-number at the correct character according to the standard. That test also covers the case where a digit separator was followed by an identifier-nondigit that is not a nondigit (e.g. a UCN); that case was already handled correctly. Bootstrapped with no regressions for x86_64-pc-linux-gnu. libcpp/ PR c++/83873 PR preprocessor/97604 * lex.c (lex_number): Reject adjacent digit separators here. Do not allow digit separators before '.' or an exponent with sign. * expr.c (cpp_classify_number): Do not check for adjacent digit separators here. gcc/testsuite/ PR c++/83873 PR preprocessor/97604 * g++.dg/cpp1y/digit-sep-neg-2.C, g++.dg/cpp1y/digit-sep-pp-number.C: New tests. * g++.dg/cpp1y/digit-sep-line-neg.C, g++.dg/cpp1y/digit-sep-neg.C: Adjust expected messages.
[Bug c++/83873] adjacent digit separators are accepted in the exponent-part of floating-point literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83873 --- Comment #2 from CVS Commits --- The master branch has been updated by Joseph Myers : https://gcc.gnu.org/g:8f51cf38bb9628546effe66c070188d10f80b5ca commit r12-580-g8f51cf38bb9628546effe66c070188d10f80b5ca Author: Joseph Myers Date: Thu May 6 23:20:35 2021 + preprocessor: Fix pp-number lexing of digit separators [PR83873, PR97604] When the preprocessor lexes preprocessing numbers in lex_number, it accepts digit separators in more cases than actually permitted in pp-numbers by the standard syntax. One thing this accepts is adjacent digit separators; there is some code to reject those later, but as noted in bug 83873 it fails to cover the case of adjacent digit separators within a floating-point exponent. Accepting adjacent digit separators only results in a missing diagnostic, not in valid code being rejected or being accepted with incorrect semantics, because the correct lexing in such a case would have '' start the following preprocessing tokens, and no valid preprocessing token starts '' while ' isn't valid on its own as a preprocessing token either. So this patch fixes that case by moving the error for adjacent digit separators to lex_number (allowing a more specific diagnostic than if '' were excluded from the pp-number completely). Other cases inappropriately accepted involve digit separators before '.', 'e+', 'e-', 'p+' or 'p-' (or corresponding uppercase variants). In those cases, as shown by the test digit-sep-pp-number.C added, this can result in valid code being wrongly rejected as a result of too many characters being included in the pp-number. So this case is fixed by terminating the pp-number at the correct character according to the standard. That test also covers the case where a digit separator was followed by an identifier-nondigit that is not a nondigit (e.g. a UCN); that case was already handled correctly. Bootstrapped with no regressions for x86_64-pc-linux-gnu. libcpp/ PR c++/83873 PR preprocessor/97604 * lex.c (lex_number): Reject adjacent digit separators here. Do not allow digit separators before '.' or an exponent with sign. * expr.c (cpp_classify_number): Do not check for adjacent digit separators here. gcc/testsuite/ PR c++/83873 PR preprocessor/97604 * g++.dg/cpp1y/digit-sep-neg-2.C, g++.dg/cpp1y/digit-sep-pp-number.C: New tests. * g++.dg/cpp1y/digit-sep-line-neg.C, g++.dg/cpp1y/digit-sep-neg.C: Adjust expected messages.
[Bug c/100464] New: emitted binary code changes when -g is enabled at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100464
Bug ID: 100464
Summary: emitted binary code changes when -g is enabled at -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
For the following program, when I turn on and off the flag '-g', the emitted
binary code by gcc-trunk is difference.
$ cat small.c
int *a;
static int b, c, d, e, g, h;
int f;
void i() {
int *j[] = {, , , , , , , , , , ,
, , , , , , , , , , ,
, , , , , , , , , , };
int **k = [5];
for (; f;)
b |= *a;
*k =
}
int main() {}
$
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.PQ1fNP1RKJ-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210506 (experimental) [master revision
:60f7b28fb:e1fcf14f33e4f371aae8ae497ca58a760d53ca6d] (GCC)
$
$ gcc-trunk small.c -O3 -w ; objdump --disassemble a.out > "no-g.txt"
$ gcc-trunk small.c -O3 -w -g ; objdump --disassemble a.out > "g.txt"
$ diff no-g.txt g.txt
35,36c35,36
< 401043: 49 c7 c0 b0 11 40 00mov$0x4011b0,%r8
< 40104a: 48 c7 c1 40 11 40 00mov$0x401140,%rcx
---
> 401043: 49 c7 c0 d0 11 40 00mov$0x4011d0,%r8
> 40104a: 48 c7 c1 60 11 40 00mov$0x401160,%rcx
108,156c108,162
< 401128: 74 06 je 401130
< 40112a: eb fe jmp40112a
< 40112c: 0f 1f 40 00 nopl 0x0(%rax)
< 401130: c3 retq
< 401131: 66 2e 0f 1f 84 00 00nopw %cs:0x0(%rax,%rax,1)
< 401138: 00 00 00
< 40113b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
<
< 00401140 <__libc_csu_init>:
< 401140: f3 0f 1e fa endbr64
< 401144: 41 57 push %r15
< 401146: 4c 8d 3d f3 2c 00 00lea0x2cf3(%rip),%r15#
403e40 <__frame_dummy_init_array_entry>
< 40114d: 41 56 push %r14
< 40114f: 49 89 d6mov%rdx,%r14
< 401152: 41 55 push %r13
< 401154: 49 89 f5mov%rsi,%r13
< 401157: 41 54 push %r12
< 401159: 41 89 fcmov%edi,%r12d
< 40115c: 55 push %rbp
< 40115d: 48 8d 2d e4 2c 00 00lea0x2ce4(%rip),%rbp#
403e48 <__do_global_dtors_aux_fini_array_entry>
< 401164: 53 push %rbx
< 401165: 4c 29 fdsub%r15,%rbp
< 401168: 48 83 ec 08 sub$0x8,%rsp
< 40116c: e8 8f fe ff ff callq 401000 <_init>
< 401171: 48 c1 fd 03 sar$0x3,%rbp
< 401175: 74 1f je 401196 <__libc_csu_init+0x56>
< 401177: 31 db xor%ebx,%ebx
< 401179: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
< 401180: 4c 89 f2mov%r14,%rdx
< 401183: 4c 89 eemov%r13,%rsi
< 401186: 44 89 e7mov%r12d,%edi
< 401189: 41 ff 14 df callq *(%r15,%rbx,8)
< 40118d: 48 83 c3 01 add$0x1,%rbx
< 401191: 48 39 ddcmp%rbx,%rbp
< 401194: 75 ea jne401180 <__libc_csu_init+0x40>
< 401196: 48 83 c4 08 add$0x8,%rsp
< 40119a: 5b pop%rbx
< 40119b: 5d pop%rbp
< 40119c: 41 5c pop%r12
< 40119e: 41 5d pop%r13
< 4011a0: 41 5e pop%r14
< 4011a2: 41 5f pop%r15
< 4011a4: c3 retq
< 4011a5: 66 66 2e 0f 1f 84 00data16 nopw %cs:0x0(%rax,%rax,1)
< 4011ac: 00 00 00 00
<
< 004011b0 <__libc_csu_fini>:
< 4011b0: f3 0f 1e fa endbr64
< 4011b4: c3 retq
---
> 401128: 74 26 je 401150
> 40112a: 48 8b 15 07 2f 00 00mov0x2f07(%rip),%rdx#
> 404038
> 401131: 8b 05 09 2f 00 00 mov0x2f09(%rip),%eax#
> 404040
> 401137: 66 0f 1f 84 00 00 00nopw 0x0(%rax,%rax,1)
> 40
[Bug target/100461] [11/12 Regression] mingw build broken due to change of rdtsc implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461 --- Comment #3 from H.J. Lu --- What is in mingw-w64-crt/intrincs/rdtsc.c?
[Bug fortran/100440] allocated() gives True for unallocated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440 --- Comment #3 from Steve Kargl --- On Thu, May 06, 2021 at 09:31:49PM +, David.Smith at lmu dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440 > > --- Comment #2 from David.Smith at lmu dot edu --- > > With neither access to the actual code nor a reduced testcase, > > it will be virtually impossible to debug this problem. > > Right, I have enclosed a small program pulled out of my real application > that displays the error. Thanks for reduce this to a testcase. I don't see it attached to this email or in bugzilla. gcc.gno.org may have stripped the attachment (for some dumb reason). Feel free to send the test case to me, and I make sure it gets attached to the bug report. > > > Does the code run with the following compiler options: > > > -O0 -fno-frontend-optimize -fcheck=all > > Yes, it compiles and runs, giving the allocate error. > > > Does the code compile without warning if you use -Wall -Wextra? > > There are many warnings, and I think they may all be ignored for this > program: > > IUNKNO = -HUGE(I_TWO)/18 > Warning: Integer division truncated to constant ‘119304647’ > > (Yes, that is what we want) > > IF (MB%MP(2) /= MUNKNO .OR. MB%MP(3) /= 1) THEN > Warning: Inequality comparison for REAL(8) > > (This is a numerical analysis application -- it knows what it is > doing when it compares reals) > > KT1 = MWA%MP(J+1) > Warning: Possible change of value in conversion from REAL(8) to INTEGER(4) > > (ditto) > > TYPE(MULTI), SAVE, DIMENSION(LMBERN) :: MBERN > Warning: Array ‘mbern’ at (1) is larger than limit set by > ‘-fmax-stack-var-size=’, > moved from stack to static storage. > > (That's fine here) > > INTEGER :: J,JMA,JMW,N1,N2 > Warning: Unused variable ‘jma’ declared > > (I removed most of the routines in the full program to make a small > version that gives the error. Also removed some test code that uses > these 'unused' variables) > >IF (KRESLT /= 0) THEN >Warning: ‘kreslt’ may be used uninitialized in this function > > (ditto) > > > > I have attached the file "allocate_error.f95". Output (without the warnings): > > > gfortran allocate_error.f95 -o allocate_error -Wall -Wextra -O0 > -fno-frontend-optimize -fcheck=all > $ allocate_error > > > > Sample 10. Eigenvalue from matrix powers. > > Iterationeigenvalue approximation > > 0 1.0 > 21 j= 1 allocated(FMMATMUL21_FM(J)%MFM%mp) = T > size(FMMATMUL21_FM(J)%MFM%mp) =1 > allocate_error(29813,0x108292dc0) malloc: *** error for object > 0xb000: pointer being freed was not allocated > allocate_error(29813,0x108292dc0) malloc: *** set a breakpoint in > malloc_error_break to debug > > Program received signal SIGABRT: Process abort signal. > > Backtrace for this error: > #0 0x104c1ad3d > #1 0x104c1a16d > #2 0x7fff6f56042c > zsh: abort allocate_error The above malloc error suggests to me that you're possibly stepping off the end of an array. -fcheck=all should have caught that. :(
[Bug c++/100462] g++ fails to find a generated pre-compiled header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462 --- Comment #2 from Andrew Pinski --- Running GCC under strace (with -f option since GCC forks off to exec cc1plus). Should be able to see where the files are being tested for.
[Bug target/100461] [11/12 Regression] mingw build broken due to change of rdtsc implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-05-06 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #2 from Andrew Pinski --- To me this looks like a bug in mingw-w64-crt rather than a bug in GCC. A simple fix to the mingw-w64-crt sources is just do: unsigned __int64 (__rdtsc)(void)
[Bug other/100463] many errors using GTY and hash_map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100463 --- Comment #5 from Martin Sebor --- Created attachment 50770 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50770=edit Patch to complete GTY support for hash_map. Patch to add support for GTY hash_map for all integer types.
[Bug fortran/100440] allocated() gives True for unallocated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440 --- Comment #2 from David.Smith at lmu dot edu --- > With neither access to the actual code nor a reduced testcase, > it will be virtually impossible to debug this problem. Right, I have enclosed a small program pulled out of my real application that displays the error. > Does the code run with the following compiler options: > -O0 -fno-frontend-optimize -fcheck=all Yes, it compiles and runs, giving the allocate error. > Does the code compile without warning if you use -Wall -Wextra? There are many warnings, and I think they may all be ignored for this program: IUNKNO = -HUGE(I_TWO)/18 Warning: Integer division truncated to constant ‘119304647’ (Yes, that is what we want) IF (MB%MP(2) /= MUNKNO .OR. MB%MP(3) /= 1) THEN Warning: Inequality comparison for REAL(8) (This is a numerical analysis application -- it knows what it is doing when it compares reals) KT1 = MWA%MP(J+1) Warning: Possible change of value in conversion from REAL(8) to INTEGER(4) (ditto) TYPE(MULTI), SAVE, DIMENSION(LMBERN) :: MBERN Warning: Array ‘mbern’ at (1) is larger than limit set by ‘-fmax-stack-var-size=’, moved from stack to static storage. (That's fine here) INTEGER :: J,JMA,JMW,N1,N2 Warning: Unused variable ‘jma’ declared (I removed most of the routines in the full program to make a small version that gives the error. Also removed some test code that uses these 'unused' variables) IF (KRESLT /= 0) THEN Warning: ‘kreslt’ may be used uninitialized in this function (ditto) I have attached the file "allocate_error.f95". Output (without the warnings): gfortran allocate_error.f95 -o allocate_error -Wall -Wextra -O0 -fno-frontend-optimize -fcheck=all $ allocate_error Sample 10. Eigenvalue from matrix powers. Iterationeigenvalue approximation 0 1.0 21 j= 1 allocated(FMMATMUL21_FM(J)%MFM%mp) = T size(FMMATMUL21_FM(J)%MFM%mp) =1 allocate_error(29813,0x108292dc0) malloc: *** error for object 0xb000: pointer being freed was not allocated allocate_error(29813,0x108292dc0) malloc: *** set a breakpoint in malloc_error_break to debug Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x104c1ad3d #1 0x104c1a16d #2 0x7fff6f56042c zsh: abort allocate_error Thanks for your help, David Smith From: kargl at gcc dot gnu.org Sent: Wednesday, May 5, 2021 5:22 PM To: Smith, David Subject: [Bug fortran/100440] allocated() gives True for unallocated variable https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- With neither access to the actual code nor a reduced testcase, it will be virtually impossible to debug this problem. Does the code run with the following compiler options: -O0 -fno-frontend-optimize -fcheck=all Does the code compile without warning if you use -Wall -Wextra? -- You are receiving this mail because: You reported the bug.
[Bug other/100463] many errors using GTY and hash_map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100463
--- Comment #4 from Martin Sebor ---
So besides the hash_map GTY support being incomplete it also seems like ggc.h
support is missing something. The following change to the header lets the
whole patch below compile:
diff --git a/gcc/ggc.h b/gcc/ggc.h
index 65f6cb4d19d..9feeffc0f06 100644
--- a/gcc/ggc.h
+++ b/gcc/ggc.h
@@ -347,4 +347,9 @@ gt_pch_nx (unsigned int)
{
}
+inline void
+gt_pch_nx (long int)
+{
+}
+
#endif
So to use a hash_map from HWI to int the following appears necessary. But if I
need unsigned HWI I have to repeat the whole exercise yet again.
diff --git a/gcc/except.c b/gcc/except.c
index a7902bbd555..a47841cf395 100644
--- a/gcc/except.c
+++ b/gcc/except.c
@@ -149,6 +149,21 @@ static GTY(()) int call_site_base;
static GTY(()) hash_map *type_to_runtime_map;
+typedef int_hash test_int_hash_t;
+typedef hash_map test_int_hash_map_t;
+static GTY(()) test_int_hash_map_t *test_int_hash_map;
+
+inline void
+gt_ggc_mx (test_int_hash_t *)
+{
+}
+
+inline void
+gt_pch_nx (test_int_hash_t *)
+{
+}
+
+
static GTY(()) tree setjmp_fn;
/* Describe the SjLj_Function_Context structure. */
diff --git a/gcc/ggc.h b/gcc/ggc.h
index 65f6cb4d19d..9feeffc0f06 100644
--- a/gcc/ggc.h
+++ b/gcc/ggc.h
@@ -347,4 +347,9 @@ gt_pch_nx (unsigned int)
{
}
+inline void
+gt_pch_nx (long int)
+{
+}
+
#endif
diff --git a/gcc/hash-map.h b/gcc/hash-map.h
index 0779c930f0a..c07bd04704f 100644
--- a/gcc/hash-map.h
+++ b/gcc/hash-map.h
@@ -114,6 +114,11 @@ class GTY((user)) hash_map
static void
pch_nx_helper (unsigned int, gt_pointer_operator, void *)
+ {
+ }
+
+static void
+ pch_nx_helper (long int, gt_pointer_operator, void *)
{
}
[Bug other/100463] many errors using GTY and hash_map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100463
--- Comment #3 from Martin Sebor ---
As it turns out, the hash_map primary template is incomplete. Defining the
following member fixes that error only to expose another:
index 0779c930f0a..c07bd04704f 100644
--- a/gcc/hash-map.h
+++ b/gcc/hash-map.h
@@ -114,6 +114,11 @@ class GTY((user)) hash_map
static void
pch_nx_helper (unsigned int, gt_pointer_operator, void *)
+ {
+ }
+
+static void
+ pch_nx_helper (long int, gt_pointer_operator, void *)
{
}
In file included from /ssd/src/gcc/trunk/gcc/hash-table.h:595,
from /ssd/src/gcc/trunk/gcc/coretypes.h:480,
from /ssd/src/gcc/trunk/gcc/except.c:114:
/ssd/src/gcc/trunk/gcc/hash-map.h: In instantiation of ‘static void hash_map<
, ,
>::hash_entry::pch_nx(hash_map< ,
, >::hash_entry&) [with KeyId
= int_hash; Value = int; Traits =
simple_hashmap_traits >, int>]’:
/ssd/src/gcc/trunk/gcc/hash-table.h:1198:17: required from ‘void
gt_pch_nx(hash_table*) [with D = hash_map, int>::hash_entry]’
/ssd/src/gcc/trunk/gcc/hash-map.h:319:13: required from ‘void
gt_pch_nx(hash_map*) [with K = int_hash; V = int; H =
simple_hashmap_traits >, int>]’
./gt-except.h:97:19: required from here
/ssd/src/gcc/trunk/gcc/hash-map.h:87:12: error: call of overloaded
‘gt_pch_nx(hash_map, int>::Key&)’ is
ambiguous
gt_pch_nx (e.m_key);
~~^
In file included from /ssd/src/gcc/trunk/gcc/hash-table.h:247,
from /ssd/src/gcc/trunk/gcc/coretypes.h:480,
from /ssd/src/gcc/trunk/gcc/except.c:114:
/ssd/src/gcc/trunk/gcc/ggc.h:341:1: note: candidate: ‘void gt_pch_nx(int)’
gt_pch_nx (int)
^
/ssd/src/gcc/trunk/gcc/ggc.h:346:1: note: candidate: ‘void gt_pch_nx(unsigned
int)’
gt_pch_nx (unsigned int)
^
[Bug other/100463] many errors using GTY and hash_map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100463
--- Comment #2 from Martin Sebor ---
But suppose I change my mind and want to define a map from HWI_INT to int:
diff --git a/gcc/except.c b/gcc/except.c
index a7902bbd555..a47841cf395 100644
--- a/gcc/except.c
+++ b/gcc/except.c
@@ -149,6 +149,21 @@ static GTY(()) int call_site_base;
static GTY(()) hash_map *type_to_runtime_map;
+typedef int_hash test_int_hash_t;
+typedef hash_map test_int_hash_map_t;
+static GTY(()) test_int_hash_map_t *test_int_hash_map;
+
+inline void
+gt_ggc_mx (test_int_hash_t *)
+{
+}
+
+inline void
+gt_pch_nx (test_int_hash_t *)
+{
+}
+
+
static GTY(()) tree setjmp_fn;
/* Describe the SjLj_Function_Context structure. */
I now get another series of errors:
In file included from /ssd/src/gcc/trunk/gcc/hash-table.h:595,
from /ssd/src/gcc/trunk/gcc/coretypes.h:480,
from /ssd/src/gcc/trunk/gcc/except.c:114:
/ssd/src/gcc/trunk/gcc/hash-map.h: In instantiation of ‘static void hash_map<
, ,
>::hash_entry::pch_nx(hash_map< ,
, >::hash_entry&) [with KeyId
= int_hash; Value = int; Traits =
simple_hashmap_traits >, int>]’:
/ssd/src/gcc/trunk/gcc/hash-table.h:1198:17: required from ‘void
gt_pch_nx(hash_table*) [with D = hash_map, int>::hash_entry]’
/ssd/src/gcc/trunk/gcc/hash-map.h:314:13: required from ‘void
gt_pch_nx(hash_map*) [with K = int_hash; V = int; H =
simple_hashmap_traits >, int>]’
./gt-except.h:97:19: required from here
/ssd/src/gcc/trunk/gcc/hash-map.h:87:12: error: call of overloaded
‘gt_pch_nx(hash_map, int>::Key&)’ is
ambiguous
gt_pch_nx (e.m_key);
~~^
In file included from /ssd/src/gcc/trunk/gcc/hash-table.h:247,
from /ssd/src/gcc/trunk/gcc/coretypes.h:480,
from /ssd/src/gcc/trunk/gcc/except.c:114:
/ssd/src/gcc/trunk/gcc/ggc.h:341:1: note: candidate: ‘void gt_pch_nx(int)’
gt_pch_nx (int)
^
/ssd/src/gcc/trunk/gcc/ggc.h:346:1: note: candidate: ‘void gt_pch_nx(unsigned
int)’
gt_pch_nx (unsigned int)
^
In file included from /ssd/src/gcc/trunk/gcc/hash-table.h:595,
from /ssd/src/gcc/trunk/gcc/coretypes.h:480,
from /ssd/src/gcc/trunk/gcc/except.c:114:
/ssd/src/gcc/trunk/gcc/hash-map.h: In instantiation of ‘static void hash_map<
, ,
>::hash_entry::pch_nx_helper(T&, gt_pointer_operator, void*) [with T = long
int; KeyId = int_hash; Value = int; Traits =
simple_hashmap_traits >, int>; gt_pointer_operator = void (*)(void*, void*)]’:
/ssd/src/gcc/trunk/gcc/hash-map.h:93:16: required from ‘static void hash_map<
, ,
>::hash_entry::pch_nx(hash_map< ,
, >::hash_entry&,
gt_pointer_operator, void*) [with KeyId = int_hash; Value = int; Traits =
simple_hashmap_traits >, int>; gt_pointer_operator = void (*)(void*, void*)]’
/ssd/src/gcc/trunk/gcc/hash-table.h:1181:17: required from ‘void
hashtab_entry_note_pointers(void*, void*, gt_pointer_operator, void*) [with D =
hash_map, int>::hash_entry;
gt_pointer_operator = void (*)(void*, void*)]’
/ssd/src/gcc/trunk/gcc/hash-table.h:1190:26: required from ‘void
gt_pch_nx(hash_table*) [with D = hash_map, int>::hash_entry]’
/ssd/src/gcc/trunk/gcc/hash-map.h:314:13: required from ‘void
gt_pch_nx(hash_map*) [with K = int_hash; V = int; H =
simple_hashmap_traits >, int>]’
./gt-except.h:97:19: required from here
/ssd/src/gcc/trunk/gcc/hash-map.h:107:14: error: no matching function for call
to ‘gt_pch_nx(long int*, void (*&)(void*, void*), void*&)’
gt_pch_nx (, op, cookie);
~~^~~~
In file included from /ssd/src/gcc/trunk/gcc/coretypes.h:454,
from /ssd/src/gcc/trunk/gcc/except.c:114:
/ssd/src/gcc/trunk/gcc/wide-int.h:3335:1: note: candidate: ‘template
void gt_pch_nx(generic_wide_int*)’
gt_pch_nx (generic_wide_int *)
^
/ssd/src/gcc/trunk/gcc/wide-int.h:3335:1: note: template argument
deduction/substitution failed:
In file included from /ssd/src/gcc/trunk/gcc/hash-table.h:595,
from /ssd/src/gcc/trunk/gcc/coretypes.h:480,
from /ssd/src/gcc/trunk/gcc/except.c:114:
/ssd/src/gcc/trunk/gcc/hash-map.h:107:14: note: mismatched types
‘generic_wide_int’ and ‘long int’
gt_pch_nx (, op, cookie);
~~^~~~
In file included from /ssd/src/gcc/trunk/gcc/coretypes.h:454,
from /ssd/src/gcc/trunk/gcc/except.c:114:
/ssd/src/gcc/trunk/gcc/wide-int.h:3341:1: note: candidate: ‘template
void gt_pch_nx(generic_wide_int*, void (*)(void*, void*), void*)’
gt_pch_nx (generic_wide_int *, void (*) (void *, void *), void *)
^
/ssd/src/gcc/trunk/gcc/wide-int.h:3341:1: note: template argument
deduction/substitution failed:
In file included from /ssd/src/gcc/trunk/gcc/hash-table.h:595,
from /ssd/src/gcc/trunk/gcc/coretypes.h:480,
from /ssd/src/gcc/trunk/gcc/except.c:114:
/ssd/src/gcc/trunk/gcc/hash-map.h:107:14: note: mismatched types
‘generic_wide_int’ and ‘long int’
gt_pch_nx (, op,
[Bug other/100463] many errors using GTY and hash_map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100463
--- Comment #1 from Martin Sebor ---
Adding the two missing function like below fixes the errors.
diff --git a/gcc/except.c b/gcc/except.c
index a7902bbd555..913632f5199 100644
--- a/gcc/except.c
+++ b/gcc/except.c
@@ -149,6 +149,21 @@ static GTY(()) int call_site_base;
static GTY(()) hash_map *type_to_runtime_map;
+typedef int_hash test_int_hash_t;
+typedef hash_map test_int_hash_map_t;
+static GTY(()) test_int_hash_map_t *test_int_hash_map;
+
+inline void
+gt_ggc_mx (test_int_hash_t *)
+{
+}
+
+inline void
+gt_pch_nx (test_int_hash_t *)
+{
+}
+
+
static GTY(()) tree setjmp_fn;
/* Describe the SjLj_Function_Context structure. */
[Bug other/100463] New: many errors using GTY and hash_map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100463 Bug ID: 100463 Summary: many errors using GTY and hash_map Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- Trying to use a simple hash_map specialization with GTY is a horrible experience in debugging obscure template errors. For example, in the trivial patch below I'd like to define a hash_map from int to int in a file that already uses a GTY hash_map. It seems that it should be straightforward but: diff --git a/gcc/except.c b/gcc/except.c index a7902bbd555..1671847d00e 100644 --- a/gcc/except.c +++ b/gcc/except.c @@ -149,6 +149,10 @@ static GTY(()) int call_site_base; static GTY(()) hash_map *type_to_runtime_map; +typedef int_hash test_int_hash_t; +typedef hash_map test_int_hash_map_t; +static GTY(()) test_int_hash_map_t *test_int_hash_map; + static GTY(()) tree setjmp_fn; /* Describe the SjLj_Function_Context structure. */ ...the patch leads to the following errors: In file included from /ssd/src/gcc/trunk/gcc/except.c:3525: ./gt-except.h: In function ‘void gt_ggc_mx(int_hash&)’: ./gt-except.h:62:21: error: no matching function for call to ‘gt_ggc_mx(int_hash*)’ gt_ggc_mx (&((*x))); ^ In file included from /ssd/src/gcc/trunk/gcc/coretypes.h:454, from /ssd/src/gcc/trunk/gcc/except.c:114: /ssd/src/gcc/trunk/gcc/wide-int.h:3329:1: note: candidate: ‘template void gt_ggc_mx(generic_wide_int*)’ gt_ggc_mx (generic_wide_int *) ^ /ssd/src/gcc/trunk/gcc/wide-int.h:3329:1: note: template argument deduction/substitution failed: In file included from /ssd/src/gcc/trunk/gcc/except.c:3525: ./gt-except.h:62:21: note: ‘int_hash’ is not derived from ‘generic_wide_int’ gt_ggc_mx (&((*x))); ^ In file included from /ssd/src/gcc/trunk/gcc/coretypes.h:454, from /ssd/src/gcc/trunk/gcc/except.c:114: /ssd/src/gcc/trunk/gcc/wide-int.h:3347:1: note: candidate: ‘template void gt_ggc_mx(trailing_wide_ints*)’ gt_ggc_mx (trailing_wide_ints *) ^ /ssd/src/gcc/trunk/gcc/wide-int.h:3347:1: note: template argument deduction/substitution failed: In file included from /ssd/src/gcc/trunk/gcc/except.c:3525: ./gt-except.h:62:21: note: ‘int_hash’ is not derived from ‘trailing_wide_ints’ gt_ggc_mx (&((*x))); ^ In file included from /ssd/src/gcc/trunk/gcc/coretypes.h:469, from /ssd/src/gcc/trunk/gcc/except.c:114: /ssd/src/gcc/trunk/gcc/poly-int.h:2708:1: note: candidate: ‘template void gt_ggc_mx(poly_int_pod*)’ gt_ggc_mx (poly_int_pod *) ^ /ssd/src/gcc/trunk/gcc/poly-int.h:2708:1: note: template argument deduction/substitution failed: In file included from /ssd/src/gcc/trunk/gcc/except.c:3525: ./gt-except.h:62:21: note: ‘int_hash’ is not derived from ‘poly_int_pod’ gt_ggc_mx (&((*x))); ^ In file included from /ssd/src/gcc/trunk/gcc/coretypes.h:472, from /ssd/src/gcc/trunk/gcc/except.c:114: /ssd/src/gcc/trunk/gcc/machmode.h:1190:1: note: candidate: ‘template void gt_ggc_mx(pod_mode*)’ gt_ggc_mx (pod_mode *) ^ /ssd/src/gcc/trunk/gcc/machmode.h:1190:1: note: template argument deduction/substitution failed: In file included from /ssd/src/gcc/trunk/gcc/except.c:3525: ./gt-except.h:62:21: note: ‘int_hash’ is not derived from ‘pod_mode’ gt_ggc_mx (&((*x))); ^ In file included from /ssd/src/gcc/trunk/gcc/hash-table.h:247, from /ssd/src/gcc/trunk/gcc/coretypes.h:480, from /ssd/src/gcc/trunk/gcc/except.c:114: /ssd/src/gcc/trunk/gcc/ggc.h:325:1: note: candidate: ‘void gt_ggc_mx(const char*)’ gt_ggc_mx (const char *s) ^ /ssd/src/gcc/trunk/gcc/ggc.h:325:1: note: no known conversion for argument 1 from ‘int_hash*’ to ‘const char*’ /ssd/src/gcc/trunk/gcc/ggc.h:336:1: note: candidate: ‘void gt_ggc_mx(int)’ gt_ggc_mx (int) ^ /ssd/src/gcc/trunk/gcc/ggc.h:336:1: note: conversion of argument 1 would be ill-formed: In file included from /ssd/src/gcc/trunk/gcc/except.c:3525: ./gt-except.h:62:14: error: invalid conversion from ‘int_hash*’ to ‘int’ [-fpermissive] gt_ggc_mx (&((*x))); ^~~ In file included from /ssd/src/gcc/trunk/gcc/hash-table.h:248, from /ssd/src/gcc/trunk/gcc/coretypes.h:480, from /ssd/src/gcc/trunk/gcc/except.c:114: /ssd/src/gcc/trunk/gcc/vec.h:1349:1: note: candidate: ‘template void gt_ggc_mx(vec*)’ gt_ggc_mx (vec *v) ^ /ssd/src/gcc/trunk/gcc/vec.h:1349:1: note: template argument deduction/substitution failed: In file included from /ssd/src/gcc/trunk/gcc/except.c:3525: ./gt-except.h:62:21: note: ‘int_hash’ is not derived from ‘vec’ gt_ggc_mx (&((*x)));
[Bug target/100461] [11/12 Regression] mingw build broken due to change of rdtsc implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461 Uroš Bizjak changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #1 from Uroš Bizjak --- CC author.
[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
liblfds admin changed:
What|Removed |Added
CC||liblfds_gccbz at winterflaw
dot ne
||t
--- Comment #32 from liblfds admin ---
(In reply to Andrew Pinski from comment #31)
> Again the problem is stuff like:
> static const _Atomic __int128_t t = 2000;
>
> __int128_t g(void)
> {
> return t;
> }
>
> DOES NOT WORK if you use CAS (or ldaxp/stlxp).
>
> So clang is broken really
>
> Also GCC for ARM64 emits calls for all compare and exchange because using
> the LSE (from ARMv8.1-a) is useful.
It may be a case of selecting the lesser of two evils.
The problem for me, as an author of a lock-free data structure library, is that
a mutex is not repeat NOT a replacement for a compare-exchange instruction.
This is because lock-free data structures possess the property of not sleeping.
Such data structures are used in kernels, at times and in places where
sleeping is absolutely forbidden and will cause the kernel to panic.
Accordingly, replacing an atomic exchange with a mutex does *not* provide
identical functionality - an atomic exchange works fine, a mutex makes the
kernel panic.
To reiterate : I write a library of lock-free data structures, and on the face
of it you would then think I would be a prime user of libatomic, and I
*specifically* MUST avoid libatomic, and indeed have basically implemented my
own, because of how libatomic behaves.
It's crazy that people writing lock-free data structure must specifically
ensure and guarantee they absolutely do not touch libatomic,
[Bug c++/100462] g++ fails to find a generated pre-compiled header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462 --- Comment #1 from Marco Trevisan --- Some verbose logging: unstable /data/GNOME/gjs ❯ echo $PWD /data/GNOME/gjs unstable /data/GNOME/gjs ❯ ls _build/libgjs.so.0.0.0.p -lht total 119M -rw-rw-r-- 1 marco marco 119M mag 6 22:37 gjs_pch.hh.gch -rw-rw-r-- 1 marco marco 43K mag 6 22:37 libgjs-private_gjs-gdbus-wrapper.c.o -rw-rw-r-- 1 marco marco 21K mag 6 22:37 libgjs-private_gjs-util.c.o -rw-rw-r-- 1 marco marco 251K mag 6 22:37 meson-generated_.._js-resources.c.o -rw-rw-r-- 1 marco marco 3,2K mag 6 22:37 gjs_gi_probes.o -rw-rw-r-- 1 marco marco 1,5K mag 6 22:37 gjs_gi_probes.h -rw-rw-r-- 1 marco marco 186 mag 6 22:37 GjsPrivate_1.0_gir_filelist g++ -v -Ilibgjs.so.0.0.0.p -I. -I.. -I/opt/dev/GNOME/include/glib-2.0 -I/opt/dev/GNOME/lib/glib-2.0/include -I/opt/dev/GNOME/include/gobject-introspection-1.0 -I/opt/dev/GNOME/include/pixman-1 -I/usr/include/cairo -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -fvisibility=hidden -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -std=c++17 -fno-rtti -g -fno-strict-aliasing -Wno-variadic-macros -Wno-missing-field-initializers -fno-semantic-interposition -fPIC -pthread -isystem/opt/dev/GNOME/include/sysprof-4 -include /usr/include/mozjs-78/js/RequiredDefines.h -isystem /usr/include/mozjs-78 -DGJS_COMPILATION '-DGJS_JS_DIR="/usr/local/share/gjs-1.0"' '-DPKGLIBDIR="/usr/local/lib/x86_64-linux-gnu/gjs"' '-DG_LOG_DOMAIN="Gjs"' -fpch-preprocess -include gjs_pch.hh -MD -MQ libgjs.so.0.0.0.p/gi_arg-cache.cpp.o -MF libgjs.so.0.0.0.p/gi_arg-cache.cpp.o.d -o libgjs.so.0.0.0.p/gi_arg-cache.cpp.o -c ../gi/arg-cache.cpp Using built-in specs. COLLECT_GCC=g++ OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 10.3.0-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-10-gDeRY6/gcc-10-10.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-gDeRY6/gcc-10-10.3.0/debian/tmp-gcn/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1) COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-v' '-I' 'libgjs.so.0.0.0.p' '-I' '.' '-I' '..' '-I' '/opt/dev/GNOME/include/glib-2.0' '-I' '/opt/dev/GNOME/lib/glib-2.0/include' '-I' '/opt/dev/GNOME/include/gobject-introspection-1.0' '-I' '/opt/dev/GNOME/include/pixman-1' '-I' '/usr/include/cairo' '-I' '/usr/include/uuid' '-I' '/usr/include/freetype2' '-I' '/usr/include/libpng16' '-fvisibility=hidden' '-pipe' '-D' '_FILE_OFFSET_BITS=64' '-Wall' '-Winvalid-pch' '-Wnon-virtual-dtor' '-Wextra' '-std=c++17' '-fno-rtti' '-g' '-fno-strict-aliasing' '-Wno-variadic-macros' '-Wno-missing-field-initializers' '-fno-semantic-interposition' '-fPIC' '-pthread' '-isystem' '/opt/dev/GNOME/include/sysprof-4' '-include' '/usr/include/mozjs-78/js/RequiredDefines.h' '-isystem' '/usr/include/mozjs-78' '-D' 'GJS_COMPILATION' '-D' 'GJS_JS_DIR="/usr/local/share/gjs-1.0"' '-D' 'PKGLIBDIR="/usr/local/lib/x86_64-linux-gnu/gjs"' '-D' 'G_LOG_DOMAIN="Gjs"' '-fpch-preprocess' '-include' 'gjs_pch.hh' '-MD' '-MQ' 'libgjs.so.0.0.0.p/gi_arg-cache.cpp.o' '-MF' 'libgjs.so.0.0.0.p/gi_arg-cache.cpp.o.d' '-o' 'libgjs.so.0.0.0.p/gi_arg-cache.cpp.o' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/10/cc1plus -quiet -v -I libgjs.so.0.0.0.p -I . -I .. -I /opt/dev/GNOME/include/glib-2.0 -I /opt/dev/GNOME/lib/glib-2.0/include -I /opt/dev/GNOME/include/gobject-introspection-1.0 -I /opt/dev/GNOME/include/pixman-1 -I /usr/include/cairo -I /usr/include/uuid -I /usr/include/freetype2 -I /usr/include/libpng16 -imultiarch x86_64-linux-gnu -MD libgjs.so.0.0.0.p/gi_arg-cache.cpp.d -MF libgjs.so.0.0.0.p/gi_arg-cache.cpp.o.d -MQ libgjs.so.0.0.0.p/gi_arg-cache.cpp.o -D_GNU_SOURCE -D_REENTRANT -D _FILE_OFFSET_BITS=64 -D
[Bug c++/100462] New: g++ fails to find the a pre-compiled header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462 Bug ID: 100462 Summary: g++ fails to find the a pre-compiled header Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mail at 3v1n0 dot net Target Milestone: --- Unfortunately I've not a minimal test case for this, but in gjs we can't use pre-compiled headers with g++ (while they work fine with clang++). In particular, we get this error: cc1plus: fatal error: gjs_pch.hh: No such file or director When in the build directory (that is included) there's a pch file (_build/libgjs.so.0.0.0.p/gjs_pch.hh.pch). This happens no matter what's in the pch source (can be just an include). An example failure is visible at: - https://gitlab.gnome.org/3v1n0/gjs/-/jobs/1288211 (see job artifacts for more logs) While the file gets used by clang++ (https://gitlab.gnome.org/3v1n0/gjs/-/jobs/1288273) The best way to reproduce this is: git clone https://gitlab.gnome.org/3v1n0/gjs -b pch cd gjs meson _build -Db_pch=true ninja -C _build I tried to make a minimal reproducer, but can't define one.
[Bug target/100461] New: [11/12 Regression] mingw build broken due to change of rdtsc implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461
Bug ID: 100461
Summary: [11/12 Regression] mingw build broken due to change of
rdtsc implementation
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Target Milestone: ---
GCC 11.1.0 build for mingw-w64 is broken now. Up to 10.3.0 the following was
used in gcc/config/i386/ia32intrin.h:
extern __inline unsigned long long
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
__rdtsc (void)
{
return __builtin_ia32_rdtsc ();
}
extern __inline unsigned long long
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
__rdtscp (unsigned int *__A)
{
return __builtin_ia32_rdtscp (__A);
}
but now we have just
#define __rdtsc() __builtin_ia32_rdtsc ()
#define __rdtscp(a) __builtin_ia32_rdtscp (a)
Changing this back fixes the build.
See also mingw-w64 7.0.0 at mingw-w64-crt/intrincs/rdtsc.c.
[Bug target/100460] New: [11/12 Regression] mingw build broken due to use of unsupported open() flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100460 Bug ID: 100460 Summary: [11/12 Regression] mingw build broken due to use of unsupported open() flags Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: daniel.f.starke at freenet dot de Target Milestone: --- GCC 11.1.0 fails to build with C++ under MinGW due to unsupported open() flags S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH in function finish_module_processing() within gcc/cp/module.cc. I suggest to remove these flags. MinGW will not fix this due to unforseen side effects: https://sourceforge.net/p/mingw/mailman/mingw-users/thread/znzrt579@wanadoo.es/
[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #31 from Andrew Pinski ---
(In reply to Niall Douglas from comment #30)
> I got bit by this GCC regression today at work. Consider
> https://godbolt.org/z/M9fd7nhdh where std::atomic<__int128> is compare
> exchanged with -march=sandybridge:
>
> - On GCC 6.4 and earlier, this emits lock cmpxchg16b, as you would expect.
>
> - From GCC 7 up to trunk (12?), this emits __atomic_compare_exchange_16.
>
> - On clang, this emits lock cmpxchg16b, as you would expect.
>
> This is clearly a regression. GCCs before 7 did the right thing. GCCs from 7
> onwards do not. clangs with libstdc++ do do the right thing.
>
> This isn't just an x64 thing, either. Consider
> https://godbolt.org/z/x6d5GE4o6 where GCC on ARM64 emits
> __atomic_compare_exchange_16, whereas clang on ARM64 emits ldaxp/stlxp, as
> you would expect.
>
> Please mark this bug as a regression affecting all versions of GCC from 7 to
> trunk, and affecting all 128 bit atomic capable architectures not just x64.
Again the problem is stuff like:
static const _Atomic __int128_t t = 2000;
__int128_t g(void)
{
return t;
}
DOES NOT WORK if you use CAS (or ldaxp/stlxp).
So clang is broken really
Also GCC for ARM64 emits calls for all compare and exchange because using the
LSE (from ARMv8.1-a) is useful.
[Bug c++/51577] dependent name lookup finds operator in global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c/100450] Missing ' ' space for '-E' preprocessing output, works with direct compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450 --- Comment #4 from Jakub Jelinek --- Created attachment 50769 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50769=edit gcc12-pr100450.patch Untested fix.
[Bug c/100450] Missing ' ' space for '-E' preprocessing output, works with direct compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2021-05-06 Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek --- I guess would should in libcpp/lex.c (cpp_avoid_paste) handle case CPP_PRAGMA: like case CPP_NAME: cpp_avoid_paste is called only from token_streamer::stream and from Fortran scan_translation_unit, so I think we should be ok. What we print for CPP_PRAGMA is always #pragma name or #pragma space name where name is some identifier.
[Bug c++/51577] dependent name lookup finds operator in global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 --- Comment #19 from Jason Merrill --- (In reply to Patrick Palka from comment #18) > ever since Nathan's r11-2876. As this commit mentions, should we enable the > maybe_save_operator_binding / push_operator_binding mechanism for all > templates? Let's.
[Bug c/100450] Missing ' ' space for '-E' preprocessing output, works with direct compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I think it started with my https://gcc.gnu.org/legacy-ml/gcc-patches/2008-02/msg01329.html Before that we weren't expanding those CLAUSES at all during preprocessing, neither for _Pragma nor for #pragma. But #pragma omp for CLAUSES works fine.
[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 Niall Douglas changed: What|Removed |Added CC||s_gccbugzilla at nedprod dot com --- Comment #30 from Niall Douglas --- I got bit by this GCC regression today at work. Consider https://godbolt.org/z/M9fd7nhdh where std::atomic<__int128> is compare exchanged with -march=sandybridge: - On GCC 6.4 and earlier, this emits lock cmpxchg16b, as you would expect. - From GCC 7 up to trunk (12?), this emits __atomic_compare_exchange_16. - On clang, this emits lock cmpxchg16b, as you would expect. This is clearly a regression. GCCs before 7 did the right thing. GCCs from 7 onwards do not. clangs with libstdc++ do do the right thing. This isn't just an x64 thing, either. Consider https://godbolt.org/z/x6d5GE4o6 where GCC on ARM64 emits __atomic_compare_exchange_16, whereas clang on ARM64 emits ldaxp/stlxp, as you would expect. Please mark this bug as a regression affecting all versions of GCC from 7 to trunk, and affecting all 128 bit atomic capable architectures not just x64.
[Bug c++/100459] [10/11 regression] constexpr decltype(auto) variable declaration bogus cv qual error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100459 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I think that's a desirable change, implemented in r11-2202: commit e7f0873a9c4ebccd078fc5330866efe0cd4c1309 Author: Marek Polacek Date: Wed Jul 8 19:45:34 2020 -0400 c++: Diagnose cv-qualified decltype(auto) [PR79815] "If the placeholder is the decltype(auto) type-specifier, T shall be the placeholder alone." but we weren't detecting "const decltype(auto)". I've just expanded the existing diagnostic detecting "decltype(auto) &" and similar. gcc/cp/ChangeLog: PR c++/79815 * decl.c (grokdeclarator): Detect cv-qual decltype(auto). * pt.c (do_auto_deduction): Likewise. gcc/testsuite/ChangeLog: PR c++/79815 * g++.dg/cpp1y/auto-fn59.C: New test.
[Bug tree-optimization/100453] [12 Regression] wrong code at -O1 and above since r12-434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453 Jakub Jelinek changed: What|Removed |Added Version|unknown |12.0 Last reconfirmed||2021-05-06 Target Milestone|--- |12.0 Ever confirmed|0 |1 Summary|wrong code at -O1 and above |[12 Regression] wrong code ||at -O1 and above since ||r12-434 Status|UNCONFIRMED |NEW CC||ebotcazou at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with r12-434-g93f8cb4965cebee125f96376367f05e18ee5749b
[Bug c++/100459] New: [10/11 regression] constexpr decltype(auto) variable declaration bogus cv qual error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100459 Bug ID: 100459 Summary: [10/11 regression] constexpr decltype(auto) variable declaration bogus cv qual error Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wjwray at gmail dot com Target Milestone: --- GCC11 rejects: constexpr decltype(auto) i = 0; GCC>10 error: decltype(auto) cannot be cv-qualified GCC<=10 accepts (Clang & MSVC too) https://godbolt.org/z/q75nMKvs8
[Bug target/100441] [8/9 Regression] ICE in output_constant_pool_2, at varasm.c:3955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100441 Jakub Jelinek changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Note, the 8 branch will be frozen tomorrow and closed in a week after that, so if you have anything to backport there, please do that before noon CET May 7th.
[Bug c++/100443] member using declaration of function templates with different return types does not bring base class overload into derived class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100443 --- Comment #6 from gnzlbg --- >From [basic.scope.scope]/p3.3.2 http://eel.is/c++draft/basic.scope.scope#3.3.2 I think that A::f and B::f don't correspond because they are function templates but their return types differ. Since they don't correspond, I interpret from [namespace.udecl]/p11 http://eel.is/c++draft/namespace.udecl#11 that the using-declaration must bring A::f into scope, and then the function call is ambiguous in C++ > 20. In C++20 and earlier this example seems legal.
[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 --- Comment #5 from Jakub Jelinek --- Yeah, I've noticed that when looking at combined constructs because otherwise the 2.14 rule that in_reduction when on target shall be also map(always,tofrom:) doesn't make any sense. Anyway, we have some known differences in the handling of the oldest cases (parallel for, parallel sections). And we have the stuff I've put into the tarball already compile time covered in c-c++-common/gomp/clauses-1.c hopefully, but I think it would be finally worth it to add scan-tree-dump gimple checks on these simplified testcases (with 1 or 2 clauses instead of all possible ones), with xfails for the cases we don't handle correctly and comments for those xfailed cases. I'll work on that now. And your patch is in the review queue, but I think it is better to figure out what we do wrong and how much first.
[Bug target/100441] [8/9 Regression] ICE in output_constant_pool_2, at varasm.c:3955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100441 Alex Coplan changed: What|Removed |Added Summary|[ICE] |[8/9 Regression] ICE in |output_constant_pool_2, at |output_constant_pool_2, at |varasm.c:3955 |varasm.c:3955 --- Comment #8 from Alex Coplan --- GCC 8 also seems to be affected.
[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 --- Comment #4 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #3) > I think we should start by checking what we are missing from the handling of > the harder clauses on combined/composite constructs against the 5.0 2.14 > section. [...] in_reduction. BTW: we already miss parser support for 'omp target in_reduction' - even without combined constructs ...
[Bug target/100458] [10 Regression] arm: ICE in change_address_1 with -march=armv7-m -fstack-protector-all -mpure-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100458 Alex Coplan changed: What|Removed |Added Target||arm Keywords||ice-on-valid-code Known to fail||10.3.1 Target Milestone|--- |10.4
[Bug target/100458] New: [10 Regression] arm: ICE in change_address_1 with -march=armv7-m -fstack-protector-all -mpure-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100458
Bug ID: 100458
Summary: [10 Regression] arm: ICE in change_address_1 with
-march=armv7-m -fstack-protector-all -mpure-code
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
On the head of the GCC 10 branch, the following fails:
$ cat test.c
void a() {}
$ gcc/xgcc -B gcc test.c -c -march=armv7-m -fstack-protector-all -mpure-code
during RTL pass: mach
test.c: In function ‘a’:
test.c:1:11: internal compiler error: in change_address_1, at emit-rtl.c:2273
1 | void a() {}
| ^
0x7c1890 change_address_1
/home/alecop01/toolchain/src/gcc/gcc/emit-rtl.c:2273
0x7f069d emit_move_insn(rtx_def*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:3851
0x10a5779 gen_split_74(rtx_insn*, rtx_def**)
/home/alecop01/toolchain/src/gcc/gcc/config/arm/arm.md:9218
0x7c6873 try_split(rtx_def*, rtx_insn*, int)
/home/alecop01/toolchain/src/gcc/gcc/emit-rtl.c:3836
0xa76801 split_insn
/home/alecop01/toolchain/src/gcc/gcc/recog.c:2884
0xa7acc7 split_all_insns_noflow()
/home/alecop01/toolchain/src/gcc/gcc/recog.c:3046
0xe05ea7 arm_reorg
/home/alecop01/toolchain/src/gcc/gcc/config/arm/arm.c:19154
0xaa5389 execute
/home/alecop01/toolchain/src/gcc/gcc/reorg.c:4010
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 --- Comment #3 from Jakub Jelinek --- Created attachment 50768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50768=edit pr99928.tar.xz I think we should start by checking what we are missing from the handling of the harder clauses on combined/composite constructs against the 5.0 2.14 section. By the harder clauses I mean firstprivate, lastprivate, firstprivate+lastprivate, linear (explicit non-IV, explicit IV, implicit IV), reduction and in_reduction. I've tried to construct testcases attached here that hopefully handle all possible cases and now the gimple dump should be checked against the rules. The rules are known to be buggy in 5.0, but let's assume that reduction even without inscan is tofrom on target combined with it as it was meant (and then mistakenly broken, fixed in 5.1). I've noticed we don't handle in_reduction clause on target construct.
[Bug tree-optimization/100442] Spurious -Wstringop-overread error with odd boundaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100442
Martin Sebor changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING |RESOLVED
--- Comment #3 from Martin Sebor ---
The warning is working correctly: it sees (and prints) the range below.
;; basic block 7, loop depth 1, count 2036975 (estimated locally), maybe hot
;; Invalid sum of incoming counts 4073950 (estimated locally), should be
2036975 (estimated locally)
;;prev block 6, next block 8, flags: (NEW, REACHABLE, VISITED)
;;pred: 5 [50.0% (guessed)] count:4073950 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
# RANGE [18446744073709551612, 18446744073709551615] <<< excessive range
_78 = (long unsigned intD.10) lexeme_len_24(D);
# RANGE [0, 1048575] NONZERO 1048575
_79 = (sizetype) _75;
# PT = nonlocal
_80 = _7 + _79;
# VUSE <.MEM_20(D)>
# USE = nonlocal escaped
cmp_81 = memcmpD.890 (lexeme_23(D), _80, _78); <<< -Wstringop-overead
if (cmp_81 == 0)
goto ; [50.00%]
else
goto ; [50.00%]
Ending up with an excessive range isn't uncommon in code that freely converts
between signed and unsigned integers (e.g., by passing an int to a size_t
argument) and involves conditionals like those in tsCompareString(). GCC must
assume the signed integers may be negative and convert to very large positive
values. Changing tsCompareString() to take size_t arguments instead of int
avoids the warning:
int32 tsCompareString(char *a, size_t lena, char *b, size_t lenb, _Bool
prefix);
Alternatively, asserting that the signed arguments aren't negative also
prevents the warning and in addition appears to result in better code
(tsvector_bsearch is inlined as well):
...
else
{
if (lena < 0 || lenb < 0)
__builtin_unreachable ();
cmp = memcmp(a, b, ((lena) < (lenb) ? (lena) : (lenb)));
I don't think there is anything for GCC to do here.
[Bug c++/100138] ICE with constructor constrained (C++20 Concepts) by parameter pack length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100138 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/100456] [11 regression] Obsolete Template parameter Causes Compile Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100456 --- Comment #5 from Jonathan Wakely --- The CWG issue is http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2237 and the C++20 standard even calls it out as an incompatibility with C++17.
[Bug c++/100456] [11 regression] Obsolete Template parameter Causes Compile Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100456 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jonathan Wakely --- That is an intentional change, not a bug: c++: C++20 DR 2237, disallow simple-template-id in cdtor. This patch implements DR 2237 which says that a simple-template-id is no longer valid as the declarator-id of a constructor or destructor; see [diff.cpp17.class]#2. It is not explicitly stated but out-of-line destructors with a simple-template-id are also meant to be ill-formed now. (Out-of-line constructors like that are invalid since DR1435 I think.) This change only applies to C++20; it is not a DR against C++17. I'm not crazy about the diagnostic in constructors but ISTM that cp_parser_constructor_declarator_p shouldn't print errors. See g:4b38d56dbac6742b038551a36ec80200313123a1 GCC is correct to reject the code.
[Bug c++/100455] [11 regression9 Obsoltee Template paraeter Cann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100455 H.J. Lu changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 100456 ***
[Bug c++/100456] [11 regression] Obsolete Template parameter Causes Compile Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100456 --- Comment #3 from H.J. Lu --- *** Bug 100455 has been marked as a duplicate of this bug. ***
[Bug c/100450] Missing ' ' space for '-E' preprocessing output, works with direct compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450 --- Comment #1 from Tobias Burnus --- Likewise with g++ - nonsurprising as it is common code in c-ppoutput.c's token_streamer::stream. First called with token->type == CPP_PRAGMA fprintf (print.outf, "%s %s", space, name); is the proper '#pragma omp for'. Then comes a CPP_PADDING followed by CPP_NAME. There is some 'Subtle logic to output a space if and only if necessary.' at the top of that file - and that seems to break here.
[Bug c++/100456] [11 regression] Obsolete Template parameter Causes Compile Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100456 --- Comment #2 from dominik.stras...@onespin-solutions.com --- Created attachment 50767 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50767=edit Test source
[Bug target/100445] [12 Regression] ice during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
--- Comment #10 from Uroš Bizjak ---
Following patch fixes the failures:
--cut here--
diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
index 4dfe7d6c282..61b2f921f41 100644
--- a/gcc/config/i386/i386-expand.c
+++ b/gcc/config/i386/i386-expand.c
@@ -3490,7 +3490,11 @@ static bool
ix86_use_mask_cmp_p (machine_mode mode, machine_mode cmp_mode,
rtx op_true, rtx op_false)
{
- if (GET_MODE_SIZE (mode) == 64)
+ int vector_size = GET_MODE_SIZE (mode);
+
+ if (vector_size < 16)
+return false;
+ else if (vector_size == 64)
return true;
/* When op_true is NULL, op_false must be NULL, or vice versa. */
--cut here--
But perhaps 64bit V2SI, V4HI and V8QI vpcmp insns can be emulated via their
128bit versions?
[Bug tree-optimization/100457] New: [meta bug] Enabling O2 vectorization in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100457 Bug ID: 100457 Summary: [meta bug] Enabling O2 vectorization in GCC 12 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: crazylht at gmail dot com CC: hjl.tools at gmail dot com Target Milestone: --- This metabug is used to track all the O2 vectorization issues. We're trying to enable vectorization in O2 for GCC12. To do that, we need to make there's no regression comparing -O2 -ftree-vectorize -fvect-cost-model=very-cheap to plain -O2, or those regressions are acceptable.
[Bug ipa/97937] [11 Regression] Line numbers are missing from duplicated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97937 --- Comment #3 from CVS Commits --- The master branch has been updated by Bernd Edlinger : https://gcc.gnu.org/g:e69ac0203725fb8da83a1cc88d32191b7a0b2c0c commit r12-574-ge69ac0203725fb8da83a1cc88d32191b7a0b2c0c Author: Bernd Edlinger Date: Tue Jan 12 16:27:53 2021 +0100 Add line debug info for virtual thunks There is no debug info when the DECL_IGNORED_P flag is set. But sometimes we have the line info of the function decl, as in the case of on virtual thunks. So instead of no line info at all, we emit at least the location of the function decl. On the other side, there are DECL_IGNORED_P functions which do not have any source line info at all. Remove those from the debug_range info, to make it clear for the debugger that the line info for these functions is invalid. This has the effect that the debugger will not step into the function without debug info. 2021-05-06 Bernd Edlinger PR ipa/97937 * debug.h (gcc_debug_hooks): Add set_ignored_loc function pointer. * dwarf2out.h (dw_fde_node::ignored_debug): New data item. * dbxout.c (dbx_debug_hooks, xcoff_debug_hooks): Add dummy set_ignored_loc callbacks. * debug.c (do_nothing_debug_hooks): Likewise. * vmsdbgout.c (vmsdbg_debug_hooks): Likewise. * dwarf2out.c (text_section_used, cold_text_section_used): Remove. (in_text_section_p, last_text_label, last_cold_label, switch_text_ranges, switch_cold_ranges): New data items. (dwarf2out_note_section_used): Remove. (dwarf2out_begin_prologue): Set fde->ignored_debug and in_text_section_p. (mark_ignored_debug_section): New helper function. (dwarf2out_end_epilogue, dwarf2out_switch_text_section): Call mark_ignored_debug_section. (dwarf2_debug_hooks): Use dwarf2out_set_ignored_loc. (dwarf2_lineno_debug_hooks): Use dummy for set_ignored_loc. (size_of_aranges): Adjust formula for multi-part text ranges size. (output_aranges): Output multi-part text ranges. (dwarf2out_set_ignored_loc): New callback function. (dwarf2out_finish): Output multi-part text ranges. (dwarf2out_c_finalize): Clear new data items. * final.c (final_start_function_1): Call set_ignored_loc callback. (final_scan_insn_1): Likewise. * ggc-page.c (gt_ggc_mx): New helper function. * stringpool.c (gt_pch_nx): Likewise.
[Bug c++/100456] [11 regression] Obsolete Template parameter Causes Compile Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100456 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2021-05-06 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to dominik.strasser from comment #0) > For the attached Source Code, I get The attachment is missing.
[Bug target/100441] [ICE] output_constant_pool_2, at varasm.c:3955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100441 --- Comment #7 from Alex Coplan --- So I'd guess the PR99037 fix just needs backporting to GCC 9, but we'll need to confirm that it's the same issue.
[Bug testsuite/100454] gnat.dg/opt93.adb FAILs on 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100454 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Eric Botcazou --- Thanks for reporting the problem.
[Bug testsuite/100454] gnat.dg/opt93.adb FAILs on 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100454 --- Comment #2 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:0f442f1378f4e9866793309504e38467f34c5d61 commit r12-573-g0f442f1378f4e9866793309504e38467f34c5d61 Author: Eric Botcazou Date: Thu May 6 16:26:55 2021 +0200 Fix PR testsuite/100454 gcc/testsuite/ * gnat.dg/opt93.adb: Compile only for LP64 targets.
[Bug sanitizer/100439] stack overflow running ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439 --- Comment #3 from Florin Iucha --- Tried it with current HEAD of https://github.com/google/googletest (f5e592d8ee5ffb1d9af5be7f715ce3576b8bf9c4), with the cmake patched to add "-fsanitize=undefined -fno-omit-frame-pointer -std=c++2a" and the behavior is reproducible there.
[Bug testsuite/100454] gnat.dg/opt93.adb FAILs on 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100454 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Target|sparc-sun-solaris2.11, | |i386-pc-solaris2.11,| |x86_64-pc-linux-gnu,| |hppa-unknown-linux-gnu, | |x86_64-apple-darwin*| Last reconfirmed||2021-05-06 Summary|gnat.dg/opt93.adb FAILs |gnat.dg/opt93.adb FAILs on ||32-bit targets Ever confirmed|0 |1 Component|ada |testsuite --- Comment #1 from Eric Botcazou --- I indeed missed it on SPARC/Solaris...
[Bug c++/100456] New: [11 regression] Obsolete Template parameter Causes Compile Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100456
Bug ID: 100456
Summary: [11 regression] Obsolete Template parameter Causes
Compile Error
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dominik.stras...@onespin-solutions.com
Target Milestone: ---
For the attached Source Code, I get
t.cpp:4:21: error: expected unqualified-id before ')' token
4 | Template() {}
| ^
in C++-20 Mode.
The error location seems to be off, too.
G++ 10.x, and clang 11/12 compile this fine.
g++ -std=c++20 t.cpp
[Bug ada/100454] gnat.dg/opt93.adb FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100454 Rainer Orth changed: What|Removed |Added Target Milestone|--- |12.0
[Bug ada/100454] New: gnat.dg/opt93.adb FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100454 Bug ID: 100454 Summary: gnat.dg/opt93.adb FAILs Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: ebotcazou at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11, i386-pc-solaris2.11, x86_64-pc-linux-gnu, hppa-unknown-linux-gnu, x86_64-apple-darwin* The new gnat.dg/opt93.adb test FAILs for 32-bit compilation on many targets: FAIL: gnat.dg/opt93.adb scan-tree-dump optimized "ivtmp.[0-9_]+ = ivtmp.[0-9_]+ + 2" probably everywhere.
[Bug c++/100455] New: [11 regression9 Obsoltee Template paraeter Cann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100455 Bug ID: 100455 Summary: [11 regression9 Obsoltee Template paraeter Cann Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dominik.stras...@onespin-solutions.com Target Milestone: ---
[Bug c++/51577] dependent name lookup finds operator in global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #18 from Patrick Palka ---
If the dependent operator call is inside a lambda, e.g. when adjusting the
testcase in comment #1 to:
template
void test( T v )
{
[&] { +v; }
}
namespace A
{
struct X { };
}
void operator+(A::X) { }
int main()
{
test( A::X() );
}
then GCC 11 correctly rejects the testcase:
51577.C: In instantiation of ‘bool test(T, U) [with T = A::X; U = B::Y]’:
51577.C:23:7: required from here
51577.C:5:14: error: no match for ‘operator==’ (operand types are ‘A::X’ and
‘B::Y’)
5 | [&] { v1 == v2; };
| ~~~^
ever since Nathan's r11-2876. As this commit mentions, should we enable the
maybe_save_operator_binding / push_operator_binding mechanism for all
templates? Something like
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -9116,7 +9116,7 @@ static const char *const op_bind_attrname = "operator
bindings";
void
maybe_save_operator_binding (tree e)
{
- /* This is only useful in a generic lambda. */
+ /* This is only useful in a template. */
if (!processing_template_decl)
return;
@@ -9124,11 +9124,6 @@ maybe_save_operator_binding (tree e)
if (!cfn)
return;
- /* Do this for lambdas and code that will emit a CMI. In a module's
- GMF we don't yet know whether there will be a CMI. */
- if (!module_has_cmi_p () && !global_purview_p () && !current_lambda_expr())
- return;
-
tree fnname = ovl_op_identifier (false, TREE_CODE (e));
if (!fnname)
return;
seems to fix all the related testcases I tried.
[Bug tree-optimization/100453] New: wrong code at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453
Bug ID: 100453
Summary: wrong code at -O1 and above
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It seems to be a recent regression.
[513] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210506 (experimental) [master revision
1698f496c5e:27b373b33d4:a1ac9ffb5a7f44b2e2633b7265c21ce803c8e854] (GCC)
[514] %
[514] % gcctk -O0 small.c; ./a.out
[515] % gcc110 -O1 small.c; ./a.out
[516] %
[516] % gcctk -O1 small.c
[517] % ./a.out
Segmentation fault
[518] %
[518] % cat small.c
struct a {
int b : 4;
} d;
static int c, e;
static const struct a f;
static void g(const struct a h) {
for (; c < 1; c++)
d = h;
e = h.b;
c = h.b;
}
int main() {
g(f);
return 0;
}
[Bug target/100441] [ICE] output_constant_pool_2, at varasm.c:3955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100441 --- Comment #6 from Alex Coplan --- On the GCC 10 branch it was the backport of the PR99037 fix which stopped the ICE (r11-7888-g37d9074e12082132ae62c12fbe958c697f638c0a on trunk, r10-9628-g1a92899b08e61d503a2897f2f66b064eb84706bc on the branch).
[Bug target/100445] [12 Regression] ice during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445 --- Comment #9 from Uroš Bizjak --- ix86_use_mask_cmp_p should be refined, it has an early return for 64bit modes: if (GET_MODE_SIZE (mode) == 64) return true;
[Bug tree-optimization/100452] g++.dg/vect/slp-pr99971.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100452 Rainer Orth changed: What|Removed |Added Target Milestone|--- |12.0
[Bug tree-optimization/100452] g++.dg/vect/slp-pr99971.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100452 --- Comment #1 from Rainer Orth --- Created attachment 50766 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50766=edit 32-bit sparc-sun-solaris2.11 slp-pr99971.cc.179t.slp2
[Bug tree-optimization/100452] New: g++.dg/vect/slp-pr99971.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100452 Bug ID: 100452 Summary: g++.dg/vect/slp-pr99971.cc FAILs Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11, armeb-none-linux-gnueabihf, powerpc64-unknown-linux-gnu, ia64-suse-linux-gnu The new g++.dg/vect/slp-pr99971.cc FAILs on a number of targets: FAIL: g++.dg/vect/slp-pr99971.cc -std=c++14 scan-tree-dump-not slp2 "removing SLP instance" FAIL: g++.dg/vect/slp-pr99971.cc -std=c++14 scan-tree-dump-times slp2 "SLPing BB part" 1 FAIL: g++.dg/vect/slp-pr99971.cc -std=c++14 scan-tree-dump-times slp2 "Vectorizing SLP" 2 FAIL: g++.dg/vect/slp-pr99971.cc -std=c++17 scan-tree-dump-not slp2 "removing SLP instance" FAIL: g++.dg/vect/slp-pr99971.cc -std=c++17 scan-tree-dump-times slp2 "SLPing BB part" 1 FAIL: g++.dg/vect/slp-pr99971.cc -std=c++17 scan-tree-dump-times slp2 "Vectorizing SLP" 2 FAIL: g++.dg/vect/slp-pr99971.cc -std=c++2a scan-tree-dump-not slp2 "removing SLP instance" FAIL: g++.dg/vect/slp-pr99971.cc -std=c++2a scan-tree-dump-times slp2 "SLPing BB part" 1 FAIL: g++.dg/vect/slp-pr99971.cc -std=c++2a scan-tree-dump-times slp2 "Vectorizing SLP" 2 FAIL: g++.dg/vect/slp-pr99971.cc -std=c++98 scan-tree-dump-not slp2 "removing SLP instance" FAIL: g++.dg/vect/slp-pr99971.cc -std=c++98 scan-tree-dump-times slp2 "SLPing BB part" 1 FAIL: g++.dg/vect/slp-pr99971.cc -std=c++98 scan-tree-dump-times slp2 "Vectorizing SLP" 2 I'm seeing it on 32 and 64-bit SPARC myself, and there are reports on ARM, PowerPC, and IA-64 as well.
[Bug target/100445] [12 Regression] ice during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #8 from H.J. Lu ---
r514 also caused
FAIL: gcc.dg/pr97238.c (internal compiler error)
FAIL: gcc.dg/pr97238.c (test for excess errors)
FAIL: gcc.dg/vect/bb-slp-49.c -flto -ffat-lto-objects (internal compiler error)
FAIL: gcc.dg/vect/bb-slp-49.c -flto -ffat-lto-objects (test for excess errors)
FAIL: gcc.dg/vect/bb-slp-49.c (internal compiler error)
FAIL: gcc.dg/vect/bb-slp-49.c (test for excess errors)
FAIL: gcc.target/i386/pr96827.c (internal compiler error)
FAIL: gcc.target/i386/pr96827.c (test for excess errors)
with
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr97238.c
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="vect.exp=gcc.dg/vect/bb-slp-49.c --target_board='unix{-m64\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr96827.c --target_board='unix{-m64\
-march=cascadelake}'"
[Bug testsuite/100451] g++.dg/warn/Warray-bounds-20.C XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100451 Rainer Orth changed: What|Removed |Added Target Milestone|--- |12.0 --- Comment #1 from Rainer Orth --- It seems likely that this is due to commit 30b10dacd0a8c926c22eab7d4aeb52ff86534acf Author: Martin Sebor Date: Thu Mar 18 13:36:09 2021 -0600 PR middle-end/99502 - missing -Warray-bounds on partial out of bounds
[Bug testsuite/100451] New: g++.dg/warn/Warray-bounds-20.C XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100451 Bug ID: 100451 Summary: g++.dg/warn/Warray-bounds-20.C XPASSes Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- Between 20210318 (ab03c0d5753549f1a78eeb706510b55fb97c8651) and 20210319 (287e3e8466f44f9d395a2e4dcfcda56cc34ceb1c), g++.dg/warn/Warray-bounds-20.C began to XPASS for 32-bit compilations: XPASS: g++.dg/warn/Warray-bounds-20.C -std=gnu++14 assign (test for warnings, line 30) XPASS: g++.dg/warn/Warray-bounds-20.C -std=gnu++17 assign (test for warnings, line 30) XPASS: g++.dg/warn/Warray-bounds-20.C -std=gnu++2a assign (test for warnings, line 30) XPASS: g++.dg/warn/Warray-bounds-20.C -std=gnu++98 assign (test for warnings, line 30) I'm seeing it on all of i386-pc-solaris2.11, sparc-sun-solaris2.11, and x86_64-pc-linux-gnu with -m32. According to gcc-testresults, the same issue exists on a wide range of other targets, probably everywhere. The gcc-11 branch is affected as well.
[Bug fortran/99819] [9/10/11/12 Regression] ICE in gfc_defer_symbol_init, at fortran/trans-decl.c:841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99819 --- Comment #3 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:a2c593009fef1564dbef2237ee71e9fd08f5361e commit r12-570-ga2c593009fef1564dbef2237ee71e9fd08f5361e Author: Paul Thomas Date: Thu May 6 14:41:33 2021 +0100 Fortran: Assumed and explicit size class arrays [PR46691/99819]. 2021-05-06 Paul Thomas gcc/fortran/ChangeLog PR fortran/46691 PR fortran/99819 * class.c (gfc_build_class_symbol): Remove the error that disables assumed size class arrays. Class array types that are not deferred shape or assumed rank are given a unique name and placed in the procedure namespace. * trans-array.c (gfc_trans_g77_array): Obtain the data pointer for class arrays. (gfc_trans_dummy_array_bias): Suppress the runtime error for extent violations in explicit shape class arrays because it always fails. * trans-expr.c (gfc_conv_procedure_call): Handle assumed size class actual arguments passed to non-descriptor formal args by using the data pointer, stored as the symbol's backend decl. gcc/testsuite/ChangeLog PR fortran/46691 PR fortran/99819 * gfortran.dg/class_dummy_6.f90: New test. * gfortran.dg/class_dummy_7.f90: New test.
[Bug c++/46691] Null pointer in template deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46691 --- Comment #2 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:a2c593009fef1564dbef2237ee71e9fd08f5361e commit r12-570-ga2c593009fef1564dbef2237ee71e9fd08f5361e Author: Paul Thomas Date: Thu May 6 14:41:33 2021 +0100 Fortran: Assumed and explicit size class arrays [PR46691/99819]. 2021-05-06 Paul Thomas gcc/fortran/ChangeLog PR fortran/46691 PR fortran/99819 * class.c (gfc_build_class_symbol): Remove the error that disables assumed size class arrays. Class array types that are not deferred shape or assumed rank are given a unique name and placed in the procedure namespace. * trans-array.c (gfc_trans_g77_array): Obtain the data pointer for class arrays. (gfc_trans_dummy_array_bias): Suppress the runtime error for extent violations in explicit shape class arrays because it always fails. * trans-expr.c (gfc_conv_procedure_call): Handle assumed size class actual arguments passed to non-descriptor formal args by using the data pointer, stored as the symbol's backend decl. gcc/testsuite/ChangeLog PR fortran/46691 PR fortran/99819 * gfortran.dg/class_dummy_6.f90: New test. * gfortran.dg/class_dummy_7.f90: New test.
[Bug target/91400] __builtin_cpu_supports conjunction is optimized poorly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91400 H.J. Lu changed: What|Removed |Added Version|unknown |12.0 Resolution|--- |FIXED Target Milestone|--- |12.0 Status|NEW |RESOLVED --- Comment #4 from H.J. Lu --- Fixed for GCC 12.
[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347 --- Comment #14 from Iain Sandoe --- (In reply to Erik Schnetter from comment #13) > The failing GCC 11.1.0 is built by Apple Clang 12.0.5 via Spack. Looking at > debug output, I see that Spack inserts a "-march=skylake" command line > option. (I was not aware of this before.) It does so by creating a compiler > wrapper (called "clang++" as well), which calls the actual compiler and adds > this (and some other) flags. > > I seem to recall having read somewhere that GCC's CPU detection code must be > built without any "-march=..." flag. well, the GCC config makes sensible default choices for CPU (if there's no --with-cpu=) - which is core2 mostly (so that the code should run anywhere). As of this moment the only machines I've got builds with --with-cpu= specify the correct CPU for the machine, so -march= isn't going to tell anything - except I can say for sure that it doesn't report x86_64): /src-local/gcc-master/configure --prefix=/opt/iains/x86_64-apple-darwin16/gcc-12-0-0d --build=x86_64-apple-darwin16 --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk --enable-languages=all --with-cpu=corei7 --with-tune=skylake CC=x86_64-apple-darwin16-gcc CXX=x86_64-apple-darwin16-g++ $ ./gcc/xgcc -Bgcc -march=native -Q --help=target | grep march -march= skylake So that's reporting what was configures, but also what would be correct for the hardware - it hasn't overridden the configuration settings. can we get the output of "gcc -v" for the compiler that isn't working? If this is a compiler built without bootstrap, and the bootstrap compiler is clang, then that could be an unknown quantity. Production compilers should be bootstrapped.
[Bug c/100450] New: Missing ' ' space for '-E' preprocessing output, works with direct compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
Bug ID: 100450
Summary: Missing ' ' space for '-E' preprocessing output, works
with direct compilation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
The following code compiles with
-c -fopenmp -Wall test.c
But the output with -E + compilation shows:
warning: ignoring ‘#pragma omp forreduction’ [-Wunknown-pragmas]
as the -E preprocessor outputs:
#pragma omp forreduction(+:red)
instead of the expected
#pragma omp for reduction(+:red)
-^
Testcase:
---
#define TEST(T) { \
{T} \
}
#define CLAUSES reduction(+:red)
#define PARALLEL_FOR(X) TEST({ \
_Pragma("omp for CLAUSES") \
X \
})
void foo()
{
int red = 0;
int A[3] = {};
#pragma omp parallel shared(red)
PARALLEL_FOR( for(int i=0; i < 3; i++) red += A[i]; )
}
[Bug target/100445] [12 Regression] ice during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445 --- Comment #7 from Jakub Jelinek --- I have no XOP CPU either, normally I bootstrap on Intel i9-7960X and on my desktop I have AMD Ryzen 5 3600, but that doesn't have XOP either.
[Bug c++/99692] Lookup for operator<< skips global scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99692 --- Comment #12 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #9) > (In reply to Jonathan Wakely from comment #4) > > The __rvalue_ostream_type constraints are going away soon: > > https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566863.html > > N.B. that change is on gcc trunk now. And the gcc-11 branch, so the original testcases compile now because the problematic __is_insertable check isn't in the library now. The reduced cases above still fail on all branches.
[Bug libstdc++/80675] Incorrect implementation of LWG 2534
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80675 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ca7d2f2ec9142995179a5d832a946b50de05e659 commit r11-8369-gca7d2f2ec9142995179a5d832a946b50de05e659 Author: Jonathan Wakely Date: Fri Apr 30 14:07:28 2021 +0100 libstdc++: Implement LWG 1203 for rvalue iostreams This implements the resolution of LWG 1203 so that the constraints for rvalue stream insertion/extraction are simpler, and the return type is the original rvalue stream type not its base class. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: * include/std/istream (operator>>(Istream&&, x&)): Simplify, as per LWG 1203. * include/std/ostream (operator<<(Ostream&&, const x&)): Likewise. * testsuite/27_io/basic_istream/extractors_character/char/lwg2499_neg.cc: Adjust dg-error pattern. * testsuite/27_io/basic_istream/extractors_character/wchar_t/lwg2499_neg.cc: Likewise. * testsuite/27_io/basic_istream/extractors_other/char/4.cc: Define is_extractable trait to replace std::__is_extractable. Make it work with rvalue streams as well as lvalues, to replace f() and g() helper functions. * testsuite/27_io/basic_istream/extractors_other/wchar_t/4.cc: Likewise. * testsuite/27_io/basic_ostream/inserters_other/char/6.cc: Define is_insertable trait to replace std::__is_insertable. Make it work with rvalue streams as well as lvalues, to replace f() and g() helper functions. * testsuite/27_io/basic_ostream/inserters_other/wchar_t/6.cc: Likewise. * testsuite/27_io/filesystem/path/io/dr2989.cc: Prune additional errors from new constraints. * testsuite/27_io/rvalue_streams-2.cc: Remove PR 80675 checks, which are no longer expected to compile. * testsuite/27_io/rvalue_streams.cc: Adjust existing test. Verify LWG 1203 changes. (cherry picked from commit aa475c4ac80733f85ba47b109fc1900f05e810e2)
[Bug libstdc++/100384] Compiling in c++17 mode breaks compilation of functions named visit()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100384 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e99763ee6da8e378073b847243d9ac2538903534 commit r11-8363-ge99763ee6da8e378073b847243d9ac2538903534 Author: Jonathan Wakely Date: Tue May 4 12:16:46 2021 +0100 libstdc++: Do not use deduced return type for std::visit [PR 100384] This avoids errors outside the immediate context when std::visit is an overload candidate because of ADL, but not actually viable. The solution is to give std::visit a non-deduced return type. New helpers are introduced for that, and existing ones refactored slightly. libstdc++-v3/ChangeLog: PR libstdc++/100384 * include/std/variant (__get_t): New alias template yielding the return type of std::get on a variant. (__visit_result_t): New alias template yielding the result of std::visit. (__same_types): Move into namespace __detail::__variant. (__check_visitor_results): Likewise. Use __invoke_result_t and __get_t. (__check_visitor_result): Remove. (visit): Use __visit_result_t for return type. * testsuite/20_util/variant/100384.cc: New test. (cherry picked from commit af5b2b911dd80ae9cc87404b7e7ab807cf6655d4)
[Bug target/100445] [12 Regression] ice during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445 --- Comment #6 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #5) > ix86_expand_sse_movcc has special TARGET_XOP path, so the following patch is > needed: Ah, you beat me by the second ;) Anyway, I have no XOP target, so probably you can test the patch on a real XOP target.
[Bug target/100445] [12 Regression] ice during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
--- Comment #5 from Uroš Bizjak ---
ix86_expand_sse_movcc has special TARGET_XOP path, so the following patch is
needed:
diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index 347295afbb5..667dd057e0d 100644
--- a/gcc/config/i386/mmx.md
+++ b/gcc/config/i386/mmx.md
@@ -1687,6 +1687,17 @@ (define_expand "vcondu"
DONE;
})
+;; XOP parallel XMM conditional moves
+(define_insn "*mmx_pcmov"
+ [(set (match_operand:MMXMODEI 0 "register_operand" "=x")
+ (if_then_else:MMXMODEI
+ (match_operand:MMXMODEI 3 "register_operand" "x")
+ (match_operand:MMXMODEI 1 "register_operand" "x")
+ (match_operand:MMXMODEI 2 "register_operand" "x")))]
+ "TARGET_MMX_WITH_SSE && TARGET_XOP"
+ "vpcmov\t{%3, %2, %1, %0|%0, %1, %2, %3}"
+ [(set_attr "type" "sse4arg")])
+
(define_expand "vcond_mask_"
[(set (match_operand:MMXMODEI 0 "register_operand")
(vec_merge:MMXMODEI
[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347 --- Comment #13 from Erik Schnetter --- The failing GCC 11.1.0 is built by Apple Clang 12.0.5 via Spack. Looking at debug output, I see that Spack inserts a "-march=skylake" command line option. (I was not aware of this before.) It does so by creating a compiler wrapper (called "clang++" as well), which calls the actual compiler and adds this (and some other) flags. I seem to recall having read somewhere that GCC's CPU detection code must be built without any "-march=..." flag.
[Bug rtl-optimization/100263] [11/12 Regression] RTL optimizers miscompile loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100263
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #17 from Stefan Schulze Frielinghaus ---
Closing since fixed in releases/gcc-{8,9,10,11} and mainline.
[Bug target/100445] [12 Regression] ice during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 50765 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50765=edit gcc12-pr100445.patch Untested patch that implements the latter.
[Bug target/100445] [12 Regression] ice during RTL pass: vregs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
--- Comment #3 from Jakub Jelinek ---
Slightly more readable testcase without warnings, -O3 -mxop:
int a, b[3];
void bar (int *);
void
foo (void)
{
for (; a < 3; a++)
b[a] = (a - 1) / 2;
bar (b);
}
IMHO we can either avoid the TARGET_XOP stuff for 8-byte vector modes, like:
--- gcc/config/i386/i386-expand.c.jj2021-05-06 10:14:55.486063301 +0200
+++ gcc/config/i386/i386-expand.c 2021-05-06 14:37:58.104025120 +0200
@@ -3653,7 +3653,7 @@ ix86_expand_sse_movcc (rtx dest, rtx cmp
emit_insn (gen_rtx_SET (dest, x));
return;
}
- else if (TARGET_XOP)
+ else if (TARGET_XOP && (!VECTOR_MODE_P (mode) || GET_MODE_SIZE (mode) != 8))
{
op_true = force_reg (mode, op_true);
or add the MMXMODEI xop_pcmov_* patterns.
[Bug c/100449] New: Unrolled loop ignores __building_constant_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100449
Bug ID: 100449
Summary: Unrolled loop ignores __building_constant_p
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: christophe.leroy at csgroup dot eu
Target Milestone: ---
The following code built with -m32 -O2 -c :
static inline void mtsr(unsigned long val, unsigned long idx)
{
if (__builtin_constant_p(idx))
asm volatile("mtsr %1, %0" : : "r" (val), "i" (idx >> 28));
else
asm volatile("mtsrin %0, %1" : : "r" (val), "r" (idx));
}
void update_user_segments(unsigned long val)
{
int i;
for (i = 0; i < 4; i++)
mtsr(val + 0x111 * i, i << 28);
}
Results in:
:
0: 39 20 00 00 li r9,0
4: 7c 60 49 e4 mtsrin r3,r9
8: 3d 40 10 00 lis r10,4096
c: 39 23 01 11 addir9,r3,273
10: 7d 20 51 e4 mtsrin r9,r10
14: 3d 40 20 00 lis r10,8192
18: 39 23 02 22 addir9,r3,546
1c: 7d 20 51 e4 mtsrin r9,r10
20: 3d 20 30 00 lis r9,12288
24: 38 63 03 33 addir3,r3,819
28: 7c 60 49 e4 mtsrin r3,r9
2c: 4e 80 00 20 blr
I would expect GCC to realise that once unrolled, parameters to mtsr() are
constant, leading to something like the following:
mtsr 0, r3
addi r9,r3,273
mtsr 1, r9
addi r9,r3,546
mtsr 2, r9
addi r3,r3,819
mtsr 3, r3
blr
[Bug c++/100443] member using declaration of function templates with different return types does not bring base class overload into derived class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100443 --- Comment #5 from gnzlbg --- > There is still no mention of signatures, which is why I wondered why you're > talking about them. Re-reading that part, you are correct that it does not mention signatures. I misunderstood it. Reading [basic.scope.scope], i'm not sure if `A::f` "corresponds to" `B::f`. Does it?
[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347 --- Comment #12 from Erik Schnetter --- Yes, GCC 10.3 (built via MacPorts) still works. The sample program reports a Skylake CPU with both compilers.
