[og12] In 'libgomp/target.c:gomp_unmap_vars_internal', defer 'gomp_remove_var' (was: [PATCH, v2, OpenMP 5.0, libgomp] Structure element mapping for OpenMP 5.0)

ndled. I've pushed to devel/omp/gcc-12 commit 65037818987ffce7d6f466fa8bde13e9f59a3218 "In 'libgomp/target.c:gomp_unmap_vars_internal', defer 'gomp_remove_var'", see attached. Grüße Thomas - Siemens Electronic Design Automation GmbH; Anschri

[og12] libgomp: Simplify OpenMP reverse offload host <-> device memory copy implementation (was: [Patch] libgomp/nvptx: Prepare for reverse-offload callback handling)

ify OpenMP reverse offload host <-> device memory copy implementation", see attached. May this also go into master branch still at this time, or "next year"? Grüße Thomas - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 Münche

Re: [PATCH, OpenACC, v3] Non-contiguous array support for OpenACC data clauses

27;free'? > > Please verify the attached > "Given OpenACC 'async', defer 'free' of non-contiguous array support data > structures", > in particular the 'libgomp/oacc-parallel.c:GOACC_parallel_keyed' case. To allow me to make progress with the &q

[og12] libgomp: Document OpenMP 'pinned' memory (was: [PATCH] libgomp, openmp: pinned memory

Hi! On 2022-01-04T15:32:17+, Andrew Stubbs wrote: > This patch implements the OpenMP pinned memory trait [...] I figure it may be helpful to document the current og12 state of affairs; does the attached "libgomp: Document OpenMP 'pinned' memory" look good

Add caveat/safeguard to OpenMP: Handle descriptors in target's firstprivate [PR104949] (was: [Patch] OpenMP: Handle descriptors in target's firstprivate [PR104949])

er branch commit e8fec6998b656dac02d4bc6c69b35a0fb5611e87 "Add caveat/safeguard to OpenMP: Handle descriptors in target's firstprivate [PR104949]", see attached. Grüße Thomas > On 2022-05-11T19:33:00+0200, Tobias Burnus wrote: >> this patch handles (for target regions) &

Re: [OG12][committed] amdgcn: OpenMP low-latency allocator

lean-up re OpenMP 'ompx_unified_shared_mem_space', 'ompx_host_mem_space'", I've now pushed the corresponding GCN 'ompx_host_mem_space' thing to devel/omp/gcc-12 branch in commit b39e4bbab59f5e4b551c44dbce0ce3acf4afc22a "Miscellaneous clean-up r

[og12] Add 'libgomp.c/alloc-ompx_host_mem_alloc-1.c'

Hi! This had fallen out of some earlier work of mine; I've now pushed to devel/omp/gcc-12 branch commit ae2dca26602678f8b70e22da1bce8302c0751b75 "Add 'libgomp.c/alloc-ompx_host_mem_alloc-1.c'", see attached. Grüße Thomas - Siemens Electronic Design A

[og12] libgomp: Document OpenMP 'pinned' memory (was: [PATCH] libgomp, openmp: pinned memory)

Hi! On 2023-03-27T09:27:31+, "Stubbs, Andrew" wrote: >> -Original Message- >> From: Thomas Schwinge >> Sent: 24 March 2023 15:50 >> >> On 2022-01-04T15:32:17+, Andrew Stubbs >> wrote: >> > This patch implements the Op

Enable 'gfortran.dg/weak-2.f90' for nvptx target (was: Support for WEAK attribute, part 2)

"" { nvptx-*-* } } > +[...] Pushed to master branch commit b3c5933ee726004e4e47291d422dfe7ac3345062 "Enable 'gfortran.dg/weak-2.f90' for nvptx target", see attached. I'm sorry I've not yet been able to look into the other items discussed in this thread. Grüße Th

'g++.dg/modules/modules.exp': don't leak local 'unsupported' proc [PR108899] (was: [PATCH] testsuite: Fix up modules.exp [PR108899])

