SIGSEGV.
Second, it seems strange to examine only the first statement of inner
'GIMPLE_BIND' (via 'inner_sequence' being a 'typedef gimple *gimple_seq'),
so I changed that to examine all statements contained therein, which I
suppose must've been the intentio
Hi David!
On 2020-11-24T15:29:17-0500, David Edelsohn via Gcc-patches
wrote:
> On Tue, Nov 24, 2020 at 5:19 AM Thomas Schwinge
> wrote:
>> On 2020-11-21T10:50:10-0500, David Edelsohn wrote:
>> > I see
>> >
>> > "during GIMPLE pass: omplower"
Hi David!
On 2020-11-27T10:47:17-0500, David Edelsohn wrote:
> Actually, yes, AIX does allow dereference of a NULL pointer.
Oh. That's not what I expected! Heh.
Anyway, that then indeed completely explains what was going on here --
which is good. :-)
Grüße
Thomas
> On Fri, N
From: Thomas Rodgers
Adds __cpp_lib_atomic_wait feature test macro which was overlooked in
the initial commit of this feature. Replaces uses of
_GLIBCXX_HAVE_ATOMIC_WAIT.
libstdc++-v3/ChangeLog:
* include/bits/atomic_base.h: Replace usage of
_GLIBCXX_HAVE_ATOMIC_WAIT with
"Add 'gfortran.dg/goacc-gomp/omp-scan-1-if_present.f90'"?
Regarding my comment "As long as '!$omp scan' inside '!$acc host_data'
(generally, all constructs using 'if_present') reliably results in a
compile-time error, [...]": do we need a more
Hi!
On 2020-12-09T12:51:57+0100, Jakub Jelinek wrote:
> On Wed, Dec 09, 2020 at 12:36:26PM +0100, Thomas Schwinge wrote:
>> Yeah, that re-purposing of 'if_present' made me raise an eyebrow, too.
>
> I've missed yesterday that the if_present is on the EXEC_OMP_SCAN,
From: Thomas Rodgers
* Note: depends on a sufficiently C++20ified basic_stringbuf<>.
libstdc++/Changelog:
libstdc++-v3/include/Makefile.am (std_headers): Add new header.
libstdc++-v3/include/Makefile.in: Regenerate.
libstdc++-v3/include/std/streambuf
(__
From: Thomas Rodgers
This should address the cumulative comments (modulo the discussion going
on on the reflector about specification issues/questions).
libstdc++/Changelog:
libstdc++-v3/doc/doxygen/user.cfg.in (INPUT): Add new header.
libstdc++-v3/include/Makefile.am
From: Thomas Rodgers
libstdc++/Changelog:
libstdc++-v3/doc/doxygen/user.cfg.in (INPUT): Add new header.
libstdc++-v3/include/Makefile.am (std_headers): Add new header.
libstdc++-v3/include/Makefile.in: Regenerate.
libstdc++-v3/include/precompiled/stdc++.h: Include
> On Oct 21, 2020, at 10:34 AM, Jonathan Wakely wrote:
>
> On 21/10/20 09:53 -0700, Thomas Rodgers wrote:
>> From: Thomas Rodgers
>>
>> libstdc++/Changelog:
>> libstdc++-v3/doc/doxygen/user.cfg.in (INPUT): Add new header.
>> libstdc++-v3/inc
From: Thomas Rodgers
New ctors and ::view() accessor for -
* basic_stingbuf
* basic_istringstream
* basic_ostringstream
* basic_stringstreamm
New ::get_allocator() accessor for basic_stringbuf.
libstdc++-v3/ChangeLog:
* acinclude.m4 (glibcxx_SUBDIRS): Add src/c++20
From: Thomas Rodgers
Add support for -
* atomic_flag::wait/notify_one/notify_all
* atomic::wait/notify_one/notify_all
* counting_semaphore
* binary_semaphore
* latch
libstdc++-v3/ChangeLog:
* include/Makefile.am (bits_headers): Add new header.
* include/Makefile.in
From: Thomas Rodgers
Addresses latest patch feedback. Changes to also work on
single threaded configurations.
libstdc++/ChangeLog:
libstdc++-v3/doc/doxygen/user.cfg.in (INPUT): Add new header.
libstdc++-v3/include/Makefile.am (std_headers): Add new header.
libstdc++-v3
pushed to master branch commit
fa410314ec94c9df2ad270c1917adc51f9147c2c "[OpenACC] Elaborate testcases
that verify column location information [PR92793]", backported to
releases/gcc-10 branch in commit
fc423b4e5b16dc02cc9f91fdfc800d00a5103dea, see attached.
Grüße
Thomas
> Fixed
ith* column location information for C, C++, but the
very same diagnostics *without* column location information for Fortran.
Once I had some understood the Fortran front end locaiton processing --
uh... ;-\ -- I came up with the attached patch to "Further improve
Fortran column locat
line LaNE }
{
/* We're actually executing with num_gangs (1). */
gangs_actual = 1;
@@ -115,7 +115,7 @@ int main ()
workers_min = workers_max = acc_worker ();
vectors_min = vectors_max = acc_vector ();
}
-}
+}
{ dg-message "optimized: [...]" "" { target *-*-* }
line$line_count } */
/* { dg-message "note: [...]" "" { target *-*-* }
line$line_count } */
for (int i = 0; i < ni; ++i)
For each 'dg-l
Hi Jakub!
On 2020-10-30T12:40:02+0100, Jakub Jelinek wrote:
> On Fri, Oct 30, 2020 at 12:34:57PM +0100, Thomas Schwinge wrote:
>> On 2017-05-22T18:55:29+0200, Tom de Vries wrote:
>> > On 05/16/2017 03:12 PM, Rainer Orth wrote:
>> >> [...], but the new proc [&
Hi!
Frederik stumbled over a related thing.
On 2020-04-03T12:36:29+0200, Richard Biener wrote:
> On Fri, 3 Apr 2020, Thomas Schwinge wrote:
>> On 2020-04-02T11:12:48+0200, Richard Biener wrote:
>> > On Wed, 1 Apr 2020, Jason Merrill wrote:
>> >
>> >>
ot seeing this diagnostic.
In addition to the (presumedly unexpected) missing diagnostic for
'-fopenacc-dim=::128' mentioned above -- OK to simplify and enhance the
testcases as attached, "Simplify and enhance
'libgomp.oacc-c-c++-common/pr85486*.c' [PR85486]"?
Grüße
Thom
LL;
> + if (offload_region_p && has_vector_partitionable_routine_calls_p (decl))
> +{
> + if (dims[GOMP_DIM_VECTOR] > PTX_WARP_SIZE)
> + {
> + vector_reason = G_("using vector_length (%d) due to call to"
> + " vector
Hi!
On 2022-10-12T11:21:19+0200, Martin Liška wrote:
> On 10/10/22 16:19, Thomas Schwinge wrote:
>> attached
>> "Restore default 'sorry' 'TARGET_ASM_CONSTRUCTOR', 'TARGET_ASM_DESTRUCTOR'".
> Thanks for th
Hi!
On 2022-11-04T10:04:59+0100, wrote:
> On 2022-10-12T11:21:19+0200, Martin Liška wrote:
>> On 10/10/22 16:19, Thomas Schwinge wrote:
>>> attached
>>> "Restore default 'sorry' 'TARGET_ASM_CONSTRUCTOR', 'TARGET_ASM_DESTRUCTOR'"
ault_reloc_rw_mask (void);
extern bool default_generate_pic_addr_diff_vec (void);
+extern void default_asm_out_constructor (rtx, int);
+extern void default_asm_out_destructor (rtx, int);
extern tree default_mangle_decl_assembler_name (tree, tree);
extern tree default_emutls_
27;t these identifiers actually stay (so that any accidental future
use gets flagged, as I understand this machinery), and instead more
identifiers be added potentially: those where their definition/use got
removed with "STABS: remove -gstabs and -gxcoff functionality"? (I've
not che
x27;ve now pushed to master
branch commit e4cba49413ca429dc82f6aa2e88129ecb3fdd943
"Remove support for Intel MIC offloading", see attached (generated with
'git format-patch --irreversible-delete', 'xz -9').
Grüße
Thomas
>> --- a/gcc/config/i386/
recation.
Now, looking forward to the day when someone introduces support for (new)
Intel GPU offloading! (See initial/inconclusive discussion in thread at
<https://inbox.sourceware.org/gcc/87v933nlhn@dem-tschwing-1.ger.mentorg.com/>
"GCC/OpenMP offloading for Intel GPUs?".
Hi Jakub!
On 2022-11-04T11:30:04+0100, Jakub Jelinek wrote:
> On Fri, Nov 04, 2022 at 10:54:02AM +0100, Thomas Schwinge wrote:
>> On 2022-10-20T22:56:57+0200, I wrote:
>> > Hi Jakub, Tobias!
>> >
>> > On 2022-10-20T13:15:43+0200, I wrote:
>> >>
ex ctanhl(long double complex);
-long double complex cexpl(long double complex);
-long double complex cpowl(long double complex, long double complex);
-long double complex conjl(long double complex);
-long double complex cprojl(long double complex);
-#if __GNU_VISIBLE
+# if defined(__CYGWIN__)
long double complex clog10l(long double complex);
+# endif
#endif
-#endif /* __CYGWIN__ */
__END_DECLS
--
2.25.1
-
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
..
>
> 'stack_size'
> Target has limited stack size. [...]
On top of that, OK to push the attached
"nvptx: stack size limits are relevant for execution only"?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201
the testsuite given
> that it is not valid OpenMP, but perhaps it is ok as we are testing a QoI.
For non-offloading x86_64-pc-linux-gnu '-m32', I'm occasionally (but very
rarely!) seeing this test case FAIL its execution test. Similar can also
be seen on occasional reports via ,
memory
location, to signal end of processing for reverse offloads?
That is:
- enqueue 'cuLaunchKernel'
- enqueue 'cuStreamWriteValue' (to signal end of processing for reverse
offloads)
- loop on 'cuStreamWaitValue' (until end of processing for reverse offload
Hi Tobias!
On 2023-04-28T10:48:31+0200, Tobias Burnus wrote:
> On 21.03.23 16:53, Thomas Schwinge wrote:
>> On 2022-08-26T11:07:28+0200, Tobias Burnus
>> wrote:
>>> This patch adds initial [OpenMP reverse offload] support for nvptx.
>>> CUDA does lockup
them with '-fopenacc' instead of '-fopenmp'. ;-)
Chalk up one for the idea that I once had, to have '-fopenacc',
'-fopenmp', '-fopenmp-simd' enable '-Wunknown-pragmas' by default.
Grüße
Thomas
-----
Siemens Electronic D
gt; ! { -O2 -flto -fno-use-linker-plugin -flto-partition=none } \
> ! { -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects }
> ! ]
> ! } else {
> ! set LTO_TORTURE_OPTIONS [list \
> ! { -O2 -flto -flto-partition=none } \
> ! { -O2 -flto -f
Hi Julian!
On 2023-04-29T03:57:41-0700, Julian Brown wrote:
> This patch moves several tests introduced by the following patch:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616939.html
>
> into the proper location for OpenACC testing (thanks to Thomas for
> s
lude_flags' instead of
'libstdcxx_includes'"?
This does not adjust the 'libstdcxx_includes' usage in libitm and libvtv
testsuites -- maybe those should also get 'lang_include_flags' ported
(separately)?
Grüße
Thomas
-
Siemens Electronic De
s that libgomp for 'make -j' now does use the parallel testing code
paths, but is restricted to just one slot. That is, no actual change in
behavior, other than that 'libgomp.sum' then is filtered through
'contrib/dg-extract-results.sh'.
OK to push the attached
"Suppo
arallelize *all* compilation, while just allowing for *one*
| execution test job slot. That will require some GCC DejaGnu test
| harness hackery which I've [now] gotten to look into. That is, enable
| the usual GCC/DejaGnu parallel testing, but also have some kind of
| mutex for the execution
Hi Bernhard!
Thanks for your comments.
On 2023-05-06T16:15:45+0200, Bernhard Reutner-Fischer via Gcc-patches
wrote:
> On Fri, 5 May 2023 10:55:41 +0200
> Thomas Schwinge wrote:
>
>> >> > with a minimal change
>> >> > to libgomp.exp so the generated
Hi!
On 2023-04-14T13:49:20+0100, Gaius Mulley via Gcc-patches
wrote:
> Thomas Schwinge writes:
>> Separately, given that plain 'autoreconf' works, why have 'autogen.sh' at
>> all?
>
> If autoreconf does the same as autogen.sh then yes this can b
Hi!
Ping: OK to push to newlib main branch the attached
"For GCC, newlib combined tree, newlib build-tree testing, use standard search
paths"?
Or, has anybody got adverse comments/insight into this?
Grüße
Thomas
On 2023-04-14T22:03:28+0200, I wrote:
> Hi!
>
> OK to
Hi Christophe!
On 2023-05-09T09:32:55+0200, Christophe Lyon wrote:
> On Wed, 3 May 2023 at 13:47, Richard Biener via Gcc-patches
> wrote:
>> On Wed, 3 May 2023, Thomas Schwinge wrote:
>> > "Let each 'lto_init' determine the default 'L
Hi!
On 2014-11-04T10:31:37-0800, Mike Stump wrote:
> On Nov 4, 2014, at 4:13 AM, Thomas Schwinge wrote:
>> On Wed, 15 Oct 2014 17:46:48 +0200, I wrote:
>>> [...]
>>>
>>> Am I on the right track with the following?
>>
>> Nobody commented, whic
Hi!
On 2023-05-09T14:36:53+0200, I wrote:
> On 2014-11-04T10:31:37-0800, Mike Stump wrote:
>> On Nov 4, 2014, at 4:13 AM, Thomas Schwinge wrote:
>>> On Wed, 15 Oct 2014 17:46:48 +0200, I wrote:
>>>> [...]
>>>>
>>>> Am I on the right track wi
Hi!
On 2023-05-09T14:39:53+0200, I wrote:
> On 2023-05-09T14:36:53+0200, I wrote:
>> On 2014-11-04T10:31:37-0800, Mike Stump wrote:
>>> On Nov 4, 2014, at 4:13 AM, Thomas Schwinge wrote:
>>>> On Wed, 15 Oct 2014 17:46:48 +0200, I wrote:
>>>>> [...]
#x27;s a new patch, loosely based on/extracted out of my earlier
work. I'm posting it separately, but given that it's in line with my
earlier work (just a separate step), I intend to push it soon, unless
there are any objections, of course.)
Grüße
Thomas
-
Siemens Electro
my earlier work. This is
to enable follow-on clean-up.
> given that it's in line with my
> earlier work (just a separate step), I intend to push it soon, unless
> there are any objections, of course.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Ans
gnore-all-space'
variant, for easier review.
>> given that it's in line with my
>> earlier work (just a separate step), I intend to push it soon, unless
>> there are any objections, of course.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH;
*/
> + abort ();
> +}
> }
That has put "the PR85463 stuff" into the one central place, and allows
for simplifying GCC as per the attached
'Clean up after newlib "nvptx: In offloading execution, map '_exit' to 'abort&
ck' fit for non-full-warp execution"?
For now pushed, still with TODO markers, to devel/omp/gcc-12 branch in
commit d26a2a299392af330b3576b62d4eb6c81820be29
"nvptx: Make 'nvptx_uniform_warp_check' fit for non-full-warp execution",
see attached.
Grüße
Thomas
--
Hi!
On 2022-12-19T21:40:06+0100, Thomas Schwinge wrote:
> ... to document the status quo re implicit (via 'need_softstack_decl',
> 'need_unisimt_decl') and explicit declarations of '__nvptx_stacks',
> '__nvptx_uni'.
Fo
Hi!
On 2022-12-19T21:40:07+0100, Thomas Schwinge wrote:
> As I have reported to Nvidia in 2022-12-01 'NVIDIA Incident Report (3891704):
> ptxas: Duplicate declaration error: "cannot be resolved by a '.static'"',
> 'ptxas' has an inscrutable err
",
see attached.
> Per my quick scanning of 'gcc/config.gcc' history, for more than two
> decades, there was a clear trend to remove 'use_collect2=yes'
> configurations; now finally a new one is being added -- making sure we're
> not slowly dispensing with the need for
yes'
>> configurations; now finally a new one is being added -- making sure we're
>> not slowly dispensing with the need for the early 1990s piece of work
>> that 'gcc/collect2*' is... ;'-P
>
> (I still find that "notable" and "funny&
nfig/nvptx/oacc-parallel.c', and observing them be executed),
> and also in my WIP development tree with standard libgfortran
> constructors (with 'LIBGFOR_MINIMAL' disabled).
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraß
ation", see
attached. This I've just pushed to devel/omp/gcc-12 branch in
commit 26d3146736218ccfdaba4da1edf969bc190d, and would like to push
to master branch once other pending GCC patches have been accepted.
Grüße
Thomas
-
Siemens Electronic Design Automation Gmb
-Wframe-malloc-threshold'"
experimenting. (The latter works to some extent, but also has other
issues that I shall detail at some later point in time.)
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellscha
7;s not that easy. ;-) Pushed to devel/omp/gcc-12 branch
commit d90a8a5685c8bd3657892feac01739fe87a457a5
"Make 'libgcc/config/nvptx/crt0.c' build '--without-headers'", see
attached. Please consider that one 'fixup'ed into the GCC master branch
submission.
Grüße
Thomas
ote from Tobias to "update the the last but one bullet point at
https://gcc.gnu.org/onlinedocs/libgomp/nvptx.html";. Thus pushed to
devel/omp/gcc-12 branch commit 8c29332e98ca4669a059ebc0d90903b409ae049f
"Update 'libgomp/libgomp.texi' for 'nvptx, libgfortran: Switch ou
at that, please also adjust:
> --- /dev/null
> +++ b/gcc/config/i386/gnu64.h
> @@ -0,0 +1,40 @@
> +/* Configuration for an x86_64 running GNU with ELF as the target machine.
> */
> +
> +/*
> +Copyright (C) 2022 Free Software Foundation, Inc.
^ 2023 ;-)
Grüße
Thomas
--
rg/gcc-patches/20230128132353.77631-1-i...@sandoe.co.uk>,
which remains necessary for:
'gm2/warnings/returntype/pass/Termbase.mod',
'gm2/warnings/returntype/pass/goodreturn.mod',
'gm2/warnings/returntype/pass/keypressedsimple.mod'.
Grüße
Thomas
> 2023-01-30 Rainer Or
for x86_64-*-gnu-* targets to build x86_64 gnumach/hurd",
see attached.
I'll watch how x86_64 GNU/Hurd develops! :-)
Grüße
Thomas
> On Fri, Jan 27, 2023 at 4:16 PM Thomas Schwinge
> wrote:
>
>> Hi Flavio!
>>
>> Sorry to bother you one last time (hopef
+}
However, this misses compiler libraries (such as libgcc, which libstdc++
may depend on). For example, I see my x86_64-pc-linux-gnu '-m32' testing
not pick up the build-tree libgcc, but instead some random system one,
which (expectedly) doesn't satisfy requirements of other build-
or "'var2' in 'allocate'
directive at .1. is not present in associated 'allocate' statement." }
OK to push to devel/omp/gcc-12 branch the attached
"Fix 'omp_allocator_handle_kind' example in 'gfortran.dg/gomp/allocate-4.f90'&quo
Hi!
On 2023-02-01T16:12:07+0100, Martin Jambor wrote:
> On Thu, Oct 20 2022, Richard Biener via Gcc-patches wrote:
>>> Am 20.10.2022 um 14:41 schrieb Jakub Jelinek via Gcc-patches
>>> :
>>> On Thu, Oct 20, 2022 at 12:33:28PM +, Michael Matz wrote:
>>>
e-offload-6.f90' nvptx offloading compilation",
see attached.
Grüße
Thomas
> I improved the wording in the commit comment a bit, compared to previous
> attachment and I have verified that those features work with AMDGCN* and
> without offloading.
>
> Tobias
>
>
^
cc1: all warnings being treated as errors
make[9]: *** [target.lo] Error 1
make[9]: Leaving directory `[...]/build-gcc/x86_64-pc-linux-gnu/32/libgomp'
[...]
I suppose you'd do similar to what you already have a few lines above;
2022 at 12:33:28PM +, Michael Matz wrote:
>>>>>> On Thu, 20 Oct 2022, Thomas Schwinge wrote:
>>>>>> This had been done in
>>>>>> wwwdocs commit 5c7ecfb5627e412a3d142d8dc212f4cd39b3b73f
>>>>>> "Document deprecation o
bd75ebf9b9d0150
"'c-c++-common/gomp/alloc-pinned-1.c' ->
'libgomp.c-c++-common/alloc-pinned-1.c'",
see attached.
Note that this likewise applies to the current upstream submission:
"openmp: -foffload-memory=pinned".
Grüße
Thomas
-
Si
vel/omp/gcc-12 branch
commit 6e0ba07ff1859bc822c7220bfff18e7e9a147206
"'{c-c++-common,gfortran.dg}/gomp/uses_allocators-*' ->
'libgomp.{c-c++-common,fortran}/uses_allocators-*'",
see attached.
Grüße
Thomas
-
Siemens Electronic Design Automa
0' -> 'libgomp.fortran/allocate-5.f90'",
see attached.
Note that this likewise applies to the current upstream submission:
<https://inbox.sourceware.org/gcc-patches/c00649080f9127a0eeabb45536a2846ffc4c3fa7.1657188329.git@codesourcery.com>
"Add parsing suppo
to contrib/config-list.mk".
Grüße
Thomas
> contrib/config-list.mk | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/config-list.mk b/contrib/config-list.mk
> index 20b8f4a196f..661b11c9bbd 100644
> --- a/contrib/config-list.mk
> +++ b/cont
#x27;, clarify i686-symbolics-gnu to i686-gnu".
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
; *device,
>DLSYM (unload_image);
>DLSYM (alloc);
>DLSYM (free);
> + DLSYM_OPT (usm_alloc, usm_alloc);
> + DLSYM_OPT (usm_free, usm_free);
> + DLSYM_OPT (is_usm_ptr, is_usm_ptr);
>DLSYM (dev2host);
>DLSYM (host2dev);
As a sanity check, shouldn't w
a but will not fail with 'ENOMEM' if the area cannot be populated.
What exactly is that supposed to tell us: "will make a best effort [...]
but will not fail"? Isn't that in conflict with the earlier statement?
So can we rely on 'mremap' together with '
(SPF_Id : Entity_Id) return Boolean;
..., which got added in commit
r11-5477-g23e3e22105723fde2a9161757611544f180ba805
"[Ada] Implement AI12-0187 (Stable properties of abstract data types)".
So, what is actually the prerequisite GCC/Ada compiler version to be able
to b
Hi!
Ping.
Grüße
Thomas
On 2022-05-13T14:29:01+0200, I wrote:
> Hi!
>
> On 2022-04-29T15:48:03+0200, I wrote:
>> On 2022-04-06T11:57:57+0200, Tom de Vries wrote:
>>> On 4/5/22 17:14, Thomas Schwinge wrote:
>>>> Regarding [...]
>
>>>> No
efine HAVE_GAS_ARM_EXTENDED_ARCH 1" >>confdefs.h
> -
> -fi
> -
> esac
> --- a/gcc/configure.ac
> +++ b/gcc/configure.ac
> case "$target" in
>amdgcn-* | gcn-*)
> [...]
> ;;
> - arm*)
> -gcc_GAS_CHECK_FEATURE([assembler for ar
entorEmbedded/nvptx-tools/pull/37>
"Put '-v' verbose output onto stderr instead of stdout")?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführ
it available to you in another way?
Note that I'm really just relaying information here, but other than
general interest, I'm myself not too familiar with the details of Static
Analysis. Just thought that you would appreciate hearing about GCC's
Static Analyzer "spotted in the wil
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
>> attached "nvptx: forward '-v' command-line option to assembler, linker"?
&
veryone i will reach out to overseers about the
> Mailing List idea.
A mailing list has thus been set up a year ago;
now documented on <https://gcc.gnu.org/lists.html> per gcc-wwwdocs
commit 1c89cdccbebda5d4c2eeeb627b1461b8877bb27e
"Document mailing list", see attached.
Grüße
Thomas
t up GCC Bugzilla:
- Add new component *rust*:
<https://gcc.gnu.org/bugzilla/editcomponents.cgi?action=edit&product=gcc&component=rust>.
- Add new version *rust/master*:
<https://gcc.gnu.org/bugzilla/editversions.cgi?action=edit&product=gcc&version=rust%2Fmaster>
f0a9fe11544326dabd743b7aa6b54223>:
"Page-locks the memory range specified [...] and maps it for the
device(s) [...]. This memory range also is added to the same tracking
mechanism as cuMemHostAlloc to automatically accelerate [...]"? (No
manual 'mlock'ing involved in that case, to
gins (offloading), might move 'DL_LIBS',
'PLUGIN_SUPPORT' from 'libgomp/plugin/configfrag.ac' into
'libgomp/configure.ac', and 'libgomp_la_LIBADD += $(DL_LIBS)' from
'libgomp/plugin/Makefrag.am' into 'libgomp/Makefile.am'.
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
;, and (c) sets up a '-march-map' -> '-march' alias for backwards
compatibility (if so desired)? Regarding (a), (b), in my opinion,
there's no backwards compatibility issue there: the "new '-march'" will
simply accept more options than the "old
loc (c_sizeof (q), d)
16 if (.not. c_associated (p)) &
17 stop 0 ! okay
18
19 if (omp_target_associate_ptr (c_loc (q), p, c_sizeof (q), &
20 0_c_size_t, d) == 0) then
21
22 if(c_associated (omp_get_mapped_ptr (
Hi Jakub!
On 2022-06-15T10:46:30+0200, Jakub Jelinek wrote:
> On Tue, Jun 14, 2022 at 06:41:37PM +0200, Thomas Schwinge wrote:
>> On 2022-06-13T14:06:39+0200, Jakub Jelinek via Gcc-patches
>> wrote:
>> > OpenMP 5.2 changed once more what device numbers are
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+, "vries at gcc dot gnu.org via Gcc-bugs"
>>> wrote:
>>>> I&#x
admit I don't have much experience with debugging
> NVPTX offloaded code...
Any luck?
Until this gets resolved properly, OK to push something like the attached
(currently testing) "Avoid OpenMP/nvptx execution-time hangs for simple
nested OpenMP 'target&#x
c.: it needs to also be passed to 'walk_gimple_seq_mod' calls triggered
from inside 'walk_gimple_stmt'. Hence, I've put it into the state
'struct walk_stmt_info'.
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registe
Hi!
On 2021-03-17T08:54:15+0100, Richard Biener wrote:
> On Wed, Mar 17, 2021 at 12:35 AM Thomas Schwinge
> wrote:
>> On 2021-03-17T00:24:55+0100, I wrote:
>> > Now, walking each function backwards (!), [...]
>>
>> > I've now got a simple &#
Hi Jakub!
On 2021-03-04T09:52:41+0100, Jakub Jelinek via Gcc-patches
wrote:
> On Thu, Jan 14, 2021 at 07:18:13PM +0100, Thomas Schwinge wrote:
>> libgomp/
>> PR libgomp/65099
>> * plugin/configfrag.ac (PLUGIN_NVPTX): Restrict to supported
>> con
DA
> 11.0+?
>
> I don't think losing sm_30 support is a major concern: support for sm_35
> has been introduced with PTX ISA 3.1, CUDA 5.0, driver r302.
Grüße
Thomas
> Further:
> After quite some digression to first add a testsuite to nvptx-tools (see
> <https://t
On 2021-03-22 08:29, Thiago Macieira via Libstdc++ wrote:
Discussion at:
https://gcc.gnu.org/pipermail/libstdc++/2021-February/052043.html
This patch set includes the uncontroversial parts that improve
performance but don't otherwise change ABI.
Please note we still need to decide on how to de
From: Thomas Rodgers
* This patch addresses jwakely's previous feedback.
* This patch also subsumes thiago.macie...@intel.com 's 'Uncontroversial
improvements to C++20 wait-related implementation'.
* This patch also changes the atomic semaphore implementation to avoi
ors are emitted
> by the ME.)
This later got cherry-picked into devel/omp/gcc-10 branch, with FAILing
testcase 'gfortran.dg/gomp/order-4.f90'. I've now pushed "Adjust
'gfortran.dg/gomp/order-4.f90' for og10" to devel/omp/gcc-10 branch in
commit b0e5c3b84ef2c
uires directive: adjust libgomp HSA plugin"
to devel/omp/gcc-10 branch in commit
4ef4921cb10693c59b488002179db131683af8bc, see attached. (The libgomp HSA
plugin has been removed in master branch, so not applicable there.)
Grüße
Thomas
> 2021-01-13 Chung-Lin Tang
>
>
> +[...]
I've pushed "'libgomp.oacc-fortran/derivedtypes-arrays-1.f90' OpenACC
'serial' construct diagnostic for nvptx offloading" to master branch in
commit 8bafce1be11a301c2421483736c634b8bf330e69, and cherry-picked into
devel/omp/gcc-10 branch in commit
c89b23b73ede
1701 - 1800 of 5833 matches
Mail list logo
