From: Thomas Schwinge
gcc/c/
* c-parser.c (c_parser_oacc_all_clauses): New function.
(c_parser_oacc_parallel): Use it.
* c-typeck.c (c_finish_omp_clauses): Update comment. Remove
duplicated variable initialization.
---
gcc/c/c-parser.c | 59
From: Thomas Schwinge
gcc/c-family/
* c-pragma.h (pragma_omp_clause): Add PRAGMA_OMP_CLAUSE_COPY,
PRAGMA_OMP_CLAUSE_COPYOUT, PRAGMA_OMP_CLAUSE_CREATE,
PRAGMA_OMP_CLAUSE_DELETE, PRAGMA_OMP_CLAUSE_DEVICEPTR,
PRAGMA_OMP_CLAUSE_PRESENT
From: Thomas Schwinge
gcc/
* tree-core.h (omp_clause_map_kind): Make the identifiers' bit
patterns more obvious. Add comments.
* omp-low.c (lower_oacc_parallel, lower_omp_target): Test for
omp_clause_map_kind flags set instead of for values.
---
gc
From: Thomas Schwinge
gcc/c/
* c-parser.c (OACC_PARALLEL_CLAUSE_MASK): Add
PRAGMA_OMP_CLAUSE_COPY, PRAGMA_OMP_CLAUSE_COPYIN,
PRAGMA_OMP_CLAUSE_COPYOUT, PRAGMA_OMP_CLAUSE_CREATE,
PRAGMA_OMP_CLAUSE_DEVICEPTR, PRAGMA_OMP_CLAUSE_PRESENT
From: Thomas Schwinge
gcc/
* tree-core.h (omp_clause_map_kind): Add OMP_CLAUSE_MAP_FORCE,
OMP_CLAUSE_MAP_FORCE_ALLOC, OMP_CLAUSE_MAP_FORCE_TO,
OMP_CLAUSE_MAP_FORCE_FROM, OMP_CLAUSE_MAP_FORCE_TOFROM,
OMP_CLAUSE_MAP_FORCE_PRESENT
From: Thomas Schwinge
gcc/
* gimplify.c (gimplify_call_expr, gimplify_modify_expr)
(omp_firstprivatize_variable, omp_notice_threadprivate_variable)
(omp_notice_variable, gimplify_adjust_omp_clauses)
(gimplify_omp_workshare): Treat ORT_TARGET as a flag, not
From: Thomas Schwinge
libgomp/
* libgomp_g.h: Include for size_t.
---
libgomp/libgomp_g.h | 1 +
1 file changed, 1 insertion(+)
diff --git libgomp/libgomp_g.h libgomp/libgomp_g.h
index 32c4cf6..577956a 100644
--- libgomp/libgomp_g.h
+++ libgomp/libgomp_g.h
@@ -29,6 +29,7
From: Thomas Schwinge
libgomp/
* testsuite/lib/libgomp.exp (libgomp_init): Don't add -fopenmp to
ALWAYS_CFLAGS.
* testsuite/libgomp.c++/c++.exp (ALWAYS_CFLAGS): Add -fopenmp.
* testsuite/libgomp.c/c.exp (ALWAYS_CFLAGS): Likewise.
* test
From: Thomas Schwinge
gcc/c-family/
* c-cppbuiltin.c (c_cpp_builtins): Conditionally define _OPENACC.
gcc/fortran/
* cpp.c (cpp_define_builtins): Conditionally define _OPENACC.
gcc/testsuite/
* c-c++-common/cpp/openacc-define-1.c: Test _OPENACC
From: Thomas Schwinge
gcc/
* gimplify.c (gimplify_body): Consider flag_openacc additionally
to flag_openmp.
* omp-low.c (execute_expand_omp, execute_lower_omp)
(gate_diagnose_omp_blocks): Likewise.
gcc/testsuite/
* gcc.dg/goacc-gomp/goacc
From: Thomas Schwinge
gcc/c-family/
* c.opt (fopenacc): New option.
gcc/fortran/
* lang.opt (fopenacc): New option.
* invoke.texi (-fopenacc): Document it.
* gfortran.h (gfc_option_t): New member.
* options.c (gfc_init_options
From: Thomas Schwinge
gcc/c-family/
* c-pragma.c (oacc_pragmas): New array.
(c_pp_lookup_pragma, init_pragma): Handle it.
gcc/
* doc/invoke.texi (-fopenacc): Update.
gcc/c/
* c-parser.c (c_parser_omp_all_clauses): Make a parser error
From: Thomas Schwinge
gcc/
* oacc-builtins.def: New file.
* Makefile.in (BUILTINS_DEF): Add oacc-builtins.def.
* builtins.def (DEF_GOACC_BUILTIN): New macro.
Include "oacc-builtins.def".
gcc/fortran/
* f95-lang.c (DEF_GOACC_BUI
From: Thomas Schwinge
gcc/
* gcc.c (LINK_COMMAND_SPEC, GOMP_SELF_SPECS): For -fopenacc, link
to libgomp and its dependencies.
* config/arc/arc.h (LINK_COMMAND_SPEC): Likewise.
* config/darwin.h (LINK_COMMAND_SPEC_A): Likewise.
* config/i386/mingw32
ompiler error: tree
code 'statement_list' is not supported in LTO streams)
Grüße
Thomas
> Fortran: Support OpenMP's 'allocate' directive for stack vars
>
> gcc/fortran/ChangeLog:
>
> * gfortran.h (ext_attr_t): Add omp_allocate flag.
> *
gt;>>>> +++ b/contrib/dg-extract-results.py
>>>>>> @@ -113,7 +113,7 @@ class Prog:
>>>>>> # Whether to create .sum rather than .log output.
>>>>>> self.do_sum = True
>>>>>> # Regexps used while parsing.
>>>>>> -self.test_run_re = re.compile (r'^Test Run By (\S+) on (.*)$')
>>>>>> +self.test_run_re = re.compile (r'^Test run by (\S+) on (.*)$')
>>>>>> self.tool_re = re.compile (r'^\t\t=== (.*) tests ===$')
>>>>>> self.result_re = re.compile
>>>>>> (r'^(PASS|XPASS|FAIL|XFAIL|UNRESOLVED'
>>>>>>
>>>>>> r'|WARNING|ERROR|UNSUPPORTED|UNTESTED'
>>>>>> diff --git a/contrib/dg-extract-results.sh
>>>>>> b/contrib/dg-extract-results.sh
>>>>>> index ff6c50d029c..57f6fe0e997 100755
>>>>>> --- a/contrib/dg-extract-results.sh
>>>>>> +++ b/contrib/dg-extract-results.sh
>>>>>> @@ -271,7 +271,7 @@ cat $SUM_FILES \
>>>>>>
>>>>>> # Write the begining of the combined summary file.
>>>>>>
>>>>>> -head -n 2 $FIRST_SUM
>>>>>> +head -n 3 $FIRST_SUM
>>>>>> echo
>>>>>> echo " === $TOOL tests ==="
>>>>>> echo
-
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
c-c++/c++.exp:proc check_effective_target_c { } {
libgomp/testsuite/libgomp.oacc-c++/c++.exp-return 0
libgomp/testsuite/libgomp.oacc-c++/c++.exp-}
libgomp/testsuite/libgomp.oacc-c++/c++.exp:proc check_effective_target_c++ { } {
libgomp/testsuite/libgomp.oacc-c++/c++.exp-return 1
libgomp/testsuite
Hi Tobias!
On 2023-10-18T11:53:30+0200, Tobias Burnus wrote:
> On 18.10.23 11:44, Thomas Schwinge wrote:
>> No need to change anything now, but in case that's useful later:
>> [...]
>> ..., just noting that '{ target c }', '{ target c++ }' are trivia
'ptx_isa_option' -- but may be convinced otherwise (incremental change),
if that's maybe more convenient for others? (Roger?)
Grüße
Thomas
> nvptx: Use fatal_error when -march= is missing not an assert [PR111093]
>
> gcc/ChangeLog:
>
> PR target/111093
>
sk the right questions... ;-)
What do people think about the attached
"Enable top-level recursive 'autoreconf'"? Only lightly tested, so far.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit bes
Hi!
On 2023-10-19T11:57:33+0200, Andreas Schwab wrote:
> On Okt 19 2023, Thomas Schwinge wrote:
>> On 2023-10-18T15:42:18+0100, R jd <3246251196r...@gmail.com> wrote:
>>> I guess I can ask, why there is not a recursive approach for configuring
>>> GCC.
nce, I
wholeheartedly recommend for doing pthreads debugging).
The interface remains as before - link in pthread to get asynchronous
I/O, which matches what ifort does.
So, OK for trunk?
Regards
Thomas
2018-07-02 Nicolas Koenig
Thomas Koenig
PR fortran/25829
ChangeLog which fixes the typo :-)
Again regression-tested.
So, OK for trunk?
Regards
Thomas
2018-07-02 Nicolas Koenig
Thomas Koenig
PR fortran/25829
* gfortran.texi: Add description of asynchronous I/O.
* trans-decl.c (gfc_finish_var_decl): Treat
o control
which register it loads into. This is because sharing the PIC register
between prologue and epilogue could lead to spilling due to CSE again
which an attacker could use to control what the canary gets compared
against.
ChangeLog entries are as follows:
*** gcc/ChangeLog ***
2018-07-05 Tho
Adding Jeff and Eric since the patch adds an RTL target hook.
Best regards,
Thomas
On Thu, 5 Jul 2018 at 15:48, Thomas Preudhomme
wrote:
>
> In case of high register pressure in PIC mode, address of the stack
> protector's guard can be spilled on ARM targets as shown in P
fixed.
Regards
Thomas
Hi Janus,
The cleaner approach would certainly be to avoid short-circuiting of
impure functions altogether. If we can all agree that this is a good
idea,
This is a fine example of logical short-circuiting - the condition you
mention is false, therefore the rest need not be evaluated :-)
pthreads, so the
tests would not be executed in parallel, and some of them
would fail.
So, here is the final version. I would really like to get this
into trunk, and out of the way, so Nicolas and I can focus on
other things.
So, OK?
Regards
Thomas
2018-07-15 Nicolas Koenig
Thomas
ith -pthread enabled.
However, this is something for the future, and requires knowledge
of dejagnu that I don't currently have :-)
Regards
Thomas
ised
us to put all the stuff requiring pthreads into libgomp.
Do you have a pointer to that previous discussion?
https://gcc.gnu.org/ml/fortran/2018-04/msg00048.html is what I based
my recollection on.
Regards
Thomas
, which should then be enabled by -Wextra.
-Waggressive-function-elimination, could be reused for this,
or something else
Regards
Thomas
other matter).
Regards
Thomas
Fixed in attached patch. ChangeLog entries are unchanged:
*** gcc/ChangeLog ***
2018-07-05 Thomas Preud'homme
PR target/85434
* target-insns.def (stack_protect_combined_set): Define new standard
pattern name.
(stack_protect_combined_test): Likewise.
* cfgexp
ntage?
Regards
Thomas
Am 17.07.2018 um 19:19 schrieb Janus Weil:
2018-07-17 17:18 GMT+02:00 Fritz Reese :
2018-07-17 9:52 GMT+02:00 Janus Weil :
In other words: Does it make sense to tone down
-Wfunction-elimination, by only warning about impure functions?
Here is an update of the patch which does that. Regtesting
ct on 521.wrf, so this would
be ideal.
If you could run 521.wrf on x86_64, and find that it does not
regress measureably (or even shows an improvement), the patch is OK.
I'd be interested in the timings you get.
Regards
Thomas
Hi Kyrlll,
> Am 18.07.2018 um 13:17 schrieb Kyrill Tkachov :
>
> Thomas, Janne, would this relaxation of NaN handling be acceptable given the
> benefits
> mentioned above? If so, what would be the recommended adjustment to the
> nan_1.f90 test?
I would be a bit careful about
uot;Name(processor_type) Type(enum processor_type) ForceHelp"
> +print "Known ARM CPUs (for use with the -mtune= options):\n"
Why changing the text beyond adding ForceHelp?
> +@item ForceHelp
> +This property is optional. If present, enum values is printed
> +in @option{--h
[Dropping Jeff Law from the list since he already commented on the
middle end parts]
Hi Kyrill,
On Thu, 19 Jul 2018 at 12:02, Kyrill Tkachov
wrote:
>
> Hi Thomas,
>
> On 17/07/18 12:02, Thomas Preudhomme wrote:
> > Fixed in attached patch. ChangeLog entries are unchange
oesn't that expand to more insns
(subreg to reg and reg to subreg)? Couldn't you improve the logic to
check that there is actually a mode change so that if there isn't
(like moving from one subreg to another) just expand to a single move?
Best regards,
Thomas
>
> This patch e
:
*** gcc/ChangeLog ***
2018-07-05 Thomas Preud'homme
* target-insns.def (stack_protect_combined_set): Define new standard
pattern name.
(stack_protect_combined_test): Likewise.
* cfgexpand.c (stack_protect_prologue): Try new
stack_protect_combined_set pattern
Hi Tamar,
On Wed, 25 Jul 2018 at 16:28, Tamar Christina wrote:
>
> Hi Thomas,
>
> Thanks for the review!
>
> > >
> > > I don't believe the TARGET_FP16 guard to be needed, because the
> > > pattern doesn't actually generate code and requires a
On Thu, 26 Jul 2018 at 12:01, Tamar Christina wrote:
>
> Hi Thomas,
>
> > -Original Message-
> > From: Thomas Preudhomme
> > Sent: Thursday, July 26, 2018 09:29
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; Ramana Radhak
hours or so? If so, I would like to commit this. Otherwise, Nicolas
and I will not be able to fix this for a week or so, and it would be
best to revert the async I/O patch :-(
Regards
Thomas
2018-07-25 Thomas Koenig
* io/async.h: Test for feature macros for __gthread_cond_t and
Am 26.07.2018 um 22:54 schrieb Thomas Koenig:
Hi Ulrich,
The problem is that io/asynch.h unconditionally uses a couple of
features that are not provided by gthr-simplex, in particular
__gthread_cond_t
and
__gthread_equal / __gthread_self
According to the documentation in gthr.h, the
8a98da-0231-7a95-017b-ea5d8ae65...@rivosinc.com>.
Otherwise:
> I do have a multilib problem [with libgomp] on Darwin (which has been noticed
> : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951) but it is not obvious
> how the fix proposed would solve this - unless it’s some sub
ue to
'torture-init-done', due to 'LTO_TORTURE_OPTIONS'), but it does
'set-torture-options', then skips 'torture-finish', and then any next
'torture-init' detects the mismatch, thus ERRORs.
I can be convinced otherwise, but I still maintain my positi
just calls 'gcc-dg-runtest', which internally does
'torture-init', 'torture-finish' -- like in a number of other '*.exp'
files. As you say, this patch "doesn't actually fix any errors".
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
the current state of affaris plus some polishing, the attached
"Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing
(instead of build-time 'CC' etc.) [PR109951]"
appears to be doing the right thing per my (limited, so far) tes
Hi!
OK to push the attached
"Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'"?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Th
Hi!
OK to push the attached
"driver: Forward '-lgfortran', '-lm' to offloading compilation"?
(We didn't have a PR open for that, or did we?)
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
Mün
Hi!
On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote:
> On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge
> wrote:
>> This issue comes up in context of me working on C++ support for GCN and
>> nvptx target. Those targets shall default to '-fno-exceptions' -- or,
>&g
Hi!
On 2023-06-07T09:12:31+0100, Jonathan Wakely wrote:
> On Wed, 7 Jun 2023 at 08:13, Thomas Schwinge wrote:
>> On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote:
>> > On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge
>> > wrote:
>> >> This issue comes up
.s
> new file mode 100644
> index 000..e69de29bb2d
OK to push the attached
"Remove 'gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s'"?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Ges
* c-c++-common/Wfree-nonheap-object-2.c: New test.
> * c-c++-common/Wfree-nonheap-object-3.c: New test.
> * c-c++-common/Wfree-nonheap-object.c: New test.
OK to push the attached
"Tighten 'dg-warning' alternatives in
'c-c++-common/Wfree-nonheap-object{,-2,-3}
Hi!
On 2023-06-05T14:18:48+0200, I wrote:
> OK to push the attached
> "Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'"?
Ping.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Ges
Hi!
On 2023-06-05T14:25:18+0200, I wrote:
> OK to push the attached
> "driver: Forward '-lgfortran', '-lm' to offloading compilation"?
> (We didn't have a PR open for that, or did we?)
Ping.
Grüße
Thomas
-
Siemens Electronic Des
P_TARGET_OFFLOAD is set to MANDATORY but only
> the host device is available.*" { target { ! offload_device } } } */
> +/* { dg-output ".*libgomp: OMP_TARGET_OFFLOAD is set to MANDATORY but device
> not found.*" { target offload_device } } */
I intend to push the attach
; instead of 'GOMP_MAP_FLAG_PRESENT' (plus
'GOMP_MAP_FORCE_PRESENT')?
Instead of the current effective 'GOMP_MAP_FLAG_ALWAYS_PRESENT':
GOMP_MAP_FLAG_SPECIAL_0
| GOMP_MAP_FLAG_SPECIAL_2
| GOMP_MAP_FLAG_SPECIAL_5
..., it could/should use a simpler flag combination? (My idea is that
this later make usage of flag bits for other purposes easier -- but I've
not verified that in depth.)
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
Hi!
On 2023-06-13T13:11:38+0200, Tobias Burnus wrote:
> On 13.06.23 12:42, Thomas Schwinge wrote:
>> On 2023-06-05T14:18:48+0200, I wrote:
>>> OK to push the attached
>>> "Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'"?
>>
Hi!
Any objections to pushing the attached
"libgomp testsuite: Don't handle 'lang_link_flags'"?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäf
Hi!
On 2023-06-14T11:42:22+0200, Tobias Burnus wrote:
> On 14.06.23 10:09, Thomas Schwinge wrote:
>> Let me know if I should also adjust the new 'target { ! offload_device }'
>> diagnostic "[...] MANDATORY but only the host device is available" to
>> incl
Hi!
On 2023-06-15T08:50:59+0800, "haochen.jiang via Gcc-patches"
wrote:
> On Linux/x86_64,
Actually: generally...
> 9c03391ba447ff86038d6a34c90ae737c3915b5f is the first bad commit
> commit 9c03391ba447ff86038d6a34c90ae737c3915b5f
> Author: Thomas Schwinge
> Date:
Hi!
On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote:
> On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge wrote:
>> This issue comes up in context of me working on C++ support for GCN and
>> nvptx target. Those targets shall default to '-fno-exceptions' -- or,
>>
Hi!
On 2023-06-15T17:15:54+0200, I wrote:
> On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote:
>> On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge wrote:
>>> This issue comes up in context of me working on C++ support for GCN and
>>> nvptx target. Those targets shall
Hi!
On 2023-06-15T17:15:54+0200, I wrote:
> On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote:
>> On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge wrote:
>>> This issue comes up in context of me working on C++ support for GCN and
>>> nvptx target. Those targets shall
11
Program aborted. Backtrace:
#0 0x400f9c in test
at [...]/libgomp.fortran/loop-transforms/unroll-2.f90:85
#1 0x400fd3 in main
at [...]/libgomp.fortran/loop-transforms/unroll-2.f90:59
Grüße
Thomas
> Changes:
>
> * I missed to update
Hi Chung-Lin!
On 2023-07-13T18:54:00+0800, Chung-Lin Tang wrote:
> On 2023/6/16 5:13 PM, Thomas Schwinge wrote:
>> OK with one small change, please -- unless there's a reason for doing it
>> this way: [...]
> I've adjusted the Fortran implementation as you describ
p, tree clause, int
> spc, dump_flags_t flags)
>
> case OMP_CLAUSE__CACHE_:
>pp_string (pp, "(");
> + if (OMP_CLAUSE__CACHE__READONLY (clause))
> + pp_string (pp, "readonly:");
>dump_generic_node (pp, OMP_CLAUSE_DECL (clause),
&g
which enables us to start
the recruitment process.
We look forward to receiving your detailed job inquiry with specifications and
other parameters to enable us to submit our suitable and competitive profiles.
Kind Regards,
Vinod Thomas
Bang
Hi!
On 2023-07-19T23:41:47+0200, Gerald Pfeifer wrote:
> It's my pleasure to announce Thomas Schwinge as co-maintainer of the
> nvptx backend.
>
> Congratulations and Happy Hacking, Thomas! Please go ahead and update
> MAINTAINERS accordingly.
>
> Gerald (on behalf
gt; -return EINVAL;
> -
>return 0;
> }
>
> @@ -4624,18 +4706,36 @@ omp_target_memcpy_rect_copy (void *dst, const void
> *src,
>struct gomp_device_descr *dst_devicep,
>struct gomp_device_descr *src_devicep)
>
Hi Tom!
Ping.
Grüße
Thomas
On 2022-06-07T17:41:16+0200, I wrote:
> Hi!
>
> On 2022-05-30T09:06:21+0200, Tobias Burnus wrote:
>> On 29.05.22 22:49, Thomas Schwinge wrote:
>>> Not sure if that's what you had in mind, but what do you think about the
>>>
Hi Tom!
Ping.
Grüße
Thomas
On 2022-06-15T23:18:10+0200, I wrote:
> Hi Tom!
>
> On 2022-05-13T16:20:14+0200, I wrote:
>> On 2022-02-04T13:09:29+0100, Tom de Vries via Gcc wrote:
>>> On 2/4/22 08:21, Thomas Schwinge wrote:
>>>> On 2022-02-03T13:35:55+000
OK to push the attached
"Define 'OMP_REQUIRES_[...]', 'GOMP_REQUIRES_[...]' in a single place"?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer:
ot;? (Currently
testing.)
> (and no longer a weak variable)
... which actually removed my "contribution" (hack!) to this patch. ;-)
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkte
] == '\0')
+fatal_error (input_location, "GCC_OFFLOAD_OMP_REQUIRES_FILE unset");
..., and all offloading compilation fail with that 'fatal_error'. OK to
push the attached "Fix Intel MIC 'mkoffload' for OpenMP 'requires'"?
(Cur
Hi Tobias!
On 2022-07-06T13:29:14+0200, Tobias Burnus wrote:
> On 06.07.22 13:04, Thomas Schwinge wrote:
>> On 2022-06-08T05:56:02+0200, Tobias Burnus wrote:
>>> PS: I have not fully tested the intelmic version.
>> As part of my standard testing, I'm reporting tha
Hi Tobias!
On 2022-07-06T15:59:59+0200, Tobias Burnus wrote:
> On 06.07.22 12:42, Thomas Schwinge wrote:
>> --- a/libgomp/target.c
>> +++ b/libgomp/target.c
>> /* This function should be called from every offload image while unloading.
>> GOMP_offload_unreg
MP 'requires' directive with non-identical clauses in
> multiple compilation units: 'unified_address, unified_shared_memory' vs.
> 'unified_address'" "" { target *-*-* } 0 } */
> +/* { dg-excess-errors "Ignore messages like: errors duri
> +int a[10];
> +extern void foo (void);
> +
> +int
> +main (void)
> +{
> + #pragma omp target
> + for (int i = 0; i < 10; i++)
> +a[i] = 0;
> +
> + foo ();
> + return 0;
> +}
> +
> +/* { dg-output "devices present but 'omp requires unified_address,
&g
Hi Tobias!
On 2022-07-07T11:36:34+0200, Tobias Burnus wrote:
> On 07.07.22 10:42, Thomas Schwinge wrote:
>> In preparation for other changes:
> ...
>> On 2022-06-29T16:33:02+0200, Tobias Burnus wrote:
>>> +/* { dg-output "devices present b
Hi Tobias!
On 2022-07-06T15:30:57+0200, Tobias Burnus wrote:
> On 06.07.22 14:38, Thomas Schwinge wrote:
>> :-) Haha, that's actually *exactly* what I had implemented first! But
>> then I realized that 'target offloading_enabled' is doing exactly that:
>>
quot;OpenMP % directive with %qs specified "
> + "only in some compilation units", buf2);
> + inform (UNKNOWN_LOCATION, "%qs has %qs",
> + val != OMP_REQUIRES_TARGET_USED ? fn2 : fn1,
> + buf
Hi!
On 2022-07-07T15:56:28+0200, Tobias Burnus wrote:
> On 07.07.22 15:26, Thomas Schwinge wrote:
>> On 2022-07-01T23:08:16+0200, Tobias Burnus
>> wrote:
>>> Updated version attached – I hope I got everything right, but I start to
>>> get tired, I am not 100% su
tests which were sensitive
>> > to the
>> > location being output. In all these cases, the new locations seem more
>> > informative to me than the old ones.
ACK, thanks.
On top of that, I've just pushed to master branch
commit 06b2a2abe26554c6f9365676683d67368cbba
cro 'check_reduction'" "" { target *-*-*
> } check_reduction_loc } */
Oh my, PR101551 "[offloading] Differences in diagnostics etc."
strikes again... The latter two 'note' diagnostics are currently
only emitted in non-offloading configurations. I&#x
Hi Tom!
Ping.
Grüße
Thomas
On 2022-07-05T16:58:54+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-06-07T17:41:16+0200, I wrote:
>> Hi!
>>
>> On 2022-05-30T09:06:21+0200, Tobias Burnus wrote:
>>> On 29.05.22 2
Hi Tom!
Ping.
Grüße
Thomas
On 2022-07-05T16:59:23+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-06-15T23:18:10+0200, I wrote:
>> Hi Tom!
>>
>> On 2022-05-13T16:20:14+0200, I wrote:
>>> On 2022-02-04T13:09:2
Hi Tom!
Ping.
Grüße
Thomas
On 2022-07-13T10:41:23+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-07-05T16:58:54+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
Hi Tom!
Ping.
Grüße
Thomas
On 2022-07-13T10:42:44+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-07-05T16:59:23+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
Hi Tom!
Ping.
Grüße
Thomas
On 2022-07-20T14:44:36+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-07-13T10:41:23+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
Hi Tom!
Ping.
Grüße
Thomas
On 2022-07-20T14:46:03+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-07-13T10:42:44+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
the rust target host info
> * i386.h: define TARGET_RUST_CPU_INFO hook
> * linux-common.h: define hooks for target info
> * lynx.h: likewise
> * mingw32.h: likewise
> * netbsd-elf.h: likewise
> * netbsd64.h: likewise
> * nto.
ime-critical, let me offer that instead of my
"[HACK] Disable 'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO'",
I'll cook up a proper patch, removing the implementations of
'TARGET_RUST_CPU_INFO', 'TARGET_RUST_OS_INFO', etc., but keeping the
ge
Hi Tom!
Ping.
Grüße
Thomas
On 2022-07-27T17:48:46+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-07-20T14:44:36+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
Hi Tom!
Ping.
Grüße
Thomas
On 2022-07-27T17:48:58+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-07-20T14:46:03+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
Hi Tobias!
On 2023-07-28T13:51:41+0200, Tobias Burnus wrote:
> On 27.07.23 23:00, Thomas Schwinge wrote:
>>> + else if (src_devicep != NULL
>>> +&& (dst_devicep == NULL
>>> +|| (dst_devicep->capabilities
>>>
t>:
On 2023-06-30T13:46:07+0200, Thomas Schwinge wrote:
> In particular, the 'lto_mode_identity_table' changes would seem necessary
> to keep standard LTO ('-flto') functional for large 'machine_mode' size?
... which is exactly the problem you've no
}
That is, we should keep here the original 'inform' for 'ctx->location',
and *add another* 'inform' for 'ctx->oacc_default_clause_ctx->location'.
Otherwise that's confusing to users.
Instead of requiring another iteration through you, I'
1 - 100 of 5586 matches
Mail list logo
