Re: [PATCH] coreutils-sum-pr108666.c: fix spurious LLP64 warnings
On 2/2/24 23:55, Jonathan Yong wrote: Attached patch OK? Fixes the following warnings: coreutils-sum-pr108666.c:17:1: warning: conflicting types for built-in function ‘memcpy’; expected ‘void *(void *, const void *, long long unsigned int)’ [-Wbuiltin-declaration-mismatch] 17 | memcpy(void* __restrict __dest, const void* __restrict __src, size_t __n) | ^~ coreutils-sum-pr108666.c:25:1: warning: conflicting types for built-in function ‘malloc’; expected ‘void *(long long unsigned int)’ [-Wbuiltin-declaration-mismatch] 25 | malloc(size_t __size) __attribute__((__nothrow__, __leaf__)) | ^~ Copied for review convenience: diff --git a/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c b/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c index 5684d1b02d4..dadd27eaf41 100644 --- a/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c +++ b/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c @@ -1,6 +1,6 @@ /* Reduced from coreutils's sum.c: bsd_sum_stream */ -typedef long unsigned int size_t; +typedef __SIZE_TYPE__ size_t; typedef unsigned char __uint8_t; typedef unsigned long int __uintmax_t; typedef struct _IO_FILE FILE; Ping?
Re: [PATCH] coreutils-sum-pr108666.c: fix spurious LLP64 warnings
On 2/14/24 13:55, David Malcolm wrote: On Fri, 2024-02-02 at 23:55 +, Jonathan Yong wrote: Attached patch OK? Fixes the following warnings: Thanks; looks good to me. Dave Thanks, pushed to master branch.
[PATCH] c-c++-common/Wrestrict.c: fix some typos and enable for LLP64
Attached patch OK?
Copy/pasted for review convenience.
diff --git a/gcc/testsuite/c-c++-common/Wrestrict.c
b/gcc/testsuite/c-c++-common/Wrestrict.c
index 4d005a618b3..57a3f67e21e 100644
--- a/gcc/testsuite/c-c++-common/Wrestrict.c
+++ b/gcc/testsuite/c-c++-common/Wrestrict.c
@@ -381,14 +381,14 @@ void test_memcpy_range_exceed (char *d, const char *s)
T (d + i, s + 1, 3); /* { dg-warning "accessing 3 bytes at offsets \\\[\[0-9\]+,
\[0-9\]+] and 1 overlaps 1 byte" "memcpy" } */
#if __SIZEOF_SIZE_T__ == 8
- /* Verfiy the offset and size computation is correct. The overlap
- offset mentioned in the warning plus sthe size of the access must
+ /* Verify the offset and size computation is correct. The overlap
+ offset mentioned in the warning plus the size of the access must
not exceed DIFF_MAX. */
- T (d, d + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and
\\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset 9223372036854775802"
"LP64" { target lp64 } } */
- T (d + i, d, 5); /* { dg-warning "accessing 5 bytes at offsets \\\[9223372036854775805,
9223372036854775807] and 0 overlaps 3 bytes at offset 9223372036854775802" "LP64" {
target lp64 } } */
+ T (d, d + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and
\\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset 9223372036854775802"
"LP64" { target { lp64 || llp64 } } } */
+ T (d + i, d, 5); /* { dg-warning "accessing 5 bytes at offsets \\\[9223372036854775805,
9223372036854775807] and 0 overlaps 3 bytes at offset 9223372036854775802" "LP64" {
target { lp64 || llp64 } } } */
- T (d, s + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and \\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset 9223372036854775802" "LP64" { target lp64 } } */
- T (d + i, s, 5); /* { dg-warning "accessing 5 bytes at offsets \\\[9223372036854775805,
9223372036854775807] and 0 overlaps 3 bytes at offset 9223372036854775802" "LP64" {
target lp64 } } */
+ T (d, s + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and
\\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset 9223372036854775802"
"LP64" { target { lp64 || llp64 } } } */
+ T (d + i, s, 5); /* { dg-warning "accessing 5 bytes at offsets \\\[9223372036854775805,
9223372036854775807] and 0 overlaps 3 bytes at offset 9223372036854775802" "LP64" {
target { lp64 || llp64 } } } */
#elif __SIZEOF_SIZE_T__ == 4
T (d, d + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and \\\[2147483645,
2147483647] overlaps 3 bytes at offset 2147483642" "ILP32" { target ilp32 } } */
T (d + i, d, 5); /* { dg-warning "accessing 5 bytes at offsets \\\[2147483645,
2147483647] and 0 overlaps 3 bytes at offset 2147483642" "ILP32" { target ilp32 } }
*/From 57b2310756b5d0de99fbdbf7b0b11f01fe66be11 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Sun, 11 Feb 2024 09:25:25 +
Subject: [PATCH] c-c++-common/Wrestrict.c: fix some typos and enable for LLP64
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
gcc/testsuite:
* c-c++-common/Wrestrict.c: Fix typos in comments and
enable for LLP64 testing.
---
gcc/testsuite/c-c++-common/Wrestrict.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/gcc/testsuite/c-c++-common/Wrestrict.c b/gcc/testsuite/c-c++-common/Wrestrict.c
index 4d005a618b3..57a3f67e21e 100644
--- a/gcc/testsuite/c-c++-common/Wrestrict.c
+++ b/gcc/testsuite/c-c++-common/Wrestrict.c
@@ -381,14 +381,14 @@ void test_memcpy_range_exceed (char *d, const char *s)
T (d + i, s + 1, 3); /* { dg-warning "accessing 3 bytes at offsets \\\[\[0-9\]+, \[0-9\]+] and 1 overlaps 1 byte" "memcpy" } */
#if __SIZEOF_SIZE_T__ == 8
- /* Verfiy the offset and size computation is correct. The overlap
- offset mentioned in the warning plus sthe size of the access must
+ /* Verify the offset and size computation is correct. The overlap
+ offset mentioned in the warning plus the size of the access must
not exceed DIFF_MAX. */
- T (d, d + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and \\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset 9223372036854775802" "LP64" { target lp64 } } */
- T (d + i, d, 5); /* { dg-warning "accessing 5 bytes at offsets \\\[9223372036854775805, 9223372036854775807] and 0 overlaps 3 bytes at offset 9223372036854775802" "LP64" { target lp64 } } */
+ T (d, d + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and \\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset 9223372036854775802" "LP64" { targ
Re: [PATCH] libgcc: fix Win32 CV abnormal spurious wakeups in timed wait [PR113850]
On 2/10/24 10:10, Matteo Italia wrote: Il 09/02/24 15:18, Matteo Italia ha scritto: The Win32 threading model uses __gthr_win32_abs_to_rel_time to convert the timespec used in gthreads to specify the absolute time for end of the condition variables timed wait to a milliseconds value relative to "now" to pass to the Win32 SleepConditionVariableCS function. Unfortunately, the conversion is incorrect, as, due to a typo, it returns the relative time _in seconds_, so SleepConditionVariableCS receives a timeout value 1000 times shorter than it should be, resulting in a huge amount of spurious wakeups in calls such as std::condition_variable::wait_for or wait_until. Re-reading the commit message I found a few typos, and it was generally a bit more obscure than I like; reworded it now, hope it's better. Thanks, pushed to master and 13.x branches.
Re: [PATCH] libgcc: fix Win32 CV abnormal spurious wakeups in timed wait [PR113850]
On 2/19/24 13:48, Matteo Italia wrote: Il 17/02/24 01:24, Jonathan Yong ha scritto: On 2/10/24 10:10, Matteo Italia wrote: Il 09/02/24 15:18, Matteo Italia ha scritto: The Win32 threading model uses __gthr_win32_abs_to_rel_time to convert the timespec used in gthreads to specify the absolute time for end of the condition variables timed wait to a milliseconds value relative to "now" to pass to the Win32 SleepConditionVariableCS function. Unfortunately, the conversion is incorrect, as, due to a typo, it returns the relative time _in seconds_, so SleepConditionVariableCS receives a timeout value 1000 times shorter than it should be, resulting in a huge amount of spurious wakeups in calls such as std::condition_variable::wait_for or wait_until. Re-reading the commit message I found a few typos, and it was generally a bit more obscure than I like; reworded it now, hope it's better. Thanks, pushed to master and 13.x branches. Great, thank you! Do I need to change the status of the Bugzilla entry to RESOLVED, or it's going to be closed automatically at the next releases, or something else? Closed as resolved, thanks.
Re: [PATCH] c-c++-common/Wrestrict.c: fix some typos and enable for LLP64
On 2/15/24 14:08, Jonathan Yong wrote: Attached patch OK? Copy/pasted for review convenience. Ping.
Re: [PATCH] c-c++-common/Wrestrict.c: fix some typos and enable for LLP64
On 3/17/24 17:38, Mike Stump wrote:
On Feb 15, 2024, at 6:08 AM, Jonathan Yong wrote:
Attached patch OK?
Ok.
Copy/pasted for review convenience.
diff --git a/gcc/testsuite/c-c++-common/Wrestrict.c
b/gcc/testsuite/c-c++-common/Wrestrict.c
index 4d005a618b3..57a3f67e21e 100644
--- a/gcc/testsuite/c-c++-common/Wrestrict.c
+++ b/gcc/testsuite/c-c++-common/Wrestrict.c
@@ -381,14 +381,14 @@ void test_memcpy_range_exceed (char *d, const char *s)
T (d + i, s + 1, 3); /* { dg-warning "accessing 3 bytes at offsets \\\[\[0-9\]+,
\[0-9\]+] and 1 overlaps 1 byte" "memcpy" } */
#if __SIZEOF_SIZE_T__ == 8
- /* Verfiy the offset and size computation is correct. The overlap
- offset mentioned in the warning plus sthe size of the access must
+ /* Verify the offset and size computation is correct. The overlap
+ offset mentioned in the warning plus the size of the access must
not exceed DIFF_MAX. */
- T (d, d + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and
\\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset 9223372036854775802"
"LP64" { target lp64 } } */
- T (d + i, d, 5); /* { dg-warning "accessing 5 bytes at offsets \\\[9223372036854775805,
9223372036854775807] and 0 overlaps 3 bytes at offset 9223372036854775802" "LP64" {
target lp64 } } */
+ T (d, d + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and
\\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset 9223372036854775802"
"LP64" { target { lp64 || llp64 } } } */
+ T (d + i, d, 5); /* { dg-warning "accessing 5 bytes at offsets \\\[9223372036854775805,
9223372036854775807] and 0 overlaps 3 bytes at offset 9223372036854775802" "LP64" {
target { lp64 || llp64 } } } */
- T (d, s + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and
\\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset 9223372036854775802"
"LP64" { target lp64 } } */
- T (d + i, s, 5); /* { dg-warning "accessing 5 bytes at offsets \\\[9223372036854775805,
9223372036854775807] and 0 overlaps 3 bytes at offset 9223372036854775802" "LP64" {
target lp64 } } */
+ T (d, s + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and
\\\[9223372036854775805, 9223372036854775807] overlaps 3 bytes at offset 9223372036854775802"
"LP64" { target { lp64 || llp64 } } } */
+ T (d + i, s, 5); /* { dg-warning "accessing 5 bytes at offsets \\\[9223372036854775805,
9223372036854775807] and 0 overlaps 3 bytes at offset 9223372036854775802" "LP64" {
target { lp64 || llp64 } } } */
#elif __SIZEOF_SIZE_T__ == 4
T (d, d + i, 5); /* { dg-warning "accessing 5 bytes at offsets 0 and \\\[2147483645,
2147483647] overlaps 3 bytes at offset 2147483642" "ILP32" { target ilp32 } } */
T (d + i, d, 5); /* { dg-warning "accessing 5 bytes at offsets \\\[2147483645, 2147483647] and
0 overlaps 3 bytes at offset 2147483642" "ILP32" { target ilp32 } }
*/<0001-c-c-common-Wrestrict.c-fix-some-typos-and-enable-for.patch>
Thanks all, pushed to master branch.
[PATCH] Simplify \r handling
Simplify \r checking with regex globs.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
gcc/testsuite
* g++.dg/contracts/contracts14.C: simplify \r regex.
* g++.dg/contracts/contracts15.C: ditto
* g++.dg/contracts/contracts16.C: ditto
* g++.dg/coroutines/torture/mid-suspend-destruction-0.C: ditto
---
gcc/testsuite/g++.dg/contracts/contracts14.C | 12 ++--
gcc/testsuite/g++.dg/contracts/contracts15.C | 8
gcc/testsuite/g++.dg/contracts/contracts16.C | 4 ++--
.../coroutines/torture/mid-suspend-destruction-0.C | 8
4 files changed, 16 insertions(+), 16 deletions(-)
Attached patch Okay?From b64524632e236b2476d5eced8315c2ba8bece315 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Sun, 11 Feb 2024 09:26:20 +
Subject: [PATCH] Simplify \r handling
Simplify \r checking with regex globs.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
gcc/testsuite
* g++.dg/contracts/contracts14.C: simplify \r regex.
* g++.dg/contracts/contracts15.C: ditto
* g++.dg/contracts/contracts16.C: ditto
* g++.dg/coroutines/torture/mid-suspend-destruction-0.C: ditto
---
gcc/testsuite/g++.dg/contracts/contracts14.C | 12 ++--
gcc/testsuite/g++.dg/contracts/contracts15.C | 8
gcc/testsuite/g++.dg/contracts/contracts16.C | 4 ++--
.../coroutines/torture/mid-suspend-destruction-0.C | 8
4 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/gcc/testsuite/g++.dg/contracts/contracts14.C b/gcc/testsuite/g++.dg/contracts/contracts14.C
index d9156d6875d..fb2884b8cb2 100644
--- a/gcc/testsuite/g++.dg/contracts/contracts14.C
+++ b/gcc/testsuite/g++.dg/contracts/contracts14.C
@@ -48,11 +48,11 @@ int main(int, char**) {
return 0;
}
-// { dg-output "custom std::handle_contract_violation called: 30 .*/contracts14.C(\n|\r\n|\r)" }
-// { dg-output "synth caught direct: -30(\n|\r\n|\r)" }
-// { dg-output "custom std::handle_contract_violation called: 18 .*/contracts14.C(\n|\r\n|\r)" }
-// { dg-output "synth caught indirect: -18(\n|\r\n|\r)" }
-// { dg-output "custom std::handle_contract_violation called: 18 .*/contracts14.C(\n|\r\n|\r)" }
-// { dg-output "synth caught double indirect: -18(\n|\r\n|\r)" }
+// { dg-output "custom std::handle_contract_violation called: 30 .*/contracts14.C\r*\n+" }
+// { dg-output "synth caught direct: -30\r*\n+" }
+// { dg-output "custom std::handle_contract_violation called: 18 .*/contracts14.C\r*\n+" }
+// { dg-output "synth caught indirect: -18\r*\n+" }
+// { dg-output "custom std::handle_contract_violation called: 18 .*/contracts14.C\r*\n+" }
+// { dg-output "synth caught double indirect: -18\r*\n+" }
// { dg-output "end main" }
diff --git a/gcc/testsuite/g++.dg/contracts/contracts15.C b/gcc/testsuite/g++.dg/contracts/contracts15.C
index ef52a0e67f0..58db940518a 100644
--- a/gcc/testsuite/g++.dg/contracts/contracts15.C
+++ b/gcc/testsuite/g++.dg/contracts/contracts15.C
@@ -48,9 +48,9 @@ int main(int, char**) {
return 0;
}
-// { dg-output "custom std::handle_contract_violation called: 30 .*/contracts15.C(\n|\r\n|\r)" }
-// { dg-output "synth caught direct: -30(\n|\r\n|\r)" }
-// { dg-output "custom std::handle_contract_violation called: 18 .*/contracts15.C(\n|\r\n|\r)" }
-// { dg-output "terminate called after throwing an instance of .int.(\n|\r\n|\r)" }
+// { dg-output "custom std::handle_contract_violation called: 30 .*/contracts15.C\r*\n+" }
+// { dg-output "synth caught direct: -30\r*\n+" }
+// { dg-output "custom std::handle_contract_violation called: 18 .*/contracts15.C\r*\n+" }
+// { dg-output "terminate called after throwing an instance of .int.\r*\n+" }
// { dg-shouldfail "throwing in noexcept" }
diff --git a/gcc/testsuite/g++.dg/contracts/contracts16.C b/gcc/testsuite/g++.dg/contracts/contracts16.C
index 5d58ab8eaa1..9e1688ba51b 100644
--- a/gcc/testsuite/g++.dg/contracts/contracts16.C
+++ b/gcc/testsuite/g++.dg/contracts/contracts16.C
@@ -29,6 +29,6 @@ int main(int, char**) {
return 0;
}
-// { dg-output "custom std::handle_contract_violation called: 18 .*/contracts16.C(\n|\r\n|\r)" }
-// { dg-output "synth caught indirect: -18(\n|\r\n|\r)" }
+// { dg-output "custom std::handle_contract_violation called: 18 .*/contracts16.C\r*\n+" }
+// { dg-output "synth caught indirect: -18\r*\n+" }
diff --git a/gcc/testsuite/g++.dg/coroutines/torture/mid-suspend-destruction-0.C b/gcc/testsuite/g++.dg/coroutines/torture/mid-suspend-destruction-0.C
index 0cbf93ad8af..00d6d58c3b1 100644
--- a/gcc/testsuite/g++.dg/coroutines/torture/mid-suspend-destruction-0.C
+++ b/gcc/testsuite/g++.dg/coroutines/torture/mid-suspend-destruction-0.C
Re: [RFC] Either fix or disable SME feature for `aarch64-w64-mingw32` target?
On 1/9/24 19:37, Radek Barton wrote: Hello. I forgot to add the target maintainers to the CC. My apologies for that. Furthermore, I am adding also relevant changes in `libgcc/config/aarch64/lse.S` file to the patch. Originally we wanted to submit those changes separately but after the feedback from Andrew Pinski, it makes sense to add them here. I needed to rename `HIDDEN`, `TYPE`, and `SIZE` macros to `HIDDEN_PO`, `TYPE_PO`, and `SIZE_PO` (pseudo-op) because there is a collision with other macro named `SIZE` in the `lse.S` file. Best regards, Radek Looks fine to me, but is __ELF__ correct? I am not familiar with pseudo-ops, OK if it is ELF specific when PE is targeted.
Re: Ping: Re: [PATCH] libgcc: fix SEH C++ rethrow semantics [PR113337]
On 1/24/24 15:17, Matteo Italia wrote:
Ping! That's a one-line fix, and you can find all the details in the
bugzilla entry. Also, I can provide executables built with the affected
toolchains, demonstrating the problem and the fix.
Thanks,
Matteo
I was away last week. LH, care to comment? Changes look fine to me.
Il 17/01/24 12:51, Matteo Italia ha scritto:
SEH _Unwind_Resume_or_Rethrow invokes abort directly if
_Unwind_RaiseException doesn't manage to find a handler for the rethrown
exception; this is incorrect, as in this case std::terminate should be
invoked, allowing an application-provided terminate handler to handle
the situation instead of straight crashing the application through
abort.
The bug can be demonstrated with this simple test case:
===
static void custom_terminate_handler() {
fprintf(stderr, "custom_terminate_handler invoked\n");
std::exit(1);
}
int main(int argc, char *argv[]) {
std::set_terminate(&custom_terminate_handler);
if (argc < 2) return 1;
const char *mode = argv[1];
fprintf(stderr, "%s\n", mode);
if (strcmp(mode, "throw") == 0) {
throw std::exception();
} else if (strcmp(mode, "rethrow") == 0) {
try {
throw std::exception();
} catch (...) {
throw;
}
} else {
return 1;
}
return 0;
}
===
On all gcc builds with non-SEH exceptions, this will print
"custom_terminate_handler invoked" both if launched as ./a.out throw or
as ./a.out rethrow, on SEH builds instead if will work as expected only
with ./a.exe throw, but will crash with the "built-in" abort message
with ./a.exe rethrow.
This patch fixes the problem, forwarding back the error code to the
caller (__cxa_rethrow), that calls std::terminate if
_Unwind_Resume_or_Rethrow returns.
The change makes the code path coherent with SEH _Unwind_RaiseException,
and with the generic _Unwind_Resume_or_Rethrow from libgcc/unwind.inc
(used for SjLj and Dw2 exception backend).
libgcc/ChangeLog:
* unwind-seh.c (_Unwind_Resume_or_Rethrow): forward
_Unwind_RaiseException return code back to caller instead of
calling abort, allowing __cxa_rethrow to invoke std::terminate
in case of uncaught rethrown exception
---
libgcc/unwind-seh.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libgcc/unwind-seh.c b/libgcc/unwind-seh.c
index 8ef0257b616..f1b8f5a8519 100644
--- a/libgcc/unwind-seh.c
+++ b/libgcc/unwind-seh.c
@@ -395,9 +395,9 @@ _Unwind_Reason_Code
_Unwind_Resume_or_Rethrow (struct _Unwind_Exception *exc)
{
if (exc->private_[0] == 0)
- _Unwind_RaiseException (exc);
- else
- _Unwind_ForcedUnwind_Phase2 (exc);
+ return _Unwind_RaiseException (exc);
+
+ _Unwind_ForcedUnwind_Phase2 (exc);
abort ();
}
[PATCH] uninit-pr108968-register.c: use __UINTPTR_TYPE__ for LLP64
Ensure sp variable is long enough by using __UINTPTR_TYPE__ for
rsp.
Attached patch okay? Changes unsigned long to __UINTPTR_TYPE__.From 8b5e79e1345d99ec6d3595013a20a9c672edb403 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Wed, 31 Jan 2024 13:31:30 +
Subject: [PATCH] uninit-pr108968-register.c: use __UINTPTR_TYPE__ for LLP64
Ensure sp variable is long enough by using __UINTPTR_TYPE__ for
rsp.
gcc/testsuite/ChangeLog:
* c-c++-common/analyzer/uninit-pr108968-register.c:
Use __UINTPTR_TYPE__ instead of unsigned long for LLP64.
---
gcc/testsuite/c-c++-common/analyzer/uninit-pr108968-register.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/c-c++-common/analyzer/uninit-pr108968-register.c b/gcc/testsuite/c-c++-common/analyzer/uninit-pr108968-register.c
index a76c09e7b14..e9a1c21990b 100644
--- a/gcc/testsuite/c-c++-common/analyzer/uninit-pr108968-register.c
+++ b/gcc/testsuite/c-c++-common/analyzer/uninit-pr108968-register.c
@@ -4,6 +4,6 @@
struct cpu_info {};
struct cpu_info *get_cpu_info(void)
{
- register unsigned long sp asm("rsp");
+ register __UINTPTR_TYPE__ sp asm("rsp");
return (struct cpu_info *)((sp | (STACK_SIZE - 1)) + 1) - 1; /* { dg-bogus "use of uninitialized value 'sp'" } */
}
--
2.43.0
Re: [PATCH] uninit-pr108968-register.c: use __UINTPTR_TYPE__ for LLP64
On 1/31/24 13:52, Richard Biener wrote: On Wed, Jan 31, 2024 at 2:39 PM Jonathan Yong <10wa...@gmail.com> wrote: Ensure sp variable is long enough by using __UINTPTR_TYPE__ for rsp. Attached patch okay? Changes unsigned long to __UINTPTR_TYPE__. OK. Thanks, pushed to master branch.
[PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu
Attached patch OK? Copied inline for review convenience. diff --git a/gcc/ira-conflicts.cc b/gcc/ira-conflicts.cc index 671b4e42b6f..e966afe6cdc 100644 --- a/gcc/ira-conflicts.cc +++ b/gcc/ira-conflicts.cc @@ -150,9 +150,9 @@ build_conflict_bit_table (void) if (internal_flag_ira_verbose > 0 && ira_dump_file != NULL) fprintf (ira_dump_file, - "+++Allocating %ld bytes for conflict table (uncompressed size %ld)\n", - (long) allocated_words_num * sizeof (IRA_INT_TYPE), - (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)); + "+++Allocating %zu bytes for conflict table (uncompressed size %zu)\n", + (size_t)(allocated_words_num * sizeof (IRA_INT_TYPE)), + (size_t)(object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE))); objects_live = sparseset_alloc (ira_objects_num); for (i = 0; i < ira_max_point; i++)From 48861b8578526ac199b123ff71af8f9778c396c3 Mon Sep 17 00:00:00 2001 From: Jonathan Yong <10wa...@gmail.com> Date: Thu, 1 Feb 2024 12:35:52 + Subject: [PATCH] PR target/43613: use %zu for build_conflict_bit_table LLP64 platforms like uses 32bit for long and may truncate. Use size_t and %zu to guarantee 64bit lengths. gcc: *ira-conflicts.cc: use %zu for build_conflict_bit_table. --- gcc/ira-conflicts.cc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gcc/ira-conflicts.cc b/gcc/ira-conflicts.cc index 671b4e42b6f..e966afe6cdc 100644 --- a/gcc/ira-conflicts.cc +++ b/gcc/ira-conflicts.cc @@ -150,9 +150,9 @@ build_conflict_bit_table (void) if (internal_flag_ira_verbose > 0 && ira_dump_file != NULL) fprintf (ira_dump_file, - "+++Allocating %ld bytes for conflict table (uncompressed size %ld)\n", - (long) allocated_words_num * sizeof (IRA_INT_TYPE), - (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)); + "+++Allocating %zu bytes for conflict table (uncompressed size %zu)\n", + (size_t)(allocated_words_num * sizeof (IRA_INT_TYPE)), + (size_t)(object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE))); objects_live = sparseset_alloc (ira_objects_num); for (i = 0; i < ira_max_point; i++) -- 2.43.0
Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu
On 2/1/24 13:06, Xi Ruoyao wrote: On Thu, 2024-02-01 at 14:01 +0100, Jakub Jelinek wrote: On Thu, Feb 01, 2024 at 12:45:31PM +, Jonathan Yong wrote: Attached patch OK? Copied inline for review convenience. No, I think e.g. AIX doesn't support the z modifier. I don't see %zd or %zu used anywhere except in gcc/jit/ which presumably doesn't work on AIX. Should use HOST_WIDE_INT_PRINT_UNSIGNED instead of PRIu64. Updated the patch with the suggestions. diff --git a/gcc/ira-conflicts.cc b/gcc/ira-conflicts.cc index 671b4e42b6f..32688f9dc39 100644 --- a/gcc/ira-conflicts.cc +++ b/gcc/ira-conflicts.cc @@ -150,9 +150,9 @@ build_conflict_bit_table (void) if (internal_flag_ira_verbose > 0 && ira_dump_file != NULL) fprintf (ira_dump_file, - "+++Allocating %ld bytes for conflict table (uncompressed size %ld)\n", - (long) allocated_words_num * sizeof (IRA_INT_TYPE), - (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)); + "+++Allocating "HOST_WIDE_INT_PRINT_UNSIGNED" bytes for conflict table (uncompressed size "HOST_WIDE_INT_PRINT_UNSIGNED")\n", + (size_t)(allocated_words_num * sizeof (IRA_INT_TYPE)), + (size_t)(object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE))); objects_live = sparseset_alloc (ira_objects_num); for (i = 0; i < ira_max_point; i++)From 8d3294370404ceda3177bdd8fa7749bfc4d64bc6 Mon Sep 17 00:00:00 2001 From: Jonathan Yong <10wa...@gmail.com> Date: Thu, 1 Feb 2024 12:35:52 + Subject: [PATCH] PR target/43613: use HOST_WIDE_INT_PRINT_UNSIGNED for build_conflict_bit_table LLP64 platforms like uses 32bit for long and may truncate. Use size_t and HOST_WIDE_INT_PRINT_UNSIGNED to guarantee 64bit lengths. gcc: *ira-conflicts.cc (build_conflict_bit_table): use HOST_WIDE_INT_PRINT_UNSIGNED. --- gcc/ira-conflicts.cc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gcc/ira-conflicts.cc b/gcc/ira-conflicts.cc index 671b4e42b6f..32688f9dc39 100644 --- a/gcc/ira-conflicts.cc +++ b/gcc/ira-conflicts.cc @@ -150,9 +150,9 @@ build_conflict_bit_table (void) if (internal_flag_ira_verbose > 0 && ira_dump_file != NULL) fprintf (ira_dump_file, - "+++Allocating %ld bytes for conflict table (uncompressed size %ld)\n", - (long) allocated_words_num * sizeof (IRA_INT_TYPE), - (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)); + "+++Allocating "HOST_WIDE_INT_PRINT_UNSIGNED" bytes for conflict table (uncompressed size "HOST_WIDE_INT_PRINT_UNSIGNED")\n", + (size_t)(allocated_words_num * sizeof (IRA_INT_TYPE)), + (size_t)(object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE))); objects_live = sparseset_alloc (ira_objects_num); for (i = 0; i < ira_max_point; i++) -- 2.43.0
Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu
On 2/1/24 14:33, Xi Ruoyao wrote: I mean if you are casting it to unsigned HOST_WIDE_INT, you should use HOST_WIDE_INT_PRINT_UNSIGNED, If you are casting it to size_t you cannot use it (as Jakub has explained). When you use printf-like things you have to keep the correspondence between format specifier and the argument itself, No, that is wrong. That will break bootstrap on lots of hosts, any time size_t is not unsigned long (if unsigned long is 64-bit) or unsigned long long (if unsigned long is not 64-bit). That includes e.g. all targets where size_t is unsigned int, and some others too. Jakub Thanks, that makes sense, tested on x86_64-linux. diff --git a/gcc/ira-conflicts.cc b/gcc/ira-conflicts.cc index 671b4e42b6f..ff5db18ffcc 100644 --- a/gcc/ira-conflicts.cc +++ b/gcc/ira-conflicts.cc @@ -150,9 +150,9 @@ build_conflict_bit_table (void) if (internal_flag_ira_verbose > 0 && ira_dump_file != NULL) fprintf (ira_dump_file, - "+++Allocating %ld bytes for conflict table (uncompressed size %ld)\n", - (long) allocated_words_num * sizeof (IRA_INT_TYPE), - (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)); + "+++Allocating "HOST_WIDE_INT_PRINT_UNSIGNED" bytes for conflict table (uncompressed size "HOST_WIDE_INT_PRINT_UNSIGNED")\n", + (unsigned HOST_WIDE_INT)(allocated_words_num * sizeof (IRA_INT_TYPE)), + (unsigned HOST_WIDE_INT)(object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE))); objects_live = sparseset_alloc (ira_objects_num); for (i = 0; i < ira_max_point; i++)From ab44628feca0b200aaaa2d3344af1a96cb1437c0 Mon Sep 17 00:00:00 2001 From: Jonathan Yong <10wa...@gmail.com> Date: Thu, 1 Feb 2024 12:35:52 + Subject: [PATCH] PR target/43613: use HOST_WIDE_INT_PRINT_UNSIGNED for build_conflict_bit_table LLP64 platforms like uses 32bit for long and may truncate. Use unsigned HOST_WIDE_INT and HOST_WIDE_INT_PRINT_UNSIGNED to guarantee 64bit widths. gcc: *ira-conflicts.cc (build_conflict_bit_table): use unsigned HOST_WIDE_INT and HOST_WIDE_INT_PRINT_UNSIGNED. --- gcc/ira-conflicts.cc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gcc/ira-conflicts.cc b/gcc/ira-conflicts.cc index 671b4e42b6f..ff5db18ffcc 100644 --- a/gcc/ira-conflicts.cc +++ b/gcc/ira-conflicts.cc @@ -150,9 +150,9 @@ build_conflict_bit_table (void) if (internal_flag_ira_verbose > 0 && ira_dump_file != NULL) fprintf (ira_dump_file, - "+++Allocating %ld bytes for conflict table (uncompressed size %ld)\n", - (long) allocated_words_num * sizeof (IRA_INT_TYPE), - (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)); + "+++Allocating "HOST_WIDE_INT_PRINT_UNSIGNED" bytes for conflict table (uncompressed size "HOST_WIDE_INT_PRINT_UNSIGNED")\n", + (unsigned HOST_WIDE_INT)(allocated_words_num * sizeof (IRA_INT_TYPE)), + (unsigned HOST_WIDE_INT)(object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE))); objects_live = sparseset_alloc (ira_objects_num); for (i = 0; i < ira_max_point; i++) -- 2.43.0
Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu
On 2/1/24 15:25, Jakub Jelinek wrote:
On Thu, Feb 01, 2024 at 03:55:51PM +0100, Jakub Jelinek wrote:
No, besides the formatting being incorrect both in ChangeLog and in the
patch, this pessimizes ILP32 hosts unnecessarily.
So like this instead?
2024-02-01 Jakub Jelinek
* hwint.h (GCC_PRISZ, fmt_size_t, HOST_SIZE_T_PRINT_DEC,
HOST_SIZE_T_PRINT_UNSIGNED, HOST_SIZE_T_PRINT_HEX,
HOST_SIZE_T_PRINT_HEX_PURE): Define.
* ira-conflicts.cc (build_conflict_bit_table): Use it. Formatting
fixes.
--- gcc/hwint.h.jj 2024-01-03 11:51:32.676715299 +0100
+++ gcc/hwint.h 2024-02-01 16:22:53.037013522 +0100
@@ -115,6 +115,27 @@ typedef HOST_WIDE_INT __gcc_host_wide_in
#define HOST_WIDE_INT_PRINT_DOUBLE_HEX "0x%" PRIx64 "%016" PRIx64
#define HOST_WIDE_INT_PRINT_PADDED_HEX "%016" PRIx64
+/* Similarly format modifier for printing size_t. As not all hosts support
+ z modifier in printf, use GCC_PRISZ and cast argument to fmt_size_t.
+ So, instead of doing fprintf ("%zu\n", sizeof (x) * y); use
+ fprintf (HOST_SIZE_T_PRINT_UNSIGNED "\n",
+ (fmt_size_t) (sizeof (x) * y)); */
+#if SIZE_MAX <= INT_MAX
+# define GCC_PRISZ ""
+# define fmt_size_t unsigned int
+#elif SIZE_MAX <= LONG_MAX
+# define GCC_PRISZ HOST_LONG_FORMAT
+# define fmt_size_t unsigned long int
+#else
+# define GCC_PRISZ HOST_LONG_LONG_FORMAT
+# define fmt_size_t unsigned long long int
+#endif
+
+#define HOST_SIZE_T_PRINT_DEC "%" GCC_PRISZ "d"
+#define HOST_SIZE_T_PRINT_UNSIGNED "%" GCC_PRISZ "u"
+#define HOST_SIZE_T_PRINT_HEX "%#" GCC_PRISZ "x"
+#define HOST_SIZE_T_PRINT_HEX_PURE "%" GCC_PRISZ "x"
+
...
- (ira_dump_file,
- "+++Allocating %ld bytes for conflict table (uncompressed size %ld)\n",
- (long) allocated_words_num * sizeof (IRA_INT_TYPE),
- (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE));
+fprintf (ira_dump_file,
+"+++Allocating " HOST_SIZE_T_PRINT_UNSIGNED
+" bytes for conflict table (uncompressed size "
+HOST_SIZE_T_PRINT_UNSIGNED ")\n",
+(fmt_size_t) (sizeof (IRA_INT_TYPE) * allocated_words_num),
+(fmt_size_t) (sizeof (IRA_INT_TYPE) * object_set_words
+ * ira_objects_num));
objects_live = sparseset_alloc (ira_objects_num);
for (i = 0; i < ira_max_point; i++)
Jakub
Looks good for ILP32/LLP64.
Re: [PATCH] Change gcc/ira-conflicts.cc build_conflict_bit_table to use size_t/%zu
On 2/1/24 15:33, Jonathan Yong wrote: On 2/1/24 15:25, Jakub Jelinek wrote: On Thu, Feb 01, 2024 at 03:55:51PM +0100, Jakub Jelinek wrote: No, besides the formatting being incorrect both in ChangeLog and in the patch, this pessimizes ILP32 hosts unnecessarily. So like this instead? 2024-02-01 Jakub Jelinek * hwint.h (GCC_PRISZ, fmt_size_t, HOST_SIZE_T_PRINT_DEC, HOST_SIZE_T_PRINT_UNSIGNED, HOST_SIZE_T_PRINT_HEX, HOST_SIZE_T_PRINT_HEX_PURE): Define. * ira-conflicts.cc (build_conflict_bit_table): Use it. Formatting fixes. Looks good for ILP32/LLP64. Are you planning to push yet?
[PATCH] coreutils-sum-pr108666.c: fix spurious LLP64 warnings
Attached patch OK? Fixes the following warnings: coreutils-sum-pr108666.c:17:1: warning: conflicting types for built-in function ‘memcpy’; expected ‘void *(void *, const void *, long long unsigned int)’ [-Wbuiltin-declaration-mismatch] 17 | memcpy(void* __restrict __dest, const void* __restrict __src, size_t __n) | ^~ coreutils-sum-pr108666.c:25:1: warning: conflicting types for built-in function ‘malloc’; expected ‘void *(long long unsigned int)’ [-Wbuiltin-declaration-mismatch] 25 | malloc(size_t __size) __attribute__((__nothrow__, __leaf__)) | ^~ Copied for review convenience: diff --git a/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c b/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c index 5684d1b02d4..dadd27eaf41 100644 --- a/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c +++ b/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c @@ -1,6 +1,6 @@ /* Reduced from coreutils's sum.c: bsd_sum_stream */ -typedef long unsigned int size_t; +typedef __SIZE_TYPE__ size_t; typedef unsigned char __uint8_t; typedef unsigned long int __uintmax_t; typedef struct _IO_FILE FILE;From 54731e86e4bdce03ef4a722860ea8cee931ec127 Mon Sep 17 00:00:00 2001 From: Jonathan Yong <10wa...@gmail.com> Date: Fri, 2 Feb 2024 23:47:47 + Subject: [PATCH] coreutils-sum-pr108666.c: fix spurious LLP64 warnings MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fixes the following warnings on x86_64-w64-mingw32: coreutils-sum-pr108666.c:17:1: warning: conflicting types for built-in function ‘memcpy’; expected ‘void *(void *, const void *, long long unsigned int)’ [-Wbuiltin-declaration-mismatch] 17 | memcpy(void* __restrict __dest, const void* __restrict __src, size_t __n) | ^~ coreutils-sum-pr108666.c:25:1: warning: conflicting types for built-in function ‘malloc’; expected ‘void *(long long unsigned int)’ [-Wbuiltin-declaration-mismatch] 25 | malloc(size_t __size) __attribute__((__nothrow__, __leaf__)) | ^~ gcc/testsuite: * coreutils-sum-pr108666.c: Use __SIZE_TYPE__ instead of long unsigned int for size_t definition. Signed-off-by: Jonathan Yong <10wa...@gmail.com> --- gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c b/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c index 5684d1b02d4..dadd27eaf41 100644 --- a/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c +++ b/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c @@ -1,6 +1,6 @@ /* Reduced from coreutils's sum.c: bsd_sum_stream */ -typedef long unsigned int size_t; +typedef __SIZE_TYPE__ size_t; typedef unsigned char __uint8_t; typedef unsigned long int __uintmax_t; typedef struct _IO_FILE FILE; -- 2.43.0
Re: [PATCH] libstdc++: /dev/null is not accessible on Windows
On 2/5/24 19:38, Jonathan Wakely wrote: On Mon, 5 Feb 2024, 19:07 Torbjörn SVENSSON, wrote: Ok for trunk and releases/gcc-13? OK, thanks Done, pushed to master and releases/gcc-13.
Re: Ping: Re: [PATCH] libgcc: fix SEH C++ rethrow semantics [PR113337]
On 2/6/24 05:31, NightStrike wrote: On Mon, Feb 5, 2024, 06:53 Matteo Italia wrote: Il 31/01/24 04:24, LIU Hao ha scritto: 在 2024-01-31 08:08, Jonathan Yong 写道: On 1/24/24 15:17, Matteo Italia wrote: Ping! That's a one-line fix, and you can find all the details in the bugzilla entry. Also, I can provide executables built with the affected toolchains, demonstrating the problem and the fix. Thanks, Matteo I was away last week. LH, care to comment? Changes look fine to me. The change looks good to me, too. I haven't tested it though. According to a similar construction around 'libgcc/unwind.inc:265' it should be that way. Hello, thank you for the replies, is there anything else I can do to help push this forward? Remember to mention the pr with the right syntax in the ChangeLog so the bot adds a comment field. I didn't see it in yours, but I might have missed it. Thanks all, pushed to master branch.
Re: [PATCH v2] Define which threading model is in use on Windows
On 5/27/24 05:16, Julian Waters wrote: Hi all, Please review a trivial change that defines which threading model is used on Windows, so applications can check it. This is also useful for system headers, since some headers should be switched off if pthread is the threading model (Currently they are included unconditionally on Windows). In effect this merely reworks some existing code that defines __USING_MCFGTHREAD__ and adds some new logic to it to define __USING_POSIXTHREAD__ whenever appropriate. Do note that I don't have any write access, so whoever reviews this for me has to help me push it as well best regards, Julian P.S. This has been resent since my email client kept mangling the tabs, so I had to send it as a patch file instead gcc/config/mingw/ChangeLog: * mingw32.h: Add new define for POSIX threads Looks good to me, pushed to master branch.
Re: [PATCH v1 0/6] Add DLL import/export implementation to AArch64
On 6/5/24 06:01, Uros Bizjak wrote:
On Tue, Jun 4, 2024 at 10:10 PM Evgeny Karpov
wrote:
Richard and Uros, could you please review the changes for v2?
LGTM for the generic x86 part, OS-specific part (cygming) should also
be reviewed by OS port maintainer (CC'd).
Thanks,
Uros.
Where is HAVE_64BIT_POINTERS used?
Additionally, we have detected an issue with GCC GC in winnt-dll.cc. The fix
will be included in v2.
-ix86_handle_selectany_attribute (tree *node, tree name, tree, int,
+mingw_handle_selectany_attribute (tree *node, tree name, tree, int,
bool *no_add_attrs)
please reindent the parameters for the new name length.
Richard, could you please clarify how it should be done?
Thanks!
Regards,
Evgeny
---
gcc/config/aarch64/cygming.h | 6 +
gcc/config/i386/cygming.h | 6 +
gcc/config/i386/i386-expand.cc | 6 +++--
gcc/config/i386/i386-expand.h | 2 --
gcc/config/i386/i386.cc| 42 ++
gcc/config/i386/i386.h | 2 ++
gcc/config/mingw/winnt-dll.cc | 8 ++-
gcc/config/mingw/winnt-dll.h | 2 +-
8 files changed, 33 insertions(+), 41 deletions(-)
diff --git a/gcc/config/aarch64/cygming.h b/gcc/config/aarch64/cygming.h
index 4beebf9e093..0ff475754e0 100644
--- a/gcc/config/aarch64/cygming.h
+++ b/gcc/config/aarch64/cygming.h
@@ -183,4 +183,10 @@ still needed for compilation. */
#undef MAX_OFILE_ALIGNMENT
#define MAX_OFILE_ALIGNMENT (8192 * 8)
+#define CMODEL_IS_NOT_LARGE_OR_MEDIUM_PIC 0
+
+#define HAVE_64BIT_POINTERS 1
+
+#define GOT_ALIAS_SET mingw_GOT_alias_set ()
+
#endif
diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h
index ee01e6bb6ce..cd240533dbc 100644
--- a/gcc/config/i386/cygming.h
+++ b/gcc/config/i386/cygming.h
@@ -469,3 +469,9 @@ do {\
#ifndef HAVE_GAS_ALIGNED_COMM
# define HAVE_GAS_ALIGNED_COMM 0
#endif
+
+#define CMODEL_IS_NOT_LARGE_OR_MEDIUM_PIC ix86_cmodel != CM_LARGE_PIC &&
ix86_cmodel != CM_MEDIUM_PIC
+
+#define HAVE_64BIT_POINTERS TARGET_64BIT_DEFAULT
+
+#define GOT_ALIAS_SET mingw_GOT_alias_set ()
diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc
index fb460e30d0a..267d0ba257b 100644
--- a/gcc/config/i386/i386-expand.cc
+++ b/gcc/config/i386/i386-expand.cc
@@ -408,11 +408,12 @@ ix86_expand_move (machine_mode mode, rtx operands[])
: UNSPEC_GOT));
op1 = gen_rtx_CONST (Pmode, op1);
op1 = gen_const_mem (Pmode, op1);
- set_mem_alias_set (op1, ix86_GOT_alias_set ());
+ set_mem_alias_set (op1, GOT_ALIAS_SET);
}
else
{
- tmp = ix86_legitimize_pe_coff_symbol (op1, addend != NULL_RTX);
+#if TARGET_PECOFF
+ tmp = legitimize_pe_coff_symbol (op1, addend != NULL_RTX);
if (tmp)
{
op1 = tmp;
@@ -424,6 +425,7 @@ ix86_expand_move (machine_mode mode, rtx operands[])
op1 = operands[1];
break;
}
+#endif
}
if (addend)
diff --git a/gcc/config/i386/i386-expand.h b/gcc/config/i386/i386-expand.h
index a8c20993954..5e02df1706d 100644
--- a/gcc/config/i386/i386-expand.h
+++ b/gcc/config/i386/i386-expand.h
@@ -34,9 +34,7 @@ struct expand_vec_perm_d
};
rtx legitimize_tls_address (rtx x, enum tls_model model, bool for_mov);
-alias_set_type ix86_GOT_alias_set (void);
rtx legitimize_pic_address (rtx orig, rtx reg);
-rtx ix86_legitimize_pe_coff_symbol (rtx addr, bool inreg);
bool insn_defines_reg (unsigned int regno1, unsigned int regno2,
rtx_insn *insn);
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 66845b30446..ee3a59ed498 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -11807,30 +11807,6 @@ constant_address_p (rtx x)
}
-#if TARGET_PECOFF
-rtx ix86_legitimize_pe_coff_symbol (rtx addr, bool inreg)
-{
- return legitimize_pe_coff_symbol (addr, inreg);
-}
-
-alias_set_type
-ix86_GOT_alias_set (void)
-{
- return mingw_GOT_alias_set ();
-}
-#else
-rtx ix86_legitimize_pe_coff_symbol (rtx addr, bool inreg)
-{
- return NULL_RTX;
-}
-
-alias_set_type
-ix86_GOT_alias_set (void)
-{
- return -1;
-}
-#endif
-
/* Return a legitimate reference for ORIG (an address) using the
register REG. If REG is 0, a new pseudo is generated.
@@ -11867,9 +11843,11 @@ legitimize_pic_address (rtx orig, rtx reg)
if (TARGET_64BIT && TARGET_DLLIMPORT_DECL_ATTRIBUTES)
{
- rtx tmp = ix86_legitimize_pe_coff_symbol (addr, true);
+#if TARGET_PECOFF
+ rtx tmp = legitimize_pe_coff_symbol (addr, true);
if (tmp)
return tmp;
+#endif
}
if (TARGET_64BIT && legitimate_pic_address_disp_p (addr))
@@ -11912,9 +11890,11 @@ legitimize_pic_address (rtx orig, rtx reg)
on VxWorks, see gotoff_operand. */
|| (TARGET_VXWORKS_RTP && GET_CODE (addr) == LABEL_REF)
Re: [PATCH v1 0/6] Add DLL import/export implementation to AArch64
On 6/6/24 09:23, Evgeny Karpov wrote: Thursday, June 6, 2024 1:42 AM Jonathan Yong <10wa...@gmail.com> wrote: Where is HAVE_64BIT_POINTERS used? Sorry, it was missed in the posted changes for review. Regards, Evgeny diff --git a/gcc/config/mingw/mingw32.h b/gcc/config/mingw/mingw32.h index 8a6f0e8e8a5..0c9d5424942 100644 --- a/gcc/config/mingw/mingw32.h +++ b/gcc/config/mingw/mingw32.h @@ -82,7 +82,7 @@ along with GCC; see the file COPYING3. If not see #endif #undef SUB_LINK_ENTRY -#if TARGET_64BIT_DEFAULT || defined (TARGET_AARCH64_MS_ABI) +#if HAVE_64BIT_POINTERS #define SUB_LINK_ENTRY SUB_LINK_ENTRY64 #else #define SUB_LINK_ENTRY SUB_LINK_ENTRY32 Looks OK to me.
Re: [PATCH] Do not use caller-saved registers for COMDAT functions
On 7/15/24 09:04, LIU Hao wrote: diff --git a/gcc/varasm.cc b/gcc/varasm.cc index 747f74ba1c0..b67a0b524db 100644 --- a/gcc/varasm.cc +++ b/gcc/varasm.cc @@ -7805,6 +7805,8 @@ decl_binds_to_current_def_p (const_tree decl) for all other declaration types. */ if (DECL_WEAK (decl)) return false; + if (DECL_COMDAT_GROUP (decl)) +return false; if (DECL_COMMON (decl) && (DECL_INITIAL (decl) == NULL || (!in_lto_p && DECL_INITIAL (decl) == error_mark_node))) -- 2.34.1 Looks ok to me, will push to master branch soon if there are no further comments.
Re: [PATCH] Do not use caller-saved registers for COMDAT functions
On 7/15/24 12:45, Jonathan Yong wrote: On 7/15/24 09:04, LIU Hao wrote: diff --git a/gcc/varasm.cc b/gcc/varasm.cc index 747f74ba1c0..b67a0b524db 100644 --- a/gcc/varasm.cc +++ b/gcc/varasm.cc @@ -7805,6 +7805,8 @@ decl_binds_to_current_def_p (const_tree decl) for all other declaration types. */ if (DECL_WEAK (decl)) return false; + if (DECL_COMDAT_GROUP (decl)) + return false; if (DECL_COMMON (decl) && (DECL_INITIAL (decl) == NULL || (!in_lto_p && DECL_INITIAL (decl) == error_mark_node))) -- 2.34.1 Looks ok to me, will push to master branch soon if there are no further comments. Thanks, pushed to master branch.
Re: [PATCH v3 1/3] diagnostics: Enable escape sequence processing on windows consoles
On 6/3/24 17:07, Peter Damianov wrote: Since windows 10 release v1511, the windows console has had support for VT100 escape sequences. We should try to enable this, and utilize it where possible. Thank you. Patches look good to me, pushed to master branch.
Re: [PATCH] Fix MinGW option -mcrtdll=
On 6/23/24 16:40, Pali Rohár wrote: Add missing msvcr40* and msvcrtd* cases to CPP_SPEC and document missing _UCRT macro and msvcr71* case. Fixes commit 453cb585f0f8673a5d69d1b420ffd4b3f53aca00. Thanks, pushed to master branch.
Re: [PATCH] Fix MinGW option -mcrtdll=
On 7/5/24 09:53, Pali Rohár wrote: On Monday 24 June 2024 10:03:26 Jonathan Yong wrote: On 6/23/24 16:40, Pali Rohár wrote: Add missing msvcr40* and msvcrtd* cases to CPP_SPEC and document missing _UCRT macro and msvcr71* case. Fixes commit 453cb585f0f8673a5d69d1b420ffd4b3f53aca00. Thanks, pushed to master branch. Hello, thanks for quick reply. I would like to ask one thing. I see that the mentioned commit was branched into release gcc-14. Should be this fixup commit included into release gcc-14 too? Done, cherry-picked to gcc-14 branch.
Re: [PATCH] mingw: Exclude utf8 manifest [PR111170, PR108865]
On 11/21/23 18:07, Costas Argyris wrote:
This patch makes the inclusion of the utf8 manifest on the
mingw hosts optional by introducing the configure option
--disable-win32-utf8-manifest (has no effect on non-mingw
hosts).
Bootstrapped OK on i686-w64-mingw32 and x86_64-w64-mingw32
with and without --disable-win32-utf8-manifest.
Costas
I would prefer a AC_ARG_ENABLE to document the option in configure.ac,
so it would show with configure --help. It should set new variables to
i386/x-mingw32-utf8, utf8rc-mingw32.o and utf8-mingw32.o respectively
unless disabled, like so:
host_xmake_mingw=i386/x-mingw32-utf8
host_extra_gcc_objs_mingw=utf8rc-mingw32.o
host_extra_objs=utf8-mingw32.o
And then entries in config.host would be:
i[34567]86-*-mingw32* | x86_64-*-mingw*)
host_xm_file=i386/xm-mingw32.h
host_xmake_file="${host_xmake_file} ${host_xmake_mingw} i386/x-mingw32"
host_extra_gcc_objs="${host_extra_gcc_objs} ${host_extra_gcc_objs_mingw} driver-mingw32.
> host_extra_objs="${host_extra_objs} ${host_extra_objs_mingw}"
Re: [PATCH] mingw: Exclude utf8 manifest [PR111170, PR108865]
On 11/22/23 12:34, Costas Argyris wrote: Attached a new patch. A couple things to note: 1) I changed your host_extra_objs=utf8-mingw32.o to host_extra_objs_mingw=utf8-mingw32.o to match the other two, since I believe that's what you meant. 2) This approach has the complication that the variables in configure.ac need to be set before it sources config.host. I specifically asked for it to be done that way so users are aware of it with --help. Thanks, pushed to master.
Re: [PATCH] mingw: Exclude utf8 manifest [PR111170, PR108865]
On 11/29/23 09:36, Costas Argyris wrote: Thanks. Eric, who originally reported the issue with the Ada compiler dropping a feature due to the utf8 manifest, is asking for this to be backported onto the 13 branch here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70#c13 If you agree with this, is there anything you would like me to do patch-wise? Costas No, I have just cherry-picked it onto releases/gcc-13, it should be part of any newer gcc-13 releases from now on. OpenPGP_0x713B5FE29C145D45_and_old_rev.asc Description: OpenPGP public key OpenPGP_signature.asc 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: 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
[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
[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_
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
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] 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
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: 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: 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: [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: [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] 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] 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] 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.
[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
[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
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.
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.
[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/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.
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: [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: [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] 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] 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] 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: 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] 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] 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 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] 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] 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 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: 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: 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: [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: [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] 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: 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.
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: 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]
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: 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/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: [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.
[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] 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.
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] 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] 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
[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
[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
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?
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.
[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
[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.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] 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
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
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.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] 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: 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] 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.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: 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 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: [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.
