..., using the standard idiom. This '*.exp' file doesn't adhere to the
parallel testing protocol as defined in 'gcc/testsuite/lib/gcc-defs.exp'.
This also restores proper behavior for '*.exp' files executing after (!) this
one, which erroneously caused hundreds or even thousands of individual tes
ger :: tmp_x(2,2), tmp_y(2,2), tmp_z(2,2), i, j
> + tmp_x = reshape([1, 4, 11, 14], [2,2])
> + tmp_y = reshape([2, 5, 12, 15], [2,2])
> + tmp_z = reshape([3, 6, 13, 16], [2,2])
> + do j = 1, 2
> +do i = 1, 2
> + if (var4%Q%D(i,j)%x /= tmp_x(i,j)) stop 16
> + if (va
Hi Andre,
On Thu, 17 Apr 2025 at 14:20, Andre Vehreschild wrote:
> Hi Jerry,
>
> thanks for the review and sorry for the long delay. With publishing the
> team's
> patches for gfortran, I also created a pull request for OpenCoarrays.
> There I
> was asked to add some testcase with more "beef" in
18]",
see attached? Or, is another approach preferable?
Grüße
Thomas
--- /dev/null
+++ b/gcc/testsuite/cobol.dg/group2/FUNCTION_DATE___TIME_OMNIBUS.cob
@@ -0,0 +1,334 @@
+ *> { dg-do run }
+
+identification division.
+program-id. test
Unused; remnant of an (internal) experiment, before we had nvptx 'as'.
gcc/
* config/nvptx/nvptx.cc (TARGET_ASM_NEED_VAR_DECL_BEFORE_USE):
Don't '#define'.
---
gcc/config/nvptx/nvptx.cc | 2 --
1 file changed, 2 deletions(-)
diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/co
INE
>C(int) {};
>~C() {};
Pushed to trunk branch commit 518efed8cb7d003cd85477060b1fe926a2d7a53b
"Remove 'ALWAYS_INLINE' workaround in
'libgomp.c++/target-exceptions-pr118794-1.C'",
see attached.
Grüße
Thomas
>From 518efed8cb7d003cd85477060b1fe9
PR target/106445
libgomp/
* testsuite/libgomp.c++/pr106445-1.C: New.
* testsuite/libgomp.c++/pr106445-1-O0.C: Likewise.
---
libgomp/testsuite/libgomp.c++/pr106445-1-O0.C | 3 +++
libgomp/testsuite/libgomp.c++/pr106445-1.C| 18 ++
2 files changed
Hi!
On 2025-03-25T11:51:26+0100, Tom de Vries wrote:
> On 3/25/25 11:18, Thomas Schwinge wrote:
>> On 2022-03-22T14:41:46+0100, Tom de Vries via Gcc-patches
>> wrote:
>>> Starting with ptx isa version 6.3, a ptx directive .alias is available.
>>
>> Regar
gcc/testsuite/
* g++.target/gcn/exceptions-bad_cast-1.C: New.
* g++.target/nvptx/exceptions-bad_cast-1.C: Likewise.
libgomp/
* testsuite/libgomp.c++/target-exceptions-bad_cast-1.C: New.
* testsuite/libgomp.oacc-c++/exceptions-bad_cast-1.C: Likewise.
-
With '-mfake-exceptions' enabled, the user-visible behavior in presence of
exception handling constructs changes such that the compile-time
'sorry, unimplemented: exception handling not supported' is skipped, code
generation proceeds, and instead, exception handling constructs 'abort' at
run time.
Like 'gcc.target/gcn/gcn.exp' is modeled after 'gcc.dg/dg.exp', this new
'g++.target/gcn/gcn.exp' is modeled after 'g++.dg/dg.exp'.
gcc/testsuite/
* g++.target/gcn/gcn.exp: New.
---
gcc/testsuite/g++.target/gcn/gcn.exp | 56
1 file changed, 56 insertio
gcc/testsuite/
* g++.target/gcn/exceptions-throw-3.C: New.
* g++.target/nvptx/exceptions-throw-3.C: Likewise.
libgomp/
* testsuite/libgomp.c++/target-exceptions-throw-3.C: New.
* testsuite/libgomp.oacc-c++/exceptions-throw-3.C: Likewise.
---
.../g++.
gcc/testsuite/
* g++.target/gcn/exceptions-throw-2.C: New.
* g++.target/nvptx/exceptions-throw-2.C: Likewise.
libgomp/
* testsuite/libgomp.c++/target-exceptions-throw-2.C: New.
* testsuite/libgomp.c++/target-exceptions-throw-2-offload-sorry-GCN.C:
Li
gcc/testsuite/
* g++.target/gcn/exceptions-throw-1.C: New.
* g++.target/nvptx/exceptions-throw-1.C: Likewise.
libgomp/
* testsuite/libgomp.c++/target-exceptions-throw-1.C: New.
* testsuite/libgomp.c++/target-exceptions-throw-1-O0.C: Likewise.
gcc/testsuite/
* g++.target/gcn/exceptions-bad_cast-3.C: New.
* g++.target/nvptx/exceptions-bad_cast-3.C: Likewise.
libgomp/
* testsuite/libgomp.c++/target-exceptions-bad_cast-3.C: New.
* testsuite/libgomp.oacc-c++/exceptions-bad_cast-3.C: Likewise.
-
gcc/testsuite/
* g++.target/gcn/exceptions-bad_cast-2.C: New.
* g++.target/nvptx/exceptions-bad_cast-2.C: Likewise.
libgomp/
* testsuite/libgomp.c++/target-exceptions-bad_cast-2.C: New.
*
testsuite/libgomp.c++/target-exceptions-bad_cast-2-offload-sor
PR target/118794
gcc/testsuite/
* g++.target/gcn/exceptions-pr118794-1.C: New.
* g++.target/nvptx/exceptions-pr118794-1.C: Likewise.
libgomp/
* testsuite/libgomp.c++/target-exceptions-pr118794-1.C: New.
*
testsuite/libgomp.c++/target-exceptio
... documenting the status quo.
PR c++/119692
gcc/testsuite/
* g++.target/gcn/pr119692-1-1.C: New.
* g++.target/nvptx/pr119692-1-1.C: Likewise.
libgomp/
* testsuite/libgomp.c++/pr119692-1-1.C: New.
* testsuite/libgomp.c++/pr119692-1-2.C: Like
("eval" body line 1)
invoked from within
"eval saved-dg-test $args "
(procedure "dg-test" line 1)
invoked from within
"dg-test $testcase $options ${default-extra-options}"
(procedure "dg-runtest" line 10)
ppose we could move this wrapping setup into
'asan_init', and then undo it in 'asan_finish'.
I'll be happy to draft a patch if someone confirms my thinking.
Grüße
Thomas
verbose "Failed test for output line $linenum" 3
> + pass "$name output file test"
> + verbose "Passed test for output file [lindex ${output-file}
> 1]" 3
OK to push the attached "Polish 'dg-output-f
Ah, yes :-)
Thanks for the patch!
Committed as r15-9406-g64319b2ccae2fdfae06347545e031e56d790dad7 .
Thanks for the review!
Best regards
Thomas
Fix-up for commit 2d7e1d6e40a13a5f160b584336795b80f193ec3b
"Fortran: Add code gen for do,concurrent's LOCAL/LOCAL_INIT [PR101602]":
../../source-gcc/gcc/fortran/trans-stmt.cc: In function ‘void
gfc_trans_concurrent_locality_spec(bool, stmtblock_t*,
std::vector*, gfc_expr_list**)’:
../../
Hi All,
Now that the reduce intrinsic seems to be OK on all platforms, I thought
that it was time to catch up with the documentation.
The attached produces good .html without any additional warnings or errors
using texi2any and ~/share/info/gfortran.info is as intended.
OK for mainline?
Paul
di
ought better
safe than sorry.
Most of the patch is actually reformatting due to the 80-column-rule.
(Do we really want to keep that for gfortran?)
Regression-tested. OK for trunk?
Best regards
Thomas
Fix ICE in compare_parameter.
gcc/fortran/ChangeLog:
PR fortran/1
standardization
by the OpenACC Technical Committee.)
Grüße
Thomas
>From 660ffe85a98e9f0ec6ddd6ba1f383a44b672502c Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Wed, 9 Apr 2025 17:35:42 +0200
Subject: [PATCH] OpenACC: Support GCC/C++-special 'default(_GCC_firstprivate)'
cla
This resolves GCN:
ld: error: undefined symbol: _Unwind_DeleteException
>>> referenced by eh_catch.cc:109
([...]/source-gcc/libstdc++-v3/libsupc++/eh_catch.cc:109)
>>> eh_catch.o:(__cxa_end_catch) in archive
[...]/build-gcc/amdgcn-amdhsa/libstdc++-v3/src/.libs/libstdc++
This resolves GCN:
ld: error: undefined symbol: _Unwind_RaiseException
>>> referenced by eh_throw.cc:93
([...]/source-gcc/libstdc++-v3/libsupc++/eh_throw.cc:93)
>>> eh_throw.o:(__cxa_throw) in archive
/srv/data/tschwinge/amd-instinct2/gcc/build/submit-light-target_gcn/b
Minor fix-up for commit 65b31b3fff2fced015ded1026733605f34053796
"nvptx: In offloading compilation, special-case certain host-setup symbol
aliases [PR101544]",
as of which we see for non-offloading configurations:
+[...]/source-gcc/gcc/config/nvptx/nvptx.cc: In function 'void
nvptx_asm_outpu
For both GCN, nvptx, this gets rid of 'configure'-time:
configure: WARNING: No native atomic operations are provided for this
platform.
configure: WARNING: They will be faked using a mutex.
configure: WARNING: Performance of certain classes will degrade as a result.
..., and changes:
e to compile-time detection
of 'sorry, unimplemented: dynamic stack allocation not supported' in
'gcc/testsuite/lib/gcc-dg.exp:gcc-dg-prune', we should also be able to
implement a corrsponding thing for this run-time failure, via new
machinery in the repla
s [PR119645]"?
Jonathan, please put a sharp eye on the
'libstdc++-v3/acinclude.m4:GLIBCXX_ENABLE_LOCK_POLICY' change; to make
sure this only affects GCN, nvptx, but nothing else.
Grüße
Thomas
>From 1d3278050f9560666f6debcd2ead711660bebd4e Mon Sep 17 00:00:00 2001
From: Thoma
Hi Andre,
On Mon, 7 Apr 2025 at 07:29, Andre Vehreschild wrote:
> Hi Paul,
>
> shouldn't this be done in iresolve.cc to make other parts of gfortran
> benefit
> from learning, that the sym is allocatable?
>
> I'll give it a try. I was attempting to eliminate any wider side effects
by setting the
Hi All,
As far as I can tell, the attached patch fixes the problems with the reduce
intrinsic. I would be grateful to the reporters if they would confirm that
this is the case.
The key to the fix appears in reduce_3.f90, which failed even with -m64.
Although it was not apparent from the tree dump
... testing for the GCC/nvptx "alias definitions not supported" error
diagnostic.
gcc/testsuite/
* gcc.target/nvptx/alias-unsupported-1.c: New.
---
gcc/testsuite/gcc.target/nvptx/alias-unsupported-1.c | 9 +
1 file changed, 9 insertions(+)
create mode 100644 gcc/testsuite
This resolves all instances of PR119369
"GCN: weak undefined symbols -> execution test FAIL,
'HSA_STATUS_ERROR_VARIABLE_UNDEFINED'";
for all affected test cases, the execution test status progresses FAIL -> PASS.
This however also causes a small number of (expected) regressions, very similar
to G
... next to '-malias' variant: commit a1865fd33897bc6c6e0109df0a12ee73ce386315
"Add 'g++.target/nvptx/alias-g++.dg_init_dtor2-1.C'", to document what we're
doing to '-mno-alias'.
gcc/testsuite/
* g++.target/nvptx/alias-g++.dg_init_dtor2-2.C: New.
---
.../nvptx/alias-g++.dg_init_dt
configurations; any comments before I push the attached
"nvptx: In offloading compilation, special-case certain host-setup symbol
aliases [PR101544]"?
In particular, is the use of a new 'c++ cdtor alias' attribute OK?
Grüße
Thomas
>From 9bc9f515ed26602e97ebbcac453f73cddb8
\$(CXXFLAGS-\$(subdir)/\$@)"
> +# ..., see:
> +tmake_file="$tmake_file cpu/nvptx/t-nvptx"
... this is not necessary anymore, and I've pushed to trunk branch
commit 287f360b3e75a19c48ee14c71f51b6e7968474ef
"libstdc++, nvptx: Remove machinery to inject per-fi
Hi!
I have, by the way, filed <https://gcc.gnu.org/PR119573>
"nvptx: PTX '.const', constant state space" for this topic.
On 2025-04-01T09:32:46+0200, Jakub Jelinek wrote:
> On Tue, Apr 01, 2025 at 09:19:08AM +0200, Richard Biener via Gcc wrote:
>> On Tue, Apr
This fixes a few hundreds of compilation/linking FAILs (similar to PR69506),
where the GCN/LLVM 'ld' reported:
ld: error: relocation R_AMDGPU_REL32_LO cannot be used against symbol
'_ZGTtnam'; recompile with -fPIC
>>> defined in
[...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a(co
From: Thomas Schwinge
..., so that users don't manually need to specify '-foffload-options=-lstdc++'
in addition to '-lstdc++' (specified manually, or implicitly by the driver).
Do like commit 4bcb46b3ade1796c5a57b294f5cca25f00671cac
"driver: Forward '-lgfortra
Hello Harald,
OK with the above addressed.
Both addressed and pushed in
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=737a5760bb24a0a945cc2c916ba452e3f0060c58
Thanks for the review (and for catching the miscellaneous
problems on the way)!
Best regards
Thomas
Hi!
On 2025-03-24T13:38:56-0400, Jason Merrill wrote:
> On 3/24/25 7:02 AM, Thomas Schwinge wrote:
>> On 2025-03-21T15:46:01+0100, I wrote:
>>> On 2025-03-19T14:25:49+, Jonathan Wakely wrote:
>>>> On Wed, 19 Mar 2025 at 14:21, Marek Polacek wrote:
>>&g
sn't cgraph 'referred_to_p ()', but it should it be? (I have not much
clue about the cgraph machinery generally, and even less about the
applicability of it/of its state in offloading compilation,
specifically.)
Grüße
Thomas
u please check whether you inadvertently added something
that was not planned or tested?
I sent out the wrong version of the patch, sorry (one which contained
an intermediate stage of something I tried, and then abandoned).
Here is the one that actually in my tree, and that I regression-tested.
B
Best regards
Thomas
gcc/fortran/ChangeLog:
PR fortran/119419
* dump-parse-tree.cc (write_funptr_fcn): New function.
(write_type): Invoke it for C_FUNPTR.
(write_interop_decl): Do not dump vtabs.
diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran
obviously the same if there is only a single nvptx device.
>
> The patch mimics what other code in the plugin uses and has been lightly
> tested so far.
>
> Comments before I push it?
I still see 'libgomp.c/interop-fr-1.c' FAIL in the same way with this
patch applied
for excess errors)
As other files state:
! The following definitions are in omp_lib, which cannot be included
! in gcc/testsuite/
Grüße
Thomas
> + integer(omp_interop_kind) :: a1 ! by ref
> + integer(omp_interop_kind), optional :: a2 ! as pointer
> + integer(omp
Hi!
On 2025-03-21T15:46:01+0100, I wrote:
> On 2025-03-19T14:25:49+, Jonathan Wakely wrote:
>> On Wed, 19 Mar 2025 at 14:21, Marek Polacek wrote:
>>> On Wed, Mar 19, 2025 at 12:38:31PM +0100, Thomas Schwinge wrote:
>>> > In 2001
From: Thomas Schwinge
PR target/101544
libgomp/
* testsuite/libgomp.c++/pr101544-1.C: New.
* testsuite/libgomp.c++/pr101544-1-O0.C: Likewise.
* testsuite/libgomp.oacc-c++/pr101544-1.C: Likewise.
---
libgomp/testsuite/libgomp.c++/pr101544-1-O0.C | 4
PR libgomp/96835
libgomp/
* testsuite/libgomp.c++/pr96835-1.C: New.
* testsuite/libgomp.c++/pr96835-1-O0.C: Likewise.
* testsuite/libgomp.oacc-c++/pr96835-1.C: Likewise.
---
libgomp/testsuite/libgomp.c++/pr96835-1-O0.C | 3 ++
libgomp/testsuite/libgomp.c++
Hi!
On 2025-03-21T08:37:16-0400, Jason Merrill wrote:
> On 3/20/25 12:48 PM, Thomas Schwinge wrote:
>> On 2025-03-20T11:59:07-0400, Jason Merrill wrote:
>>> On 3/20/25 11:35 AM, Thomas Schwinge wrote:
>>>> Appears that I'm too dumb to implement
>>>>
gcc/
* config/nvptx/nvptx.cc (default_ptx_version_option): Default at
least to '-mptx=6.3'.
* doc/invoke.texi (Nvidia PTX Options): Update '-mptx=[...]'.
gcc/testsuite/
* gcc.target/nvptx/march-map=sm_30.c: Adjust.
* gcc.target/nvptx/march-map
Hi Andre,
I am reasonably familiar with the mess that is gfc_conv_procedure_call :-)
So in spite of you having a hard time explaining things today, I see your
patch as verging on 'obvious' and is certainly the best that can be done
without refactoring the whole thing.
OK fo mainline.
Thanks for
I feel like holding on on this for a few days would make the process
> easier? What do you
> think?
Works for me; I'll keep this local until then.
Grüße
Thomas
> On Sat, 22 Mar 2025 at 15:43, Thomas Schwinge wrote:
>>
>> Hi!
>>
>> On 2025-03-17T16:33:34+
g/liblibformat_parser.a] Error 101
make[3]: Target 'all' not remade because of errors.
make[3]: Leaving directory '[...]/build-gcc/libgrust/libformat_parser'
[...]
With this commit reverted, the build again succeeds, with good test
results. Ma
Hi Jason!
On 2025-03-20T11:52:46-0400, Jason Merrill wrote:
> On 3/19/25 1:35 PM, Thomas Schwinge wrote:
>> On 2013-05-03T16:24:43-0400, Jason Merrill wrote:
>>> Last year Florian fixed the compiler to detect overflow in array new
>>> size calculations and pass (siz
Hi!
On 2025-03-19T14:25:49+, Jonathan Wakely wrote:
> On Wed, 19 Mar 2025 at 14:21, Marek Polacek wrote:
>> On Wed, Mar 19, 2025 at 12:38:31PM +0100, Thomas Schwinge wrote:
>> > In 2001 Subversion r40924 (Git commit
>> > 52a11cbfcf0cfb32628b6953588b6af4037ac0b6
Hi Andre,
Gosh, that's a mighty complicated patch :-) I suggest changing the comment
in the test case:
s/Check that components of procedure pointer aren't freeed./Do not free
procedure pointer components/ or some such.
OK for mainline and, I propose, 14-branch.
Regards and thanks
Paul
On Fri
Hi Jason!
On 2025-03-20T11:59:07-0400, Jason Merrill wrote:
> On 3/20/25 11:35 AM, Thomas Schwinge wrote:
>> Appears that I'm too dumb to implement
>> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101544#c22>:
>>
>> | We "simply" need to tran
row_bad_array_new_length' in
'input file 5 at offset 14095', first defined in 'input file 5 at offset 14095'
nvptx-run: cuLinkAddData failed: device kernel image is invalid
(CUDA_ERROR_INVALID_SOURCE, 300)
How can we improve on "Pretend it returns sizetype"?
utable stack when working in
> OpenCoarrays, but haven't had time (or desire) to look into it. I will put
> myself into CC of the pr Jerry mentioned.
>
> Besides the mentions above, this looks good to me.
>
> Thanks for the patch and
>
> Regards,
> Andre
>
&
In 2001 Subversion r40924 (Git commit 52a11cbfcf0cfb32628b6953588b6af4037ac0b6)
"IA-64 ABI Exception Handling", '__cxa_bad_cast' changed from 'void *' to
'void' return type:
--- libstdc++-v3/libsupc++/exception_support.cc
+++ /dev/null
@@ -1,388 +0,0 @@
-[...]
-// Helpers for r
Hi Andre and Harald,
It looks good to me too.
Indeed, the associate construct is a strange one since TKR guessing is done
at a very early stage so that the associate block can be parsed. About a
year ago, I started looking at tackling this by delaying parsing the blocks
until the containing block
n. This is unnecessry for REDUCE because the
+ wrapper for the OPERATION function takes care of this. */
arg = expr->value.function.actual;
if (result && arg && expr->rank
&& isym && isym->transformational
+ && isym->id != GFC_ISYM_REDUC
Hi Paul,
It looks good to me. Thanks for the patch.
Thanks!
I just added one word, "modular", and committed it.
Best regards
Thomas
Hi Thomas,
It looks good to me. Thanks for the patch.
Regards
Paul
On Sat, 15 Mar 2025 at 15:15, Thomas Koenig wrote:
> Hello world,
>
> the attached patch, tested with "tidy -e", puts the two parts
> mentioning UNSSIGNED into a single paragraph, mentions
> extensi
tomorrow.
Best regards
Thomas
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 7e5da369..1dcef49b 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -182,6 +182,7 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
either add
This was added in commit f553b1aaa2b1b925c918e5dcf966290b045321c2
"Refactor duplicated code into 'gcc/testsuite/lib/gcc-dg.exp:find-dg-do-what'",
for use by 'gcc/testsuite/lib/target-supports.exp'. The latter is used by
several test suites, 'gcc/testsuite/lib/gcc-dg.exp' however doesn't get loaded
one. (..., and
some more fine-tuning is to follow later on.)
Grüße
Thomas
>From cb01ed054f767511102264977ad5b33811c8bec5 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Thu, 20 Feb 2025 16:31:50 +0100
Subject: [PATCH] GCN, nvptx: Allow for "hosted" libstdc++ build
We need &
Hi Harald,
The solution is to use the auxiliary parameter of gfc_traverse_expr
to control whether to descend into character length or not.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks good to me.
Thanks for the patch!
Best regards
Thomas
dule files? Or, in other words, will PR118337 not rear its ugly
head again?
Best regards
Thomas
Hi!
On 2023-12-23T10:17:57+0100, I wrote:
> On 2023-12-21T13:58:23+0100, Jakub Jelinek wrote:
>> On Thu, Dec 21, 2023 at 01:31:19PM +0100, Thomas Schwinge wrote:
>>> OK to push, for a start, the attached
>>> "GCN, nvptx: Basic '__cxa_guard_{acquire,abor
From: Thomas Schwinge
In addition to making libstdc++ itself available, this, via enabling
'build-gcc/*/libstdc++-v3/scripts/testsuite_flags', in particular also makes
the standard C++ headers available to 'make check-gcc-c++'. With that, there
are a lot of FAIL/UNRESOLVED
Am 12.03.25 um 18:33 schrieb Thomas Koenig:
The test case should stay, but I will remove the dg-error directives.
Fix committed as obvious and simple as r15-8006 .
Thanks for the heads-up!
Best regards
Thomas
.
binding_label_tests_26b.f90 has
module f! { dg-error "uses the same global identifier" }
use fg! { dg-error "uses the same global identifier" }
end module
so it tests for that error.
The test case should stay, but I will remove the dg-error directives.
Best regards
Thomas
Hello world,
the attached patch makes sure that procedures from abstract
interfaces and dummy arguments are not put into the global
symbol table, and are not checked against global symbols.
Regression-tested. OK for trunk?
Best regards
Thomas
Abstract interfaces and dummy arguments
Am 11.03.25 um 10:22 schrieb Andre Vehreschild:
Hi Thomas,
looks good to me as well. Thanks for the patch.
Committed as r15-7964.
Thanks Harald and Andre!
Best regards
Thomas
Am 10.03.25 um 22:34 schrieb Harald Anlauf:
the patch looks basically fine but I cannot find the testcase.
You're right, here it is.
Best regards
Thomas
diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc
index 20bf6e127ff..ef9c80147cc 100644
---
Hi Harald,
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks good to me.
Thanks for the patch!
Best regards
Thomas
his down (and sorry for me messing it up in the
first place). I checked your logic and your patch, and both look fine to me.
Best
Thomas
ely clear whether that can happen).
You're right, this is the cleaner solution.
(Actually, none of the cases you mentioned above can happen, at least
not now, but you're right). Patch which does this approved?
Best regards
Thomas
Am 08.03.25 um 20:29 schrieb Steve Kargl:
On Sat, Mar 08, 2025 at 01:52:06PM +0100, Thomas Koenig wrote:
While looking at the code, I also saw that a member of gfc_symbol
introduced with my patch should be a bitfield of width 1.
OK for trunk?
OK (assuming a successful regression test run
.
OK for trunk?
Best regards
Thomas
gcc/fortran/ChangeLog:
PR fortran/119157
* gfortran.h (gfc_symbol): Make ext_dummy_arglist_mismatch a
one-bit bitfield
(gfc_pop_undo_symbol): Declare prototype.
* symbol.cc (gfc_pop_undo_symbol): New function
Hi Jonathan!
On 2025-03-06T19:58:55+, Jonathan Wakely wrote:
> On Thu, 6 Mar 2025 at 19:48, Jonathan Wakely wrote:
>> On Thu, 6 Mar 2025 at 14:28, Thomas Schwinge wrote:
>> > In a '-fno-exceptions' configuration:
>> >
>> > In file include
Hi!
On 2025-02-26T23:08:29+, Jonathan Wakely wrote:
> On Wed, 26 Feb 2025 at 20:53, Thomas Schwinge wrote:
>> On 2025-02-26T10:50:11+, Jonathan Wakely wrote:
>> > On Wed, 26 Feb 2025 at 10:47, Jonathan Wakely wrote:
>> >> On Wed, 26 Feb 2025 at 10:19, Tho
In a '-fno-exceptions' configuration:
In file included from
../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:29:
[...]/build-gcc/[...]/libstdc++-v3/include/format: In function ‘void
std::__throw_format_error(const char*)’:
[...]/build-gcc/[...]/libstdc++-v3/include/format:2
From: Jonathan Wakely
libstdc++-v3/
* src/c++20/tzdb.cc [__GTHREADS && !__GTHREADS_CXX0X]: Use
'__gnu_cxx::__mutex'.
Co-authored-by: Thomas Schwinge
---
libstdc++-v3/src/c++20/tzdb.cc | 12 +++-
1 file changed, 11 insertions(+), 1 deletio
tion in changes.html shortly.
Best regards
Thomas
Hi Andre,
You beat me to it! I had just noticed the missing indirect reference. Yes,
this is good for mainline and backporting to 14-branch at very least.
Thanks for the patch. If you want to do the push to mainline, I will do the
backporting if you like? I'll not be back at base for a little whi
the '[is_remote host]' case, as far as I can
tell, but resolving that shall not be my problem of today. ;-)
And, considering that for GCN/nvptx libstdc++ I also need a way to inject
compiler flags into 'make check-target-libstdc++-v3', and these happen to
overlap with those needed for the libstdc++ build, so the current
'EXTRA_CXX_FLAGS' actually fits that model. ;-)
And for flags that only apply to libstdc++ compilation but not apply to
'make check-target-libstdc++-v3', I may use 'OPTIMIZE_CXXFLAGS'.
Sounds like a plan, I guess? (So, effectively no code changes, but I'll
still propose updates to the documentation.)
Grüße
Thomas
...)?
OK for trunk?
Best regards
Thomas
gcc/fortran/ChangeLog:
PR fortran/119049
PR fortran/119074
* dump-parse-tree.cc (seen_conflict): New static varaible.
(gfc_dump_external_c_prototypes): Initialize it. If it was
set, write out a warning that -std=c23
ases where 'EXTRA_CXX_FLAGS' (as
specified by '--enable-cxx-flags=[...]') apply, and then make that apply
in a uniform way? I think I'd be in favor of removing them from
'testsuite_flags --cxxflags' -- but can't quite tell which use cases
that'd break...
Grüße
Thomas
Hi Andre,
This looks fine to me. You say that this is a regression. How far back does
it go?
OK for mainline and, if required, for backporting.
Thanks for the patch.
Paul
On Fri, 28 Feb 2025 at 15:54, Andre Vehreschild wrote:
> Hi all,
>
> on this regression I had to chew a longer time. Ass
gcc/testsuite/
* gcc.target/nvptx/stack_frame-1.c: New.
---
.../gcc.target/nvptx/stack_frame-1.c | 34 +++
1 file changed, 34 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/nvptx/stack_frame-1.c
diff --git a/gcc/testsuite/gcc.target/nvptx/stack
... instead of 64 via 'gcc/defaults.h':
MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (DImode)
This fixes ICEs:
[-FAIL: c-c++-common/pr111309-1.c -Wc++-compat (internal compiler error:
in expand_fn_using_insn, at internal-fn.cc:268)-]
[-FAIL:-]{+PASS:+} c-c++-common/pr111309-1.c -Wc++-com
As of recent commit 8bf0ee8d62b8a08e808344d31354ab713157e15d
"Fortran: Add transfer_between_remotes [PR107635]", we've got 'alloca' usage
in 'libgfortran/caf/single.c:_gfortran_caf_transfer_between_remotes', and
the libgfortran target library fails to build for legacy configurations where
PTX 'allo
With '-mfake-ptx-alloca' enabled, the user-visible behavior changes only
for configurations where PTX 'alloca' is not available. Rather than a
compile-time 'sorry, unimplemented: dynamic stack allocation not supported'
in presence of dynamic stack allocation, compilation and assembly then
succeeds
This gives the back end a chance to clean out a few more unnecessary instances
of dynamic stack allocation. This progresses:
PASS: gcc.dg/pr78902.c (test for warnings, line 7)
PASS: gcc.dg/pr78902.c (test for warnings, line 8)
PASS: gcc.dg/pr78902.c (test for warnings, line 9)
1 - 100 of 1594 matches
Mail list logo
