Hi,
on 2024/5/9 06:01, Steve Kargl wrote:
> On Wed, May 08, 2024 at 01:27:53PM +0800, Kewen.Lin wrote:
>>
>> Previously effective target fortran_real_c_float128 never
>> passes on Power regardless of the default 128 long double
>> is ibmlongdouble or ieeelongdouble. It's due to that TF
>> mode
On 27 April 2024 22:02:21 CEST, rep.dot@gmail.com wrote:
>On 27 April 2024 16:11:32 CEST, Jerry D wrote:
>
>>
>>I found these (and several more) patches dated around 2018.
>>
>>https://gcc.gnu.org/git/?p=gcc-old.git;a=commitdiff;h=d38e734485cc84ed0eda7f30b16fb62bdb0cb174
>
>IOPARM_type_char2
On Wed, May 08, 2024 at 01:27:53PM +0800, Kewen.Lin wrote:
>
> Previously effective target fortran_real_c_float128 never
> passes on Power regardless of the default 128 long double
> is ibmlongdouble or ieeelongdouble. It's due to that TF
> mode is always used for kind 16 real, which has
Hi Paul,
this looks mostly good, but the new testcase transfer_class_4.f90
does exhibit a problem with your patch. Run it with valgrind,
or with -fcheck=bounds, or with -fsanitize=address, or add the
following around the final transfer:
print *, storage_size (star_a), storage_size (chr_a),
This fix is straightforward and described by the ChangeLog. Jose Rui
Faustino de Sousa posted the same fix for the ICE on the fortran list
slightly more than three years ago. Thinking that he had commit rights, I
deferred but, regrettably, the patch was never applied. The attached patch
also fixes
On 5/7/24 20:44, Toon Moene wrote:
On 5/7/24 20:35, Andrew Pinski wrote:
On Tue, May 7, 2024 at 11:31 AM Toon Moene wrote:
On 5/7/24 00:02, Toon Moene wrote:
OK, perhaps on the aarch64 I need the following option to make the
comparison fair:
‘rdma’
Enable Round Double Multiply
Hello,
Le 08/05/2024 à 07:27, Kewen.Lin a écrit :
Hi,
Previously effective target fortran_real_c_float128 never
passes on Power regardless of the default 128 long double
is ibmlongdouble or ieeelongdouble. It's due to that TF
mode is always used for kind 16 real, which has precision
127,
