[Bug target/105613] [13 Regression] wrong code with unsigned V1TI comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105613 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-16 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/105613] [13 Regression] wrong code with unsigned V1TI comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105613 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug target/105613] New: [13 Regression] wrong code with unsigned V1TI comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105613
Bug ID: 105613
Summary: [13 Regression] wrong code with unsigned V1TI
comparison
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 52982
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52982=edit
reduced testcase
Output:
$ x86_64-pc-linux-gnu-gcc testcase.c
$ ./a.out
Aborted
(gdb) p r
$1 = {0}
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-468-20220516083034-g69c4b5c519f-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-468-20220516083034-g69c4b5c519f-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220516 (experimental) (GCC)
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #16 from harper at msor dot vuw.ac.nz ---
I have now used ifort on my latest test program, which you should
already have, in the hope that it helps you. It printed this:
john@johns-laptop:~/Jfh$ ifort testiostat4.f90
Compiling "ifort testiostat4.f90"
john@johns-laptop:~/Jfh$ ./a.out
i= 1 input(i) = "2,5,"
with decimal=point x(:) = 2.0 5.0 ios=0
with decimal=comma x(:) = 666.0 666.0 ios=59
i= 2 input(i) = "2;5,"
with decimal=point x(:) = 666.0 666.0 ios=59
with decimal=comma x(:) = 2.0 5.0 ios=0
i= 3 input(i) = "2 5,"
with decimal=point x(:) = 2.0 5.0 ios=0
with decimal=comma x(:) = 2.0 5.0 ios=0
i= 4 input(i) = "2.5,"
with decimal=point x(:) = 2.5 666.0 ios=-1
with decimal=comma x(:) = 666.0 666.0 ios=59
i= 5 input(i) = "2,5;"
with decimal=point x(:) = 2.0 666.0 ios=59
with decimal=comma x(:) = 2.5 666.0 ios=-1
i= 6 input(i) = "2;5;"
with decimal=point x(:) = 666.0 666.0 ios=59
with decimal=comma x(:) = 2.0 5.0 ios=0
i= 7 input(i) = "2 5;"
with decimal=point x(:) = 2.0 666.0 ios=59
with decimal=comma x(:) = 2.0 5.0 ios=0
i= 8 input(i) = "2.5;"
with decimal=point x(:) = 666.0 666.0 ios=59
with decimal=comma x(:) = 666.0 666.0 ios=59
i= 9 input(i) = "2,5 "
with decimal=point x(:) = 2.0 5.0 ios=0
with decimal=comma x(:) = 2.5 666.0 ios=-1
i= 10 input(i) = "2;5 "
with decimal=point x(:) = 666.0 666.0 ios=59
with decimal=comma x(:) = 2.0 5.0 ios=0
i= 11 input(i) = "2 5 "
with decimal=point x(:) = 2.0 5.0 ios=0
with decimal=comma x(:) = 2.0 5.0 ios=0
i= 12 input(i) = "2.5 "
with decimal=point x(:) = 2.5 666.0 ios=-1
with decimal=comma x(:) = 666.0 666.0 ios=59
i= 13 input(i) = "2,5."
with decimal=point x(:) = 2.0 5.0 ios=0
with decimal=comma x(:) = 666.0 666.0 ios=59
i= 14 input(i) = "2;5."
with decimal=point x(:) = 666.0 666.0 ios=59
with decimal=comma x(:) = 2.0 666.0 ios=59
i= 15 input(i) = "2 5."
with decimal=point x(:) = 2.0 5.0 ios=0
with decimal=comma x(:) = 2.0 666.0 ios=59
i= 16 input(i) = "2.5."
with decimal=point x(:) = 666.0 666.0 ios=59
with decimal=comma x(:) = 666.0 666.0 ios=59
john@johns-laptop:~/Jfh$
-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
-- Forwarded message --
Date: Mon, 16 May 2022 01:44:15 +
From: harper at msor dot vuw.ac.nz
To: John Harper
Subject: [Bug fortran/105473] semicolon allowed when list-directed read integer
with decimal='point'
Resent-Date: Mon, 16 May 2022 13:44:25 +1200 (NZST)
Resent-From:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #15 from harper at msor dot vuw.ac.nz ---
Thank you. My test program failed to distinguish some bad cases from good
cases; a revised version of the program is below. The important change
was making both elements of x be 666 just before both read statements, to
allow checking whether anything was read as well as what. A cosmetic
change was an explicit format called fmt instead of * when printing x etc.
! Does list-directed reading work properly with decimal='comma' ?
implicit none
real x(2)
character(*),parameter:: punc = ",; .", fmt = '(A,2(F0.1,1X),A,I0)'
integer,parameter:: lpunc =len(punc)
integer ios,i,j
character:: msg*80, input(lpunc**2)*4 = &
[(("2"//punc(i:i)//"5"//punc(j:j),i=1,lpunc),j=1,lpunc)]
do i = 1,size(input)
print *,'i=',i,'input(i) = "',input(i),'"'
x = 666
read(input(i),*,decimal='point',iostat=ios,iomsg=msg) x
print fmt,' with decimal=point x(:) =',x,' ios=',ios
! if(ios/=0) print *,trim(msg)
x = 666
read(input(i),*,decimal='comma',iostat=ios,iomsg=msg) x
print fmt,' with decimal=comma x(:) =',x,' ios=',ios
! if(ios/=0) print *,trim(msg)
end do
end program
On Mon, 16 May 2022, jvdelisle at gcc dot gnu.org wrote:
> Date: Mon, 16 May 2022 00:49:44 +
> From: jvdelisle at gcc dot gnu.org
> To: John Harper
> Subject: [Bug fortran/105473] semicolon allowed when list-directed read
> integer with decimal='point'
> Resent-Date: Mon, 16 May 2022 12:49:53 +1200 (NZST)
> Resent-From:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
>
> --- Comment #13 from Jerry DeLisle ---
> With John's multiple combinations test case I get the following results with
> the attached patch. All places where we gave an error before the patch, we
> give
> errors now plus new errors
>
> $ gfc multi.f90
> $ ./a.out
> i= 1 input(i) = "2,5,"
> with decimal=point x(:) = 2. 5. ios= 0
> with decimal=comma x(:) = 2. 666.00 ios=5010
> i= 2 input(i) = "2;5,"
[Bug target/105513] [9/10/11/12/13 Regression] Unnecessary SSE spill since r9-5748-g1d4b4f4979171ef0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105513 --- Comment #5 from Hongtao.liu --- And for constraint like 'vm', it's different from 'v,m' in calculating mem_cost which will impact RA when op is REG_P. For 'v,m' mem_cost is just 1 * frequency, but for 'vm' mem_cost is much bigger(memory_move_cost - 1) * frequency. It means the impact of writing 'v,m' instead of 'vm' makes RA more likely to choose mem instead of register. 928 if (op_class == NO_REGS) 929/* Although we don't need insn to reload from 930 memory, still accessing memory is usually more 931 expensive than a register. */ 932pp->mem_cost = frequency; 933 else 934/* If the alternative actually allows memory, make 935 things a bit cheaper since we won't need an 936 extra insn to load it. */ 937pp->mem_cost 938 = ((out_p ? ira_memory_move_cost[mode][op_class][0] : 0) 939 + (in_p ? ira_memory_move_cost[mode][op_class][1] : 0) 940=> - allows_mem[i]) * frequency;
[Bug debug/105586] [11/12/13 Regression] -fcompare-debug failure (length) with -O2 -fno-if-conversion -mtune=power4 -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105586 Kewen Lin changed: What|Removed |Added CC||jskumari at gcc dot gnu.org, ||pthaugen at linux dot ibm.com --- Comment #3 from Kewen Lin --- btw, it doesn't need the cross build for reproduction, but if the native cpu isn't power8, it needs the explicit option -mcpu=power8, otherwise cpu power9/10 makes this issue gone.
[Bug target/103743] PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103743 --- Comment #6 from Jiu Fu Guo --- Drafted a patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594702.html
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #15 from harper at msor dot vuw.ac.nz ---
Thank you. My test program failed to distinguish some bad cases from good
cases; a revised version of the program is below. The important change
was making both elements of x be 666 just before both read statements, to
allow checking whether anything was read as well as what. A cosmetic
change was an explicit format called fmt instead of * when printing x etc.
! Does list-directed reading work properly with decimal='comma' ?
implicit none
real x(2)
character(*),parameter:: punc = ",; .", fmt = '(A,2(F0.1,1X),A,I0)'
integer,parameter:: lpunc =len(punc)
integer ios,i,j
character:: msg*80, input(lpunc**2)*4 = &
[(("2"//punc(i:i)//"5"//punc(j:j),i=1,lpunc),j=1,lpunc)]
do i = 1,size(input)
print *,'i=',i,'input(i) = "',input(i),'"'
x = 666
read(input(i),*,decimal='point',iostat=ios,iomsg=msg) x
print fmt,' with decimal=point x(:) =',x,' ios=',ios
! if(ios/=0) print *,trim(msg)
x = 666
read(input(i),*,decimal='comma',iostat=ios,iomsg=msg) x
print fmt,' with decimal=comma x(:) =',x,' ios=',ios
! if(ios/=0) print *,trim(msg)
end do
end program
On Mon, 16 May 2022, jvdelisle at gcc dot gnu.org wrote:
> Date: Mon, 16 May 2022 00:49:44 +
> From: jvdelisle at gcc dot gnu.org
> To: John Harper
> Subject: [Bug fortran/105473] semicolon allowed when list-directed read
> integer with decimal='point'
> Resent-Date: Mon, 16 May 2022 12:49:53 +1200 (NZST)
> Resent-From:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
>
> --- Comment #13 from Jerry DeLisle ---
> With John's multiple combinations test case I get the following results with
> the attached patch. All places where we gave an error before the patch, we
> give
> errors now plus new errors
>
> $ gfc multi.f90
> $ ./a.out
> i= 1 input(i) = "2,5,"
> with decimal=point x(:) = 2. 5. ios= 0
> with decimal=comma x(:) = 2. 666.00 ios=5010
> i= 2 input(i) = "2;5,"
> with decimal=point x(:) = 2. 666.00 ios=5010
> with decimal=comma x(:) = 2. 5. ios= 0
> i= 3 input(i) = "2 5,"
> with decimal=point x(:) = 2. 5. ios= 0
> with decimal=comma x(:) = 2. 5. ios= 0
> i= 4 input(i) = "2.5,"
> with decimal=point x(:) = 2.5000 5. ios= -1
> with decimal=comma x(:) = 2.5000 666.00 ios=5010
> i= 5 input(i) = "2,5;"
> with decimal=point x(:) = 2. 5. ios=5010
> with decimal=comma x(:) = 2.5000 666.00 ios= -1
> i= 6 input(i) = "2;5;"
> with decimal=point x(:) = 2. 666.00 ios=5010
> with decimal=comma x(:) = 2. 5. ios= 0
> i= 7 input(i) = "2 5;"
> with decimal=point x(:) = 2. 5. ios=5010
> with decimal=comma x(:) = 2. 5. ios= 0
> i= 8 input(i) = "2.5;"
> with decimal=point x(:) = 2.5000 5. ios=5010
> with decimal=comma x(:) = 2.5000 666.00 ios= -1
> i= 9 input(i) = "2,5 "
> with decimal=point x(:) = 2. 5. ios= 0
> with decimal=comma x(:) = 2.5000 666.00 ios= -1
> i= 10 input(i) = "2;5 "
> with decimal=point x(:) = 2. 666.00 ios=5010
> with decimal=comma x(:) = 2. 5. ios= 0
> i= 11 input(i) = "2 5 "
> with decimal=point x(:) = 2. 5. ios= 0
> with decimal=comma x(:) = 2. 5. ios= 0
> i= 12 input(i) = "2.5 "
> with decimal=point x(:) = 2.5000 5. ios= -1
> with decimal=comma x(:) = 2.5000 666.00 ios= -1
> i= 13 input(i) = "2,5."
> with decimal=point x(:) = 2. 5. ios= 0
> with decimal=comma x(:) = 2. 666.00 ios=5010
> i= 14 input(i) = "2;5."
> with decimal=point x(:) = 2. 666.00 ios=5010
> with decimal=comma x(:) = 2. 5. ios= 0
> i= 15 input(i) = "2 5."
> with decimal=point x(:) = 2. 5. ios= 0
> with decimal=comma x(:) = 2. 5. ios= 0
> i= 16 input(i) = "2.5."
> with decimal=point x(:) = 2. 5. ios=5010
> with decimal=comma x(:) = 2.
[Bug c++/87504] inconsistent diagnostic style between C and C++ for binary operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87504 Eric Gallager changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #10 from Eric Gallager --- (In reply to Eric Gallager from comment #9) > (In reply to David Malcolm from comment #8) > > Author: dmalcolm > > Date: Thu Dec 20 14:18:48 2018 > > New Revision: 267299 > > > > URL: https://gcc.gnu.org/viewcvs?rev=267299=gcc=rev > > Log: > > -Wtautological-compare: fix comparison of macro expansions > > > > gcc/c-family/ChangeLog: > > PR c++/87504 > > * c-warn.c (get_outermost_macro_expansion): New function. > > (spelled_the_same_p): Use it to unwind the macro expansions, and > > compare the outermost macro in each nested expansion, rather than > > the innermost. > > > > gcc/testsuite/ChangeLog: > > PR c++/87504 > > * c-c++-common/Wtautological-compare-8.c: New test. > > > > > > Added: > > trunk/gcc/testsuite/c-c++-common/Wtautological-compare-8.c > > Modified: > > trunk/gcc/c-family/ChangeLog > > trunk/gcc/c-family/c-warn.c > > trunk/gcc/testsuite/ChangeLog > > so is this fixed now? WAITING on a reply
[Bug c/105612] New: [meta-bug] bogus/missing -Wtautological-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105612 Bug ID: 105612 Summary: [meta-bug] bogus/missing -Wtautological-compare Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic, meta-bug Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org Target Milestone: --- alias Wtautological-compate
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #14 from Jerry DeLisle --- The first set of results in in Comment #13 is with the line that prints msg commented out. The second set is with the msg prints.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #13 from Jerry DeLisle --- With John's multiple combinations test case I get the following results with the attached patch. All places where we gave an error before the patch, we give errors now plus new errors $ gfc multi.f90 $ ./a.out i= 1 input(i) = "2,5," with decimal=point x(:) = 2. 5. ios= 0 with decimal=comma x(:) = 2. 666.00 ios=5010 i= 2 input(i) = "2;5," with decimal=point x(:) = 2. 666.00 ios=5010 with decimal=comma x(:) = 2. 5. ios= 0 i= 3 input(i) = "2 5," with decimal=point x(:) = 2. 5. ios= 0 with decimal=comma x(:) = 2. 5. ios= 0 i= 4 input(i) = "2.5," with decimal=point x(:) = 2.5000 5. ios= -1 with decimal=comma x(:) = 2.5000 666.00 ios=5010 i= 5 input(i) = "2,5;" with decimal=point x(:) = 2. 5. ios=5010 with decimal=comma x(:) = 2.5000 666.00 ios= -1 i= 6 input(i) = "2;5;" with decimal=point x(:) = 2. 666.00 ios=5010 with decimal=comma x(:) = 2. 5. ios= 0 i= 7 input(i) = "2 5;" with decimal=point x(:) = 2. 5. ios=5010 with decimal=comma x(:) = 2. 5. ios= 0 i= 8 input(i) = "2.5;" with decimal=point x(:) = 2.5000 5. ios=5010 with decimal=comma x(:) = 2.5000 666.00 ios= -1 i= 9 input(i) = "2,5 " with decimal=point x(:) = 2. 5. ios= 0 with decimal=comma x(:) = 2.5000 666.00 ios= -1 i= 10 input(i) = "2;5 " with decimal=point x(:) = 2. 666.00 ios=5010 with decimal=comma x(:) = 2. 5. ios= 0 i= 11 input(i) = "2 5 " with decimal=point x(:) = 2. 5. ios= 0 with decimal=comma x(:) = 2. 5. ios= 0 i= 12 input(i) = "2.5 " with decimal=point x(:) = 2.5000 5. ios= -1 with decimal=comma x(:) = 2.5000 666.00 ios= -1 i= 13 input(i) = "2,5." with decimal=point x(:) = 2. 5. ios= 0 with decimal=comma x(:) = 2. 666.00 ios=5010 i= 14 input(i) = "2;5." with decimal=point x(:) = 2. 666.00 ios=5010 with decimal=comma x(:) = 2. 5. ios= 0 i= 15 input(i) = "2 5." with decimal=point x(:) = 2. 5. ios= 0 with decimal=comma x(:) = 2. 5. ios= 0 i= 16 input(i) = "2.5." with decimal=point x(:) = 2. 5. ios=5010 with decimal=comma x(:) = 2. 666.00 ios=5010 [jerry@amdr pr105473]$ gfc multi.f90 [jerry@amdr pr105473]$ ./a.out i= 1 input(i) = "2,5," with decimal=point x(:) = 2. 5. ios= 0 with decimal=comma x(:) = 2. 666.00 ios=5010 Bad real number in item 1 of list input i= 2 input(i) = "2;5," with decimal=point x(:) = 2. 666.00 ios=5010 Semicolon not allowed as separator with DECIMAL='point' with decimal=comma x(:) = 2. 5. ios= 0 i= 3 input(i) = "2 5," with decimal=point x(:) = 2. 5. ios= 0 with decimal=comma x(:) = 2. 5. ios= 0 i= 4 input(i) = "2.5," with decimal=point x(:) = 2.5000 5. ios= -1 End of file with decimal=comma x(:) = 2.5000 666.00 ios=5010 Bad real number in item 1 of list input i= 5 input(i) = "2,5;" with decimal=point x(:) = 2. 5. ios=5010 Semicolon not allowed as separator with DECIMAL='point' with decimal=comma x(:) = 2.5000 666.00 ios= -1 End of file i= 6 input(i) = "2;5;" with decimal=point x(:) = 2. 666.00 ios=5010 Semicolon not allowed as separator with DECIMAL='point' with decimal=comma x(:) = 2. 5. ios= 0 i= 7 input(i) = "2 5;" with decimal=point x(:) = 2. 5. ios=5010
[Bug target/105587] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-210-gfcda0efccad41eba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105587 --- Comment #4 from Hongtao.liu --- Fixed in GCC13.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #12 from Jerry DeLisle --- Created attachment 52981 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52981=edit Prposed Patch to add checks for 'comma' and 'point' This patch is pretty close. It does regression test OK.
[Bug target/105587] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-210-gfcda0efccad41eba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105587 --- Comment #3 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:69c4b5c519f0df37e4903992644cc29682721bc1 commit r13-468-g69c4b5c519f0df37e4903992644cc29682721bc1 Author: liuhongt Date: Fri May 13 15:48:01 2022 +0800 Fix ICE caused by wrong condition. When d->perm[i] == d->perm[i-1] + 1 and d->perm[i] == nelt, it's not continuous. It should fail if there's more than 2 continuous areas. gcc/ChangeLog: PR target/105587 * config/i386/i386-expand.cc (expand_vec_perm_pslldq_psrldq_por): Fail when (d->perm[i] == d->perm[i-1] + 1) && d->perm[i] == nelt && start != -1. gcc/testsuite/ChangeLog: * gcc.target/i386/pr105587.c: New test.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #11 from harper at msor dot vuw.ac.nz ---
Thank you Jerry. Commas as separators with DECIMAL = 'comma' may be
trickier because commas then do the job that decimal points normally do,
and they cannot act as separators.
Here is a little test program that reads from all 16 of "2p5q" where
p and q are comma,semicolon,blank, or point, using both 'comma' and
'point'. It gave me the same 60 lines of output with -std=f2003 or
-std=f2018
! Does list-directed reading work properly with decimal='comma' ?
implicit none
real x(2)
character(*),parameter:: punc = ",; ."
integer,parameter:: lpunc =len(punc)
integer ios,i,j
character:: msg*80, input(lpunc**2)*4 = &
[(("2"//punc(i:i)//"5"//punc(j:j),i=1,lpunc),j=1,lpunc)]
do i = 1,size(input)
print *,'i=',i,'input(i) = "',input(i),'"'
read(input(i),*,decimal='point',iostat=ios,iomsg=msg) x
print *,'with decimal=point x(:) =',x,' ios=',ios
if(ios/=0) print *,trim(msg)
x(2) = 666
read(input(i),*,decimal='comma',iostat=ios,iomsg=msg) x
print *,'with decimal=comma x(:) =',x,' ios=',ios
if(ios/=0) print *,trim(msg)
end do
end program
On Sun, 15 May 2022, jvdelisle at gcc dot gnu.org wrote:
> Date: Sun, 15 May 2022 15:56:00 +
> From: jvdelisle at gcc dot gnu.org
> To: John Harper
> Subject: [Bug fortran/105473] semicolon allowed when list-directed read
> integer with decimal='point'
> Resent-Date: Mon, 16 May 2022 03:56:12 +1200 (NZST)
> Resent-From:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
>
> --- Comment #10 from Jerry DeLisle ---
> Just completed good regression testing and have this:
>
> testinput = "1;17;3.14159"
> At line 8 of file pr105473.f90
> Fortran runtime error: Semicolon not allowed as separator with DECIMAL='point'
>
> Now I wonder if I should likewise do the same for the other case with
> DECIMAL='comma' and we find a 'comma' separator.
>
> --
> You are receiving this mail because:
> You reported the bug.
>
-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105243
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-05-16
Priority|P3 |P4
CC||kargl at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from kargl at gcc dot gnu.org ---
This fixes the problem. Someone that regularly use git will need to commit it.
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index bd586e75008..6712efd6ec8 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -6283,6 +6283,15 @@ gfc_match_data_decl (void)
goto cleanup;
}
+ /* F2018:C708. */
+ if (current_ts.type == BT_CLASS && current_attr.flavor == FL_PARAMETER)
+{
+ gfc_error ("CLASS entity at %C shall be a dummy argument or have the "
+"ALLOCATABLE or POINTER attribute.");
+ m = MATCH_ERROR;
+ goto cleanup;
+}
+
ok:
/* If we have an old-style character declaration, and no new-style
attribute specifications, then there a comma is optional between
[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Bug 83819 depends on bug 83907, which changed state. Bug 83907 Summary: missing strlen optimization for non-zero memset followed by a nul byte store https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83907 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/83907] missing strlen optimization for non-zero memset followed by a nul byte store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83907 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||13.0 Target Milestone|--- |13.0 Resolution|--- |FIXED --- Comment #3 from Roger Sayle --- This should now be fixed on mainline.
[Bug target/93082] macOS Authorization.h needs fixinclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 --- Comment #11 from Iain Sandoe --- Created attachment 52980 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52980=edit work in progress patch for this case * this is not finished (needs to be conditional on a compatibility flag) * might not be acceptable upstream (depending on whether other maintainers are willing to accept clang extension work-arounds). However, AFAICS this 'extension' would affect all targets if they were presented with such input (so that this is not actually a Darwin-specific problem) - it's just that we see it in the headers. The patch is against recent master, but I'd expect it to apply reasonably easily to 12.1, 11.3 and 10.x.
[Bug target/93082] macOS Authorization.h needs fixinclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 --- Comment #10 from Iain Sandoe --- I also have a few "clang compatibility workarounds" for GCC (including one for this specific case) - but they need putting behind some "-fclang-compatibility" flag or so. Hopefully, will work on integrating them in GCC-13. In some cases that is going to work better than a fix includes. FWIW this is not actually a bug in GCC, the bug is in the headers as Andrew points out (the value is valid in C++ but not for C): " Funny how clang thinks this was an GNU extension when it is not one." I do not currently have a plan to try and build a second fix includes tree for Frameworks, but happy to review patches if someone else does :)
[Bug target/93082] macOS Authorization.h needs fixinclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 --- Comment #9 from Bruce Korb --- Um, I didn't finish my misthink for item#1 above. Please ignore. :)
[Bug target/93082] macOS Authorization.h needs fixinclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082
--- Comment #8 from Bruce Korb ---
It should not be terribly difficult to add another include tree for fixinc to
search. Also, unless 32 is cast as forever being the only value
kAuthorizationExternalFormLength could possibly ever have:
select=
"static const size_t kAuthorizationExternalFormLength = (32);\n";
c_fix = format;
c_fix_arg =
"enum { kAuthorizationExternalFormLength = %1 };\n";
BTW:
1. if you're going to simply replace text
2. on page https://gcc.gnu.org/wiki/GitMirror the "getting started" section
leads to this error:
> fatal: 'svn/trunk' is not a commit and a branch 'trunk' cannot be created
> from it
(I don't have access to the GCC tree anymore [lost keys], so I'm starting
over.)
[Bug libstdc++/105611] New: std::shift_left/right should not use ranges::next
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105611
Bug ID: 105611
Summary: std::shift_left/right should not use ranges::next
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Because they are based on different iterator systems.
#include
struct I {
std::in_place_t in_place;
using value_type = int;
using difference_type = std::ptrdiff_t;
int& operator*() const;
I& operator++();
I operator++(int);
bool operator==(I) const;
};
int main() {
std::shift_left(I(), I(), 0);
std::shift_right(I(), I(), 0);
}
https://godbolt.org/z/v35h5Eobe
[Bug c/105557] -Wtautological-compare doesn't warn about bitwise expressions that always evaluate to true or false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105557 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- There are several other bugs about -Wtautological-compare open, and I can't tell if this is a dup of any of them at the moment; it's probably time to have a meta-bug to group them all together...
[Bug bootstrap/100932] autoconf error: possibly undefined macro: GCC_AC_ENABLE_DECIMAL_FLOAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100932 --- Comment #2 from Nicolas Boulenguez --- I fail to understand how your answer helps anyone. Currently, 'autoconf' fails and 'autoconf -I../config' succeeds. With the change, both would succeed and be equivalent. What is the benefit of requiring a command-line option when the only possible value can be provided as a default? I am using # autoreconf $(computed list of subdirectories) This would be way more difficult if I had to add a different -I option for each subdirectory.
[Bug c++/58993] incorrectly accept access of protected member method from derived class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58993 --- Comment #11 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:4df735e01e319997841574f353d2aa076a0335c2 commit r13-465-g4df735e01e319997841574f353d2aa076a0335c2 Author: Jason Merrill Date: Fri Mar 18 22:52:32 2022 -0400 c++: hidden friend access [DR1699] It has come up several times that Clang considers hidden friends of a class to be sufficiently memberly to be covered by a friend declaration naming the class. This is somewhat unclear in the standard: [class.friend] says "Declaring a class to be a friend implies that private and protected members of the class granting friendship can be named in the base-specifiers and member declarations of the befriended class." A hidden friend is a syntactic member-declaration, but is it a "member declaration"? CWG was ambivalent, and referred the question to EWG as a design choice. But recently Patrick mentioned that the current G++ choice not to treat it as a "member declaration" was making his library work significantly more cumbersome, so let's go ahead and vote the other way. This means that the testcases for 100502 and 58993 are now accepted. DR1699 PR c++/100502 PR c++/58993 gcc/cp/ChangeLog: * friend.cc (is_friend): Hidden friends count as members. * search.cc (friend_accessible_p): Likewise. gcc/testsuite/ChangeLog: * g++.dg/template/access37.C: Now OK. * g++.dg/template/friend69.C: Now OK. * g++.dg/lookup/friend23.C: New test.
[Bug c++/100502] [11/12 Regression] ICE in enforce_access at cp/semantics.c:368 since r11-6800-g29853c653245c37e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100502 --- Comment #6 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:4df735e01e319997841574f353d2aa076a0335c2 commit r13-465-g4df735e01e319997841574f353d2aa076a0335c2 Author: Jason Merrill Date: Fri Mar 18 22:52:32 2022 -0400 c++: hidden friend access [DR1699] It has come up several times that Clang considers hidden friends of a class to be sufficiently memberly to be covered by a friend declaration naming the class. This is somewhat unclear in the standard: [class.friend] says "Declaring a class to be a friend implies that private and protected members of the class granting friendship can be named in the base-specifiers and member declarations of the befriended class." A hidden friend is a syntactic member-declaration, but is it a "member declaration"? CWG was ambivalent, and referred the question to EWG as a design choice. But recently Patrick mentioned that the current G++ choice not to treat it as a "member declaration" was making his library work significantly more cumbersome, so let's go ahead and vote the other way. This means that the testcases for 100502 and 58993 are now accepted. DR1699 PR c++/100502 PR c++/58993 gcc/cp/ChangeLog: * friend.cc (is_friend): Hidden friends count as members. * search.cc (friend_accessible_p): Likewise. gcc/testsuite/ChangeLog: * g++.dg/template/access37.C: Now OK. * g++.dg/template/friend69.C: Now OK. * g++.dg/lookup/friend23.C: New test.
[Bug c++/105589] [12/13 Regression] [ICE] templated type alias over std::array with bound type in template function fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105589 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jason Merrill --- Fixed for 12.2/13.
[Bug c++/92385] extremely long and memory intensive compilation for brace construction of array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92385
--- Comment #17 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:40f749b364b740f41ea6b211f81c21919a2e8bee
commit r12-8380-g40f749b364b740f41ea6b211f81c21919a2e8bee
Author: Jason Merrill
Date: Fri May 13 16:07:10 2022 -0400
c++: array {}-init [PR105589]
My patch for 105191 made us use build_value_init more frequently from
build_vec_init_expr, but build_value_init doesn't like to be called to
initialize a class in a template. That's caused trouble in the past, and
seems like a strange restriction, so let's fix it.
PR c++/105589
PR c++/105191
PR c++/92385
gcc/cp/ChangeLog:
* init.cc (build_value_init): Handle class in template.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-array16.C: New test.
[Bug c++/105191] [12 Regression] '' "is not a constant expression" regression in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105191
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:40f749b364b740f41ea6b211f81c21919a2e8bee
commit r12-8380-g40f749b364b740f41ea6b211f81c21919a2e8bee
Author: Jason Merrill
Date: Fri May 13 16:07:10 2022 -0400
c++: array {}-init [PR105589]
My patch for 105191 made us use build_value_init more frequently from
build_vec_init_expr, but build_value_init doesn't like to be called to
initialize a class in a template. That's caused trouble in the past, and
seems like a strange restriction, so let's fix it.
PR c++/105589
PR c++/105191
PR c++/92385
gcc/cp/ChangeLog:
* init.cc (build_value_init): Handle class in template.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-array16.C: New test.
[Bug c++/105589] [12/13 Regression] [ICE] templated type alias over std::array with bound type in template function fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105589
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:40f749b364b740f41ea6b211f81c21919a2e8bee
commit r12-8380-g40f749b364b740f41ea6b211f81c21919a2e8bee
Author: Jason Merrill
Date: Fri May 13 16:07:10 2022 -0400
c++: array {}-init [PR105589]
My patch for 105191 made us use build_value_init more frequently from
build_vec_init_expr, but build_value_init doesn't like to be called to
initialize a class in a template. That's caused trouble in the past, and
seems like a strange restriction, so let's fix it.
PR c++/105589
PR c++/105191
PR c++/92385
gcc/cp/ChangeLog:
* init.cc (build_value_init): Handle class in template.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-array16.C: New test.
[Bug c++/104470] [10/11/12 Regression] internal compiler error: Segmentation fault compiling std::variant with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104470 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:73b47159d7811cf1d7aaaf78dbdd141161b93ca3 commit r12-8379-g73b47159d7811cf1d7aaaf78dbdd141161b93ca3 Author: Jason Merrill Date: Wed Apr 27 11:13:24 2022 -0400 c++: alias CTAD and member alias templates [PR104470] In this testcase, we were trying to substitute into variant>::__accepted_type, but failed to look it up because variant> doesn't exist. In other cases we already rewrite such things into a dependent reference; we need to do that for alias templates as well. This caused some testsuite regressions on alias uses outside of deduction guides, so I've made all of this rewriting conditional on a new tf_dguide tsubst flag. PR c++/104470 gcc/cp/ChangeLog: * cp-tree.h (enum tsubst_flags): Add tf_dguide. * pt.cc (tsubst_aggr_type): Check it. (tsubst_baselink, tsubst_copy): Check it. (maybe_dependent_member_ref): Check it. (instantiate_alias_template): Handle it. (build_deduction_guide): Set it. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/explicit11.C: Second example also ill-formed. * g++.dg/cpp2a/class-deduction-alias12.C: New test.
[Bug c++/49387] t.cxx:140: error: too many initializers for ‘const __class_type_info_pseudo’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49387 --- Comment #10 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5237059e04d105fe5441fa7434699eea9a34bf1b commit r12-8378-g5237059e04d105fe5441fa7434699eea9a34bf1b Author: Jason Merrill Date: Fri Apr 15 00:11:00 2022 -0400 c++: typeid and instantiation [PR102651] PR49387 was a problem with initially asking for a typeid for a class template specialization before it was complete, and later actually filling in the descriptor when the class was complete, and thus disagreeing on the form of the descriptor. I fixed that by forcing the class to be complete, but this testcase shows why that approach is problematic. So instead let's adjust the type of the descriptor later if needed. PR c++/102651 PR c++/49387 gcc/cp/ChangeLog: * rtti.cc (get_tinfo_decl_direct): Don't complete_type. (emit_tinfo_decl): Update tdesc type if needed. gcc/testsuite/ChangeLog: * g++.dg/rtti/typeid-complete1.C: New test.
[Bug c++/102651] [9/10/11/12 Regression] typeid(X**) instantiates X caused by r0-109856
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102651 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5237059e04d105fe5441fa7434699eea9a34bf1b commit r12-8378-g5237059e04d105fe5441fa7434699eea9a34bf1b Author: Jason Merrill Date: Fri Apr 15 00:11:00 2022 -0400 c++: typeid and instantiation [PR102651] PR49387 was a problem with initially asking for a typeid for a class template specialization before it was complete, and later actually filling in the descriptor when the class was complete, and thus disagreeing on the form of the descriptor. I fixed that by forcing the class to be complete, but this testcase shows why that approach is problematic. So instead let's adjust the type of the descriptor later if needed. PR c++/102651 PR c++/49387 gcc/cp/ChangeLog: * rtti.cc (get_tinfo_decl_direct): Don't complete_type. (emit_tinfo_decl): Update tdesc type if needed. gcc/testsuite/ChangeLog: * g++.dg/rtti/typeid-complete1.C: New test.
[Bug c++/92385] extremely long and memory intensive compilation for brace construction of array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92385
--- Comment #16 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:ce46d6041358052dfa26f3720732f0357c5d72e7
commit r13-463-gce46d6041358052dfa26f3720732f0357c5d72e7
Author: Jason Merrill
Date: Fri May 13 16:07:10 2022 -0400
c++: array {}-init [PR105589]
My patch for 105191 made us use build_value_init more frequently from
build_vec_init_expr, but build_value_init doesn't like to be called to
initialize a class in a template. That's caused trouble in the past, and
seems like a strange restriction, so let's fix it.
PR c++/105589
PR c++/105191
PR c++/92385
gcc/cp/ChangeLog:
* init.cc (build_value_init): Handle class in template.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-array16.C: New test.
[Bug c++/105191] [12 Regression] '' "is not a constant expression" regression in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105191
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:ce46d6041358052dfa26f3720732f0357c5d72e7
commit r13-463-gce46d6041358052dfa26f3720732f0357c5d72e7
Author: Jason Merrill
Date: Fri May 13 16:07:10 2022 -0400
c++: array {}-init [PR105589]
My patch for 105191 made us use build_value_init more frequently from
build_vec_init_expr, but build_value_init doesn't like to be called to
initialize a class in a template. That's caused trouble in the past, and
seems like a strange restriction, so let's fix it.
PR c++/105589
PR c++/105191
PR c++/92385
gcc/cp/ChangeLog:
* init.cc (build_value_init): Handle class in template.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-array16.C: New test.
[Bug c++/105589] [12/13 Regression] [ICE] templated type alias over std::array with bound type in template function fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105589
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:ce46d6041358052dfa26f3720732f0357c5d72e7
commit r13-463-gce46d6041358052dfa26f3720732f0357c5d72e7
Author: Jason Merrill
Date: Fri May 13 16:07:10 2022 -0400
c++: array {}-init [PR105589]
My patch for 105191 made us use build_value_init more frequently from
build_vec_init_expr, but build_value_init doesn't like to be called to
initialize a class in a template. That's caused trouble in the past, and
seems like a strange restriction, so let's fix it.
PR c++/105589
PR c++/105191
PR c++/92385
gcc/cp/ChangeLog:
* init.cc (build_value_init): Handle class in template.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-array16.C: New test.
[Bug c/105492] [13 Regression] ICE in set_underlying_type, at c-family/c-common.cc:8164 since r13-57-g0aa277bf0b4b7943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105492 Jason Merrill changed: What|Removed |Added Keywords||ice-on-valid-code, patch Priority|P3 |P1 --- Comment #2 from Jason Merrill --- Patch still waiting for approval. https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594135.html
[Bug c++/105589] [12/13 Regression] [ICE] templated type alias over std::array with bound type in template function fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105589 Jason Merrill changed: What|Removed |Added Keywords|patch | --- Comment #3 from Jason Merrill --- (In reply to Jason Merrill from comment #2) > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594135.html Oops, wrong PR.
[Bug c++/105589] [12/13 Regression] [ICE] templated type alias over std::array with bound type in template function fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105589 Jason Merrill changed: What|Removed |Added Priority|P3 |P1 Keywords||patch --- Comment #2 from Jason Merrill --- https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594135.html
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #10 from Jerry DeLisle --- Just completed good regression testing and have this: testinput = "1;17;3.14159" At line 8 of file pr105473.f90 Fortran runtime error: Semicolon not allowed as separator with DECIMAL='point' Now I wonder if I should likewise do the same for the other case with DECIMAL='comma' and we find a 'comma' separator.
[Bug target/105601] spidermonkey-91 fails to compile with: ../12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105601 --- Comment #14 from tt_1 --- any objections to reporting this to binutils bugzilla at sourceware?
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #9 from Jerry DeLisle --- Thank you for digging out the standards references. That was going to be my next step as the standards are notorious for these kinds of tidbits and corner cases. I have been reviewing the code implementations of this stuff so I have identified the places where checks can be added. Some of my preliminary attempts have resulted in quite a few test regressions. I am still at it here.
[Bug c++/105610] New: warn about cv qualifiers ignored for a base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105610
Bug ID: 105610
Summary: warn about cv qualifiers ignored for a base class
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fsb4000 at yandex dot ru
Target Milestone: ---
No bug here, but a feature request.
it would be nice if for such code
class Base {
public:
int base;
};
typedef const Base ConstBase;
class CDerived: public ConstBase {
public:
int derived;
};
gcc reports a warning.
http://eel.is/c++draft/class.derived.general#2.sentence-2
[Bug target/105607] sh-unknown-elf: Error: opcode not valid for this cpu variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105607 --- Comment #9 from Chris Packham --- (In reply to Andrew Pinski from comment #8) > (In reply to Chris Packham from comment #7) > > There's also > > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > > h=081c9dfb67a0d2e7425ddb5420ada588026f92ca > > That should not have an effect on the multi-libs compiled for. Indeed. I reverting it with no change. I don't know anything about the SH architecture so I can't say if -mb -m1 is a valid combination. But under GCC 11.3.0 it isn't in the default multilib list but somehow it is under GCC 12.1.0
[Bug c++/105609] New: ranges::move(_backward) should use ranges::iter_move instead of std::move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105609
Bug ID: 105609
Summary: ranges::move(_backward) should use ranges::iter_move
instead of std::move
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
This is specified in [alg.move].
#include
struct O {
O(int&);
O(int&&) = delete;
};
struct I {
using value_type = int;
using difference_type = std::ptrdiff_t;
int operator*() const;
I& operator++();
I operator++(int);
I& operator--();
I operator--(int);
bool operator==(I) const;
friend int& iter_move(const I&);
};
int main() {
O* o = nullptr;
std::ranges::move(I{}, I{}, o);
std::ranges::move_backward(I{}, I{}, o);
}
https://godbolt.org/z/KoxEPbPrP
[Bug target/105607] sh-unknown-elf: Error: opcode not valid for this cpu variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105607 --- Comment #8 from Andrew Pinski --- (In reply to Chris Packham from comment #7) > There's also > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=081c9dfb67a0d2e7425ddb5420ada588026f92ca That should not have an effect on the multi-libs compiled for.
[Bug target/105607] sh-unknown-elf: Error: opcode not valid for this cpu variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105607 --- Comment #7 from Chris Packham --- There's also https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=081c9dfb67a0d2e7425ddb5420ada588026f92ca
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #8 from harper at msor dot vuw.ac.nz --- Thank you. Unfortunately I think you found some but not all of what the standard says about semicolons as separators. You will recall that my original bug report had a program compiled with std=f2003, which should disallow extensions to that standard. (I chose f2003 because that was the first version in which POINT and COMMA appeared.) I admit that the f2003 standard 10.9 begins as follows: List-directed input/output allows data editing according to the type of the list item instead of by a format specification. It also allows data to be free-field, that is, separated by commas (or semicolons) or blanks. That would allow a free choice between comma and semicolon, except that later in 10.9 a semicolon is allowed only if the decimal edit mode is COMMA. In my test program the decimal edit mode was POINT, not COMMA. The wording that may have been overlooked was this: A value separator is (1) A comma optionally preceded by one or more contiguous blanks and optionally followed by one or more contiguous blanks, unless the decimal edit mode is COMMA, in which case a semicolon is used in place of the comma, (2) ... Equivalent wording to f2003 10.9 is in f2018 13.10.1 and 13.10.2. On Sat, 14 May 2022, jvdelisle at gcc dot gnu.org wrote: > Date: Sat, 14 May 2022 22:00:09 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug fortran/105473] semicolon allowed when list-directed read > integer with decimal='point' > Resent-Date: Sun, 15 May 2022 10:00:21 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 > > --- Comment #7 from Jerry DeLisle --- > My apologies for taking some time to get back to this. After a closer look, I > realize that in the original test case there is no problem. The semicolon is > an acceptable value separator regardless of decimal='point' or decimal='comma' > > Take these two examples: > > 1) The comma is the decimal keeper so semicolon must be used as the separator > > implicit none > integer n,m,ios > real r > character(20):: testinput = '1;17;3,14159' > n = 999 > print *,'testinput = "',testinput,'"' > read(testinput,*,decimal='comma', iostat=ios) n, m, r > print *,'n=',n,' m= ', m,' r= ', r,' ios=',ios > if(ios>0) print *,'testinput was not an integer' > end program > > 2) The point is the decimal keeper so semicolon may be used as the separator > or > a comma > > implicit none > integer n,m,ios > real r > character(20):: testinput = '1;17;3.14159' > n = 999 > print *,'testinput = "',testinput,'"' > read(testinput,*,decimal='point', iostat=ios) n, m, r > print *,'n=',n,' m= ', m,' r= ', r,' ios=',ios > if(ios>0) print *,'testinput was not an integer' > end program > > In the original test case, the semicolon is a separator and is simply ending > the read as no value is there. > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
[Bug target/105607] sh-unknown-elf: Error: opcode not valid for this cpu variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105607 --- Comment #6 from Chris Packham --- Here's the relevant snippet from the log. CC_FOR_BUILD='x86_64-build_pc-linux-gnu-gcc' CFLAGS='-O2 -g -I/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/buildtools/include ' CFLAGS_FOR_BUILD='-O2 -g -I/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/buildtools/include ' CXXFLAGS='-O2 -g -I/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/buildtools/include ' CXXFLAGS_FOR_BUILD='-O2 -g -I/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/buildtools/include ' LDFLAGS='-L/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/buildtools/lib ' CFLAGS_FOR_TARGET='-g -O2 -idirafter /home/runner/work/crosstool-ng/crosstool-ng/x-tools/sh-unknown-elf/sh-unknown-elf/include' CXXFLAGS_FOR_TARGET='-g -O2 -idirafter /home/runner/work/crosstool-ng/crosstool-ng/x-tools/sh-unknown-elf/sh-unknown-elf/include' LDFLAGS_FOR_TARGET=' -static' '/usr/bin/bash' '/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/src/gcc/configure' '--build=x86_64-build_pc-linux-gnu' '--host=x86_64-build_pc-linux-gnu' '--target=sh-unknown-elf' '--prefix=/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/buildtools' '--exec_prefix=/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/buildtools' '--with-local-prefix=/home/runner/work/crosstool-ng/crosstool-ng/x-tools/sh-unknown-elf/sh-unknown-elf' '--without-headers' '--with-newlib' '--enable-threads=no' '--disable-shared' '--with-endian=little,big' '--with-pkgversion=crosstool-NG UNKNOWN' '--enable-__cxa_atexit' '--disable-libgomp' '--disable-libmudflap' '--disable-libmpx' '--disable-libssp' '--disable-libquadmath' '--disable-libquadmath-support' '--disable-libstdcxx-verbose' '--disable-libstdcxx' '--with-gmp=/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/buildtools' '--with-mpfr=/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/buildtools' '--with-mpc=/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/buildtools' '--with-isl=/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/buildtools' '--enable-lto' '--enable-target-optspace' '--disable-nls' '--enable-multiarch' '--enable-languages=c' incidentally if anyone wants the full log it's downloadable from https://github.com/crosstool-ng/crosstool-ng/suites/6509540897/artifacts/242118465
[Bug target/105607] sh-unknown-elf: Error: opcode not valid for this cpu variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105607 --- Comment #5 from Andrew Pinski --- The only change I have saw to the sh specific files which would affect was in t-linux but that would be linux only, this is elf. r12-6929-g06995c2958aaae
[Bug target/105607] sh-unknown-elf: Error: opcode not valid for this cpu variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105607 --- Comment #4 from Andrew Pinski --- Can you provide the exact configure options you used?
[Bug target/105607] sh-unknown-elf: Error: opcode not valid for this cpu variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105607 --- Comment #3 from Chris Packham --- Just blindly comparing log files between a good and a bad build the `-mb -m1` combination appears to be new and is the one causing problems.
[Bug c/105492] [13 Regression] ICE in set_underlying_type, at c-family/c-common.cc:8164 since r13-57-g0aa277bf0b4b7943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105492 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #1 from Sergei Trofimovich --- I similar ICE proxmark3-3.1.0 on x86_64-pc-linux-gnu as well: $ cat a.c.c typedef int __attribute__((aligned)) __attribute__((vector_size(8))) bitslice_value_t; $ /tmp/gb/gcc/xgcc -B/tmp/gb/gcc -c a.c.c |& ungcc |& unnix a.c.c:2:1: internal compiler error: in set_underlying_type, at c-family/c-common.cc:8164 2 | bitslice_value_t; | ^~~~ 0x796076 set_underlying_type(tree_node*) <>/gcc/c-family/c-common.cc:8164 0x6be37a pushdecl(tree_node*) <>/gcc/c/c-decl.cc:3324 0x6d4ed7 start_decl(c_declarator*, c_declspecs*, bool, tree_node*, unsigned int*) <>/gcc/c/c-decl.cc:5285 0x74ec13 c_parser_declaration_or_fndef <>/gcc/c/c-parser.cc:2315 0x759215 c_parser_external_declaration <>/gcc/c/c-parser.cc:1787 0x759d45 c_parser_translation_unit <>/gcc/c/c-parser.cc:1660 0x759d45 c_parse_file() <>/gcc/c/c-parser.cc:23384 0x7cbfe7 c_common_parse_file() <>/gcc/c-family/c-opts.cc:1235 $ /tmp/gb/gcc/xgcc -B/tmp/gb/gcc -v Reading specs from /tmp/gb/gcc/specs COLLECT_GCC=/tmp/gb/gcc/xgcc COLLECT_LTO_WRAPPER=/tmp/gb/gcc/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: <>/configure --disable-multilib --disable-bootstrap --with-native-system-header-dir=/<>/glibc-2.34-115-dev/include --prefix=/tmp/gb/__td__ CFLAGS='-O1 -ggdb3' CXXFLAGS='-O1 -ggdb3' LDFLAGS='-O1 -ggdb3' Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.0.0 20220515 (experimental) (GCC)
[Bug preprocessor/105608] New: [13 Regression] ICE: in linemap_add, at libcpp/line-map.cc:502 on ovito-3.7.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608
Bug ID: 105608
Summary: [13 Regression] ICE: in linemap_add, at
libcpp/line-map.cc:502 on ovito-3.7.1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
ICE initially observed on ovito-3.7.1 source code where
-DCOPYRIGHT="\"${long-string}\"" is used along with precompiled headers in
standard cmake setup.
Here is a 0-file reproducer:
# create empty files and dirs:
$ mkdir -p ph
$ touch ph/h.hxx.cxx
$ touch a.cpp
# trigger the bug:
$ /tmp/gb/gcc/xg++ -B/tmp/gb/gcc -Winvalid-pch -x c++-header -o ph/h.hxx.gch -c
ph/h.hxx.cxx
$ /tmp/gb/gcc/xg++ -B/tmp/gb/gcc
-DBUG=aa
-Winvalid-pch -include ph/h.hxx -o a.o -c a.cpp
ph/h.hxx.cxx:1:116: internal compiler error: in linemap_add, at
libcpp/line-map.cc:502
0x220adce linemap_add(line_maps*, lc_reason, unsigned int, char const*,
unsigned int)
<>/libcpp/line-map.cc:502
0x220b129 linemap_line_start(line_maps*, unsigned int, unsigned int)
<>/libcpp/line-map.cc:827
0x220b3f3 linemap_position_for_column(line_maps*, unsigned int)
<>/libcpp/line-map.cc:898
0x220802b _cpp_lex_direct
<>/libcpp/lex.cc:3596
0x22119dd lex_expansion_token
<>/libcpp/macro.cc:3552
0x22119dd create_iso_definition
<>/libcpp/macro.cc:3665
0x22119dd _cpp_create_definition
<>/libcpp/macro.cc:3829
0x2214574 cpp_read_state(cpp_reader*, char const*, _IO_FILE*, save_macro_data*)
<>/libcpp/pch.cc:841
0xad8b8d c_common_read_pch(cpp_reader*, char const*, int, char const*)
<>/gcc/c-family/c-pch.cc:347
0x2201213 is_known_idempotent_file
<>/libcpp/files.cc:817
0x2201213 _cpp_stack_file
<>/libcpp/files.cc:906
0x220182e _cpp_stack_include
<>/libcpp/files.cc:1113
0x2201e26 cpp_push_include(cpp_reader*, char const*)
<>/libcpp/files.cc:1621
0xad5d51 push_command_line_include
<>/gcc/c-family/c-opts.cc:1565
0xad5e79 cb_file_change
<>/gcc/c-family/c-opts.cc:1619
0x21f95cc _cpp_do_file_change
<>/libcpp/directives.cc:1181
0x21fa073 _cpp_pop_buffer
<>/libcpp/directives.cc:2773
0x22045b0 _cpp_get_fresh_line
<>/libcpp/lex.cc:3490
0x2207eb8 _cpp_lex_direct
<>/libcpp/lex.cc:3552
0x2209867 _cpp_lex_token
<>/libcpp/lex.cc:3398
gcc-12.1.0 does not seem to be affected. Only gcc-13 fails for me including
current master.
$ /tmp/gb/gcc/xg++ -B/tmp/gb/gcc -v
Reading specs from /tmp/gb/gcc/specs
COLLECT_GCC=/tmp/gb/gcc/xg++
COLLECT_LTO_WRAPPER=/tmp/gb/gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: <>/configure --disable-multilib --disable-bootstrap
--with-native-system-header-dir=/<>/glibc-2.34-115-dev/include
--prefix=/tmp/gb/__td__ CFLAGS='-O1 -ggdb3' CXXFLAGS='-O1 -ggdb3' LDFLAGS='-O1
-ggdb3'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220515 (experimental) (GCC)
[Bug target/105607] sh-unknown-elf: Error: opcode not valid for this cpu variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105607 --- Comment #2 from Chris Packham --- binutils is the same but I did update the kernel headers.
[Bug target/105607] sh-unknown-elf: Error: opcode not valid for this cpu variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105607 --- Comment #1 from Andrew Pinski --- >The same configuration/build recipe successfully builds GCC 11.3.0 Did you change binutils too or they kept the same?
[Bug target/105601] spidermonkey-91 fails to compile with: ../12.1.0/include/g++-v12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105601 --- Comment #13 from tt_1 --- Created attachment 52979 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52979=edit verbose output with -v and binutils-2.38 don't see any difference with binutils-2.38?
[Bug libgcc/105607] New: sh-unknown-elf: Error: opcode not valid for this cpu variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105607 Bug ID: 105607 Summary: sh-unknown-elf: Error: opcode not valid for this cpu variant Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: judge.packham at gmail dot com Target Milestone: --- I'm in the process of adding GCC 12.1.0 to crosstool-ng. When building for sh-unknown-elf we see the following errors building libgcc [ALL ] /home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/build/build-cc-gcc-core/./gcc/xgcc -B/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/build/build-cc-gcc-core/./gcc/ -B/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/buildtools/sh-unknown-elf/bin/ -B/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/buildtools/sh-unknown-elf/lib/ -isystem /home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/buildtools/sh-unknown-elf/include -isystem /home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/buildtools/sh-unknown-elf/sys-include -g -O2 -idirafter /home/runner/work/crosstool-ng/crosstool-ng/x-tools/sh-unknown-elf/sh-unknown-elf/include -g -Os -mb -m1 -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../../.././gcc -I/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/src/gcc/libgcc -I/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/src/gcc/libgcc/. -I/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/src/gcc/libgcc/../gcc -I/home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/src/gcc/libgcc/../include -DHAVE_CC_TLS -o _movmem_i4_s.o -MT _movmem_i4_s.o -MD -MP -MF _movmem_i4_s.dep -DSHARED -DL_movmem_i4 -xassembler-with-cpp -c /home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/src/gcc/libgcc/config/sh/lib1funcs.S [ALL ] /home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/src/gcc/libgcc/config/sh/lib1funcs.S: Assembler messages: [ERROR] /home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/src/gcc/libgcc/config/sh/lib1funcs.S:933: Error: opcode not valid for this cpu variant [ERROR] /home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/src/gcc/libgcc/config/sh/lib1funcs.S:935: Error: opcode not valid for this cpu variant [ERROR] /home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/src/gcc/libgcc/config/sh/lib1funcs.S:942: Error: opcode not valid for this cpu variant [ERROR] /home/runner/work/crosstool-ng/crosstool-ng/.build/sh-unknown-elf/src/gcc/libgcc/config/sh/lib1funcs.S:944: Error: opcode not valid for this cpu variant [ERROR]make[4]: *** [Makefile:491: _movmem_i4_s.o] Error 1 The same configuration/build recipe successfully builds GCC 11.3.0 The assembly that is being complained about is 931 L_movmem_loop: 932 mov.l r3,@(12,r4) 933 dt r6 934 mov.l @r5+,r0 935 bt/sL_movmem_2mod4_end 936 mov.l @r5+,r1 937 add #16,r4 938 L_movmem_start_even: 939 mov.l @r5+,r2 940 mov.l @r5+,r3 941 mov.l r0,@r4 942 dt r6 943 mov.l r1,@(4,r4) 944 bf/sL_movmem_loop 945 mov.l r2,@(8,r4) 946 rts 947 mov.l r3,@(12,r4) The code in question hasn't changed in many years so I assume it's something to do with GCC passing the CPU information to gas
[Bug c++/105606] [12 Regression] std::pair with nested struct and NSDMI and -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105606 --- Comment #6 from Andrew Pinski --- (In reply to Joel Johnson from comment #4) > > Wait you didn't mention you needed -std=c++20 to get the failure. > > Ah indeed, my apologies! > > I'm unable to reproduce the Clang failure using -std=c++20, at least in a > quick godbolt check at https://godbolt.org/z/3W4xeYdWs. Try clang trunk. clang 14 in godbolt uses the libstdc++ headers from GCC 11.2.0.
[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102199 Andrew Pinski changed: What|Removed |Added CC||mrjoel at lixil dot net --- Comment #8 from Andrew Pinski --- *** Bug 105606 has been marked as a duplicate of this bug. ***
[Bug c++/105606] [12 Regression] std::pair with nested struct and NSDMI and -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105606 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #5 from Andrew Pinski --- There was libstdc++ change to better support C++20. *** This bug has been marked as a duplicate of bug 102199 ***
[Bug c++/105606] [12 Regression] std::pair with nested struct and NSDMI and -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105606 --- Comment #4 from Joel Johnson --- > Wait you didn't mention you needed -std=c++20 to get the failure. Ah indeed, my apologies! I'm unable to reproduce the Clang failure using -std=c++20, at least in a quick godbolt check at https://godbolt.org/z/3W4xeYdWs.
[Bug c++/105606] [12 Regression] std::pair with nested struct and NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105606 --- Comment #3 from Andrew Pinski --- Note clang also rejects it for -std=c++20 and accepts it for -std=c++17. Let me dig into the changes, I suspect this is another standard change.
[Bug c++/105606] [12 Regression] std::pair with nested struct and NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105606 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #2 from Andrew Pinski --- Wait you didn't mention you needed -std=c++20 to get the failure.
[Bug c++/96645] [9/10/11/12/13 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 Andrew Pinski changed: What|Removed |Added CC||mrjoel at lixil dot net --- Comment #28 from Andrew Pinski --- *** Bug 105606 has been marked as a duplicate of this bug. ***
[Bug c++/105606] [12 Regression] std::pair with nested struct and NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105606 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Both examples compile just fine with the released GCC 12. You must be using a pre-released version when testing. *** This bug has been marked as a duplicate of bug 96645 ***
