Hi Jakub,
for C/C++, -fno-builtin-omp_is_initial_device already disabled the
expansion.
I added it also for Fortran. Plus added a C and a Fortran testcase for
the disable flag.
* * *
Wording wise, it failed before for Fortran with:
f951: Warning: command-line option ‘-fno-builtin-omp_is_i
Hi Thomas,
Thomas Schwinge wrote:
The new test case 'libgomp.c-c++-common/target-link-2.c' generally PASSes
on one-GPU systems, but on a multi-GPU system (tested nvidia5):
After having debugged it, it became glaringly obvious, but could
otherwise be missed …
The testcase checks that mapping
The commit for PR 116258, added a x86_64 specific testcase,
I thought it would be a good idea to add an aarch64 testcase too.
And since it also fixed VLA vectors too so add a SVE testcase.
Pushed as obvious after a test for aarch64-linux-gnu.
PR middle-end/116258
PR middle-end/116
On Wed, Aug 07, 2024 at 05:57:05PM +0200, Tobias Burnus wrote:
> for C/C++, -fno-builtin-omp_is_initial_device already disabled the
> expansion.
Good idea.
> RFC: Should be document this new built-in some where? If so, where? As part
> of the routine description in libgomp.texi? Or in extend.texi
On Wed, Aug 07, 2024 at 06:58:23PM +0200, Jakub Jelinek wrote:
> > For Fortran, this plus into gfc_get_extern_function_decl, i.e. that name
> > appears as external declaration. While the user could mess around, it checks
> > that it is a function and the return type is the expected on (i.e. logical
GCC maintainers:
The following series of patches for PowerPC removes some built-ins that
are covered by existing overloaded built-ins. Additionally, there are
patches to add missing testcases and documentation.
The patch series has been tested on Power 10 LE and BE with no regressions.
Pl
Currently, if a warning references a cloned function, the name of the cloned
function will be emitted in the "In function %qs" part of the diagnostic,
which users aren't supposed to see. This patch follows the DECL_ORIGIN link
to get the name of the original function.
gcc/ChangeLog:
PR dia
I forgot to state what changed in the v2. Now, following the DECL_ORIGIN
is done in lhd_print_error_function instead of lhd_decl_printable_name
because lhd_decl_printable_name was used in other circumstances, like
dumping RTL. This caused test failures.
GCC maintainers:
The following patch adds missing test cases for the overloaded vec_perm
built-in. It also fixes and issue with printing the 128-bit values in
the DEBUG section that was noticed when adding the additional test cases.
The patch has been tested on Power 10 LE and BE with no r
GCC maintainers:
The following patch removes two redundant built-ins
__builtin_vsx_vperm_8hi and __builtin_vsx_vperm_8hi_uns. The built-ins
are covered by the overloaded vec_perm built-in.
The patch has been tested on Power 10 LE and BE with no regressions.
Please let me know if it is acc
GCC maintainers:
The patch removed the built-in __builtin_vsx_xvcvuxwdp as it is covered
by the overloaded vec_doubleo built-in.
The patch has been tested on Power 10 LE and BE with no regressions.
Please let me know if it is acceptable for mainline. Thanks.
Carl
---
GCC maintainers:
The following patch fixes errors in the definition of the
__builtin_vsx_uns_floate_v2di, __builtin_vsx_uns_floato_v2di and
__builtin_vsx_uns_float2_v2di built-ins. The arguments should be
unsigned but are listed as signed.
Additionally, there are a number of test cases
On Mon, Jul 29, 2024 at 2:14 PM David Faust wrote:
>
>
> On 7/29/24 07:42, Will Hawkins wrote:
> > If the user provides a kind value that is more than 5 bits, the
> > BTF_KIND_INFO macro would emit incorrect values for info (by clobbering
> > values of the kind flag).
> >
> > Tested on x86_64-redh
Steve, Peter, Kewen:
Yes, it does look like supporting signed and unsigned char would be
consistent with the vec_cmpeq built-in.n I have played around with
adding both and it looks to be reasonable.
Per your second response:
On 8/7/24 9:25 AM, Steven Munroe wrote:
This Message Is From an
The following test was failing when building on 32 bit targets
due to not overwriting the mabi arg. This resulted in dejagnu
attempting to run the test with -mabi=ilp32d -march=rv64gcv_zvl256b
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr116202-run-1.c: Add mabi arg
Signed-off-
On 8/6/24 2:35 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Another potential approach would be to go searching for this unexported
type and load it, either with a new LOOK_want::ANY_REACHABLE flag or by
expanding on the lookup_imported_temploid_fri
I should probably start by saying that the "model" heuristic is now
pretty old and was originally tuned for an in-order AArch32 core.
The aim wasn't to *minimise* spilling, but to strike a better balance
between parallelising with spills vs. sequentialising. At the time,
scheduling without taking
> -Original Message-
> From: Jakub Jelinek
> Sent: Monday, August 5, 2024 8:01 PM
> To: Prathamesh Kulkarni
> Cc: Richard Biener ; Richard Sandiford
> ; gcc-patches@gcc.gnu.org
> Subject: Re: Support streaming of poly_int for offloading when it's
> degree <= accel's NUM_POLY_INT_COEFFS
On Wed, Aug 07, 2024 at 05:53:00PM +, Prathamesh Kulkarni wrote:
> > Two spaces after . rather than just one, and because of that move in
> > on the next line.
> >
> > > + host_num_poly_int_coeffs. */
> >
> > Otherwise LGTM.
> Thanks, I have adjusted the formatting of the comment and a typ
On Wed, Aug 07, 2024 at 11:10:37AM +0200, Jakub Jelinek wrote:
> > In any case how about the simpler
> >
> > if (!DECL_NAME (object) || DECL_NAMELESS (object))
> > DECL_NAME (object) = create_tmp_var_name ("C");
> >
> > ?
>
> This is what I had in my first version, but I was wo
> -Original Message-
> From: Jakub Jelinek
> Sent: Wednesday, August 7, 2024 11:27 PM
> To: Prathamesh Kulkarni
> Cc: Richard Biener ; Richard Sandiford
> ; gcc-patches@gcc.gnu.org
> Subject: Re: Support streaming of poly_int for offloading when it's
> degree <= accel's NUM_POLY_INT_CO
On Linux/x86_64,
5b97d1a2102dca57918947d7e40a6ca68871 is the first bad commit
commit 5b97d1a2102dca57918947d7e40a6ca68871
Author: Richard Biener
Date: Wed Aug 7 13:54:53 2024 +0200
tree-optimization/116258 - do not lower PAREN_EXPR of vectors
caused
FAIL: gcc.target/i386/pr116258
On top of what Jonathan said, Teju Jagua yields a smaller binary size since
it needs fewer look-up tables.
Regarding performance and correctness:
1) My patch passes all the tests.
2) The GitHub project of the reference implementation (*) scans all floats
and the results of Teju Jagua, Ryu and Dr
On 8/7/24 11:47 AM, Richard Sandiford wrote:
I should probably start by saying that the "model" heuristic is now
pretty old and was originally tuned for an in-order AArch32 core.
The aim wasn't to *minimise* spilling, but to strike a better balance
between parallelising with spills vs. sequent
Tested on x86_64-darwin21, pushed to trunk, thanks
Iain
--- 8< ---
XCode compilers recognise the weak_framework linker option in the driver
and forward it. This patch makes GCC adopt the same behaviour.
PR target/116237
gcc/ChangeLog:
* config/darwin.h (SUBTARGET_DRIVER_SELF_S
> > + /* Create chain of switch tests for each case. */
> > + tree switch_cond = NULL_TREE;
> > + tree index = gimple_switch_index (sw);
> > + for (unsigned i = 1; i < gimple_switch_num_labels (sw); i++)
> > + {
> > + tree label = gimple_switch
The attach patch is specific to the RTEMS RISC-V architecture multilib which is
controlled by the t-rtems file in the gcc/config/riscv/ directory. The patch
file was created from the gcc-13.3.0 branch. It was successfully tested within
RTEMS Source Builder.
gcc-13.3.0-RTEMS-riscv-multilib.pa
On 8/5/24 9:16 AM, Nathaniel Shead wrote:
Bootstrapped and regtested (so far just modules.exp) on
x86_64-pc-linux-gnu, OK for trunk if full regtest passes?
OK.
-- >8 --
Currently name lookup generally seems to assume that all entities
declared within a named module (partition) are attached t
This patch to the Go frontend avoids assuming that ATTRIBUTE_UNUSED is
defined. While it is defined when building the Go frontend as part of
GCC, it is meant to work with other compilers as well. Bootstrapped
and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
e89ddb749517ea
Hi Martin,
On Wed, Aug 07, 2024 at 12:07:00PM GMT, Martin Uecker wrote:
> > > void foo(char (*a)[*], int x[*]);
> > > void foo(char (*a)[*], int x[__lengthof__(*a)]);
> >
> > But [*] is a VLA. Do we want to return a constexpr for it?
>
> No, my point is only that we could have a test for not
>
This is a small C++11-ificiation for the use of vect_vect_recog_func_ptrs.
Changes the loop into a range based loop which then we can remove the variable
definition of NUM_PATTERNS. Also uses const reference instead of a pointer.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
On 8/7/24 12:28, Jeff Law wrote:
> On 8/7/24 11:47 AM, Richard Sandiford wrote:
>> I should probably start by saying that the "model" heuristic is now
>> pretty old and was originally tuned for an in-order AArch32 core.
>> The aim wasn't to *minimise* spilling, but to strike a better balance
>> bet
On 7/3/24 10:37 AM, Jakub Jelinek wrote:
Hi!
With the PR115754 fix in, constexpr placement new mostly just works,
so this patch just adds constexpr keyword to the placement new operators
in , adds FTMs and testsuite coverage.
There is one accepts-invalid though, the
new (p + 1) int[]{2, 3};
Hi Jens, Joseph,
On Wed, Aug 07, 2024 at 05:30:13PM GMT, Jens Gustedt wrote:
> Hi
>
> Am 7. August 2024 17:05:48 MESZ schrieb Joseph Myers :
> > On Wed, 7 Aug 2024, Alejandro Colomar wrote:
> >
> > > +@node Length
> > > +@section Determining the Length of Arrays
> > > +@cindex lengthof
> > > +@c
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This error message reads to me the wrong way around, particularly in the
context of other errors. Updated so that the ellipsis connect.
gcc/cp/ChangeLog:
* module.cc (trees_in::read_enum_def): Clarify error.
gcc
On Linux/x86_64,
f1bfba3a9b3f31e3e06bfd1911c9f223869ea03f is the first bad commit
commit f1bfba3a9b3f31e3e06bfd1911c9f223869ea03f
Author: Tobias Burnus
Date: Wed Aug 7 19:31:19 2024 +0200
OpenMP: Constructors and destructors for "declare target" static aggregates
caused
FAIL: libgomp.c++
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This patch goes through all .cc files in gcc/cp and adds in any
auto_diagnostic_groups that seem to be missing by looking for any
'inform' calls that aren't grouped with their respective error/warning.
Now with SARIF output
On Wed, Aug 07, 2024 at 04:18:47PM -0400, Jason Merrill wrote:
> On 8/5/24 9:16 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested (so far just modules.exp) on
> > x86_64-pc-linux-gnu, OK for trunk if full regtest passes?
>
> OK.
>
> > -- >8 --
> >
> > Currently name lookup generally seem
On Wed, Aug 07, 2024 at 01:44:31PM -0400, Jason Merrill wrote:
> On 8/6/24 2:35 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > Another potential approach would be to go searching for this unexported
> > type and load it, either with a new LO
101 - 139 of 139 matches
Mail list logo
