>
>
> 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'/'parallel'/'task' constructs [PR99555]"?
As posted, I'
Hi!
On 2021-01-19T12:37:56+0100, Martin Jambor wrote:
> On Thu, Jan 14 2021, Thomas Schwinge wrote:
>> I'm raising here an issue with HSA libgomp plugin code changes from a
>> while ago. While HSA is now no longer relevant for GCC master branch,
>> the same code has
afce1be11a301c2421483736c634b8bf330e69, and cherry-picked into
> devel/omp/gcc-10 branch in commit
> c89b23b73edeeb7e3d8cbad278e505c2d6d770c4, see attached.
I'd pushed the wrong thing to devel/omp/gcc-10 branch, so I've now pushed
"Adjust 'libgomp.oacc-fortran/derivedtypes-arrays-1
On 2021-03-23 09:35, Jonathan Wakely wrote:
On 23/03/21 09:26 -0700, Thiago Macieira via Libstdc++ wrote: On
Tuesday, 23 March 2021 08:39:43 PDT Thomas Rodgers wrote: I will be
submitting a new patch for the
atomic.wait/barrier/latch/semaphore functionality a bit later today
that
subsumes
just
>> > on_device_arch.h that is #included in each test instead of additional
>> > sources? If we don't like inlining, just use noinline attribute, but I
>> > don't see why inlining would hurt.
>> > For Fortran, sure, we can't include it, so let'
(); //TODO Until resolved, skip, with error status.
Actually, we can do better: do try to execute this trivial OpenMP code
(expected to complete in no time), but for nvptx offloading "make sure
that we exit quickly, with error status", and XFAIL that. So that we'll
get XFAIL -&
* omp-expand.c (expand_oacc_collapse_init): Update condition in
> a gcc_assert.
> * testsuite/c-c++-common/goacc/collapse-2.c: New.
>
> libgomp/
> * testsuite/libgomp.oacc-c-c++-common/collapse-2.c: Add check
> for loop with GT/GE condition.
> * te
es
otherwise, we'll then adjust.
(I have not reviewed the PR90779 code changes; it was sufficient for my
case to understand what I called GCC's observed behavior.)
I've now pushed "Add 'libgomp.oacc-c-c++-common/static-variable-1.c'
[PR84991, PR84992, PR90779]" to master branch i
x27;parallel'/'task' constructs [PR99555]" to
>> master branch in commit d99111fd8e12deffdd9a965ce17e8a760d531ec3, see
>> attached. "... awaiting proper resolution, of course."
>
>> + if (on_device_arch_nvptx ())
>> +__builtin_abort (); //TODO
Hi!
On 2021-02-26T04:34:50-0800, Julian Brown wrote:
> This patch
Thanks, Julian, for your continued improving of these changes!
This has iterated through several conceptually different designs and
implementations, by several people, over the past several years.
It's now been made my task to f
Hi!
On 2021-04-16T17:05:24+0100, Andrew Stubbs wrote:
> On 15/04/2021 18:26, Thomas Schwinge wrote:
>>> and optimisation, since shared memory might be faster than
>>> the main memory on a GPU.
>>
>> Do we potentially have a problem that making more use of (s
(OPENACC_KERNELS_PARLOOPS)
> +-fopenacc-kernels=[decompose|parloops] Specify mode of OpenACC
> 'kernels' constructs handling.
>
> and
>
> On 13.11.20 23:22, Thomas Schwinge wrote:
>> Not yet enabled by default: for now, the current mode of OpenACC 'kernels&#
Hi!
On 2021-04-18T23:53:01+0100, Andrew Stubbs wrote:
> On 16/04/2021 18:30, Thomas Schwinge wrote:
>> On 2021-04-16T17:05:24+0100, Andrew Stubbs wrote:
>>> On 15/04/2021 18:26, Thomas Schwinge wrote:
>>>>> and optimisation, since shared memory might be faste
Hi!
On 2021-04-19T10:29:17+0200, Thomas Schwinge wrote:
> On 2020-11-15T09:14:32+0100, Tobias Burnus wrote:
>> regarding the new option:
>>
>> +fopenacc-kernels=
>> +C ObjC C++ ObjC++ RejectNegative Joined Enum(openacc_kernels)
>> Var(flag_openacc_kerne
From: Thomas Rodgers
This patch address jwakely's feedback from 2021-04-15.
This is a substantial rewrite of the atomic wait/notify (and timed wait
counterparts) implementation.
The previous __platform_wait looped on EINTR however this behavior is
not required by the standard.
On 2021-04-21 05:12, Jonathan Wakely wrote:
On 21/04/21 12:38 +0100, Jonathan Wakely wrote: On 20/04/21 22:12
-0700, Thomas Rodgers wrote: @@ -86,6 +88,24 @@
_GLIBCXX_BEGIN_NAMESPACE_VERSION
}
}
+_GLIBCXX_ALWAYS_INLINE bool
+_M_try_acquire() noexcept
+{
+ for
From: Thomas Rodgers
A change was made to __atomic_semaphore::_S_do_try_acquire() to
(ideally) let the compare_exchange reload the value of __old rather than
always reloading it twice. This causes _M_acquire to spin indefinitely
if the value of __old is already 0.
libstdc++/ChangeLog
On 2021-04-21 11:23, Jonathan Wakely wrote:
On 21/04/21 10:10 -0700, Thomas Rodgers wrote:
[...snip...]
Please commit your patch to trunk, since that's what you had in your
original patch before I asked you to change it (causing the bug).
We should do this for gcc-11 too if an RM app
From: Thomas Rodgers
NOTE - This patch also needs to be backported to gcc-11 in order for
semaphore release() to work correctly on non-futex platforms.
Tested sparc-sun-solaris2.11
For types that track whether or not there extant waiters (e.g.
semaphore) internally, the
On 2021-04-21 14:22, Jakub Jelinek wrote:
On Wed, Apr 21, 2021 at 07:23:30PM +0100, Jonathan Wakely via
Gcc-patches wrote:
We should do this for gcc-11 too if an RM approves it, since acquire()
is currently broken.
Ok, but please commit it soon, we'll need to do a RC2 tomorrow or on
Friday
On 2021-04-22 02:23, Jonathan Wakely wrote:
On 21/04/21 18:29 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
NOTE - This patch also needs to be backported to gcc-11 in order for
semaphore release() to work correctly on non-futex platforms.
Tested sparc-sun-solaris2.11
For types that
This is an 'interim' fix. For now it forces all waiting threads to wake
on _M_release(). This isn't exactly efficient but resolves the issue
in the immediate term.
libstdc++-v3/ChangeLog:
libstdc++/PR100806
* include/bits/semaphore_base.h (__atomic_semaphore::_M_release():
Same as previous version except removing the copyright notice from the
test.
libstdc++-v3/ChangeLog:
libstdc++/PR100806
* include/bits/semaphore_base.h (__atomic_semaphore::_M_release():
Force _M_release() to wake all waiting threads.
* testsuite/30_threads/semaphor
9s9l.fsf@euler.schwinge.homeip.net">http://mid.mail-archive.com/87sg1s9s9l.fsf@euler.schwinge.homeip.net>
(you were CCed).
> .../libgomp.oacc-c-c++-common/deep-copy-10.c | 14 +-
Please provide some detail about that one ("Fix async behaviour"). It's
not obvious
NT_INFINITY' value.
This might not be an actually observable bug (I have not verified, have
not tried to construct a test case), but should this be changed anyway?
(Back to 'tgt->refcount = 1'; not yet tested?)
Grüße
Thomas
signature.asc
Description: PGP signature
case of
> present_create_copy has also been adjusted in anticipation of a new
> version of the above-linked patch.
But please back out this one, for it's not related to this bug fix, and
we shall take care of that in a later patch. (No need for you to re-post
that one just for this.)
> Tested with offloading to nvptx. OK for trunk?
I'm see C++ compilation failures the new libgomp test cases; OK with
these resolved. To record the review effort, please include
"Reviewed-by: Thomas Schwinge " in the commit
log, see <https://gcc.gnu.org/wiki/Reviewed-by>.
Grüße
Thomas
signature.asc
Description: PGP signature
Tested x86_64-pc-linux-gnu, committed to trunk.
Jonathan Wakely writes:
> On 13/11/19 17:59 -0800, Thomas Rodgers wrote:
>>+/** @file include/stop_token
>>+ * This is a Standard C++ Library header.
>>+ */
>>+
>>+#ifndef _GLIBCXX_STOP_TOKEN
>>+#define _GL
Hi Tobias,
I think you need to add at least VOLATILE to this list
Yes, I'll do that.
Any other comments?
Regards
Thomas
"(?n)__attribute__\\(\\(oacc kernels parallelized, oacc
function \\(, , \\), oacc kernels, omp target entrypoint\\)\\)" 1
So, OK for trunk?
Regards
Thomas
2019-11-11 Thomas Koenig
PR fortran/67202
* dump-parse-tree.c (debug): Add for gfc
'?), and then (b) later on. As
always, doing the incremental thing, (a) first, then (b) later, would
give it more exposure in the wild, which should help to identify design
issues etc. now instead of much later, for example.
> Thoughts?
One very high-level item: you're using the very generic name "analyzer"
('-Wanalyzer', 'gcc/analyzer/' filenames, for example, or the '-fanalyze'
I just proposed). Might there be potential for confusion (now, or in the
future) what kind of analyzer that is, or is it safe to assume that in
context of a compiler, an analyzer is always a compile-time, static code
analyzer? After all, the existing run-time ones are known as "checkers":
'-fstack-check', or "sanitizers": '--fsanitize, or "verifiers":
'-fvtable-verify'.
Grüße
Thomas
.
Regards
Thomas
* include/pstl/glue_numeric_defs.h: Restore enable_if lost during
original
import of pstl.
* include/pstl/glue_numeric_impl.h: Likewise.
---
libstdc++-v3/include/pstl/glue_numeric_defs.h | 2 +-
libstdc++-v3/include/pstl/glue_numeric_impl.h | 2 +-
2 files changed, 2 ins
NTENT(IN) now, because an argument which
cannot be modified (even by passing to a procedure with a dummy argument
with unknown intent) is now also handled.
Regards
Thomas
.
Regards
Thomas
Am 20.11.19 um 23:18 schrieb Janne Blomqvist:
On Wed, Nov 20, 2019 at 11:35 PM Thomas König wrote:
Am 20.11.19 um 21:45 schrieb Janne Blomqvist:
BTW, since this is done for the purpose of optimization, have you done
testing on some suitable benchmark suite such as polyhedron, whether
it a
jump out of transfer_array_inner when the file
was at its end, was found by Harald; I just added a NULL pointer
check to make some regressions go away.
Regression-tested. OK for all affected branches (trunk, gcc 9 and
gcc 8)?
Regards
Thomas
Fix EOF handling for arrays.
2019-11-23 Thomas
Hi,
the PR is a gcc-9 only regression, for which I just committed a test
case to trunk.
We can then check what fixed this...
2019-11-23 Thomas Koenig
PR fortran/92442
* gfortran.dg/bounds_check_21.f90: New test.
! { dg-do compile }
! { dg-options "-Warray-bound
Actually, that was 92422. ChangeLog changed correspondingly.
Am 23.11.19 um 14:15 schrieb Thomas Koenig:
* gfortran.dg/eof_4.f90: New test.
This should be eof_6.f90 (and will be on commit).
Regards
Thomas
Here's an update to the previous patch.
Upon reflection, I think it is better for performance to have two
versions of the loop so the test is only performed when it is
needed.
So, OK for trunk?
Regards
Thomas
Fix EOF handling for arrays.
2019-11-23 Thomas Koenig
H
Hello world,
this patch fixes a 10 regression in dependency checking. The
approach is simple - if gfc_dep_resolver is handed references
with _data, remove that.
Regression-tested. OK for trunk?
Regards
Thomas
Do not look at _data component in gfc_dep_resolver.
2019-11-24 Thomas
x" variants, as I couldn't find a way to express the
'dg-*' directives in one combined file. I want to actually see the nvptx
XFAILs, so that we'll notice XPASSes once/if nvptx switches away from the
minimal libgfortran. (Changing that would be a separate discussion.)
Committ
float32_type_node) = DECIMAL32_TYPE_SIZE;
> + SET_TYPE_MODE (dfloat32_type_node, SDmode);
> + layout_type (dfloat32_type_node);
> + dfloat32_ptr_type_node = build_pointer_type (dfloat32_type_node);
>
> - dfloat64_type_node = make_node (REAL_TYPE);
> - TYPE_PRECISION (dfloat64_type_node) = DECIMAL64_TYPE_SIZE;
> - SET_TYPE_MODE (dfloat64_type_node, DDmode);
> - layout_type (dfloat64_type_node);
> - dfloat64_ptr_type_node = build_pointer_type (dfloat64_type_node);
> + dfloat64_type_node = make_node (REAL_TYPE);
> + TYPE_PRECISION (dfloat64_type_node) = DECIMAL64_TYPE_SIZE;
> + SET_TYPE_MODE (dfloat64_type_node, DDmode);
> + layout_type (dfloat64_type_node);
> + dfloat64_ptr_type_node = build_pointer_type (dfloat64_type_node);
>
> - dfloat128_type_node = make_node (REAL_TYPE);
> - TYPE_PRECISION (dfloat128_type_node) = DECIMAL128_TYPE_SIZE;
> - SET_TYPE_MODE (dfloat128_type_node, TDmode);
> - layout_type (dfloat128_type_node);
> - dfloat128_ptr_type_node = build_pointer_type (dfloat128_type_node);
> + dfloat128_type_node = make_node (REAL_TYPE);
> + TYPE_PRECISION (dfloat128_type_node) = DECIMAL128_TYPE_SIZE;
> + SET_TYPE_MODE (dfloat128_type_node, TDmode);
> + layout_type (dfloat128_type_node);
> + dfloat128_ptr_type_node = build_pointer_type (dfloat128_type_node);
> +}
>
>complex_integer_type_node = build_complex_type (integer_type_node, true);
>complex_float_type_node = build_complex_type (float_type_node, true);
Grüße
Thomas
signature.asc
Description: PGP signature
Hi!
So, testing just finished, and indeed:
On 2019-11-27T22:33:25+, Joseph Myers wrote:
> On Wed, 27 Nov 2019, Thomas Schwinge wrote:
>
>> If I turn that conditional cited above into 'if (1)', then nvptx
>> offloading testing seems to return to normality, bu
complex_integer_type_node = build_complex_type (integer_type_node, true);
>complex_float_type_node = build_complex_type (float_type_node, true);
(Maybe that's indeed better than my "hamfisted" patch.) ;-)
But it still reads a bit like a workaround (explicitly setting only
'dfloat*_ptr_type_node' here, leaving the actual 'dfloat*_type_node'
untouched (and then later on implicitly converted to 'error_mark_node' as
mentioned).
I guess we need somebody with more experience to review this.
Grüße
Thomas
signature.asc
Description: PGP signature
Hi Tobias!
On 2019-11-25T15:02:16+0100, Tobias Burnus wrote:
> sorry for the belated reply.
Eh, no worries -- I'm way more behind on things...
> On 11/11/19 10:39 AM, Thomas Schwinge wrote:
>> By the way, do you know what's the status is for Fortran common blocks in
&
f this:
> I could use no_create
... which basically means 'present' but don't complain if not actually
present.
> but that's not yet
> supported.
But will be soon. :-)
Grüße
Thomas
> --- a/libgomp/testsuite/libgomp.oacc-fortran/declare-5.f90
> +++ b/li
truct
a test case that will result in a 'NULL' pointer there, other than via
Fortran optional arguments? If not, then that hunk should be removed
here, and move into/stay in the Fortran optional arguments patch that
you've posted.
(And that said, Julian's got a patch pendin
Am 24.11.19 um 18:09 schrieb Thomas Koenig:
Hello world,
this patch fixes a 10 regression in dependency checking. The
approach is simple - if gfc_dep_resolver is handed references
with _data, remove that.
Regression-tested. OK for trunk?
Ping?
est_file_found } {
>
> set acc_mem_shared 0
> }
> + gcn {
> + set acc_mem_shared 0
> + }
> default {
> error "Unknown OpenACC device type: $openacc_device_type
> (offload target: $offload_target)&qu
nstructor would call some libgomp
> library function that in the end would when loading plugins ensure that
> only shared memory supporting plugins are loaded. If the gcn plugin
> will support shared memory only conditionally, we'll need some interfaces to
> ensure that.
(I have not yet completely digested the relevant OpenMP features.)
Grüße
Thomas
signature.asc
Description: PGP signature
s no 'acc_device_gcn' in OpenACC. Per OpenACC 3.0, A.1.2. "AMD
GPU Targets", for example, there is 'acc_device_radeon' (and "the
case-insensitive name 'radeon' for the environment variable
'ACC_DEVICE_TYPE'"). If that is not appropriate to use (I have not read
up how exactly AMD's "GCN" and "radeon" relate to each other), we should
get that clarified in the OpenACC specification.
Grüße
Thomas
signature.asc
Description: PGP signature
Hi Tobias!
On 2019-11-29T18:47:12+0100, Tobias Burnus wrote:
> On 11/28/19 6:02 PM, Thomas Schwinge wrote:
> [Test case which uses common blocks in device_resident.]
>> If you'd like to, please commit that, to document the status quo. (I
>> have not reviewed.)
>
Hi!
On 2019-12-02T14:50:42+, Julian Brown wrote:
> On Mon, 2 Dec 2019 15:43:29 +0100
> Thomas Schwinge wrote:
>
>> > --- a/libgomp/openacc.h
>> > +++ b/libgomp/openacc.h
>> > @@ -55,6 +55,7 @@ typedef enum acc_device_t {
>>
ourse; these will then go
into the 'acc_get_property' changes, don't need to re-post
'acc_get_property' because of that). To record the review effort, please
include "Reviewed-by: Thomas Schwinge " in the
commit log, see <https://gcc.gnu.org/wiki/Reviewed-by&g
Hi!
On 2019-12-03T12:56:49+, Andrew Stubbs wrote:
> On 02/12/2019 14:19, Thomas Schwinge wrote:
>> Generally, I'm in favor if you'd consider such a thing (that in principle
>> is just a copy/adapt of the existing cases) as obvious to commit (even
>> more so wit
Hi!
On 2019-12-03T13:13:33+, Andrew Stubbs wrote:
> On 02/12/2019 14:43, Thomas Schwinge wrote:
>> On 2019-11-12T13:29:13+, Andrew Stubbs wrote:
>>> --- a/include/gomp-constants.h
>>> +++ b/include/gomp-constants.h
>>> @@ -174,6 +174,7
Hi!
On 2019-12-03T14:20:13+, Julian Brown wrote:
> On Tue, 3 Dec 2019 10:32:57 +0100
> Thomas Schwinge wrote:
>> On 2019-12-02T14:50:42+, Julian Brown
>> wrote:
>> > On Mon, 2 Dec 2019 15:43:29 +0100
>> > Thomas Schwinge wrote:
>> >
that's not specific to the 'no_create' clause, just doesn't
cause any harm (given the existing testsuite...) for other OpenACC
constructs/clauses?
The incremental Fortran test case changes have bene done in a rush; not
sure if they make much sense, or should see some further work
)?
For avoidance of doubt:
> + case Name_Present:
> + map_kind = GOMP_MAP_FORCE_PRESENT;
> + case Name_Device_Ptr:
> + map_kind = GOMP_MAP_FORCE_DEVICEPTR;
... these remain correct to use 'FORCE' mapping kinds.
Grüße
Thomas
signature.asc
Description: PGP signature
n 'STARTFILE_SPEC', fix 'crt0.o' for '-mmainkernel'" to all
active GCC branches? (... instead of having to restore this "blunder"
(do "search for input files in '-L'directories") in nvptx-tools...)
Grüße
Thomas
-
Siemen
e GCC/Rust 'constexpr_ops_count' to
'HOST_WIDE_INT' (submitted <https://github.com/Rust-GCC/gccrs/pull/1666>
'Revert #1661 "58e75f65e56d: Remove HOST_WIDE_INT struct member"'), and
if anything needs to be changed, do thatt in GCC/C++ first, and then
mirror that into GCC/Rust.
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!
Ping.
Grüße
Thomas
On 2022-11-08T21:29:49+0100, I wrote:
> Hi!
>
> On 2017-06-09T16:24:30+0200, Tom de Vries wrote:
>> The patch defines an effective target stack_size, which is used in
>> individual test-cases to add -DSTACK_SIZE= [...]
>
>> gcci
o-[...]'
behavior -- or maybe warning flags are not passed to those at all, at
stage 1 build where this is (only) relevant.
I've thus proposed <https://github.com/Rust-GCC/gccrs/pull/1670>
"'rust-warn += -Wno-unused-parameter'".
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
ing changes to it.
I might thus be interested in joining that effort (I'm more interested in
the front end and GCC proper parts) -- but, again, this will be
low-priority project for me.
Grüße
Thomas
> Just a brief overview of my plans for the frontend and library-- When
> GCJ was fi
ss errors)
{+FAIL: gcc.dg/ipa/pr81520.c (internal compiler error: in
function_and_variable_visibility, at ipa-visibility.cc:647)+}
FAIL: gcc.dg/ipa/pr81520.c (test for excess errors)
Such ICEs we're not yet currently seeing elsewhere; this remains to be
analyzed -- after all, these test
Hi!
I'm proposing to re-enable a number of test cases for nvptx. OK to push?
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;
pr59417.c
b/gcc/testsuite/gcc.c-torture/compile/pr59417.c
index 891ba66718a4..227c5d841059 100644
--- a/gcc/testsuite/gcc.c-torture/compile/pr59417.c
+++ b/gcc/testsuite/gcc.c-torture/compile/pr59417.c
@@ -1,5 +1,4 @@
/* PR tree-optimization/59417 */
-/* { dg-skip-if "ptxas times out" { nvptx-*-* } { "-O1" "-O2" "-Os" } { "" } }
*/
int a, b, d;
short c;
--
2.35.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
raß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
xit (int);
--
2.35.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
rs or libraries other than what is considered essential.
-proc check_effective_target_freestanding { } {
-if { [istarget nvptx-*-*] } {
- return 1
-}
-return 0
-}
-
# Check to see that file I/O functions are available.
proc check_effective_target_fileio { } {
return [check_no_compiler_messages fileio_available executable {
--
2.35.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
orted to nvidia 2016-05-18. */
-/* { dg-skip-if "PTX assembler bug" { nvptx-*-* } { "-O0" } { "" } } */
-
struct xx
{
int a;
--
2.35.1
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit
4e9796f7826f..12262ebbe692 100644
--- a/gcc/testsuite/gcc.dg/torture/stackalign/struct-1.c
+++ b/gcc/testsuite/gcc.dg/torture/stackalign/struct-1.c
@@ -1,6 +1,5 @@
/* { dg-do run } */
/* { dg-skip-if "Stack alignment is too small" { hppa*-*-hpux* } } */
-/* { dg-skip-if "Stack alignment cau
bject file than the weak definition. */
-/* { dg-skip-if "" { "nvptx-*-*" } } */
-
#include
extern int foo(void);
--
2.35.1
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer
de "complex-sign.h"
--
2.35.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
tronic 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
; any
comments to those?)
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 the ear
gcc/config/mips/mips.h- { "subtarget_cpp_spec", SUBTARGET_CPP_SPEC },
\
--
gcc/config/mips/r3900.h-/* By default (if not mips-something-else) produce
code for the r3900 */
gcc/config/mips/r3900.h:#undef SUBTARGET_CC1_SPEC
gcc/c
Hi!
On 2022-12-07T07:04:10+0100, Sebastian Huber
wrote:
> On 06.12.22 22:06, Thomas Schwinge wrote:
> I suppose I just fail to see some detail here, but:
>
>> On 2022-11-21T08:25:25+0100, Sebastian
>> Huber wrote:
>>> gcc/ChangeLog:
>>>
>>>
;> +
>> +#endif // RUST_MAKE_UNIQUE_H
>
> I think this was added recently, see commit
> 00d7c8ff16e6838273cea808ffbe22e98104f9d5 and gcc/make-unique.h.
I too had seen that, but decided to wait for until after the GCC/Rust
merge, to not add more complexity to that one. It&
Hi Andrew!
On 2022-12-02T09:12:23-0500, Andrew MacLeod via Gcc-patches
wrote:
> This consists of 3 changes which stronger type checking has indicated
> are non-compliant with the type field.
I'm curious what that "stronger type checking" is?
Grüße
Thomas
> I doubt
f there is anything that I need to do to actually
generate the empty 'gcc/rust/ChangeLog' file.
(For avoidance of doubt: yes, only 'gcc/rust/' at this time.)
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Ge
aadf3, see attached.
> (For avoidance of doubt: yes, only 'gcc/rust/' at this time.)
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
ed to master branch commit 228d64af4e244faabab5c47506920a1bde85d74e
"Adjust 'gfortran.dg/goacc/privatization-1-*' [PR103576, PR103697]", see
attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit
Hi!
On 2021-12-13T14:12:26-0500, David Malcolm wrote:
> On Mon, 2021-12-13 at 10:53 -0700, Martin Sebor via Gcc-patches wrote:
>> On 12/10/21 3:42 PM, Thomas Schwinge wrote:
>> > OK to push the attached "testsuite: Be more informative for ICEs"?
>>
>> Add
ser.
In preparation for a forthcoming ICE fix, I've pushed to master branch
commit 862e5f398b7e0a62460e8bc3fe4045e9da6cbf3b
"Enhance OpenACC 'kernels' decomposition testing", see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 8063
I've pushed to master branch
commit 9b32c1669aad5459dd053424f9967011348add83
"OpenACC 'kernels' decomposition: Mark variables used in synthesized data
clauses as addressable [PR100280]", see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation G
ot; directives when translating asynchronous
> kernels regions instead.
(Or rather, use structured 'data' (as we're now doing), but with
appropriate 'async' clauses.)
> The attached patch just adds a "wait" operation before the end of
> the enclosing data reg
Hi!
Jakub, I'd still like your comment on the two "should we" questions cited
below.
On 2021-08-24T13:43:38+0200, Richard Biener via Gcc-patches
wrote:
> On Tue, Aug 24, 2021 at 12:23 PM Thomas Schwinge
> wrote:
>> On 2021-08-19T22:13:56+0200, I wrote:
>> >
Hi!
This has fallen out of (unfinished...) work earlier in the year: pushed
to master branch commit 4bd8b1e881f0c26a5103cd1919809b3d63b60ef2
"Document current '-Wuninitialized'/'-Wmaybe-uninitialized' diagnostics
for OpenACC test cases".
Grüße
Thomas
--
t; for OpenACC test cases".
..., and commit 2edbcaed95b8d8cbb05a6af486179db0da6e3245
"Document current '-Wuninitialized' diagnostics for
'libgomp.oacc-fortran/routine-10.f90' [PR102192]".
Grüße
Thomas
-
Siemens Electronic Design Automa
Hi!
On 2021-11-22T16:02:31+0100, Jakub Jelinek via Gcc-patches
wrote:
> On Mon, Nov 22, 2021 at 03:49:42PM +0100, Thomas Schwinge wrote:
>> Then, regarding the user-visible behavior:
>>
>> > +#pragma acc routine /* { dg-error "not immediately followed by a single
e Intel MIC offloading XFAILing for 'omp_get_device_num'", see
attached.
(It wasn't obvious to me how to implement that; very incomplete
"[WIP] Intel MIC 'omp_get_device_num'" attached, not planning on working
on this any further.)
Grüße
Thomas
-
Hi Martin!
On 2022-01-13T09:06:16-0700, Martin Sebor wrote:
> On 1/13/22 03:55, Thomas Schwinge wrote:
>> This has fallen out of (unfinished...) work earlier in the year: pushed
>> to master branch commit 4bd8b1e881f0c26a5103cd1919809b3d63b60ef2
>> "Document current
gfortran.dg/gomp/allocate-2.f90 -O (test for errors, line 40)
PASS: gfortran.dg/gomp/allocate-2.f90 -O (test for warnings, line 28)
PASS: gfortran.dg/gomp/allocate-2.f90 -O (test for warnings, line 32)
PASS: gfortran.dg/gomp/allocate-2.f90 -O (test for excess errors)
his should've unblocked your
"[wwwdocs] gcc-12/changes.html (GCN): >1 workers per gang"; see
<http://mid.mail-archive.com/87a6lhpwlq.fsf@euler.schwinge.homeip.net>.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 8
selected && { !
__OPTIMIZE__ } } } */
... I've now pushed to master branch in
commit fbb438808e9b53a6e6b179a5787d609443acaad6
"Test cases for references in OpenACC 'private' clauses", see attached.
Grüße
Thomas
-
Siemens Electronic Desi
8dc9950bcf0
"Extend test cases for references in OpenACC 'private' clauses",
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
71
print(f'Line should not start with space: "{line}"')
^
SyntaxError: invalid syntax
}
FAIL: check-MAINTAINERS.py
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Ans
mentation"
(still testing), 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ünche
1801 - 1900 of 5920 matches
Mail list logo
