Re: [PATCH] libgcc: PR target/116363 Fix SFtype to UDWtype conversion

[Jeff Law]

On 2/22/25 8:10 AM, Jan Dubiec wrote:

This patch fixes SFtype to UDWtype (aka float to unsigned long long)
conversion on targets without DFmode like e.g. H8/300H. It solely relies
on SFtype->UWtype and UWtype->UDWtype conversions/casts. The existing code
in line 2218 (counter = a) assigns/casts a float which is *always* not 
lesser

than Wtype_MAXp1_F to an UWtype int which of course does not have enough
capacity.

2025-02-22  Jan Dubiec  

 PR target/116363

libgcc/ChangeLog:

 * libgcc2.c (__fixunssfDI): Fix SFtype to UDWtype conversion for 
targets

 without LIBGCC2_HAS_DF_MODE defined
Thanks!  Just a note we're in stage4 of our development cycle 
(regression bugfixes) as we prepare for gcc-15.  This doesn't look like 
something we would typically make an exception for, it'll have to wait 
for the next development window.  Meaning it probably won't get any 
attention for a couple months.


Jeff

Re: [PATCH 1/2] Add TARGET_COMPUTE_MULTILIB_OS hook to override multi-lib-os result.

[Jin Ma]

On Fri, 14 Feb 2025 21:03:46 +0800, Jin Ma wrote:
> Create a new hook to let target could override the multi-lib-os result.
> 
> The motivation for this change arises from the fact that using
> TARGET_COMPUTE_MULTILIB to override the original multilib_dir can lead
> to unexpected behavior with multilib_os_dir.
> 
> In our build scripts, we establish a connection between multilib_os_dir
> and multilib_dir. For example, in gcc/config/riscv/t-linux, we set
> multilib_os_dir to be the parent directory of multilib_dir. However,
> when TARGET_COMPUTE_MULTILIB overrides multilib_dir and returns a reused
> result for multilib_dir, multilib_os_dir ends up being identical to
> multilib_dir. This discrepancy is clearly inconsistent with our
> expectations.
> 
> gcc/ChangeLog:
> 
>  * common/common-target.def (compute_multilib_os): New.
>  * common/common-targhooks.cc (default_compute_multilib_os): New.
>  * common/common-targhooks.h (default_compute_multilib_os): New.
>  * doc/tm.texi (TARGET_COMPUTE_MULTILIB_OS): New.
>  * doc/tm.texi.in: Regen.
>  * gcc.cc (set_multilib_dir): Call targetm_common.compute_multilib_os.
> ---
>  gcc/common/common-target.def   | 14 ++
>  gcc/common/common-targhooks.cc |  9 +
>  gcc/common/common-targhooks.h  |  5 +
>  gcc/doc/tm.texi                | 10 ++
>  gcc/doc/tm.texi.in             |  1 +
>  gcc/gcc.cc                     |  4 
>  6 files changed, 43 insertions(+)

Ping again :)

Is there any comment on this patches?

Best regards,
Jin Ma

Ref：
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675786.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675787.html

