[PATCH] includes, Darwin: Handle modular use for macOS SDKs [PR116827].

2025-03-23 Thread Iain Sandoe
From: Iain Sandoe 

Tested on x86_64/aarch64 Darwin and x86_64-linux,
OK for trunk?
backports to branches supporting modules?
thanks
Iain

--- 8< ---

Recent changes to the OS SDKs have altered the way in which include guards
are used for a number of headers when C++ modules are enabled.  Instead of
placing the guards in the included header, they are being placed in the
including header.  This breaks the assumptions in the current GCC stddef.h
specifically, that the presence of __PTRDIFF_T and __SIZE_T means that the
relevant defs are already made.  However in the case of the module-enabled
C++ with these SDKs, that is no longer true.

stddef.h has a large body of special-cases already, but it seems that the
only viable solution here is to add a new one specifically for __APPLE__
and modular code.

This fixes around 280 new fails in the modules test-suite; it is needed on
all open branches that support modules.

PR target/116827

gcc/ChangeLog:

* ginclude/stddef.h: Undefine __PTRDIFF_T and __SIZE_T for module-
enabled c++ on Darwin/macOS platforms.

Signed-off-by: Iain Sandoe 
---
 gcc/ginclude/stddef.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/gcc/ginclude/stddef.h b/gcc/ginclude/stddef.h
index 0d53103ce20..bf9c6e609dc 100644
--- a/gcc/ginclude/stddef.h
+++ b/gcc/ginclude/stddef.h
@@ -89,6 +89,17 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
 #undef _PTRDIFF_T_
 #endif
 
+#if defined (__APPLE__)
+# if defined(__has_feature) && __has_feature(modules)
+#  if defined (__need_ptrdiff_t)
+#   undef __PTRDIFF_T
+#  endif
+#  if defined (__need_size_t)
+#   undef __SIZE_T
+#  endif
+# endif
+#endif
+
 /* On VxWorks,  may have defined macros like
_TYPE_size_t which will typedef size_t.  fixincludes patched the
vxTypesBase.h so that this macro is only defined if _GCC_SIZE_T is
-- 
2.39.2 (Apple Git-143)



[committed] d: Fix ICE type variant differs by TYPE_PACKED [PR117621]

2025-03-23 Thread Iain Buclaw
Hi,

r13-1104-gf4c3ce32fa54c1 introduced a regression, which had an
accidental self assignment of TYPE_PACKED when it should have been
assigned to the type's variants. This patch fixes that.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32, committed
to mainline, and backported to releases/gcc-14 and releases/gcc-13.

Regards,
Iain.

---
PR d/117621

gcc/d/ChangeLog:

* types.cc (finish_aggregate_type): Propagate TYPE_PACKED to variants.

gcc/testsuite/ChangeLog:

* gdc.dg/pr117621.d: New test.
---
 gcc/d/types.cc  |  2 +-
 gcc/testsuite/gdc.dg/pr117621.d | 11 +++
 2 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gdc.dg/pr117621.d

diff --git a/gcc/d/types.cc b/gcc/d/types.cc
index 47ef66c2580..98074f1fb68 100644
--- a/gcc/d/types.cc
+++ b/gcc/d/types.cc
@@ -704,7 +704,7 @@ finish_aggregate_type (unsigned structsize, unsigned 
alignsize, tree type)
   TYPE_LANG_SPECIFIC (t) = TYPE_LANG_SPECIFIC (type);
   TYPE_SIZE (t) = TYPE_SIZE (type);
   TYPE_SIZE_UNIT (t) = TYPE_SIZE_UNIT (type);
-  TYPE_PACKED (type) = TYPE_PACKED (type);
+  TYPE_PACKED (t) = TYPE_PACKED (type);
   SET_TYPE_ALIGN (t, TYPE_ALIGN (type));
   TYPE_USER_ALIGN (t) = TYPE_USER_ALIGN (type);
 }
diff --git a/gcc/testsuite/gdc.dg/pr117621.d b/gcc/testsuite/gdc.dg/pr117621.d
new file mode 100644
index 000..f0b96cbff2c
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/pr117621.d
@@ -0,0 +1,11 @@
+// { dg-do "compile" }
+// { dg-options "-g" }
+void pr117621()
+{
+auto fun()(inout int)
+{
+struct S {}
+return inout(S)();
+}
+auto s = fun(0);
+}
-- 
2.43.0



[PATCH] toplevel, Makefile: Add missing CXX_FOR_TARGET export [PR88319].

2025-03-23 Thread Iain Sandoe
Tested on x86_64-Linux, Darwin,
OK for trunk?
backports?
thanks
Iain

--- 8< ---

Actually, the issue is not local to the libitm case, it currently affects
any 'cxx=true' top-level configured target library.

The issue is a missing export of CXX_FOR_TARGET.

PR libitm/88319

ChangeLog:

* Makefile.in: Regenerate.
* Makefile.tpl: Add CXX_FOR_TARGET to NORMAL_TARGET_EXPORTS.

Signed-off-by: Iain Sandoe 
---
 Makefile.in  | 1 +
 Makefile.tpl | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Makefile.in b/Makefile.in
index 87880c62ad2..a5e6e11aece 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -339,6 +339,7 @@ RAW_CXX_TARGET_EXPORTS = \
 
 NORMAL_TARGET_EXPORTS = \
$(BASE_TARGET_EXPORTS) \
+   CXX_FOR_TARGET="$(CXX_FOR_TARGET)"; export CXX_FOR_TARGET; \
CXX="$(CXX_FOR_TARGET) $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CXX;
 
 # Where to find GMP
diff --git a/Makefile.tpl b/Makefile.tpl
index da38dca697a..7dccf91ed8e 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -342,6 +342,7 @@ RAW_CXX_TARGET_EXPORTS = \
 
 NORMAL_TARGET_EXPORTS = \
$(BASE_TARGET_EXPORTS) \
+   CXX_FOR_TARGET="$(CXX_FOR_TARGET)"; export CXX_FOR_TARGET; \
CXX="$(CXX_FOR_TARGET) $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CXX;
 
 # Where to find GMP
-- 
2.39.2 (Apple Git-143)



[patch,avr,applied] Add AVR-SD devices

2025-03-23 Thread Georg-Johann Lay

Added the following 6 AVR-SD devices.

Johann

--

AVR: Add AVR-SD devices.

gcc/
* config/avr/avr-mcus.def: Add AVR32SD20, AVR32SD28, AVR32SD32,
AVR64SD28, AVR64SD32, AVR64SD48.
* doc/avr-mmcu.texi: Rebuild.diff --git a/gcc/config/avr/avr-mcus.def b/gcc/config/avr/avr-mcus.def
index 9f79a9a4579..ad640501541 100644
--- a/gcc/config/avr/avr-mcus.def
+++ b/gcc/config/avr/avr-mcus.def
@@ -326,6 +326,9 @@ AVR_MCU ("avr64du32",ARCH_AVRXMEGA2, AVR_CVT | AVR_ISA_FLMAP, "__AVR_AVR
 AVR_MCU ("avr64ea28",ARCH_AVRXMEGA2, AVR_CVT | AVR_ISA_FLMAP, "__AVR_AVR64EA28__",   0x6800, 0x0, 0x1, 0)
 AVR_MCU ("avr64ea32",ARCH_AVRXMEGA2, AVR_CVT | AVR_ISA_FLMAP, "__AVR_AVR64EA32__",   0x6800, 0x0, 0x1, 0)
 AVR_MCU ("avr64ea48",ARCH_AVRXMEGA2, AVR_CVT | AVR_ISA_FLMAP, "__AVR_AVR64EA48__",   0x6800, 0x0, 0x1, 0)
+AVR_MCU ("avr64sd28",ARCH_AVRXMEGA2, AVR_CVT | AVR_ISA_FLMAP, "__AVR_AVR64SD28__",   0x6000, 0x0, 0x1, 0)
+AVR_MCU ("avr64sd32",ARCH_AVRXMEGA2, AVR_CVT | AVR_ISA_FLMAP, "__AVR_AVR64SD32__",   0x6000, 0x0, 0x1, 0)
+AVR_MCU ("avr64sd48",ARCH_AVRXMEGA2, AVR_CVT | AVR_ISA_FLMAP, "__AVR_AVR64SD48__",   0x6000, 0x0, 0x1, 0)
 /* Xmega, Flash + RAM < 64K, flash visible in RAM address space */
 AVR_MCU ("avrxmega3",ARCH_AVRXMEGA3, AVR_ISA_NONE,NULL,  0x3f00, 0x0, 0x8000, 0)
 AVR_MCU ("attiny202",ARCH_AVRXMEGA3, AVR_CVT | AVR_ISA_RCALL, "__AVR_ATtiny202__",   0x3f80, 0x0, 0x800,  0x8000)