-proc unsupported { args } { > -global module_do > -lset module_do 1 "N" > -return [saved-unsupported $args] > +if { [info procs unsupported] != [list] \ > + && [info procs saved-unsupported] == [list] } { > +rename unsupported saved-unsupported > +

Re: 'g++.dg/modules/modules.exp': don't leak local 'unsupported' proc [PR108899]

Hi! On 2023-03-30T04:00:03-0300, Alexandre Oliva wrote: > On Mar 29, 2023, Thomas Schwinge wrote: >> But surely the curly braces in: > >> -UNSUPPORTED: g++.dg/modules/explicit-bool-1_a.H -std=c++17 > >> +UNSUPPORTED: {g++.dg/modules/explicit-bool-1_a.H -

Re: [PATCH 1/7] openmp: Add Fortran support for "omp unroll" directive

ot offloading), '-O0' (only): spawn [open ...] 41 Program aborted. Backtrace: #0 0x8048c35 in ??? #1 0x8048c72 in ??? #2 0x55977af2 in ??? #3 0x8048a60 in ??? FAIL: libgomp.fortran/loop-transforms/unroll-simd-1.f90 -O0 execution test All other variants PASS with: spawn [open ...] 16 Grüße Thomas - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

Re: [PATCH] [og12] OpenMP: Constructors and destructors for "declare target" static aggregates

E_CHAIN (*fvarsp); 5290else 5291 *fvarsp = OMP_CLAUSE_CHAIN (*fvarsp); 5292 } Please have a look. Grüße Thomas > gcc/cp/ > * decl2.cc (priority_info): Add omp_tgt_initializations_p and >

[og12] OpenACC: Pass pre-allocated 'ptrblock' to 'goacc_noncontig_array_create_ptrblock' [PR76739] (was: [PATCH, OpenACC, v3] Non-contiguous array support for OpenACC data clauses)

commit c58b28cb650995a41e1ab0166169799f3991bdd6 "OpenACC: Pass pre-allocated 'ptrblock' to 'goacc_noncontig_array_create_ptrblock' [PR76739]", see attached. Grüße Thomas - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 2

[og12] '-foffload-memory=pinned' using offloading device interfaces (was: -foffload-memory=pinned)

Hi! On 2023-02-13T15:20:07+, Andrew Stubbs wrote: > On 13/02/2023 14:38, Thomas Schwinge wrote: >> On 2022-03-08T11:30:55+, Hafiz Abid Qadeer >> wrote: >>> From: Andrew Stubbs >>> >>> Add a new option. It will be used in follow-up patches.

Re: [Patch] nvptx/mkoffload.cc: Add dummy proc for OpenMP rev-offload table [PR108098]

Hi! Are we going to install such a work-around? Grüße Thomas On 2022-12-19T13:04:43+0100, I wrote: > Hi! > > On 2022-12-16T17:19:00+0100, Tobias Burnus wrote: >> Seems to be a CUDA JIT issue > > A Nvidia Driver JIT issue, more precisely. ;-) > >> which is fix

Re: [Patch] libgomp/nvptx: Prepare for reverse-offload callback handling

acquire.sys.global.u64 %0, [%1];" : "=r" (fn2) : "r" (addr_struct_fn) : "memory"); } while (fn2 != 0); #else /* ld.global.u64 %r64,[__gomp_rev_offload_var]; ld.u64 %r36,[%r64]; membar.sys; */ whi

Re: 'g++.dg/modules/modules.exp': don't leak local 'unsupported' proc [PR108899]

end of last week, are you going to push that anytime soon, please? With... Co-authored-by: Thomas Schwinge ... added, I suppose. Grüße Thomas > [PR108899] testsuite: fix proc unsupported overriding in modules.exp > > The overrider of proc unsupported in modules.exp had two prob

Re: Rust front-end update 2023-04-05

Hi Arthur! On 2023-04-05T16:02:43+0200, arthur.co...@embecosm.com wrote: > This patchset contains around 80 commits concerning the Rust frontend. Did you not intend to actually 'git push' those? ;-P Grüße Thomas > We have been hard at work trying to get the Rust core libr

Re: 'g++.dg/modules/modules.exp': don't leak local 'unsupported' proc [PR108899]

Hi Alexandre! On 2023-04-05T23:38:43-0300, Alexandre Oliva via Gcc-patches wrote: > On Apr 5, 2023, Thomas Schwinge wrote: >> With... > >> Co-authored-by: Thomas Schwinge > >> ... added, I suppose. > > I wrote the patch based on your report, before even

libgm2: Adjust 'autogen.sh' to 'ACLOCAL_AMFLAGS', and simplify (was: [PATCH v3 8/19] modula2 front end: libgm2 contents)

und via search paths. OK to align (and simplify) that as per the attached "libgm2: Adjust 'autogen.sh' to 'ACLOCAL_AMFLAGS', and simplify"? Separately, given that plain 'autoreconf' works, why have 'autogen.sh' at all? Grüße Thomas

For GCC, newlib combined tree, newlib build-tree testing, use standard search paths

y not the first person to be testing such a setup?) I'm not doing anything special here: just symlink 'newlib' into the GCC source directory, build the combined tree, and then run 'make check', as mentioned in the attached Git commit log. Grüße Thomas -

Re: Async I/O patch with compilation fix

have two compilers, one with the patch and one without: Is there a difference in the generated files for -dump-tree-original, -fdump-tree-optimized and -S? Regards, Thomas

[PATCH] Clarify source of tm.texi to copy for GFDL grant