Gracefully handle the case that 'gcc/testsuite/lib/gcc-dg.exp:find-dg-do-what' has not been called (indirectly) from 'dg-test' (was: Refactor duplicated code into 'gcc/testsuite/lib/gcc-dg.exp:find-dg

[Thomas Schwinge]

Hi!

On 2025-02-22T22:51:36+0100, I wrote:
> On 2025-02-22T22:49:47+0100, I wrote:
>> Pushed to trunk branch commit f553b1aaa2b1b925c918e5dcf966290b045321c2
>> "Refactor duplicated code into 
>> 'gcc/testsuite/lib/gcc-dg.exp:find-dg-do-what'",
>> [...]

> --- a/gcc/testsuite/lib/gcc-dg.exp
> +++ b/gcc/testsuite/lib/gcc-dg.exp

> +# Find the 'dg-do-what' variable living inside DejaGnu's 'dg-test' procedure,
> +# as a local variable.  We start looking at the second-outer frame: this way,
> +# the caller of 'find-dg-do-what' may maintain a local 'dg-do-what' variable
> +# without interfering with this search.
> +proc find-dg-do-what { } {
> +set lookup_level 2
> +while true {
> + upvar $lookup_level dg-do-what dg-do-what
> + if { [info exists dg-do-what] } {
> + verbose "find-dg-do-what: found 'dg-do-what' at level 
> $lookup_level: ${dg-do-what}" 2
> + return ${dg-do-what}
> + }
> + incr lookup_level
> +}
> +}

Pushed to trunk branch commit e8e228acffe382f003a7f2ca37c068a5e0c74df4
"Gracefully handle the case that 'gcc/testsuite/lib/gcc-dg.exp:find-dg-do-what' 
has not been called (indirectly) from 'dg-test'",
see attached, to prepare for another use case.


Grüße
 Thomas


>From e8e228acffe382f003a7f2ca37c068a5e0c74df4 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 21 Feb 2025 21:54:59 +0100
Subject: [PATCH] Gracefully handle the case that
 'gcc/testsuite/lib/gcc-dg.exp:find-dg-do-what' has not been called
 (indirectly) from 'dg-test'

No change in behavior intended.

	gcc/testsuite/
	* lib/gcc-dg.exp (find-dg-do-what): Gracefully handle the case
	that we've not be called (indirectly) from 'dg-test'.
	* lib/target-supports.exp (check_effective_target_stack_size)
	(check_effective_target_alloca): Catch this.
---
 gcc/testsuite/lib/gcc-dg.exp  | 6 +-
 gcc/testsuite/lib/target-supports.exp | 6 ++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 6e9a7b207ab..c0adef6c450 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -1375,8 +1375,9 @@ set dg_runtest_extra_prunes ""
 # the caller of 'find-dg-do-what' may maintain a local 'dg-do-what' variable
 # without interfering with this search.
 proc find-dg-do-what { } {
+set level [info level]
 set lookup_level 2
-while true {
+while { $lookup_level <= $level } {
 	upvar $lookup_level dg-do-what dg-do-what
 	if { [info exists dg-do-what] } {
 	verbose "find-dg-do-what: found 'dg-do-what' at level $lookup_level: ${dg-do-what}" 2
@@ -1384,4 +1385,7 @@ proc find-dg-do-what { } {
 	}
 	incr lookup_level
 }
+# We've not be called (indirectly) from 'dg-test'.
+verbose "find-dg-do-what: have not found 'dg-do-what'" 2
+return [list]
 }
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 7b3172d55b4..4970536bb59 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -653,6 +653,9 @@ proc check_effective_target_stack_size { } {
 # For nvptx target, stack size limits are relevant for execution only.
 if { [istarget nvptx-*-*] } {
 	set dg-do-what [find-dg-do-what]
+	if { ![llength ${dg-do-what}] } {
+	error "unexpected call stack"
+	}
 	if { ![string equal [lindex ${dg-do-what} 0] run] } {
 	return 0
 	}
@@ -1014,6 +1017,9 @@ proc check_effective_target_alloca {} {
 	}
 
 	set dg-do-what [find-dg-do-what]
+	if { ![llength ${dg-do-what}] } {
+		error "unexpected call stack"
+	}
 	if { [string equal [lindex ${dg-do-what} 0] run] } {
 		# For 'dg-do run', it additionally depends on runtime support.
 		# (If not supported, we don't try to demote 'run' to 'link',
-- 
2.34.1

How to retrieve the CCVS/85 User Guide

[James K. Lowden]

On Fri, 21 Feb 2025 19:59:25 +0100
Florian Weimer  wrote:

> * James K. Lowden:
> 
> > As I mentioned in other posts, IMO (IANAL) the copyright in
> > unimportant and probably unenforceable.  The National Computing
> > Centre no longer exists, and the document was also published by NIST
> > which, as part of the US government, does not copyright its
> > publications.
> 
> In the United States.  It is generally assumed that the
> U.S. government can claim copyright on its works abroad.

It may be useful to know the text can be freely retrieved.  If one is patient 
with a recalcitrant system.  My copy is not samizdat.  

Go to: 

https://ntrl.ntis.gov/NTRL/

Under "Date Published" at the left edge of the screen, 

Enter: 1980
as the start date.  You don't want the 1974 version. 

Under "Advanced Search" at the left edge of the screen, 

Enter: CCVS 85
Check: Only documents with full text
Press:  Search

It takes a moment.  Under "Search Results" in the middle of the screen, 

Enter: cobol
to the left of the Filter Results button
Press : Filter Results

In my browser, Accession Number PB93163178 is the 3rd row.  You want the title 
"COBOL Compiler Validation System (CCVS 85), User Guide, Version 4.2".

The "Title/Authors" column looks like dead text, and the "Download" column has 
a PDF button (un)carefully wired not to work.  These are what we call negative 
affordances.  There is a trick, though, even two tricks.  

1.  Simply clicking on the PDF logo usually IME yields a "server not available" 
page.  However, the XHTML logo downloads a page and, if you *immediately* 
follow that by clicking on the PDF, you'll often get the PDF.  

2.  Click on the word "COBOL" in the title.  It's a link.  It brings me to this 
URL:


https://ntrl.ntis.gov/NTRL/dashboard/searchResults/titleDetail/PB93163178.xhtml

That page looks like a library card describing an entry.  It bears this 
abstract: 

"The report is a comprehensive user guide for the COBOL 85 Compiler 
Validation System. It gives a brief description of each test program and 
supplies information on running the tests and interpreting the results. The 
validation system is used to validate COBOL compilers to ensure their 
conformance to the Federal standard as prescribed in Federal Information 
Processing Standards (FIPS) PUB 21-3 and the International Organization for 
Standardization (ISO) Standard 1989:1985. It consists of approximately 300 
COBOL programs, each of which contains several independent tests."

Continuing with our negative affordances, please find beneath the blue bar at 
the top of the page labeled "Details", another word, "Actions", and two little 
icons above the word "Download" in fine print.  You may recognize (what i think 
is) the red Adobe logo representing a PDF, and an XHTML logo.  These are 
buttons that provoke a download of CCVS/85, version 4.2, as PDF and XHTML. As 
on the search page, it is sometimes necessary to awaken the PDF genie by 
downloading the XHTML first.  It's part of the secret handshake, I guess.  

The XHTML is derived from the PDF, because modernity:


http://www.w3.org/1999/xhtml";>







There are other ways to get there, and this way requires patience.  But the 
fact that the document can be retrieved (and that NTRL evidently means it to be 
retrieved) is perhaps worth something.  

--jkl

[committed] libstdc++: Remove redundant cast in floating_from_chars.cc

[Jonathan Wakely]

In r15-7647-g32457bc25fea80 I added a cast and also changed the type of
the variable, making the cast redundant. This removes the cast.

libstdc++-v3/ChangeLog:

* src/c++17/floating_from_chars.cc (__floating_from_chars_hex):
Remove redundant cast.
---

Tested x86_64-linux. Pushed to trunk.

 libstdc++-v3/src/c++17/floating_from_chars.cc | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libstdc++-v3/src/c++17/floating_from_chars.cc 
b/libstdc++-v3/src/c++17/floating_from_chars.cc
index d48f1c0d454..9bad12c7f69 100644
--- a/libstdc++-v3/src/c++17/floating_from_chars.cc
+++ b/libstdc++-v3/src/c++17/floating_from_chars.cc
@@ -1103,8 +1103,7 @@ namespace
// If the leading hexit is not '1', shift MANTISSA to make it so.
// This normalizes input like "4.08p0" into "1.02p2".
const unsigned leading_hexit = mantissa >> mantissa_bits;
-   const int leading_hexit_width
- = __bit_width((unsigned)leading_hexit); // FIXME: optimize?
+   const int leading_hexit_width = __bit_width(leading_hexit); // FIXME: 
optimize?
__glibcxx_assert(leading_hexit_width >= 1 && leading_hexit_width <= 4);
shift_mantissa(leading_hexit_width - 1);
// After this adjustment, we can assume the leading hexit is '1'.
-- 
2.48.1

[committed] libstdc++: Remove misleading comment in __atomic_base

[Jonathan Wakely]

No conversion is needed because the type of _M_i is __int_type anyway.

libstdc++-v3/ChangeLog:

* include/bits/atomic_base.h (__atomic_base<_ITp>): Remove
misleading comment.
---

Tested x86_64-linux. Pushed to trunk.

 libstdc++-v3/include/bits/atomic_base.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libstdc++-v3/include/bits/atomic_base.h 
b/libstdc++-v3/include/bits/atomic_base.h
index b56007b7bf5..92d1269493f 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -355,7 +355,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __atomic_base& operator=(const __atomic_base&) = delete;
   __atomic_base& operator=(const __atomic_base&) volatile = delete;
 
-  // Requires __int_type convertible to _M_i.
   constexpr __atomic_base(__int_type __i) noexcept : _M_i (__i) { }
 
   operator __int_type() const noexcept
-- 
2.48.1

libgomp: Add '__attribute__((unused))' to variables used only in 'assert(...)' (was: [PATCH] libgomp: avoid unused-variable-error when configured with CFLAGS=-DNDEBUG)

[Thomas Schwinge]

Hi!

On 2025-02-17T16:40:05+, "shynur ."  wrote:
>> As part of the Git commit message, please include a ChangeLog update (see
>>  and 'git log').
>
> I've written a new patch which is attached.

Pushed to trunk branch commit e759ff08e2e2e7128db7e6313b4218daa367c74f
"libgomp: Add '__attribute__((unused))' to variables used only in 
'assert(...)'",
see attached.  The only change is that I've added a "libgomp:" prefix to
the title line of the Git commit log.  Thanks!


Grüße
 Thomas


>From e759ff08e2e2e7128db7e6313b4218daa367c74f Mon Sep 17 00:00:00 2001
From: shynur 
Date: Mon, 17 Feb 2025 23:06:58 +0800
Subject: [PATCH] libgomp: Add '__attribute__((unused))' to variables used only
 in 'assert(...)'

Without this attribute, the building process will fail if GCC is configured
with 'CFLAGS=-DNDEBUG'.

libgomp/ChangeLog:

	* oacc-mem.c (acc_unmap_data, goacc_exit_datum_1, find_group_last,
	goacc_enter_data_internal): Add '__attribute__((unused))'.
	* target.c (gomp_unmap_vars_internal): Likewise.
---
 libgomp/oacc-mem.c | 9 +
 libgomp/target.c   | 5 +++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/libgomp/oacc-mem.c b/libgomp/oacc-mem.c
index c75471bc2be..718252b44ba 100644
--- a/libgomp/oacc-mem.c
+++ b/libgomp/oacc-mem.c
@@ -480,7 +480,7 @@ acc_unmap_data (void *h)
   tgt->tgt_end = 0;
   tgt->to_free = NULL;
 
-  bool is_tgt_unmapped = gomp_remove_var (acc_dev, n);
+  bool is_tgt_unmapped __attribute__((unused)) = gomp_remove_var (acc_dev, n);
   assert (is_tgt_unmapped);
 
   gomp_mutex_unlock (&acc_dev->lock);
@@ -743,7 +743,8 @@ goacc_exit_datum_1 (struct gomp_device_descr *acc_dev, void *h, size_t s,
 	if (n->tgt->list[l_i].key
 		&& !n->tgt->list[l_i].is_attach)
 	  ++num_mappings;
-	  bool is_tgt_unmapped = gomp_remove_var (acc_dev, n);
+	  bool is_tgt_unmapped __attribute__((unused))
+	= gomp_remove_var (acc_dev, n);
 	  assert (is_tgt_unmapped || num_mappings > 1);
 	}
 }
@@ -1023,7 +1024,7 @@ static int
 find_group_last (int pos, size_t mapnum, size_t *sizes, unsigned short *kinds)
 {
   unsigned char kind0 = kinds[pos] & 0xff;
-  int first_pos = pos;
+  int first_pos __attribute__((unused)) = pos;
 
   switch (kind0)
 {
@@ -1203,7 +1204,7 @@ goacc_enter_data_internal (struct gomp_device_descr *acc_dev, size_t mapnum,
 	  /* Let 'goacc_map_vars' -> 'gomp_map_vars_internal' handle
 		 this.  */
 	  gomp_mutex_unlock (&acc_dev->lock);
-	  struct target_mem_desc *tgt_
+	  struct target_mem_desc *tgt_ __attribute__((unused))
 		= goacc_map_vars (acc_dev, aq, groupnum, &hostaddrs[i], NULL,
   &sizes[i], &kinds[i], true,
   GOMP_MAP_VARS_ENTER_DATA);
diff --git a/libgomp/target.c b/libgomp/target.c
index 9fc51b160f0..dbc4535b96f 100644
--- a/libgomp/target.c
+++ b/libgomp/target.c
@@ -2092,8 +2092,9 @@ gomp_unmap_vars_internal (struct target_mem_desc *tgt, bool do_copyfrom,
 			tgt->list[i].length);
   if (do_remove)
 	{
-	  struct target_mem_desc *k_tgt = k->tgt;
-	  bool is_tgt_unmapped = gomp_remove_var (devicep, k);
+	  struct target_mem_desc *k_tgt __attribute__((unused)) = k->tgt;
+	  bool is_tgt_unmapped __attribute__((unused))
+	= gomp_remove_var (devicep, k);
 	  /* It would be bad if TGT got unmapped while we're still iterating
 	 over its LIST_COUNT, and also expect to use it in the following
 	 code.  */
-- 
2.34.1

Refactor duplicated code into 'gcc/testsuite/lib/gcc-dg.exp:find-dg-do-what' (was: nvptx: PTX 'alloca' for '-mptx=7.3'+, '-march=sm_52'+ [PR65181])

[Thomas Schwinge]

Hi!

On 2025-01-09T14:21:18+0100, I wrote:
> Pushed to trunk branch commit 3861d362ec7e3c50742fc43833fe9d8674f4070e
> "nvptx: PTX 'alloca' for '-mptx=7.3'+, '-march=sm_52'+ [PR65181]",
> [...]

> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -1009,9 +1009,37 @@ proc check_effective_target_alloca {} {
> [...]
> + # Find 'dg-do-what' in an outer frame.
> + set level 1
> + while true {
> + upvar $level dg-do-what dg-do-what
> + if [info exists dg-do-what] then break
> + incr level
> + }
> + verbose "check_effective_target_alloca: found dg-do-what at level 
> $level" 2
> [...]

Here, I'd duplicated code from 'check_effective_target_stack_size', boo.
Pushed to trunk branch commit f553b1aaa2b1b925c918e5dcf966290b045321c2
"Refactor duplicated code into 'gcc/testsuite/lib/gcc-dg.exp:find-dg-do-what'",
see attached.


Grüße
 Thomas

Refactor duplicated code into 'gcc/testsuite/lib/gcc-dg.exp:find-dg-do-what' (was: nvptx: PTX 'alloca' for '-mptx=7.3'+, '-march=sm_52'+ [PR65181])

[Thomas Schwinge]

Hi!

On 2025-02-22T22:49:47+0100, I wrote:
> On 2025-01-09T14:21:18+0100, I wrote:
>> Pushed to trunk branch commit 3861d362ec7e3c50742fc43833fe9d8674f4070e
>> "nvptx: PTX 'alloca' for '-mptx=7.3'+, '-march=sm_52'+ [PR65181]",
>> [...]
>
>> --- a/gcc/testsuite/lib/target-supports.exp
>> +++ b/gcc/testsuite/lib/target-supports.exp
>> @@ -1009,9 +1009,37 @@ proc check_effective_target_alloca {} {
>> [...]
>> +# Find 'dg-do-what' in an outer frame.
>> +set level 1
>> +while true {
>> +upvar $level dg-do-what dg-do-what
>> +if [info exists dg-do-what] then break
>> +incr level
>> +}
>> +verbose "check_effective_target_alloca: found dg-do-what at level 
>> $level" 2
>> [...]
>
> Here, I'd duplicated code from 'check_effective_target_stack_size', boo.
> Pushed to trunk branch commit f553b1aaa2b1b925c918e5dcf966290b045321c2
> "Refactor duplicated code into 
> 'gcc/testsuite/lib/gcc-dg.exp:find-dg-do-what'",

... now really...

> see attached.


Grüße
 Thomas


>From f553b1aaa2b1b925c918e5dcf966290b045321c2 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 21 Feb 2025 19:42:28 +0100
Subject: [PATCH] Refactor duplicated code into
 'gcc/testsuite/lib/gcc-dg.exp:find-dg-do-what'

No change in behavior intended.

	gcc/testsuite/
	* lib/gcc-dg.exp (proc find-dg-do-what): New.
	* lib/target-supports.exp (check_effective_target_stack_size)
	(check_effective_target_alloca): Use it.
---
 gcc/testsuite/lib/gcc-dg.exp  | 16 
 gcc/testsuite/lib/target-supports.exp | 20 ++--
 2 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 70be7a8d5fd..6e9a7b207ab 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -1369,3 +1369,19 @@ proc gcc-transform-out-of-tree { args } {
 
 set additional_prunes ""
 set dg_runtest_extra_prunes ""
+
+# Find the 'dg-do-what' variable living inside DejaGnu's 'dg-test' procedure,
+# as a local variable.  We start looking at the second-outer frame: this way,
+# the caller of 'find-dg-do-what' may maintain a local 'dg-do-what' variable
+# without interfering with this search.
+proc find-dg-do-what { } {
+set lookup_level 2
+while true {
+	upvar $lookup_level dg-do-what dg-do-what
+	if { [info exists dg-do-what] } {
+	verbose "find-dg-do-what: found 'dg-do-what' at level $lookup_level: ${dg-do-what}" 2
+	return ${dg-do-what}
+	}
+	incr lookup_level
+}
+}
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 7eab76a7eb6..7b3172d55b4 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -652,15 +652,7 @@ proc check_effective_target_trampolines { } {
 proc check_effective_target_stack_size { } {
 # For nvptx target, stack size limits are relevant for execution only.
 if { [istarget nvptx-*-*] } {
-	# Find 'dg-do-what' in an outer frame.
-	set level 1
-	while true {
-	upvar $level dg-do-what dg-do-what
-	if [info exists dg-do-what] then break
-	incr level
-	}
-	verbose "check_effective_target_stack_size: found dg-do-what at level $level" 2
-
+	set dg-do-what [find-dg-do-what]
 	if { ![string equal [lindex ${dg-do-what} 0] run] } {
 	return 0
 	}
@@ -1021,15 +1013,7 @@ proc check_effective_target_alloca {} {
 		return 0
 	}
 
-	# Find 'dg-do-what' in an outer frame.
-	set level 1
-	while true {
-		upvar $level dg-do-what dg-do-what
-		if [info exists dg-do-what] then break
-		incr level
-	}
-	verbose "check_effective_target_alloca: found dg-do-what at level $level" 2
-
+	set dg-do-what [find-dg-do-what]
 	if { [string equal [lindex ${dg-do-what} 0] run] } {
 		# For 'dg-do run', it additionally depends on runtime support.
 		# (If not supported, we don't try to demote 'run' to 'link',
-- 
2.34.1

Re: [Fortran, Patch, PR107635, 4_v1] Fix class type and descriptor handling for new coarray interface [PR107635]

[Harald Anlauf]

Hi Andre,

Am 21.02.25 um 14:35 schrieb Andre Vehreschild:

Hi all,

during testing and compiling some larger coarray codes, I found a few
deficiencies. One was with handling class types when splitting the coarray
expression and the other was that the backend_decl of a formal argument in a
function's symbol was not the same as the one the function was compiled to. So
looking at the function-decl's tree n-th formal argument is the way to go there.

Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?


I am amazed that you do not get lost handling 9-fold nested
macros!  This is OK, as this touches your CAF code.

Otherwise, I'd recommend to add an explaining comment in the
code or code such that mere mortals have a better chance to
follow...

Thanks,
Harald


Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de

Re: [PATCH 1/2] Add TARGET_COMPUTE_MULTILIB_OS hook to override multi-lib-os result.

[Palmer Dabbelt]

On Sat, 22 Feb 2025 02:19:03 PST (-0800), ji...@linux.alibaba.com wrote:

On Fri, 14 Feb 2025 21:03:46 +0800, Jin Ma wrote:

Create a new hook to let target could override the multi-lib-os result.

The motivation for this change arises from the fact that using
TARGET_COMPUTE_MULTILIB to override the original multilib_dir can lead
to unexpected behavior with multilib_os_dir.

In our build scripts, we establish a connection between multilib_os_dir
and multilib_dir. For example, in gcc/config/riscv/t-linux, we set
multilib_os_dir to be the parent directory of multilib_dir. However,
when TARGET_COMPUTE_MULTILIB overrides multilib_dir and returns a reused
result for multilib_dir, multilib_os_dir ends up being identical to
multilib_dir. This discrepancy is clearly inconsistent with our
expectations.

gcc/ChangeLog:

  * common/common-target.def (compute_multilib_os): New.
  * common/common-targhooks.cc (default_compute_multilib_os): New.
  * common/common-targhooks.h (default_compute_multilib_os): New.
  * doc/tm.texi (TARGET_COMPUTE_MULTILIB_OS): New.
  * doc/tm.texi.in: Regen.
  * gcc.cc (set_multilib_dir): Call targetm_common.compute_multilib_os.
---
  gcc/common/common-target.def   | 14 ++
  gcc/common/common-targhooks.cc |  9 +
  gcc/common/common-targhooks.h  |  5 +
  gcc/doc/tm.texi                | 10 ++
  gcc/doc/tm.texi.in             |  1 +
  gcc/gcc.cc                     |  4 
  6 files changed, 43 insertions(+)


Ping again :)

Is there any comment on this patches?


Not yet, I've got them open but I haven't had time to figure out the 
paths yet.  I know we screwed this up the first time and need to do 
something, I'm just not really quite sure what the right answer is yet.




Best regards,
Jin Ma

Ref：
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675786.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675787.html

Re: [Fortran, Patch, PR107635, 4_v1] Fix class type and descriptor handling for new coarray interface [PR107635]

[Andre Vehreschild]

Hi Harald,

thanks for the review. Silently I'd hoped that there is some macro to get
the i-th argument, that I just haven't found and someone could point me to.
I will add a comment, when ko one comes up with the macro by Monday.

Thanks,
Andre
Andre Vehreschild * ve...@gmx.de
Am 22. Februar 2025 15:29:20 schrieb Harald Anlauf :


Hi Andre,

Am 21.02.25 um 14:35 schrieb Andre Vehreschild:

Hi all,

during testing and compiling some larger coarray codes, I found a few
deficiencies. One was with handling class types when splitting the coarray
expression and the other was that the backend_decl of a formal argument in a
function's symbol was not the same as the one the function was compiled to. So
looking at the function-decl's tree n-th formal argument is the way to go
there.

Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?


I am amazed that you do not get lost handling 9-fold nested
macros!  This is OK, as this touches your CAF code.

Otherwise, I'd recommend to add an explaining comment in the
code or code such that mere mortals have a better chance to
follow...

Thanks,
Harald


Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de

Re: The COBOL front end, version 3, now in 14 easy pieces (+NIST)

[Richard Kenner]

Paul Koning wrote:

> >> As I mentioned in other posts, IMO (IANAL) the copyright in
> >> unimportant and probably unenforceable.  The National Computing
> >> Centre no longer exists, and the document was also published by NIST
> >> which, as part of the US government, does not copyright its
> >> publications.
> > 
> > In the United States.  It is generally assumed that the
> > U.S. government can claim copyright on its works abroad.
> 
> Really?  That's puzzling.  It's my understanding that works of the
> United States are, by law, in the public domain.

Yes, but what are "works of the United States"?  17 USC 105 specifically
says that the government "is not precluded from receiving and holding
copyrights transferred to it by assignment".

If a Federal employee creates a work as part of their duties, that
work cannot be copyrighted. But if the government hires a contractor
to create a work and that contractor transfers their copyright of the
work to the government, that work *is* copyrighted by the US.  So the
criteria isn't whether it was created in the US or abroad, but whether
it was created by employees or contractors and, in the latter case,
whether the contractor copyrighted the work or not.

[committed] libstdc++: Fix bootstrap failure with --enable-vtable-verify [PR118981]

[Jonathan Wakely]

The compiler emits code with init_priority(99) for -fvtable-verify=std
and that creates a section conflict with the uses of init_priority(99)
that I recently added to src/c++20/tzdb.cc.

Change tzdb.cc to use a different priority to avoid the conflict.

libstdc++-v3/ChangeLog:

PR c++/118981
* src/c++20/tzdb.cc: Use init_priority(98) instead of
init_priority(99).
---

Tested x86_64-linux, and bootstrapped with --enable-vtable-verify.

Pushed to trunk.

 libstdc++-v3/src/c++20/tzdb.cc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
index c3bb6a12ccc..9cf9eeccc59 100644
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -181,14 +181,14 @@ namespace std::chrono
 
 #pragma GCC diagnostic ignored "-Wprio-ctor-dtor"
 
-  [[gnu::init_priority(99)]]
+  [[gnu::init_priority(98)]]
   constinit tzdb_list tzdb_list::_Node::_S_the_list(nullptr);
 
-  [[gnu::init_priority(99)]]
+  [[gnu::init_priority(98)]]
   constinit tzdb_list::_Node::head_ptr 
tzdb_list::_Node::_S_head_owner{nullptr};
 
 #if USE_ATOMIC_LIST_HEAD
-  [[gnu::init_priority(99)]]
+  [[gnu::init_priority(98)]]
   constinit atomic tzdb_list::_Node::_S_head_cache{nullptr};
 #endif
 
-- 
2.48.1

[committed, obvious] OpenMP: Silence uninitialized variable warning in C++ front end.

[Sandra Loosemore]

There's no actual problem with the code here, just a false-positive
warning emitted by some older GCC versions.

gcc/cp/ChangeLog
* parser.cc (cp_finish_omp_declare_variant): Initialize
append_args_last.
---
 gcc/cp/parser.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 0578aad1b1c..9f619b11167 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -50383,7 +50383,7 @@ cp_finish_omp_declare_variant (cp_parser *parser, 
cp_token *pragma_tok,
   location_t varid_loc = make_location (caret_loc, start_loc, finish_loc);
 
   tree append_args_tree = NULL_TREE;
-  tree append_args_last;
+  tree append_args_last = NULL_TREE;
   vec adjust_args_list = vNULL;
   bool has_match = false, has_adjust_args = false;
   location_t adjust_args_loc = UNKNOWN_LOCATION;
-- 
2.34.1

Re: [PATCH 1/2] Add TARGET_COMPUTE_MULTILIB_OS hook to override multi-lib-os result.

[Jeff Law]

On 2/22/25 7:31 AM, Palmer Dabbelt wrote:

On Sat, 22 Feb 2025 02:19:03 PST (-0800), ji...@linux.alibaba.com wrote:

On Fri, 14 Feb 2025 21:03:46 +0800, Jin Ma wrote:

Create a new hook to let target could override the multi-lib-os result.

The motivation for this change arises from the fact that using
TARGET_COMPUTE_MULTILIB to override the original multilib_dir can lead
to unexpected behavior with multilib_os_dir.

In our build scripts, we establish a connection between multilib_os_dir
and multilib_dir. For example, in gcc/config/riscv/t-linux, we set
multilib_os_dir to be the parent directory of multilib_dir. However,
when TARGET_COMPUTE_MULTILIB overrides multilib_dir and returns a reused
result for multilib_dir, multilib_os_dir ends up being identical to
multilib_dir. This discrepancy is clearly inconsistent with our
expectations.

gcc/ChangeLog:

  * common/common-target.def (compute_multilib_os): New.
  * common/common-targhooks.cc (default_compute_multilib_os): New.
  * common/common-targhooks.h (default_compute_multilib_os): New.
  * doc/tm.texi (TARGET_COMPUTE_MULTILIB_OS): New.
  * doc/tm.texi.in: Regen.
  * gcc.cc (set_multilib_dir): Call targetm_common.compute_multilib_os.
---
  gcc/common/common-target.def   | 14 ++
  gcc/common/common-targhooks.cc |  9 +
  gcc/common/common-targhooks.h  |  5 +
  gcc/doc/tm.texi                | 10 ++
  gcc/doc/tm.texi.in             |  1 +
  gcc/gcc.cc                     |  4 
  6 files changed, 43 insertions(+)


Ping again :)

Is there any comment on this patches?


Not yet, I've got them open but I haven't had time to figure out the 
paths yet.  I know we screwed this up the first time and need to do 
something, I'm just not really quite sure what the right answer is yet.
And I'm deeply concerned about adding another overriding target hook in 
here.  It feels like we're papering over a bigger problem elsewhere, but 
I haven't had the time to really dive in to either articulate my 
concerns more clearly or alleviate them.


jeff

[PATCH] libgcc: PR target/116363 Fix SFtype to UDWtype conversion

[Jan Dubiec]

This patch fixes SFtype to UDWtype (aka float to unsigned long long)
conversion on targets without DFmode like e.g. H8/300H. It solely relies
on SFtype->UWtype and UWtype->UDWtype conversions/casts. The existing code
in line 2218 (counter = a) assigns/casts a float which is *always* not lesser
than Wtype_MAXp1_F to an UWtype int which of course does not have enough
capacity.

2025-02-22  Jan Dubiec  

PR target/116363

libgcc/ChangeLog:

* libgcc2.c (__fixunssfDI): Fix SFtype to UDWtype conversion for targets
without LIBGCC2_HAS_DF_MODE defined libgcc/libgcc2.c | 41 +
 1 file changed, 13 insertions(+), 28 deletions(-)

diff --git a/libgcc/libgcc2.c b/libgcc/libgcc2.c
index 92cb79dc8f8..b1e24927f47 100644
--- a/libgcc/libgcc2.c
+++ b/libgcc/libgcc2.c
@@ -2187,36 +2187,21 @@ __fixunssfDI (SFtype a)
   if (a < 1)
 return 0;
   if (a < Wtype_MAXp1_F)
-return (UWtype)a;
+return (UWtype) a;
   if (a < Wtype_MAXp1_F * Wtype_MAXp1_F)
 {
-  /* Since we know that there are fewer significant bits in the SFmode
-quantity than in a word, we know that we can convert out all the
-significant bits in one step, and thus avoid losing bits.  */
-
-  /* ??? This following loop essentially performs frexpf.  If we could
-use the real libm function, or poke at the actual bits of the fp
-format, it would be significantly faster.  */
-
-  UWtype shift = 0, counter;
-  SFtype msb;
-
-  a /= Wtype_MAXp1_F;
-  for (counter = W_TYPE_SIZE / 2; counter != 0; counter >>= 1)
-   {
- SFtype counterf = (UWtype)1 << counter;
- if (a >= counterf)
-   {
- shift |= counter;
- a /= counterf;
-   }
-   }
-
-  /* Rescale into the range of one word, extract the bits of that
-one word, and shift the result into position.  */
-  a *= Wtype_MAXp1_F;
-  counter = a;
-  return (DWtype)counter << shift;
+  /* We assume that SFtype -> UWtype and UWtype -> UDWtype casts work
+ properly. Obviously, we *cannot* assume that SFtype -> UDWtype
+ works as expected.  */
+  SFtype a_hi, a_lo;
+
+  a_hi = a / Wtype_MAXp1_F;
+  a_lo = a - a_hi * Wtype_MAXp1_F;
+
+  /* A lot of parentheses. This is to make it very clear what is
+ the sequence of operations.  */
+  return ((UDWtype) ((UWtype) a_hi)) << W_TYPE_SIZE
+| (UDWtype) ((UWtype) a_lo);
 }
   return -1;
 #else

[PATCH v1] RISC-V: Fix bug for expand_const_vector interleave [PR118931]

[pan2 . li]

From: Pan Li 

This patch would like to fix one bug when expanding const vector for the
interleave case.  For example, we have:

base1 = 151
step = 121

For vec_series, we will generate vector in format of v[i] = base + i * step.
Then the vec_series will have below result for HImode, and we can find
that the result overflow to the highest 8 bits of HImode.

v1.b = {151, 255, 7,  0, 119,  0, 231,  0, 87,  1, 199,  1, 55,   2, 167,   2}

Aka we expect v1.b should be:

v1.b = {151, 0, 7,  0, 119,  0, 231,  0, 87,  0, 199,  0, 55,   0, 167,   0}

After that it will perform the IOR with v2 for the base2(aka another series).

v2.b =  {0,  17, 0, 33,   0, 49,   0, 65,  0, 81,   0, 97,  0, 113,   0, 129}

Unfortunately, the base1 + i * step1 in HImode may overflow to the high
8 bits, and the high 8 bits will pollute the v2 and result in incorrect
value in const_vector.

This patch would like to perform the overflow to smode check before IOR
the base2 series, and perform the clean highest bit if the const_vector
overflow to smode occurs.  If no overflow, there will do nothing here.

The below test suites are passed for this patch.
* The rv64gcv fully regression test.

PR target/118931

gcc/ChangeLog:

* config/riscv/riscv-v.cc (expand_const_vector): Add overflow to
smode check and clean up highest bits if overflow.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr118931-run-1.c: New test.

Signed-off-by: Pan Li 
---
 gcc/config/riscv/riscv-v.cc   | 31 ++-
 .../riscv/rvv/base/pr118931-run-1.c   | 19 
 2 files changed, 49 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr118931-run-1.c

diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index 7cc15f3d53c..43b54b4184f 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -1504,9 +1504,38 @@ expand_const_vector (rtx target, rtx src)
  && get_vector_mode (new_smode, new_nunits).exists (&new_mode))
{
  rtx tmp1 = gen_reg_rtx (new_mode);
- base1 = gen_int_mode (rtx_to_poly_int64 (base1), new_smode);
+ poly_int64 base1_poly = rtx_to_poly_int64 (base1);
+ base1 = gen_int_mode (base1_poly, new_smode);
  expand_vec_series (tmp1, base1, gen_int_mode (step1, new_smode));
 
+ bool overflow_smode_p = false;
+
+ for (int i = 0; i < XVECLEN (src, 0) / 2; i++)
+   {
+ for (int k = 0; k < NUM_POLY_INT_COEFFS; k++)
+   if (((uint64_t)(base1_poly.coeffs[k] + i * step1.coeffs[k])
+   >> builder.inner_bits_size ()) != 0)
+ overflow_smode_p = true;
+
+ if (overflow_smode_p)
+   break;
+   }
+
+ if (overflow_smode_p)
+   {
+ /* The vec_series base1 may overflow bits to base2 series.  */
+ rtx vec_mask = gen_vec_duplicate (new_mode,
+   CONSTM1_RTX (new_smode));
+ rtx lshift_vec_mask = gen_reg_rtx (new_mode);
+ rtx shift = gen_int_mode (builder.inner_bits_size (), Xmode);
+ rtx lshift_ops[] = {lshift_vec_mask, vec_mask, shift};
+ emit_vlmax_insn (code_for_pred_scalar (LSHIFTRT, new_mode),
+  BINARY_OP, lshift_ops);
+ rtx and_ops[] = {tmp1, tmp1, lshift_vec_mask};
+ emit_vlmax_insn (code_for_pred (AND, new_mode), BINARY_OP,
+ and_ops);
+   }
+
  if (rtx_equal_p (base2, const0_rtx) && known_eq (step2, 0))
/* { 1, 0, 2, 0, ... }.  */
emit_move_insn (result, gen_lowpart (mode, tmp1));
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr118931-run-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr118931-run-1.c
new file mode 100644
index 000..ef866a72039
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr118931-run-1.c
@@ -0,0 +1,19 @@
+/* { dg-do run { target { riscv_v } } } */
+/* { dg-options "-O3 -march=rv64gcv -flto -mrvv-vector-bits=zvl" } */
+
+long long m;
+char f = 151;
+char h = 103;
+unsigned char a = 109;
+
+int main() {
+  for (char l = 0; l < 255 - 241; l += h - 102)
+a *= f;
+
+  m = a;
+
+  if (m != 29)
+__builtin_abort ();
+
+  return 0;
+}
-- 
2.43.0