Re: [arm] MVE: Relax addressing modes for full loads and stores
Hi André, On Fri, Jan 14, 2022 at 6:03 PM Andre Vieira (lists) via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > Hi Christophe, > > This patch relaxes the addressing modes for the mve full load and stores > (by full loads and stores I mean non-widening or narrowing loads and > stores resp). The code before was requiring a LO_REGNUM for these, where > this is only a requirement if the load is widening or the store narrowing. > > So with this your patch should not be necessary. > > Regression tested on arm-none-eabi-gcc. Can you please confirm this > fixes the issue you were seeing too? > Yes, I confirm this fixes the problem I was fixing with my patch #15 in my MVE/VCMP/VCOND series. I'll drop it. Thanks! Christophe > > gcc/ChangeLog: > > * config/arm/arm.h (MVE_STN_LDW_MODE): New MACRO. > * config/arm/arm.c (mve_vector_mem_operand): Relax constraint on > base register for non widening loads or narrowing stores. > > > Kind Regards, > Andre Vieira
Re: [PATCH 1/3] tree-ssa-sink: do not sink to in front of setjmp
On Fri, Jan 14, 2022 at 7:21 PM Alexander Monakov wrote:
>
> gcc/ChangeLog:
>
> * tree-ssa-sink.c (select_best_block): Punt if selected block
> has incoming abnormal edges.
OK.
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/setjmp-7.c: New test.
> ---
> gcc/testsuite/gcc.dg/setjmp-7.c | 13 +
> gcc/tree-ssa-sink.c | 6 ++
> 2 files changed, 19 insertions(+)
> create mode 100644 gcc/testsuite/gcc.dg/setjmp-7.c
>
> diff --git a/gcc/testsuite/gcc.dg/setjmp-7.c b/gcc/testsuite/gcc.dg/setjmp-7.c
> new file mode 100644
> index 0..44b5bcbfa
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/setjmp-7.c
> @@ -0,0 +1,13 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fno-guess-branch-probability -w" } */
> +/* { dg-require-effective-target indirect_jumps } */
> +
> +struct __jmp_buf_tag { };
> +typedef struct __jmp_buf_tag jmp_buf[1];
> +struct globals { jmp_buf listingbuf; };
> +extern struct globals *const ptr_to_globals;
> +void foo()
> +{
> +if ( _setjmp ( ((*ptr_to_globals).listingbuf )))
> + ;
> +}
> diff --git a/gcc/tree-ssa-sink.c b/gcc/tree-ssa-sink.c
> index 66d7ae89e..016ecbaec 100644
> --- a/gcc/tree-ssa-sink.c
> +++ b/gcc/tree-ssa-sink.c
> @@ -208,6 +208,12 @@ select_best_block (basic_block early_bb,
>temp_bb = get_immediate_dominator (CDI_DOMINATORS, temp_bb);
> }
>
> + /* Placing a statement before a setjmp-like function would be invalid
> + (it cannot be reevaluated when execution follows an abnormal edge).
> + If we selected a block with abnormal predecessors, just punt. */
> + if (bb_has_abnormal_pred (best_bb))
> +return early_bb;
> +
>/* If we found a shallower loop nest, then we always consider that
> a win. This will always give us the most control dependent block
> within that loop nest. */
> --
> 2.33.1
>
[Bug fortran/104048] ICE with recursively defined derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104048 --- Comment #3 from Andrew Pinski --- (In reply to Arjen Markus from comment #2) > That reduced example is wonderfully compact! (I checked for similar reports > but probably missed bug report 79440, because it was not associated with > "recursive" data types) Because I don't think it is related at all to recursive data types at all take: MODULE h TYPE :: tt END TYPE tt TYPE :: tt1 TYPE(tt), ALLOCATABLE :: left_view END TYPE tt1 CONTAINS FUNCTION ff( arg ) result(res) CLASS(tt), INTENT(IN) :: arg CLASS(tt1), ALLOCATABLE :: res ALLOCATE( res ) res%left_view = arg END FUNCTION ff END MODULE We get the same ICE.
[Bug fortran/104048] ICE with recursively defined derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104048 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-17
[Bug fortran/104048] ICE with recursively defined derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104048 --- Comment #2 from Arjen Markus --- That reduced example is wonderfully compact! (I checked for similar reports but probably missed bug report 79440, because it was not associated with "recursive" data types)
Re: [patch, libgfortran, power-ieee128] Add multiple defaults for GFORTRAN_CONVERT_UNIT
On 13.01.22 22:58, Thomas Koenig via Fortran wrote: with this patch, it is now possible to specify both the endianness and the REAL(KIND=16) format using the environment variable GFORTRAN_CONVERT_UNIT. I have now pushed this to trunk. Best regards Thomas
[Bug target/100952] [12 regression] several test case failures after r12-1202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952 --- Comment #16 from HaoChen Gui --- prefix-no-update.c should be fixed by the patch Segher proposed in PR103197. pr56605.c got a wrong fixed and failed with GCC11. I will submit a patch to fix it.
[Bug target/103197] ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197 HaoChen Gui changed: What|Removed |Added CC||guihaoc at gcc dot gnu.org --- Comment #11 from HaoChen Gui --- Segher, Will you commit your patch in stage4? Several issues are supposed to be fixed by your patch. Thanks.
Re: [PATCH] rs6000: Use known constant for GET_MODE_NUNITS and similar
on 2022/1/14 下午9:53, David Edelsohn wrote: > On Fri, Jan 14, 2022 at 5:42 AM Kewen.Lin wrote: >> >> on 2022/1/13 下午11:15, David Edelsohn wrote: >>> On Thu, Jan 13, 2022 at 7:40 AM Kewen.Lin wrote: Hi David, on 2022/1/13 上午11:12, David Edelsohn wrote: > On Wed, Jan 12, 2022 at 8:56 PM Kewen.Lin wrote: >> >> Hi, >> >> This patch is to clean up some codes with GET_MODE_UNIT_SIZE or >> GET_MODE_NUNITS, which can use known constant instead. > > I'll let Segher decide, but often the additional code is useful > self-documentation instead of magic constants. Or at least the change > requires comments documenting the derivation of the constants > currently described by the code itself. > Thanks for the comments, I added some comments as suggested, also removed the whole "altivec_vreveti2" since I noticed it's useless, it's not used by any built-in functions and even unused in the commit db042e1603db50573. The updated version has been tested as before. >>> >>> As we have discussed offline, the comments need to be clarified and >>> expanded. >>> >>> And the removal of altivec_vreveti2 should be confirmed with Carl >>> Love, who added the pattern less than a year ago. There may be another >>> patch planning to use it. >>> >> >> Thanks for the suggestions David! The comments have been updated, and Carl >> also helped to confirm the altivec_vreveti2 pattern is not planned for any >> future work and looks reasonable to remove. >> >> Does this updated version look good to you? > > The revised patch is okay. Thanks! Committed as r12-6621. BR, Kewen
[Bug target/103124] PPC: "mr" instruction is unnecessary when extending DI to V1TI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103124 --- Comment #6 from CVS Commits --- The master branch has been updated by HaoChen Gui : https://gcc.gnu.org/g:240dd6c063b481c092c9ec406b69b400f6f033f1 commit r12-6620-g240dd6c063b481c092c9ec406b69b400f6f033f1 Author: Haochen Gui Date: Mon Jan 17 11:24:20 2022 +0800 rs6000: Split pattern for TI to V1TI move [PR103124] This patch defines a new split pattern for TI to V1TI move. The pattern concatenates two subreg:DI of a TI to a V2DI. With the pattern, the subreg pass can do register split for TI when there is a TI to V1TI move. gcc/ PR target/103124 * config/rs6000/vsx.md (split pattern for TI to V1TI move): Defined. gcc/testsuite/ PR target/103124 * gcc.target/powerpc/pr103124.c: New testcase.
[r12-6616 Regression] FAIL: gfortran.dg/ieee/signaling_3.f90 -Os execution test on Linux/x86_64
On Linux/x86_64,
86e3b476d5defaa79c94d40b76cbeec21cd02e5f is the first bad commit
commit 86e3b476d5defaa79c94d40b76cbeec21cd02e5f
Author: Francois-Xavier Coudert
Date: Mon Jan 17 00:00:18 2022 +0100
Fortran: xfail signaling NaN testcases on x87
caused
FAIL: gfortran.dg/ieee/signaling_3.f90 -O0 execution test
FAIL: gfortran.dg/ieee/signaling_3.f90 -O1 execution test
FAIL: gfortran.dg/ieee/signaling_3.f90 -O2 execution test
FAIL: gfortran.dg/ieee/signaling_3.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/ieee/signaling_3.f90 -O3 -g execution test
FAIL: gfortran.dg/ieee/signaling_3.f90 -Os execution test
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-6616/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="ieee.exp=gfortran.dg/ieee/signaling_3.f90
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="ieee.exp=gfortran.dg/ieee/signaling_3.f90
--target_board='unix{-m32\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
[Bug rtl-optimization/104059] [12 Regression] cprop_hardreg propgates hard registers for mov instructions between different REG_CLASS without considering cost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104059 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-01-17 Summary|cprop_hardreg propgates |[12 Regression] |hard registers for mov |cprop_hardreg propgates |instructions between|hard registers for mov |different REG_CLASS without |instructions between |considering cost|different REG_CLASS without ||considering cost Component|target |rtl-optimization --- Comment #1 from Andrew Pinski --- Confirmed, I see it even on aarch64: addvs0, v0.4s fmovw0, s0 fmovw1, s0 In GCC 11 we get: ldr q0, [x1] shl v0.4s, v0.4s, 1 addvs0, v0.4s fmovw0, s0 lsr w1, w0, 16 add w0, w1, w0, uxth lsr w0, w0, 1 While on the trunk we get: shl v0.4s, v0.4s, 1 addvs0, v0.4s fmovw0, s0 fmovw1, s0 and w0, w0, 65535 add w0, w0, w1, lsr 16 lsr w0, w0, 1
[Bug tree-optimization/104060] [11/12 Regression] -Wmaybe-uninitialized false alarm on address of local array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104060
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2022-01-17
Known to work||10.3.0
Summary|-Wmaybe-uninitialized false |[11/12 Regression]
|alarm on address of local |-Wmaybe-uninitialized false
|array |alarm on address of local
||array
Known to fail||11.1.0
Keywords||diagnostic
Target Milestone|--- |11.3
--- Comment #1 from Andrew Pinski ---
Confirmed reduced further:
void *ptr_align (void const *ptr, unsigned long alignment);
int j (void)
{
unsigned char j[1];
unsigned char *k = ptr_align (j, 1024);
return !k;
}
The warning is suspect to make sure you have accessed something inside j before
the call to ptr_align but it looks like the warning just produces false
positive 100% of the time in this testcase and there is no way for the warning
to be shut up correctly..
There is no way for GCC to know what ptr_align does, GCC thinks it reads from
the first argument but it does not.
Note my recommendation to how to fix this is we should just revert this warning
which was added for GCC 11 and close the original bug which asks about this
warning as won't fix.
[Bug tree-optimization/104060] New: -Wmaybe-uninitialized false alarm on address of local array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104060 Bug ID: 104060 Summary: -Wmaybe-uninitialized false alarm on address of local array Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: eggert at cs dot ucla.edu Target Milestone: --- Created attachment 52209 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52209=edit compile with 'gcc -Wuninitialized' to see the false alarm I ran into this problem when compiling an experimental version of GNU coreutils with gcc 11.2.1 20211203 (Red Hat 11.2.1-7), x86-64. This is a regression, since gcc 8.5.0 20210514 (Red Hat 8.5.0-4) does not have the problem. Compile the attached program with 'gcc -Wuninitialized -S false-alarm-uninit.c'. There should be no output, but GCC outputs the following. The diagnostic is incorrect, as bin_buffer_unaligned is an array that is never read from or written to. Apparently GCC is getting confused because the array's address is taken (but that address is never dereferenced). false-alarm-uninit.c: In function ‘digest_check’: false-alarm-uninit.c:13:31: warning: ‘bin_buffer_unaligned’ may be used uninitialized [-Wmaybe-uninitialized] 13 | unsigned char *bin_buffer = ptr_align (bin_buffer_unaligned, 1024); | ^~ false-alarm-uninit.c:2:1: note: by argument 1 of type ‘const void *’ to ‘ptr_align’ declared here 2 | ptr_align (void const *ptr, unsigned long alignment) | ^ false-alarm-uninit.c:12:17: note: ‘bin_buffer_unaligned’ declared here 12 | unsigned char bin_buffer_unaligned[1]; | ^~~~
[Bug target/104059] New: cprop_hardreg propgates hard registers for mov instructions between different REG_CLASS without considering cost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104059
Bug ID: 104059
Summary: cprop_hardreg propgates hard registers for mov
instructions between different REG_CLASS without
considering cost
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
int test (uint8_t *p, uint32_t t[1][1], int n) {
int sum = 0;
uint32_t a0;
for (int i = 0; i < 4; i++, p++)
t[i][0] = p[0];
for (int i = 0; i < 4; i++) {
{
int t0 = t[0][i] + t[0][i];
a0 = t0;
};
sum += a0;
}
return (((uint16_t)sum) + ((uint32_t)sum >> 16)) >> 1;
}
testcase is from PR104049, for x86 with -O3 -mavx2 ,before cprop_hardregs it's
before cprop_hardreg--
(insn 100 79 81 2 (set (reg:SI 1 dx [orig:90 stmp__9.14 ] [90])
(reg:SI 20 xmm0 [114])) 81 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 20 xmm0 [114])
(nil)))
(debug_insn 81 100 96 2 (debug_marker) "/app/example.cpp":16:3 -1
(nil))
(insn 96 81 82 2 (set (reg:SI 0 ax [116])
(reg:SI 1 dx [orig:90 stmp__9.14 ] [90])) "/app/example.cpp":16:44 81
{*movsi_internal}
(nil))
---end
--after cprop_hardreg
(insn 100 79 81 2 (set (reg:SI 1 dx [orig:90 stmp__9.14 ] [90])
(reg:SI 20 xmm0 [114])) 81 {*movsi_internal}
(nil))
(debug_insn 81 100 96 2 (debug_marker) "/app/example.cpp":16:3 -1
(nil))
(insn 96 81 82 2 (set (reg:SI 0 ax [116])
(reg:SI 20 xmm0 [orig:90 stmp__9.14 ] [90])) "/app/example.cpp":16:44
81 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 20 xmm0 [orig:90 stmp__9.14 ] [90])
(nil)))
--end--
it's
vmovd edx, xmm0
movl eax, edx
vs
vmovd edx, xmm0
vmovd eax, xmm0
vmovd is expensive for many x86 targets.
Ping Re: [PATCH] middle-end: move initialization of stack_limit_rtx [PR103163]
On 1/8/22 9:24 PM, Sandra Loosemore wrote: This patch fixes the ICE I reported in PR103163. We were initializing stack_limit_rtx before the register properties it depends on were getting set. I moved it to the same function where stack_pointer_rtx, frame_pointer_rtx, etc are being initialized. Besides nios2 where I observed it, this bug was also reported to affect powerpc. Anybody want to check it there? Otherwise, OK to check in? Ping? https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587958.html -Sandra
[Bug fortran/104048] ICE with recursively defined derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104048 Andrew Pinski changed: What|Removed |Added Known to fail||7.1.0 Keywords||ice-on-valid-code --- Comment #1 from Andrew Pinski --- Confirmed, reduced testcase: MODULE h TYPE :: tt TYPE(tt), ALLOCATABLE :: left_view END TYPE tt CONTAINS FUNCTION ff( arg ) result(res) CLASS(tt), INTENT(IN) :: arg CLASS(tt), ALLOCATABLE :: res ALLOCATE( res ) res%left_view = arg END FUNCTION ff END MODULE
[Bug fortran/104047] Invalid result with assignment of recursive derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104047 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-17 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Simplified testcase: program chkrecursive implicit none type recursive integer :: chk type(recursive), allocatable :: next end type recursive type(recursive) :: chain2 chain2%chk = 2 chain2%next = chain2 chain2%chk = 2 chain2%next = chain2 if (chain2%next%next%chk .ne. 2) then call abort end if end program chkrecursive
[Bug target/104039] AArch64 Redundant instruction moving general to vector register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104039
Andrew Pinski changed:
What|Removed |Added
Known to fail||9.1.0
Severity|enhancement |normal
Target Milestone|--- |9.5
Known to work||8.5.0
--- Comment #2 from Andrew Pinski ---
So back in GCC 8.5 we used dup to create the initial vector and then did an
insert. for floating point registers this works fine.
But if we do:
typedef double f64x2 __attribute__((vector_size(16)));
f64x2 combine(double a, double b) {
asm("// %0 %1":"+r"(a));
f64x2 v = {a,b};
return v;
}
We get two ins which we should not get.
While in GCC 8.5.0 we got:
fmovx0, d0
// x0 x0
fmovd0, x0
dup v0.2d, v0.d[0]
ins v0.d[1], v1.d[0]
Which is also wrong because there is no reason for a fmov/dup, just fmov is
enough.
[Bug rtl-optimization/104049] [12 Regression] vec_select to subreg lowering causes superfluous moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-17 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104039 Target Milestone|--- |12.0 Ever confirmed|0 |1 Keywords||ra --- Comment #1 from Andrew Pinski --- This might be the same issue as PR 104039 really, though there we have a paradoxical subreg. The problem is the register allocator really really does not handle subreg in a decent way.
[Bug tree-optimization/104058] [12 Regression] 6-7% x264_r regression with -march=native -Ofast -funroll-loops -flto on x86 since r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104058 --- Comment #1 from Andrew Pinski --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997#c4 might be the discussion around what is happening.
[Bug tree-optimization/104058] [12 Regression] 6-7% x264_r regression with -march=native -Ofast -funroll-loops -flto on x86 since r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104058 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Blocks||53947 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/104058] New: [12 Regression] 6-7% x264_r regression with -march=native -Ofast -funroll-loops -flto on x86 since r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104058 Bug ID: 104058 Summary: [12 Regression] 6-7% x264_r regression with -march=native -Ofast -funroll-loops -flto on x86 since r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: admin at levyhsu dot com Target Milestone: --- We observed regression on 525.x264_r with commit d3ff7420e941931d32ce2e332e7968fe67ba20af On IceLake(8358): -7.27% On Zen3(7763): -6.67% On Zen3(5800x): -6.45% The regression on Zen 3 can also be found in https://lnt.opensuse.org/db_default/v4/SPEC/graph?highlight_run=22984=475.377.0
[r12-6615 Regression] FAIL: gfortran.dg/ieee/signaling_2.f90 -Os execution test on Linux/x86_64
On Linux/x86_64,
90045c5df5b3c8853e7740fb72a11aead1c489bb is the first bad commit
commit 90045c5df5b3c8853e7740fb72a11aead1c489bb
Author: Francois-Xavier Coudert
Date: Mon Jan 10 17:04:34 2022 +0100
Fortran: allow IEEE_VALUE to correctly return signaling NaNs
caused
FAIL: gfortran.dg/ieee/signaling_2.f90 -O0 execution test
FAIL: gfortran.dg/ieee/signaling_2.f90 -O1 execution test
FAIL: gfortran.dg/ieee/signaling_2.f90 -O2 execution test
FAIL: gfortran.dg/ieee/signaling_2.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: gfortran.dg/ieee/signaling_2.f90 -O3 -g execution test
FAIL: gfortran.dg/ieee/signaling_2.f90 -Os execution test
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-6615/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="ieee.exp=gfortran.dg/ieee/signaling_2.f90
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="ieee.exp=gfortran.dg/ieee/signaling_2.f90
--target_board='unix{-m32\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057
--- Comment #21 from cqwrteur ---
(In reply to cqwrteur from comment #18)
> (In reply to Andrew Pinski from comment #17)
> > also multilib directories under ${prefix} for a cross does not use OS
> > directories as most cross compilers have OS directories.
>
> Of course. I installed Linux kernel headers and glibc.
>
> they are installed in $PREFIX/$TARGET
>
> Since we need to build 32 glibc, x32 glibc, 64 glibc. I installed them into
> separate dirs and copy files with each other. Or they will overwrite file.
>
> Then copy all headers to $PREFIX/$TARGET/include
>
> glibc32/lib to $PREFIX/lib32 $PREFIX/lib/32
>
> glibc64/lib to $PREFIX/lib64 $PREFIX/lib
>
> glibcx32/lib to $PREFIX/libx32 $PREFIX/lib/x32
glibc32/lib to $PREFIX/$TARGET/lib32 $PREFIX/$TARGET/lib/32
glibc64/lib to $PREFIX/$TARGET/lib64 $PREFIX/$TARGET/lib
glibcx32/lib to $PREFIX/$TARGET/libx32 $PREFIX/$TARGET/lib/x32
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057
--- Comment #20 from cqwrteur ---
(In reply to cqwrteur from comment #18)
> (In reply to Andrew Pinski from comment #17)
> > also multilib directories under ${prefix} for a cross does not use OS
> > directories as most cross compilers have OS directories.
>
> Of course. I installed Linux kernel headers and glibc.
>
> they are installed in $PREFIX/$TARGET
>
> Since we need to build 32 glibc, x32 glibc, 64 glibc. I installed them into
> separate dirs and copy files with each other. Or they will overwrite file.
>
> Then copy all headers to $PREFIX/$TARGET/include
>
> glibc32/lib to $PREFIX/lib32 $PREFIX/lib/32
>
> glibc64/lib to $PREFIX/lib64 $PREFIX/lib
>
> glibcx32/lib to $PREFIX/libx32 $PREFIX/lib/x32
I use the first gcc to build them to build libgcc and libsupc++.
Build them to build glibc.
Then rebuild entire gcc with glibc.
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057
--- Comment #19 from cqwrteur ---
(In reply to cqwrteur from comment #18)
> (In reply to Andrew Pinski from comment #17)
> > also multilib directories under ${prefix} for a cross does not use OS
> > directories as most cross compilers have OS directories.
>
> Of course. I installed Linux kernel headers and glibc.
>
> they are installed in $PREFIX/$TARGET
>
> Since we need to build 32 glibc, x32 glibc, 64 glibc. I installed them into
> separate dirs and copy files with each other. Or they will overwrite file.
>
> Then copy all headers to $PREFIX/$TARGET/include
>
> glibc32/lib to $PREFIX/lib32 $PREFIX/lib/32
>
> glibc64/lib to $PREFIX/lib64 $PREFIX/lib
>
> glibcx32/lib to $PREFIX/libx32 $PREFIX/lib/x32
https://pete.akeo.ie/2010/07/compiling-mingw-w64-with-multilib-on.html
Here was a similar result other people built 10 years ago. I find this issue
happens for all targets, not just x86_64-w64-mingw32. The GCC just find
different directories at build stage and after build.
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057
--- Comment #18 from cqwrteur ---
(In reply to Andrew Pinski from comment #17)
> also multilib directories under ${prefix} for a cross does not use OS
> directories as most cross compilers have OS directories.
Of course. I installed Linux kernel headers and glibc.
they are installed in $PREFIX/$TARGET
Since we need to build 32 glibc, x32 glibc, 64 glibc. I installed them into
separate dirs and copy files with each other. Or they will overwrite file.
Then copy all headers to $PREFIX/$TARGET/include
glibc32/lib to $PREFIX/lib32 $PREFIX/lib/32
glibc64/lib to $PREFIX/lib64 $PREFIX/lib
glibcx32/lib to $PREFIX/libx32 $PREFIX/lib/x32
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057
--- Comment #17 from Andrew Pinski ---
also multilib directories under ${prefix} for a cross does not use OS
directories as most cross compilers have OS directories.
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057
--- Comment #16 from Andrew Pinski ---
There are a definitely a few steps missing,
Where is the Linux headers installed?
How did you configure glibc and install it?
I don't see you copying the headers of glibc anywhere.
sysroots make it easier to place just the normal OS directory structure under
${prefix}/${target}/sys-root/ which is why it is the recommened way.
If sys-root is broken for mingw we should fix that instead.
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057 --- Comment #15 from cqwrteur --- (In reply to cqwrteur from comment #14) > export PATH=$PREFIX/bin:$PATH > > sorry x86_64-ubuntu-linux-gnu-g++ -v Using built-in specs. COLLECT_GCC=x86_64-ubuntu-linux-gnu-g++ COLLECT_LTO_WRAPPER=/home/cqwrteur/toolchains/gnu/native/x86_64-ubuntu-linux-gnu/libexec/gcc/x86_64-ubuntu-linux-gnu/12.0.0/lto-wrapper Target: x86_64-ubuntu-linux-gnu Configured with: ../../../../gcc/configure --disable-nls --disable-werror --target=x86_64-ubuntu-linux-gnu --prefix=/home/cqwrteur/toolchains/gnu/native/x86_64-ubuntu-linux-gnu --disable-libstdcxx-verbose --disable-bootstrap --enable-languages=c,c++ --with-multilib-list=m64,m32,mx32 --enable-multilib --with-gxx-libcxx-include-dir=/home/cqwrteur/toolchains/gnu/native/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/include/c++/v1 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20220116 (experimental) (GCC)
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057 --- Comment #14 from cqwrteur --- export PATH=$PREFIX/bin:$PATH sorry
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057 --- Comment #13 from cqwrteur --- (In reply to Andrew Pinski from comment #12) > I don't care about your youtube videos (they are not accessable due to not > having > the steps written down). I need the steps written here in the bug report. export TARGET=x86_64-ubuntu-linux-gnu export PREFIX=$HOME/cross/$TARGET export PATH=$PREFIX:$PATH ../../binutils-gdb/configure --disable-werror --disable-nls --target=$TARGET --enable-gold --with-python3 --prefix=$PREFIX ../../gcc/configure --disable-nls --disable-werror --target=$TARGET --prefix=$PREFIX --without-headers --with-newlib --disable-hosted-libstdcxx --disable-shared --disable-threads --enable-languages=c,c++ Use this to build a x86_64-ubuntu-linux-gnu-gcc to build glibc glibc 32,64,x32 copy glibc32/lib to $PREFIX/$TARGET/lib/32 and $PREFIX/$TARGET/lib32 copy glibc64/lib to $PREFIX/$TARGET/lib $PREFIX/$TARGET/lib64 copy glibcx32/lib to $PREFIX/$TARGET/lib/x32 $PREFIX/$TARGET/libx32 Then build gcc2. ../../gcc/configure --disable-nls --disable-werror --target=$TARGET --prefix=$PREFIX --disable-libstdcxx-verbose --enable-languages=c,c++ then copy all files from lib32 to lib (since GCC cannot find 32bit libs in lib32 for x86_64-linux-gnu) Done
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057 --- Comment #12 from Andrew Pinski --- I don't care about your youtube videos (they are not accessable due to not having the steps written down). I need the steps written here in the bug report.
Re: [PATCH v2 RFA] diagnostic: avoid repeating include path
On Fri, 2022-01-14 at 23:01 -0500, Jason Merrill wrote:
> On 1/13/22 17:30, David Malcolm wrote:
> > On Thu, 2022-01-13 at 17:08 -0500, Jason Merrill wrote:
> > > When a sequence of diagnostic messages bounces back and forth
> > > repeatedly
> > > between two includes, as with
> > >
> > > #include
> > > std::map m ("123", "456");
> > >
> > > The output is quite a bit longer than necessary because we dump
> > > the
> > > include
> > > path each time it changes. I'd think we could print the include
> > > path
> > > once
> > > for each header file, and then expect that the user can look
> > > earlier
> > > in the
> > > output if they're wondering.
> > >
> > > Tested x86_64-pc-linux-gnu, OK for trunk?
> > >
> > > gcc/ChangeLog:
> > >
> > > * diagnostic.c (includes_seen): New.
> > > (diagnostic_report_current_module): Use it.
> > > ---
> > > gcc/diagnostic.c | 12 +++-
> > > 1 file changed, 11 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
> > > index 58139427d01..e56441a2dbf 100644
> > > --- a/gcc/diagnostic.c
> > > +++ b/gcc/diagnostic.c
> > > @@ -700,6 +700,16 @@ set_last_module (diagnostic_context
> > > *context,
> > > const line_map_ordinary *map)
> > > context->last_module = map;
> > > }
> > >
> > > +/* Only dump the "In file included from..." stack once for each
> > > file. */
> > > +
> > > +static bool
> > > +includes_seen (const line_map_ordinary *map)
> > > +{
> > > + using hset = hash_set;
> > > + static hset *set = new hset;
> > > + return set->add (map);
> > > +}
> >
> > Overall, I like the idea, but...
> >
> > - the patch works at the level of line_map_ordinary instances,
> > rather
> > than header files. There are various ways in which a single header
> > file can have multiple line maps e.g. due to very long lines, or
> > including another file, etc. I think it makes sense to do it at
> > the
> > per-file level, assuming we aren't in a horrible situation where a
> > header is being included repeatedly, with different effects. So
> > maybe
> > this ought to look at what include directive led to this map, i.e.
> > looking at the ord_map->included_from field, and having a
> > hash_set ?
>
> Done. This version doesn't affect printing of the module import path
> yet, pending more consideration of whether we always want to identify
> the module it comes from or just the file/line is enough.
Seems like a good choice given that everyone's going to be much less
familiar with modules than with include files, for some time.
>
> > - there's no test coverage, but it's probably not feasible to write
> > DejaGnu tests for this, given the way prune.exp's prune_gcc_output
> > strips these strings. Maybe a dg directive to selectively disable
> > the
> > pertinent pruning operations in prune_gcc_output??? Gah...
> >
> > - global state is a pet peeve of mine; can the above state be put
> > inside the diagnostic_context instead? (perhaps via a pointer to
> > a
> > wrapper class to avoid requiring all users of diagnostic.h to
> > include
> > hash-set.h?).
>
> It seems that using hash_set directly doesn't break any users.
Thanks. The updated patch looks good to me.
Dave
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057 --- Comment #11 from cqwrteur --- (In reply to Andrew Pinski from comment #10) > Please provide the full steps how you build the cross compilers? > Please provide the exact command where the problem shows up after building > the compiler? > > > Without that we cannot fix anything. > If you don't want to provide that then you will need to fix the problem > yourself since we cannot read your mind of what is going wrong. I have entire series of videos how to do Canadian compilation. https://youtu.be/pfE35Xm_kB8
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057 --- Comment #10 from Andrew Pinski --- Please provide the full steps how you build the cross compilers? Please provide the exact command where the problem shows up after building the compiler? Without that we cannot fix anything. If you don't want to provide that then you will need to fix the problem yourself since we cannot read your mind of what is going wrong.
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057 --- Comment #9 from Andrew Pinski --- There is --with-build-sysroot option explicitly for that case.
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057 --- Comment #8 from cqwrteur --- (In reply to Andrew Pinski from comment #6) > (In reply to cqwrteur from comment #5) > > There is a lot of reasons why sysroot should not be set. Like Canadian > > compilation. > > Huh? I do Canadian crosses with sysroot too. Just fix the build scripts to make it find the right path, is it very hard?
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057 --- Comment #7 from cqwrteur --- (In reply to Andrew Pinski from comment #6) > (In reply to cqwrteur from comment #5) > > There is a lot of reasons why sysroot should not be set. Like Canadian > > compilation. > > Huh? I do Canadian crosses with sysroot too. I do not want to set sysroot, please. Some people even told me sysroot would find weird path for x86_64-w64-mingw32 host
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057 --- Comment #6 from Andrew Pinski --- (In reply to cqwrteur from comment #5) > There is a lot of reasons why sysroot should not be set. Like Canadian > compilation. Huh? I do Canadian crosses with sysroot too.
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057 --- Comment #5 from cqwrteur --- (In reply to Andrew Pinski from comment #4) > There is also multi-arch too. > I build cross compilers all the time and they find libraries under the > sysroot : > /bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../libexec/gcc/aarch64- > marvell-linux-gnu/10.1.0/collect2 -plugin > /bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../libexec/gcc/aarch64- > marvell-linux-gnu/10.1.0/liblto_plugin.so > -plugin-opt=/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../libexec/ > gcc/aarch64-marvell-linux-gnu/10.1.0/lto-wrapper > -plugin-opt=-fresolution=/tmp/ccp36LLm.res -plugin-opt=-pass-through=-lgcc > -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc > -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s > --sysroot=/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64- > marvell-linux-gnu/sys-root --eh-frame-hdr -dynamic-linker > /lib/ld-linux-aarch64.so.1 -X -EL -maarch64linux > /bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell- > linux-gnu/sys-root/usr/lib/../lib64/crt1.o > /bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell- > linux-gnu/sys-root/usr/lib/../lib64/crti.o > /bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64- > marvell-linux-gnu/10.1.0/crtbegin.o > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64- > marvell-linux-gnu/10.1.0 > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64- > marvell-linux-gnu/10.1.0/../../../../aarch64-marvell-linux-gnu/lib/../lib64 > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell- > linux-gnu/sys-root/lib/../lib64 > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell- > linux-gnu/sys-root/usr/lib/../lib64 > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64- > marvell-linux-gnu/10.1.0/../../../../aarch64-marvell-linux-gnu/lib > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell- > linux-gnu/sys-root/lib > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell- > linux-gnu/sys-root/usr/lib /tmp/ccDOS00V.o -lgcc --push-state --as-needed > -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state > /bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64- > marvell-linux-gnu/10.1.0/crtend.o > /bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell- > linux-gnu/sys-root/usr/lib/../lib64/crtn.o > > > > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64- > marvell-linux-gnu/10.1.0 > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64- > marvell-linux-gnu/10.1.0/../../../../aarch64-marvell-linux-gnu/lib/../lib64 > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell- > linux-gnu/sys-root/lib/../lib64 > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell- > linux-gnu/sys-root/usr/lib/../lib64 > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64- > marvell-linux-gnu/10.1.0/../../../../aarch64-marvell-linux-gnu/lib > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell- > linux-gnu/sys-root/lib > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell- > linux-gnu/sys-root/usr/lib > > I configured with: > Configured with: /bajas/pinskia/src/toolchain-10/scripts/../src/configure > --disable-fixed-point --without-ppl --without-python --disable-werror > --enable-plugins > --with-lto-plugin-source=/bajas/pinskia/src/toolchain-10/scripts/../gits/gcc/ > lto-plugin --with-system-zlib --with-system-zstd --enable-initfini-array > --disable-source-highlight --with-sysroot > --with-local-prefix=/bajas/pinskia/src/toolchain-10/scripts/../marvell-tools/ > aarch64-marvell-linux-gnu/sys-root --disable-sim --enable-symvers=gnu > --enable-__cxa_atexit --enable-symvers=gnu --enable-__cxa_atexit > --disable-sim --with-multilib-list=lp64,ilp32 --enable-gnu-indirect-function > --target=aarch64-marvell-linux-gnu --enable-languages=c,c++,fortran,go > --prefix=/bajas/pinskia/src/toolchain-10/scripts/../marvell-tools > --with-pkgversion='Marvell Inc. Version: Marvell GCC10 build 1026.0-3b' > --with-bugurl=http://www.marvell.com/support/ > --with-libexpat-prefix=/bajas/pinskia/src/toolchain-10/scripts/../libs > > > I don't see a problem with the search for libs really. It searchs the > correct directories. I even tried with -mabi=ilp32 and I get: > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64- > marvell-linux-gnu/10.1.0/ilp32 > -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64- > marvell-linux-gnu/10.1.0/../../../../aarch64-marvell-linux-gnu/lib/../
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057 --- Comment #4 from Andrew Pinski --- There is also multi-arch too. I build cross compilers all the time and they find libraries under the sysroot : /bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../libexec/gcc/aarch64-marvell-linux-gnu/10.1.0/collect2 -plugin /bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../libexec/gcc/aarch64-marvell-linux-gnu/10.1.0/liblto_plugin.so -plugin-opt=/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../libexec/gcc/aarch64-marvell-linux-gnu/10.1.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccp36LLm.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell-linux-gnu/sys-root --eh-frame-hdr -dynamic-linker /lib/ld-linux-aarch64.so.1 -X -EL -maarch64linux /bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell-linux-gnu/sys-root/usr/lib/../lib64/crt1.o /bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell-linux-gnu/sys-root/usr/lib/../lib64/crti.o /bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64-marvell-linux-gnu/10.1.0/crtbegin.o -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64-marvell-linux-gnu/10.1.0 -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64-marvell-linux-gnu/10.1.0/../../../../aarch64-marvell-linux-gnu/lib/../lib64 -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell-linux-gnu/sys-root/lib/../lib64 -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell-linux-gnu/sys-root/usr/lib/../lib64 -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64-marvell-linux-gnu/10.1.0/../../../../aarch64-marvell-linux-gnu/lib -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell-linux-gnu/sys-root/lib -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell-linux-gnu/sys-root/usr/lib /tmp/ccDOS00V.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64-marvell-linux-gnu/10.1.0/crtend.o /bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell-linux-gnu/sys-root/usr/lib/../lib64/crtn.o -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64-marvell-linux-gnu/10.1.0 -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64-marvell-linux-gnu/10.1.0/../../../../aarch64-marvell-linux-gnu/lib/../lib64 -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell-linux-gnu/sys-root/lib/../lib64 -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell-linux-gnu/sys-root/usr/lib/../lib64 -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64-marvell-linux-gnu/10.1.0/../../../../aarch64-marvell-linux-gnu/lib -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell-linux-gnu/sys-root/lib -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell-linux-gnu/sys-root/usr/lib I configured with: Configured with: /bajas/pinskia/src/toolchain-10/scripts/../src/configure --disable-fixed-point --without-ppl --without-python --disable-werror --enable-plugins --with-lto-plugin-source=/bajas/pinskia/src/toolchain-10/scripts/../gits/gcc/lto-plugin --with-system-zlib --with-system-zstd --enable-initfini-array --disable-source-highlight --with-sysroot --with-local-prefix=/bajas/pinskia/src/toolchain-10/scripts/../marvell-tools/aarch64-marvell-linux-gnu/sys-root --disable-sim --enable-symvers=gnu --enable-__cxa_atexit --enable-symvers=gnu --enable-__cxa_atexit --disable-sim --with-multilib-list=lp64,ilp32 --enable-gnu-indirect-function --target=aarch64-marvell-linux-gnu --enable-languages=c,c++,fortran,go --prefix=/bajas/pinskia/src/toolchain-10/scripts/../marvell-tools --with-pkgversion='Marvell Inc. Version: Marvell GCC10 build 1026.0-3b' --with-bugurl=http://www.marvell.com/support/ --with-libexpat-prefix=/bajas/pinskia/src/toolchain-10/scripts/../libs I don't see a problem with the search for libs really. It searchs the correct directories. I even tried with -mabi=ilp32 and I get: -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64-marvell-linux-gnu/10.1.0/ilp32 -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../lib/gcc/aarch64-marvell-linux-gnu/10.1.0/../../../../aarch64-marvell-linux-gnu/lib/../libilp32 -L/bajas/pinskia/src/toolchain-10/3b/marvell-tools/bin/../aarch64-marvell-linux-gnu/sys-root/lib/../libilp32
[Bug c++/104055] Temporary with conteval constructor is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104055
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-01-17
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed simplified testcase:
extern "C" void exit(int);
extern "C" void abort(void);
struct A {
~A() { exit(0); }
consteval A() {}
};
int main() {
{
A{};
}
abort();
}
Here is a different testcase which shows the same problem too:
extern "C" void exit(int);
extern "C" void abort(void);
struct A {
~A() { exit(0); }
consteval A() {}
};
template
struct f
{
f(T){}
};
f t(A{});
int main() {
return 1;
}
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057
--- Comment #3 from cqwrteur ---
(In reply to Andrew Pinski from comment #1)
> Can you give an example?
> There are two different directories where multilib is there.
> One is based on the multilib name and the other is the OS multi-lib
> directory name.
>
> the one that matters to GCC depends on the context of the directory.
> For an example ${prefix}/lib and ${prefix}/lib64 are OS directory names.
> While things under ${prefix}/lib/gcc/${triplet}/${version}/ are the
> multi-lib path.
>
> Are you using --with-sysroot to use the normal OS directory structure?
Correct behavior should be the same.
When build GCC, GCC would find libs in
$HOME/cross/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/lib for all targets
$HOME/cross/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/lib64 for 64 bit
targets
$HOME/cross/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/libx32 for x32 bit
targets
However, after building gcc, GCC would find libs in
$HOME/cross/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/lib for all targets
$HOME/cross/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/lib64 for 64 bit
targets
$HOME/cross/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/libx32 for x32 bit
targets
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057
--- Comment #2 from cqwrteur ---
(In reply to Andrew Pinski from comment #1)
> Can you give an example?
> There are two different directories where multilib is there.
> One is based on the multilib name and the other is the OS multi-lib
> directory name.
>
> the one that matters to GCC depends on the context of the directory.
> For an example ${prefix}/lib and ${prefix}/lib64 are OS directory names.
> While things under ${prefix}/lib/gcc/${triplet}/${version}/ are the
> multi-lib path.
>
> Are you using --with-sysroot to use the normal OS directory structure?
Example 1: target=x86_64-ubuntu-linux-gnu
Let's assume prefix is $HOME/cross/x86_64-ubuntu-linux-gnu
When build GCC, GCC would find libs in
$HOME/cross/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/lib for all targets
$HOME/cross/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/lib/64 for 64 bit
target
$HOME/cross/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/lib/x32 for x32
target.
However, after building gcc, GCC would find libs in
$HOME/cross/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/lib for all targets
$HOME/cross/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/lib64 for 64 bit
targets
$HOME/cross/x86_64-ubuntu-linux-gnu/x86_64-ubuntu-linux-gnu/libx32 for x32 bit
targets
Example 2: target=x86_64-w64-mingw32
Let's assume prefix is $HOME/cross/x86_64-w64-mingw32
When build GCC, GCC would find libs in
$HOME/cross/x86_64-w64-mingw32/x86_64-w64-mingw32/lib for all targets
$HOME/cross/x86_64-w64-mingw32/x86_64-w64-mingw32/lib/32 for 32 bit target
However, after building gcc, GCC would find libs in
$HOME/cross/x86_64-w64-mingw32/x86_64-w64-mingw32/lib for all targets
$HOME/cross/x86_64-w64-mingw32/x86_64-w64-mingw32/lib32 for 32 bit targets
[committed] libstdc++: Update C++20 status table
libstdc++-v3/ChangeLog: * doc/xml/manual/status_cxx2020.xml: Update. * doc/html/manual/status.html: Regenerate. Pushed to trunk. commit a326934886f606b4a4a60254917f58c825d7c94b Author: Jonathan Wakely Date: Thu Jan 13 22:18:13 2022 libstdc++: Update C++20 status table libstdc++-v3/ChangeLog: * doc/xml/manual/status_cxx2020.xml: Update. * doc/html/manual/status.html: Regenerate. diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml index 26c882907f3..cebe36a8d5e 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml @@ -114,24 +114,22 @@ or any notes about the implementation. - Making std::string constexpr http://www.w3.org/1999/xlink; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0980r1.pdf;> P0980R1 - + 12 __cpp_lib_constexpr_string = 201907L - Making std::vector constexpr http://www.w3.org/1999/xlink; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1004r2.pdf;> P1004R2 - + 12 __cpp_lib_constexpr_vector = 201907L @@ -397,13 +395,12 @@ or any notes about the implementation. - Atomic shared_ptr http://www.w3.org/1999/xlink; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0718r2.html;> P0718R2 - + 12 __cpp_lib_atomic_shared_ptr = 201711L @@ -893,13 +890,12 @@ or any notes about the implementation. - Extending make_shared to Support Arrays http://www.w3.org/1999/xlink; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0674r1.html;> P0674R1 - + 12 __cpp_lib_shared_ptr_arrays = 201707L @@ -936,13 +932,12 @@ or any notes about the implementation. - Smart pointer creation with default initialization http://www.w3.org/1999/xlink; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1020r1.html;> P1020R1 - + 12 __cpp_lib_smart_ptr_for_overwrite = 201811L @@ -1079,13 +1074,12 @@ or any notes about the implementation. - Reviewing Deprecated Facilities of C++17 for C++20 http://www.w3.org/1999/xlink; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0619r4.html;> P0619R4 - + 12
Re: [PATCH] libstdc++: Implement C++20 atomic and atomic
On Fri, 14 Jan 2022 at 22:40, Jonathan Wakely wrote:
>
>
> On Sat, 18 Sept 2021 at 05:12, Thomas Rodgers
> wrote:
>
>> From: Thomas Rodgers
>>
>> Let's try this one instead.
>>
>> Signed-off-by: Thomas Rodgers
>>
>
> If you're doing DCO "Signed-off-by" commits you don't need FSF copyright
> notices in the new tests.
>
> I no longer put any copyright notices in the tests, because it's largely
> pointless. They're usually not interesting and don't do anything that
> anybody is going to want to steal to incorporate into non-GPL code. Your
> new 20_util/shared_ptr/atomic/atomic_shared_ptr.cc is non-trivial, and
> maybe interesting, but the two that just check feature test macros are not
> worth putting licence headers and copyright notices on.
>
>
>
>> libstdc++-v3/ChangeLog:
>> * acinclude.m4: Update ABI version.
>> * config/abi/pre/gnu.ver (GLIBCXX_3.4.21): Do not match new
>> _Sp_locker
>> constructor.
>> (GLIBCXX_3.4.30): Export _Sp_locker::_M_wait/_M_notify and new
>> constructor.
>> * include/bits/shared_ptr_atomic.h: define
>> __cpp_lib_atomic_shared_ptr
>> feature test macro.
>> (_Sp_locker::_Sp_locker(const void*, bool): New constructor.
>> (_Sp_locker::_M_wait()), _Sp_locker::_M_notify()): New methods.
>> (_Sp_impl): New type.
>> (atomic>): New partial template specialization.
>> (atomic>): New partial template specialization.
>> * include/std/version: define __cpp_lib_atomic_shared_ptr feature
>> test macro.
>> * doc/xml/manual/abi.xml: New ABI version.
>> * src/c++11/Makefile.am: Compile src/c++11/shared_ptr.cc
>> -std=gnu++20.
>> * src/c++11/Makefile.in: Regenerate.
>> * src/c++11/shared_ptr.cc (_Sp_locker::_Sp_locker(const void*,
>> bool),
>> _Sp_locker::_M_wait(), _Sp_locker::_M_notify(): Implement.
>> * testsuite/20_util/shared_ptr/atomic/4.cc: New test.
>> * testsuite/20_util/shared_ptr/atomic/5.cc: Likewise.
>> * testsuite/20_util/shared_ptr/atomic/atomic_shared_ptr.cc:
>> Likewise.
>> * testuite/util/testsuite_abi.cc: New ABI version.
>> ---
>> libstdc++-v3/acinclude.m4 | 2 +-
>> libstdc++-v3/config/abi/pre/gnu.ver | 12 +-
>> libstdc++-v3/configure| 2 +-
>> libstdc++-v3/doc/xml/manual/abi.xml | 1 +
>> libstdc++-v3/include/bits/shared_ptr_atomic.h | 309 ++
>> libstdc++-v3/include/std/version | 1 +
>> libstdc++-v3/src/c++11/Makefile.am| 6 +
>> libstdc++-v3/src/c++11/Makefile.in| 6 +
>> libstdc++-v3/src/c++11/shared_ptr.cc | 86 -
>> .../testsuite/20_util/shared_ptr/atomic/4.cc | 28 ++
>> .../testsuite/20_util/shared_ptr/atomic/5.cc | 28 ++
>> .../shared_ptr/atomic/atomic_shared_ptr.cc| 159 +
>> libstdc++-v3/testsuite/util/testsuite_abi.cc | 3 +-
>> 13 files changed, 637 insertions(+), 6 deletions(-)
>> create mode 100644 libstdc++-v3/testsuite/20_util/shared_ptr/atomic/4.cc
>> create mode 100644 libstdc++-v3/testsuite/20_util/shared_ptr/atomic/5.cc
>> create mode 100644
>> libstdc++-v3/testsuite/20_util/shared_ptr/atomic/atomic_shared_ptr.cc
>>
>>
> [...]
>
>
>> + void
>> + store(value_type __r, memory_order __o = memory_order_seq_cst)
>> noexcept
>> + { _M_impl._M_store(move(__r), __o); }
>>
>
> Every move(x) needs to be qualified as std::move(x) to avoid ADL.
>
>
>
>>
>> +
>> +// { dg-options "-std=gnu++2a" }
>> +// { dg-do run { target c++2a } }
>>
>
> gnu++20 and c++20 has been OK for a while, there's no need to use the 2a
> forms.
>
> Other than that, the patch looks OK, but I have a modified version based
> on your patch just using atomic ops, no mutexes, which I'll post shortly.
>
Here's the finished version of that patch, which is all inline in the
header, and performs faster too.
Tested powerpc64le-linux and x86_64-linux.
Pushed to trunk.
commit 2ac0649d7bf3eacbf92add1ec2b54045c401a4c2
Author: Jonathan Wakely
Date: Sun Jan 16 20:47:09 2022
libstdc++: Implement C++20 atomic and atomic
This adds another piece of C++20, the std::atomic specializations for
std::shared_ptr and std::weak_ptr.
The new _Sp_atomic type mimics the structure of shared_ptr and
weak_ptr, holding a T* pointer (the one returned by get() on a
shared_ptr/weak ptr) and a _Sp_counted_base<>* pointer to the
ref-counted control block. For _Sp_atomic the low bit of the control
block pointer is used as a lock bit, to ensure only one thread will
access the object at a time. The pointer is actually stored as a
uintptr_t to avoid accidental dereferences of the pointer when unlocked
(which would be a race) or when locked (which would dereference the
wrong pointer value due to the low bit being set). To get a raw pointer
to the control block, the lock must be acquired.
Re: GSoC: Working on the static analyzer
On Fri, 2022-01-14 at 22:15 +0530, Mir Immad wrote: > HI David, > I've been tinkering with the static analyzer for the last few days. I > find > the project of adding SARIF output to the analyzer intresting. I'm > writing > this to let you know that I'm trying to learn the codebase. > Thank you. Excellent. BTW, I think adding SARIF output would involve working more with GCC's diagnostics subsystem than with the static analyzer, since (in theory) all of the static analyzer's output is passing through the diagnostics subsystem - though the static analyzer is probably the only GCC component generating diagnostic paths. I'm happy to mentor such a project as I maintain both subsystems and SARIF output would benefit both - but it would be rather tangential to the analyzer - so if you had specifically wanted to be working on the guts of the analyzer itself, you may want to pick a different subproject. The SARIF standard is rather long and complicated, and we would want to be compatible with clang's implementation. It would be very cool if gcc could also accept SARIF files as an *input* format, and emit them as diagnostics; that might help with debugging SARIF output. (I have a old patch for adding JSON parsing support to GCC that could be used as a starting point for this). Hope the above makes sense Dave > > On Tue, Jan 11, 2022, 7:09 PM David Malcolm > wrote: > > > On Tue, 2022-01-11 at 11:03 +0530, Mir Immad via Gcc wrote: > > > Hi everyone, > > > > Hi, and welcome. > > > > > I intend to work on the static analyzer. Are these documents > > > enough to > > > get > > > started: https://gcc.gnu.org/onlinedocs/gccint and > > > > > https://gcc.gnu.org/onlinedocs/gccint/Analyzer-Internals.html#Analyzer-Internals > > > > Yes. > > > > There are also some high-level notes here: > > https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer > > > > Also, given that the analyzer is part of GCC, the more general > > introductions to hacking on GCC will be useful. > > > > I recommend creating a trivial C source file with a bug in it (e.g. > > a > > 3-line function with a use-after-free), and stepping through the > > analyzer to get a sense of how it works. > > > > Hope this is helpful; don't hesitate to ask questions. > > Dave > > > >
Re: [PATCH 11/11] libstdc++: Fix ODR issues with different -m flags
On Fri, 14 Jan 2022 at 21:30, Jonathan Wakely wrote: > > > On Mon, 15 Nov 2021 at 08:57, Matthias Kretz wrote: > >> ping. OK to push? >> > > Sorry for the delay - this is OK for trunk. > I see a new failure on powerpc64le-linux (gcc112 in the cfarm) after this commit: FAIL: experimental/simd/standard_abi_usable_2.cc -maltivec -mpower8-vector -O2 -Wno-psabi (test for excess errors)
[Bug go/77780] Go front-end ignores NO_DOLLAR_IN_LABEL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77780 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Ian Lance Taylor --- This was fixed a while back for the GCC 8 release.
Re: Accessing const parameter of GIMPLE_CALL
On Sun, 2022-01-16 at 18:52 +0530, Shubham Narlawar via Gcc wrote:
> Hello,
Hi; various notes inline below...
>
> My aim is to iterate over gimple call stmt parameters and check
> whether it is constant or constant expression and mark/store them for
> some gimple transformation.
>
> I have an intrinsic function call of the following -
>
> __builtin_xyz(void*, 7, addr + 10);
>
> I want to find its parameters which are either constant or constant
> expression i.e. 7 and addr + 10 from above case.
Gimple "flattens" all tree-like operations into a sequence of simple
operations, so I would expect the gimple for this to look something
like this:
_tmp = addr + 10;
__builtin_xyx (7, _tmp);
Your email doesn't specify *when* your code runs.
The IR for a function goes through several stages:
- an initial gimple IR without a CFG
- gimple with a CFG, but not in SSA
- gimple-SSA with a CFG
(most of the gimple optimization passes operate in this form of the
IR)
- gimple with a CFG, but no longer in CFG form, immediately before
conversion to RTL-with-CFG form
- RTL-with-CFG
- RTL-without a CFG
- assembler
Are you doing it as part of a plugin, or modifying an existing pass?
In either case, it's a good idea to dump the gimple and see what the
code has been turned into. You'll probably find the following options
useful:
-fdump-tree-all -fdump-gimple-all
or alternatively just turn it on for the pass that you're working on.
>
> [1] I tried below macro but there is very less usage in the entire
> source code -
>
> tree fn_ptr = gimple_call_fn (dyn_cast (stmt)); //stmt
gimple_call_fn returns the function that will be called, a pointer.
This is very general, for handling things like jumps through function
pointers, but here you have the common case of a callsite that calls a
specific function, so "fn_ptr" here is:
&__builtin_xyx
i.e. an ADDR_EXPR where operand 0 is the FUNCTION_DECL for the builtin.
> = gimple_call
> function_args_iterator iter;
> tree argtype;
>
> if (TREE_CODE (fn_ptr) == ADDR_EXPR)
> {
> FOREACH_FUNCTION_ARGS (fn_ptr, argtype, iter)
Looking in tree.h, FOREACH_FUNCTION_ARGS takes a FUNCTION_TYPE as its
first argument, but the code above is passing it the ADDR_EXPR wrapping
the FUNCTION_DECL.
Unfortunately, because these things are all of type "tree", this kind
of type mismatch doesn't get caught - unless you build gcc from source
(with --enable-checking=debug) in which case all these accesses are
checked at the compiler's run time (which is probably a good thing to
do if you're hoping to work on gcc for GSoC).
You can get the FUNCTION_TYPE of a FUNCTION_DECL via TREE_TYPE
(fndecl), or alternatively, gimple_call_fntype (call) will get the type
of the function expected at the call stmt (useful if there was a type
mismatch).
That said, FOREACH_FUNCTION_ARGS iterates through the types of the
params of the FUNCTION_TYPE, but it sounds like you want to be
iterating through the arguments at this particular *callsite*.
For that you can use
gimple_call_num_args (call);
and
gimple_call_arg (call, idx);
> {
> if (TREE_CONSTANT (argtype))
> // Found a constant expression parameter
> }
> }
>
> The problem is I am getting only one parameter tree but there are 2
> constants in the above function call. Even if "addr + 10" is treated
> differently, I want to mark it for the transformation.
I think you're seeing the function pointer being called, ather than the
params.
>
> a. Is the above correct method to iterate over function call
> parameters?
As noted above, it depends on whether you want to iterate over the
types of the parameters in the function's decl, or over the expressions
of the arguments at the callsite. I believe the above explains how to
do each of these.
> b. Is there a different way to achieve the above goal?
If you're looking to get familiar with GCC's insides, I recommend
stepping through it in the debugger, rather than relying on injecting
print statements and recompiling, since the former makes it much easier
to spot mistakes like the one above (which we all make).
I've written a guide to debugging GCC here:
https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html
Hope this is helpful
Dave
[Bug bootstrap/104057] cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-01-16
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
--- Comment #1 from Andrew Pinski ---
Can you give an example?
There are two different directories where multilib is there.
One is based on the multilib name and the other is the OS multi-lib directory
name.
the one that matters to GCC depends on the context of the directory.
For an example ${prefix}/lib and ${prefix}/lib64 are OS directory names.
While things under ${prefix}/lib/gcc/${triplet}/${version}/ are the multi-lib
path.
Are you using --with-sysroot to use the normal OS directory structure?
[Bug sanitizer/99476] 'PATH_MAX' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99476 --- Comment #1 from cqwrteur --- ../../../../../../../gcc/libsanitizer/asan/asan_linux.cpp: In function 'void __asan::AsanCheckIncompatibleRT()': ../../../../../../../gcc/libsanitizer/asan/asan_linux.cpp:200:21: error: 'PATH_MAX' was not declared in this scope 200 | char filename[PATH_MAX]; | ^~~~ ../../../../../../../gcc/libsanitizer/asan/asan_linux.cpp:201:35: error: 'filename' was not declared in this scope; did you mean 'rename'? 201 | MemoryMappedSegment segment(filename, sizeof(filename)); | ^~~~ | rename The bug is still in the source
[Bug bootstrap/104057] New: cross compiler multilibs libs path too chaos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104057 Bug ID: 104057 Summary: cross compiler multilibs libs path too chaos Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- When build a cross compiler for gcc with multilib support, it does not correctly find libs in the lib, lib32, libx32, lib64 etc, rather, it finds libs in the lib/64 lib/x32 and lib which is ridiculous. lib32, libx32, lib64 are completely ignored by the GCC build scripts.
[Bug c++/104052] Modules ICE on powerpc64le-linux with -mabi=ieeelongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104052 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-01-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #5 from Andrew Pinski --- Seems like when register_builtin_type is called, there should be another vector holding those types and handling those in module.cc too. That would fix this and the vector type issues I think.
[PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc
This patch is the third in my “signaling NaN” series. For targets with IEEE support but without the issignaling macro in libc (i.e., everywhere except glibc), this allows us to provide a fallback implementation. In order to keep the code in ieee_helper.c relatively readable, I’ve put that new implementation in a separate file, issignaling_fallback.h. The logic is borrowed from different routines in glibc, but gathered into a single file and much simpler than the glibc implementation, because we do not need to cover all the cases they have (comments with details are available in issignaling_fallback.h). I can’t test this on all the targets I’d like to, obviously. But it was tested on x86_64-pc-linux-gnu (where it doesn’t do anything), on x86_64-pc-linux-gnu by mimicking the lack of a issignaling macro, and on x86_64-apple-darwin (which does not have issignaling). OK to push? issignaling.diff Description: Binary data
Re: [PATCH] Fortran: make IEEE_VALUE produce signaling NaNs
Hi Mikael, team, > Thanks. Pushed: > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=90045c5df5b3c8853e7740fb72a11aead1c489bb Pushed a further commit to XFAIL the testcases on x87: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=86e3b476d5defaa79c94d40b76cbeec21cd02e5f There the ABI does not allow us to meaningfully pass signaling NaNs in float and double types, sadly. FX
[Bug c++/104052] Modules ICE on powerpc64le-linux with -mabi=ieeelongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104052 --- Comment #4 from Andrew Pinski --- There are other types it messes up with too. E.g. the opaque types (PR 98688). I noticed vector types are not handled correctly either. It assumes all vector types of the same size are the same which is definitely not true for aarch64.
[Bug c++/104052] Modules ICE on powerpc64le-linux with -mabi=ieeelongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104052 --- Comment #3 from Jakub Jelinek --- config/aarch64/aarch64-builtins.c: aarch64_fp16_type_node = make_node (REAL_TYPE); config/aarch64/aarch64-builtins.c: aarch64_bf16_type_node = make_node (REAL_TYPE); config/arm/arm-builtins.c: arm_bf16_type_node = make_node (REAL_TYPE); config/arm/arm-builtins.c: arm_fp16_type_node = make_node (REAL_TYPE); config/csky/csky.c: static tree csky_floatHF_type_node = make_node (REAL_TYPE); config/i386/i386-builtins.c: ix86_float16_type_node = make_node (REAL_TYPE); config/i386/i386-builtins.c: float80_type_node = make_node (REAL_TYPE); config/ia64/ia64.c: fpreg_type = make_node (REAL_TYPE); config/ia64/ia64.c: float80_type = make_node (REAL_TYPE); config/rs6000/rs6000-call.c: ibm128_float_type_node = make_node (REAL_TYPE); is all I could find, now the question is what from these types are already in some global_trees. But the upper bound for target specific floating point types will be most likely either 2 or 1.
[Bug c++/104031] [12 regression] Global nested constructors generate invalid code since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104031 --- Comment #10 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #8) > That last testcase isn't very good for the testsuite, because 0 is pretty > common value on the stack, so even without the store the chances that it > will be already zero are high. Yes I didn't think of that while reducing it further. But that explains why it would pass at -O0 really :)
[Bug c++/104052] Modules ICE on powerpc64le-linux with -mabi=ieeelongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104052
--- Comment #2 from Jakub Jelinek ---
I bet we don't reach this because modules.cc has:
/* Global trees. */
static const std::pair global_tree_arys[] =
{
std::pair (sizetype_tab, stk_type_kind_last),
std::pair (integer_types, itk_none),
std::pair (global_trees, TI_MODULE_HWM),
std::pair (c_global_trees, CTI_MODULE_HWM),
std::pair (cp_global_trees, CPTI_MODULE_HWM),
std::pair (NULL, 0)
};
and special cases those somehow. So e.g. long_double_type_node and others
#define float_type_node global_trees[TI_FLOAT_TYPE]
#define double_type_nodeglobal_trees[TI_DOUBLE_TYPE]
#define long_double_type_node global_trees[TI_LONG_DOUBLE_TYPE]
or
#define float128_type_node global_trees[TI_FLOAT128_TYPE]
all go through that. But modules.cc doesn't know about types the backend
creates
like __ibm128. __int24 etc. is probably ok due to integer_types
containing
itk_intN_0,
itk_unsigned_intN_0,
itk_intN_1,
itk_unsigned_intN_1,
itk_intN_2,
itk_unsigned_intN_2,
itk_intN_3,
itk_unsigned_intN_3,
So, one way through this would be to reserve one or more global_trees for the
extra backend floating point types.
[Bug c++/104052] Modules ICE on powerpc64le-linux with -mabi=ieeelongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104052 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- ibm128_float_type_node = make_node (REAL_TYPE); TYPE_PRECISION (ibm128_float_type_node) = 128; SET_TYPE_MODE (ibm128_float_type_node, IFmode); layout_type (ibm128_float_type_node); long_double_type_node = make_node (REAL_TYPE); TYPE_PRECISION (long_double_type_node) = LONG_DOUBLE_TYPE_SIZE; layout_type (long_double_type_node); I don't see any difference there either. I don't see any reference to long_double_type_node in module.cc either. Nor TYPE_MODE.
gcc-12-20220116 is now available
Snapshot gcc-12-20220116 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20220116/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 90045c5df5b3c8853e7740fb72a11aead1c489bb You'll find: gcc-12-20220116.tar.xz Complete GCC SHA256=a5053a81a814496c95f3a5e3ae4a6c2d3164bd7ddc832e694f64f6267bae98aa SHA1=c4866e76b2b6243751fb186e20c33d95aae12e02 Diffs from 12-20220109 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [pushed 3/3] testsuite: Enrich tests with variants failing on the branch.
Hi Mikael, Backporting the fix for pr103789 on the 11 branch revealed a lack of test coverage for the tests provided with that fix. Indeed, the tests use the KIND argument of the respective intrinsics only with keyword arguments. This adds variants with non-keyword arguments. The tests enriched this way fail on the branch if the fix is cherry-picked straightforwardly. The fix will have to be tweaked slightly there. As a general principle, we should not add or amend test cases unless it is wrong code that we need to remove The reason is that changing a test case makes regression testing, especially the automated version, harder - if a test starts failing, is it due to a change in the test case or a change in the compiler or library? I don't think there is a need to revert this patch, but please add separate test cases if you have new things to test in the future. Best regards Thomas
Re: [PATCH] Fortran: make IEEE_VALUE produce signaling NaNs
Thanks Mikael, > This looks good to me. Thanks. Thanks. Pushed: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=90045c5df5b3c8853e7740fb72a11aead1c489bb FX
Hilfsfonds – 5 Millionen €
- This e-mail is subjected to the disclaimer that can be viewed at: * http://www.cut.ac.za/www/disclaimer/email_disclaimer -
[pushed 3/3] testsuite: Enrich tests with variants failing on the branch.
Backporting the fix for pr103789 on the 11 branch revealed a lack of test coverage for the tests provided with that fix. Indeed, the tests use the KIND argument of the respective intrinsics only with keyword arguments. This adds variants with non-keyword arguments. The tests enriched this way fail on the branch if the fix is cherry-picked straightforwardly. The fix will have to be tweaked slightly there. PR fortran/103789 PR fortran/87711 PR fortran/97896 gcc/testsuite/ChangeLog: * gfortran.dg/maskl_1.f90: Enrich test with usages of MASKL with a non-keyword KIND argument. * gfortran.dg/maskr_1.f90: Same for MASKR. * gfortran.dg/scan_3.f90: Same for SCAN. * gfortran.dg/verify_3.f90: Same for VERIFY. (cherry picked from commit 15630e6e9eb019477d1fc5c0966b43979e18ae18) --- gcc/testsuite/gfortran.dg/maskl_1.f90 | 3 ++- gcc/testsuite/gfortran.dg/maskr_1.f90 | 3 ++- gcc/testsuite/gfortran.dg/scan_3.f90 | 5 - gcc/testsuite/gfortran.dg/verify_3.f90 | 5 - 4 files changed, 12 insertions(+), 4 deletions(-) diff --git a/gcc/testsuite/gfortran.dg/maskl_1.f90 b/gcc/testsuite/gfortran.dg/maskl_1.f90 index 9e25c2c9cdc..56350e269da 100644 --- a/gcc/testsuite/gfortran.dg/maskl_1.f90 +++ b/gcc/testsuite/gfortran.dg/maskl_1.f90 @@ -4,7 +4,8 @@ ! Check the absence of ICE when generating calls to MASKL with a KIND argument. program p - integer :: z(2), y(2) + integer :: z(2), y(2), x(2) y = [1, 13] z = maskl(y, kind=4) + 1 + x = maskl(y, 4) + 1 end program p diff --git a/gcc/testsuite/gfortran.dg/maskr_1.f90 b/gcc/testsuite/gfortran.dg/maskr_1.f90 index ebfd3dbba33..f8ccdd11ab3 100644 --- a/gcc/testsuite/gfortran.dg/maskr_1.f90 +++ b/gcc/testsuite/gfortran.dg/maskr_1.f90 @@ -4,7 +4,8 @@ ! Check the absence of ICE when generating calls to MASKR with a KIND argument. program p - integer :: z(2), y(2) + integer :: z(2), y(2), x(2) y = [1, 13] z = maskr(y, kind=4) + 1 + x = maskr(y, 4) + 1 end program p diff --git a/gcc/testsuite/gfortran.dg/scan_3.f90 b/gcc/testsuite/gfortran.dg/scan_3.f90 index 80262ae2167..2a9ed080957 100644 --- a/gcc/testsuite/gfortran.dg/scan_3.f90 +++ b/gcc/testsuite/gfortran.dg/scan_3.f90 @@ -5,7 +5,10 @@ program p character(len=10) :: y(2) - integer :: z(2) + integer :: z(2), x(2), w(2), v(2) y = ['abc', 'def'] z = scan(y, 'e', kind=4) + 1 + x = scan(y, 'e', back=.false., kind=4) + 1 + w = scan(y, 'e', .false., kind=4) + 1 + v = scan(y, 'e', .false., 4) + 1 end program p diff --git a/gcc/testsuite/gfortran.dg/verify_3.f90 b/gcc/testsuite/gfortran.dg/verify_3.f90 index f01e24e199e..c8b26b70614 100644 --- a/gcc/testsuite/gfortran.dg/verify_3.f90 +++ b/gcc/testsuite/gfortran.dg/verify_3.f90 @@ -5,7 +5,10 @@ program p character(len=10) :: y(2) - integer :: z(2) + integer :: z(2), x(2), w(2), v(2) y = ['abc', 'def'] z = verify(y, 'e', kind=4) + 1 + x = verify(y, 'e', back=.false., kind=4) + 1 + w = verify(y, 'e', .false., kind=4) + 1 + x = verify(y, 'e', .false., 4) + 1 end program p
[pushed 2/3] Fortran: Ignore KIND argument of a few more intrinsics. [PR103789]
After PR97896 for which some code was added to ignore the KIND argument
of the INDEX intrinsics, and PR87711 for which that was extended to LEN_TRIM
as well, this propagates it further to MASKL, MASKR, SCAN and VERIFY.
PR fortran/103789
gcc/fortran/ChangeLog:
* trans-array.c (arg_evaluated_for_scalarization): Add MASKL, MASKR,
SCAN and VERIFY to the list of intrinsics whose KIND argument is to be
ignored.
gcc/testsuite/ChangeLog:
* gfortran.dg/maskl_1.f90: New test.
* gfortran.dg/maskr_1.f90: New test.
* gfortran.dg/scan_3.f90: New test.
* gfortran.dg/verify_3.f90: New test.
(cherry picked from commit c1c17a43e172ebc28f2cd247f6e83c5fdbc6219f)
---
gcc/fortran/trans-array.c | 4
gcc/testsuite/gfortran.dg/maskl_1.f90 | 10 ++
gcc/testsuite/gfortran.dg/maskr_1.f90 | 10 ++
gcc/testsuite/gfortran.dg/scan_3.f90 | 11 +++
gcc/testsuite/gfortran.dg/verify_3.f90 | 11 +++
5 files changed, 46 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/maskl_1.f90
create mode 100644 gcc/testsuite/gfortran.dg/maskr_1.f90
create mode 100644 gcc/testsuite/gfortran.dg/scan_3.f90
create mode 100644 gcc/testsuite/gfortran.dg/verify_3.f90
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index e187a08f8f0..308213c57e3 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -11225,11 +11225,15 @@ arg_evaluated_for_scalarization (gfc_intrinsic_sym *function,
switch (function->id)
{
case GFC_ISYM_INDEX:
+ case GFC_ISYM_SCAN:
+ case GFC_ISYM_VERIFY:
if (arg_num == 3)
return false;
break;
case GFC_ISYM_LEN_TRIM:
+ case GFC_ISYM_MASKL:
+ case GFC_ISYM_MASKR:
if (arg_num == 1)
return false;
diff --git a/gcc/testsuite/gfortran.dg/maskl_1.f90 b/gcc/testsuite/gfortran.dg/maskl_1.f90
new file mode 100644
index 000..9e25c2c9cdc
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/maskl_1.f90
@@ -0,0 +1,10 @@
+! { dg-do compile }
+!
+! PR fortran/103789
+! Check the absence of ICE when generating calls to MASKL with a KIND argument.
+
+program p
+ integer :: z(2), y(2)
+ y = [1, 13]
+ z = maskl(y, kind=4) + 1
+end program p
diff --git a/gcc/testsuite/gfortran.dg/maskr_1.f90 b/gcc/testsuite/gfortran.dg/maskr_1.f90
new file mode 100644
index 000..ebfd3dbba33
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/maskr_1.f90
@@ -0,0 +1,10 @@
+! { dg-do compile }
+!
+! PR fortran/103789
+! Check the absence of ICE when generating calls to MASKR with a KIND argument.
+
+program p
+ integer :: z(2), y(2)
+ y = [1, 13]
+ z = maskr(y, kind=4) + 1
+end program p
diff --git a/gcc/testsuite/gfortran.dg/scan_3.f90 b/gcc/testsuite/gfortran.dg/scan_3.f90
new file mode 100644
index 000..80262ae2167
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/scan_3.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+!
+! PR fortran/103789
+! Check the absence of ICE when generating calls to SCAN with a KIND argument.
+
+program p
+ character(len=10) :: y(2)
+ integer :: z(2)
+ y = ['abc', 'def']
+ z = scan(y, 'e', kind=4) + 1
+end program p
diff --git a/gcc/testsuite/gfortran.dg/verify_3.f90 b/gcc/testsuite/gfortran.dg/verify_3.f90
new file mode 100644
index 000..f01e24e199e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/verify_3.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+!
+! PR fortran/103789
+! Check the absence of ICE when generating calls to VERIFY with a KIND argument.
+
+program p
+ character(len=10) :: y(2)
+ integer :: z(2)
+ y = ['abc', 'def']
+ z = verify(y, 'e', kind=4) + 1
+end program p
[pushed 1/3] Fortran: Fix KIND argument index for LEN_TRIM.
The mainline code to check whether an argument has to be included in
scalarization uses only the name of a dummy argument object to recognize a
specific argument of an intrinsic procedure. On the 11 branch, the dummy
argument object is not available and the code uses a mix of check for
argument name (for keyword arguments) and argument index (for non-keyword ones).
This makes backports non-straightforward in this area, as the argument indexes
depend on the intrinsics.
This change fixes a bogus backport for LEN_TRIM, whose KIND argument index
should be different from that of INDEX.
PR fortran/87711
PR fortran/97896
gcc/fortran/ChangeLog:
* trans-array.c (arg_evaluated_for_scalarization): Handle keyword and
non-keyword arguments separatedly. Adapt the expected argument index
for KIND to each intrinsic in the non-keyword case.
gcc/testsuite/ChangeLog:
* gfortran.dg/index_5.f90: Enrich test with usages of INDEX with
a non-keyword KIND argument.
* gfortran.dg/len_trim.f90: Same for LEN_TRIM.
(tests cherry picked from commit 15630e6e9eb019477d1fc5c0966b43979e18ae18)
---
gcc/fortran/trans-array.c | 41 +++---
gcc/testsuite/gfortran.dg/index_5.f90 | 2 ++
gcc/testsuite/gfortran.dg/len_trim.f90 | 6
3 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index db14daca459..e187a08f8f0 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -11220,18 +11220,39 @@ arg_evaluated_for_scalarization (gfc_intrinsic_sym *function,
{
if (function != NULL)
{
- switch (function->id)
+ if (actual_arg.name == NULL)
{
- case GFC_ISYM_INDEX:
- case GFC_ISYM_LEN_TRIM:
- if ((actual_arg.name == NULL && arg_num == 3)
- || (actual_arg.name != NULL
- && strcmp ("kind", actual_arg.name) == 0))
- return false;
- /* Fallthrough. */
+ switch (function->id)
+ {
+ case GFC_ISYM_INDEX:
+ if (arg_num == 3)
+ return false;
+ break;
- default:
- break;
+ case GFC_ISYM_LEN_TRIM:
+ if (arg_num == 1)
+ return false;
+
+ /* Fallthrough. */
+
+ default:
+ break;
+ }
+ }
+ else
+ {
+ switch (function->id)
+ {
+ case GFC_ISYM_INDEX:
+ case GFC_ISYM_LEN_TRIM:
+ if (strcmp ("kind", actual_arg.name) == 0)
+ return false;
+
+ /* Fallthrough. */
+
+ default:
+ break;
+ }
}
}
diff --git a/gcc/testsuite/gfortran.dg/index_5.f90 b/gcc/testsuite/gfortran.dg/index_5.f90
index e039455d175..4dc2ce4c0a1 100644
--- a/gcc/testsuite/gfortran.dg/index_5.f90
+++ b/gcc/testsuite/gfortran.dg/index_5.f90
@@ -19,5 +19,7 @@ program p
d = index ('xyxyz','yx', back=a, kind=8)
b = index ('xyxyz','yx', back=a, kind=8)
d = index ('xyxyz','yx', back=a, kind=4)
+ b = index ('xyxyz','yx', a, 4)
+ d = index ('xyxyz','yx', a, 8)
end
diff --git a/gcc/testsuite/gfortran.dg/len_trim.f90 b/gcc/testsuite/gfortran.dg/len_trim.f90
index 2252b81f084..77e3d30c669 100644
--- a/gcc/testsuite/gfortran.dg/len_trim.f90
+++ b/gcc/testsuite/gfortran.dg/len_trim.f90
@@ -17,11 +17,17 @@ program main
kk = len_trim (a)
mm = len_trim (a, kind=4)
nn = len_trim (a, kind=8)
+ mm = len_trim (a, 4)
+ nn = len_trim (a, 8)
kk = len_trim ([b])
mm = len_trim ([b],kind=4)
nn = len_trim ([b],kind=8)
+ mm = len_trim ([b], 4)
+ nn = len_trim ([b], 8)
kk = len_trim (c)
mm = len_trim (c, kind=4)
nn = len_trim (c, kind=8)
+ mm = len_trim (c, 4)
+ nn = len_trim (c, 8)
if (any (l4 /= 2_4) .or. any (l8 /= 2_8)) stop 1
end program main
[pushed 0/3][gcc11] fortran: Backpoprt KIND arg of intrinsics fix [PR103789]
Hello, I noticed a bug while backporting the fix for PR103789 on the 11 branch. It makes the cherry-pick not exactly straightforward. The bug is fixed in the first patch, the backport comes in the second, and additional test coverage (pushed earlier today on master) is added in the third. Tested on x86_64-linux on the 11 branch, pushed. Mikael Morin (3): Fortran: Fix KIND argument index for LEN_TRIM. Fortran: Ignore KIND argument of a few more intrinsics. [PR103789] testsuite: Enrich tests with variants failing on the branch. gcc/fortran/trans-array.c | 45 -- gcc/testsuite/gfortran.dg/index_5.f90 | 2 ++ gcc/testsuite/gfortran.dg/len_trim.f90 | 6 gcc/testsuite/gfortran.dg/maskl_1.f90 | 11 +++ gcc/testsuite/gfortran.dg/maskr_1.f90 | 11 +++ gcc/testsuite/gfortran.dg/scan_3.f90 | 14 gcc/testsuite/gfortran.dg/verify_3.f90 | 14 7 files changed, 93 insertions(+), 10 deletions(-) create mode 100644 gcc/testsuite/gfortran.dg/maskl_1.f90 create mode 100644 gcc/testsuite/gfortran.dg/maskr_1.f90 create mode 100644 gcc/testsuite/gfortran.dg/scan_3.f90 create mode 100644 gcc/testsuite/gfortran.dg/verify_3.f90 -- 2.34.1
[Bug libstdc++/104056] --disable-hosted-libstdcxx does not work for x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104056 --- Comment #2 from cqwrteur --- skipping link test. i got features.h no such file /home/cqwrteur/myhome/gcc_build/native/x86_64-ubuntu-linux-gnu/gcc/x86_64-ubuntu-linux-gnu/libstdc++-v3/include/x86_64-ubuntu-linux-gnu/bits/os_defines.h:39:10: fatal error: features.h: No such file or directory 39 | #include | ^~~~ In file included from /home/cqwrteur/myhome/gcc_build/native/x86_64-ubuntu-linux-gnu/gcc/x86_64-ubuntu-linux-gnu/libstdc++-v3/include/x86_64-ubuntu-linux-gnu/bits/c++config.h:649, from /home/cqwrteur/myhome/gcc/libstdc++-v3/libsupc++/cxxabi.h:49, from ../../../../../../../gcc/libstdc++-v3/libsupc++/atexit_arm.cc:24: /home/cqwrteur/myhome/gcc_build/native/x86_64-ubuntu-linux-gnu/gcc/x86_64-ubuntu-linux-gnu/libstdc++-v3/include/x86_64-ubuntu-linux-gnu/bits/os_defines.h:39:10: fatal error: features.h: No such file or directory 39 | #include | ^~~~ In file included from /home/cqwrteur/myhome/gcc_build/native/x86_64-ubuntu-linux-gnu/gcc/x86_64-ubuntu-linux-gnu/libstdc++-v3/include/x86_64-ubuntu-linux-gnu/bits/c++config.h:649, from ../../../../../../../gcc/libstdc++-v3/libsupc++/new:40, from ../../../../../../../gcc/libstdc++-v3/libsupc++/bad_alloc.cc:26: /home/cqwrteur/myhome/gcc_build/native/x86_64-ubuntu-linux-gnu/gcc/x86_64-ubuntu-linux-gnu/libstdc++-v3/include/x86_64-ubuntu-linux-gnu/bits/os_defines.h:39:10: fatal error: features.h: No such file or directory 39 | #include | ^~~~ compilation terminated. compilation terminated. compilation terminated.
[Bug fortran/97896] [11/12 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896 --- Comment #17 from CVS Commits --- The releases/gcc-11 branch has been updated by Mikael Morin : https://gcc.gnu.org/g:024fd4fb5a1ba742242eec84149f159518444ae3 commit r11-9469-g024fd4fb5a1ba742242eec84149f159518444ae3 Author: Mikael Morin Date: Sun Jan 16 18:33:36 2022 +0100 testsuite: Enrich tests with variants failing on the branch. Backporting the fix for pr103789 on the 11 branch revealed a lack of test coverage for the tests provided with that fix. Indeed, the tests use the KIND argument of the respective intrinsics only with keyword arguments. This adds variants with non-keyword arguments. The tests enriched this way fail on the branch if the fix is cherry-picked straightforwardly. The fix will have to be tweaked slightly there. PR fortran/103789 PR fortran/87711 PR fortran/97896 gcc/testsuite/ChangeLog: * gfortran.dg/maskl_1.f90: Enrich test with usages of MASKL with a non-keyword KIND argument. * gfortran.dg/maskr_1.f90: Same for MASKR. * gfortran.dg/scan_3.f90: Same for SCAN. * gfortran.dg/verify_3.f90: Same for VERIFY. (cherry picked from commit 15630e6e9eb019477d1fc5c0966b43979e18ae18)
[Bug fortran/103789] ICE when providing kind argument to mask{l,r}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103789 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Mikael Morin : https://gcc.gnu.org/g:024fd4fb5a1ba742242eec84149f159518444ae3 commit r11-9469-g024fd4fb5a1ba742242eec84149f159518444ae3 Author: Mikael Morin Date: Sun Jan 16 18:33:36 2022 +0100 testsuite: Enrich tests with variants failing on the branch. Backporting the fix for pr103789 on the 11 branch revealed a lack of test coverage for the tests provided with that fix. Indeed, the tests use the KIND argument of the respective intrinsics only with keyword arguments. This adds variants with non-keyword arguments. The tests enriched this way fail on the branch if the fix is cherry-picked straightforwardly. The fix will have to be tweaked slightly there. PR fortran/103789 PR fortran/87711 PR fortran/97896 gcc/testsuite/ChangeLog: * gfortran.dg/maskl_1.f90: Enrich test with usages of MASKL with a non-keyword KIND argument. * gfortran.dg/maskr_1.f90: Same for MASKR. * gfortran.dg/scan_3.f90: Same for SCAN. * gfortran.dg/verify_3.f90: Same for VERIFY. (cherry picked from commit 15630e6e9eb019477d1fc5c0966b43979e18ae18)
[Bug fortran/87711] ICE in gfc_trans_transfer, at fortran/trans-io.c:2676
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87711 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Mikael Morin : https://gcc.gnu.org/g:024fd4fb5a1ba742242eec84149f159518444ae3 commit r11-9469-g024fd4fb5a1ba742242eec84149f159518444ae3 Author: Mikael Morin Date: Sun Jan 16 18:33:36 2022 +0100 testsuite: Enrich tests with variants failing on the branch. Backporting the fix for pr103789 on the 11 branch revealed a lack of test coverage for the tests provided with that fix. Indeed, the tests use the KIND argument of the respective intrinsics only with keyword arguments. This adds variants with non-keyword arguments. The tests enriched this way fail on the branch if the fix is cherry-picked straightforwardly. The fix will have to be tweaked slightly there. PR fortran/103789 PR fortran/87711 PR fortran/97896 gcc/testsuite/ChangeLog: * gfortran.dg/maskl_1.f90: Enrich test with usages of MASKL with a non-keyword KIND argument. * gfortran.dg/maskr_1.f90: Same for MASKR. * gfortran.dg/scan_3.f90: Same for SCAN. * gfortran.dg/verify_3.f90: Same for VERIFY. (cherry picked from commit 15630e6e9eb019477d1fc5c0966b43979e18ae18)
[Bug fortran/103789] ICE when providing kind argument to mask{l,r}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103789 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Mikael Morin : https://gcc.gnu.org/g:8d394947776ad2b3ab8376dbf3c198f357bcd322 commit r11-9468-g8d394947776ad2b3ab8376dbf3c198f357bcd322 Author: Mikael Morin Date: Fri Jan 7 22:34:59 2022 +0100 Fortran: Ignore KIND argument of a few more intrinsics. [PR103789] After PR97896 for which some code was added to ignore the KIND argument of the INDEX intrinsics, and PR87711 for which that was extended to LEN_TRIM as well, this propagates it further to MASKL, MASKR, SCAN and VERIFY. PR fortran/103789 gcc/fortran/ChangeLog: * trans-array.c (arg_evaluated_for_scalarization): Add MASKL, MASKR, SCAN and VERIFY to the list of intrinsics whose KIND argument is to be ignored. gcc/testsuite/ChangeLog: * gfortran.dg/maskl_1.f90: New test. * gfortran.dg/maskr_1.f90: New test. * gfortran.dg/scan_3.f90: New test. * gfortran.dg/verify_3.f90: New test. (cherry picked from commit c1c17a43e172ebc28f2cd247f6e83c5fdbc6219f)
[Bug fortran/97896] [11/12 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896 --- Comment #16 from CVS Commits --- The releases/gcc-11 branch has been updated by Mikael Morin : https://gcc.gnu.org/g:e63ef9ae51ab67fdd280401e643eb97fddef8d93 commit r11-9467-ge63ef9ae51ab67fdd280401e643eb97fddef8d93 Author: Mikael Morin Date: Sun Jan 16 16:26:15 2022 +0100 Fortran: Fix KIND argument index for LEN_TRIM. The mainline code to check whether an argument has to be included in scalarization uses only the name of a dummy argument object to recognize a specific argument of an intrinsic procedure. On the 11 branch, the dummy argument object is not available and the code uses a mix of check for argument name (for keyword arguments) and argument index (for non-keyword ones). This makes backports non-straightforward in this area, as the argument indexes depend on the intrinsics. This change fixes a bogus backport for LEN_TRIM, whose KIND argument index should be different from that of INDEX. PR fortran/87711 PR fortran/97896 gcc/fortran/ChangeLog: * trans-array.c (arg_evaluated_for_scalarization): Handle keyword and non-keyword arguments separatedly. Adapt the expected argument index for KIND to each intrinsic in the non-keyword case. gcc/testsuite/ChangeLog: * gfortran.dg/index_5.f90: Enrich test with usages of INDEX with a non-keyword KIND argument. * gfortran.dg/len_trim.f90: Same for LEN_TRIM. (tests cherry picked from commit 15630e6e9eb019477d1fc5c0966b43979e18ae18)
[Bug fortran/87711] ICE in gfc_trans_transfer, at fortran/trans-io.c:2676
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87711 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Mikael Morin : https://gcc.gnu.org/g:e63ef9ae51ab67fdd280401e643eb97fddef8d93 commit r11-9467-ge63ef9ae51ab67fdd280401e643eb97fddef8d93 Author: Mikael Morin Date: Sun Jan 16 16:26:15 2022 +0100 Fortran: Fix KIND argument index for LEN_TRIM. The mainline code to check whether an argument has to be included in scalarization uses only the name of a dummy argument object to recognize a specific argument of an intrinsic procedure. On the 11 branch, the dummy argument object is not available and the code uses a mix of check for argument name (for keyword arguments) and argument index (for non-keyword ones). This makes backports non-straightforward in this area, as the argument indexes depend on the intrinsics. This change fixes a bogus backport for LEN_TRIM, whose KIND argument index should be different from that of INDEX. PR fortran/87711 PR fortran/97896 gcc/fortran/ChangeLog: * trans-array.c (arg_evaluated_for_scalarization): Handle keyword and non-keyword arguments separatedly. Adapt the expected argument index for KIND to each intrinsic in the non-keyword case. gcc/testsuite/ChangeLog: * gfortran.dg/index_5.f90: Enrich test with usages of INDEX with a non-keyword KIND argument. * gfortran.dg/len_trim.f90: Same for LEN_TRIM. (tests cherry picked from commit 15630e6e9eb019477d1fc5c0966b43979e18ae18)
[Bug libstdc++/104056] --disable-hosted-libstdcxx does not work for x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104056 --- Comment #1 from cqwrteur --- ../../../../gcc/configure --disable-nls --disable-werror --disable-shared --disable-threads --without-headers --disable-hosted-libstdcxx --disable-libstdcxx-verbose --enable-initfini-array --with-multilib-list=m64,m32,mx32 --disable-decimal-float --enable-languages=c,c++ --disable-libgomp --disable-libquadmath --disable-libssp --disable-libvtv --disable-libsanitizer --prefix=/home/cqwrteur/toolchains/gnu/native/x86_64-ubuntu-linux-gnu --target=x86_64-ubuntu-linux-gnu --disable-libatomic
[Bug libstdc++/104056] New: --disable-hosted-libstdcxx does not work for x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104056 Bug ID: 104056 Summary: --disable-hosted-libstdcxx does not work for x86_64-linux-gnu Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- ../../../../gcc/configure --disable-nls --disable-werror --disable-shared --disable-threads --without-headers --disable-hosted-libstdcxx --disable-libstdcxx-verbose --enable-initfini-array --with-multilib-list=m64,m32,mx32 --disable-decimal-float --enable-languages=c,c++ --disable-libgomp --disable-libquadmath --disable-libssp --disable-libvtv --disable-libsanitizer --prefix=$PREFIX --target=$TARGET --disable-libatomic gcc_build/native/x86_64-ubuntu-linux-gnu/gcc/./gcc/collect-ld -m elf_x86_64) supports shared libraries... yes checking dynamic linker characteristics... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [Makefile:13858: configure-target-libstdc++-v3] Error 1 make[1]: *** Waiting for unfinished jobs mv -f .deps/libcp1plugin.Tpo .deps/libcp1plugin.Plo
PING^3: [PATCH] Add --enable-first-stage-cross configure option
Final ping before stage3 ends: [PATCH] Add --enable-first-stage-cross configure option https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575318.html
[Bug c++/104055] New: Temporary with conteval constructor is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104055
Bug ID: 104055
Summary: Temporary with conteval constructor is ignored
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
Execution of the following program
```
#include
int g = 0;
struct A {
~A() { g = 1; }
consteval A() {}
};
int main() {
A{};
std::cout << g;
}
```
prints `0` in GCC. Demo: https://gcc.godbolt.org/z/7xxn67WbM
This means that the destructor of the temporary (which sets g=1) is not called.
[Bug fortran/67804] ICE on data initialization of type(character) with wrong data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67804 --- Comment #7 from anlauf at gcc dot gnu.org --- *** Bug 77667 has been marked as a duplicate of this bug. ***
[Bug fortran/77667] ICE in expand_call, at calls.c:2588
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77667 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #6 from anlauf at gcc dot gnu.org --- Indeed fixed on mainline by r12-6557. *** This bug has been marked as a duplicate of bug 67804 ***
[Bug fortran/103782] [9/10/11/12 Regression] internal error occurs when overloading intrinsic since r9-1566-g87c789f1c0b2df41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103782 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:eff452df296a6f3d0f94408bb2a4a5c4a3c86eb7 commit r11-9466-geff452df296a6f3d0f94408bb2a4a5c4a3c86eb7 Author: Harald Anlauf Date: Thu Jan 13 21:50:45 2022 +0100 Fortran: fix ICE overloading elemental intrinsics gcc/fortran/ChangeLog: PR fortran/103782 * expr.c (gfc_simplify_expr): Adjust logic for when to scalarize a call of an intrinsic which may have been overloaded. gcc/testsuite/ChangeLog: PR fortran/103782 * gfortran.dg/overload_4.f90: New test. (cherry picked from commit a4a8ae123cd70188e4b4bf5e288a84e0a76fb0fd)
[Bug fortran/67804] ICE on data initialization of type(character) with wrong data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67804 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c5bf6dc27cdb091f1f8046f98ce7ca197bffd908 commit r11-9465-gc5bf6dc27cdb091f1f8046f98ce7ca197bffd908 Author: Harald Anlauf Date: Wed Jan 12 21:24:49 2022 +0100 Fortran: fix error recovery on bad structure constructor in DATA statement gcc/fortran/ChangeLog: PR fortran/67804 * primary.c (gfc_match_structure_constructor): Recover from errors that occurred while checking for a valid structure constructor in a DATA statement. gcc/testsuite/ChangeLog: PR fortran/67804 * gfortran.dg/pr93604.f90: Adjust to changed diagnostics. * gfortran.dg/pr67804.f90: New test. (cherry picked from commit 0b8464365b15ac108cd1d00d5bc56d229c1340de)
[Bug c++/104031] [12 regression] Global nested constructors generate invalid code since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104031 --- Comment #9 from Jakub Jelinek --- Created attachment 52208 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52208=edit gcc12-pr104031.patch This seems to work for the testcase, but dunno if there aren't better fixes.
[Bug testsuite/104037] [12 regression] excess errors in g++.old-deja/g++.robertl/eb43.C after r12-6581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104037 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED --- Comment #2 from Jonathan Wakely --- Fixed now, sorry about that.
Re: [PATCH] libstdc++: Add attribute to features deprecated in C++17 [PR91260]
On Fri, 14 Jan 2022 at 11:32, Jonathan Wakely wrote:
>
>
> On Wed, 12 Jan 2022 at 09:34, Jonathan Wakely via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> This passes testing (with -std=gnu++98/11/17/20) but is quite a large
>> patch for this late in stage 3. Does anybody object to doing this now?
>> The bugs it fixes were closed as INVALID because we're not actually
>> *required* to remove these or deprecate them. But users are right to
>> complain about us silently accepting use of things like std::bind1st in
>> C++20 mode. Probably WONTFIX would have been better, and in fact we can
>> fix them (as this patch does). If we don't do this, users will keep
>> reporting bugs about it, but it could wait for stage 1 if needed.
>>
>
> Pushed to trunk.
>
>
And this fix for the g++ tests.
Tested powerpc64le-linux, pushed to trunk.
commit bca1c431affee41ecadb7f29d8d65142a73e0ebf
Author: Jonathan Wakely
Date: Fri Jan 14 22:08:16 2022
libstdc++: Ignore deprecated warnings [PR104037]
The std::pointer_to_binary_function utility was deprecated in C++11 and
removed in C++17. Libstdc++ has started to warn about using it, so
suppress the warnings for this test.
gcc/testsuite/ChangeLog:
PR testsuite/104037
* g++.old-deja/g++.robertl/eb43.C: Ad -Wno-deprecated.
diff --git a/gcc/testsuite/g++.old-deja/g++.robertl/eb43.C
b/gcc/testsuite/g++.old-deja/g++.robertl/eb43.C
index 90afbe4f190..c54050c3c7a 100644
--- a/gcc/testsuite/g++.old-deja/g++.robertl/eb43.C
+++ b/gcc/testsuite/g++.old-deja/g++.robertl/eb43.C
@@ -5,6 +5,7 @@
// to pointer_to_binary_function, which has an `explicit' constructor.
// { dg-prune-output "note" }
+// { dg-options "-Wno-deprecated" }
#include
#include
[Bug c++/104031] [12 regression] Global nested constructors generate invalid code since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104031
--- Comment #8 from Jakub Jelinek ---
That last testcase isn't very good for the testsuite, because 0 is pretty
common value on the stack, so even without the store the chances that it will
be already zero are high.
42 is less likely...
// PR c++/104031
// { dg-do run { target c++14 } }
// { dg-options "-O2" }
struct A {
A () {}
~A () {}
};
struct B {
A a;
int b = 0;
};
struct C
{
[[gnu::noipa]]
C (B x) { if (x.b != 42) __builtin_abort (); }
};
static C c ({ .a = A{}, .b = 42 });
int
main ()
{
}
Re: [PATCH] Strengthen memory memory order for atomic::wait/notify
On Sun, 16 Jan 2022 at 01:48, Thomas Rodgers via Libstdc++ < libstd...@gcc.gnu.org> wrote: > This patch updates the memory order of atomic accesses to the waiter's > count to match libc++'s usage. It should be backported to GCC11. > The commit subject line says "memory memory order", OK for trunk and gcc-11 with that fixed. > Tested x86_64-pc-linux-gnu. >
[Bug testsuite/104037] [12 regression] excess errors in g++.old-deja/g++.robertl/eb43.C after r12-6581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104037 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:bca1c431affee41ecadb7f29d8d65142a73e0ebf commit r12-6614-gbca1c431affee41ecadb7f29d8d65142a73e0ebf Author: Jonathan Wakely Date: Fri Jan 14 22:08:16 2022 + libstdc++: Ignore deprecated warnings [PR104037] The std::pointer_to_binary_function utility was deprecated in C++11 and removed in C++17. Libstdc++ has started to warn about using it, so suppress the warnings for this test. gcc/testsuite/ChangeLog: PR testsuite/104037 * g++.old-deja/g++.robertl/eb43.C: Ad -Wno-deprecated.
[Bug testsuite/103324] RFE: Add a `make quickcheck` or `make smoketest` Makefile target to allow only running a portion of the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103324 --- Comment #3 from Eric Gallager --- https://gcc.gnu.org/install/test.html says "To get a list of the possible *.exp files, pipe the output of ‘make check’ into a file and look at the ‘Running … .exp’ lines." ...has anyone stored their output from doing so recently? I don't really want to run the entire testsuite just to generate this list...
[pushed] fortan testsuite: Enrich tests with variants failing on the branch.
Hello,
I have just pushed the attached patch after testing the impacted tests
individually.
MikaelFrom 15630e6e9eb019477d1fc5c0966b43979e18ae18 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Sun, 16 Jan 2022 18:33:36 +0100
Subject: [PATCH] testsuite: Enrich tests with variants failing on the branch.
Backporting the fix for pr103789 on the 11 branch revealed a lack of test
coverage for the tests provided with that fix. Indeed, the tests use the KIND
argument of the respective intrinsics only with keyword arguments.
This adds variants with non-keyword arguments.
The tests enriched this way fail on the branch if the fix is cherry-picked
straightforwardly. The fix will have to be tweaked slightly there.
PR fortran/103789
PR fortran/87711
PR fortran/97896
gcc/testsuite/ChangeLog:
* gfortran.dg/index_5.f90: Enrich test with usages of INDEX with
a non-keyword KIND argument.
* gfortran.dg/len_trim.f90: Same for LEN_TRIM.
* gfortran.dg/maskl_1.f90: Same for MASKL.
* gfortran.dg/maskr_1.f90: Same for MASKR.
* gfortran.dg/scan_3.f90: Same for SCAN.
* gfortran.dg/verify_3.f90: Same for VERIFY.
---
gcc/testsuite/gfortran.dg/index_5.f90 | 2 ++
gcc/testsuite/gfortran.dg/len_trim.f90 | 6 ++
gcc/testsuite/gfortran.dg/maskl_1.f90 | 3 ++-
gcc/testsuite/gfortran.dg/maskr_1.f90 | 3 ++-
gcc/testsuite/gfortran.dg/scan_3.f90 | 5 -
gcc/testsuite/gfortran.dg/verify_3.f90 | 5 -
6 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/index_5.f90 b/gcc/testsuite/gfortran.dg/index_5.f90
index e039455d175..4dc2ce4c0a1 100644
--- a/gcc/testsuite/gfortran.dg/index_5.f90
+++ b/gcc/testsuite/gfortran.dg/index_5.f90
@@ -19,5 +19,7 @@ program p
d = index ('xyxyz','yx', back=a, kind=8)
b = index ('xyxyz','yx', back=a, kind=8)
d = index ('xyxyz','yx', back=a, kind=4)
+ b = index ('xyxyz','yx', a, 4)
+ d = index ('xyxyz','yx', a, 8)
end
diff --git a/gcc/testsuite/gfortran.dg/len_trim.f90 b/gcc/testsuite/gfortran.dg/len_trim.f90
index 2252b81f084..77e3d30c669 100644
--- a/gcc/testsuite/gfortran.dg/len_trim.f90
+++ b/gcc/testsuite/gfortran.dg/len_trim.f90
@@ -17,11 +17,17 @@ program main
kk = len_trim (a)
mm = len_trim (a, kind=4)
nn = len_trim (a, kind=8)
+ mm = len_trim (a, 4)
+ nn = len_trim (a, 8)
kk = len_trim ([b])
mm = len_trim ([b],kind=4)
nn = len_trim ([b],kind=8)
+ mm = len_trim ([b], 4)
+ nn = len_trim ([b], 8)
kk = len_trim (c)
mm = len_trim (c, kind=4)
nn = len_trim (c, kind=8)
+ mm = len_trim (c, 4)
+ nn = len_trim (c, 8)
if (any (l4 /= 2_4) .or. any (l8 /= 2_8)) stop 1
end program main
diff --git a/gcc/testsuite/gfortran.dg/maskl_1.f90 b/gcc/testsuite/gfortran.dg/maskl_1.f90
index 9e25c2c9cdc..56350e269da 100644
--- a/gcc/testsuite/gfortran.dg/maskl_1.f90
+++ b/gcc/testsuite/gfortran.dg/maskl_1.f90
@@ -4,7 +4,8 @@
! Check the absence of ICE when generating calls to MASKL with a KIND argument.
program p
- integer :: z(2), y(2)
+ integer :: z(2), y(2), x(2)
y = [1, 13]
z = maskl(y, kind=4) + 1
+ x = maskl(y, 4) + 1
end program p
diff --git a/gcc/testsuite/gfortran.dg/maskr_1.f90 b/gcc/testsuite/gfortran.dg/maskr_1.f90
index ebfd3dbba33..f8ccdd11ab3 100644
--- a/gcc/testsuite/gfortran.dg/maskr_1.f90
+++ b/gcc/testsuite/gfortran.dg/maskr_1.f90
@@ -4,7 +4,8 @@
! Check the absence of ICE when generating calls to MASKR with a KIND argument.
program p
- integer :: z(2), y(2)
+ integer :: z(2), y(2), x(2)
y = [1, 13]
z = maskr(y, kind=4) + 1
+ x = maskr(y, 4) + 1
end program p
diff --git a/gcc/testsuite/gfortran.dg/scan_3.f90 b/gcc/testsuite/gfortran.dg/scan_3.f90
index 80262ae2167..2a9ed080957 100644
--- a/gcc/testsuite/gfortran.dg/scan_3.f90
+++ b/gcc/testsuite/gfortran.dg/scan_3.f90
@@ -5,7 +5,10 @@
program p
character(len=10) :: y(2)
- integer :: z(2)
+ integer :: z(2), x(2), w(2), v(2)
y = ['abc', 'def']
z = scan(y, 'e', kind=4) + 1
+ x = scan(y, 'e', back=.false., kind=4) + 1
+ w = scan(y, 'e', .false., kind=4) + 1
+ v = scan(y, 'e', .false., 4) + 1
end program p
diff --git a/gcc/testsuite/gfortran.dg/verify_3.f90 b/gcc/testsuite/gfortran.dg/verify_3.f90
index f01e24e199e..c8b26b70614 100644
--- a/gcc/testsuite/gfortran.dg/verify_3.f90
+++ b/gcc/testsuite/gfortran.dg/verify_3.f90
@@ -5,7 +5,10 @@
program p
character(len=10) :: y(2)
- integer :: z(2)
+ integer :: z(2), x(2), w(2), v(2)
y = ['abc', 'def']
z = verify(y, 'e', kind=4) + 1
+ x = verify(y, 'e', back=.false., kind=4) + 1
+ w = verify(y, 'e', .false., kind=4) + 1
+ x = verify(y, 'e', .false., 4) + 1
end program p
--
2.34.1
[Bug fortran/97896] [11/12 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896 --- Comment #15 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:15630e6e9eb019477d1fc5c0966b43979e18ae18 commit r12-6613-g15630e6e9eb019477d1fc5c0966b43979e18ae18 Author: Mikael Morin Date: Sun Jan 16 18:33:36 2022 +0100 testsuite: Enrich tests with variants failing on the branch. Backporting the fix for pr103789 on the 11 branch revealed a lack of test coverage for the tests provided with that fix. Indeed, the tests use the KIND argument of the respective intrinsics only with keyword arguments. This adds variants with non-keyword arguments. The tests enriched this way fail on the branch if the fix is cherry-picked straightforwardly. The fix will have to be tweaked slightly there. PR fortran/103789 PR fortran/87711 PR fortran/97896 gcc/testsuite/ChangeLog: * gfortran.dg/index_5.f90: Enrich test with usages of INDEX with a non-keyword KIND argument. * gfortran.dg/len_trim.f90: Same for LEN_TRIM. * gfortran.dg/maskl_1.f90: Same for MASKL. * gfortran.dg/maskr_1.f90: Same for MASKR. * gfortran.dg/scan_3.f90: Same for SCAN. * gfortran.dg/verify_3.f90: Same for VERIFY.
[Bug fortran/103789] ICE when providing kind argument to mask{l,r}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103789 --- Comment #5 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:15630e6e9eb019477d1fc5c0966b43979e18ae18 commit r12-6613-g15630e6e9eb019477d1fc5c0966b43979e18ae18 Author: Mikael Morin Date: Sun Jan 16 18:33:36 2022 +0100 testsuite: Enrich tests with variants failing on the branch. Backporting the fix for pr103789 on the 11 branch revealed a lack of test coverage for the tests provided with that fix. Indeed, the tests use the KIND argument of the respective intrinsics only with keyword arguments. This adds variants with non-keyword arguments. The tests enriched this way fail on the branch if the fix is cherry-picked straightforwardly. The fix will have to be tweaked slightly there. PR fortran/103789 PR fortran/87711 PR fortran/97896 gcc/testsuite/ChangeLog: * gfortran.dg/index_5.f90: Enrich test with usages of INDEX with a non-keyword KIND argument. * gfortran.dg/len_trim.f90: Same for LEN_TRIM. * gfortran.dg/maskl_1.f90: Same for MASKL. * gfortran.dg/maskr_1.f90: Same for MASKR. * gfortran.dg/scan_3.f90: Same for SCAN. * gfortran.dg/verify_3.f90: Same for VERIFY.
[Bug fortran/87711] ICE in gfc_trans_transfer, at fortran/trans-io.c:2676
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87711 --- Comment #7 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:15630e6e9eb019477d1fc5c0966b43979e18ae18 commit r12-6613-g15630e6e9eb019477d1fc5c0966b43979e18ae18 Author: Mikael Morin Date: Sun Jan 16 18:33:36 2022 +0100 testsuite: Enrich tests with variants failing on the branch. Backporting the fix for pr103789 on the 11 branch revealed a lack of test coverage for the tests provided with that fix. Indeed, the tests use the KIND argument of the respective intrinsics only with keyword arguments. This adds variants with non-keyword arguments. The tests enriched this way fail on the branch if the fix is cherry-picked straightforwardly. The fix will have to be tweaked slightly there. PR fortran/103789 PR fortran/87711 PR fortran/97896 gcc/testsuite/ChangeLog: * gfortran.dg/index_5.f90: Enrich test with usages of INDEX with a non-keyword KIND argument. * gfortran.dg/len_trim.f90: Same for LEN_TRIM. * gfortran.dg/maskl_1.f90: Same for MASKL. * gfortran.dg/maskr_1.f90: Same for MASKR. * gfortran.dg/scan_3.f90: Same for SCAN. * gfortran.dg/verify_3.f90: Same for VERIFY.
[PATCH 2/6] libstdc++: Import the fast_float library
We're going to use the fast_float library in our (compiled-in)
floating-point std::from_chars implementation for faster and more
portable parsing of binary32/64 decimal strings.
The single file fast_float.h is an amalgamation of the entire library,
which can be (re)generated with the command
python3 ./script/amalgamate.py --license=MIT \
> $GCC_SRC/libstdc++-v3/c++17/fast_float/fast_float.h
[1]: https://github.com/fastfloat/fast_float
libstdc++-v3/ChangeLog:
* src/c++17/fast_float/LOCAL_PATCHES: New file.
* src/c++17/fast_float/MERGE: New file.
* src/c++17/fast_float/README.fd: New file, copied from the
fast_float library sources.
* src/c++17/fast_float/fast_float.h: New file, an amalgamation
of the fast_float library.
Signed-off-by: Patrick Palka
---
.../src/c++17/fast_float/LOCAL_PATCHES|0
libstdc++-v3/src/c++17/fast_float/MERGE |4 +
libstdc++-v3/src/c++17/fast_float/README.md | 218 ++
.../src/c++17/fast_float/fast_float.h | 2944 +
4 files changed, 3166 insertions(+)
create mode 100644 libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
create mode 100644 libstdc++-v3/src/c++17/fast_float/MERGE
create mode 100644 libstdc++-v3/src/c++17/fast_float/README.md
create mode 100644 libstdc++-v3/src/c++17/fast_float/fast_float.h
diff --git a/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
b/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
new file mode 100644
index 000..e69de29bb2d
diff --git a/libstdc++-v3/src/c++17/fast_float/MERGE
b/libstdc++-v3/src/c++17/fast_float/MERGE
new file mode 100644
index 000..43bdc3981c8
--- /dev/null
+++ b/libstdc++-v3/src/c++17/fast_float/MERGE
@@ -0,0 +1,4 @@
+d35368cae610b4edeec61cd41e4d2367a4d33f58
+
+The first line of this file holds the git revision number of the
+last merge done from the master library sources.
diff --git a/libstdc++-v3/src/c++17/fast_float/README.md
b/libstdc++-v3/src/c++17/fast_float/README.md
new file mode 100644
index 000..1e1c06d0a3e
--- /dev/null
+++ b/libstdc++-v3/src/c++17/fast_float/README.md
@@ -0,0 +1,218 @@
+## fast_float number parsing library: 4x faster than strtod
+
+/badge.svg)
+/badge.svg)
+
+
+
+[](https://github.com/fastfloat/fast_float/actions/workflows/vs16-ci.yml)
+
+The fast_float library provides fast header-only implementations for the C++
from_chars
+functions for `float` and `double` types. These functions convert ASCII
strings representing
+decimal values (e.g., `1.3e10`) into binary types. We provide exact rounding
(including
+round to even). In our experience, these `fast_float` functions many times
faster than comparable number-parsing functions from existing C++ standard
libraries.
+
+Specifically, `fast_float` provides the following two functions with a
C++17-like syntax (the library itself only requires C++11):
+
+```C++
+from_chars_result from_chars(const char* first, const char* last, float&
value, ...);
+from_chars_result from_chars(const char* first, const char* last, double&
value, ...);
+```
+
+The return type (`from_chars_result`) is defined as the struct:
+```C++
+struct from_chars_result {
+const char* ptr;
+std::errc ec;
+};
+```
+
+It parses the character sequence [first,last) for a number. It parses
floating-point numbers expecting
+a locale-independent format equivalent to the C++17 from_chars function.
+The resulting floating-point value is the closest floating-point values (using
either float or double),
+using the "round to even" convention for values that would otherwise fall
right in-between two values.
+That is, we provide exact parsing according to the IEEE standard.
+
+
+Given a successful parse, the pointer (`ptr`) in the returned value is set to
point right after the
+parsed number, and the `value` referenced is set to the parsed value. In case
of error, the returned
+`ec` contains a representative error, otherwise the default (`std::errc()`)
value is stored.
+
+The implementation does not throw and does not allocate memory (e.g., with
`new` or `malloc`).
+
+It will parse infinity and nan values.
+
+Example:
+
+``` C++
+#include "fast_float/fast_float.h"
+#include
+
+int main() {
+const std::string input = "3.1416 xyz ";
+double result;
+auto answer = fast_float::from_chars(input.data(),
input.data()+input.size(), result);
+if(answer.ec != std::errc()) { std::cerr <<
[PATCH 4/6] libstdc++: Adjust fast_float's over/underflow behavior for conformnace
This makes fast_float handle the situation where std::from_chars is
specified to return result_out_of_range, i.e. when the parsed value
is outside the representable range of the floating-point type.
This adjusts fast_float's behavior in case of over/underflow: instead of
returning errc{} and setting value to +-0 or +-infinity, return
result_out_of_range and don't modify value, as per [charconv.from.chars]/1.
libstdc++-v3/ChangeLog:
* src/c++17/fast_float/LOCAL_PATCHES: Update.
* src/c++17/fast_float/fast_float.h (from_chars_advanced): In
case of over/underflow, return errc::result_out_of_range and don't
modify 'value'.
---
libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES | 1 +
libstdc++-v3/src/c++17/fast_float/fast_float.h | 9 +
2 files changed, 10 insertions(+)
diff --git a/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
b/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
index e9d7bba6195..1f90f9d1d85 100644
--- a/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
+++ b/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
@@ -1 +1,2 @@
r12-
+r12-
diff --git a/libstdc++-v3/src/c++17/fast_float/fast_float.h
b/libstdc++-v3/src/c++17/fast_float/fast_float.h
index c908719ec3a..97d28940944 100644
--- a/libstdc++-v3/src/c++17/fast_float/fast_float.h
+++ b/libstdc++-v3/src/c++17/fast_float/fast_float.h
@@ -2884,6 +2884,15 @@ from_chars_result from_chars_advanced(const char *first,
const char *last,
// If we called compute_float>(pns.exponent, pns.mantissa)
and we have an invalid power (am.power2 < 0),
// then we need to go the long way around again. This is very uncommon.
if(am.power2 < 0) { am = digit_comp(pns, am); }
+
+ if((pns.mantissa != 0 && am.mantissa == 0 && am.power2 == 0) || am.power2 ==
binary_format::infinite_power()) {
+// In case of over/underflow, return result_out_of_range and don't modify
value,
+// as per [charconv.from.chars]/1. Note that LWG 3081 wants to modify
value in
+// this case too.
+answer.ec = std::errc::result_out_of_range;
+return answer;
+ }
+
to_float(pns.negative, am, value);
return answer;
}
--
2.35.0.rc1
[PATCH 5/6] libstdc++: Use fast_float in std::from_chars for binary32/64
This makes our std::from_chars implementation use fast_float for parsing
chars_format::scientific/fixed/general parsing into binary32/64 values.
For other floating-point formats we still use the fallback implementation
that goes through the strtod family of functions.
libstdc++-v3/ChangeLog:
* src/c++17/floating_from_chars.cc: (USE_LIB_FAST_FLOAT):
Conditionally define, and use it to conditionally include
fast_float.
(from_chars): Use fast_float for float and double when
USE_LIB_FAST_FLOAT.
---
libstdc++-v3/src/c++17/floating_from_chars.cc | 31 ---
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/libstdc++-v3/src/c++17/floating_from_chars.cc
b/libstdc++-v3/src/c++17/floating_from_chars.cc
index b186da9a955..c340eb18ea8 100644
--- a/libstdc++-v3/src/c++17/floating_from_chars.cc
+++ b/libstdc++-v3/src/c++17/floating_from_chars.cc
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -53,6 +54,18 @@
extern "C" __ieee128 __strtoieee128(const char*, char**);
#endif
+#if _GLIBCXX_FLOAT_IS_IEEE_BINARY32 && _GLIBCXX_DOUBLE_IS_IEEE_BINARY64
+# define USE_LIB_FAST_FLOAT 1
+#endif
+
+#if USE_LIB_FAST_FLOAT
+# define FASTFLOAT_DEBUG_ASSERT __glibcxx_assert
+namespace
+{
+# include "fast_float/fast_float.h"
+} // anon namespace
+#endif
+
#if _GLIBCXX_HAVE_USELOCALE
namespace std _GLIBCXX_VISIBILITY(default)
{
@@ -775,8 +788,12 @@ from_chars(const char* first, const char* last, float&
value,
#if _GLIBCXX_FLOAT_IS_IEEE_BINARY32 && _GLIBCXX_DOUBLE_IS_IEEE_BINARY64
if (fmt == chars_format::hex)
return __floating_from_chars_hex(first, last, value);
-#endif
-
+ else
+{
+ static_assert(USE_LIB_FAST_FLOAT);
+ return fast_float::from_chars(first, last, value, fmt);
+}
+#else
errc ec = errc::invalid_argument;
#if _GLIBCXX_USE_CXX11_ABI
buffer_resource mr;
@@ -797,6 +814,7 @@ from_chars(const char* first, const char* last, float&
value,
fmt = chars_format{};
}
return make_result(first, len, fmt, ec);
+#endif
}
from_chars_result
@@ -806,8 +824,12 @@ from_chars(const char* first, const char* last, double&
value,
#if _GLIBCXX_FLOAT_IS_IEEE_BINARY32 && _GLIBCXX_DOUBLE_IS_IEEE_BINARY64
if (fmt == chars_format::hex)
return __floating_from_chars_hex(first, last, value);
-#endif
-
+ else
+{
+ static_assert(USE_LIB_FAST_FLOAT);
+ return fast_float::from_chars(first, last, value, fmt);
+}
+#else
errc ec = errc::invalid_argument;
#if _GLIBCXX_USE_CXX11_ABI
buffer_resource mr;
@@ -828,6 +850,7 @@ from_chars(const char* first, const char* last, double&
value,
fmt = chars_format{};
}
return make_result(first, len, fmt, ec);
+#endif
}
from_chars_result
--
2.35.0.rc1