tm.texi to copy, I think it would be clearer to indicate the absolute path for the source as well. This patch achieves that. ChangeLog entry is as follows: *** gcc/ChangeLog *** 2018-08-09 Thomas Preud'homme * Makefile.in: Clarify which tm.texi to copy over to assert the right to gr

Re: [PATCH][GCC][AArch64] Limit movmem copies to TImode copies.

Hi Tamar, Thanks for your patch. Just one comment about your ChangeLog entry for the testsuiet change: shouldn't it mention that it is a new testcase? The patch you attached seems to create the file. Best regards, Thomas On Mon, 13 Aug 2018 at 10:33, Tamar Christina wrote: > Hi All

Re: Async I/O patch with compilation fix

ldly inaccurate). So, I'd appreciate testing. If this passes, this will be committed ASAP. Regards Thomas Index: gcc/fortran/gfortran.texi === --- gcc/fortran/gfortran.texi (Revision 263618) +++ gcc/fortran/gfortran.tex

Re: Async I/O patch with compilation fix

nge armeb failure (if the test for the macros above does not a promising approach). Let us then fix this PR before the 9.0 release. Regards Thomas

Re: [PATCH] Unconditionally use MAX_EXPR/MIN_EXPR for MAX/MIN intrinsics

pc-linux-gnu, Ok for trunk? OK. Could you also document this behavior in the "Compiler Characteristics" section, and make mention of the change in gcc-9/changes.html ? Regards Thomas

Re: Async I/O patch with compilation fix

Hi everybody, Nicolas has committed the patch as r263750. PR 87048 now traces the armeb regression, which is assumed to resurface now. Let's really try and fix that one before 9.0 :-) Regards Thomas

Re: Optimization in load_generic_interfaces()

sion tests cleanly. The patch is OK for trunk. Thanks! Regards Thomas

Re: Async I/O patch with compilation fix

Both Nicolas and I will be there. In the meantime, I have committed the following patch (r263788) as obvious after regression-testing on Linux both with ASYNC_IO set to 1 and to 0. Let me know how that works out. 2018-08-22 Thomas Koenig * async.h: Set ASYNC_IO to zero if _AIX is de

Re: Async I/O patch with compilation fix

a patch (for which I promise a fast review) or, if you feel that the patch is simple and obvious, commit it yourself and announce it to the fortran and gcc-patches mailing list. Thomas

Re: [PATCH,FORTRAN] Remove OS dependency in definition of ASYNC_IO

sufficient. This patch simplifies the macro definition. Bootstrapped on powerpc-ibm-aix7.2.0.0 Okay? OK. Thanks for the patch! Thomas

[patch, fortran] Fix PR 86837, wrong code regression in implied do loop in i/o

K for trunk and 8.x? Regards Thomas 2018-08-23 Thomas Koenig PR fortran/86837 * frontend-passes.c (var_in_expr_callback): New function. (var_in_expr): New function. (traverse_io_block): Use var_in_expr instead of gfc_check_dependency for checking i

[patch, libfortran] correct buffer size in library matmul

Hello world, the attached patch fixes a regression where the calculation of the size of the buffer for matmul was too small for ine special case. Regression-tested. OK for trunk? Regards Thomas 2018-08-25 Thomas Koenig PR libfortran/86704 * m4/matmul_internal.m4

Re: [Patch, fortran] PRs 80477 and 86481 - memory leaks following function calls.

Hi Paul, Bootstrapped and regtested on FC28/x86_64 - OK for trunk? OK, and thanks for the patch! Regards Thomas

Re: [PATCH, ARM] PR85434: Prevent spilling of stack protector guard's address on ARM

Resend hopefully without HTML this time. On Wed, 29 Aug 2018 at 10:49, Thomas Preudhomme wrote: > > Hi, > > I've reworked the patch fixing PR85434 (spilling of stack protector guard's > address on ARM) to address the testsuite regression on powerpc and x86 as

Re: [PATCH, ARM] PR85434: Prevent spilling of stack protector guard's address on ARM

ed by manual inspection of the code. I've attached the interdiff from previous version for reference. Best regards, Thomas On Wed, 29 Aug 2018 at 10:51, Thomas Preudhomme wrote: > > Resend hopefully without HTML this time. > > On Wed, 29 Aug 2018 at 10:49, Thomas Preudhomm

Re: [patch, libgfortran] Fix warning about mismatched type declarations.

Hi Jerry, The subject patch fixes the declaration for the vlist argument of the formatted_dtio function pointer definition which currently gives a warnings during compilation for mismatched types. Regression tested on x86_64-pc-linux. OK for trunk? OK. Thanks! Regards Thomas

Re: [PATCH, GCC/LTO, ping3] Fix PR69866: LTO with def for weak alias in regular object file

