Re: [PATCH] Fortran: use name of array component in runtime error message [PR30802]

On 28 January 2024 22:43:37 CET, Steve Kargl wrote: >On Sun, Jan 28, 2024 at 08:56:24PM +0100, Harald Anlauf wrote: >> >> Am 28.01.24 um 12:39 schrieb Mikael Morin: >> > Le 24/01/2024 à 22:39, Harald Anlauf a écrit : >> > > Dear all, >> > > >> > > this patch is actually only a followup fix to g

Re: [PATCH v4 0/4] When cmodel=extreme, add macro support and only support macros.

在 2024/1/27 下午10:03, chenglulu 写道: 在 2024/1/27 下午7:11, Xi Ruoyao 写道: On Sat, 2024-01-27 at 18:02 +0800, Xi Ruoyao wrote: On Sat, 2024-01-27 at 11:15 +0800, chenglulu wrote: 在 2024/1/26 下午6:57, Xi Ruoyao 写道: On Fri, 2024-01-26 at 16:59 +0800, chenglulu wrote: 在 2024/1/26 下午4:49, Xi Ruoyao

Re: [PATCH] RISC-V: Add require-effective-target to pr113429 testcase

ok juzhe.zh...@rivai.ai From: Patrick O'Neill Date: 2024-01-27 10:50 To: gcc-patches CC: juzhe.zhong; Patrick O'Neill Subject: [PATCH] RISC-V: Add require-effective-target to pr113429 testcase The pr113429 testcase fails with newlib spike runs. Adding require-effective-target rv64 and riscv_v

Re: [PATCH] testsuite: Fix vect_long_mult on Power [PR109705]

on 2024/1/27 06:42, Andrew Pinski wrote: > On Mon, Jan 15, 2024 at 6:43 PM Kewen.Lin wrote: >> >> Hi, >> >> As pointed out by the discussion in PR109705, the current >> vect_long_mult effective target check on Power is broken. >> This patch is to fix it accordingly. >> >> With additional change by

Re: [PATCH] jit: Ensure ssize_t is defined.

> On 28 Jan 2024, at 21:25, Eric Gallager wrote: > > On Sun, Jan 28, 2024 at 6:45 AM Iain Sandoe wrote: >> >> Tested on i686, x86_64 Darwin, x86_64 Linux, >> OK for trunk? >> >> --- 8< --- >> >> On some targets it seems that ssize_t is not defined by any of the >> headers transitively incl

Re: [PATCH] Fortran: use name of array component in runtime error message [PR30802]

On Sun, Jan 28, 2024 at 08:56:24PM +0100, Harald Anlauf wrote: > > Am 28.01.24 um 12:39 schrieb Mikael Morin: > > Le 24/01/2024 à 22:39, Harald Anlauf a écrit : > > > Dear all, > > > > > > this patch is actually only a followup fix to generate the proper name > > > of an array reference in derive

Re: [PATCH] jit: Ensure ssize_t is defined.

On Sun, Jan 28, 2024 at 6:45 AM Iain Sandoe wrote: > > Tested on i686, x86_64 Darwin, x86_64 Linux, > OK for trunk? > > --- 8< --- > > On some targets it seems that ssize_t is not defined by any of the > headers transitively included by . This leads to a bootstrap > fail when jit is enabled. > >

Re: [PATCH] Fortran: use name of array component in runtime error message [PR30802]

Hi Mikael, Am 28.01.24 um 12:39 schrieb Mikael Morin: Le 24/01/2024 à 22:39, Harald Anlauf a écrit : Dear all, this patch is actually only a followup fix to generate the proper name of an array reference in derived-type components for the runtime error message generated for the bounds-checking

Re: [PATCH 2/2] libgcc: Make heap trampoline support dynamic [PR113403].

On Sun, Jan 28, 2024 at 02:07:33PM +, Iain Sandoe wrote: > In order to handle system security constraints during GCC build > and test and that most platform versions cannot link to libgcc_eh > since the unwinder there is incompatible with the system one. > > 1. We make the support functions we

Re: [PATCH 1/2] libgcc: Make heap trampoline support dynamic [PR113403].

On Sun, Jan 28, 2024 at 02:07:32PM +, Iain Sandoe wrote: > This removes the heap trampoline support functions from libgcc.a and > adds them to libgcc_eh.a. They are also present in libgcc_s. > > PR libgcc/113403 > > libgcc/ChangeLog: > > * config/aarch64/t-heap-trampoline: Move

[libatomic PATCH] PR other/113336: Fix libatomic testsuite regressions on ARM.

This patch is a revised version of the fix for PR other/113336. This patch has been tested on arm-linux-gnueabihf with --with-arch=armv6 with make bootstrap and make -k check where it fixes all of the FAILs in libatomic. Ok for mainline? 2024-01-28 Roger Sayle Victor Do Nascimen

Re: [PATCH] testsuite, gfortan: Update link flags [PR112862].

> Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux, > OK for trunk? Looks good to me. Please leave 48h before pushing for other Fortran maintainers to comment if they see something I missed (in particular the coarrays part). FX

Re: [PATCH] testsuite, GDC: Update link flags [PR112861].

Excerpts from Iain Sandoe's message of Januar 28, 2024 4:02 pm: > Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux, > OK for trunk? > thanks, > Iain > OK. Thanks again! Iain.