@@ -407,6 +410,9 @@ AVR_MCU ("avr16ea48",ARCH_AVRXMEGA3, AVR_CVT, "__AVR_AVR
 AVR_MCU ("avr32ea28",ARCH_AVRXMEGA3, AVR_CVT, "__AVR_AVR32EA28__",   0x7000, 0x0, 0x8000, 0x8000)
 AVR_MCU ("avr32ea32",ARCH_AVRXMEGA3, AVR_CVT, "__AVR_AVR32EA32__",   0x7000, 0x0, 0x8000, 0x8000)
 AVR_MCU ("avr32ea48",ARCH_AVRXMEGA3, AVR_CVT, "__AVR_AVR32EA48__",   0x7000, 0x0, 0x8000, 0x8000)
+AVR_MCU ("avr32sd20",ARCH_AVRXMEGA3, AVR_CVT, "__AVR_AVR32SD20__",   0x7000, 0x0, 0x8000, 0x8000)
+AVR_MCU ("avr32sd28",ARCH_AVRXMEGA3, AVR_CVT, "__AVR_AVR32SD28__",   0x7000, 0x0, 0x8000, 0x8000)
+AVR_MCU ("avr32sd32",ARCH_AVRXMEGA3, AVR_CVT, "__AVR_AVR32SD32__",   0x7000, 0x0, 0x8000, 0x8000)
 /* Xmega, 64K < Flash <= 128K, RAM <= 64K */
 AVR_MCU ("avrxmega4",ARCH_AVRXMEGA4, AVR_ISA_NONE, NULL,   0x2000, 0x0, 0x11000, 0)
 AVR_MCU ("atxmega64a3",  ARCH_AVRXMEGA4, AVR_ISA_NONE, "__AVR_ATxmega64A3__",  0x2000, 0x0, 0x11000, 0)
diff --git a/gcc/doc/avr-mmcu.texi b/gcc/doc/avr-mmcu.texi
index 18101a8d6c6..feb772549a4 100644
--- a/gcc/doc/avr-mmcu.texi
+++ b/gcc/doc/avr-mmcu.texi
@@ -50,11 +50,11 @@
 
 @item @anchor{avrxmega2}avrxmega2
 ``XMEGA'' devices with more than 8@tie{}KiB and up to 64@tie{}KiB of program memory.
-@*@var{mcu}@tie{}= @code{atxmega8e5}, @code{atxmega16a4}, @code{atxmega16a4u}, @code{atxmega16c4}, @code{atxmega16d4}, @code{atxmega16e5}, @code{atxmega32a4}, @code{atxmega32a4u}, @code{atxmega32c3}, @code{atxmega32c4}, @code{atxmega32d3}, @code{atxmega32d4}, @code{atxmega32e5}, @code{avr64da28}, @code{avr64da32}, @code{avr64da48}, @code{avr64da64}, @code{avr64db28}, @code{avr64db32}, @code{avr64db48}, @code{avr64db64}, @code{avr64dd14}, @code{avr64dd20}, @code{avr64dd28}, @code{avr64dd32}, @code{avr64du28}, @code{avr64du32}, @code{avr64ea28}, @code{avr64ea32}, @code{avr64ea48}.
+@*@var{mcu}@tie{}= @code{atxmega8e5}, @code{atxmega16a4}, @code{atxmega16a4u}, @code{atxmega16c4}, @code{atxmega16d4}, @code{atxmega16e5}, @code{atxmega32a4}, @code{atxmega32a4u}, @code{atxmega32c3}, @code{atxmega32c4}, @code{atxmega32d3}, @code{atxmega32d4}, @code{atxmega32e5}, @code{avr64da28}, @code{avr64da32}, @code{avr64da48}, @code{avr64da64}, @code{avr64db28}, @code{avr64db32}, @code{avr64db48}, @code{avr64db64}, @code{avr64dd14}, @code{avr64dd20}, @code{avr64dd28}, @code{avr64dd32}, @code{avr64du28}, @code{avr64du32}, @code{avr64ea28}, @code{avr64ea32}, @code{avr64ea48}, @code{avr64sd28}, @code{avr64sd32}, @code{avr64sd48}.
 
 @item @anchor{avrxmega3}avrxmega3
 ``XMEGA'' devices with up to 64@tie{}KiB of combined program memory and RAM, and with program memory visible in the RAM address space.
-@*@var{mcu}@tie{}= @code{attiny202}, @code{attiny204}, @code{attiny212}, @code{attiny214}, @code{attiny402}, @code{attiny404}, @code{attiny406}, @code{attiny412}, @code{attiny414}, @code{attiny416}, @code{attiny416auto}, @code{attiny417}, @code{attiny424}, @code{attiny426}, @code{attiny427}, @code{attiny804}, @code{attiny806}, @code{attiny807}, @code{attiny814}, @code{attiny816}, @code{attiny817}, @code{attiny824}, @code{attiny826}, @code{attiny827}, @code{attiny1604}, @code{attiny1606}, @code{attiny1607}, @code{attiny1614}, @code{attiny1616}, @code{attiny1617}, @code{attiny1624}, @code{attiny1626}, @code{attiny1627}, @code{attiny3214}, @code{attiny3216}, 

Re: [PATCH] toplevel, Makefile: Add missing CXX_FOR_TARGET export [PR88319].

2025-03-23 Thread Iain Sandoe
Hi Jeff,

> On 23 Mar 2025, at 14:25, Jeff Law  wrote:
> On 3/23/25 8:03 AM, Iain Sandoe wrote:
>> Tested on x86_64-Linux, Darwin,
>> OK for trunk?
>> backports?
>> thanks
>> Iain
>> --- 8< ---
>> Actually, the issue is not local to the libitm case, it currently affects
>> any 'cxx=true' top-level configured target library.
>> The issue is a missing export of CXX_FOR_TARGET.
>>  PR libitm/88319
>> ChangeLog:
>>  * Makefile.in: Regenerate.
>>  * Makefile.tpl: Add CXX_FOR_TARGET to NORMAL_TARGET_EXPORTS.
> So how does one trigger this failure?   ISTM that every libitm build should 
> be failing.  I think the patch is likely fine, but struggle to see why this 
> hasn't been more widely reported.

take your current build, and then delete /{,mlib}/libitm
then try 
“make ….. all-target-libitm”  .. I believe it will fail with a libtool error 
(because the compiler is not passed - only the options)

That was certainly failing on both x86_64 linux/darwin before the patch.

cheers
Iain



RE: [PATCH] change cbl_field_data_t::etc_t::value from _Float128 to tree

2025-03-23 Thread Robert Dubner
Crossed in the mail.

I applied your fixes below.

The output of the one-liner program is now 1.2345678E+07, as expected.

The .00 instead of .01 problem still exists; source code coming soon.

UAT test failures down to 11 from 23.

NIST failures holding steady at 273.

> -Original Message-
> From: Richard Biener 
> Sent: Friday, March 21, 2025 14:12
> To: Robert Dubner 
> Cc: gcc-patches@gcc.gnu.org; Jakub Jelinek 
> Subject: RE: [PATCH] change cbl_field_data_t::etc_t::value from
_Float128
> to tree
> 
> On Fri, 21 Mar 2025, Robert Dubner wrote:
> 
> > I did what I described to apply the patch copied in this e-mail
> >
> > The results:  You started with two errors in our gcc/cobol/tests, one
> was
> > the 55.5556 problem.  That one is gone.  But another test where a
> > couple of results that should be 0.01 and 0.1 are coming out .00 and
.0
> >
> > You started with 23 errors in our autotest suite; there are still 23
> > errors.  Presumably they are the same errors; I haven't checked.
> >
> > In the NIST tests, you started with 280 errors yesterday.  Today that
is
> > 273.
> >
> > Let's see... at seven tests per day, with 273 left to go
> >
> > This program is failing:
> >
> > IDENTIFICATION DIVISION.
> > PROGRAM-ID. onsize.
> > DATA DIVISION.
> > WORKING-STORAGE SECTION.
> > 01  FLOATLONG  FLOAT-LONG   VALUE
12345678.
> > *>01  FLOATEXT   FLOAT-EXTENDED   VALUE
> 12345678.
> > PROCEDURE   DIVISION.
> > DISPLAY FLOATLONG
> > *>DISPLAY FLOATEXT
> > GOBACK.
> > END PROGRAM onsize.
> >
> > The resulting output is
> >
> > 1.59149684322395424E-314
> >
> > FLOAT-LONG is an IEEE-754 64-bit binary "double".
> >
> > If you instead try just the FLOATEXT variable, the output is zero.
> >
> > If you leave them both in, uncommented, the compiler crashes.
Something
> > to do with a free(), I think, with the initial message "
munmap_chunk():
> > invalid pointer" before the stack trace.
> >
> > I am going to start digging through the patched code, using the
> FLOATLONG
> > example.  This feels to me like a fundamental lack of communication; I
> > sense a gap between assumptions you make automatically from years of
> > intimate understanding of GCC and compilers, and the assumptions I was
> > operating under having started with zero understanding of GCC and
> compiler
> > principles and theory.
> >
> > Since I, at least in principle, have some idea of what I thought I was
> > doing, maybe I can identify something.
> 
> So this is the following hunk where I totally misunderstood
> real_to_target when converting this from native_encode_expr and
> a tree to using REAL_VALUE_TYPE:
> 
> @@ -15702,13 +15714,16 @@ initial_from_float128(cbl_field_t *field,
> _Float128 va
> lue)
>switch( field->data.capacity )
>  {
>  case 4:
> -  *(_Float32 *)retval = (_Float32) value;
> + value = real_value_truncate (TYPE_MODE (FLOAT), value);
> + real_to_target ((long *)retval, &value, TYPE_MODE (FLOAT));
>break;
>  case 8:
> -  *(_Float64 *)retval = (_Float64) value;
> + value = real_value_truncate (TYPE_MODE (DOUBLE), value);
> + real_to_target ((long *)retval, &value, TYPE_MODE (DOUBLE));
>break;
>  case 16:
> -  *(_Float128 *)retval = (_Float128) value;
> + value = real_value_truncate (TYPE_MODE (FLOAT128), value);
> + real_to_target ((long *)retval, &value, TYPE_MODE (FLOAT128));
>break;
> 
> an incremental fix is the following, exposing a native_encode_real
> with REAL_VALUE_TYPE input would be nicer, but going back to
> native_encode_expr works.  So - can you apply the following and
> re-try?  A testcase for the 0.01 vs. 0.0 thing would be nice to have
> as well.
> 
> diff --git a/gcc/cobol/genapi.cc b/gcc/cobol/genapi.cc
> index 382a796ec18..e36952e2f03 100644
> --- a/gcc/cobol/genapi.cc
> +++ b/gcc/cobol/genapi.cc
> @@ -15710,20 +15710,24 @@ initial_from_float128(cbl_field_t *field)
> 
>  case FldFloat:
>{
> +  tree tem;
>retval = (char *)xmalloc(field->data.capacity);
>switch( field->data.capacity )
>  {
>  case 4:
> value = real_value_truncate (TYPE_MODE (FLOAT), value);
> -   real_to_target ((long *)retval, &value, TYPE_MODE (FLOAT));
> +   tem = build_real (FLOAT, value);
> +   native_encode_expr (tem, (unsigned char *)retval, 4, 0);
>break;
>  case 8:
> value = real_value_truncate (TYPE_MODE (DOUBLE), value);
> -   real_to_target ((long *)retval, &value, TYPE_MODE (DOUBLE));
> +   tem = build_real (DOUBLE, value);
> +   native_encode_expr (tem, (unsigned char *)retval, 8, 0);
>break;
>  case 16:
> value = real_value_truncate (TYPE_MODE (FLOAT128), value);
> -   real_to_target ((long *)retval, &va

Re: [PATCH][RFC] [cobol] change cbl_field_data_t::etc_t::value from _Float128 to tree

2025-03-23 Thread Richard Biener
On Fri, 21 Mar 2025, Jakub Jelinek wrote:

> On Fri, Mar 21, 2025 at 08:32:51AM +0100, Richard Biener wrote:
> > > So I really think we should go to mpfr, I can implement it tomorrow unless
> > > Richi wants to do that.
> > 
> > Go to mpfr for the string conversions?  Yeah, maybe that's a good
> > idea.
> 
> Actually, thinking about it some more, perhaps it would be enough to just
> call real_from_decimal with a different precision the second time + adjust
> the string.

So the issue is in binary_initial_from_float128 where formerly

  strfromf128(ach, sizeof(ach), "%.0f", value);

ensured that after value *= get_power_of_ten(rdigits); the result was
rounded to an integer (string).  As I removed the string detour I
forgot to apply such rounding.

The following incremental patch fixes your testcase for me.

I'm going to merge this with the pending patch, I'll also add the
test as one in cobol.dg as well as the other testcase I created myself
when fixing the output formatting side.

Richard.


diff --git a/gcc/cobol/genapi.cc b/gcc/cobol/genapi.cc
index 7f1b78dbf9a..989ccceb42e 100644
--- a/gcc/cobol/genapi.cc
+++ b/gcc/cobol/genapi.cc
@@ -15254,11 +15254,13 @@ binary_initial_from_float128(cbl_field_t *field, 
int rdigits,
   // data.initial member of the incoming field
   char *retval = NULL;
 
-// We need to adjust value so that it has no decimal places
+  // We need to adjust value so that it has no decimal places
   if( rdigits )
 {
   REAL_VALUE_TYPE pow10 = real_powi10 (rdigits);
   real_arithmetic (&value, MULT_EXPR, &value, &pow10);
+  // But make sure to round properly
+  real_round (&value, VOIDmode, &value);
 }
   // We need to make sure that the resulting string will fit into
   // a number with 'digits' digits



[wwwdocs,applied] AVR: Mention more supported devices

2025-03-23 Thread Georg-Johann Lay

Support for the AVR-SD devices (which are 1-liners) has been backported
to v13 and v14.

Johann

--

gcc-13, gcc-14: AVR: Mention more new devices.

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 4860c500..e589e0d6 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -542,6 +542,10 @@ You may also want to check out our
 AVR64DD32, AVR64DU28, AVR64DU32, AVR64EA28, AVR64EA32, AVR64EA48,
 ATA5787, ATA5835, ATA5700M322.
   
+  Support for the following devices has been added in v13.4:
+AVR32SD20, AVR32SD28, AVR32SD32,
+   AVR64SD28, AVR64SD32, AVR64SD48.
+  
 

 IA-32/x86-64
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 8ff84582..d720ab87 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -902,6 +902,10 @@ __asm (".global __flmap_lock"  "\n\t"
 It now constrains the registers R24…R31 as is the case for all
 the other devices.
   
+  Support for the following devices has been added in v14.3:
+AVR32SD20, AVR32SD28, AVR32SD32,
+   AVR64SD28, AVR64SD32, AVR64SD48.
+  
 

 IA-32/x86-64


Re: [PATCH] OpenMP: 'interop' construct - add ME support + target-independent libgomp

2025-03-23 Thread Paul-Antoine Arras

Thanks Sandra and Jakub for your comments.

Here is attached an updated version of the patch:

* Removed special case for n==1, now use an array even when only one 
interop object is passed.

* Updated scan dumps; added C/C++ disjunction where needed.
* Updated the signature of GOMP_interop to actual rather than generic types.
* Renamed 'nowait' argument into 'flags' to allow for future extension.
* Added comments.
* Fixed style and formatting.
--
PAFrom 971aff0b218e6dfc0215d3fd04bfa24aded61532 Mon Sep 17 00:00:00 2001
From: Paul-Antoine Arras 
Date: Thu, 13 Mar 2025 17:16:41 +0100
Subject: [PATCH] OpenMP: 'interop' construct - add ME support +
 target-independent libgomp

This patch partially enables use of the OpenMP interop construct by adding
middle end support, mostly in the omplower pass, and in the target-independent
part of the libgomp runtime. It follows up on previous patches for C, C++ and
Fortran front ends support. The full interop feature requires another patch to
enable foreign runtime support in libgomp plugins.

gcc/ChangeLog:

	* builtin-types.def
	(BT_FN_VOID_INT_INT_PTR_PTR_PTR_INT_PTR_INT_PTR_UINT_PTR): New.
	* gimple-low.cc (lower_stmt): Handle GIMPLE_OMP_INTEROP.
	* gimple-pretty-print.cc (dump_gimple_omp_interop): New function.
	(pp_gimple_stmt_1): Handle GIMPLE_OMP_INTEROP.
	* gimple.cc (gimple_build_omp_interop): New function.
	(gimple_copy): Handle GIMPLE_OMP_INTEROP.
	* gimple.def (GIMPLE_OMP_INTEROP): Define.
	* gimple.h (gimple_build_omp_interop): Declare.
	(gimple_omp_interop_clauses): New function.
	(gimple_omp_interop_clauses_ptr): Likewise.
	(gimple_omp_interop_set_clauses): Likewise.
	(gimple_return_set_retval): Handle GIMPLE_OMP_INTEROP.
	* gimplify.cc (gimplify_scan_omp_clauses): Handle OMP_CLAUSE_INIT,
	OMP_CLAUSE_USE and OMP_CLAUSE_DESTROY.
	(gimplify_omp_interop): New function.
	(gimplify_expr): Replace sorry with call to gimplify_omp_interop.
	* omp-builtins.def (BUILT_IN_GOMP_INTEROP): Define.
	* omp-low.cc (scan_sharing_clauses): Handle OMP_CLAUSE_INIT,
	OMP_CLAUSE_USE and OMP_CLAUSE_DESTROY.
	(scan_omp_1_stmt): Handle GIMPLE_OMP_INTEROP.
	(lower_omp_interop_action_clauses): New function.
	(lower_omp_interop): Likewise.
	(lower_omp_1): Handle GIMPLE_OMP_INTEROP.

gcc/c/ChangeLog:

	* c-parser.cc (c_parser_omp_clause_destroy): Make addressable.
	(c_parser_omp_clause_init): Make addressable.

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_omp_clause_init): Make addressable.

gcc/fortran/ChangeLog:

	* trans-openmp.cc (gfc_trans_omp_clauses): Make OMP_CLAUSE_DESTROY and
	OMP_CLAUSE_INIT addressable.
	* types.def (BT_FN_VOID_INT_INT_PTR_PTR_PTR_INT_PTR_INT_PTR_UINT_PTR):
	New.

include/ChangeLog:

	* gomp-constants.h (GOMP_DEVICE_DEFAULT_OMP_61): Define.
	(GOMP_INTEROP_FLAG_TARGET): Define.
	(GOMP_INTEROP_FLAG_TARGETSYNC): Define.

libgomp/ChangeLog:

	* icv-device.c (omp_set_default_device): Check
	GOMP_DEVICE_DEFAULT_OMP_61.
	* libgomp-plugin.h (struct interop_obj_t): New.
	(enum gomp_interop_flag): New.
	(GOMP_OFFLOAD_interop): Declare.
	(GOMP_OFFLOAD_get_interop_int): Declare.
	(GOMP_OFFLOAD_get_interop_ptr): Declare.
	(GOMP_OFFLOAD_get_interop_str): Declare.
	(GOMP_OFFLOAD_get_interop_type_desc): Declare.
	* libgomp.h (_LIBGOMP_OMP_LOCK_DEFINED): Define.
	(struct gomp_device_descr): Add interop_func, get_interop_int_func,
	get_interop_ptr_func, get_interop_str_func, get_interop_type_desc_func.
	* libgomp.map: Add GOMP_interop.
	* libgomp_g.h (GOMP_interop): Declare.
	* target.c (resolve_device): Handle GOMP_DEVICE_DEFAULT_OMP_61.
	(omp_get_interop_int): Replace stub with actual implementation.
	(omp_get_interop_ptr): Likewise.
	(omp_get_interop_str): Likewise.
	(omp_get_interop_type_desc): Likewise.
	(struct interop_data_t): Define.
	(gomp_interop_internal): New function.
	(GOMP_interop): Likewise.
	(gomp_load_plugin_for_device): Load symbols for get_interop_int,
	get_interop_ptr, get_interop_str and get_interop_type_desc.
	* testsuite/libgomp.c-c++-common/interop-1.c: New test.

gcc/testsuite/ChangeLog:

	* c-c++-common/gomp/interop-1.c: Remove dg-prune-output "sorry".
	* c-c++-common/gomp/interop-2.c: Likewise.
	* c-c++-common/gomp/interop-3.c: Likewise.
	* c-c++-common/gomp/interop-4.c: Remove dg-message "not supported".
	* g++.dg/gomp/interop-5.C: Likewise.
	* gfortran.dg/gomp/interop-4.f90: Likewise.
	* c-c++-common/gomp/interop-5.c: New test.
	* gfortran.dg/gomp/interop-5.f90: New test.

Co-authored-by: Tobias Burnus 
---
 gcc/builtin-types.def |   3 +
 gcc/c/c-parser.cc |   6 +-
 gcc/cp/parser.cc  |   1 +
 gcc/fortran/trans-openmp.cc   |  20 +-
 gcc/fortran/types.def |   3 +
 gcc/gimple-low.cc |   1 +
 gcc/gimple-pretty-print.cc|  23 ++
 gcc/gimple.cc |  18 ++
 gcc/gimple.def|   4 +
 gcc/gimple.h  | 

Re: [PATCH] change cbl_field_data_t::etc_t::value from _Float128 to tree

2025-03-23 Thread Jakub Jelinek
On Sat, Mar 22, 2025 at 11:25:13PM -0500, Robert Dubner wrote:
> Real progress here.  Preliminary report:
> 
> I am still seeing trouble with a PIC PP9 variable coming back .000 instead
> of 0.001.
> 
> In my 679 UAT tests, the failure count is down from 23 to 4
> 
> In the NIST tests, the failure count is down from 273 to 35

Nice.

> It's after midnight, and my daily chores are not done, so I can't really
> look into all of the failures.
> 
> Here's one, though:
> 
> IDENTIFICATION DIVISION.
> PROGRAM-ID.  numeds.
> DATA DIVISION.
> WORKING-STORAGE SECTION.
> 01 VARPP9 PIC PP9 VALUE 0.001.
> 01 VARP9  PIC P9  VALUE 0.01.
> 01 VARV9  PIC V9  VALUE 0.1.
> 01 VAR9   PIC 9   VALUE 1.
> 01 VAR9P  PIC 9P  VALUE 10.
> 01 VAR9PP PIC 9PP VALUE 100.
> PROCEDURE DIVISION.
> DISPLAY "VARPP9 should be .001 is "  VARPP9
> DISPLAY "VARP9  should be .01  is "  VARP9
> DISPLAY "VARV9  should be .1   is "  VARV9
> DISPLAY "VAR9   should be 1is "  VAR9
> DISPLAY "VAR9P  should be 10   is "  VAR9P
> DISPLAY "VAR9PP should be 100  is "  VAR9PP.
> END PROGRAM numeds.
> 
> What I am seeing with your patch is 
> 
> VARPP9 should be .001 is .000
> VARP9  should be .01  is .01
> VARV9  should be .1   is .1
> VAR9   should be 1is 1
> VAR9P  should be 10   is 10
> VAR9PP should be 100  is 100

Ok, here is another incremental patch (so you need Richi's patch
+ my incremental you were testing + this one) for this:

--- gcc/cobol/genapi.cc.jj  2025-03-22 08:21:18.287554771 +0100
+++ gcc/cobol/genapi.cc 2025-03-23 11:38:04.757439095 +0100
@@ -53,6 +53,7 @@
 #include "../../libgcobol/valconv.h"
 #include "show_parse.h"
 #include "fold-const.h"
+#include "realmpfr.h"
 
 extern int yylineno;
 
@@ -15284,22 +15285,36 @@ binary_initial_from_float128(cbl_field_t
 {
   REAL_VALUE_TYPE pow10 = real_powi10 (rdigits);
   real_arithmetic (&value, MULT_EXPR, &value, &pow10);
-  // But make sure to round properly
-  real_roundeven (&value, VOIDmode, &value);
+  real_convert (&value, TYPE_MODE (float128_type_node), &value);
 }
   // We need to make sure that the resulting string will fit into
   // a number with 'digits' digits
-  bool fail = false;
-  FIXED_WIDE_INT(128) i
-= FIXED_WIDE_INT(128)::from (real_to_integer (&value, &fail, 128), SIGNED);
 
   // Keep in mind that pure binary types, like BINARY-CHAR, have no digits
   if( field->data.digits )
 {
-  FIXED_WIDE_INT(128) pow10 = get_power_of_ten (field->data.digits);
-  i = wi::smod_trunc (i, pow10);
+  REAL_VALUE_TYPE pow10 = real_powi10 (field->data.digits);
+  mpfr_t m0, m1;
+
+  mpfr_inits2 (REAL_MODE_FORMAT (TYPE_MODE (float128_type_node))->p,
+  m0, m1, NULL);
+  mpfr_from_real (m0, &value, MPFR_RNDN);
+  mpfr_from_real (m1, &pow10, MPFR_RNDN);
+  mpfr_clear_flags ();
+  mpfr_fmod (m0, m0, m1, MPFR_RNDN);
+  real_from_mpfr (&value, m0,
+ REAL_MODE_FORMAT (TYPE_MODE (float128_type_node)),
+ MPFR_RNDN);
+  real_convert (&value, TYPE_MODE (float128_type_node), &value);
+  mpfr_clears (m0, m1, NULL);
 }
 
+  real_roundeven (&value, TYPE_MODE (float128_type_node), &value);
+
+  bool fail = false;
+  FIXED_WIDE_INT(128) i
+= FIXED_WIDE_INT(128)::from (real_to_integer (&value, &fail, 128), SIGNED);
+
   /* ???  Use native_encode_* below.  */
   retval = (char *)xmalloc(field->data.capacity);
   switch(field->data.capacity)
@@ -15349,13 +15364,26 @@ digits_from_float128(char *retval, cbl_f
 }
   // We need to make sure that the resulting string will fit into
   // a number with 'digits' digits
+  REAL_VALUE_TYPE pow10 = real_powi10 (field->data.digits);
+  mpfr_t m0, m1;
+
+  mpfr_inits2 (FLOAT_MODE_FORMAT (TYPE_MODE (float128_type_node))->p, m0, m1,
+  NULL);
+  mpfr_from_real (m0, &value, MPFR_RNDN);
+  mpfr_from_real (m1, &pow10, MPFR_RNDN);
+  mpfr_clear_flags ();
+  mpfr_fmod (m0, m0, m1, MPFR_RNDN);
+  real_from_mpfr (&value, m0,
+ REAL_MODE_FORMAT (TYPE_MODE (float128_type_node)),
+ MPFR_RNDN);
+  real_convert (&value, TYPE_MODE (float128_type_node), &value);
+  mpfr_clears (m0, m1, NULL);
+  real_roundeven (&value, TYPE_MODE (float128_type_node), &value);
+
   bool fail = false;
   FIXED_WIDE_INT(128) i
 = FIXED_WIDE_INT(128)::from (real_to_integer (&value, &fail, 128), SIGNED);
 
-  FIXED_WIDE_INT(128) pow10 = get_power_of_ten (field->data.digits);
-  i = wi::smod_trunc (i, pow10);
-
   // We convert it to a integer string of digits:
   print_dec (i, ach, SIGNED);
 


Jakub



[PATCH] cobol: Make CXXFLAGS_FOR_TARGET available to the libgcobol build.

2025-03-23 Thread Robert Dubner
I seek benediction.  Failing that, I ask for advice.

This patch makes it possible for me to set the environment variable
'CXXFLAGS_FOR_TARGET="-ggdb -O0"' at configure time, and end up with a
debuggable libgcobol.so.

Is this a correct way to gain that capability?

If not, then how?

If so, then OK for trunk?

Thanks all.

>From c03774e34bde193da7f80eea53b49915e311df0d Mon Sep 17 00:00:00 2001
From: Bob Dubner mailto:rdub...@symas.com
Date: Thu, 20 Mar 2025 23:44:12 -0400
Subject: [PATCH] cobol: Make CXXFLAGS_FOR_TARGET available to the
libgcobol
 build.

By setting "CXXFLAGS_FOR_TARGET=-ggdb -O0", a debuggable version
of libgcobol.so is created.

libgcobol

* Makefile.am: Incorporate AM_CXXFLAGS = $(CXXFLAGS_FOR_TARGET).
* Makefile.in: Regenerated.
---
 libgcobol/Makefile.am | 2 ++
 libgcobol/Makefile.in | 1 +
 2 files changed, 3 insertions(+)

diff --git a/libgcobol/Makefile.am b/libgcobol/Makefile.am
index eddf209807e6..2bd634f30d4c 100644
--- a/libgcobol/Makefile.am
+++ b/libgcobol/Makefile.am
@@ -52,6 +52,8 @@ libgcobol_la_LINK = $(LIBTOOL) --mode=link --tag=CXX
$(CXX)  \
 
 WARN_CFLAGS = -W -Wall -Wwrite-strings
 
+AM_CXXFLAGS =$(CXXFLAGS_FOR_TARGET)
+
 # not defined: DEFS, MAX_ERRORS, LTLDFLAGS
 ALL_CXXFLAGS = -I. -I$(srcdir) $(AM_CPPFLAGS) $(DEFS)  \
$(XCFLAGS) $(AM_CXXFLAGS) $(WARN_CFLAGS) $(MAX_ERRORS)  \
diff --git a/libgcobol/Makefile.in b/libgcobol/Makefile.in
index a6096d2a64aa..6f3ef0750114 100644
--- a/libgcobol/Makefile.in
+++ b/libgcobol/Makefile.in
@@ -425,6 +425,7 @@ libgcobol_la_LINK = $(LIBTOOL) --mode=link --tag=CXX
$(CXX)  \
$(LTLDFLAGS)
 
 WARN_CFLAGS = -W -Wall -Wwrite-strings
+AM_CXXFLAGS = $(CXXFLAGS_FOR_TARGET)
 
 # not defined: DEFS, MAX_ERRORS, LTLDFLAGS
 ALL_CXXFLAGS = -I. -I$(srcdir) $(AM_CPPFLAGS) $(DEFS)  \
-- 
2.34.1



New Croatian PO file for 'gcc' (version 15.1-b20250316)

2025-03-23 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Croatian team of translators.  The file is available at:

https://translationproject.org/latest/gcc/hr.po

(This file, 'gcc-15.1-b20250316.hr.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.




[PATCH] libgcobol: Only use random_r if it is available [PR119295]

2025-03-23 Thread Iain Sandoe
Tested on x86_64 and aarch64 Linux and x86_64 darwin,
OK for trunk?
thanks
Iain

This applies on top of
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/678927.html

--- 8< ---

We do not have a replacement at the moment, so fall back to using
regular random and friends.

PR cobol/119295

libgcobol/ChangeLog:

* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Configure random_r and friends
* intrinsic.cc (__gg__random): Use random_r when available.
(__gg__random_next): Likewise.

Signed-off-by: Iain Sandoe 
---
 libgcobol/config.h.in  |  12 +
 libgcobol/configure| 105 -
 libgcobol/configure.ac |   3 ++
 libgcobol/intrinsic.cc |  25 --
 4 files changed, 138 insertions(+), 7 deletions(-)

diff --git a/libgcobol/config.h.in b/libgcobol/config.h.in
index 14ebaeb2b26..e7e1492b579 100644
--- a/libgcobol/config.h.in
+++ b/libgcobol/config.h.in
@@ -9,6 +9,9 @@
 /* Define if you have the iconv() function and it works. */
 #undef HAVE_ICONV
 
+/* Define to 1 if you have the `initstate_r' function. */
+#undef HAVE_INITSTATE_R
+
 /* Define to 1 if you have the  header file. */
 #undef HAVE_INTTYPES_H
 
@@ -18,6 +21,15 @@
 /* Define to 1 if you have the  header file. */
 #undef HAVE_MEMORY_H
 
+/* Define to 1 if you have the `random_r' function. */
+#undef HAVE_RANDOM_R
+
+/* Define to 1 if you have the `setstate_r' function. */
+#undef HAVE_SETSTATE_R
+
+/* Define to 1 if you have the `srandom_r' function. */
+#undef HAVE_SRANDOM_R
+
 /* Define to 1 if you have the  header file. */
 #undef HAVE_STDINT_H
 
diff --git a/libgcobol/configure b/libgcobol/configure
index ffbfebd96bf..0a6bafe265b 100755
--- a/libgcobol/configure
+++ b/libgcobol/configure
@@ -629,6 +629,7 @@ ac_includes_default="\
 # include 
 #endif"
 
+ac_func_list=
 ac_unique_file="Makefile.am"
 ac_subst_vars='am__EXEEXT_FALSE
 am__EXEEXT_TRUE
@@ -2337,6 +2338,76 @@ rm -f conftest.val
   as_fn_set_status $ac_retval
 
 } # ac_fn_cxx_compute_int
+
+# ac_fn_cxx_check_func LINENO FUNC VAR
+# 
+# Tests whether FUNC exists, setting the cache variable VAR accordingly
+ac_fn_cxx_check_func ()
+{
+  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
+$as_echo_n "checking for $2... " >&6; }
+if eval \${$3+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  if test x$gcc_no_link = xyes; then
+  as_fn_error $? "Link tests are not allowed after GCC_NO_EXECUTABLES." 
"$LINENO" 5
+fi
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+/* Define $2 to an innocuous variant, in case  declares $2.
+   For example, HP-UX 11i  declares gettimeofday.  */
+#define $2 innocuous_$2
+
+/* System header to define __stub macros and hopefully few prototypes,
+which can conflict with char $2 (); below.
+Prefer  to  if __STDC__ is defined, since
+ exists even on freestanding compilers.  */
+
+#ifdef __STDC__
+# include 
+#else
+# include 
+#endif
+
+#undef $2
+
+/* Override any GCC internal prototype to avoid an error.
+   Use char because int might match the return type of a GCC
+   builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char $2 ();
+/* The GNU C library defines this for functions which it implements
+to always fail with ENOSYS.  Some functions are actually named
+something starting with __ and the normal name is an alias.  */
+#if defined __stub_$2 || defined __stub___$2
+choke me
+#endif
+
+int
+main ()
+{
+return $2 ();
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_cxx_try_link "$LINENO"; then :
+  eval "$3=yes"
+else
+  eval "$3=no"
+fi
+rm -f core conftest.err conftest.$ac_objext \
+conftest$ac_exeext conftest.$ac_ext
+fi
+eval ac_res=\$$3
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
+$as_echo "$ac_res" >&6; }
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+
+} # ac_fn_cxx_check_func
 cat >config.log <<_ACEOF
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
@@ -2621,6 +2692,10 @@ $as_echo "$as_me: creating cache $cache_file" >&6;}
   >$cache_file
 fi
 
+as_fn_append ac_func_list " random_r"
+as_fn_append ac_func_list " srandom_r"
+as_fn_append ac_func_list " initstate_r"
+as_fn_append ac_func_list " setstate_r"
 # Check that the precious variables saved in the cache have kept the same
 # value.
 ac_cache_corrupted=false
@@ -11546,7 +11621,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11549 "configure"
+#line 11624 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11652,7 +11727,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#l

RE: [PATCH] change cbl_field_data_t::etc_t::value from _Float128 to tree

2025-03-23 Thread Robert Dubner
Jim is back from a short COBOL-related business trip.  I am going to take
this working collection of patched patched patches and put it up where he
can get at it.

That location is the float_to_tree branch of 

https://gitlab.cobolworx.com/COBOLworx/gcc-cobol.git

And we'll review it. We want to make sure that these changes don't do any
damage that might be hidden because there are no tests for some things
that nonetheless might be visible to us when we look at it.

So, with the understanding that this is still pending internal Jim & Bob
review, I am putting the probable patch here:


>From 111f9b952918aaa3d64ce34ad9d0bb5101d9be49 Mon Sep 17 00:00:00 2001
From: Bob Dubner 
Date: Sun, 23 Mar 2025 20:57:44 -0400
Subject: [PATCH] FloatToTree accumulated patches leading to all tests
passing

This commit will become the basis of the patch to gcc/master
---
 gcc/cobol/gcobolspec.cc |   4 +-
 gcc/cobol/genapi.cc | 293 +---
 gcc/cobol/genapi.h  |   3 -
 gcc/cobol/gengen.cc |   2 +-
 gcc/cobol/genutil.cc|  26 ++--
 gcc/cobol/genutil.h |   2 +-
 gcc/cobol/parse.y   | 149 
 gcc/cobol/symbols.cc|  26 ++--
 gcc/cobol/symbols.h |  39 +++---
 libgcobol/libgcobol.h   |   2 +-
 10 files changed, 335 insertions(+), 211 deletions(-)

diff --git a/gcc/cobol/gcobolspec.cc b/gcc/cobol/gcobolspec.cc
index 4ae8e2cfd9e4..bd4c8f137773 100644
--- a/gcc/cobol/gcobolspec.cc
+++ b/gcc/cobol/gcobolspec.cc
@@ -387,8 +387,8 @@ lang_specific_driver (struct cl_decoded_option
**in_decoded_options,
   case OPT_print_multi_os_directory:
   case OPT_print_multiarch:
   case OPT_print_sysroot_headers_suffix:
-   no_files_error = false;
-   break;
+no_files_error = false;
+break;
 
   case OPT_v:
 no_files_error = false;
diff --git a/gcc/cobol/genapi.cc b/gcc/cobol/genapi.cc
index 8f4f9b213705..e032f3217817 100644
--- a/gcc/cobol/genapi.cc
+++ b/gcc/cobol/genapi.cc
@@ -52,6 +52,8 @@
 #include "../../libgcobol/charmaps.h"
 #include "../../libgcobol/valconv.h"
 #include "show_parse.h"
+#include "fold-const.h"
+#include "realmpfr.h"
 
 extern int yylineno;
 
@@ -1041,7 +1043,9 @@ initialize_variable_internal( cbl_refer_t refer,
   default:
 {
 char ach[128];
-strfromf128(ach, sizeof(ach), "%.16E",
parsed_var->data.value_of());
+real_to_decimal (ach,
+ TREE_REAL_CST_PTR
(parsed_var->data.value_of()),
+ sizeof(ach), 16, 0);
 SHOW_PARSE_TEXT(ach);
 break;
 }
@@ -1296,8 +1300,8 @@ get_binary_value_from_float(tree value,
   gg_assign(fvalue,
 gg_multiply(fvalue,
 gg_float(ftype,
- build_int_cst_type(INT,
-
get_power_of_ten(rdigits);
+ wide_int_to_tree(INT,
+
get_power_of_ten(rdigits);
 
   // And we need to throw away any digits to the left of the leftmost
digits:
   // At least, we need to do so in principl.  I am deferring this problem
until
@@ -4025,11 +4029,7 @@ psa_FldLiteralN(struct cbl_field_t *field )
 field->literal_decl_node = gg_define_variable(DOUBLE, id_string,
vs_static);
 TREE_READONLY(field->literal_decl_node) = 1;
 TREE_CONSTANT(field->literal_decl_node) = 1;
-char ach[128];
-strfromf128(ach, sizeof(ach), "%.36E", field->data.value_of());
-REAL_VALUE_TYPE real;
-real_from_string(&real, ach);
-tree initer = build_real (DOUBLE, real);
+tree initer = fold_convert (DOUBLE, field->data.value_of());
 DECL_INITIAL(field->literal_decl_node) = initer;
 
 }
@@ -4884,26 +4884,66 @@ parser_display_internal(tree file_descriptor,
 // We make use of that here
 
 char ach[128];
-strfromf128(ach, sizeof(ach), "%.33E", refer.field->data.value_of());
-char *p = strchr(ach, 'E');
+real_to_decimal (ach, TREE_REAL_CST_PTR
(refer.field->data.value_of()),
+ sizeof(ach), 33, 0);
+char *p = strchr(ach, 'e');
 if( !p )
   {
   // Probably INF -INF NAN or -NAN, so ach has our result
+  // Except that real_to_decimal prints -0.0 and 0.0 like that with
+  // no e.
+  if( ach[0] == '0' || ( ach[0] == '-' && ach[1] == '0' ))
+__gg__remove_trailing_zeroes(ach);
   }
 else
   {
-  p += 1;
-  int exp = atoi(p);
+  int exp = atoi(p+1);
   if( exp >= 6 || exp <= -5 )
 {
 // We are going to stick with the E notation, so ach has our
result
+// Except that real_to_decimal prints with e notation rather than
E
+// and doesn't guarantee at least two exponent digits.
+*p = 'E';
+if( exp < 0 && exp >= -9 )
+  {
+p[1] = '-';
+p[2] = '0';
+p[3] = '0' - exp;
+p[4] = '\0';
+  }
+else if( exp >= 0 && exp <= 9 )
+  {
+  

[PATCH] OpenMP: Create additional interop objects with append_args.

2025-03-23 Thread Sandra Loosemore
This patch adds support for the case where #pragma omp declare variant
with append_args is used inside a #pragma omp dispatch interop that
specifies fewer interop args than required by the variant; new interop
objects are implicitly created and then destroyed around the call to the
variant, using the GOMP_interop builtin.

gcc/ChangeLog
* gimplify.cc (modify_call_for_omp_dispatch): Adjust arguments.
Remove the "sorry" for the case where new interop objects must be
constructed, and add code to make it work instead.
(expand_variant_call_expr): Adjust arguments and call to
modify_call_for_omp_dispatch.
(gimplify_variant_call_expr): Simplify logic for calling
expand_variant_call_expr.

gcc/testsuite/ChangeLog
* c-c++-common/gomp/append-args-1.c: Adjust expected behavior.
* c-c++-common/gomp/append-args-interop.c: New.
* c-c++-common/gomp/dispatch-11.c: Adjust expected behavior.
* g++.dg/gomp/append-args-1.C: Likewise.
* gfortran.dg/gomp/declare-variant-mod-2.f90: Likewise.

Co-Authored-By: Tobias Burnus 
---
 gcc/gimplify.cc   | 229 +++---
 .../c-c++-common/gomp/append-args-1.c |  14 +-
 .../c-c++-common/gomp/append-args-interop.c   |  44 
 gcc/testsuite/c-c++-common/gomp/dispatch-11.c |   3 -
 gcc/testsuite/g++.dg/gomp/append-args-1.C |  18 +-
 .../gomp/declare-variant-mod-2.f90|   6 -
 6 files changed, 245 insertions(+), 69 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/gomp/append-args-interop.c

diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 354c3d663e7..1ba56149ecc 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -3874,8 +3874,8 @@ find_supercontext (void)
 
 /* OpenMP: Handle the append_args and adjust_args clauses of
declare_variant for EXPR, which is a CALL_EXPR whose CALL_EXPR_FN
-   is the variant, within a dispatch construct with clauses DISPATCH_CLAUSES
-   and location DISPATCH_LOC.
+   is the variant, within a dispatch construct with clauses DISPATCH_CLAUSES.
+   WANT_VALUE and POINTERIZE are as for expand_variant_call_expr.
 
'append_args' causes interop objects are added after the last regular
(nonhidden, nonvariadic) arguments of the variant function.
@@ -3885,7 +3885,7 @@ find_supercontext (void)
address.  */
 static tree
 modify_call_for_omp_dispatch (tree expr, tree dispatch_clauses,
- location_t dispatch_loc)
+ bool want_value, bool pointerize)
 {
   tree fndecl = get_callee_fndecl (expr);
 
@@ -3893,9 +3893,11 @@ modify_call_for_omp_dispatch (tree expr, tree 
dispatch_clauses,
   if (!fndecl)
 return expr;
 
+  tree init_code = NULL_TREE;
+  tree cleanup = NULL_TREE;
+  tree clobbers = NULL_TREE;
   int nargs = call_expr_nargs (expr);
   tree dispatch_device_num = NULL_TREE;
-  tree dispatch_device_num_init = NULL_TREE;
   tree dispatch_interop = NULL_TREE;
   tree dispatch_append_args = NULL_TREE;
   int nfirst_args = 0;
@@ -3956,14 +3958,6 @@ modify_call_for_omp_dispatch (tree expr, tree 
dispatch_clauses,
"the % clause must be present if the % "
"clause has more than one list item");
 }
-  if (dispatch_append_args && nappend != ninterop)
-{
-  sorry_at (EXPR_LOCATION (TREE_PURPOSE (dispatch_append_args)),
-   "% clause not yet supported for %qD, except "
-   "when specifying all %d objects in the % clause "
-   "of the % directive", fndecl, nappend);
-  inform (dispatch_loc, "required by % construct");
-}
   else if (dispatch_append_args)
 {
   tree *buffer = XALLOCAVEC (tree, nargs + nappend);
@@ -3976,11 +3970,153 @@ modify_call_for_omp_dispatch (tree expr, tree 
dispatch_clauses,
  arg = TREE_CHAIN (arg);
  buffer[i] = CALL_EXPR_ARG (expr, i);
}
-  int j = nappend;
+  int j = ninterop;
   for (tree t = dispatch_interop; t; t = TREE_CHAIN (t))
if (OMP_CLAUSE_CODE (t) == OMP_CLAUSE_INTEROP)
  buffer[i + --j] = OMP_CLAUSE_DECL (t);
   gcc_checking_assert (j == 0);
+
+  /* Do we need to create additional interop objects?  */
+  if (ninterop < nappend)
+   {
+ if (dispatch_device_num == NULL_TREE)
+   /* Not remapping device number.  */
+   dispatch_device_num = build_int_cst (integer_type_node,
+GOMP_DEVICE_ICV);
+ int nnew = nappend - ninterop;
+ tree nobjs = build_int_cst (integer_type_node, nnew);
+ tree a, t;
+
+ /* Skip to the append_args clause for the first constructed
+interop argument.  */
+ tree apparg = dispatch_append_args;
+ for (j = 0; j < ninterop; j++)
+   apparg = TREE_CHAIN (apparg);
+
+ /* omp_interop_t *objs[n]; */
+ tree objtype = build_pointer_type (pointer_sized_int_node);
+ t = buil

Re: [PATCH] c++: Don't mix timevar_start and auto_cond_timevar for TV_NAME_LOOKUP [PR116681]

2025-03-23 Thread Jason Merrill

On 3/23/25 1:55 AM, Simon Martin wrote:

Hi,

On Sat Sep 14, 2024 at 10:00 AM CEST, Jason Merrill wrote:

On 9/13/24 1:31 PM, Simon Martin wrote:

We currently ICE upon the following testcase when using -ftime-report

=== cut here ===
template < int> using __conditional_t = int;
template < typename _Iter >
concept random_access_iterator = requires { new _Iter; };
template < typename _Iterator >
struct reverse_iterator {
using iterator_concept =
  __conditional_t< random_access_iterator< _Iterator>>;
};
void RemoveBottom() {
int iter;
for (reverse_iterator< int > iter;;)
;
}
=== cut here ===

The problem is that qualified_namespace_lookup does a plain start() of
the TV_NAME_LOOKUP timer (that asserts that the timer is not already
started). However this timer has already been cond_start()'d in the call
stack - by pushdecl - so the assert fails.

This patch simply ensures that we always conditionally start this timer
(which is done in all other places that use it).


OK, thanks.

Richard B suggested in the ticket to try to backport since that bug can
get in the way of some investigations.

I have checked and the patch applies cleanly on GCC 13 and 14, and tests
are successful for both on x86_64-pc-linux-gnu.

OK for backporting there?


OK.



[PATCH] RISC-V: xtheadmemidx: Split slli.uw pattern

2025-03-23 Thread Bohan Lei
The combine pass can generate an index like (and:DI (mult:DI (reg:DI)
(const_int scale)) (const_int mask)) when XTheadMemIdx is available.
LRA may pull it out, and thus a splitter is needed when Zba is not
available.

A similar splitter were introduced when XTheadMemIdx support was added,
but removed in commit 31c3c5d.  The new splitter in this new patch is
based on the removed one.

gcc/ChangeLog:

* config/riscv/thead.md (*th_memidx_operand): New splitter.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xtheadmemidx-bug.c: New test.
---
 gcc/config/riscv/thead.md | 21 +++
 .../gcc.target/riscv/xtheadmemidx-bug.c   | 13 
 2 files changed, 34 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadmemidx-bug.c

diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md
index d816f3b86dd..20e82e68df2 100644
--- a/gcc/config/riscv/thead.md
+++ b/gcc/config/riscv/thead.md
@@ -458,6 +458,27 @@ (define_insn "*th_mempair_load_zero_extendsidi2"
 
 ;; XTheadMemIdx
 
+;; Help reload to add a displacement for the base register.
+;; In the case `zext(*(uN*))(base+((rN<<1)&0x1fffe))` LRA splits
+;; off two new instructions: a) `new_base = base + disp`, and
+;; b) `index = (rN<<1)&0x1fffe`.  The index calculation has no
+;; corresponding instruction pattern and needs this insn_and_split
+;; to recover.
+
+(define_insn_and_split "*th_memidx_operand"
+  [(set (match_operand:DI 0 "register_operand" "=r")
+   (and:DI (ashift:DI (match_operand:DI 1 "register_operand" "r")
+  (match_operand:QI 2 "imm123_operand" "Ds3"))
+   (match_operand 3 "const_int_operand" "n")))]
+  "TARGET_64BIT && TARGET_XTHEADMEMIDX && (lra_in_progress || reload_completed)
+   && (INTVAL (operands[3]) >> INTVAL (operands[2])) == 0x"
+  "#"
+  "&& !TARGET_ZBA && reload_completed"
+  [(set (match_dup 0) (zero_extend:DI (subreg:SI (match_dup 1) 0)))
+   (set (match_dup 0) (ashift:DI (match_dup 0) (match_dup 2)))]
+  ""
+  [(set_attr "type" "bitmanip")])
+
 (define_insn "*th_memidx_zero_extendqi2"
   [(set (match_operand:SUPERQI 0 "register_operand" "=r,r,r,r,r,r")
(zero_extend:SUPERQI
diff --git a/gcc/testsuite/gcc.target/riscv/xtheadmemidx-bug.c 
b/gcc/testsuite/gcc.target/riscv/xtheadmemidx-bug.c
new file mode 100644
index 000..92b24e311b6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/xtheadmemidx-bug.c
@@ -0,0 +1,13 @@
+/* { dg-do compile { target { rv64 } } } */
+/* { dg-skip-if "" { *-*-* } { "-O0" "-Os" "-Og" "-Oz" } } */
+/* { dg-options "-march=rv64gc_xtheadmemidx" } */
+
+int a;
+int **b;
+
+void
+c ()
+{
+  int **e = &b[(unsigned)(long)&a];
+  __asm__ ("" : "+A"(*e));
+}
-- 
2.46.0



Re: [PATCH] RISC-V: Allow redirecting function calls to the same FMV clone

2025-03-23 Thread Yangyu Chen



> On 24 Mar 2025, at 11:03, Andrew Carlotti  wrote:
> 
> Two brief comments, since I'm on holiday until 31st but happened to notice 
> this
> patch anyway.
> 
> On Mon, Mar 24, 2025 at 02:19:21AM +0800, Yangyu Chen wrote:
>> This behavior does not ensure that if any higher priority callee version
>> were selected at runtime, then a higher priority caller version would have
>> been eligible for selection. But this is hard to solve due to comparing
>> the priority of different versions of the caller may not be meaningful.
> 
> I've discussed this problem with Alfie (added to CC), who is currently working
> on FMV improvements for AArch64 and hoping to clean up the backend/middle end
> interface as well.  I think we agreed that it would be good to add a target
> hook to compare versions,

Actually, we already have a target hook for comparing the priority
of mv clones called: TARGET_COMPARE_VERSION_PRIORITY.

The problem is that if we don’t have the same target list for both
caller and callee, then such optimization might be meaningless.

For example, we know "arch=+v,+zbb", "arch=+v" and "arch=+zbb" can
speed up vector rotation right operations on RISC-V. But "v" does
not imply "zbb" extension. We have a callee for all these targets.
And we have a caller that has only "arch=+v" and "arch=+zbb". Then
running on a CPU with only "v" extension but no Zbb. In this case,
the callee with "arch+v" is the best target for this operation on
this CPU. But "arch=+v,+zbb" might be better for some platforms.
Here are some tradeoffs: if this function call is very frequent,
and zbb is only used for small-sized scalar data epilog, then calling
from PLT rather than inline the "v" version of callee might have
more performance penalty.

My point is that, if it only happens in the same compilation unit,
we should let the developer know this optimization and have the
same target list for both the caller and the callee. Sometimes, a
function call will introduce more performance penalties than using
a default target. And if we don't have this optimization, the callee
cannot be inlined.

I'm still open to hearing some more detailed and effective strategies
for addressing this issue.

> at which point the hard problem can more easily be
> solved for all targets.  I don't know what progress Alfie has made towards 
> this
> so far, but I think we're aiming to get these improvements into GCC 16.
> 
> On which note: I presume this patch is proposed for GCC 16 Stage 1?

Yes.

Thanks,
Yangyu Chen



Re: [patch] make vhdl known to the PPC backend

2025-03-23 Thread Peter Bergner
On 3/20/25 2:51 AM, Richard Biener wrote:
> On Wed, Mar 19, 2025 at 6:39 PM Matthias Klose  wrote:
>>
>> For building ghdl, the compiler needs to be patched to know the "vhdl"
>> language.  Could that patch be applied to the upstream GCC, so that not
>> everybody needs to patch GCC to build ghdl?
> 
> I would suggest, since with LTO all languages are globbed to i == 0, to
> rework the if chain to instead of making it exhaustive with gcc_unreachable 
> (),
> make it fall back to i == 0 for not otherwise handled languages.
> 
> Whatever this code does.

This code is for emitting our traceback table, which is some data in the text
section immediately after the end of the function.  IIRC, on Linux, we default
to emitting an empty traceback table now, so this specific code doesn't really
get used anymore, so I think your suggestion of reworking this to just default
to i = 0 for C and all unknown languages is probably the best solution.
Segher, do you agree?

Peter




Re: [PATCH] RISC-V: Allow redirecting function calls to the same FMV clone

2025-03-23 Thread Andrew Carlotti
Two brief comments, since I'm on holiday until 31st but happened to notice this
patch anyway.

On Mon, Mar 24, 2025 at 02:19:21AM +0800, Yangyu Chen wrote:
> This behavior does not ensure that if any higher priority callee version
> were selected at runtime, then a higher priority caller version would have
> been eligible for selection. But this is hard to solve due to comparing
> the priority of different versions of the caller may not be meaningful.

I've discussed this problem with Alfie (added to CC), who is currently working
on FMV improvements for AArch64 and hoping to clean up the backend/middle end
interface as well.  I think we agreed that it would be good to add a target
hook to compare versions, at which point the hard problem can more easily be
solved for all targets.  I don't know what progress Alfie has made towards this
so far, but I think we're aiming to get these improvements into GCC 16.

On which note: I presume this patch is proposed for GCC 16 Stage 1?