symbol, even external aliases. How about the following: ChangeLog entries are as follow: *** gcc/lto/ChangeLog *** 2017-06-02 Thomas Preud'homme * lto/lto-partition.c (add_symbol_to_partition_1): Change assert to allow external aliases to be added. *** gcc/Chan

Re: [PING] [PING] Make the OpenACC C++ acc_on_device wrapper "always inline"

Hi Jakub! On Tue, 6 Jun 2017 08:58:21 +0200, Jakub Jelinek wrote: > On Tue, Jun 06, 2017 at 08:35:40AM +0200, Thomas Schwinge wrote: > > > > commit 9cc3a384c17e9f692f7864c604d2e2f9fbf0bac9 > > > > Author: Thomas Schwinge > > > > Date: Tue May 23 13:21:

[PATCH, GCC/testsuite/ARM] Allow arm_arch_*_ok to test several macros

not work as intendend for architecture extensions (eg. ARMv8.1-A) due to lack of extension-specific macro similar to __ARM_ARCH_*__. ChangeLog entry is as follows: *** gcc/testsuite/ChangeLog *** 2017-06-06 Thomas Preud'homme * lib/target-support

[patch, fortran] Fix PR 80988

Hello world, the attached patch fixes the PR by not doing a replacement of (a(i,i),i=1,3) by an array expression (which does not exist). Regression-tested. OK for trunk? Regards Thomas 2017-06-09 Thomas Koenig PR fortran/80988 * frontend-passes.c

Re: [PATCH, GCC/LTO, ping] Fix PR69866: LTO with def for weak alias in regular object file

Ping? Best regards, Thomas On 06/06/17 11:12, Thomas Preudhomme wrote: On 09/05/17 23:36, Jan Hubicka wrote: Ping? Sorry for late reply My turn to apologize now. Hi, This patch fixes an assert failure when linking one LTOed object file having a weak alias with a regular object file

[PATCH, GCC/testsuite/ARM] Consistently check for neon in vect effective targets

-target This patch consolidate all of these check into using is-effective-target arm_neon and when little endian was checked, the check is kept. ChangeLog entry is as follows: *** gcc/testsuite/ChangeLog *** 2017-06-06 Thomas Preud'homme * lib/target-support

[PATCH, GCC/testsuite] Fix gen-vect-26.c requirements

Hi, gen-vect-26.c tests the vectorizer but only requires vect_cmdline_needed effective target. It should also depends on vect_int to make sure a vector unit is available on the target. This patch fixes that. ChangeLog entry is as follows: *** gcc/testsuite/ChangeLog *** 2017-06-05 Thomas

Re: [PATCH, GCC/testsuite/ARM] Consistently check for neon in vect effective targets

On 13/06/17 20:22, Christophe Lyon wrote: Hi Thomas, On 13 June 2017 at 11:08, Thomas Preudhomme wrote: Hi, Conditions checked for ARM targets in vector-related effective targets are inconsistent: * sometimes arm*-*-* is checked * sometimes Neon is checked * sometimes arm_neon_ok and

Re: [PATCH, GCC/testsuite/ARM] Consistently check for neon in vect effective targets

On 14/06/17 09:29, Christophe Lyon wrote: On 14 June 2017 at 10:25, Thomas Preudhomme wrote: On 13/06/17 20:22, Christophe Lyon wrote: Hi Thomas, On 13 June 2017 at 11:08, Thomas Preudhomme wrote: Hi, Conditions checked for ARM targets in vector-related effective targets are

[PATCH, contrib] Support multi-tool sum files in dg-cmp-results.sh

tools. This patch changes the logic to instead keep everything between "Running target" line and the beginning of Summary line. Other existing filter mechanism will ensure only FAIL, PASS, etc. lines are kept after that. ChangeLog entry is as follow: *** contrib/ChangeLog *** 2017-06-

Re: [PATCH, GCC/testsuite/ARM] Allow arm_arch_*_ok to test several macros

I've heard adding the patch usually helps getting it review so here it is. :-) Best regards, Thomas On 07/06/17 16:42, Thomas Preudhomme wrote: Hi, The general arm_arch_*_ok procedures check architecture availability by substituting macros inside a defined preprocessor operator. This l

[PATCH, GCC/testsuite/ARM] Make gcc.target/arm/its.c more robust

targets is even more restrictive (only one instruction per IT block), restricting the testcase to all Thumb-only devices is sufficient. ChangeLog entry is as follows: *** gcc/testsuite/ChangeLog *** 2017-06-09 Thomas Preud'homme * gcc.target/arm/its.c: Check that no IT blocks has

[patch, libfortran] Speed up cshift for dim > 1