Re: [PATCH] testsuite, libphobos: Update link flags [PR112864].

Excerpts from Iain Sandoe's message of Januar 28, 2024 4:03 pm: > Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux, > OK for trunk? > thanks, > Iain > Thanks Iain! OK. Seems reasonable to me. Iain.

[PATCH] testsuite, Objective-C++: Update link flags [PR112863].

Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux, OK for trunk? thanks, Iain --- 8< --- These regressions are caused by missing or duplicate runpaths which now fire linker warnings. We need to add options to locate libobjc (and on Darwin libobjc-gnu) along with libstdc++. Usually '

[PATCH] testsuite, libphobos: Update link flags [PR112864].

Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux, OK for trunk? thanks, Iain --- 8< --- The regressions here are primarily from duplicated '-B' additions. We remove the duplicate on the link line. We also make sure that platforms with extensions other than .so for shared libs will

[PATCH] testsuite, gfortan: Update link flags [PR112862].

Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux, OK for trunk? thanks, Iain --- 8< --- The regressions here are caused by two issues: 1. In some cases there is no generated runpath for libatomic 2. In other cases there are duplicate paths. This patch simplifies the addition of the

[PATCH] testsuite, GDC: Update link flags [PR112861].

Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux, OK for trunk? thanks, Iain --- 8< --- The regressions here are because we do not generate a runpath for the uninstalled libstdc++. This patch updates the link flags handling to simplify it. We need to add options to locate both lib

[PATCH 2/2] libgcc: Make heap trampoline support dynamic [PR113403].

In order to handle system security constraints during GCC build and test and that most platform versions cannot link to libgcc_eh since the unwinder there is incompatible with the system one. 1. We make the support functions weak definitions. 2. We include them as a CRT for platform conditions tha

[PATCH 1/2] libgcc: Make heap trampoline support dynamic [PR113403].

This removes the heap trampoline support functions from libgcc.a and adds them to libgcc_eh.a. They are also present in libgcc_s. PR libgcc/113403 libgcc/ChangeLog: * config/aarch64/t-heap-trampoline: Move the heap trampoline support functions from libgcc.a to libgcc_eh.

[PATCH 0/2] libgcc: Make heap trampoline support dynamic [PR113403].

This series follows Jakub's suggestion in the PR (for Linux in the first patch) and handles Darwin-specific cases (in the second). Sorry this has taken a while, the Darwin permutations had some glitches which necessitated re-tests on several OS versions. Tested on x86_64 (and aarch64) Darwin, x86

Re: [PATCH] Fortran: NULL actual to optional dummy with VALUE attribute [PR113377]

Le 25/01/2024 à 22:26, Harald Anlauf a écrit : Dear all, this is the third patch in a series that addresses dummy arguments with the VALUE attribute, now handling the passing of NULL actual arguments. It is based on the refactoring in the previous patch and reuses the handling of absent argumen

[pushed] Objective-C, Darwin: Do not overalign CFStrings and Objective-C metadata.

Tested on i686, powerpc, x86_64 Darwin, x86_64, aarch64 Linux, pushed to trunk, thanks, Iain --- 8< --- We have reports of regressions in both Objective-C and Objective-C++ on Darwin23 (macOS 14). In some cases, these are linker warnings about the alignment of CFString constants; in other cases

[PATCH] jit: Ensure ssize_t is defined.

Tested on i686, x86_64 Darwin, x86_64 Linux, OK for trunk? --- 8< --- On some targets it seems that ssize_t is not defined by any of the headers transitively included by . This leads to a bootstrap fail when jit is enabled. The fix proposed here is to include sys/types.h when it is available si

Re: [PATCH] Fortran: use name of array component in runtime error message [PR30802]

Le 24/01/2024 à 22:39, Harald Anlauf a écrit : Dear all, this patch is actually only a followup fix to generate the proper name of an array reference in derived-type components for the runtime error message generated for the bounds-checking code. Without the proper part ref, not only a user may

[pushed] testsuite, Objective-C: Fix duplicate libobjc cases.

tested on i686, powerpc, x86_64 Darwin, x86_64, aarch64 Linux, pushed to trunk, thanks, Iain --- 8< --- Two of the encode testcases include '-lobjc' as their dg-options. Since the library is already appended as part of the generic testsuite handling, this means that two instances appear on the l

Re: [PATCH v3] Fix __builtin_nested_func_ptr_{created, deleted} symbol versions [PR113402]

> On 18 Jan 2024, at 15:05, Jakub Jelinek wrote: > > On Thu, Jan 18, 2024 at 02:59:23PM +, Iain Sandoe wrote: >> --- a/gcc/builtins.cc >> +++ b/gcc/builtins.cc >> @@ -8416,6 +8416,11 @@ expand_builtin (tree exp, rtx target, rtx subtarget, >> machine_mode mode, >> case BUILT_IN_ADJUST_D

Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Am Freitag, dem 26.01.2024 um 14:33 + schrieb Qing Zhao: > > > On Jan 26, 2024, at 3:04 AM, Martin Uecker wrote: > > > > > > I haven't looked at the patch, but it sounds you give the result > > the wrong type. Then patching up all use cases instead of the > > type seems wrong. > > Yes, thi