c' configuration, again", see attached.
Thanks for the report, Tobias!
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,
Hi!
Pushed to master branch commit fe0f9e09413047484441468b05288412760d8a09
"Add 'libgomp.c-c++-common/pr100059-1.c'" (omitting PR100059 tag
unfortunately), see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße
in addition to a register. I suppose that only allowing
for the second input operand to be an immediate is sufficient/desirable:
reduces load on the matching; we shouldn't ever end up with 'IMM + IMM',
for example: should've optimized that before. As I learn from
<https://gcc.gnu.org/onl
e prefixed, I think I'll go with the current
'append function_regexp "\t" $line "\n"', that is, prefix expected output
lines with '\t' (as done in 'gcc.target/nvptx/abort.c'), and also for
nvptx handle labels as "fluff" (until we solve
gt;
>https://gcc.gnu.org/wiki/cauldron2023
Pushed to wwwdocs commit 24127b05c065c0fd24c996f5b27829bfa37de485
"GNU Tools Cauldron 2023", see attached.
See you in less than three weeks!
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 20
c check-function-bodies { args } {
>
> set count 0
> set function_regexp ""
> -set label {^(\S+):$}
> +#TODO
> +set label {^// BEGIN GLOBAL FUNCTION DEF: ([a-zA-Z_]\S+)$}
There's actually no reason that the expected output syntax (this one
ode);
> --- gcc/varasm.cc.jj 2023-08-08 15:54:35.517598423 +0200
> +++ gcc/varasm.cc 2023-08-08 16:12:02.330939784 +0200
> @@ -5281,6 +5281,61 @@ output_constant (tree exp, unsigned HOST
> + struct bitint_info info;
> + tree type = TREE_TYPE (exp);
> + gcc_assert (targetm.
T_DEF' -> 'if (TARGET_SUPPORTS_ALIASES)' etc.".
OK to push?
These changes are necessary to cure nvptx regressions raised in
<https://inbox.sourceware.org/87iliurqt1@euler.schwinge.homeip.net>
"[nvptx] Use .alias directive for mptx >= 6.3", addressing
Hi!
GCC/C++ front end maintainers, please provide input on the overall
approach here:
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
ume(++y == 43)));
return x + y;
@}
@end smallexample
@code{y} is not actually incremented and the compiler can but does not
have to optimize it to just @code{return 42 + 42;}.
(I've not actually verified that'd do the job here, but I'd be very
surprised if not.)
+
> +#define N 256
> +
> +#pragma omp begin declare target indirect
> +int foo(void) { return 5; }
> +int bar(void) { return 8; }
> +int baz(void) { return 11; }
> +#pragma omp end declare target
> +
> +int main (void)
> +{
> + int i, x = 0, expected = 0;
> + int (*fn_ptr[N])(void);
> +
> + for (i = 0; i < N; i++)
> +{
> + switch (i % 3)
> + {
> + case 0: fn_ptr[i] = &foo;
> + case 1: fn_ptr[i] = &bar;
> + case 2: fn_ptr[i] = &baz;
> + }
> + expected += (*fn_ptr[i]) ();
> +}
> +
> +#pragma omp target teams distribute parallel for reduction(+: x) \
> + map (to: fn_ptr) map (tofrom: x)
> + for (int i = 0; i < N; i++)
> +x += (*fn_ptr[i]) ();
> +
> + return x - expected;
> +}
[...]/libgomp.c-c++-common/declare-target-indirect-2.c: In function ‘main’:
[...]/libgomp.c-c++-common/declare-target-indirect-2.c:20:27: warning: this
statement may fall through [-Wimplicit-fallthrough=]
20 | case 0: fn_ptr[i] = &foo;
| ~~^~
[...]/libgomp.c-c++-common/declare-target-indirect-2.c:21:9: note: here
21 | case 1: fn_ptr[i] = &bar;
| ^~~~
[...]/libgomp.c-c++-common/declare-target-indirect-2.c:21:27: warning: this
statement may fall through [-Wimplicit-fallthrough=]
21 | case 1: fn_ptr[i] = &bar;
| ~~^~
[...]/libgomp.c-c++-common/declare-target-indirect-2.c:22:9: note: here
22 | case 2: fn_ptr[i] = &baz;
| ^~~~
..., so I suppose that's effectively testing 'fn_ptr[i] = &baz;' only for
all 'i's?
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
stsuite/gcc.dg/vect/vect-cond-reduc-4.c:19:21: note:
vect_is_simple_use: vectype vector(64) int
[...]/source-gcc/gcc/testsuite/gcc.dg/vect/vect-cond-reduc-4.c:19:21:
missed: optimizing condition reduction with FOLD_EXTRACT_LAST.
vect_model_reduction_cost: inside_cost = 0, prologue_c
FAIL: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "&a" 1
PASS: gcc.dg/tree-ssa/scev-5.c (test for excess errors)
[-FAIL:-]{+XFAIL:+} gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts
"&a" 1
Grüße
Thomas
> The transformation is not consider
Hi!
On 2023-11-09T17:00:11+0100, Tobias Burnus wrote:
> On 09.11.23 13:24, Thomas Schwinge wrote:
>> Also, assuming that the order of appearance of 'IND_FUNC_MAP' does matter
>> as it does for 'FUNC_MAP', ...
>> https://github.com/MentorEmbedded/nvp
That's in order to
observe effects of a later patch, and also to exercise the new nvptx
'check-function-bodies' a bit.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung
9b3a242121eef8a532f5224c00c471b56
"Update nvptx's bitrev2 pattern to use BITREVERSE rtx.", 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: Thom
Fix copy'n'paste-o in '__builtin_nvptx_brev' description", see
attached.
> +@enddefbuiltin
> +
> +@defbuiltin{unsigned long long __builtin_nvptx_brevll (unsigned long long
> @var{x})}
> +Reverse the bit order of a 64-bit unsigned inte
h_--srcdir=[...]/source-gcc/fixincludes=no: No such file
or directory
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... nvptx-unknown-none
[...]
I'm not convinced that's achieving what it means t
est
[...]
error : Prototype doesn't match for 'main' [...]
I'll add handling for this case in (I suppose)
'gcc/config/nvptx/nvptx.cc:write_fn_proto_1' if that indeed is a
conforming declaration of 'main', but is it really?
Grüße
Thomas
above. It was regtested on x86_64-apple-darwin21.
>
> Thomas, can you confirm that it also fixes things for you? Although I don’t
> see why it wouldn’t.
> Subject: [PATCH] libsanitizer: fix build on darwin
EATTACHEDWRONGPATCH? ;-)
Grüße
Thomas
-
Siemens Electronic Design
[check_effective_target_libatomic_available] {
> set maybe_atomic_lib ""
> }
>set t [get_multilibs]
> - puts "dg set al $maybe_atomic_lib ml $t"
> }
Likewise.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Ansc
the test case to verify any additional
features you think are userful to be tested there.)
(With '-fno-threadsafe-statics', this fails, as expected.)
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaf
static local variable, I assume this is intended to work "as expected"?
On the other hand, NVHPC nvc++ 23.1-0 fails, too:
NVC++-S-1062-Support procedure called within a compute region -
__cxa_guard_acquire (r.cc: 16)
[local to r_cc]::f():
16, Accelerator restriction: unsupported
//gcc.gnu.org/ml/gcc-testresults/current";>gcc-testresults
Grüße
Thomas
> htdocs/gcc-10/buildstat.html | 27 ---
> htdocs/gcc-10/index.html | 3 ---
> htdocs/gcc-11/buildstat.html | 27 ---
&g
t;News";
pushed commit 1825b255beb7d7edca775c401222ad2cb41ea193
"GCC developer room at FOSDEM 2024: Call for Participation open"
to wwwdocs master branch, see attached.
Grüße
Thomas
> https://fosdem.org/2024/
>
> This email is a Call for Presentations about GCC for the developer
> room.
>
> Imp
411eca498beb13729cc2acec77e68250940aa81
>> "Rust: Don't depend on unused 'target-libffi', 'target-libbacktrace'".)
>
> ... that change is necessary, too.
That's still unchanged in the GCC/Rust libgrust-v2/to-submit branch;
please apply to 'gcc/
ttached "Fix 'gcc.dg/tree-ssa/return-value-range-1.c'"? (..., or did
you intend something else, here?)
Grüße
Thomas
> +__attribute__ ((__noinline__))
> +int a(char c)
> +{
> + return c;
> +}
> +void link_error ();
> +
> +void
> +test(int d)
&g
defaulting to
'unsigned'", see attached. On powerpc64le-linux-gnu ('char' defaulting
to 'unsigned') I still saw:
/tmp/ccd1xwD7.o: In function `test':
return-value-range-1.c:(.text+0x50): undefined reference to `link_error'
Grüße
Thomas
> @
" } */
>> > +/* { dg-options "-O2 -fdump-ipa-profile -fno-ipa-vrp" } */
>> > --- a/gcc/testsuite/gcc.dg/tree-prof/time-profiler-2.c
>> > +++ b/gcc/testsuite/gcc.dg/tree-prof/time-profiler-2.c
>> > @@ -1,4 +1,4 @@
>> > -/* { dg-options "-O
Hi!
On 2023-11-22T11:51:02+0100, Christophe Lyon wrote:
> On Tue, 21 Nov 2023 at 22:24, Thomas Schwinge wrote:
>> On 2023-11-19T16:05:42+0100, Jan Hubicka wrote:
>> > --- /dev/null
>> > +++ b/gcc/testsuite/gcc.dg/tree-ssa/return-value-range-1.c
>>
all those test
cases have other issues; will install further patches later on.)
Jakub, Tobias, please let me know if it's not expected that *all* the
"variant" functions have to be tagged '__attribute__ ((noipa))' (as I've
done); just tagging t
licable places, to get rid of
UNRESOLVEDs for GCN plus nvptx offload configurations.)
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; S
7;-mabi' options, add 'Negative' property mentions itself"
- commit 69c426b89579312af91035c26fb1e270bfbcad00 "doc/options.texi: Fix the
description of 'Negative'"
(..., and yes, GCC/nvptx does need similar treatment...)
Grüße
Thomas
-
Hi!
On 2023-11-24T15:55:52+0100, I wrote:
> OK to push the attached
> "GCN: Tag '-march=[...]', '-mtune=[...]' as 'Negative' of themselves
> [PR112669]"?
With that in place, we may then "GCN: Remove 'last_arg' spec function",
ncrementally, later on.
I understand that your change does work for you as-is, so I've now pushed
that to master branch in commit 5707e9db9c398d311defc80c5b7822c9a07ead60
"hurd: Add multilib paths for gnu-x86_64", see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation Gmb
f
"hurd: Ad default-pie and static-pie support", 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
Hi!
On 2023-11-21T16:20:22+0100, Arthur Cohen wrote:
> A newer version of the library has been force-pushed to the branch
> `libgrust-v2/to-submit`.
> On 11/20/23 15:55, Thomas Schwinge wrote:
>> Arthur and Pierre-Emmanuel have prepared a GCC/Rust libgrust-v2/to-submit
&g
amp;& __has_extension(x))
> +#define CXX11 (__cplusplus >= 201103L)
> +#define CXX14 (__cplusplus >= 201402L)
> +
> +#if !FEAT(cxx_exceptions) || !FEAT(cxx_rtti)
> +#error
> +#endif
..., but here, they are assumed available unconditionally. OK to push
"Adju
100
> @@ -0,0 +1,309 @@
> +// C++26 P2741R3 - user-generated static_assert messages
OK to push the attached
"Fix 'g++.dg/cpp26/static_assert1.C' for '-fno-exceptions' configurations"?
Grüße
Thomas
> +// { dg-do compile { target c++11 } }
> +// { dg-option
27; for '-fno-exceptions' configurations",
see attached.
Grüße
Thomas
> @@ -0,0 +1,36 @@
> +// { dg-do run { target c++26 } }
> +
> +#include
> +#include
> +#include
> +
> +void
> +test_at()
> +{
> + int arr[4]{0, 1, 2, 3};
> + st
Hi!
On 2023-11-28T12:11:22-0500, Jason Merrill wrote:
> On 11/28/23 12:08, Thomas Schwinge wrote:
>> // { dg-options "" }
>> +// Override any default-'-fno-exceptions':
>> +// { dg-additional-options -fexceptions }
>
> Might as well put the -fe
gt; @@ -0,0 +1,9 @@
> +/* { dg-do compile } */
> +/* { dg-additional-options "-march=gfx90a -O1" } */
> +/* { dg-skip-if "incompatible ISA" { *-*-* } { "-march=gfx90[068]" } } */
> +[...]
Etc.
OK to push the attached
"GCN: Generally enable the '
'only_for_offload_target' wrapper for 'scan-offload-tree-dump'
etc.",
which I've also just pushed to master branch in
commit 27c79b91f6008a21006d4e7053a98e63f2990bb2.)
Grüße
Thomas
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c/target-simd-clone-2.c
> @
Hi!
On 2023-09-05T15:28:20+0100, Richard Sandiford via Gcc-patches
wrote:
> Thomas Schwinge writes:
>> On 2023-09-04T23:05:05+0200, I wrote:
>>> On 2019-07-16T15:04:49+0100, Richard Sandiford
>>> wrote:
>>>> This patch therefore adds a new check-fu
tion
> #define ASM_OUTPUT_DEF_FROM_DECLS(STREAM, NAME, VALUE) \
>nvptx_asm_output_def_from_decls (STREAM, NAME, VALUE)
>
> +//TODO
> +/* ..., but don't let that dummy ASM_OUTPUT_DEF definition influence other
> + macros. */
> +#define TARGET_USE_LOCAL_THUNK_ALIAS_P(DECL) (!((nvp
; \
>> CXX="$(CXX_FOR_TARGET) $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CXX;
>
> With that one moved into the generic 'BASE_TARGET_EXPORTS', [...]
Pushed to master branch commit d1bff1ba4d470f6723be83c0e3c4d5083e51877a
"Pass 'SYSROOT_CFLAGS_FOR_TAR
original scenario.)
Otherwise, I observe that my proposed re-work does still achieve the
desired outcome re '--sysroot=[...]', and Iain has long ago confirmed
that it does resolve <https://gcc.gnu.org/PR109951>
"libgomp, testsuite: non-native multilib c++ tests fail on Darwin&q
eip.net>
"libgomp: Consider '--with-build-sysroot=[...]' for target libraries'
build-tree testing (instead of build-time 'CC' etc.) [PR91884, PR109951]".
OK to push the attached
"libffi: Consider '--with-build-sysroot=[...]' for target libraries&#
quot;.
OK to push the attached
"libatomic: Consider '--with-build-sysroot=[...]' for target libraries'
build-tree testing (instead of build-time 'CC' etc.) [PR109951]"?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arn
Ian/Go upstream) the attached
"libgo: Consider '--with-build-sysroot=[...]' for target libraries' build-tree
testing (instead of build-time 'CC' etc.) [PR109951]"?
By the way, I've tested this one via hard-coding
'libgo/configure.ac:USE_DEJAGNU' to
altering issue). The html part is still scrubbed from the
>> inbox.sourceware.org archive, so b4 works just fine. But I don't know
>> what patchwork.sourceware.org does with HTML attachements. Of course
>> people really shouldn't sent HTML attachments to gcc-patches, so m
lpine.lnx.2.00.1306131614000.26...@zhemvz.fhfr.qr>
"[RFC] Re-write LTO type merging again, do tree merging", continued
<https://inbox.sourceware.org/alpine.lnx.2.00.1306141240340.6...@zhemvz.fhfr.qr>
"Re-write LTO type merging again, do tree merging".
In 2013, offloading
f ACCEL_COMPILER
> + char *omp_requires_file = getenv ("GCC_OFFLOAD_OMP_REQUIRES_FILE");
> + if (omp_requires_file == NULL || omp_requires_file[0] == '\0')
> +fatal_error (input_location, "GCC_OFFLOAD_OMP_REQUIRES_FILE unset");
> + FILE *f = fopen (omp_requires_file, "wb");
> + if (!f)
> +fatal_error (input_location, "Cannot open omp_requires file %qs",
> + omp_requires_file);
> + uint32_t req_mask = omp_requires_mask & ~OMP_REQUIRES_TARGET_USED;
> + fwrite (&req_mask, sizeof (req_mask), 1, f);
> + fclose (f);
> +#endif
> }
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-09-15T12:11:44+0200, Richard Biener via Gcc-patches
wrote:
> On Fri, Sep 15, 2023 at 11:20 AM Thomas Schwinge
> wrote:
>> Now, that was another quirky debug session: in
>> 'gcc/omp-low.cc:create_omp_child_function' we clearly do set
>> 'TREE_
Hi!
On 2023-09-15T15:33:59+0200, Robin Dapp wrote:
> is there anything we can do to assist from the riscv side in order to help
> with this? I haven't really been involved with it but was wondering
> what's missing. If I understand correctly Thomas has a major cleanup
>
ode.
Pushed to master branch commit 3049501db3a31d10c84fc42b306e29b6fe68330f
"Fix up 'g++.dg/abi/nvptx-ptrmem1.C'", see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit besch
r branch commit 0db533114235539199f6698d8d52c5101107567e
"Move 'g++.dg/abi/nvptx-[...].C' -> 'g++.target/nvptx/abi-[...].C'",
see attached.
Grüße
Thomas
> * gcc.target/nvptx/abi-complex-arg.c: New.
> * gcc.target/nvptx/abi-complex-ret.c: New.
> * gcc.target/nvptx
Hi!
Pushed to master branch commit ade81bb9079f3b84e49300a283c05ee9dc3e2af4
"Add 'g++.target/nvptx/nvptx.exp' for nvptx-specific C++ test cases",
see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
M
Hi!
Ping.
Grüße
Thomas
On 2023-09-08T14:02:50+0200, I wrote:
> Hi!
>
> On 2017-08-10T15:42:13+0200, Jan Hubicka wrote:
>>> On 07/31/2017 11:57 AM, Yuri Gribov wrote:
>>> > On Mon, Jul 31, 2017 at 9:04 AM, Martin Liška wrote:
>>> >> Doing the tra
)
> --- a/gcc/rust/config-lang.in
> +++ b/gcc/rust/config-lang.in
> +target_libs="target-libffi target-libbacktrace target-libgrust"
Please don't add back 'target-libffi' and 'target-libbacktrace' here;
just 'target-libgrust'. (As is
acro/Makefile.am: New file.
>> * libgrust/libproc_macro/proc_macro.cc: New file.
>> * libgrust/libproc_macro/proc_macro.h: New file.
>>
>> Signed-off-by: Pierre-Emmanuel Patry
... with:
libgrust/
* Makefile.am: New file.
[...]
(Or similar syntax.)
docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__MEM.html#group__CUDA__MEM_1g27f885b30c34cc20a663a671dbf6fc27>
"cuMemcpy2D" etc.)
Grüße
Thomas
> 2023-09-05 Julian Brown
>
> libgomp/
> * plugin/plugin-nvptx.c (GOMP_OFFLOAD_memcpy2d): Adjust parameter
4
-fma.rn.f64 %value,%r35,0d3c6a62633145c06e,%r23;
+fma.rn.f64 %value,%r27,0dbc6a62633145c06e,%r23;
[...]
'nvptx-none/libgcc/_gcov_info_to_gcda.o':
[...]
-.reg .u32 %r186;
[...]
-add.u32 %r186,%r59,%r59;
-add.u32 %r187,%r186,%r59;
+vadd.u32.u32.u32.ad
s etc. Also, 'tmp-libc_a-lnumeric.i.xz'
is attached if you'd like to reproduce this with your own nvptx target
'cc1':
$ [...]/configure --target=nvptx-none --enable-languages=c
$ make -j12 all-gcc
$ gcc/cc1 -fpreprocessed tmp-libc_a-lnumeric.i -quiet -dumpbase
tmp-libc_a-lnumeric.c -dumpbase-ext .c -misa=sm_30 -g -O2 -fno-builtin -o
tmp-libc_a-lnumeric.s -fdump-rtl-all # -fno-late-combine-instructions
Grüße
Thomas
tmp-libc_a-lnumeric.i.xz
Description: application/xz
op.cc
@@ -1305,17 +1305,17 @@ class pass_cprop_hardreg : public rtl_opt_pass
public:
pass_cprop_hardreg (gcc::context *ctxt)
: rtl_opt_pass (pass_data_cprop_hardreg, ctxt)
{}
/* opt_pass methods: */
bool gate (function *) final override
{
-
+++ gcc/passes.def
@@ -529,7 +529,10 @@ along with GCC; see the file COPYING3. If not see
NEXT_PASS (pass_regrename);
NEXT_PASS (pass_fold_mem_offsets);
NEXT_PASS (pass_cprop_hardreg);
- NEXT_PASS (pass_fast_rtl_dce);
+ POP_INSERT_PASSES ()
+
S (PASS)
+ NEXT_PASS (PASS, 1)
TERMINATE_PASS_LIST (PASS)
*/
[...]
(That is, this is 'NEXT_PASS' for the first instance of pass 'PASS'.)
That's benign so far, but with another thing that I'll be extending, I'd
then run into an error while the s
r.schwinge.ddns.net>
"Rewrite usage comment at the top of 'gcc/passes.def'" to avoid running
into the 'ERROR: Can't locate [...]' that I'm adding, while processing
the 'PUSH_INSERT_PASSES_WITHIN (PASS)' in the usage comment at the top
Jakub (I think) pointed out that the
> idea is not to run them to avoid crashes if reload fails e.g. for an
> invalid asm. So I've made a new container pass.
OK to push "Document 'pass_postreload' vs. 'pass_late_compilation'", see
attached?
Grüße
Th
Hi Richard!
On 2024-06-28T17:48:30+0100, Richard Sandiford
wrote:
> Richard Sandiford writes:
>> Thomas Schwinge writes:
>>> On 2024-06-27T23:20:18+0200, I wrote:
>>>> On 2024-06-27T22:27:21+0200, I wrote:
>>>>> On 2024-06-27T18:49:17+0200, I wrote
PASS (pass_leaf_regs);
> NEXT_PASS (pass_split_before_sched2);
>
> This (only) cleans up "the mess that 'pass_late_combine' created"; no
> further changes in GCC target libraries for nvptx. (For avoidance of
> doubt: "mess" is a great e
: Support mapping of DT with allocatable components" (or
some related change).
This could be the Fortran front end generating incorrect GIMPLE, or the
middle end or (more likely?) nvptx back end not correctly handling
something that only comes into existance via the Fortran front
nMP 5.1 'num_teams' lower bound", which
are exactly the corresponding changes for GCN (see below Jakub's nvptx
changes for reference); OK to push?
Grüße
Thomas
> 2021-11-12 Jakub Jelinek
>
> * config/nvptx/team.c (__gomp_team_num): Define as
> __a
Hi!
On 2024-07-15T12:16:30+0100, Andrew Stubbs wrote:
> On 15/07/2024 10:29, Thomas Schwinge wrote:
>> On 2021-11-12T18:58:04+0100, Jakub Jelinek via Gcc-patches
>> wrote:
>>> And finally here is a third version, [...]
>>
>> ... which became commit 9fa7
Hi!
On 2024-07-15T17:01:46+0100, Andrew Stubbs wrote:
> On 15/07/2024 16:36, Thomas Schwinge wrote:
>> On 2024-07-15T12:16:30+0100, Andrew Stubbs wrote:
>>> On 15/07/2024 10:29, Thomas Schwinge wrote:
>>>> On 2021-11-12T18:58:04+0100, Jakub Jelinek via Gcc-p
'gcc/testsuite/lib/target-supports-*.exp' files, to un-bloat the former
one.)
Grüße
Thomas
>From b029aac1801ae1950e19bafef966eae28ce5b29f Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Wed, 17 Jul 2024 23:11:31 +0200
Subject: [PATCH] Make 'target-supports.exp' add
Hi!
First, note this is now GCC PR115989
"[15 regression] libgomp.oacc-fortran/privatized-ref-2.f90 fails after
r15-2135-gc3aa339ea50f05".
Otherwise:
On 2024-07-19T06:54:46+0100, Paul Richard Thomas
wrote:
> Thanks for doing that test. Here is what the error looks like
with _FILE_OFFSET_BITS=64"
26 | # error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
This change has also been proposed to upstream LLVM:
https://github.com/llvm/llvm-project/pull/99699
Signed-off-by: Thomas Petazzoni
---
libsanitizer/sanitizer_common/sanitizer_
PASS: gfortran.fortran-torture/execute/intrinsic_matmul.f90 compilation,
-O2 -fomit-frame-pointer -finline-functions -funroll-loops
PASS: gfortran.fortran-torture/execute/intrinsic_matmul.f90 compilation,
-O3 -g
PASS: gfortran.fortran-torture/execute/intrinsic_matmul.f90 co
on terminated.
compiler exited with status 1
FAIL: gfortran.dg/implicit_class_1.f90 -O0 (test for excess errors)
That is, the 'gcc' invocation by 'collect2' is passed
'-fdump-fortran-original', but doesn't know what to do with that. (Maybe
using '-Wno-
rally reviewed necessary test suite changes.)
> but this is definitely an
> improvement.
Right, thanks!
A follow-up change could then make sure that 'offload_target_amdgcn' etc.
only return true if offloading compilation actually is supported given
the current command-line options. Either again via a
'check_effective_target_lp64' check in
'libgomp_check_effective_target_offload_target', or -- better? -- change
the driver to only conditionally print 'OFFLOAD_TARGET_NAMES=[...]'?
Does that basically mean to move the 'offload_abi' checks from the
'mkoffload's into the driver? That appears to make sense indeed.
(..., so that we don't even invoke the 'mkoffload's for unsupported
configurations/options.)
Grüße
Thomas
ming libgomp Fortran test cases
(where I can't easily call 'cuCtxSetLimit(CU_LIMIT_STACK_SIZE, [bytes])'
in the test cases themselves).
Grüße
Thomas
>From d32f1a6a73b767ab5cf2da502fc88975612b80f2 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Fri, 31 May 2024 17:04:39 +
parse tree.
Having a -finline-intrinsic options, which would be set at any
optimization level except -Os, may be the right way forward.
Or something else :-)
Best regards
Thomas
ive
that a try, and/or does anyone see any issues with that approach?
And use something like '-foffload-abi=disable' to replace the current:
/* PR libgomp/65099: Currently, we only support offloading in 64-bit
configurations. */
if (offload_abi == OFFLOAD_ABI_LP64)
{
(As discussed before, this should be done differently altogether, but
that's for another day.)
Grüße
Thomas
xecutable-]{+execution test+}
PASS: gfortran.dg/optional_absent_8.f90 -O1 (test for excess errors)
PASS: gfortran.dg/optional_absent_8.f90 -O1 execution test
PASS: gfortran.dg/optional_absent_8.f90 -O2 (test for excess errors)
STOP 11
Grüße
Thomas
> This patch ha
in a
few UNRESOLVEDs.
> [Etc.]
Pushed to trunk branch commit 9f5d22e3e2b8e4532896a4f3837cb86006d5930c
"OpenMP: Constructors and destructors for "declare target" static aggregates:
Fix effective-target keyword in test cases",
see attached.
Grüße
Thomas
>From 9f5d
looks obvious, too).
Best regards
Thomas
Hi Prathamesh!
On 2024-08-12T07:50:07+, Prathamesh Kulkarni wrote:
>> From: Thomas Schwinge
>> Sent: Friday, August 9, 2024 12:55 AM
>> On 2024-08-08T06:46:25-0700, Andrew Pinski wrote:
>> > On Thu, Aug 8, 2024 at 6:11 AM Prathamesh Kulkarni
>>
-if "truth type does not match vector type" { riscv_v } } */
Same thing for GCN; I've pushed to trunk branch
commit 2daf6187c7289d012365419e10995042139cf8f5
"Un-XFAIL 'gcc.dg/signbit-5.c' for GCN", see attached.
Grüße
Thomas
>From 2daf6187c7289d012365419e10
Steve,
On Sun, Aug 18, 2024 at 12:10:18PM +0200, Thomas Koenig wrote:
this version of the patch includes DOT_PRODUCT, MATMUL and quite
a few improvements for simplification.
Thomas,
Your updated patch applied cleanly on top-of-tree gcc.
Bootstrap and regression testing on amd64-*-freebsd
should do the trick then, right?
>> I will give it a try.
>
> Ok with a testcase.
No need for "Copying initpri1.c" if there's '#include "initpri1.c"'. ;-P
(In preparation for further changes) OK to push the attached
"Clarify that 'gcc.dg/initpr
gcc/testsuite/
* gcc.dg/initpri1.c: Integrate this...
* g++.dg/special/initpri1.C: ..., and this...
* c-c++-common/initpri1.c: ... here.
* gcc.dg/initpri1-lto.c: Adjust.
* gcc.dg/initpri2.c: Integrate this...
* g++.dg/special/initpri2.C: ...,
tion units, in combination with internal linkage
variants. Out of that fell the following four patches. OK to push?
This depends on
<https://inbox.sourceware.org/87y17kejqz@euler.schwinge.ddns.net>
"Clarify that 'gcc.dg/initpri3.c' is a LTO variant of 'gcc.dg/initpri1.c':
'gcc.dg/initpri1-lto.c' [PR46083]".
Grüße
Thomas
Similar to TODO
"Consolidate similar C/C++ test cases for 'constructor', 'destructor' function
attributes with priority".
gcc/testsuite/
* gcc.dg/initpri1-lto.c: Integrate this...
* c-c++-common/initpri1-lto.c: ... here.
---
gcc/testsuite/{gcc.dg => c-c++-common}/initpri1
gcc/testsuite/
* c-c++-common/initpri1.c: Split into...
* c-c++-common/initpri1_part_c1.c: ... this, and...
* c-c++-common/initpri1_part_c2.c: ... this, and...
* c-c++-common/initpri1_part_c3.c: ... this, and...
* c-c++-common/initpri1_part_cd4.c: ...
gcc/testsuite/
* c-c++-common/initpri1_part_c1.c: Consider 'CDTOR_LINKAGE'.
* c-c++-common/initpri1_part_c2.c: Likewise.
* c-c++-common/initpri1_part_c3.c: Likewise.
* c-c++-common/initpri1_part_cd4.c: Likewise.
* c-c++-common/initpri1_part_d1.c: Like
a-warp-level-primitives/
> + //TODO
> https://stackoverflow.com/questions/54055195/activemask-vs-ballot-sync
> + "\\t"".reg.b32""\\t" "%%r_exp;",
> + "%.\\t" "mov.b32" "\\t" &quo
allows
> for simplifying GCC as per the attached
> 'Clean up after newlib "nvptx: In offloading execution, map '_exit' to
> 'abort' [GCC PR85463]"',
> which I've just pushed to GCC devel/omp/gcc-12 branch in
> commit 094b379f461bb4b
the additional "for offloading" piece:
> "nvptx: Support global constructors/destructors via 'collect2' for
> offloading".
Similarly revised, I've now pushed to trunk branch
commit 5bbe5350a0932c78d4ffce292ba4104a6fe6ef96
"nvptx offloading: Global cons
Stubbs, is: "nvptx, libgcc: Stub unwinding implementation"
Pushed to trunk branch commit a29c5852a606588175d11844db84da0881227100
"nvptx, libgcc: Stub unwinding implementation", see attached.
Grüße
Thomas
>From a29c5852a606588175d11844db84da0881227100 Mon Sep 17 00:00:00
901 - 1000 of 5601 matches
Mail list logo