o much faster than an implementation of straight DO loops. Regression-tested. OK for trunk? Regards Thomas $ gfortran-7 -static-libgfortran -O3 do-1.f90 && ./a.out Testing explicit DO loops Dim =1 Elapsed CPU time =5.71363878 Dim =2 El

Re: [PATCH, GCC/testsuite/ARM] Make gcc.target/arm/its.c more robust

On 14/06/17 18:03, Richard Earnshaw (lists) wrote: On 14/06/17 17:49, Thomas Preudhomme wrote: Hi, Testcase gcc.target/arm/its.c was added as part of a patch [1] to limit IT blocks to 2 instructions maximum. However, the patch was only tested indirectly by *aiming* to check that the assembly

Re: [Patch, Fortran, F03] PR 80983: memory leak when calling procedure-pointer component with allocatable result

Hi Janus, It regtests cleanly on x86_64-linux-gnu. Ok for trunk? OK. Thanks for the patch! Regards Thomas

Re: [PATCH, contrib] Support multi-tool sum files in dg-cmp-results.sh

Forgetting the patch: check! Sending it later as a reply to the wrong message: check! Hopefully I won't check a second time any of those. Best regards, Thomas On 14/06/17 13:30, Thomas Preudhomme wrote: Hi, dg-cmp-results.sh contrib script is written to work with sum file for a single

Re: [PATCH, GCC/testsuite/ARM] Consistently check for neon in vect effective targets

-target This patch consolidate all of these check into using is-effective-target arm_neon and when little endian was checked, the check is kept. ChangeLog entry is as follows: *** gcc/testsuite/ChangeLog *** 2017-06-06 Thomas Preud'homme * lib/target-support

Re: [patch, libfortran] Speed up cshift for dim > 1

there, let's see how that works out. Regards Thomas

Re: [PATCH, GCC/testsuite/ARM] Consistently check for neon in vect effective targets

On 19/06/17 08:41, Christophe Lyon wrote: Hi Thomas, On 15 June 2017 at 18:18, Thomas Preudhomme wrote: Hi, Conditions checked for ARM targets in vector-related effective targets are inconsistent: * sometimes arm*-*-* is checked * sometimes Neon is checked * sometimes arm_neon_ok and

Re: [PATCH, contrib] Support multi-tool sum files in dg-cmp-results.sh

Wrong copy paste between the patch I tested and the patch I sent. The first and second command of the sed should be replaced, not the second and third as in the patch I sent. For more safety I'll rerun the tests. Best regards, Thomas On 15/06/17 17:15, Thomas Preudhomme wrote: Forge

Re: [PATCH, GCC/testsuite/ARM] Consistently check for neon in vect effective targets

On 19/06/17 10:16, Thomas Preudhomme wrote: On 19/06/17 08:41, Christophe Lyon wrote: Hi Thomas, On 15 June 2017 at 18:18, Thomas Preudhomme wrote: Hi, Conditions checked for ARM targets in vector-related effective targets are inconsistent: * sometimes arm*-*-* is checked * sometimes

Re: [PATCH, GCC/testsuite/ARM] Consistently check for neon in vect effective targets

On 19/06/17 15:31, Christophe Lyon wrote: On 19 June 2017 at 16:11, Thomas Preudhomme wrote: On 19/06/17 10:16, Thomas Preudhomme wrote: On 19/06/17 08:41, Christophe Lyon wrote: Hi Thomas, On 15 June 2017 at 18:18, Thomas Preudhomme wrote: Hi, Conditions checked for ARM

Re: [patch, libfortran] Speed up cshift for dim > 1

. Regards Thomas

[arm-embedded] [PATCH, ARM] Implement __ARM_FEATURE_COPROC coprocessor intrinsic feature macro

Hi, We have decided to apply the following patch to the ARM/embedded-6-branch and ARM/embedded-7-branch to implement the __ARM_FEATURE_COPROC coprocessor intrinsic feature macro. 2017-06-20 Thomas Preud'homme Backport from mainline 2017-06-20 Prakhar Bah

[arm-embedded] [PATCH, GCC/LTO, ping] Fix PR69866: LTO with def for weak alias in regular object file

Hi, We have decided to apply the referenced fix (r249352) to the ARM/embedded-6-branch along with its initial commit (r249224) to fix an ICE with LTO and aliases. Fix PR69866 2017-06-20 Thomas Preud'homme Backport from mainline 2017-06-15 Jan Hu

[arm-embedded] [PATCH, GCC/ARM, Stage 1] Rename FPSCR builtins to correct names

Hi, We have decided to apply the following patch to the embedded-6-branch to fix naming of an ARM intrinsic. ChangeLog entry is as follows: 2017-06-20 Thomas Preud'homme Backport from mainline 2017-05-04 Prakhar Bahuguna gcc/ * gcc/config/ar

