Am 29.07.24 um 11:22 schrieb Jonathan Wakely via Gcc:
> # If a testcase doesn't have special options, use these.
> global DEFAULT_FFLAGS
> if ![info exists DEFAULT_FFLAGS] then {
> set DEFAULT_FFLAGS " -pedantic-errors"
> }
I tried using that, still saw a lot of errors when compiling
C files.
Hi,
for the fortran-unsigned branch, I would like to be able to run all
existing Fortran tests also with -funsigned, to make sure the option
does not break anything on existing code.
Question is: How?
I came as far as
$ make check-fortran RUNTESTFLAGS="--target_board=unix/-funsigned"
but
Hi everybody,
now that a proposal for unsigned number inclusion in Fortran has
passed the J3 hurdle, https://j3-fortran.org/doc/year/24/24-116.txt ,
I thought I would put my working hours where my mouth is and try
my hand at a testbed implementation for gfortran. I am still
grateful to Reinhold
Am 25.06.24 um 21:08 schrieb Arsen Arsenović via Gcc:
Richard Biener writes:
I'd welcome this - care to create a patch for
contrib/gcc-git-customization.sh?
Sure - I've attached a partial patch. I didn't find the hook which runs
on each push to check commits, so the current patch is
Am 18.04.24 um 01:27 schrieb Mark Wielaard:
We also should make sure that all generated files (either in git or in
the release/snapshot tar balls) can be reliably and reproducibly
regenerated. This also helps the (pre-commit) CI buildbots. We already
have the autoregen bots for gcc and
Hi,
is there some sort of concise explanation of how to use the
scripts in contrib/reghunt? There is no real documentation
for what is in the directory, specifically not how to invoke
them, and which directory to invoke them from. I have also
not been able to do run the examples from
Hi Jakub,
It is worse than that, usually the LTO format changes e.g. any time any
option or parameter is added on a release branch (several times a year) and
at other times as well.
Hm, that makes LTO not very well suited for libraries...
Though, admittedly GCC is the single package that
Hi Toon,
During the GNU Tools Cauldron we discussed (at the BoF: IPA & LTO) the
possibility (and hazards) of building the run time libraries for various
compilers with -flto, enabling an -flto -static linking of programs with
the run time library available during link time optimizations.
Am 27.07.23 um 15:43 schrieb Michael Matz:
I've recently submitted a patch that adds some attributes that basically
say "these-and-those regs aren't clobbered by this function" (I did them
for not clobbered xmm8-15). Something similar could be used for the new
GPRs as well. Then it would be a
With the upcoming Intel APX extension, Intel processors will
finally gain 32 general-purpose registers and three-operand
arithmetic, see
https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html
Intel recommends to have the new registers as
Hi Alexandre,
On Apr 6, 2023, Bernhard Reutner-Fischer wrote:
29 For C_BOOL, the internal representation of .TRUE._C_BOOL and
.FALSE._C_BOOL shall be the same as those of
30 the C values (_Bool)1 and (_Bool)0 respectively.
I'm not changing any of the standard types, FWIW. The proposed
Hi FX,
>> The KIND=17 is a bit of a kludge. It is not visible for
>> user programs, they use KIND=16, but this is then translated
>> to library calls as if it was KIND=17 if the IEEE 128-bit floats
>> are selected
>
> Can you check what the IEEE test results are when
-mabi=ieeelongdouble is
Hi Steve,
On Thu, Jun 08, 2023 at 12:17:02PM +0200, Thomas Koenig wrote:
[...]
Thanks for the explanation. As I likely will not use a POWER-based
system, I only loosely followed the discussion. I don't remember
if ibm double-double is REAL(16) or REAL(17). If ieee 128-bit is
REAL(16),
Hi FX,
Having a POWER system isn't enough, it also needs the IBM "advance
toolchain", and (at least with current distros, which default to
ibm long double), you need to dance counterclockwise three
times... I mean you need to invoke configure with some special magic
Thanks for the frank
Hi together,
On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
Hi,
I cannot see if there is proper support for kind=17 in your patch;
at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
seem to have any related code.
Can real(kind=17) ever be an IEEE mode? If so, something
Hi Paul,
I want to get something approaching correct finalization to the
distros, which implies 12-branch at present. Hopefully I can do the
same with associate in a month or two's time.
OK by me then.
(I just wanted to be sure that we had this discussion :-)
Best regards
Thomas
Hi Paul,
I propose to backport
r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very
soon.
Is this something that we usually do?
While finalization was basically broken before, some people still used
working subsets (or subsets that were broken, and they adapted or
wrote their
Hi Lipeng,
May I know any comment or concern on this patch, thanks for your time
Thanks for your patience in getting this reviewed.
A few remarks / questions.
Which strategy is used in this implementation, read-preferring or
write-preferring? And if read-preferring is used, is there
a
On 14.05.23 14:27, Mikael Morin wrote:
(...)
@@ -2098,7 +2098,7 @@ ref_same_as_full_array (gfc_ref *full_ref,
gfc_ref *ref)
there is some kind of overlap.
0 : array references are identical or not overlapping. */
-int
+bool
gfc_dep_resolver (gfc_ref *lref, gfc_ref *rref,
Hi,
I'm not sure who on this mailing list reads comp.compilers, but there is
an interesting article about built-in regression search in the go
compiler at https://compilers.iecc.com/comparch/article/23-05-003 .
Using a similar approach could also be interesting for gcc,
complementing tools like
On 13.05.23 02:45, Po Lu via Gcc wrote:
Gabriel Ravier writes:
...You're joking, right ? You can't possibly be seriously arguing
this, you have to be kidding... right ?
No, I'm not. The meaning of a variable declaration with only a storage
class specifier is extremely clear: the type of
On 12.05.23 09:53, Eli Zaretskii via Gcc wrote:
I described in an earlier message how this breakage looks in real
life, and why it causes a lot of frustration. The main problem is
discovering that things broke because GCC defaults, and then
discovering how to pacify GCC with the least effort.
On 10.05.23 21:29, Bernhard Reutner-Fischer via Fortran wrote:
On Mon, 27 Jun 2022 14:10:36 +0800
Xi Ruoyao wrote:
fgrep has been deprecated in favor of grep -F for a long time, and the
next grep release (3.8 or 4.0) will print a warning of fgrep is used.
Stop using fgrep so we won't see the
On 10.05.23 14:03, Jakub Jelinek via Gcc wrote:
We do such changes several times a year, where we reject something that has
been previously accepted in older standards, admittedly mostly in C++.
... and in Fortran.
Not replying to anybody in particular, just a bit of history, with
some potential parallels.
In gfortran, we have had two major issues with interfaces. One was that
code which had happily violated the compiler ABI started failing, due
to a fix in the gfortran front end which meant that we were
Hi Steve,
Hi Andrew,
"long long". This was just an oversight and a missing check.
Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
Thanks!
I think this one is obvious enough that it deserves a backport.
I've cherry-picked this for gcc12, will do gcc11 tomorrow.
The
Hi Andrew,
"long long". This was just an oversight and a missing check.
Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
Thanks!
I think this one is obvious enough that it deserves a backport.
I've cherry-picked this for gcc12, will do gcc11 tomorrow.
Best regards
On 26.03.23 08:52, Paul Richard Thomas via Fortran wrote:
If you will excuse the British cultural reference, that's a Norwegian Blue
alright! Good spot.
Still pining for the fjords, I gather?
I wrote:
Yes, that's fine for trunk. I wonder if it is worth being explicit that
linear congruential pseudo-random number generators can and do fail at
-O3?
I don't think we should put this into the docs, because that can change
at any time. Maybe into porting_to.html, though (where I
Hi Paul,
Yes, that's fine for trunk. I wonder if it is worth being explicit that
linear congruential pseudo-random number generators can and do fail at -O3?
I don't think we should put this into the docs, because that can change
at any time. Maybe into porting_to.html, though (where I have
Here's also an update on the docs to explicitly mention behavior
on overflow.
Maybe this will reach another 0.05% of users...
OK for trunk?
Best regards
Thomas
gcc/fortran/ChangeLog:
* gfortran.texi: Mention behavior on overflow.
diff --git a/gcc/fortran/gfortran.texi
Hi,
the sentence below seems a bit short for such a huge undertaking,
but I could not think of anything else to day.
Tested with "tidy -e".
OK for wwwdocs?
Best regards
Thomas
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index c8d757b6..a4b71ffa 100644
---
Hi Harald,
Am 18.03.23 um 19:52 schrieb Thomas Koenig via Gcc-patches:
Hi Harald,
the Fortran standard requires an explicit procedure interface in certain
situations, such as when they have a BIND(C) attribute (F2018:15.4.2.2).
The attached patch adds a check for this.
Regtested on x86_64
Hi Harald,
the Fortran standard requires an explicit procedure interface in certain
situations, such as when they have a BIND(C) attribute (F2018:15.4.2.2).
The attached patch adds a check for this.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
While this fixes the ICE, it misses
Hi,
Text says it all. OK for web pages?
Best regards
Thomas
Mention issues with integer owerflow for random number generators.
This mentions the issues with integer overflow and how to work
around them.
diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html
index
Hi Richard,
Since this appeared only in gcc13, I see no need for a backport.
I will also document this in the changes file.
The „problem“
It's a real problem, I am afraid...
is latent forever, I’m not sure it’s good to amend the kitchen-sink >std=legacy
option with -fwrapv since that has
Hello world, here's the patch that was discussed.
Regression-tested. OK for trunk?
Since this appeared only in gcc13, I see no need for a backport.
I will also document this in the changes file.
Best regards
Thomas
Set -frapv if -std=legacy is set.
Fortran legacy codes sometimes
Paul,
first of all, thank you very much indeed for the hard work you put into
this! This is a great step for gfortran.
I can hurry this along to get the patch
into 13-branch or I can wait until 14-branch opens.
Personally, I think that this fixes so many bugs, and makes
the compiler so much
Hi Jerry,
I should have clarified in my posts that the warnings are on the use of
sstride[0], mstride[0] or both.
In a sense it is a
regression. It showed up when builds started to use -Wmaybe-unitialized.
I think this is OK for trunk now, and backport for up to whenever
Hi Harald,
the attached patch fixes an ICE on invalid (non-integer)
specification expressions for character length in function
declarations. It appears that the error handling was
already in place (mostly) and we need to essentially
prevent run-on errors.
Regtested on x86_64-pc-linux-gnu. OK
On 30.01.23 23:07, Gerald Pfeifer wrote:
Hmm, so any digit, parenthesis, or bracket in the Subject, and mails gets
to /dev/null?
Sending mail with special graphics in Subject lines is what spammers do,
to attract special attention. (And no, umlauts are not included :-).
So, If I ever happen
On 30.01.23 14:52, Mark Wielaard wrote:
Hi Steve,
On Sun, 2023-01-29 at 22:27 -0800, Steve Kargl via Gcc wrote:
Please remove the skull and cross bones in the subject line.
That is the default "hazard symbol" buildbot uses if a build turns from
success to failure. If you have a better
Hi Harald,
the code in the PR demonstrates that dependency checking in the
frontend optimization was not recovering well from invalid code,
leading to a NULL pointer dereference. An easy and really obvious
fix.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Yes indeed (and I would not
Hi Thomas,
On 2023-01-20T22:04:02+0100, I wrote:
We've been (t)asked to enable (portions of) GCC/Fortran I/O for nvptx
offloading, which means building a normal (non-'LIBGFOR_MINIMAL')
configuration of libgfortran.
This is achieved by 'nvptx, libgfortran: Switch out of "minimal" mode',
see
Hi Richard,
There is no reliable way to get this correct at the moment and if there
were good and easy ways to get this working they'd be implemented already.
OK, I then withdraw the patch (and have unassigned myself from the PR).
Best regards
Thomas
On 09.01.23 12:35, Stefan Kanthak wrote:
20 superfluous instructions of the total 102 instructions!
The proper place for bug reports is https://gcc.gnu.org/bugzilla/ .
Feel free to submit these cases there.
Hi Richard,
Am 08.01.2023 um 14:31 schrieb Paul Richard Thomas via Fortran
:
Hi Thomas,
Following your off-line explanation that the seemingly empty looking
assembly line forces an effective reload from memory, all is now clear.
It’s not a full fix (for register vars) and it’s ‚superior‘
Hello world,
this patch fixes Fortran's handling of common subexpression elimination
across ieee_set_rouding_mode calls. It does so using a rather big
hammer, by issuing a memory barrier to force reload from memory
(and thus a recomputation).
This is a rather big hammer, so if there are more
Hi Lipeng,
This patch try to introduce the rwlock and split the read/write to
unit_root tree and unit_cache with rwlock instead of the mutex to
increase CPU efficiency. In the get_gfc_unit function, the percentage
to step into the insert_unit function is around 30%, in most instances,
we can
On 17.12.22 01:26, NightStrike wrote:
On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig wrote:
On 16.12.22 03:20, NightStrike via Fortran wrote:
When I run the testsuite under wine, I'm getting a lot of ANSI escape
sequences. We had fixed this long ago, but it seems to be back. Any
idea what
Hi Harald,
please find attached an obvious patch by Steve for a technical
regression that resulted from improvements in error recovery
of bad uses of associate.
Regtested on x86_64-pc-linux-gnu.
Will commit soon unless there are comments.
Obvious enough, I think. Thanks!
As a sidenote:
Hi,
following Mikael's recent patch series, here is a first idea
of what extending clobbering to arrays wold look like.
The attached patch works for a subset of cases, for example
program main
implicit none
interface
subroutine foo(a)
integer, intent(out) :: a(*)
end
Hello Harald,
the patch for this PR was submitted for review by Jose here:
https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html
but unfortunately was never reviewed.
I verified that it works on mainline and x86_64-pc-linux-gnu,
and I think that it is fine.
Although the above mail
Hi Harald,
I think I understand much of what is said, but I feel that I do
not really understand what *clobber* means for the different
beasts we are discussing (although I have an impression of what
it means for a scalar object).
Obviously, "clobber" means taking a big stick and hitting
On 19.09.22 22:50, Mikael Morin wrote:
Le 19/09/2022 à 21:46, Harald Anlauf a écrit :
Am 18.09.22 um 22:55 schrieb Mikael Morin:
Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
Assumed shape will be on the easy side,
while assumed size likely needs to be excluded for clobbering.
Isn’t it
On 18.09.22 11:10, Mikael Morin wrote:
Le 18/09/2022 à 08:12, Richard Biener a écrit :
On Sat, Sep 17, 2022 at 9:33 PM Mikael Morin
wrote:
Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit :
I have a concern about this part, though. My understanding at the
time was that it is not
Hi Mikael,
This adds support for clobbering of partial variable references, when
they are passed as actual argument and the associated dummy has the
INTENT(OUT) attribute.
Support includes array elements, derived type component references,
and complex real or imaginary parts.
This is done by
Hi FX,
Maybe the ping is a bit early, as you know I’m not very active anymore, so I do
not know what are the current policies. In particular, how much leeway do I
have to commit the patch if there is no comment from another maintainer?
I am fairly confident about the code, because I wrote
Hi Jakub,
The following patch makes use of the new __builtin_issignaling,
so it no longer needs the fallback implementation and can use
the builtin even where glibc provides the macro.
Bootstrapped/regtested on x86_64-linux, i686-linux, powerpc64le-linux
and powerpc64le-linux, ok for trunk?
Hi Jakub,
The boz_15.f90 test FAILs on powerpc64le-linux when -mabi=ieeelongdouble
is used (either default through --with-long-double-format=ieee or
when used explicitly).
The problem is that the read/write transfer routines are called with
BT_REAL (or BT_COMPLEX) type and kind 17 which is
Hi Harald,
This introduces the helper function gfc_match_next_char, which is
your second option.
I would be a little bit concerned about compilation times
with the additional function call overhead.
The function is used only in one place; would it make
sense to put it into primary.cc and
Hi Cynthia,
> Hello, my name is Cynthia and I am a Supply Chain Risk Management
> Analyst at NASA. NASA is currently conducting a supply chain
> assessment of gfortran. As stated in Sections 208 and 514 of the
> Consolidated Appropriations Act, 2022, Public Law 117-103,
> enacted March 15,
Hi Mikael,
Feel free to comment, do we need this?
Thanks for taking this on.
One thought: If we have to bite the bullet and break the ABI, why not go
all the way and use the C descriptors in ISO_Fortran_binding.h as
gfortran's native format?
Best regards
Thomas
Hello Harald,
compile time simplification of INDEX(str1,str2,back=.true.) gave wrong
results. Looking at gfc_simplify_index, this appeared to be close to
a complete mess, while the runtime library code - which was developed
later - was a relief.
The solution is to use the runtime library code
Hello Harald,
after simplification of constant bound expressions of an explicit
shape spec of an array, we need to ensure that we never obtain
negative extents. In some cases this did happen, and we ICEd
as we hit an assert that this should never happen...
The original testcase by Gerhard
Hi,
On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote:
- if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i debian'
>/dev/null 2>&1; then \
+ if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v -i debian'
>/dev/null 2>&1; then \
Hi Harald,
we need to check the POS (and LEN) arguments of bit intrinsics
when simplifying, e.g. when used in array constructors.
Otherwise we ICE. Found by Gerhard.
The fix is straightforward, see attached.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
OK.
Thanks for the patch!
Hi,
I just pushed the attached patch to update the mail links and dates for
GCC 12 and GCC 13, as simple and obvious.
Regards
Thomasdiff --git a/htdocs/index.html b/htdocs/index.html
index 199181b1..e1bb584e 100644
--- a/htdocs/index.html
+++ b/htdocs/index.html
@@ -172,7 +172,7 @@
Hi,
after noticing an error in the gcc12 changes.html file, I fixed it as
obvious and simple with the attached patch.
Best regards
Thomas
Sun May 1 00:05:10 2022 +0200
Added equals sign to fix broken link in RISC-V section.
* gcc-12/changes.html: Fixed broken link.
Hi Mikael,
OK in any case. Anything is better than nothing.
Here is what I committed, with one final tweak.
Thanks!
Best regards
Thomas
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -501,6 +501,15 @@ function Multiply (S1, S2 : Sign) return Sign is
the attached patch documents the support for IEEE long double for
Fortran. OK? Suggestions for better wording?
I'd like to get this in before the gcc12 release. It would also
qualify as obviously correct, I think :-) so I'll commit this
on Sunday unless there are any objections.
Patch at
On 28.04.22 19:17, Bernhard Reutner-Fischer wrote:
ISTM that this should be s/mod.e/mode./ ?
Yep, fixed as obvious and simple on trunk with
r13-49-g4a8b45e8bc8246bd141dad65f571a3e0cc499c6b .
OK for backport to gcc-12? (This is both extremely safe and
not particularly important :-)
Best
Hi,
the attached patch documents the support for IEEE long double for
Fortran. OK? Suggestions for better wording?
Best regards
Thomas
Mention support for IEEE 128-bit long double for Fortran.
* htdocs/gcc-12/changes.html: Mention support for IEEE
128-bit long
Hi,
as we say in German "Nicht documentiert ist nicht gemacht", if
it is not documented, it wasn't done.
So I thought it would be time to document the changes to the various
ways of specifying CONVERT before gcc12 went out of the door, so
here is a patch for that.
If that goes in, I will also
On 26.04.22 16:40, Hans-Peter Nilsson wrote:
These, or specifically r12-8227-g89ca0fffa48b79, "fortran:
Pre-evaluate string pointers. [PR102043]" have further
exposed (the issue existed before but now fails for more
platforms) PR78054 "gfortran.dg/pr70673.f90 FAILs at -O0",
at least for
Hi Mikael,
this fixes a regression caused by my recent PR103662 patch.
Regression tested on x86_64-pc-linux-gnu. OK for master?
OK. Good to see that a bit of optimization can also sneak in with
a bug fix :-)
Best regards
Thomas
Hi Mikael,
Ping for the four patches starting at
https://gcc.gnu.org/pipermail/fortran/2022-April/057759.html :
https://gcc.gnu.org/pipermail/fortran/2022-April/057757.html
https://gcc.gnu.org/pipermail/fortran/2022-April/057760.html
Hi Harald,
Regtested again with no new failures. OK for mainline?
Looks good to me. Thanks for the patch!
Best regards
Thomas
Hi Harald,
Steve's analysis (see PR) showed that we confused the case when a
symbol refererred to a recursive procedure which was named the same
as an intrinsic. The standard allows such recursive references
(see e.g. F2018:19.3.1).
The attached patch is based on Steve's, but handles both
On 25.03.22 12:34, Jakub Jelinek via Fortran wrote:
What is the behavior with a RANGE_EXPR when one has { [0..10] = ++i;
}, is that applying the side-effects 11 times or once ?
For side effects during the evaluation of expression, Fortran has a
clear "if you depend on it, it's your fault"
Hi Harald,
a recently introduced shape validation for an array constructor
against the declared shape of a DT component failed to punt if
the shape of the constructor cannot be determined at compile time.
Suggested solution: skip the shape check in those cases.
Regtested on
Hi Harald,
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks good to me. Thanks for the patch!
Best regards
Thomas
Hi Harald,
when referencing a bad array section after an erroneous previous
declaration we might hit an assert. The assert can be replaced
by a more gracious error recovery. Reported by Gerhard.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
OK.
Thanks for the patch!
Best regards
On 24.01.22 15:23, FX via Fortran wrote:
Then it’s OK to commit for me, but you will need approval from release managers
at this stage.
Hum… I submitted it before stage 4 started, does that count?
Yes, it does.
(There is also some leeway granted to non-release-critical languages
like
Hello Harald,
when simplifying TRANSFER with a MOLD argument of type character
and with SIZE=0 we lose the character length.
This happens in all gfortran versions and results in wrong code.
The purported regression is that at some point in the 9-development
this lead to a (previously possibly
Hi Jakub,
This patch on top of the previously posted option handling changes patch
allows specifying -fconvert=swap,r16_ieee etc. (but will error on it
when not on powerpc64le because in the library such swapping is only
implemented for HAVE_REAL_17).
Bootstrapped/regtested on x86_64-linux
Hi Sandra,
This patch is for PR103695, marked as a P1 regression. OK to check in?
I'm not an OpenMP expert, but this looks straightforward enough.
I assume you ran a regression-test? OK if that is the case.
Thanks for the patch!
Best regards
Thomas
Hi Harald,
after lengthy debugging of this PR it became obvious that we killed
the typespec while trying to expand an empty array constructor.
Bad idea, but easy to fix.
Regtested on x86_64-pc-linux-gnu. OK for mainline and 11-branch?
OK.
Thanks for the patch!
Best regards
On 13.01.22 22:58, Thomas Koenig via Fortran wrote:
with this patch, it is now possible to specify both the
endianness and the REAL(KIND=16) format using the
environment variable GFORTRAN_CONVERT_UNIT.
I have now pushed this to trunk.
Best regards
Thomas
Hi Mikael,
Backporting the fix for pr103789 on the 11 branch revealed a lack of test
coverage for the tests provided with that fix. Indeed, the tests use the KIND
argument of the respective intrinsics only with keyword arguments.
This adds variants with non-keyword arguments.
The tests
Hi Harald,
An early *ping* ...
OK. Thanks for the patch!
Best regards
Thomas
Hello world,
with this patch, it is now possible to specify both the
endianness and the REAL(KIND=16) format using the
environment variable GFORTRAN_CONVERT_UNIT. The following
now works:
koenig@gcc-fortran:~/Tst$ cat write_env.f90
program main
real(kind=16) :: x
character (len=30) :: conv
On 11.01.22 14:19, Jakub Jelinek via Fortran wrote:
On Mon, Jan 10, 2022 at 11:44:13PM +0100, Thomas Koenig wrote:
Hello world,
I have just pushed the attched patch to the branch.
Thanks.
Here is a patch to fix up the ppc64be vs. ppc64le byteswapping
of IBM extended real(kind=16) and
Hello world,
I have just pushed the attched patch to the branch.
With this patch, the program
tkoenig@gcc-fortran:~/Tst$ cat write_env.f90
program main
real(kind=16) :: x
character (len=30) :: conv
x = 1/3._16
open
Hi,
I just pushed the attached patch to the branch. It works with the
attached test case for -mabi=ibmlongdouble and -mabi=ieeelongdouble.
The test case is not quite ready for inclusion in the test suite;
it still leaves its last data files behind, and it needs to be
dejagnuified and put with
On 08.01.22 15:02, Jakub Jelinek via Fortran wrote:
Note, as for byteswapping, apparently it wasn't ever working right fox
the IBM extended real(kind=16) and complex(kind=16).
The lack of bug reports since the conversion feature was introduced in
2006, more than 15 years ago, tells us
On 07.01.22 22:48, Jakub Jelinek wrote:
On Fri, Jan 07, 2022 at 10:40:50PM +0100, Thomas Koenig wrote:
One thing that one has to watch out for is a big-endian IBM long double
file, so the byte swapping will have to be done before assigning
the value.
I've tried to handle that right, i.e. on
On 07.01.22 20:52, Jakub Jelinek wrote:
Here is completely untested patch that implements something,
but doesn't implement the gcc option stuff, nor the CONVERT=
syntax to supply multiple conversion options nor done anything
about env var nor any testcases.
But it tries to have the
Hi Jakub,
So, the following patch adds -fbuilding-libgfortran option and uses
it together with TARGET_GLIBC_M* checks to decide whether to use
libquadmath APIs (for the IEEE quad kind=16 if -fbuilding-libgfortran
and not glibc or glibc is older than 2.32) or glibc 2.32 APIs
(otherwise). This
Hi Jakub,
00251038 06ad0015 R_PPC64_JMP_SLOT
__cabsieee128 + 0
All these should for POWER_IEEE128 use atan2q@QUADMATH_1.0 etc.
So, seems all these come from f951 compiled sources.
For user code, I think the agreement was if you want to use
1 - 100 of 436 matches
Mail list logo