Re: [PATCH v2] Add MinGW option -mcrtdll= for choosing C RunTime DLL library
On 6/14/23 16:09, Pali Rohár wrote: It adjust preprocess, compile and link flags, which allows to change default -lmsvcrt library by another provided by MinGW runtime. gcc/ * config/i386/mingw-w64.h (CPP_SPEC): Adjust for -mcrtdll=. (REAL_LIBGCC_SPEC): New define. * config/i386/mingw.opt: Add mcrtdll= * config/i386/mingw32.h (CPP_SPEC): Adjust for -mcrtdll=. (REAL_LIBGCC_SPEC): Adjust for -mcrtdll=. (STARTFILE_SPEC): Adjust for -mcrtdll=. * doc/invoke.texi: Add mcrtdll= documentation. --- Changes in v2: * Fixed doc/invoke.texi documentation --- gcc/config/i386/mingw-w64.h | 22 +- gcc/config/i386/mingw.opt | 4 gcc/config/i386/mingw32.h | 28 gcc/doc/invoke.texi | 24 +++- 4 files changed, 72 insertions(+), 6 deletions(-) Thanks, pushed to master branch.
Re: [PATCH] Add MinGW option -mcrtdll= for choosing C RunTime DLL library
On 6/12/23 01:26, LIU Hao wrote:
在 2023/6/12 07:08, Jonathan Yong 写道:
+preprocessor is done. MinGW import library @code{msvcrt} is just a
+symlink (or file copy) to the other MinGW CRT import library
I suggest a change to this line:
symlink to (or a copy of) another MinGW CRT import library
Also, as discussed earlier, linking against a CRT version different from
the value of `__MSVCRT_VERSION__` in _mingw.h is not officially
supported and should be warned. So maybe we can append a paragraph to
the documentation:
Generally speaking, changing the CRT DLL requires recompiling
the entire MinGW CRT. This option is for experimental and testing
purposes only.
Pali, mind updating the patch?
Re: [PATCH] Add MinGW option -mcrtdll= for choosing C RunTime DLL library
On 5/27/23 10:14, Pali Rohár wrote:
It adjust preprocess, compile and link flags, which allows to change
default -lmsvcrt library by another provided by MinGW runtime.
gcc/
* config/i386/mingw-w64.h (CPP_SPEC): Adjust for -mcrtdll=.
(REAL_LIBGCC_SPEC): New define.
* config/i386/mingw.opt: Add mcrtdll=
* config/i386/mingw32.h (CPP_SPEC): Adjust for -mcrtdll=.
(REAL_LIBGCC_SPEC): Adjust for -mcrtdll=.
(STARTFILE_SPEC): Adjust for -mcrtdll=.
* doc/invoke.texi: Add mcrtdll= documentation.
---
gcc/config/i386/mingw-w64.h | 22 +-
gcc/config/i386/mingw.opt | 4
gcc/config/i386/mingw32.h | 28
gcc/doc/invoke.texi | 21 -
4 files changed, 69 insertions(+), 6 deletions(-)
diff --git a/gcc/config/i386/mingw-w64.h b/gcc/config/i386/mingw-w64.h
index 3a21cec3f8cd..0146ed4f793e 100644
--- a/gcc/config/i386/mingw-w64.h
+++ b/gcc/config/i386/mingw-w64.h
@@ -25,7 +25,27 @@ along with GCC; see the file COPYING3. If not see
#define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} " \
"%{municode:-DUNICODE} " \
"%{" SPEC_PTHREAD1 ":-D_REENTRANT} " \
-"%{" SPEC_PTHREAD2 ":-U_REENTRANT} "
+"%{" SPEC_PTHREAD2 ":-U_REENTRANT} " \
+"%{mcrtdll=crtdll*:-U__MSVCRT__ -D__CRTDLL__} " \
+"%{mcrtdll=msvcrt10*:-D__MSVCRT_VERSION__=0x100} " \
+"%{mcrtdll=msvcrt20*:-D__MSVCRT_VERSION__=0x200} " \
+"%{mcrtdll=msvcrt40*:-D__MSVCRT_VERSION__=0x400} " \
+"%{mcrtdll=msvcrt-os*:-D__MSVCRT_VERSION__=0x700} " \
+"%{mcrtdll=msvcr70*:-D__MSVCRT_VERSION__=0x700} " \
+"%{mcrtdll=msvcr71*:-D__MSVCRT_VERSION__=0x701} " \
+"%{mcrtdll=msvcr80*:-D__MSVCRT_VERSION__=0x800} " \
+"%{mcrtdll=msvcr90*:-D__MSVCRT_VERSION__=0x900} " \
+"%{mcrtdll=msvcr100*:-D__MSVCRT_VERSION__=0xA00} " \
+"%{mcrtdll=msvcr110*:-D__MSVCRT_VERSION__=0xB00} " \
+"%{mcrtdll=msvcr120*:-D__MSVCRT_VERSION__=0xC00} " \
+"%{mcrtdll=ucrt*:-D_UCRT} "
+
+#undef REAL_LIBGCC_SPEC
+#define REAL_LIBGCC_SPEC \
+ "%{mthreads:-lmingwthrd} -lmingw32 \
+ " SHARED_LIBGCC_SPEC " \
+ -lmingwex %{!mcrtdll=*:-lmsvcrt} %{mcrtdll=*:-l%*} \
+ -lkernel32 " MCFGTHREAD_SPEC
#undef STARTFILE_SPEC
#define STARTFILE_SPEC "%{shared|mdll:dllcrt2%O%s} \
diff --git a/gcc/config/i386/mingw.opt b/gcc/config/i386/mingw.opt
index 0ae026a66bd6..dd66a50aec00 100644
--- a/gcc/config/i386/mingw.opt
+++ b/gcc/config/i386/mingw.opt
@@ -18,6 +18,10 @@
; along with GCC; see the file COPYING3. If not see
;
Re: [PATCH] libiberty: On Windows pass a >32k cmdline through a response file.
On 6/5/23 09:22, Costas Argyris wrote: Thanks, here is the follow up patch for a couple typos in the same file. Thanks, pushed as obvious.
Re: [PATCH] libiberty: On Windows pass a >32k cmdline through a response file.
On 5/23/23 08:21, Jonathan Yong wrote: On 5/22/23 13:25, Costas Argyris wrote: Currently on Windows, when CreateProcess is called with a command-line that exceeds the 32k Windows limit, we get a very bad error: "CreateProcess: No such file or directory" This patch detects the case where this would happen and writes the long command-line to a temporary response file and calls CreateProcess with @file instead. Looks OK to me. I will commit it around next week if there are no objections. Done, pushed to master, thanks.
Re: [PATCH] libiberty: On Windows pass a >32k cmdline through a response file.
On 5/22/23 13:25, Costas Argyris wrote: Currently on Windows, when CreateProcess is called with a command-line that exceeds the 32k Windows limit, we get a very bad error: "CreateProcess: No such file or directory" This patch detects the case where this would happen and writes the long command-line to a temporary response file and calls CreateProcess with @file instead. Looks OK to me. I will commit it around next week if there are no objections.
Re: [PATCH] mingw: Support building with older gcc versions
On 4/12/23 13:39, Costas Argyris wrote: This is proposed to fix PR109460 where an older version of gcc (7.3) was used to build for windows (mingw) host. Thanks, accepted and pushed to master branch.
Re: [Patch] c-c++-common/Warray-bounds.c: fix excess warnings on LLP64
On 3/31/23 00:09, Mike Stump wrote: On Feb 27, 2023, at 2:29 AM, Jonathan Yong via Gcc-patches wrote: Attached patch OK? Ok. * c-c++-common/Warray-bounds.c: Fix excess warnings on LLP64.<0001-c-c-common-Warray-bounds.c-fix-excess-warnings-on-LL.patch> Thanks for reviewing, pushed to master branch.
Re: [Patch] c-c++-common/Warray-bounds.c: fix excess warnings on LLP64
On 2/27/23 10:29, Jonathan Yong wrote: Attached patch OK? Excess errors on x86_64-w64-mingw32: /home/user/p/gcc/src/gcc-git/gcc/testsuite/c-c++-common/Warray-bounds.c:50:3: warning: array subscript 4611686018427387902 is above array bounds of 'struct S16[]' [-Warray-bounds=] /home/user/p/gcc/src/gcc-git/gcc/testsuite/c-c++-common/Warray-bounds.c:55:3: warning: array subscript 4611686018427387902 is above array bounds of 'struct S16[]' [-Warray-bounds=] /home/user/p/gcc/src/gcc-git/gcc/testsuite/c-c++-common/Warray-bounds.c:90:3: warning: array subscript 658812288346769699 is above array bounds of 'struct S16[][7]' [-Warray-bounds=] gcc/testsuite/ChangeLog: * c-c++-common/Warray-bounds.c: Fix excess warnings on LLP64. Ping?
Re: Enable UTF-8 code page in driver and compiler on 64-bit mingw host [PR108865]
On 3/28/23 10:43, Costas Argyris wrote: I forgot to update the relevant comments with the previous patch. This is a comment-only patch that brings them up-to-date. Done, thanks.
Re: Enable UTF-8 code page in driver and compiler on 64-bit mingw host [PR108865]
On 3/27/23 17:17, Costas Argyris wrote: The patch attached to this email extends the UTF-8 support of the driver and compiler processes to the 32-bit mingw host.Initially, only the 64-bit host got it. About the changes in sym-mingw32.cc: Even though the 64-bit host was building fine with the symbol being simply declared as a char, the 32-bit host was failing to find the symbol at link time because a leading underscore was being added to it by the compiler.The asm keyword ensures that the symbol always appears with that exact name, such that the linker will always find it. The patch also includes Jacek's flag about adding the .manifest file as a prerequisite for the object file (this was actually done from before but an earlier version of the patch was pushed so it was missed). Tested building from master for both 32 and 64-bit mingw hosts using: 1) cross-compilation from a Debian machine using configure + make 2) native-compilation from a Windows machine using MSYS2 Thanks, approved and pushed to master branch.
Re: [Patch] More LLP64 fixes and __PIC__ values fixes for PE targets
On 3/12/23 16:54, Jeff Law wrote: Windows code is effectively always PIC, since the PE loader can relocate it anywhere if the preferred address is already occupied. Patch still OK? Yes, still OK. Just make the trivial ChangeLog adjustments. Done, pushed to master branch, thanks.
Re: [Patch] More LLP64 fixes and __PIC__ values fixes for PE targets
On 3/11/23 17:29, Jeff Law wrote: On 2/14/23 03:42, Jonathan Yong via Gcc-patches wrote: Attached patches OK? 0002-gcc-testsuite-gcc.dg-fix-pic-test-case-for-PE-target.patch From 616e43ac41879040e73a266065874148553cddcc Mon Sep 17 00:00:00 2001 From: Jonathan Yong<10wa...@gmail.com> Date: Tue, 14 Feb 2023 10:37:03 + Subject: [PATCH 2/2] gcc/testsuite/gcc.dg: fix pic test case for PE targets gcc/testsuite/ChangeLog: * pic-2.c: fix expected __PIC__ value. * pic-3.c: ditto. * pic-4.c: ditto. Please adjust your ChangeLog entries slightly, in particular, please capitalize the first letter in each ChangeLog entry. ie, fix->Fix, ditto->Ditto. Presumably the windows platforms are not always PIC and thus should not be handled in a manner similar to MIPS? Assuming that's the case, then this patch is OK with the trivial ChangeLog fixes. Windows code is effectively always PIC, since the PE loader can relocate it anywhere if the preferred address is already occupied. Patch still OK? 0001-gcc-testsuite-gcc.dg-fix-LLP64-targets.patch From a1fafc5a3c70684e843f5f0b6cf392ce349cb6b0 Mon Sep 17 00:00:00 2001 From: Jonathan Yong<10wa...@gmail.com> Date: Tue, 14 Feb 2023 10:29:05 + Subject: [PATCH 1/2] gcc/testsuite/gcc.dg: fix LLP64 targets gcc/testsuite/ChangeLog: * gcc.dg/builtins-69.c: Use (long )*regex pattern to allow long long instead of just long. * gcc.dg/pr80163.c: use __INTPTR_TYPE__ for LLP64 tagets. OK with the trivial ChangeLog fix use->Use for the change to pr80163.c. jeff OK.
Re: Patch ping: [PATCH] cygwin: Don't try to support multilibs [PR107998]
On 3/10/23 09:37, Jakub Jelinek wrote: Hi! I'd like to ping this patch (as I wrote a week ago, NightStrike has tested it): Thanks, pushed to master branch.
Re: Enable UTF-8 code page in driver and compiler on 64-bit mingw host [PR108865]
On 3/9/23 13:33, Costas Argyris wrote: Pinging the list and mingw maintainer. Analysis and pre-approval here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 Thanks, pushed to master branch.
Re: [Patch] gcc.dg/memchr-3.c: fix for LLP64
On 3/2/23 10:46, Richard Sandiford wrote:
diff --git a/gcc/testsuite/gcc.dg/memchr-3.c b/gcc/testsuite/gcc.dg/memchr-3.c
index c38d9cf3349..af1b26ef3ae 100644
--- a/gcc/testsuite/gcc.dg/memchr-3.c
+++ b/gcc/testsuite/gcc.dg/memchr-3.c
@@ -6,7 +6,7 @@
typedef __INT8_TYPE__ int8_t;
typedef __INT32_TYPE__ int32_t;
-extern void* memchr (const void*, int, long);
+extern void* memchr (const void*, int, long); /* { dg-warning
"-Wbuiltin-declaration-mismatch" { target llp64 } } */
struct SX
{
OK, thanks.
Richard
Thanks, pushed to master branch.
Re: [Patch] gcc.dg/overflow-warn-9.c: exclude from LLP64
On 3/2/23 10:44, Richard Sandiford wrote:
diff --git a/gcc/testsuite/gcc.dg/overflow-warn-9.c
b/gcc/testsuite/gcc.dg/overflow-warn-9.c
index 57c0f17bc91..ae588bd8491 100644
--- a/gcc/testsuite/gcc.dg/overflow-warn-9.c
+++ b/gcc/testsuite/gcc.dg/overflow-warn-9.c
@@ -59,7 +59,8 @@ const struct Types t1 = {
.ui = UINT_MAX + 1L, /* { dg-warning "signed conversion from .long int. to .unsigned
int. changes value from .4294967296. to .0." "lp64" { target lp64 } } */
.ui = UINT_MAX + 1LU, /* { dg-warning "conversion from .long unsigned int. to
.unsigned int. changes value from .4294967296. to .0." "lp64" { target lp64 } } */
- .sl = LONG_MAX + 1LU, /* { dg-warning "signed conversion from .long unsigned int. to .long int. changes value from .9223372036854775808. to .-9223372036854775808." "not-ilp32" { target { ! ilp32 } } } */
+ .sl = LONG_MAX + 1LU, /* { dg-warning "signed conversion from .long unsigned int. to
.long int. changes value from .9223372036854775808. to .-9223372036854775808."
"lp64" { target lp64 } } */
/* { dg-warning "signed conversion from .long unsigned int. to .long int. changes value
from .2147483648. to .-2147483648." "ilp32" { target ilp32 } .-1 } */
+ /* { dg-warning "signed conversion from .long unsigned int. to .long int. changes value
from .2147483648. to .-2147483648." "llp64" { target llp64 } .-2 } */
.ul = ULONG_MAX + 1LU /* there should be some warning here */
};
OK, although in general I think would be good to use
{ target { ilp32 || llp64 } } for this kind of thing.
No need to change this patch though, just saying for the future.
Thanks for reviewing, how does the "ilp32" or "llp64" before the curly
target brackets work?
Pushed existing patch to master branch.
Re: [PATCH] gcc: Remove size limit of PCH for *-*-mingw32 hosts
On 3/1/23 09:21, Richard Biener wrote: On Wed, Mar 1, 2023 at 9:52 AM NightStrike via Gcc-patches wrote: On Thu, Feb 16, 2023, 11:10 LIU Hao via Gcc-patches wrote: -- Best regards, LIU Hao Ping OK. Done, pushed to master branch.
Re: [Patch] harden-sls-6.c: fix warning on LLP64
On 2/28/23 18:15, Jakub Jelinek wrote: On Wed, Feb 15, 2023 at 01:44:08PM +, Jonathan Yong via Gcc-patches wrote: gcc/testsuite/ChangeLog: * gcc.target/i386/harden-sls-6.c: fix warning on LLP64 targets. Attached patch OK? From c0572a1e95c6f569980d6b7454c8dc293f07389e Mon Sep 17 00:00:00 2001 From: Jonathan Yong <10wa...@gmail.com> Date: Wed, 15 Feb 2023 13:42:12 + Subject: [PATCH] harden-sls-6.c: fix warning on LLP64 gcc/testsuite/ChangeLog: * gcc.target/i386/harden-sls-6.c: fix warning on LLP64 targets. s/fix/Fix/ Otherwise LGTM. Pushed to master branch, thanks.
Re: [Patch] gcc.dg/memchr-3.c: fix for LLP64
On 2/27/23 16:55, Richard Sandiford wrote:
Jonathan Yong via Gcc-patches writes:
Attached patch OK?
gcc.dg/memchr-3.c: fix for LLP64
gcc/testsuite/ChangeLog:
PR middle-end/97956
* gcc.dg/memchr-3.c (memchr): fix long to size_t in
prototype.
From 194eb3d43964276beeaea14ebee4b241799cd966 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Mon, 27 Feb 2023 10:02:32 +
Subject: [PATCH] gcc.dg/memchr-3.c: fix for LLP64
gcc/testsuite/ChangeLog:
PR middle-end/97956
* gcc.dg/memchr-3.c (memchr): fix long to size_t in
prototype.
It looks like the current type signature could have been a deliberate
part of the test. I think we should just skip it for LLP64 instead.
Preapproved if you agree.
Thanks,
Richard
Revised, account for the warning in LLP64.
From 2dbfa538fe11c65914b28f94d066daee789f881a Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Mon, 27 Feb 2023 10:02:32 +
Subject: [PATCH 6/7] gcc.dg/memchr-3.c: Account for LLP64 warnings
gcc/testsuite/ChangeLog:
PR middle-end/97956
* gcc.dg/memchr-3.c (memchr): Account for LLP64 warnings.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/testsuite/gcc.dg/memchr-3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/memchr-3.c b/gcc/testsuite/gcc.dg/memchr-3.c
index c38d9cf3349..af1b26ef3ae 100644
--- a/gcc/testsuite/gcc.dg/memchr-3.c
+++ b/gcc/testsuite/gcc.dg/memchr-3.c
@@ -6,7 +6,7 @@
typedef __INT8_TYPE__ int8_t;
typedef __INT32_TYPE__ int32_t;
-extern void* memchr (const void*, int, long);
+extern void* memchr (const void*, int, long); /* { dg-warning "-Wbuiltin-declaration-mismatch" { target llp64 } } */
struct SX
{
--
2.39.2
Re: [Patch] gcc.dg/overflow-warn-9.c: exclude from LLP64
On 2/28/23 03:06, Hans-Peter Nilsson wrote:
On Mon, 27 Feb 2023, Jonathan Yong via Gcc-patches wrote:
This test is for LP64 only, exclude LLP64 too.
Patch OK?
I may be confused, but you're not making use of the "llp64"
effective target, there instead excluding/including lp64 /
ilp32 in sets that not obviously mean "exclude LLP64".
To wit, how is "! ilp32" -> "lp64" and "ilp32" -> "! lp64"
expressing "! llp64"?
brgds, H-P
Attached new version, hopefully it is clearer.
From 91102d00dc701a65dfac5820a2bc57e1e4bed5b2 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Mon, 27 Feb 2023 09:49:31 +
Subject: [PATCH 5/7] gcc.dg/overflow-warn-9.c: Fix LLP64
gcc/testsuite/ChangeLog:
* gcc.dg/overflow-warn-9.c: Add LLP64 case.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/testsuite/gcc.dg/overflow-warn-9.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/overflow-warn-9.c b/gcc/testsuite/gcc.dg/overflow-warn-9.c
index 57c0f17bc91..ae588bd8491 100644
--- a/gcc/testsuite/gcc.dg/overflow-warn-9.c
+++ b/gcc/testsuite/gcc.dg/overflow-warn-9.c
@@ -59,7 +59,8 @@ const struct Types t1 = {
.ui = UINT_MAX + 1L, /* { dg-warning "signed conversion from .long int. to .unsigned int. changes value from .4294967296. to .0." "lp64" { target lp64 } } */
.ui = UINT_MAX + 1LU, /* { dg-warning "conversion from .long unsigned int. to .unsigned int. changes value from .4294967296. to .0." "lp64" { target lp64 } } */
- .sl = LONG_MAX + 1LU, /* { dg-warning "signed conversion from .long unsigned int. to .long int. changes value from .9223372036854775808. to .-9223372036854775808." "not-ilp32" { target { ! ilp32 } } } */
+ .sl = LONG_MAX + 1LU, /* { dg-warning "signed conversion from .long unsigned int. to .long int. changes value from .9223372036854775808. to .-9223372036854775808." "lp64" { target lp64 } } */
/* { dg-warning "signed conversion from .long unsigned int. to .long int. changes value from .2147483648. to .-2147483648." "ilp32" { target ilp32 } .-1 } */
+ /* { dg-warning "signed conversion from .long unsigned int. to .long int. changes value from .2147483648. to .-2147483648." "llp64" { target llp64 } .-2 } */
.ul = ULONG_MAX + 1LU /* there should be some warning here */
};
--
2.39.2
Re: [Patch] gcc.c-torture/compile/103818.c: enable for llp64 too
On 2/28/23 02:10, Hans-Peter Nilsson wrote:
On Sun, 26 Feb 2023, Jonathan Yong via Gcc-patches wrote:
Patch OK for master branch? I did not see any obvious issues to exclude LLP64
specifically.
I see "lp64 || lp64" in that patch (which should preferably have
been sent inline, as it's harder to quote an attached patch,
QED). Sending the wrong version? Don't forget to test it.
brgds, H-P
Corrected, previous patch was manually applied from a corrupted patch file.
From 52b1209193260a624f90c3ca759a83b975c2e8e0 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Sun, 26 Feb 2023 06:34:04 +
Subject: [PATCH 4/7] gcc.c-torture/compile/103818.c: enable for llp64 too
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/103818.c: enable test for llp64.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/testsuite/gcc.c-torture/compile/103818.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.c-torture/compile/103818.c b/gcc/testsuite/gcc.c-torture/compile/103818.c
index e6cbe7860cf..57f56b6c09d 100644
--- a/gcc/testsuite/gcc.c-torture/compile/103818.c
+++ b/gcc/testsuite/gcc.c-torture/compile/103818.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target lp64 } } */
+/* { dg-do compile { target { lp64 || llp64 } } } */
struct A { int b[1]; };
void
--
2.39.2
[Patch] c-c++-common/Warray-bounds.c: fix excess warnings on LLP64
Attached patch OK?
Excess errors on x86_64-w64-mingw32:
/home/user/p/gcc/src/gcc-git/gcc/testsuite/c-c++-common/Warray-bounds.c:50:3:
warning: array subscript 4611686018427387902 is above array bounds of 'struct
S16[]' [-Warray-bounds=]
/home/user/p/gcc/src/gcc-git/gcc/testsuite/c-c++-common/Warray-bounds.c:55:3:
warning: array subscript 4611686018427387902 is above array bounds of 'struct
S16[]' [-Warray-bounds=]
/home/user/p/gcc/src/gcc-git/gcc/testsuite/c-c++-common/Warray-bounds.c:90:3:
warning: array subscript 658812288346769699 is above array bounds of 'struct
S16[][7]' [-Warray-bounds=]
gcc/testsuite/ChangeLog:
* c-c++-common/Warray-bounds.c: Fix excess warnings on
LLP64.From 559c2ee7cf208227e8d6c4cf7106815e45b10590 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Mon, 27 Feb 2023 10:20:52 +
Subject: [PATCH] c-c++-common/Warray-bounds.c: fix excess warnings on LLP64
Excess errors on x86_64-w64-mingw32:
/home/user/p/gcc/src/gcc-git/gcc/testsuite/c-c++-common/Warray-bounds.c:50:3: warning: array subscript 4611686018427387902 is above array bounds of 'struct S16[]' [-Warray-bounds=]
/home/user/p/gcc/src/gcc-git/gcc/testsuite/c-c++-common/Warray-bounds.c:55:3: warning: array subscript 4611686018427387902 is above array bounds of 'struct S16[]' [-Warray-bounds=]
/home/user/p/gcc/src/gcc-git/gcc/testsuite/c-c++-common/Warray-bounds.c:90:3: warning: array subscript 658812288346769699 is above array bounds of 'struct S16[][7]' [-Warray-bounds=]
gcc/testsuite/ChangeLog:
* c-c++-common/Warray-bounds.c: Fix excess warnings on
LLP64.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/testsuite/c-c++-common/Warray-bounds.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/c-c++-common/Warray-bounds.c b/gcc/testsuite/c-c++-common/Warray-bounds.c
index 815badc0241..ce5827d6e2c 100644
--- a/gcc/testsuite/c-c++-common/Warray-bounds.c
+++ b/gcc/testsuite/c-c++-common/Warray-bounds.c
@@ -47,12 +47,12 @@ void farr_s16 (void)
T (ax[-1]); /* { dg-warning "array subscript -1 is below array bounds" } */
T (ax[0]);
- T (ax[DIFF_MAX / 2 - 1]);
+ T (ax[DIFF_MAX / 2 - 1]); /* { dg-warning "array subscript \[0-9\]+ is above array bounds" "llp64" { target llp64 } } */
T (ax[DIFF_MAX / 2]); /* { dg-warning "array subscript \[0-9\]+ is above array bounds" } */
T (ax[DIFF_MAX / 2 + (size_t)1]); /* { dg-warning "array subscript \[0-9\]+ is above array bounds" } */
T (ax[SIZE_MAX]); /* { dg-warning "array subscript \[0-9\]+ is above array bounds" } */
T (ax[R (DIFF_MIN, -1)]); /* { dg-warning "array subscript -1 is below array bounds" } */
- T (ax[R (DIFF_MAX / 2 - 1, DIFF_MAX)]);
+ T (ax[R (DIFF_MAX / 2 - 1, DIFF_MAX)]); /* { dg-warning "array subscript \[0-9\]+ is above array bounds" "llp64" { target llp64 } } */
T (ax[R (DIFF_MAX / 2, DIFF_MAX)]); /* { dg-warning "array subscript \[0-9\]+ is above array bounds" } */
}
@@ -87,7 +87,7 @@ void farr_s16_7 (void)
T (ax_7[R (-1, DIFF_MAX)][0]);
T (ax_7[R ( 1, DIFF_MAX)][0]);
- T (ax_7[R (DIFF_MAX / 14 - 1, DIFF_MAX)][0]);
+ T (ax_7[R (DIFF_MAX / 14 - 1, DIFF_MAX)][0]); /* { dg-warning "array subscript \[0-9\]+ is above array bounds" "llp64" { target llp64 } } */
i = R (DIFF_MAX / 14, DIFF_MAX);
T (ax_7[i][0]); /* { dg-warning "array subscript \[0-9\]+ is above array bounds" } */
@@ -199,7 +199,7 @@ void fb (struct B *p)
void f_cststring (int i)
{
- T (""[DIFF_MIN]); /* { dg-warning "array subscript -\[0-9\]+ is below array bounds of .(const )?char *\\\[1]" "string" { xfail lp64 } } */
+ T (""[DIFF_MIN]); /* { dg-warning "array subscript -\[0-9\]+ is below array bounds of .(const )?char *\\\[1]" "string" { xfail { lp64 || llp64 } } } */
T (""[DIFF_MIN + 1]); /* { dg-warning "array subscript -\[0-9\]+ is below array bounds of .(const )?char *\\\[1]" "string" } */
T (""[-1]); /* { dg-warning "array subscript -1 is below array bounds of .(const )?char *\\\[1]" "string" } */
T (""[0]);
--
2.39.2
[Patch] gcc.dg/memchr-3.c: fix for LLP64
Attached patch OK?
gcc.dg/memchr-3.c: fix for LLP64
gcc/testsuite/ChangeLog:
PR middle-end/97956
* gcc.dg/memchr-3.c (memchr): fix long to size_t in
prototype.
From 194eb3d43964276beeaea14ebee4b241799cd966 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Mon, 27 Feb 2023 10:02:32 +
Subject: [PATCH] gcc.dg/memchr-3.c: fix for LLP64
gcc/testsuite/ChangeLog:
PR middle-end/97956
* gcc.dg/memchr-3.c (memchr): fix long to size_t in
prototype.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/testsuite/gcc.dg/memchr-3.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/memchr-3.c b/gcc/testsuite/gcc.dg/memchr-3.c
index c38d9cf3349..c1f4e9e10dc 100644
--- a/gcc/testsuite/gcc.dg/memchr-3.c
+++ b/gcc/testsuite/gcc.dg/memchr-3.c
@@ -5,8 +5,9 @@
typedef __INT8_TYPE__ int8_t;
typedef __INT32_TYPE__ int32_t;
+typedef __SIZE_TYPE__ size_t;
-extern void* memchr (const void*, int, long);
+extern void* memchr (const void*, int, size_t);
struct SX
{
--
2.39.2
[Patch] gcc.dg/overflow-warn-9.c: exclude from LLP64
This test is for LP64 only, exclude LLP64 too.
Patch OK?From fbc83ae10df1a0e10c302fb0fee13092eb65818e Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Mon, 27 Feb 2023 09:49:31 +
Subject: [PATCH] gcc.dg/overflow-warn-9.c: exclude from LLP64
gcc/testsuite/ChangeLog:
* gcc.dg/overflow-warn-9.c: Exclude from LLP64.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/testsuite/gcc.dg/overflow-warn-9.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/overflow-warn-9.c b/gcc/testsuite/gcc.dg/overflow-warn-9.c
index 57c0f17bc91..012892dd343 100644
--- a/gcc/testsuite/gcc.dg/overflow-warn-9.c
+++ b/gcc/testsuite/gcc.dg/overflow-warn-9.c
@@ -59,7 +59,7 @@ const struct Types t1 = {
.ui = UINT_MAX + 1L, /* { dg-warning "signed conversion from .long int. to .unsigned int. changes value from .4294967296. to .0." "lp64" { target lp64 } } */
.ui = UINT_MAX + 1LU, /* { dg-warning "conversion from .long unsigned int. to .unsigned int. changes value from .4294967296. to .0." "lp64" { target lp64 } } */
- .sl = LONG_MAX + 1LU, /* { dg-warning "signed conversion from .long unsigned int. to .long int. changes value from .9223372036854775808. to .-9223372036854775808." "not-ilp32" { target { ! ilp32 } } } */
- /* { dg-warning "signed conversion from .long unsigned int. to .long int. changes value from .2147483648. to .-2147483648." "ilp32" { target ilp32 } .-1 } */
+ .sl = LONG_MAX + 1LU, /* { dg-warning "signed conversion from .long unsigned int. to .long int. changes value from .9223372036854775808. to .-9223372036854775808." "lp64" { target lp64 } } */
+ /* { dg-warning "signed conversion from .long unsigned int. to .long int. changes value from .2147483648. to .-2147483648." "not-lp64" { target { ! lp64 } } .-1 } */
.ul = ULONG_MAX + 1LU /* there should be some warning here */
};
--
2.39.2
[Patch] gcc.c-torture/compile/103818.c: enable for llp64 too
Patch OK for master branch? I did not see any obvious issues to exclude
LLP64 specifically.From 9c770936c4c6ffb59d15e5c1ce331494ba102250 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Sun, 26 Feb 2023 06:34:04 +
Subject: [PATCH] gcc.c-torture/compile/103818.c: enable for llp64 too
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/103818.c: enable test for llp64.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/testsuite/gcc.c-torture/compile/103818.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.c-torture/compile/103818.c b/gcc/testsuite/gcc.c-torture/compile/103818.c
index e6cbe7860cf..63090534f4c 100644
--- a/gcc/testsuite/gcc.c-torture/compile/103818.c
+++ b/gcc/testsuite/gcc.c-torture/compile/103818.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target lp64 } } */
+/* { dg-do compile { target { lp64 || lp64 } } } */
struct A { int b[1]; };
void
--
2.39.2
Re: [PATCH] cygwin: Don't try to support multilibs [PR107998]
On 2/22/23 09:25, Jakub Jelinek wrote:
Hi!
As discussed in the PR, t-cygwin-w64 file has been introduced in 2013
and has one important problem, two different multilib options -m64 and -m32,
but MULTILIB_DIRNAMES with just one word in it.
Before the genmultilib sanity checking was added, my understanding is that
this essentially resulted in effective --disable-multilib,
$ gcc -print-multi-lib
.;
;@m32
$ gcc -print-multi-directory
.
$ gcc -print-multi-directory -m64
.
$ gcc -print-multi-directory -m32
$ gcc -print-multi-os-directory
../lib
$ gcc -print-multi-os-directory -m64
../lib
$ gcc -print-multi-os-directory -m32
../lib32
and because of the way e.g. config-ml.in operates
multidirs=
for i in `${CC-gcc} --print-multi-lib 2>/dev/null`; do
dir=`echo $i | sed -e 's/;.*$//'`
if [ "${dir}" = "." ]; then
true
else
if [ -z "${multidirs}" ]; then
multidirs="${dir}"
else
multidirs="${multidirs} ${dir}"
fi
fi
done
dir was . first time (and so nothing was done) and empty
second time, multidirs empty too, so multidirs was set to empty
like it would be with --disable-multilib.
With the added sanity checking the build fails unless --disable-multilib
is used in configure (dunno whether people usually configure that way
on cygwin).
From what has been said in the PR, multilibs were not meant to be supported
and e.g. cygwin headers probably aren't ready for it.
So the following patch just removes the file with the (incorrect) multilib
stuff instead of fixing it (say by setting MULTILIB_DIRNAMES to 64 32).
I have no way to test this though, no Windows around, can anyone please
test this? I just would like to get some progress on the P1s we have...
2023-02-22 Jakub Jelinek
PR target/107998
* config.gcc (x86_64-*-cygwin*): Don't add i386/t-cygwin-w64 into
$tmake_file.
* config/i386/t-cygwin-w64: Remove.
--- gcc/config.gcc.jj 2023-02-18 12:38:30.803025062 +0100
+++ gcc/config.gcc 2023-02-21 17:07:12.143164563 +0100
@@ -2105,7 +2105,7 @@ x86_64-*-cygwin*)
need_64bit_isa=yes
tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h i386/cygming.h
i386/cygwin.h i386/cygwin-w64.h i386/cygwin-stdint.h"
xm_file=i386/xm-cygwin.h
- tmake_file="${tmake_file} i386/t-cygming t-slibgcc i386/t-cygwin-w64"
+ tmake_file="${tmake_file} i386/t-cygming t-slibgcc"
target_gtfiles="$target_gtfiles \$(srcdir)/config/i386/winnt.cc"
extra_options="${extra_options} i386/cygming.opt i386/cygwin.opt"
extra_objs="${extra_objs} winnt.o winnt-stubs.o"
--- gcc/config/i386/t-cygwin-w64.jj 2020-01-12 11:54:36.333414616 +0100
+++ gcc/config/i386/t-cygwin-w642023-02-21 17:06:44.121572616 +0100
@@ -1,3 +0,0 @@
-MULTILIB_OPTIONS = m64/m32
-MULTILIB_DIRNAMES = 64
-MULTILIB_OSDIRNAMES = ../lib ../lib32
Jakub
Achim, mind looking at this?
Resending due to mail client problems, hopefully not a duplicate.
Re: [PATCH] cygwin: Don't try to support multilibs [PR107998]
On 2/22/23 09:25, Jakub Jelinek wrote:
Hi!
As discussed in the PR, t-cygwin-w64 file has been introduced in 2013
and has one important problem, two different multilib options -m64 and -m32,
but MULTILIB_DIRNAMES with just one word in it.
Before the genmultilib sanity checking was added, my understanding is that
this essentially resulted in effective --disable-multilib,
$ gcc -print-multi-lib
.;
;@m32
$ gcc -print-multi-directory
.
$ gcc -print-multi-directory -m64
.
$ gcc -print-multi-directory -m32
$ gcc -print-multi-os-directory
../lib
$ gcc -print-multi-os-directory -m64
../lib
$ gcc -print-multi-os-directory -m32
../lib32
and because of the way e.g. config-ml.in operates
multidirs=
for i in `${CC-gcc} --print-multi-lib 2>/dev/null`; do
dir=`echo $i | sed -e 's/;.*$//'`
if [ "${dir}" = "." ]; then
true
else
if [ -z "${multidirs}" ]; then
multidirs="${dir}"
else
multidirs="${multidirs} ${dir}"
fi
fi
done
dir was . first time (and so nothing was done) and empty
second time, multidirs empty too, so multidirs was set to empty
like it would be with --disable-multilib.
With the added sanity checking the build fails unless --disable-multilib
is used in configure (dunno whether people usually configure that way
on cygwin).
From what has been said in the PR, multilibs were not meant to be supported
and e.g. cygwin headers probably aren't ready for it.
So the following patch just removes the file with the (incorrect) multilib
stuff instead of fixing it (say by setting MULTILIB_DIRNAMES to 64 32).
I have no way to test this though, no Windows around, can anyone please
test this? I just would like to get some progress on the P1s we have...
2023-02-22 Jakub Jelinek
PR target/107998
* config.gcc (x86_64-*-cygwin*): Don't add i386/t-cygwin-w64 into
$tmake_file.
* config/i386/t-cygwin-w64: Remove.
--- gcc/config.gcc.jj 2023-02-18 12:38:30.803025062 +0100
+++ gcc/config.gcc 2023-02-21 17:07:12.143164563 +0100
@@ -2105,7 +2105,7 @@ x86_64-*-cygwin*)
need_64bit_isa=yes
tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h i386/cygming.h
i386/cygwin.h i386/cygwin-w64.h i386/cygwin-stdint.h"
xm_file=i386/xm-cygwin.h
- tmake_file="${tmake_file} i386/t-cygming t-slibgcc i386/t-cygwin-w64"
+ tmake_file="${tmake_file} i386/t-cygming t-slibgcc"
target_gtfiles="$target_gtfiles \$(srcdir)/config/i386/winnt.cc"
extra_options="${extra_options} i386/cygming.opt i386/cygwin.opt"
extra_objs="${extra_objs} winnt.o winnt-stubs.o"
--- gcc/config/i386/t-cygwin-w64.jj 2020-01-12 11:54:36.333414616 +0100
+++ gcc/config/i386/t-cygwin-w642023-02-21 17:06:44.121572616 +0100
@@ -1,3 +0,0 @@
-MULTILIB_OPTIONS = m64/m32
-MULTILIB_DIRNAMES = 64
-MULTILIB_OSDIRNAMES = ../lib ../lib32
Jakub
Achim,
Mind checking this out?
[Patch] harden-sls-6.c: fix warning on LLP64
gcc/testsuite/ChangeLog:
* gcc.target/i386/harden-sls-6.c: fix warning on LLP64
targets.
Attached patch OK?From c0572a1e95c6f569980d6b7454c8dc293f07389e Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Wed, 15 Feb 2023 13:42:12 +
Subject: [PATCH] harden-sls-6.c: fix warning on LLP64
gcc/testsuite/ChangeLog:
* gcc.target/i386/harden-sls-6.c: fix warning on LLP64
targets.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/testsuite/gcc.target/i386/harden-sls-6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/harden-sls-6.c b/gcc/testsuite/gcc.target/i386/harden-sls-6.c
index 9068eb64008..3b270211927 100644
--- a/gcc/testsuite/gcc.target/i386/harden-sls-6.c
+++ b/gcc/testsuite/gcc.target/i386/harden-sls-6.c
@@ -11,7 +11,7 @@ struct _Unwind_Context {
struct _Unwind_Context cur_contextcur_context =
_Unwind_Resume_or_Rethrow_this_context;
offset(0);
- __builtin_eh_return ((long) offset, 0);
+ __builtin_eh_return ((__INTPTR_TYPE__) offset, 0);
}
/* { dg-final { scan-assembler "jmp\[ \t\]+\\*%rcx" } } */
--
2.39.2
[Patch] More LLP64 fixes and __PIC__ values fixes for PE targets
Attached patches OK?From 616e43ac41879040e73a266065874148553cddcc Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Tue, 14 Feb 2023 10:37:03 +
Subject: [PATCH 2/2] gcc/testsuite/gcc.dg: fix pic test case for PE targets
gcc/testsuite/ChangeLog:
* pic-2.c: fix expected __PIC__ value.
* pic-3.c: ditto.
* pic-4.c: ditto.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/testsuite/gcc.dg/pic-2.c | 6 +-
gcc/testsuite/gcc.dg/pic-3.c | 6 +-
gcc/testsuite/gcc.dg/pic-4.c | 6 +-
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/pic-2.c b/gcc/testsuite/gcc.dg/pic-2.c
index 3846ec4ff47..24260538cc0 100644
--- a/gcc/testsuite/gcc.dg/pic-2.c
+++ b/gcc/testsuite/gcc.dg/pic-2.c
@@ -4,7 +4,11 @@
/* { dg-skip-if "__PIC__ is always 1 for MIPS" { mips*-*-* } } */
/* { dg-skip-if "__PIE__ is always defined for GCN" { amdgcn*-*-* } } */
-#if __PIC__ != 2
+#if defined(__CYGWIN__) || defined(__WIN32__)
+# if __PIC__ != 1
+# error __PIC__ is not 1!
+# endif
+#elif __PIC__ != 2
# error __PIC__ is not 2!
#endif
diff --git a/gcc/testsuite/gcc.dg/pic-3.c b/gcc/testsuite/gcc.dg/pic-3.c
index 1397977e7f8..d3eb120652a 100644
--- a/gcc/testsuite/gcc.dg/pic-3.c
+++ b/gcc/testsuite/gcc.dg/pic-3.c
@@ -1,7 +1,11 @@
/* { dg-do compile { target { ! { *-*-darwin* hppa*64*-*-* mips*-*-linux-* amdgcn*-*-* } } } } */
/* { dg-options "-fno-pic" } */
-#ifdef __PIC__
+#if defined(__CYGWIN__) || defined(__WIN32__)
+# if __PIC__ != 1
+# error __PIC__ is not 1!
+# endif
+#elif __PIC__
# error __PIC__ is defined!
#endif
diff --git a/gcc/testsuite/gcc.dg/pic-4.c b/gcc/testsuite/gcc.dg/pic-4.c
index d6d9dc90046..d7acefaf9aa 100644
--- a/gcc/testsuite/gcc.dg/pic-4.c
+++ b/gcc/testsuite/gcc.dg/pic-4.c
@@ -1,7 +1,11 @@
/* { dg-do compile { target { ! { *-*-darwin* hppa*64*-*-* mips*-*-linux-* amdgcn*-*-* } } } } */
/* { dg-options "-fno-PIC" } */
-#ifdef __PIC__
+#if defined(__CYGWIN__) || defined(__WIN32__)
+# if __PIC__ != 1
+# error __PIC__ is not 1!
+# endif
+#elif __PIC__
# error __PIC__ is defined!
#endif
--
2.39.1
From a1fafc5a3c70684e843f5f0b6cf392ce349cb6b0 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Tue, 14 Feb 2023 10:29:05 +
Subject: [PATCH 1/2] gcc/testsuite/gcc.dg: fix LLP64 targets
gcc/testsuite/ChangeLog:
* gcc.dg/builtins-69.c: Use (long )*regex pattern to
allow long long instead of just long.
* gcc.dg/pr80163.c: use __INTPTR_TYPE__ for LLP64 tagets.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/testsuite/gcc.dg/builtins-69.c | 2 +-
gcc/testsuite/gcc.dg/pr80163.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/builtins-69.c b/gcc/testsuite/gcc.dg/builtins-69.c
index 26dfb3bfc1b..b754b5d26ee 100644
--- a/gcc/testsuite/gcc.dg/builtins-69.c
+++ b/gcc/testsuite/gcc.dg/builtins-69.c
@@ -14,7 +14,7 @@ int test_index (void)
/* PR middle-end/86202 - ICE in get_range_info calling an invalid memcpy()
declaration */
-void *memcpy (void *, void *, __SIZE_TYPE__ *); /* { dg-warning "conflicting types for built-in function .memcpy.; expected .void \\\*\\\(void \\\*, const void \\\*, \(long \)?unsigned int\\\)." } */
+void *memcpy (void *, void *, __SIZE_TYPE__ *); /* { dg-warning "conflicting types for built-in function .memcpy.; expected .void \\\*\\\(void \\\*, const void \\\*, \(long \)*unsigned int\\\)." } */
void test_memcpy (void *p, void *q, __SIZE_TYPE__ *r)
{
diff --git a/gcc/testsuite/gcc.dg/pr80163.c b/gcc/testsuite/gcc.dg/pr80163.c
index 37a7abd1181..f65955c0ec9 100644
--- a/gcc/testsuite/gcc.dg/pr80163.c
+++ b/gcc/testsuite/gcc.dg/pr80163.c
@@ -2,6 +2,7 @@
/* { dg-do compile { target int128 } } */
/* { dg-options "-O0" } */
+typedef __INTPTR_TYPE__ intptr_t;
void bar (void);
__int128_t *
@@ -10,7 +11,7 @@ foo (void)
a:
bar ();
b:;
- static __int128_t d = (long) &&a - (long) &&b; /* { dg-error "initializer element is not computable at load time" } */
+ static __int128_t d = (intptr_t) &&a - (intptr_t) &&b; /* { dg-error "initializer element is not computable at load time" } */
return &d;
}
--
2.39.1
Re: [Patch] pr65658.c: fix excess warnings on LLP64 targets
On 2/13/23 07:04, Jeff Law wrote: On 1/28/23 11:16, Jonathan Yong via Gcc-patches wrote: Patch OK? gcc/testsuite/ChangeLog: * gcc.dg/pr65658.c: fix LLP64 test. 0001-pr65658.c-fix-excess-warnings-on-LLP64-targets.patch From bd2634e2795723f290dcf4bbb06e70fb6ca6af51 Mon Sep 17 00:00:00 2001 From: Jonathan Yong<10wa...@gmail.com> Date: Sat, 28 Jan 2023 18:12:50 + Subject: [PATCH] pr65658.c: fix excess warnings on LLP64 targets gcc/testsuite/ChangeLog: * gcc.dg/pr65658.c: fix LLP64 test. OK. jeff Thanks pushed to master branch 391f29e60a95335c925040641e99ddef57edac6d.
Re: [Patch] builtin-declaration-mismatch-7: fix LLP64 targets
On 2/13/23 06:28, Jeff Law wrote: On 2/11/23 01:33, Jonathan Yong via Gcc-patches wrote: Attached patch OK? 0001-builtin-declaration-mismatch-7-fix-LLP64-targets.patch From 3ba6812366e837a87c15360e83d1f72ffdd29684 Mon Sep 17 00:00:00 2001 From: Jonathan Yong<10wa...@gmail.com> Date: Sat, 11 Feb 2023 08:30:55 + Subject: [PATCH] builtin-declaration-mismatch-7: fix LLP64 targets gcc/testsuite/ChangeLog: * gcc.dg/Wbuiltin-declaration-mismatch-7.c: Use (long )* regex pattern to allow long long instead of just long. OK. Go ahead and install. Thanks, Jeff Thanks for reviewing, pushed to master branch.
Re: realpath() patch to fix symlinks resolution for win32
On 2/11/23 08:52, Gerald Pfeifer wrote: On Sat, 11 Feb 2023, Jonathan Yong via Gcc-patches wrote: could you please close the corresponding BR too?: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 I can't close it, but I put a note that it has been committed. I closed the report. Gerald Thanks.
Re: realpath() patch to fix symlinks resolution for win32
On 2/11/23 07:28, i.nix...@autistici.org wrote: Thank you Jonathan! could you please close the corresponding BR too?: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 best! I can't close it, but I put a note that it has been committed.
[Patch] builtin-declaration-mismatch-7: fix LLP64 targets
Attached patch OK?From 3ba6812366e837a87c15360e83d1f72ffdd29684 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Sat, 11 Feb 2023 08:30:55 +
Subject: [PATCH] builtin-declaration-mismatch-7: fix LLP64 targets
gcc/testsuite/ChangeLog:
* gcc.dg/Wbuiltin-declaration-mismatch-7.c: Use (long )*
regex pattern to allow long long instead of just long.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-7.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-7.c b/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-7.c
index 7f6644edb58..ba2fec9deee 100644
--- a/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-7.c
+++ b/gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-7.c
@@ -23,4 +23,4 @@ int fscanf (struct StdioFile*, const char*, size_t, ...); /* { dg-warning "con
int vfscanf (struct StdioFile*, const char*, ...); /* { dg-warning "conflicting types for built-in function .vfscanf.; expected .int\\\(\[a-z_\]+ \\\*, const char \\\*, \[^\n\r,\\\)\]+\\\)." } */
-size_t fwrite (const void*, size_t, size_t, struct StdioFile);/* { dg-warning "conflicting types for built-in function .fwrite.; expected .\(long \)?unsigned int\\\(const void \\\*, \(long \)?unsigned int, *\(long \)?unsigned int, *\[a-z_\]+ \\\*\\\)." } */
+size_t fwrite (const void*, size_t, size_t, struct StdioFile);/* { dg-warning "conflicting types for built-in function .fwrite.; expected .\(long \)*unsigned int\\\(const void \\\*, \(long \)*unsigned int, *\(long \)*unsigned int, *\[a-z_\]+ \\\*\\\)." } */
--
2.39.1
Re: realpath() patch to fix symlinks resolution for win32
On 2/6/23 06:40, Jonathan Yong wrote: On 1/18/23 10:44, i.nixman--- via Gcc-patches wrote: hello again! the final version of the path for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 successfully bootstraped for x86_64-mingw32 and x86_64-linux. could anyone apply it please? best! Looks good to me, please supply the appropriate changelog. Pushed to master.
Re: realpath() patch to fix symlinks resolution for win32
On 1/18/23 10:44, i.nixman--- via Gcc-patches wrote: hello again! the final version of the path for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 successfully bootstraped for x86_64-mingw32 and x86_64-linux. could anyone apply it please? best! Looks good to me, please supply the appropriate changelog.
[Patch] pr65658.c: fix excess warnings on LLP64 targets
Patch OK?
gcc/testsuite/ChangeLog:
* gcc.dg/pr65658.c: fix LLP64 test.From bd2634e2795723f290dcf4bbb06e70fb6ca6af51 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Sat, 28 Jan 2023 18:12:50 +
Subject: [PATCH] pr65658.c: fix excess warnings on LLP64 targets
gcc/testsuite/ChangeLog:
* gcc.dg/pr65658.c: fix LLP64 test.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/testsuite/gcc.dg/pr65658.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/pr65658.c b/gcc/testsuite/gcc.dg/pr65658.c
index bb5c37adbe3..4847dc2d5c7 100644
--- a/gcc/testsuite/gcc.dg/pr65658.c
+++ b/gcc/testsuite/gcc.dg/pr65658.c
@@ -16,10 +16,10 @@ struct undeffoo
};
struct problem
{
- unsigned long l1;
- unsigned long l2;
- unsigned long l3;
- unsigned long l4;
+ __UINTPTR_TYPE__ l1;
+ __UINTPTR_TYPE__ l2;
+ __UINTPTR_TYPE__ l3;
+ __UINTPTR_TYPE__ l4;
};
static unsigned int undef1, undef2, undef3, undef4, undef5, undef6;
static void *undefvp1;
@@ -37,7 +37,7 @@ undefinit1 (void)
}
static int
-undefinit2 (void *problemp, unsigned long problem)
+undefinit2 (void *problemp, __UINTPTR_TYPE__ problem)
{
int ret, u;
if (undefinit1 ())
@@ -60,7 +60,7 @@ fn6 (struct undefinfo *uip, struct problem *problem)
unsigned long amt;
if (external_function3 (((void *) 0), ((void *) 0), &amt, 0, 0))
return 1;
- problem->l1 = (unsigned long) undefvp1;
+ problem->l1 = (__UINTPTR_TYPE__) undefvp1;
problem->l4 = uip->l1;
problem->l3 = uip->l2;
return 0;
--
2.39.1
[Patch] Fix excess warnings for mingw-w64 (LLP64)
I'm not fully confident if it might break other platforms. So hopefully
someone can comment on the patch.
gcc/testsuite/ChangeLog:
* c-c++-common/Wsizeof-array-div1.c: fix excess warnings.
* gcc.dg/Warray-bounds-52.c: ditto
* gcc.dg/Wstringop-overflow-62.c: ditto
* gcc.dg/attr-vector_size.c: ditto
* gcc.dg/overflow-warn-9.c: ditto
Comments?From 209c55e5695e0124138b27057dac5329106f29be Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Sat, 28 Jan 2023 16:49:27 +
Subject: [PATCH] gcc/testsuite: fix excess warnings for mingw-w64
gcc/testsuite/ChangeLog:
* c-c++-common/Wsizeof-array-div1.c: fix excess warnings.
* gcc.dg/Warray-bounds-52.c: ditto
* gcc.dg/Wstringop-overflow-62.c: ditto
* gcc.dg/attr-vector_size.c: ditto
* gcc.dg/overflow-warn-9.c: ditto
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/testsuite/c-c++-common/Wsizeof-array-div1.c | 6 +++---
gcc/testsuite/gcc.dg/Warray-bounds-52.c | 2 +-
gcc/testsuite/gcc.dg/Wstringop-overflow-62.c| 2 +-
gcc/testsuite/gcc.dg/attr-vector_size.c | 4 ++--
gcc/testsuite/gcc.dg/overflow-warn-9.c | 2 +-
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/gcc/testsuite/c-c++-common/Wsizeof-array-div1.c b/gcc/testsuite/c-c++-common/Wsizeof-array-div1.c
index 6e01d6c87d1..068ce0145ca 100644
--- a/gcc/testsuite/c-c++-common/Wsizeof-array-div1.c
+++ b/gcc/testsuite/c-c++-common/Wsizeof-array-div1.c
@@ -13,12 +13,12 @@ fn (int ap[])
int r = 0;
r += sizeof (arr) / sizeof (*arr);
- r += sizeof (arr) / sizeof (p); /* { dg-warning "expression does not compute" "" { target { lp64 } } } */
- r += sizeof (arr) / sizeof p; /* { dg-warning "expression does not compute" "" { target { lp64 } } } */
+ r += sizeof (arr) / sizeof (p); /* { dg-warning "expression does not compute" "" { target { ! ilp32 } } } */
+ r += sizeof (arr) / sizeof p; /* { dg-warning "expression does not compute" "" { target { ! ilp32 } } } */
r += sizeof (arr) / (sizeof p);
r += sizeof (arr) / (sizeof (p));
r += sizeof (arr2) / sizeof p;
- r += sizeof (arr2) / sizeof (int); /* { dg-warning "expression does not compute" "" { target { lp64 } } } */
+ r += sizeof (arr2) / sizeof (int); /* { dg-warning "expression does not compute" "" { target { ! ilp32 } } } */
r += sizeof (arr2) / sizeof (int *);
r += sizeof (arr2) / sizeof (short *);
r += sizeof (arr) / sizeof (int);
diff --git a/gcc/testsuite/gcc.dg/Warray-bounds-52.c b/gcc/testsuite/gcc.dg/Warray-bounds-52.c
index c7217ad4f7b..69dc15ace2d 100644
--- a/gcc/testsuite/gcc.dg/Warray-bounds-52.c
+++ b/gcc/testsuite/gcc.dg/Warray-bounds-52.c
@@ -60,7 +60,7 @@ void ptr_idx_cst (void)
T ( 0, (int[]){ 1 });
T (+1, (int[]){ 1 }); // { dg-warning "array subscript 1 is outside array bounds of 'int\\\[1]'" }
T (INT_MIN, (int[]){ 1 });// { dg-warning "array subscript -\[0-9\]+ is outside array bounds of 'int\\\[1]'" "lp64" { xfail ilp32 } }
- T (INT_MAX, (int[]){ 1 });// { dg-warning "array subscript \[0-9\]+ is outside array bounds of 'int\\\[1]'" "lp64" { target lp64 } }
+ T (INT_MAX, (int[]){ 1 });// { dg-warning "array subscript \[0-9\]+ is outside array bounds of 'int\\\[1]'" "not-ilp32" { target { ! ilp32 } } }
// { dg-warning "array subscript -1 is outside array bounds of 'int\\\[1]'" "ilp32" { target ilp32 } .-1 }
T (SIZE_MAX, (int[]){ 1 }); // { dg-warning "array subscript -?\[0-9\]+ is outside array bounds of 'int\\\[1]'" }
}
diff --git a/gcc/testsuite/gcc.dg/Wstringop-overflow-62.c b/gcc/testsuite/gcc.dg/Wstringop-overflow-62.c
index ea19aa85905..d589f077887 100644
--- a/gcc/testsuite/gcc.dg/Wstringop-overflow-62.c
+++ b/gcc/testsuite/gcc.dg/Wstringop-overflow-62.c
@@ -41,7 +41,7 @@ void test_min (void)
memset (q, 0, DIFF_MAX - 2);
memset (q, 0, DIFF_MAX);
// { dg-warning "writing 2147483647 bytes into a region of size 2147483646" "ilp32" { target ilp32 } .-1 }
-// { dg-warning "writing 9223372036854775807 bytes into a region of size 9223372036854775806" "lp64" { target lp64 } .-2 }
+// { dg-warning "writing 9223372036854775807 bytes into a region of size 9223372036854775806" "not-ilp32" { target { ! ilp32 } } .-2 }
}
{
diff --git a/gcc/testsuite/gcc.dg/attr-vector_size.c b/gcc/testsuite/gcc.dg/attr-vector_size.c
index 3f2ce889121..9177e25250a 100644
--- a/gcc/testsuite/gcc.dg/attr-vector_size.c
+++ b/gcc/testsuite/gcc.dg/attr-vector_size.c
@@ -22,7 +22,7 @@ DEFVEC (extern, 30);
#if __SIZEOF_SIZE_T__ > 4
-VEC (POW2 (63)) char v63; /* { dg-error "'vector_size' attribute argument value '9223372036854775808' exceeds 9223372036854775807" "LP64" { target lp64 } } */
+VEC (POW2 (63)) char v63; /* { dg-error "'vector_size' attribute argument value '9223372036854775808' exceeds 9223372036854775807" "not-ILP32" { target { ! ilp32 } } } */
#else
@@ -41,7 +41,7 @@ void test_local_scope (void)
#i
Re: [Patch] Resolve bugzilla #108150 and #108192 for mingw
On 1/19/23 09:26, Jonathan Yong wrote: On 1/11/23 09:56, Jonathan Yong wrote: Are the patches and changelogs OK? Ping1. Pushed to master branch.
Re: [Patch] Resolve bugzilla #108150 and #108192 for mingw
On 1/11/23 09:56, Jonathan Yong wrote: Are the patches and changelogs OK? Ping1.
Re: [PATCH] libatomic: Use config/mingw/lock.c for --enable-threads=single
On 1/14/23 20:39, Jonathan Wakely wrote: OK for trunk? Looks OK to me, thanks for the patch.
Re: [PATCH] libstdc++: Fix unintended layout change to std::basic_filebuf [PR108331]
On 1/12/23 21:10, Jonathan Wakely wrote: Tested x86_64-linux. Bootstrapped x86_64-w64-mingw32 with both --enable-threads=posix and --enable-threads=win32. I need a libgcc or mingw maintainer to approve the gthr-win32.h part. OK for trunk? Looks good to me even if its a dummy member. Thanks for the patch.
[Patch] Resolve bugzilla #108150 and #108192 for mingw
Are the patches and changelogs OK?From 6edfba9e9a5f8fddc45d137b9f2d07c7f9065eaa Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Sun, 8 Jan 2023 01:28:34 +
Subject: [PATCH 1/2] PR c/108150 - Fix alignment test for Windows targets
gcc/testsuite/ChangeLog:
PR c/108150
* gcc.dg/attr-aligned.c: Make errors emitted on Windows
target same as on Linux.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/testsuite/gcc.dg/attr-aligned.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/testsuite/gcc.dg/attr-aligned.c b/gcc/testsuite/gcc.dg/attr-aligned.c
index a2e11c96180..887bdd0f379 100644
--- a/gcc/testsuite/gcc.dg/attr-aligned.c
+++ b/gcc/testsuite/gcc.dg/attr-aligned.c
@@ -22,6 +22,9 @@
# define ALIGN_MAX_STATIC 2
/* Work around a pdp11 ICE (see PR target/87821). */
# define ALIGN_MAX_AUTO(ALIGN_MAX_HARD >> 14)
+#elif __WIN32__ || __CYGWIN__
+# define ALIGN_MAX_STATIC 8192
+# define ALIGN_MAX_AUTO8192
#elif __powerpc64__ || __x86_64__
/* Is this processor- or operating-system specific? */
# define ALIGN_MAX_STATIC ALIGN_MAX_HARD
--
2.39.0
From 1c9781f7af30e600367682fe0e47128ea85552ab Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Wed, 11 Jan 2023 09:51:02 +
Subject: [PATCH 2/2] PR c/108192 - Fix test for mingw
gcc/testsuite/ChangeLog:
PR c/108192
* g++.dg/cet-notrack-1.C: Use puts instead of printf,
so function call is not mangled by __mingw_printf when
doing assembly symbol inspection.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/testsuite/g++.dg/cet-notrack-1.C | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/g++.dg/cet-notrack-1.C b/gcc/testsuite/g++.dg/cet-notrack-1.C
index ee98fd43d58..a19eed0fb82 100644
--- a/gcc/testsuite/g++.dg/cet-notrack-1.C
+++ b/gcc/testsuite/g++.dg/cet-notrack-1.C
@@ -18,8 +18,8 @@ B b;
A& a = b;
int (A::*amem) () __attribute__((nocf_check)) = &A::foo; // take address
if ((a.*amem)() == 73) // use the address
- printf("pass\n");
+ puts("pass\n");
else
- printf("fail\n");
+ puts("fail\n");
return 0;
}
--
2.39.0
Re: [PATCH] Always define `WIN32_LEAN_AND_MEAN` before
On 1/6/23 18:10, Jakub Jelinek wrote: On Sat, Jan 07, 2023 at 02:01:05AM +0800, LIU Hao via Gcc-patches wrote: libgomp/ PR middle-end/108300 * config/mingw32/proc.c: Define `WIN32_LEAN_AND_MEAN` before . This change is ok for trunk. Jakub Pushed to master branch, thanks LH.
Re: Adding a new thread model to GCC
On 12/24/22 21:22, i.nix...@autistici.org wrote: On 2022-12-24 15:57, i.nix...@autistici.org wrote: On 2022-12-24 15:42, i.nix...@autistici.org wrote: fixed and tested. Jonathan Yong, could you please apply the attached patch too? kings regards! oh no... please wait. fixed now. bootstrapped successfully! Jonathan Yong, could you please apply the attached patch too? best! Done, pushed to master, thanks.
Re: Adding a new thread model to GCC
On 12/22/22 12:28, i.nix...@autistici.org wrote: On 2022-12-22 12:21, Jonathan Yong wrote: hello, On 12/16/22 19:20, Eric Botcazou wrote: The libgcc parts look reasonable to me, but I can't approve them. Maybe Jonathan Yong can approve those parts as mingw-w64 target maintainer, or maybe a libgcc approver can do so. OK. The libstdc++ parts are OK for trunk. IIUC they could go in separately, they just wouldn't be very much use without the libgcc changes. Sure thing. Ping, need help to commit it? yes, it would be great if we can merge the path into gcc-13! I've tested it on gcc-12-branch and gcc-master for i686/x86_64 windows, with msvcrt and ucrt runtime - works as it should! Eric ^^^ best! Done, pushed to master branch. Thanks Eric. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Adding a new thread model to GCC
On 12/16/22 19:20, Eric Botcazou wrote: The libgcc parts look reasonable to me, but I can't approve them. Maybe Jonathan Yong can approve those parts as mingw-w64 target maintainer, or maybe a libgcc approver can do so. OK. The libstdc++ parts are OK for trunk. IIUC they could go in separately, they just wouldn't be very much use without the libgcc changes. Sure thing. Ping, need help to commit it?
Re: testsuite: Fix pr55569.c excess errors
On 12/20/22 16:55, Andrew Pinski wrote: On Tue, Dec 20, 2022 at 1:22 AM Jonathan Yong via Gcc-patches wrote: This fixes the following: It is not obvious from the email, why this patch is needed but I figured it was due to LLP64 targets or some other targets where long is not the same size of the size_t type. I think this patch is good but I cannot approve it. The commit message should be improved to make a mention of LLP64 targets and long being a smaller size than size_t. Thanks, Andrew You are right that this is for LLP64 win32. I will change the subject to "testsuite: Fix pr55569.c excess errors on LLP64" This fixes the following on LLP64 mingw-w64 target: Excess errors: gcc/testsuite/gcc.c-torture/compile/pr55569.c:13:12: warning: overflow in conversion from 'long long unsigned int' to 'long int' changes value from '4611686018427387903' to '-1' [-Woverflow] gcc/testsuite/gcc.c-torture/compile/pr55569.c:13:34: warning: iteration 2147483647 invokes undefined behavior [-Waggressive-loop-optimizations]
testsuite: Fix pr55569.c excess errors
This fixes the following:
Excess errors:
gcc/testsuite/gcc.c-torture/compile/pr55569.c:13:12: warning: overflow
in conversion from 'long long unsigned int' to 'long int' changes value
from '4611686018427387903' to '-1' [-Woverflow]
gcc/testsuite/gcc.c-torture/compile/pr55569.c:13:34: warning: iteration
2147483647 invokes undefined behavior [-Waggressive-loop-optimizations]
Patch OK?From 11cc6c38c4b44849110240da3ed553fcc3b35d05 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Tue, 20 Dec 2022 09:16:16 +
Subject: [PATCH] testsuite: Fix pr55569.c excess errors
This fixes the following:
Excess errors:
gcc/testsuite/gcc.c-torture/compile/pr55569.c:13:12: warning: overflow in conversion from 'long long unsigned int' to 'long int' changes value from '4611686018427387903' to '-1' [-Woverflow]
gcc/testsuite/gcc.c-torture/compile/pr55569.c:13:34: warning: iteration 2147483647 invokes undefined behavior [-Waggressive-loop-optimizations]
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/pr55569.c: fix excess errors.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/testsuite/gcc.c-torture/compile/pr55569.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr55569.c b/gcc/testsuite/gcc.c-torture/compile/pr55569.c
index cf274cdbb99..6c2c7c7b6f7 100644
--- a/gcc/testsuite/gcc.c-torture/compile/pr55569.c
+++ b/gcc/testsuite/gcc.c-torture/compile/pr55569.c
@@ -4,7 +4,7 @@ int *bar (void);
void
foo (void)
{
- long x;
+ __INTPTR_TYPE__ x;
int *y = bar ();
/* The loop below may be optimized to a call to memset with a size
--
2.39.0
Re: Adding a new thread model to GCC
On 10/31/22 15:22, i.nixman--- via Gcc-patches wrote: On 2022-10-31 09:18, Eric Botcazou wrote: Hi Eric! thank you very much for the job! I will try to build our (MinGW-Builds project) builds using this patch and will report back. @Jonathan what the next steps to be taken to accept this patch? I don't see any obvious problems with it, looks OK to me.
Re: [PATCH] libgcc: Update 'gthr-mcf.h' to include a dedicated header for libobjc
On 10/22/22 11:54, LIU Hao wrote: This allows building libobjc and enabling Objective-C. Tested against GCC 12 branch on i686-w64-mingw32. Done, pushed to master branch.
Re: Adding a new thread model to GCC
On 10/14/22 09:39, Jonathan Yong wrote: On 10/11/22 13:22, LIU Hao wrote: 在 2022-10-10 23:56, LIU Hao 写道: 在 2022-10-04 20:44, LIU Hao 写道: Attached are revised patches. These are exported from trunk. Revised further. The patch for libgfortran has been committed to trunk today, so I include only the other two. * In the second patch, a space character has been inserted after `(int)` for clearness. * The macro controlling how to build GCC itself has been renamed to `TARGET_USING_MCFGTHREAD` for consistency. * Checks against `TARGET_USING_MCFGTHREAD` have been updated in a more friendly way. * When not using mcfgthread, NTDLL is no longer a default library. Although all recent Windows versions are based on the NT kernel, there could still be people who want to target 9x or CE; thus NTDLL is only added when it is potentially necessary, for example when linking against the static libgcc. Attached is the (previous) third patch, with configure scripts regenerated. Any more comments? Just pushed to master branch.
Re: Adding a new thread model to GCC
On 10/11/22 13:22, LIU Hao wrote: 在 2022-10-10 23:56, LIU Hao 写道: 在 2022-10-04 20:44, LIU Hao 写道: Attached are revised patches. These are exported from trunk. Revised further. The patch for libgfortran has been committed to trunk today, so I include only the other two. * In the second patch, a space character has been inserted after `(int)` for clearness. * The macro controlling how to build GCC itself has been renamed to `TARGET_USING_MCFGTHREAD` for consistency. * Checks against `TARGET_USING_MCFGTHREAD` have been updated in a more friendly way. * When not using mcfgthread, NTDLL is no longer a default library. Although all recent Windows versions are based on the NT kernel, there could still be people who want to target 9x or CE; thus NTDLL is only added when it is potentially necessary, for example when linking against the static libgcc. Attached is the (previous) third patch, with configure scripts regenerated. Any more comments?
Re: PING^1 [PATCH] testsuite: Windows reports errors with CreateProcess
On 10/5/22 09:15, Torbjorn SVENSSON via Gcc-patches wrote: Hi, Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602541.html Kind regards, Torbjörn Looks good to me, pushed to master branch as fa8e3a055a082e38aeab2561a5016b01ebfd6ebd.
Re: [PATCH] testsuite: /dev/null is not accessible on Windows
On 10/5/22 09:34, Jonathan Yong wrote: On 9/29/22 17:38, Torbjörn SVENSSON via Gcc-patches wrote: When running the DejaGNU testsuite on a toolchain built for native Windows, the path /dev/null can't be used to open a stream to void. On native Windows, the resource is instead named "nul". The error would look like this: c:/arm-11.3.rel1/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: cannot find @/dev/null: No such file or directory Patch has been verified on Windows and Linux. Thanks, looks good to me, will push to master soon. Pushed to master branch 5fe2e4f87e512407c5c560dfec2fe48ba099c807.
Re: [PATCH] testsuite: /dev/null is not accessible on Windows
On 9/29/22 17:38, Torbjörn SVENSSON via Gcc-patches wrote:
When running the DejaGNU testsuite on a toolchain built for native
Windows, the path /dev/null can't be used to open a stream to void.
On native Windows, the resource is instead named "nul".
The error would look like this:
c:/arm-11.3.rel1/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe:
cannot find @/dev/null: No such file or directory
Patch has been verified on Windows and Linux.
gcc/testsuite:
* gcc.misc-tests/outputs.exp: Use "@nul" for Windows,
"@/dev/null" for other environments.
Co-Authored-By: Yvan ROUX
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/gcc.misc-tests/outputs.exp | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp
b/gcc/testsuite/gcc.misc-tests/outputs.exp
index ab919db1ccb..3fe7270fa63 100644
--- a/gcc/testsuite/gcc.misc-tests/outputs.exp
+++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
@@ -78,6 +78,13 @@ if {[board_info $dest exists output_format]} {
append link_options " additional_flags=-Wl,-oformat,[board_info $dest
output_format]"
}
+
+set devnull "/dev/null"
+if { [info exists ::env(OS)] && [string match "Windows*" $::env(OS)] } {
+# Windows uses special file named "nul" as a substitute for /dev/null
+set devnull "nul"
+}
+
# Avoid possible influence from the make jobserver,
# otherwise ltrans0.ltrans_args files may be missing.
if [info exists env(MAKEFLAGS)] {
@@ -353,10 +360,10 @@ outest "$b-21 exe savetmp named2" $mult "-o $b.exe
-save-temps" {} {{--1.i --1.s
# Additional files are created when an @file is used
if !$skip_atsave {
-outest "$b-22 exe savetmp namedb-2" $sing "@/dev/null -o $b.exe -save-temps"
{} {{--0.i --0.s --0.o .args.0 !!$gld .ld1_args !0 .exe}}
-outest "$b-23 exe savetmp named2-2" $mult "@/dev/null -o $b.exe -save-temps"
{} {{--1.i --1.s --1.o --2.i --2.s --2.o .args.0 !!$gld .ld1_args !0 .exe}}
-outest "$b-24 exe savetmp named2-3" $mult "@/dev/null -I dummy -o $b.exe
-save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o -args.0 -args.1 .args.2 !!$gld .ld1_args
!0 .exe}}
-outest "$b-25 exe savetmp named2-4" $mult "@/dev/null -I dummy -L dummy -o $b.exe
-save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o -args.0 -args.1 .args.2 .args.3 !!$gld
.ld1_args !0 .exe}}
+outest "$b-22 exe savetmp namedb-2" $sing "@$devnull -o $b.exe -save-temps" {}
{{--0.i --0.s --0.o .args.0 !!$gld .ld1_args !0 .exe}}
+outest "$b-23 exe savetmp named2-2" $mult "@$devnull -o $b.exe -save-temps" {}
{{--1.i --1.s --1.o --2.i --2.s --2.o .args.0 !!$gld .ld1_args !0 .exe}}
+outest "$b-24 exe savetmp named2-3" $mult "@$devnull -I dummy -o $b.exe
-save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o -args.0 -args.1 .args.2 !!$gld .ld1_args
!0 .exe}}
+outest "$b-25 exe savetmp named2-4" $mult "@$devnull -I dummy -L dummy -o $b.exe
-save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o -args.0 -args.1 .args.2 .args.3 !!$gld
.ld1_args !0 .exe}}
}
# Setting the main output to a dir selects it as the default aux&dump
@@ -714,7 +721,7 @@ outest "$b-291 lto mult named-2" $mult "-o $b.exe -O2 -flto
-fno-use-linker-plug
outest "$b-292 lto sing nameddir-2" $sing "-o dir/$b.exe -O2 -flto
-fno-use-linker-plugin -flto-partition=one -fdump-ipa-icf-optimized -fdump-rtl-final
-fstack-usage" {dir/} {{--0.c.???i.icf --0.c.???r.final .wpa.???i.icf
.ltrans0.ltrans.???r.final .ltrans0.ltrans.su .exe} {}}
outest "$b-293 lto mult nameddir-2" $mult "-o dir/$b.exe -O2 -flto
-fno-use-linker-plugin -flto-partition=one -fdump-ipa-icf-optimized -fdump-rtl-final
-fstack-usage" {dir/} {{--1.c.???i.icf --1.c.???r.final --2.c.???i.icf --2.c.???r.final
.wpa.???i.icf .ltrans0.ltrans.???r.final .ltrans0.ltrans.su .exe} {}}
if !$skip_atsave {
-outest "$b-294 lto sing unnamed-3" $sing "@/dev/null -O2 -flto
-fno-use-linker-plugin -flto-partition=one -fdump-ipa-icf-optimized -fdump-rtl-final -fstack-usage
-save-temps $oaout" {} {{a--0.c.???i.icf a--0.c.???r.final a.wpa.???i.icf
a.ltrans0.ltrans.???r.final a.ltrans0.ltrans.su a--0.o a--0.s a--0.i a.ltrans0.o a.ltrans.out
a.ltrans0.ltrans.o a.ltrans0.ltrans_args a.args.0 a.ltrans0.ltrans.s a.wpa.args.0 a.lto_args
a.ld1_args a.ltrans_args a.ltrans0.ltrans.args.0 a.ld_args $aout}}
+outest "$b-294 lto sing unnamed-3" $sing "@$devnull -O2 -flto
-fno-use-linker-plugin -flto-partition=one -fdump-ipa-icf-optimized -fdump-rtl-final -fstack-usage
-save-temps $oaout" {} {{a--0.c.???i.icf a--0.c.???r.final a.wpa.???i.icf
a.ltrans0.ltrans.???r.final a.ltrans0.ltrans.su a--0.o a--0.s a--0.i a.ltrans0.o a.ltrans.out
a.ltrans0.ltrans.o a.ltrans0.ltrans_args a.args.0 a.ltrans0.ltrans.s a.wpa.args.0 a.lto_args
a.ld1_args a.ltrans_args a.ltrans0.ltrans.args.0 a.ld_args $aout}}
}
}
Thanks, looks good to me, will push to master soon.
Re: [PATCH] mingw32: Fix warning, update documentation
On 9/8/22 11:02, Jan-Benedict Glaw wrote:
Hi!
The mingw32 port is the only port to have TARGET_OVERRIDES_FORMAT_ATTRIBUTES
defined. When this macro is defined, it will never evaluate to NULL, so this
check just leads to a warning:
/usr/lib/gcc-snapshot/bin/g++ -fcf-protection -fno-PIE -c -DIN_GCC_FRONTEND
-DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
-DHAVE_CONFIG_H -I. -Ic-family -I../../gcc/gcc -I../../gcc/gcc/c-family
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I../../gcc/gcc/../libcody -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/gcc/../libbacktrace -o c-family/c-format.o -MT
c-family/c-format.o -MMD -MP -MF c-family/.deps/c-format.TPo
../../gcc/gcc/c-family/c-format.cc
../../gcc/gcc/c-family/c-format.cc: In function 'const char*
convert_format_name_to_system_name(const char*)':
../../gcc/gcc/c-family/c-format.cc:5114:42: error: the address of
'mingw_format_attribute_overrides' will never be NULL [-Werror=address]
5114 | if (TARGET_OVERRIDES_FORMAT_ATTRIBUTES != NULL
In file included from ./tm.h:26,
from ../../gcc/gcc/c-family/c-format.cc:23:
../../gcc/gcc/config/i386/mingw32.h:268:44: note:
'mingw_format_attribute_overrides' declared here
268 | #define TARGET_OVERRIDES_FORMAT_ATTRIBUTES
mingw_format_attribute_overrides
|
^~~~
../../gcc/gcc/c-family/c-format.cc:5079:30: note: in expansion of macro
'TARGET_OVERRIDES_FORMAT_ATTRIBUTES'
5079 | extern const target_ovr_attr TARGET_OVERRIDES_FORMAT_ATTRIBUTES[];
| ^~
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile:1146: c-family/c-format.o] Error 1
make[1]: Leaving directory
'/var/lib/laminar/run/gcc-x86_64-w64-mingw32/1/toolchain-build/gcc'
make: *** [Makefile:4588: all-gcc] Error 2
Also, when TARGET_OVERRIDES_FORMAT_ATTRIBUTES is defined,
TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT must be defined as well. Add
that requirement to the docs.
2022-09-07 Jan-Benedict Glaw
gcc/ChangeLog:
* c-family/c-format.cc (convert_format_name_to_system_name): Fix
warning.
* doc/tm.texi.in (TARGET_OVERRIDES_FORMAT_ATTRIBUTES): Document
requirement
of TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT being defined as well.
* doc/tm.texi: Regenerate.
diff --git a/gcc/c-family/c-format.cc b/gcc/c-family/c-format.cc
index 68b94da40cc..a6c380bf1c8 100644
--- a/gcc/c-family/c-format.cc
+++ b/gcc/c-family/c-format.cc
@@ -5111,8 +5111,7 @@ convert_format_name_to_system_name (const char *attr_name)
#ifdef TARGET_OVERRIDES_FORMAT_ATTRIBUTES
/* Check if format attribute is overridden by target. */
- if (TARGET_OVERRIDES_FORMAT_ATTRIBUTES != NULL
- && TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT > 0)
+ if (TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT > 0)
{
for (i = 0; i < TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT; ++i)
{
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 5312059ea79..21b849ea32a 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -7836,7 +7836,8 @@ If defined, this macro is the number of entries in
If defined, this macro is the name of a global variable containing
target-specific format overrides for the @option{-Wformat} option. The
default is to have no target-specific format overrides. If defined,
-@code{TARGET_FORMAT_TYPES} must be defined, too.
+@code{TARGET_FORMAT_TYPES} and @code{TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT}
+must be defined, too.
@end defmac
@defmac TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index e47bf28089a..858bfb80cec 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -12043,7 +12043,8 @@ If defined, this macro is the number of entries in
If defined, this macro is the name of a global variable containing
target-specific format overrides for the @option{-Wformat} option. The
default is to have no target-specific format overrides. If defined,
-@code{TARGET_FORMAT_TYPES} must be defined, too.
+@code{TARGET_FORMAT_TYPES} and @code{TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT}
+must be defined, too.
@end defmac
@defmac TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT
Okay for HEAD?
Thanks,
Jan-Benedict
Looks good to me, thanks for working on it.
OpenPGP_0x713B5FE29C145D45_and_old_rev.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] Remove size limit of PCH
On 5/10/22 13:30, LIU Hao wrote: 在 2022-05-10 20:00, Xi Ruoyao 写道: On Tue, 2022-05-10 at 19:35 +0800, LIU Hao via Gcc-patches wrote: Subject: [PATCH] Remove size limit of PCH Make it "Remove size limit of PCH [PR14940]", so once it's committed a message will show up in bugzilla. Here is the revised patch. Thanks, I will commit soon if there are no objections. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] Remove dbx.h, do not set PREFERRED_DEBUGGING_TYPE from dbxcoff.h, lynx.h
On 9/9/21 1:19 PM, Richard Biener wrote: The following removes the unused config/dbx.h file and removes the setting of PREFERRED_DEBUGGING_TYPE from dbxcoff.h which is overridden by all users (djgpp/mingw/cygwin) via either including config/i386/djgpp.h or config/i386/cygming.h There are still circumstances where mingw and cygwin default to STABS, namely when HAVE_GAS_PE_SECREL32_RELOC is not defined and the target defaults to 32bit code generation. The new style handling DBX_DEBUGGING_INFO is in line with dbxelf.h which does not define PREFERRED_DEBUGGING_TYPE either. The patch also removes the PREFERRED_DEBUGGING_TYPE define from lynx.h which always follows elfos.h already defaulting to DWARF, so the comment about STABS being the default is misleading and outdated. There's no listed maintainer for Lynx OS. I have not tested this in any ways but I also have no idea how to meaningfully do so. Cygwin/MinGW seems to have HAVE_GAS_PE_SECREL32_RELOC set with modern binutils for both 32bit and 64bit, so PREFERRED_DEBUGGING_TYPE should nearly always be set as DWARF2_DEBUG. Tested with binutils 2.36.50.20210330. OpenPGP_0x713B5FE29C145D45.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] libstdc++-v3: Check for TLS support on mingw
On 8/31/21 9:02 AM, Jonathan Wakely wrote:
It looks like my questions about this patch never got an answer, and
it never got applied.
Could somebody say whether TLS is enabled for native *-*-mingw*
builds? If it is, then we definitely need to add GCC_CHECK_TLS to the
cross-compiler config too.
For a linux-hosted x86_64-w64-mingw32 cross compiler I see TLS is not enabled:
/* Define to 1 if the target supports thread-local storage. */
/* #undef _GLIBCXX_HAVE_TLS */
On Mon, 19 Feb 2018 at 08:59, Hugo Beauzée-Luyssen wrote:
libstdc++-v3: Check for TLS support on mingw
2018-02-16 Hugo Beauzée-Luyssen
* crossconfig.m4: Check for TLS support on mignw
* configure: regenerate
Index: libstdc++-v3/crossconfig.m4
===
--- libstdc++-v3/crossconfig.m4 (revision 257730)
+++ libstdc++-v3/crossconfig.m4 (working copy)
@@ -197,6 +197,7 @@ case "${host}" in
GLIBCXX_CHECK_LINKER_FEATURES
GLIBCXX_CHECK_MATH_SUPPORT
GLIBCXX_CHECK_STDLIB_SUPPORT
+GCC_CHECK_TLS
;;
*-netbsd*)
SECTION_FLAGS='-ffunction-sections -fdata-sections'
According to MSYS2 native from
https://mirror.msys2.org/mingw/ucrt64/mingw-w64-ucrt-x86_64-gcc-10.3.0-5-any.pkg.tar.zst:
x86_64-w64-mingw32/bits/c++config.h:#define _GLIBCXX_HAVE_TLS 1
So yes.
OpenPGP_0x713B5FE29C145D45.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [Patch] Fix cygming-crtend.c build warning due to -Wprio-ctor-dtor
On 8/25/21 11:06 PM, Jeff Law wrote: On 8/25/2021 10:46 AM, Jonathan Yong via Gcc-patches wrote: Attached patches OK? cygming-crtend.c: fix build warnings libgcc/Changelog: * config/i386/cygming-crtend.c: Fix register_frame_ctor and register_frame_dtor warnings. extend.texi: add note about reserved ctor/dtor priorities gcc/Changelog: * doc/extend.texi: Add note about reserved priorities to the constructor attribute. Yes. Both are OK. jeff Done, pushed to master, thanks. OpenPGP_0x713B5FE29C145D45.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[Patch] Fix cygming-crtend.c build warning due to -Wprio-ctor-dtor
Attached patches OK?
cygming-crtend.c: fix build warnings
libgcc/Changelog:
* config/i386/cygming-crtend.c: Fix register_frame_ctor
and register_frame_dtor warnings.
extend.texi: add note about reserved ctor/dtor priorities
gcc/Changelog:
* doc/extend.texi: Add note about reserved priorities
to the constructor attribute.
From e9758ef8c03e617eafe13ca6512fd7cd0256abc7 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Wed, 25 Aug 2021 16:33:36 +
Subject: [PATCH 1/2] cygming-crtend.c: fix build warnings
libgcc/Changelog:
* config/i386/cygming-crtend.c: Fix register_frame_ctor
and register_frame_dtor warnings.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
libgcc/config/i386/cygming-crtend.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libgcc/config/i386/cygming-crtend.c b/libgcc/config/i386/cygming-crtend.c
index c7ba109a04a..4ab63427ee2 100644
--- a/libgcc/config/i386/cygming-crtend.c
+++ b/libgcc/config/i386/cygming-crtend.c
@@ -56,7 +56,10 @@ static EH_FRAME_SECTION_CONST int __FRAME_END__[]
extern void __gcc_register_frame (void);
extern void __gcc_deregister_frame (void);
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wprio-ctor-dtor"
static void register_frame_ctor (void) __attribute__ ((constructor (0)));
+#pragma GCC diagnostic pop
static void
register_frame_ctor (void)
@@ -65,7 +68,10 @@ register_frame_ctor (void)
}
#if !DEFAULT_USE_CXA_ATEXIT
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wprio-ctor-dtor"
static void deregister_frame_dtor (void) __attribute__ ((destructor (0)));
+#pragma GCC diagnostic pop
static void
deregister_frame_dtor (void)
--
2.33.0
From 12b18651af252fb111e1a7375fe09fbc69987922 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Wed, 25 Aug 2021 16:36:14 +
Subject: [PATCH 2/2] extend.texi: add note about reserved ctor/dtor priorities
gcc/Changelog:
* doc/extend.texi: Add note about reserved priorities
to the constructor attribute.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/doc/extend.texi | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 49df8e6dc38..251a10302b4 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2787,16 +2787,16 @@ On some targets the attributes also accept an integer argument to
specify a priority to control the order in which constructor and
destructor functions are run. A constructor
with a smaller priority number runs before a constructor with a larger
-priority number; the opposite relationship holds for destructors. So,
-if you have a constructor that allocates a resource and a destructor
-that deallocates the same resource, both functions typically have the
-same priority. The priorities for constructor and destructor
-functions are the same as those specified for namespace-scope C++
-objects (@pxref{C++ Attributes}). However, at present, the order in which
-constructors for C++ objects with static storage duration and functions
-decorated with attribute @code{constructor} are invoked is unspecified.
-In mixed declarations, attribute @code{init_priority} can be used to
-impose a specific ordering.
+priority number; the opposite relationship holds for destructors. Note
+that priorities 0-100 are reserved. So, if you have a constructor that
+allocates a resource and a destructor that deallocates the same
+resource, both functions typically have the same priority. The
+priorities for constructor and destructor functions are the same as
+those specified for namespace-scope C++ objects (@pxref{C++ Attributes}).
+However, at present, the order in which constructors for C++ objects
+with static storage duration and functions decorated with attribute
+@code{constructor} are invoked is unspecified. In mixed declarations,
+attribute @code{init_priority} can be used to impose a specific ordering.
Using the argument forms of the @code{constructor} and @code{destructor}
attributes on targets where the feature is not supported is rejected with
--
2.33.0
OpenPGP_0x713B5FE29C145D45.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [Patch] gcc.c-torture/execute: Fix tmpnam issue on Windows
On 8/23/21 1:07 AM, Jeff Law wrote: On 8/21/2021 9:10 PM, Jonathan Yong via Gcc-patches wrote: Attached patch OK? 2021-08-22 Jonathan Yong <10wa...@gmail.com> gcc/testsuite/ChangLog: * gcc.c-torture/execute/gcc_tmpnam.h: Fix tmpnam case on Windows where it can return a filename with "\" to indicate current directory. * gcc.c-torture/execute/fprintf-2.c: Use wrapper. * gcc.c-torture/execute/printf-2.c: Use wrapper. * gcc.c-torture/execute/user-printf.c: Use wrapper. OK jeff Pushed to master branch, thanks. OpenPGP_0x713B5FE29C145D45.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[Patch] gcc.c-torture/execute: Fix tmpnam issue on Windows
Attached patch OK?
2021-08-22 Jonathan Yong <10wa...@gmail.com>
gcc/testsuite/ChangLog:
* gcc.c-torture/execute/gcc_tmpnam.h: Fix tmpnam case on Windows
where it can return a filename with "\" to indicate current
directory.
* gcc.c-torture/execute/fprintf-2.c: Use wrapper.
* gcc.c-torture/execute/printf-2.c: Use wrapper.
* gcc.c-torture/execute/user-printf.c: Use wrapper.
From a42f25168397de2f45e44b05b6e49cc455a5b7a7 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Sun, 22 Aug 2021 03:05:07 +
Subject: [PATCH] gcc.c-torture/execute: Fix tmpnam issue on Windows
2021-08-22 Jonathan Yong <10wa...@gmail.com>
gcc/testsuite/ChangLog:
* gcc.c-torture/execute/gcc_tmpnam.h: Fix tmpnam case on Windows
where it can return a filename with "\" to indicate current
directory.
* gcc.c-torture/execute/fprintf-2.c: Use wrapper.
* gcc.c-torture/execute/printf-2.c: Use wrapper.
* gcc.c-torture/execute/user-printf.c: Use wrapper.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
gcc/testsuite/gcc.c-torture/execute/fprintf-2.c | 3 ++-
gcc/testsuite/gcc.c-torture/execute/gcc_tmpnam.h | 13 +
gcc/testsuite/gcc.c-torture/execute/printf-2.c| 3 ++-
gcc/testsuite/gcc.c-torture/execute/user-printf.c | 3 ++-
4 files changed, 19 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.c-torture/execute/gcc_tmpnam.h
diff --git a/gcc/testsuite/gcc.c-torture/execute/fprintf-2.c b/gcc/testsuite/gcc.c-torture/execute/fprintf-2.c
index d8e19e7b2f8..00517d1d1ac 100644
--- a/gcc/testsuite/gcc.c-torture/execute/fprintf-2.c
+++ b/gcc/testsuite/gcc.c-torture/execute/fprintf-2.c
@@ -9,10 +9,11 @@
#include
#include
#include
+#include "gcc_tmpnam.h"
int main (void)
{
- char *tmpfname = tmpnam (0);
+ char *tmpfname = gcc_tmpnam (0);
FILE *f = fopen (tmpfname, "w");
if (!f)
{
diff --git a/gcc/testsuite/gcc.c-torture/execute/gcc_tmpnam.h b/gcc/testsuite/gcc.c-torture/execute/gcc_tmpnam.h
new file mode 100644
index 000..2136e6eaf13
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/gcc_tmpnam.h
@@ -0,0 +1,13 @@
+#include
+#ifndef GCC_TMPNAM
+#define GCC_TMPNAM
+static inline char *gcc_tmpnam(char *s)
+{
+ char *ret = tmpnam (s);
+ // Windows sometimes prepends a backslash to denote the current directory,
+ // so swallow that if it occurs
+ if (ret[0] == '\\')
+++ret;
+ return ret;
+}
+#endif
diff --git a/gcc/testsuite/gcc.c-torture/execute/printf-2.c b/gcc/testsuite/gcc.c-torture/execute/printf-2.c
index 4e7d8f7cdfa..2087bba8448 100644
--- a/gcc/testsuite/gcc.c-torture/execute/printf-2.c
+++ b/gcc/testsuite/gcc.c-torture/execute/printf-2.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include "gcc_tmpnam.h"
__attribute__ ((noipa)) void
write_file (void)
@@ -26,7 +27,7 @@ write_file (void)
int main (void)
{
- char *tmpfname = tmpnam (0);
+ char *tmpfname = gcc_tmpnam (0);
FILE *f = freopen (tmpfname, "w", stdout);
if (!f)
{
diff --git a/gcc/testsuite/gcc.c-torture/execute/user-printf.c b/gcc/testsuite/gcc.c-torture/execute/user-printf.c
index 42a3b17f123..bfee0760dd7 100644
--- a/gcc/testsuite/gcc.c-torture/execute/user-printf.c
+++ b/gcc/testsuite/gcc.c-torture/execute/user-printf.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include "gcc_tmpnam.h"
void __attribute__ ((format (printf, 1, 2), noipa))
user_print (const char *fmt, ...)
@@ -23,7 +24,7 @@ user_print (const char *fmt, ...)
int main (void)
{
- char *tmpfname = tmpnam (0);
+ char *tmpfname = gcc_tmpnam (0);
FILE *f = freopen (tmpfname, "w", stdout);
if (!f)
{
--
2.33.0
OpenPGP_0x713B5FE29C145D45.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [patch] Make -no-pie option work for native Windows
On 8/11/21 2:21 PM, Eric Botcazou wrote: Hi, as already mentioned on the list, binutils 2.36 generates PIE executables by default on native Windows (because --dynamicbase is the default) so it makes sense to have a simple way to counter that and -no-pie seems appropriate, all the more so that it is automatically passed when building the compiler. Bootstrapped on x86 and x86-64/Windows, w/ and w/o binutils 2.36, OK for the mainline and 11 branch? 2021-08-11 Eric Botcazou * configure.ac (PE linker --disable-dynamicbase support): New check. * configure: Regenerate. * config.in: Likewise. * config/i386/mingw32.h (LINK_SPEC_DISABLE_DYNAMICBASE): New define. (LINK_SPEC): Use it. * config/i386/mingw-w64.h (LINK_SPEC_DISABLE_DYNAMICBASE): Likewise. (LINK_SPEC): Likewise. Looks good to me. Do you have push permissions? OpenPGP_0x713B5FE29C145D45.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags variables
On 4/9/21 11:46 AM, Martin Storsjö wrote: This is similar to what was done in eea4e2ff0a3f5e7f37df204c070cc5d9ef339e6e (where it was added to STAGE*_CXXFLAGS), but this adds the flag to the CXXFLAGS and BOOT_CXXFLAGS variables too (as it's already added to CFLAGS and BOOT_CFLAGS). 2021-04-09 Martin Storsjö config/ChangeLog: * mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags variables --- config/mh-mingw | 2 ++ 1 file changed, 2 insertions(+) diff --git a/config/mh-mingw b/config/mh-mingw index a795096f038..e91367a7112 100644 --- a/config/mh-mingw +++ b/config/mh-mingw @@ -1,7 +1,9 @@ # Add -D__USE_MINGW_ACCESS to enable the built compiler to work on Windows # Vista (see PR33281 for details). BOOT_CFLAGS += -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format +BOOT_CXXFLAGS += -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format CFLAGS += -D__USE_MINGW_ACCESS +CXXFLAGS += -D__USE_MINGW_ACCESS STAGE1_CXXFLAGS += -D__USE_MINGW_ACCESS STAGE2_CXXFLAGS += -D__USE_MINGW_ACCESS STAGE3_CXXFLAGS += -D__USE_MINGW_ACCESS Pushed to master branch, thanks. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags variables
On 4/9/21 11:46 AM, Martin Storsjö wrote: This is similar to what was done in eea4e2ff0a3f5e7f37df204c070cc5d9ef339e6e (where it was added to STAGE*_CXXFLAGS), but this adds the flag to the CXXFLAGS and BOOT_CXXFLAGS variables too (as it's already added to CFLAGS and BOOT_CFLAGS). 2021-04-09 Martin Storsjö config/ChangeLog: * mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags variables --- config/mh-mingw | 2 ++ 1 file changed, 2 insertions(+) diff --git a/config/mh-mingw b/config/mh-mingw index a795096f038..e91367a7112 100644 --- a/config/mh-mingw +++ b/config/mh-mingw @@ -1,7 +1,9 @@ # Add -D__USE_MINGW_ACCESS to enable the built compiler to work on Windows # Vista (see PR33281 for details). BOOT_CFLAGS += -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format +BOOT_CXXFLAGS += -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format CFLAGS += -D__USE_MINGW_ACCESS +CXXFLAGS += -D__USE_MINGW_ACCESS STAGE1_CXXFLAGS += -D__USE_MINGW_ACCESS STAGE2_CXXFLAGS += -D__USE_MINGW_ACCESS STAGE3_CXXFLAGS += -D__USE_MINGW_ACCESS Patch looks good to me, will push to master branch soon. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH][RFC] Make mingw-w64 printf/scanf attribute alias to ms_printf/ms_scanf only for C89
On 11/16/20 5:40 AM, Jonathan Yong wrote: On 11/14/20 12:29 PM, Liu Hao via Gcc-patches wrote: This is the third revision of my patch: 1. Two typos in the commit message have been fixed. 2. Support for `%a` and `%A` has been added. Documentation can be found on the same page in the commit message. 3. GCC will no longer warn about 'ISO C does not support the ‘L’ ms_printf length modifier'. This was caused by mistaken array indices in `TARGET_OVERRIDES_FORMAT_INIT`. I'll be pushing this soon if there aren't any more complaints. Pushed to master, thanks all for contributing and reviewing. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH][RFC] Make mingw-w64 printf/scanf attribute alias to ms_printf/ms_scanf only for C89
On 11/14/20 12:29 PM, Liu Hao via Gcc-patches wrote: This is the third revision of my patch: 1. Two typos in the commit message have been fixed. 2. Support for `%a` and `%A` has been added. Documentation can be found on the same page in the commit message. 3. GCC will no longer warn about 'ISO C does not support the ‘L’ ms_printf length modifier'. This was caused by mistaken array indices in `TARGET_OVERRIDES_FORMAT_INIT`. I'll be pushing this soon if there aren't any more complaints. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
[PATCH][RFC] Make mingw-w64 printf/scanf attribute alias to ms_printf/ms_scanf only for C89
libgomp build fails because of the false -Wformat error, even though:
1. Correct C99 inttypes.h macros are used.
2. __mingw_* C99 wrappers are used.
3. The printf attribute is used, but it was aliased to ms_printf
The attached patch makes mingw-w64 printf attribute equivalent to other
platforms on C99 or later. This allows libgomp to build again with
-Werror on. This patch should not affect the original mingw.org
distribution in any way.
For C99 or later, the mingw-w64 headers already wrap printf/scanf
properly, and inttypes.h also gives the correct C99 specifiers, so it
makes sense to treat the printf attribute as C99 compliant. Under C89
mode, the headers would produce MS specific specifiers, so the printf
attribute under C89 reverts to the old behavior of being aliased to
ms_printf.
This might break other code that assumes differently however. I don't
think there is a solution to satisfy everyone, but at least this allows
C99/C++11 compliant code to build again with -Werror. Comments?
From 397097aba5a098f18da92704e9ca7560adb4f29c Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Thu, 12 Nov 2020 06:45:00 +
Subject: [PATCH] gcc: make mingw-w64 printf/scanf attribute gnu equivalents in
C99
Makes printf/scanf attribute equivalent to gnu_printf and gnu_scanf
in C99 mode. Fixes false positive warnings for functions with printf
attribute, even when correct C99 style printf specifiers are used.
12-11-2020 Jonathan Yong <10wa...@gmail.com>
gcc/ChangeLog:
* c-family/c-format.c
(convert_format_name_to_system_name):
Turn TARGET_OVERRIDES_FORMAT_ATTRIBUTES into a callback
that returns a list of attribute aliases.
* config/i386/mingw-w64.h (TARGET_OVERRIDES_FORMAT_C89):
Define. Tell GCC to use ms_printf and ms_scanf in C89.
* config/i386/mingw32.h:
(TARGET_OVERRIDES_FORMAT_ATTRIBUTES):
Point to wrapper function and update description.
(TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT): remove.
* config/i386/msformat-c.c:
(mingw_format_attribute_overrides):
New callback.
(mingw_format_attribute_overrides_table): make null
terminated.
---
gcc/c-family/c-format.c | 28
gcc/config/i386/mingw-w64.h | 4
gcc/config/i386/mingw32.h| 8 ++--
gcc/config/i386/msformat-c.c | 23 ---
4 files changed, 42 insertions(+), 21 deletions(-)
diff --git a/gcc/c-family/c-format.c b/gcc/c-family/c-format.c
index 77d24ad94e4..4edf4c64f79 100644
--- a/gcc/c-family/c-format.c
+++ b/gcc/c-family/c-format.c
@@ -5077,7 +5077,7 @@ extern const format_kind_info TARGET_FORMAT_TYPES[];
#endif
#ifdef TARGET_OVERRIDES_FORMAT_ATTRIBUTES
-extern const target_ovr_attr TARGET_OVERRIDES_FORMAT_ATTRIBUTES[];
+extern const target_ovr_attr* TARGET_OVERRIDES_FORMAT_ATTRIBUTES (int format_std_version);
#endif
#ifdef TARGET_OVERRIDES_FORMAT_INIT
extern void TARGET_OVERRIDES_FORMAT_INIT (void);
@@ -5102,6 +5102,9 @@ static const char *
convert_format_name_to_system_name (const char *attr_name)
{
int i;
+#ifdef TARGET_OVERRIDES_FORMAT_ATTRIBUTES
+ const target_ovr_attr* override_attributes;
+#endif
if (attr_name == NULL || *attr_name == 0
|| strncmp (attr_name, "gcc_", 4) == 0)
@@ -5112,18 +5115,19 @@ convert_format_name_to_system_name (const char *attr_name)
#ifdef TARGET_OVERRIDES_FORMAT_ATTRIBUTES
/* Check if format attribute is overridden by target. */
- if (TARGET_OVERRIDES_FORMAT_ATTRIBUTES != NULL
- && TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT > 0)
+ override_attributes = TARGET_OVERRIDES_FORMAT_ATTRIBUTES(C_STD_VER);
+ if (override_attributes != NULL)
{
- for (i = 0; i < TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT; ++i)
-{
- if (cmp_attribs (TARGET_OVERRIDES_FORMAT_ATTRIBUTES[i].named_attr_src,
- attr_name))
-return attr_name;
- if (cmp_attribs (TARGET_OVERRIDES_FORMAT_ATTRIBUTES[i].named_attr_dst,
- attr_name))
-return TARGET_OVERRIDES_FORMAT_ATTRIBUTES[i].named_attr_src;
-}
+ for (i = 0;
+ override_attributes[i].named_attr_src != NULL
+ && override_attributes[i].named_attr_dst != NULL;
+ ++i)
+ {
+ if (cmp_attribs (override_attributes[i].named_attr_src, attr_name))
+ return attr_name;
+ if (cmp_attribs (override_attributes[i].named_attr_dst, attr_name))
+ return override_attributes[i].named_attr_src;
+ }
}
#endif
/* Otherwise default to gnu format. */
diff --git a/gcc/config/i386/mingw-w64.h b/gcc/config/i386/mingw-w64.h
index 0d0aa939996..586d151a082 100644
--- a/gcc/config/i386/mingw-w64.h
+++ b/gcc/config/i386/mingw-w64.h
@@ -104,3 +104,7 @@ along with GCC; see the file COPYING3. If not see
original mingw32. */
#undef TARGET_LIBC_HAS_FUNCTION
#define TARGET_LIBC_HAS_FUNCTION gnu_libc_has_function
+
+/* alias printf/scanf attributes to MS variants when in C89 */
+#undef TARGET_OVERRIDES_FORMAT_C89
+#define TARGET_OVERRIDES_FORMAT_C89
diff --git a/gcc/config/i386/mingw32.h b
[PATCH] libstdc++: exclude cygwin/mingw from relro linker test
cygwin/mingw hosted linker may support multiple targets with ELF relro support. This breaks configure testing. Attached patch excludes cygwin/mingw PE format from relro linker flag. Patch OK? From a72f02aec065c312528e41e4243c702d7371b5ce Mon Sep 17 00:00:00 2001 From: Jonathan Yong <10wa...@gmail.com> Date: Wed, 11 Nov 2020 12:23:06 + Subject: [PATCH] libstdc++: exclude cygwin and mingw from linker relro support PE format does not have ELF style relro linker support, exclude from checking. If the host linker supports ELF format, configure may get confused. 11-11-20202 Jonathan Yong <10wa...@gmail.com> libstdc++: * acinclude (GLIBCXX_CHECK_LINKER_FEATURES): exclude cygwin and mingw from relro linker test. --- libstdc++-v3/acinclude.m4 | 23 --- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 index b9452dd74cd..650d63ab3d7 100644 --- a/libstdc++-v3/acinclude.m4 +++ b/libstdc++-v3/acinclude.m4 @@ -273,13 +273,22 @@ AC_DEFUN([GLIBCXX_CHECK_LINKER_FEATURES], [ # Note this is only for shared objects. ac_ld_relro=no if test x"$with_gnu_ld" = x"yes"; then -AC_MSG_CHECKING([for ld that supports -Wl,-z,relro]) -cxx_z_relo=`$LD -v --help 2>/dev/null | grep "z relro"` -if test -n "$cxx_z_relo"; then - OPT_LDFLAGS="-Wl,-z,relro" - ac_ld_relro=yes -fi -AC_MSG_RESULT($ac_ld_relro) +# cygwin and mingw uses PE, which has no ELF relro support, +# multi target ld may confuse configure machinery +case "$host" in +*-*-cygwin*) + ;; +*-*-mingw*) + ;; +*) + AC_MSG_CHECKING([for ld that supports -Wl,-z,relro]) + cxx_z_relo=`$LD -v --help 2>/dev/null | grep "z relro"` + if test -n "$cxx_z_relo"; then +OPT_LDFLAGS="-Wl,-z,relro" +ac_ld_relro=yes + fi + AC_MSG_RESULT($ac_ld_relro) +esac fi # Set linker optimization flags. -- 2.29.2 OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: Fwd: libstdc++: Attempt to resolve PR83562
On 11/6/20 8:34 AM, Martin Storsjö wrote: On Fri, 6 Nov 2020, Liu Hao via Gcc-patches wrote: 在 2020/10/29 下午3:56, Liu Hao 写道: I forward it here for comments. Basing on the behavior of both GCC and Clang, `__cxa_thread_atexit` is used to register the destructor of thread_local objects directly, suggesting the first parameter should have `__thiscall` convention. libstdc++ used the default `__cdecl` convention and caused crashes on 1686-w64-mingw32 (see PR83562). But to my surprise, libcxxabi uses `__cdecl` too [1], but I haven't heard any of relevant reports so far. Original patch is attached in case you can't find it in gcc-patches. FWIW, this patch looks good and correct to me, from a mingw perspective. // Martin Thanks pushed to gcc master branch as 7fc0f78c3f43af1967cb7b1ee8f4947f3b890aa2. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v2] libgcc: Expose the instruction pointer and stack pointer in SEH _Unwind_Backtrace
On 11/6/20 3:27 AM, Jeff Law wrote: On 11/2/20 5:05 AM, Kai Tietz via Gcc-patches wrote: Hello, as noone seems to be able to review this patch, I will do so, even if this is no longer a task of mine. The patch itself is reasonable and seems to fix a pending issue we have on CFA support. I had already private discussion with Martin, and I would have loved to see a test-case illustrating this fix. But as Martin explained to me, there is no trivial testcase for this, so I would approve that patch. Thanks Kai. I'll get the bits installed momentarily. FYI I already pushed this recently to gcc master branch bd6ecbe48ada79bb14cbb30ef8318495b5237790, but did not reply earlier. Sorry about the confusion. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] libstdc++: use lt_host_flags for libstdc++.la
On 10/20/20 2:03 AM, Jonathan Yong wrote: On 9/16/20 1:16 PM, JonY wrote: For platforms like Mingw and Cygwin, cygwin refuses to generate the shared library without using -no-undefined. Attached patch makes sure the right flags are used, since libtool is already used to link libstdc++. Patch OK? Ping. Ping2. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v2] libgcc: Expose the instruction pointer and stack pointer in SEH _Unwind_Backtrace
On 9/8/20 12:21 PM, Martin Storsjö wrote: Previously, the SEH version of _Unwind_Backtrace did unwind the stack and call the provided callback function as intended, but there was little the caller could do within the callback to actually get any info about that particular level in the unwind. Set the ra and cfa pointers, which are used by _Unwind_GetIP and _Unwind_GetCFA, to allow using these functions from the callacb to inspect the state at each stack frame. 2020-09-08 Martin Storsjö libgcc/Changelog: * unwind-seh.c (_Unwind_Backtrace): Set the ra and cfa pointers before calling the callback. --- libgcc/unwind-seh.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libgcc/unwind-seh.c b/libgcc/unwind-seh.c index 1a70180cfaa..275d782903a 100644 --- a/libgcc/unwind-seh.c +++ b/libgcc/unwind-seh.c @@ -466,6 +466,11 @@ _Unwind_Backtrace(_Unwind_Trace_Fn trace, &gcc_context.disp->HandlerData, &gcc_context.disp->EstablisherFrame, NULL); + /* Set values that the callback can inspect via _Unwind_GetIP + * and _Unwind_GetCFA. */ + gcc_context.ra = ms_context.Rip; + gcc_context.cfa = ms_context.Rsp; + /* Call trace function. */ if (trace (&gcc_context, trace_argument) != _URC_NO_REASON) return _URC_FATAL_PHASE1_ERROR; Pushed to master branch, thanks. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: libstdc++: Attempt to resolve PR83562
On 10/27/20 2:38 PM, Liu Hao via Gcc-patches wrote: 在 2020/10/8 22:56, Jason Merrill 写道: Hmm, why isn't the mingw implementation used for all programs? That would avoid the bug. There was a little further discussion about this [1]. TL;DR: The mingw-w64 function is linked statically and subject to issues about order of destruction. Recently mingw-w64 has got its own `__cxa_thread_atexit()` so libstdc++ no longer exposes it. This patch for libstdc++ fixes calling conventions for destructors on i686 so they match mingw-w64 ones. Any more comments? I'd like to push this soon if there are no more issues open. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: enable sincos optimization on cygming targets
On 10/22/20 11:30 AM, Alexandre Oliva wrote: On Oct 22, 2020, Jonathan Yong wrote: No objections for mingw-w64 since it has been tested, but I'm not certain if the original mingw.org version has it. Prompted by you, I looked into the original mingw32, and found it does NOT have sincos, so I withdraw the patch, in favor of this one. Since this one affects only mingw-w64, I haven't checked whether cygwin has it. Hopefully someone with easier access to the platform can do so and duplicate the change in the Cygwin-specific compiler configuration header. Thanks this patch is acceptable. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: enable sincos optimization on cygming targets
On 10/22/20 5:01 AM, Alexandre Oliva wrote: Err, sorry, I mislabeled this patch as [FYI,Ada], but it is neither about Ada nor pre-approved. It does require a review before I can check it in. No objections for mingw-w64 since it has been tested, but I'm not certain if the original mingw.org version has it. Please also do a test build for Cygwin, it uses a different runtime from mingw-w64. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] libstdc++: use lt_host_flags for libstdc++.la
On 9/16/20 1:16 PM, JonY wrote: For platforms like Mingw and Cygwin, cygwin refuses to generate the shared library without using -no-undefined. Attached patch makes sure the right flags are used, since libtool is already used to link libstdc++. Patch OK? Ping. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