[PATCH, GCC/ARM] Remove ARMv8-M code for D17-D31

=soft - include maxregno in that loop ChangeLog entry is as follows: *** gcc/ChangeLog *** 2017-06-13 Thomas Preud'homme * config/arm/arm.c (arm_option_override): Forbid ARMv8-M Security Extensions with more than 16 double VFP regi

Re: [PATCH, contrib] Support multi-tool sum files in dg-cmp-results.sh

Hi Mike, Sorry, there was a mistake in the patch I sent. Please find an updated patch below. ChangeLog entry unchanged: *** contrib/ChangeLog *** 2017-06-14 Thomas Preud'homme * dg-cmp-results.sh: Keep test result lines rather than throwing header and summary to su

[PATCH, GCC/contrib] Fix variant selection in dg-cmp-results.sh

Hi, Commit r249422 to dg-cmp-results.sh broke the variant selection feature where one can restrict the regression test to a specific target variant. This fix restores the feature. ChangeLog entry is as follows: *** contrib/ChangeLog *** 2017-06-21 Thomas Preud'homme * d

Re: [PATCH, GCC/ARM, Stage 1] Rename FPSCR builtins to correct names

patch applied cleanly on each of these versions and the testsuite didn't show any regression for any of the backport when run for Cortex-M7. Patches attached for reference. ChangeLog entries: *** gcc/ChangeLog *** 2017-06-20 Thomas Preud'homme Backport from mainline 2017

Re: [Patch, fortran] PR34640 - ICE when assigning item of a derived-component to a pointer

Great Array Descrptor Reform (TM) tends to become longer, not shorter. So, OK to proceed from my side. And thank you very much for taking on this thorny (and, for gfortran, very fundamental problem). Regards Thomas

Re: [PATCH, GCC/ARM, Stage 1] Rename FPSCR builtins to correct names

Hi Christophe, On 23/06/17 20:10, Christophe Lyon wrote: Hi Thomas, On 23 June 2017 at 17:48, Thomas Preudhomme wrote: Hi Kyrill, On 10/04/17 15:01, Kyrill Tkachov wrote: Hi Prakhar, Sorry for the delay, On 22/03/17 10:46, Prakhar Bahuguna wrote: The GCC documentation in section

[PATCH, GCC/ARM, gcc-5-branch] Fix gcc.target/arm/fpscr.c

Hi, As raised by Christophe Lyon, fpscr.c FAILs because arm_fp_ok and arm_fp are not defined in GCC 5. This commit changes the test to use the same recipe as gcc.target/arm/cmp-2.c ChangeLog entry is as follows: *** gcc/testsuite/ChangeLog *** 2017-06-26 Thomas Preud'

Re: [PATCH, ARM] Implement __ARM_FEATURE_COPROC coprocessor intrinsic feature macro

ch changes the above condition into: + if (TARGET_32BIT && arm_arch4 && !(arm_arch8 && !arm_arch_notm)) (which is not very readable with all the negations) That seems wrong. ARMv8-A was intended, not ARMv8-R. However the tests should be fixed for the macro not to be tested on

Re: [PATCH, ARM] Implement __ARM_FEATURE_COPROC coprocessor intrinsic feature macro

On 26/06/17 15:16, Christophe Lyon wrote: On 26 June 2017 at 16:09, Thomas Preudhomme wrote: Hi Christophe, On 21/06/17 17:57, Christophe Lyon wrote: Hi, On 19 June 2017 at 11:32, Richard Earnshaw (lists) wrote: On 16/06/17 15:56, Prakhar Bahuguna wrote: On 16/06/2017 15:37:18

Re: [PATCH, ARM] Implement __ARM_FEATURE_COPROC coprocessor intrinsic feature macro

On 26/06/17 17:01, Thomas Preudhomme wrote: On 26/06/17 15:16, Christophe Lyon wrote: You mean the macro is expected not to be defined on ARMv8-A ? Correct. Most instructions its value represent are not available on ARMv8-A and for those that are the intrinsics are deprecated. I&#x

Re: [PATCH, GCC/ARM, gcc-5-branch, ping] Fix gcc.target/arm/fpscr.c

Ping? Best regards, Thomas On 26/06/17 12:32, Thomas Preudhomme wrote: Hi, As raised by Christophe Lyon, fpscr.c FAILs because arm_fp_ok and arm_fp are not defined in GCC 5. This commit changes the test to use the same recipe as gcc.target/arm/cmp-2.c ChangeLog entry is as follows

Re: [PATCH, GCC/testsuite/ARM] Consistently check for neon in vect effective targets

st regards, Thomas diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp index ded6383cc1f9a1489cd83e1dace0c2fc48e252c3..aa8550c9d2cf0ae7e157d9c67fa06ad811651421 100644 --- a/gcc/testsuite/lib/target-supports.exp +++ b/gcc/testsuite/lib/target-supports.exp @@ -2916

