orry.
Pushed to master branch commit 14dfbb53594e164fe222476523a68039a8bd5252
"Fix 'libgomp.oacc-c-c++-common/kernels-decompose-1.c' expected
diagnostics", see attached.
Grüße
Thomas
>
> #pragma acc kernels /* { dg-line l_compute[incr c_compute] } */
> +
variable - or whether it should.
(Are the typos here: in "will/should map": 's%map%update', and in
"or whether it should": 's%should%shouldn't'?)
> But that's
> unrelated to this bug fix. See also: https://gcc.gnu.org/PR96668
> for th
#x27;t vs. how they do change things,
pushed to master branch commit 1d9dc3dd74eddd192bec1ac6f4d6548a81deb9a5
"Enhance further testcases to verify handling of OpenACC privatization
level [PR90115]", see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Ansc
Add 'gfortran.dg/goacc-gomp/pr102330-{1,2,3}.f90' [PR102330]", see
attached: currently XFAILed with 'dg-ice'.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Gesch
<https://gcc.gnu.org/PR104774> "OpenACC
'kernels' decomposition: internal compiler error: 'verify_gimple' failed,
with 'loop' with explicit 'seq' or 'independent'"!
Pushed to master branch commit 448741533a75862ebf51d8e73eb1dd1f6a
Hi!
On 2022-02-15T13:40:09+, Julian Brown wrote:
> On Mon, 14 Feb 2022 16:56:35 +0100
> Thomas Schwinge wrote:
>> Two more questions here, in context of <https://gcc.gnu.org/PR102330>
>> "[12 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3932
her "clause printing".
>
> As part of an ICE bug fix that I'm working on, I now need to use
> this in GCC middle end code.
Pushed to master branch commit 828335beb77676acffb5911e575672cb55beb2e9
"Add 'gcc/tree.cc:user_omp_clause_code_name' [PR65095]", se
prune-output "during GIMPLE pass: omplower" }
> + TODO { dg-do link } */
> +
> +#undef KERNELS_DECOMPOSE_ICE_HACK
> +#include "declare-vla.c"
Arseny had later reduced that, and filed <https://gcc.gnu.org/PR104086>.
To document the status quo, pushed
c-c-c++-common/declare-vla.c
>> @@ -38,6 +38,12 @@ f_data (void)
>> for (i = 0; i < N; i++)
>>A[i] = -i;
>>
>> +/* See 'declare-vla-kernels-decompose.c'. */
>> +#ifdef KERNELS_DECOMPOSE_ICE_HACK
>> +(volatile int *) &i;
>&
#x27;t vs. how they do change things,
pushed to master branch commit 2e53fa7bb2ae9fe1152c27e423be9e261da82ddc
"Enhance further testcases to verify handling of OpenACC privatization
level [PR90115]", see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Ansc
ppings
> synchronously",
> - "Fix for is_gimple_reg vars to 'data kernels'"
..., but the misbehavior is visible without the workaround patches, for
example on the master branch.
Pushed to master branch commit 535afbd959bc72de85fca36ba6417f075cca1018
"OpenACC 'ker
out the workaround patches, for
> example on the master branch.
..., and to avoid the need for those (thus, please remove for
the upcoming og12 branch, Kwok), pushed to master branch
commit a07b8f4fb756484893b5612cbe9410970dc76db9
"OpenACC 'kernels' decomposition: resolve
to master branch commit ab46fc7c3bf01337ea4554f08f4f6b0be8173557
"OpenACC privatization diagnostics vs. 'assert' [PR102841]", see
attached.
Grüße
Thomas
> --- a/libgomp/testsuite/libgomp.oacc-c-c++-common/host_data-7.c
> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/host_data-7.c
> @@ -1,6 +1,11 @@
to master branch commit 004fc4f2fc686d3366c9e1a2d8b9183796073866
"Enhance further testcases to verify handling of OpenACC privatization
level [PR90115]", see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkte
any more such issues.
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ünch
Hi Jakub!
On 2022-03-17T17:16:04+0100, Jakub Jelinek wrote:
> On Thu, Nov 11, 2021 at 02:14:05PM +0100, Thomas Schwinge wrote:
>> There appears to be yet another issue: there still are quite a number of
>> 'FAIL: libgomp.c/places-10.c execution test' reports on
>>
g down the failing test-cases.
>>>> Tested on x86_64-linux with nvptx accelerator.
>>>> [...]
>>> Will defer to Thomas, as it is a purely OpenACC change.
>>>
>>> One way to do it is
>>> /* { dg-additional-options "-DEXPENSIVE" { ta
..] and pushed r12-6605 [...]
Pushed to master branch commit 43911ddd18b97d8ebd17d2959f36efa539d359b7
"Remove mysterious '-# Defining these options here in addition to
common.opt is necessary' command-line option", see attached. ;'-)
Grüße
Thomas
with_args = ""
| +} else {
| +print "#error LangEnabledBy("enabledby_langs","enabledby_name",
" \
| +enabledby_posarg", " enabledby_negargs \
| +") with three argumen
| +LangEnabledBy(C ObjC C++ LTO ObjC++)
| ; in common.opt
|
| Warray-bounds=
OK to push the attached "options: Remove
'gcc/c-family/c.opt:Warray-bounds' option definition record"?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arn
to push the attached "options: Remove
'gcc/c-family/c.opt:Wuse-after-free' option definition record"?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäf
(C++ ObjC++)'
instead of originally-posted 'LangEnabledBy(C++ ObjC++,Wall)':
| --- gcc/c-family/c.opt
| +++ gcc/c-family/c.opt
| [...]
| +Wc++11-extensions
| +C++ ObjC++ Var(warn_cxx11_extensions) Warning LangEnabledBy(C++ ObjC++)
Init(1)
| +Warn about C++11 constructs in code compiled
prove diagnostics. OK to push the attached
"options: Improve 'LangEnabledBy' option property diagnostics"? In
addition to standard testing, I've manually verified the error cases.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfst
opts[i] ":\n\t" help[i] "\n\t" help[i + 1] \
> - | "cat 1>&2"
> + print "#error Multiple different help strings for " \
> + opts[i] ":\n\t" help[i] "\n\t&q
ves: OK to push the attached
"options: Clarifications around option definition records' help texts"?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
'gcc/optc-save-gen.awk'. To help the next person -- like,
me in a few weeks ;-) -- wondering about this, OK to push the attached
"options: Clarify 'Init' option property usage for streaming
optimization"?
Grüße
Thomas
> @@ -1257,10 +1258,21
CN and
nvptx offloading configured. This isn't going to cause any real
problems, of course, but it's confusing, and a bad example of
'offload_target_nvptx'.
'offload_device_nvptx' ought to work: "using nvptx offload device".
But again, to keep things simple, I again suggest to
("libcuda.so.1")'.
(Similar to what the libgomp GCN (and before: HSA) plugin is doing, for
example.) Quite likely that our group (at work) are the only ones to
actually use '--with-cuda-driver'?
My proposal now is: we remove '--with-cuda-driver' (make its use a
ibgomp-test-support.exp.in:set hsa_runtime_lib
> "@HSA_RUNTIME_LIB@"
>
> libgomp/testsuite/lib/libgomp.exp: append always_ld_library_path
> ":$hsa_runtime_lib"
But, as I argue in the attached "libgomp testsuite: Don't amend
'LD_LIBRARY_PAT
Hi Jakub!
On 2022-04-06T11:24:17+0200, Jakub Jelinek wrote:
> On Wed, Apr 06, 2022 at 11:20:47AM +0200, Thomas Schwinge wrote:
>> However, the libgomp GCN plugin is unconditionally built against the
>> GCC-shipped 'include/hsa*.h' header files, and at run time does
>
'libhsa-runtime64.so' to a
> 'libdl'-based runtime linking variant.
(Not intending to change anything regarding that.)
Given the 'PLUGIN_HSA_LIBS' change cited above, OK to push the attached
"libgomp GCN plugin: Clean up unused references to system
ailable. */
> +
> +#ifndef GCC_CUDA_H
> +#define GCC_CUDA_H
> +[...]
> +#endif /* GCC_CUDA_H */
OK to push the attached
"Move 'libgomp/plugin/cuda/cuda.h' to 'include/cuda/cuda.h'", so that I'm
also able to use that file in the nvptx-tools, which in
ed9c9139e2ea7b62c11f3dc5b6f6f4
"[nvptx] Use --no-verify for sm_30". OK to push, once nvptx-tools ready?
> Use a more robust workaround: verify using sm_35 when misa=sm_30 is specified
> (either implicitly or explicitly).
Thanks for that suggestion!
Grüße
Thomas
---
hed
"libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into
'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'"?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftu
.148t.dse3 2022-04-12 14:28:19.213520366 +0200
[...]
__attribute__((oacc function (32, 8, 32), oacc parallel, omp target
entrypoint))
void t4_._omp_fn.0 (const struct .omp_data_t.1 & restrict .omp_data_i)
{
@@ -34,13 +25,9 @@
[local count: 7128820]:
_104 = .G
Hi!
On 2022-04-12T15:45:03+0200, Richard Biener wrote:
> On Tue, 12 Apr 2022, Thomas Schwinge wrote:
>> On 2022-04-07T15:04:15+0200, Richard Biener via Gcc-patches
>> wrote:
>> > On Thu, 7 Apr 2022, Jan Hubicka wrote:
>> >> > On Thu, 7 Apr 2022, Jan Hu
ng) the attached
'Revert parts of "[Ada] Reduce runtime dependencies on stage1"', for the
reason detailed therein? Should the comment before 'GNAT1_C_OBJS' be
re-instated/adjusted, too? Would appreciate a careful review, as I don't
really know what I'm doing th
't assign explicit 'enum'
values, so probably there's indeed no reason for this one to be
different.
Grüße
Thomas
> --- a/include/plugin-api.h
> +++ b/include/plugin-api.h
> @@ -487,40 +487,40 @@ enum ld_plugin_level
>
> enum ld_plugin_tag
even with "static".
That's unexpected then, and should be looked into?
Still, should 'static' be removed here, too?
Grüße
Thomas
> The patch was tested on x86_64-linux with amdgcn offloading with no
> regressions.
> libgomp, OpenMP: Fix issue for omp_get_devic
_DIM_VECTOR]);
Same here.
> if (dims[GOMP_DIM_WORKER] != old_dims[GOMP_DIM_WORKER])
> warning_at (decl ? DECL_SOURCE_LOCATION (decl) : UNKNOWN_LOCATION, 0,
> - G_("using num_workers (%d), ignoring %d"),
> + G_("using % (%d), ignoring %d
for -Wformat-diag", see attached.
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ü
t it seems prudent to at least
catch it, and document via a few test cases. OK to push
"Catch 'GIMPLE_DEBUG' misbehavior in OpenACC 'kernels' decomposition
[PR100400, PR103836, PR104061]", see attached?
Grüße
Thomas
-
Siemens Electronic Design Automation
Hi Jakub!
Thanks for looking into this.
On 2022-01-20T00:00:23+0100, Jakub Jelinek wrote:
> On Wed, Jan 19, 2022 at 11:29:18PM +0100, Thomas Schwinge wrote:
>> (The pass is still disabled by default, by the way.)
>>
>> We've found that 'gcc/omp-oacc-kernels-de
g: Unused variable ‘n1’ declared at (1) [-Wunused-variable]
source-gcc/libgomp/testsuite/libgomp.fortran/allocate-1.f90:18:27:
18 | subroutine foo (x, p, q, px, h, fl)
| 1
Warning: Unused dummy argument ‘px’ at (1) [-Wunused-dummy-argument]
For r
Hi!
Pushed to master branch commit 087e545747ca9ee977e84326877b0ce1bc4c383a
"Strengthen a few OpenACC test cases", see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkt
Hi!
On 2022-01-24T12:54:27+, Hafiz Abid Qadeer wrote:
> On 24/01/2022 08:45, Tobias Burnus wrote:
>> On 21.01.22 18:15, Thomas Schwinge wrote:
>>> I'm seeing this test case randomly/non-deterministically FAIL to execute,
>>> differently on differe
Hi!
On 2021-09-17T01:01:39-0700, Andrew Pinski via Gcc-patches
wrote:
> On Fri, Sep 17, 2021 at 12:46 AM Thomas Schwinge
> wrote:
>> First, I appreciate you working through all these old PRs!
>>
>>
>> On 2021-09-15T13:56:37-0700, apinski--- via Gcc-patches
>&g
tresults from one more system, and I've filed
> <https://gcc.gnu.org/PR100678> "[OpenACC/nvptx]
> 'libgomp.oacc-c-c++-common/private-atomic-1.c' FAILs (differently) in
> certain configurations"... :-\
..., and that I also confirm to be resolved with
commit e0451f93
t in the PR104345 'libgomp.oacc-c-c++-common/reduction-cplx-dbl.c'
scenario.
> This patch has been tested on nvptx-none hosted on x86_64-pc-linux-gnu
> with a "make" and "make -k check" with no new failures. Unfortunately,
> the exact register usage of a nvptx k
g the
| same thing. A few examples.
|
| [...]
|
| ;-) Any so on, and so forth. Are there any generic recommendations,
| "best practice"?
The answer was:
| I don't know of any official documentation; in general we have tuned the
backend to the PTX that we generate, so following tha
Hi Tobias!
On 2022-01-24T09:45:48+0100, Tobias Burnus wrote:
> On 21.01.22 18:43, Tobias Burnus wrote:
>> On 21.01.22 18:15, Thomas Schwinge wrote:
>>> 11 | integer(c_int) function is_64bit_aligned (a) bind(C)
>>> Warning: Variable ‘a’ at (1) is a d
Hi!
On 2022-01-31T19:13:09+, Hafiz Abid Qadeer wrote:
> On 25/01/2022 10:32, Tobias Burnus wrote:
>> On 25.01.22 10:19, Thomas Schwinge wrote:
>>>> I am trying to figure out if the problem you observed
>>>> is a general one or just specific to fortran testcas
Hi Tobias!
On 2022-02-04T14:57:07+0100, Tobias Burnus wrote:
> On 04.02.22 10:37, Thomas Schwinge wrote:
>>> I have attached a patch (not commited), which silences the three kind of
>>> warnings and fixes the interface issue.
>>> TODO: commit it.
>> Still
current debugging task, but I've not yet run
'make check' in case anything needs to be adjusted there.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführe
Hi!
On 2022-02-10T16:36:51+, Michael Matz via Gcc-patches
wrote:
> On Thu, 10 Feb 2022, Richard Biener via Gcc-patches wrote:
>> On Wed, Feb 9, 2022 at 2:21 PM Thomas Schwinge
>> wrote:
>> > OK to push (now, or in next development stage 1?) the attached
lysis phase,
too? (This appears to work fine for OpenACC 'private' clauses (..., and
avoids marking a few as addressable/gang-private), and for those in
'gimple_bind_vars' it doesn't seem to make a difference (for the current
test cases and/or compiler transformations).)
And,
2
ld.u64 %r34,[%r33+32];
.loc 2 1317 6
setp.eq.u64 %r51,%r34,0;
@ %r51 bra $L6;
.loc 4 66 3
-membar.sys;
ld.u64 %r52,[%r33+24];
-st.u64 [%r34+80],%r52;
+membar.sys;
+atom.exch.b64 %r53,[%r34+80],%r52;
$L6:
[...]
(But I see there is another 'ld.u64
Hi Tom!
On 2022-02-15T11:52:29+0100, Tom de Vries wrote:
> On 2/15/22 08:34, Thomas Schwinge wrote:
>> For my understanding:
Thanks for your explanations!
>> It is expected that this changes, for example (similar elsewhere)
>> 'nvptx-none/libatomic/store_4_.o',
g/gomp/depend-5.f90 -O scan-tree-dump-times original
"#pragma omp task depend\\(depobj:aa\\[1\\]\\)" 1
PASS: gfortran.dg/gomp/depend-5.f90 -O scan-tree-dump-times original
"#pragma omp task depend\\(depobj:ss\\)" 1
PASS: gfortran.dg/gomp/depend-5.f90 -O (test for excess 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
Hi!
On 2022-02-11T08:02:20+0100, Richard Biener wrote:
> On Thu, Feb 10, 2022 at 11:20 PM Thomas Schwinge
> wrote:
>> On 2022-02-10T16:36:51+, Michael Matz via Gcc-patches
>> wrote:
>> > On Thu, 10 Feb 2022, Richard Biener via Gcc-patches wrote:
>> >>
middle end code. Once tested, OK to push the attached
"Add 'gcc/tree.cc:user_omp_clause_code_name' [PR65095]"?
Grüße
Thomas
> Also to be
> shared with Fortran.'
>
>> --- a/gcc/c-family/c-omp.c
>> +++ b/gcc/c-family/c-omp.c
>
>> +/* For OpenA
lelized code in gang-redundant mode, by
putting these parts into their own 'parallel' constructs, which then
default to 'num_gangs(1)'. Pushed to master branch
commit f8187b5c0d22723c8e0a3d13d0ea5dd7ecfeff75 "Fix OpenACC
gang-redundant execution in 'libgomp.oacc-fortran/
Hi!
On 2021-08-16T12:34:09+0200, I wrote:
> On 2021-08-06T09:49:58+0100, Julian Brown wrote:
>> On Wed, 4 Aug 2021 15:13:30 +0200
>> Thomas Schwinge wrote:
>>
>>> 'oacc_do_neutering' is the 'execute' function of the pass, so that
>>> me
ed something to avoid those (bug fix). Anyway: pushed to
master branch commit 54f745023276e5025e34b2cc22530c78423a93cb
"Get rid of 'gcc/omp-oacc-neuter-broadcast.cc:oacc_build_component_ref'",
see attached.
Grüße
Thomas
> On 2020-06-06T16:07:36+0100, Kwok Cheung Yeun
;
+@ ! uni trap;
+@ ! uni exit;
+}
mov.b64 {%r69,%r70},%r62;
shfl.idx.b32 %r69,%r69,%r68,31;
shfl.idx.b32 %r70,%r70,%r68,31;
[...]
So that's basically an 'assert' that all threads of a warp are converged.
(Is the JIT maybe even able to optimiz
gc=argc@entry=16, argv=0x1f1db40, argv@entry=0x7fffd5b8) at
[...]/source-gcc/gcc/toplev.cc:2312
#18 0x0174fe5f in main (argc=16, argv=0x7fffd5b8) at
[...]/source-gcc/gcc/main.cc:41
> currently testing attached
> fix.
Per the test results that I've got so far (but is still run
Hi!
Ping.
Grüße
Thomas
On 2021-11-15T15:50:58+0100, I wrote:
> Hi!
>
> ..., and here is another ping.
>
>
> Grüße
> Thomas
>
>
> On 2021-11-08T11:45:12+0100, I wrote:
>> Hi!
>>
>> Ping, once more.
>>
>>
>> Grüße
>> Th
example above, or whether the 'routine' shall just apply to 'foo'
but not 'bar', but without an error diagnostic?
OpenACC 3.2, 2.15.1 "Routine Directive" states that "the 'routine'
directive without a name may appear immediately before a f
everted (and commit f861ed8b29a5eb6164d1ddbcfbb6232dddae713f
"Use 'location_hash' for 'gcc/diagnostic-spec.h:nowarn_map'" as a
prerequisite, too).
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gese
Alternative approaches to 'gengtype' have been discussed more than once,
but...
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ür
kind);
>>> + OMP_CLAUSE_MAP_IMPLICIT_P (clause) = 1;
>>> if (DECL_SIZE (decl)
>>> && TREE_CODE (DECL_SIZE (decl)) != INTEGER_CST)
>>> {
>> Also as Thomas mentioned, it should be restricted to non-OpenACC,
> Agreed, I've adjust
Hi!
On 2021-07-30T15:58:36+0800, "Kewen.Lin" wrote:
> on 2021/7/30 下午3:18, Thomas Schwinge wrote:
>> Curious why in some instances we're not removing the 'class loop *loop'
>> declaration, I had a look, and this may suggest some further clean-up?
>
>
Hi!
On 2020-07-28T10:44:29+0200, I wrote:
> On 2020-07-26T14:05:32+0100, Kwok Cheung Yeung wrote:
>> On 24/07/2020 8:27 am, Thomas Schwinge wrote:
>>> [proposed patch] however completely defeats what we're intending to test
>>> here, which
>>> is t
from the acc
> routine call.
>
> I've applied this patch to gomp-4_0-branch.
... which I've now adapted (with several things to be fixed in follow-up
commits) and pushed to master branch in
commit 2b7dac2c0dcb087da9e4018943c023c0678234a3
"Make OpenACC orphan gan
and pushed
to master branch commit f1a58ab0db20c0862e8b5039bd448fc8c9799cac
"[OpenACC] Allow gang reductions inside serial constructs", see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschrä
Hi!
On 2020-07-20T12:26:48+0200, Frederik Harwath wrote:
> Thomas Schwinge writes:
>>> Can I include the patch in OG10?
> This has been delayed a bit by my vacation, but I have now committed
> the patch.
>> (Ideally, we'd also test 'serial' construct
ction on an orphan loop" checking',
see attached.
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 Gesells
_p = true;
> +
> + if (!gang_p)
> + this_mask = GOMP_DIM_MASK (GOMP_DIM_WORKER);
> + }
..., I don't understand what exactly that is meant to do: as far as I can
tell, we always get 'gang_p == true' from that code?
Instead, I've pushed to master
Hi!
I know I'm late this week ;-\ -- but here is another ping.
Grüße
Thomas
On 2021-11-22T11:27:49+0100, Thomas Schwinge wrote:
> Hi!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2021-11-15T15:50:58+0100, I wrote:
>> Hi!
>>
>> ..., and here i
Per my superficial review of the build log file, the
'[GCC 9.1]/bin/gdc' indeed is only used during stage 1 build, as it
should be. So that's good enough as far as I'm concerned, and unless
anyone sees any reason why such a mixed GCC 4.8/9.1 configuration would
be bad, may i
Hi!
OK to push the attached "testsuite: Be more informative for ICEs"?
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
e print_func
> argument of pretty_print.
OK to push the attached
"libstdc++: Address '-Wunused-function' for 'print_raw'",
or should this be addressed differently?
Grüße
Thomas
> When called by pretty_print the count is
> either a positive integer or -1, so
ssign
gimple_cond
-goto ; [50.00%]
+goto ; [100.00%]
else
-goto ; [50.00%]
+goto ; [0.00%]
[local count: 536870913]:
- gimple_call
- gimple_assign
+ gimple_assign
+ gimple_assign
[local count: 1073741824
libgomp.oacc-c-c++-common/kernels-loop-g.c:
> '-fcompare-debug' failure (length)
Right. I had filed <https://gcc.gnu.org/PR107231> "[13 Regression]
c-c++-common/goacc/kernels-loop-g.c: '-fcompare-debug' failure (length)"
with you in CC: . (Have you not rec
commit f36ce95ad928578aa6739f61480e6c8fbaf2248e
"Fix nvptx-specific '-foffload-options' syntax in
'libgomp.c/reverse-offload-sm30.c'", see attached.
Grüße
Thomas
> +
> +#pragma omp requires reverse_offload
> +
> +int
> +main ()
> +{
> + #
4699d91f5c61
"Tag 'gcc/gimple-expr.cc:mark_addressable_2' as 'static'", see attached.
Grüße
Thomas
> +void
> +flush_mark_addressable_queue ()
> +{
> + gcc_assert (!currently_expanding_to_rtl);
> + if (mark_addressable_queue)
> +{
> + m
; +case QImode:
Pushed to master branch commit 612de72b0d2904b5a5a2b487ce4cb907c768a947
"GCN: Restore build with GCC 4.8", see attached.
Cherry-picked pushed to devel/omp/gcc-12 branch in
commit 38e4f4f55a6823d028b8f5332c500b7267ad320b
"GCN: Restore build with GCC 4.8",
Hi!
On 2022-10-17T15:58:47+0200, Aldy Hernandez wrote:
> On Mon, Oct 17, 2022 at 9:44 AM Thomas Schwinge
> wrote:
>> On 2022-10-11T10:31:37+0200, Aldy Hernandez via Gcc-patches
>> wrote:
>> > When solving 0 = _15 & 1, we calculate _15 as:
>> >
&g
.[0-9]+' in 'private' clause";
everywhere else we have "declared in block".
As part of your verification, have you already looked into whether the
new behavior is correct here, or does this one need to continue to be
"adjusted for OpenACC privatization level: 'ga
ory). See
<https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration#Regenerating_All_GNU_Autotools_Files>.
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, Fra
gcn: Use FLAT addressing for all functions with pointer arguments
[PR105421]",
see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer:
"
... that addressed, I've now pushed to master branch
commit c7ebee2378426eeca425ca5406af213a926f154c
"Add 'libgomp.oacc-c-c++-common/private-big-1.c' [PR105421]", see
attached.
Grüße
Thomas
-
Siemens Electronic Design Automat
g/gcc/87v933nlhn@dem-tschwing-1.ger.mentorg.com/>
"GCC/OpenMP offloading for Intel GPUs?" -- but Intel don't seem
interested in working on that themselves?)
I'm proposing the attached "Remove support for Intel MIC offloading"
(generated with 'git format-
Hi!
On 2022-10-18T07:41:29+0200, Aldy Hernandez wrote:
> On Mon, Oct 17, 2022 at 4:47 PM Thomas Schwinge
> wrote:
>> On 2022-10-17T15:58:47+0200, Aldy Hernandez wrote:
>> > On Mon, Oct 17, 2022 at 9:44 AM Thomas Schwinge
>> > wrote:
>> >> On 2022-1
and now please let me crawl back under my stone, embarassing...
That'd rather be '(r & 2) || (r & 1)'.
Well, with that now clarified, how about the again updated
"Add 'gcc.dg/tree-ssa/pr107195-3.c' [PR107195]" attached?
Have I done something stupid again
7;`; do
>
>enable_offloading=1
>case "$tgt" in
> -*-intelmic-* | *-intelmicemul-*)
> - omp_device_property=omp-device-properties-i386
> - omp_device_property_tmake_file="${omp_device_property_tmake_file}
> \$(srcdir)/config/i386/t-omp-device"
&g
Hi!
On 2022-10-21T00:44:30+0200, Aldy Hernandez wrote:
> On Thu, Oct 20, 2022 at 9:22 PM Thomas Schwinge
> wrote:
>> "Add 'gcc.dg/tree-ssa/pr107195-3.c' [PR107195]" attached?
>
> I see 7 different tests in this patch. Did the 6 that pass, fail
>
#x27;libgomp.oacc-c-c++-common/nvptx-sese-1.c' SESE regions checking
[PR107195, PR107344]",
see attached.
That discussion I suppose is to be continued in
<https://gcc.gnu.org/PR107344> "GCC/nvptx SESE region optimization".
Grüße
Thomas
>> PR tree-optimizati
g this 'if (reverse_offload)' code path, which isn't
applicable to this test case (as far as I understand)? (Well, the answer
is 'bool reverse_offload = ptx_dev->rev_data != NULL;', but why is that?)
Grüße
Thomas
-
Siemens Electronic Design Autom
-- libgomp/plugin/plugin-nvptx.c
+++ libgomp/plugin/plugin-nvptx.c
@@ -546,6 +546,8 @@ nvptx_open_device (int n)
ptx_dev->omp_stacks.size = 0;
pthread_mutex_init (&ptx_dev->omp_stacks.lock, NULL);
+ ptx_dev->rev_data = NULL;
+
return ptx_dev;
301 - 400 of 5586 matches
Mail list logo