Re: [PATCH, GCC/testsuite/ARM] Consistently check for neon in vect effective targets

On 28/06/17 15:59, Kyrill Tkachov wrote: Hi Thomas, On 28/06/17 15:49, Thomas Preudhomme wrote: On 20/06/17 13:44, Christophe Lyon wrote: The results with a more recent trunk (r249356)) are here: http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/249356

Re: [PATCH, GCC/ARM, ping] Remove ARMv8-M code for D17-D31

Ping? *** gcc/ChangeLog *** 2017-06-13 Thomas Preud'homme * config/arm/arm.c (arm_option_override): Forbid ARMv8-M Security Extensions with more than 16 double VFP registers. (cmse_nonsecure_entry_clear_before_return): Remove second entry of to_clear_mas

Re: [PATCH, GCC/ARM] Remove ARMv8-M code for D17-D31

Hi Richard, On 28/06/17 16:56, Richard Earnshaw (lists) wrote: On 20/06/17 16:01, Thomas Preudhomme wrote: Hi, Function cmse_nonsecure_entry_clear_before_return has code to deal with high VFP register (D16-D31) while ARMv8-M Baseline and Mainline both do not support more than 16 double VFP

[PATCH, GCC/ARM, 0/3] Add support for ARMv8-R

Hi, This patch series adds support for the ARMv8-R architecture[1] and ARM Cortex-R52[2] to GCC. The patch series consist of the following patches: [ 1/3] Add missing MIDR information for ARM Cortex-R7 and Cortex-R8 processor [ 2/3] Add support for ARMv8-R architecture [ 3/3] Add support for A

[PATCH 1/3, GCC/ARM] Add MIDR info for ARM Cortex-R7 and Cortex-R8

Hi, The driver is missing MIDR information for processors ARM Cortex-R7 and Cortex-R8 to support -march/-mcpu/-mtune=native on the command line. This patch adds the missing information. ChangeLog entry is as follows: *** gcc/ChangeLog *** 2017-01-31 Thomas Preud'homme * confi

[PATCH 2/3, GCC/ARM] Add support for ARMv8-R architecture

/architecture/r-profile/docs/ddi0568/latest/arm-architecture-reference-manual-supplement-armv8-for-the-armv8-r-aarch32-architecture-profile ChangeLog entries are as follow: *** gcc/ChangeLog *** 2017-01-31 Thomas Preud'homme * config/arm/arm-cpus.in (armv8-r, armv8-r+rcr): Add new

[PATCH 3/3, GCC/ARM] Add support for ARM Cortex-R52 processor

Hi, This patch adds support for the ARM Cortex-R52 processor rencently announced. [1] https://developer.arm.com/products/processors/cortex-r/cortex-r52 ChangeLog entry is as follows: *** gcc/ChangeLog *** 2017-01-31 Thomas Preud'homme * config/arm/arm-cpus.in (cortex-r52)

Re: [PATCH, GCC/ARM, 0/3] Add support for ARMv8-R

On 29/06/17 15:34, Christophe Lyon wrote: On 29 June 2017 at 15:52, Thomas Preudhomme wrote: Hi, This patch series adds support for the ARMv8-R architecture[1] and ARM Cortex-R52[2] to GCC. The patch series consist of the following patches: Hi Thomas, I think you need to rebase your patch

Re: [PATCH 2/3, GCC/ARM] Add support for ARMv8-R architecture

Please ignore this patch. I'll respin the patch on a more recent GCC. Best regards, Thomas On 29/06/17 14:55, Thomas Preudhomme wrote: Hi, This patch adds support for ARMv8-R architecture [1] which was recently announced. User level instructions for ARMv8-R are the same as those in AR

Re: [PATCH 3/3, GCC/ARM] Add support for ARM Cortex-R52 processor

Please ignore this patch. I'll respin the patch on a more recent GCC. Best regards, Thomas On 29/06/17 14:56, Thomas Preudhomme wrote: Hi, This patch adds support for the ARM Cortex-R52 processor rencently announced. [1] https://developer.arm.com/products/processors/cortex-r/corte

Re: [PATCH, GCC/ARM, 0/3] Add support for ARMv8-R

On 29/06/17 16:12, Christophe Lyon wrote: On 29 June 2017 at 16:37, Thomas Preudhomme Why do you link armv8-r architecture definition to cortex-r4? I understand, where did I do such a thing? In patch #2 you have: diff --git a/gcc/config/arm/arm-cpu-data.h b/gcc/config/arm/arm-cpu

Re: [PATCH, GCC/ARM, gcc-5-branch, ping2] Fix gcc.target/arm/fpscr.c

Ping? Best regards, Thomas On 28/06/17 12:35, Thomas Preudhomme wrote: Ping? Best regards, Thomas On 26/06/17 12:32, Thomas Preudhomme wrote: Hi, As raised by Christophe Lyon, fpscr.c FAILs because arm_fp_ok and arm_fp are not defined in GCC 5. This commit changes the test to use the

[patch, fortran] Implement blocked eoshift for eoshift0

dim =3 t =3.00043702 Regression-tested. OK for trunk? Regards Thomas 2017-07-01 Thomas Koenig * intrinsics/eoshift0.c: For contiguous arrays, use block algorithm. Use memcpy where possible. 2017-07-01 Thomas Koenig * gfortran/eoshi

Re: [gomp4] fix an ICE involving assumed-size arrays

ll dtest (a, n) > + > + do i = 1, n > + if (a(i) /= i) call abort > + end do > +end program test > + > +subroutine dtest (a, n) > + integer i, n > + integer a(*) > + > + !$acc enter data copyin(a(1:n)) > + > + !$acc parallel loop > + do i = 1, n > + a(i) = i > + end do > + > + !$acc exit data copyout(a(1:n)) > +end subroutine dtest Grüße Thomas

Re: [PATCH, 2/4] Handle GOMP_OPENACC_NVPTX_{DISASM,SAVE_TEMPS} in libgomp nvptx plugin

t you to need to use secure_getenv as in > > plugin-hsa.c; certainly for anything that could results in writes to a > > file like that. > > Yeah, definitely it should be using secure_getenv/__secure_getenv. ACK. > And IMNSHO GOMP_DEBUG too. But why that? Isn't GOMP_DEBUG just controlling terminal debugging output (that you'd also like to see in setuid/setgid programs)? Grüße Thomas

[patch, libgfortran] Use memcpy in a few more places for eoshift

7;t expect anything bad (because I tested all test cases containing *eoshift*). OK for trunk if this passes? Regards Thomas 2017-06-03 Thomas Koenig * intrinsics/eoshift2.c (eoshift2): Use memcpy for innermost copy where possible. * m4/eoshift1.m4 (eoshift1)

Fix ChangeLog format in r247584

Hi, This patch fixes relative pathnames in gcc/ChangeLog for r247584. Committed as obvious to trunk, GCC 5, 6 and 7. Best regards, Thomas diff --git a/gcc/ChangeLog b/gcc/ChangeLog index f9e00198bbfd352960685b5c72193570e232e68a..39bdcb12ebbad3cdbdce6b9d4dd87c28610e37fe 100644 --- a/gcc

Re: [PATCH 1/3, GCC/ARM, ping] Add MIDR info for ARM Cortex-R7 and Cortex-R8

Ping? Best regards, Thomas On 29/06/17 14:55, Thomas Preudhomme wrote: Hi, The driver is missing MIDR information for processors ARM Cortex-R7 and Cortex-R8 to support -march/-mcpu/-mtune=native on the command line. This patch adds the missing information. ChangeLog entry is as follows

Re: [Patch, fortran] PR34640 - ICE when assigning item of a derived-component to a pointer

a normal argument - a temporary copy appears to be made. While this code is correct, I am wodering if it is intentional. Is the span field in the array descriptor used in the called subroutine? Regards Thomas

[patch, libfortran, proof of concept] maxloc for character variables

if a bit tedious. If anything more is needed for trans-* (for the dim=1 case of one-dimensional arrays, which is currently inlined), I'll need come back to the list for help. Just a heads up that I am working on this, and hope to get this bug/missing feature in for gcc 8. Just another feature of F2003... Regards Thomas

[PATCH, GCC/ARM] Fix cmse_nonsecure_entry return insn size

t fails to compile due to bugs in the RTL frontend (PR82815 and PR82817) ChangeLog entries are as follows: *** gcc/ChangeLog *** 2017-10-30 Thomas Preud'homme * config/arm/arm.c (output_return_instruction): Add comments to indicate requirement for cmse_nonsecure_entry re

[patch, doc] Document that new Perl version breaks required automake

t;make pdf". OK for trunk? 2017-11-09 Thomas Koenig PR bootstrap/82856 doc/install.texi: Document incompatibility of Perl >=5.6.26 with the required version of automake 1.11.6. Index: doc/install.texi

[PATCH, GCC/testsuite] Fix retrieval of testname

include a list of options; extract the file name. set testcase [lindex $testcase 0] ChangeLog entry is as follows: *** gcc/testsuite/ChangeLog *** 2017-11-08 Thomas Preud'homme * lib/scanasm.exp (scan-assembler): Extract filename from testname used in summary.

<    15   16   17   18   19   20   21   22   23   24   >