h was submitted upstream: https://github.com/llvm/llvm-project/pull/72642
FX
configure time) the large majority of users
> who currently get stuck at stage 2 with the "gnu/stubs-32.h" error, while
> being invisible to a large majority of the power users.
>
> So, what do you think?
>
> FX
>
Index: configure.ac
==
> Currently, gfortran.dg/erf_3.F90 FAILs on targets with 128bit
> (quadruple) long double, since high-precision erfc_scaled_r16 gets
> defined only for __float128 quadruple precision.
I can’t approve it, but yes, it makes more sense than what I did earlier.
FX
u contribute
in the first place?
Or is it a “hit and run” approach to maintainership?
FX
’re
testing, every time we merge” seems poised for failure.
FX
ements, as I learnt the hard way.)
FX
ics for this pretty
common situation sucks. It comes late in the compilation, and the message
itself isn’t helpful.
FX
> Were you waiting for further approval? If so: okay with the change
> proposed by Andrew.
Thanks, committed as rev. 205802 with Andrew’s change.
FX
n into it.
FX
> 2015-07-16 Steven G. Kargl
>
> * io.c (is_char_type): Call gfc_resolve_expr().
> (match_open_element, match_dt_element, match_inquire_element): Fix
> ASYNCHRONOUS case.
OK to commit
> 2015-07-29 Uros Bizjak
>
>PR libgfortran/66650
>* libgfortran.h (GFC_DTYPE_SIZE_MASK): Rewrite to avoid
>"left shift of negative value" warning.
OK. Thanks for the patch.
FX
> Why do you initialize a static variable to false?
You mean because false is equal to zero and it will be the default
initialization anyway?
I quite like that the default value is explicit.
FX
my earlier email was: do you have a copyright
assignment in place with the FSF?
FX
what the current
situation is.
FX
The attached patch adds logbq() to libquadmath, with code lifted from glibc.
It is made necessary by an upcoming patch for gfortran, adding full support for
the IEEE modules on __float128, and requires logbq().
Bootstrapped and regtested on x86_64-apple-darwin14.
OK to commit to trunk?
FX
exclusively mechanical changes (adding the
necessary variants to the interfaces, etc.).
Bootstrapped and regtested on x86_64-apple-darwin14 (with associated
libquadmath patch: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00124.html).
OK to commit to trunk?
FX
PS: Once this is in, I intend to
> FAIL: gfortran.dg/ieee/large_1.f90 -O0 (test for excess errors)
> Excess errors:
> large_1.f90:(.text+0x1792): undefined reference to `logbq’
Fixed by the patch there:
https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00124.html
Waiting for review.
FX
e
custom on gcc-patches.
Attached is the full diff, including Makefile.in.
FX
x.diff
Description: Binary data
ros said that underflow id not supported for __float128.
Indeed. I fixed the code, but forgot to commit the testcase. Now done as
revision 226665.
FX
> Can you please also introduce tests for ieee exceptions for long
> double and __float128 types (as is done for real and double in
> gfortran.dg/ieee/ieee_1.F90) as well as test for supported rounding
> modes as done for real and double in gfortran.dg/ieee/rounding_1.f90 ?
>
> On x86_64, these ne
?) for the future.
Bootstrapped and regtested on x86_64-apple-darwin14. OK to commit to trunk?
FX
ieee.ChangeLog
Description: Binary data
ieee.diff
Description: Binary data
> PING: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01219.html
Given that this comes from submodules, which were recently introduced by Paul,
I hoped he could comment. Paul?
FX
t fixed when this is
still fresh (submodules were just implemented few weeks ago), then it’s better!
If Paul doesn’t reply in 2 days, then OK to commit.
FX
your target is not mingw32 and stat() is not reliable, we’ll
need to provide an alternate way of handling things. Your patch would default
to the unusable stat().
What’s your target?
FX
> 2015-09-21 Steven G. Kargl
>
> PR fortran/67615
> * resolve.c (gfc_resolve_code): Check for scalar expression in
> arithmetic-if.
>
>
> 2015-09-21 Steven G. Kargl
>
> PR fortran/67615
> * gfortran.dg/pr67615.f90: new test.
OK
in use.)
I don’t find any request for this feature in the whole bugzilla database.
FX
pick it up. It is a rather “standalone” patch, I don’t think it
would bitrot fast.
But maybe other developers feel differently about it, in which case we’ll have
a more “technical” review (mostly of the testcases needed, I think).
Thanks again,
FX
> Hi!
> Ping.
OK for the Fortran part, though I suspect you need Jakub to approve it as well.
FX
w test.
OK, but not with that error message. We currently don’t use the “shorthand”
standard notation (like "scalar-int-expr”) in our error messages, and we should
keep that consistent. So I would go with “character length should be of integer
type” or something like that.
FX
pression), but not the shorthand (scalar-int-expr) which few people
outside the language lawyers know :)
FX
> In other words,
> consider youself a reviewer for patches in an area
> of the compiler that you are comfortable.
Seconded.
FX
r(len=0) :: s
Thus: not OK to commit.
FX
ng:
legal code, but dubious anyway
OK after you ponder that second point.
FX
> F90 is over 26 years old. There has been 3 major revisions that
> have superceded F90 (F95, F03, and F08). All of those revisions
> include the text that you pointed out to me. Why is it surprising
> that a compiler conforms to the standard?
>
> "Simplify, simplify, simplify." Henry David
> 2015-10-21 Steven G. Kargl
>
> PR fortran/67939
> * data.c (create_character_initializer): Deal with zero length string.
>
> 2015-10-21 Steven G. Kargl
>
> PR fortran/67939
> * gfortran.dg/pr67939.f90: New test.
OK, thanks
> 2015-10-22 Paul Thomas
>
>PR fortran/58754
>* trans-stmt.c (gfc_trans_allocate): Do not use the scalar
>character assignment if the allocate expression sis an array
>descriptor.
>
> 2015-10-22 Paul Thomas
>
>PR fortran/58754
>* gfortran.dg/pr58754.f90: New test
O
.
OK. But I don’t understand why the testcase’s dg-error pattern has this form: a
regex “or” (|) of two identical strings?
FX
OK.
Please post patches with full ChangeLog entry, stating how they were tested
(“bootstraped and regtested on x86_64-linux”, for example). And of course, do
an actual full regression-test :)
If that was done, then OK to commit.
Thanks,
FX
t I'm always confident that the ones I remember are
> good :)
OK to commit.
FX
> Because the code issues two errors, one for each dimension.
Then shouldn’t it be “string.*string” to match two occurences of the string,
with some stuff (incl. newline) in the middle?
FX
G(linker --version-script option)
+gcc_cv_ld_version_script=no
+ld_version_script_option=''
FX
I can confirm that, with the attached revised patch, a bootstrap with
--enable-languages=c,c++,jit --enable-host-shared is successful on macOS.
FX
patch
Description: Binary data
Hi David,
Any news on that patch?
Cheers,
FX
I think the doc says “assumed-shape” where it means “assumed-rank”. Is that OK?
FX
Index: gfortran.texi
===
--- gfortran.texi (revision 204389)
+++ gfortran.texi (working copy)
@@ -2624,7 +2624,7 @@ other hand, assumed
< 12, it simply
calls erfcq() then multiplies by expq(x*x). For larger arguments, it uses a
power expansion in 1/x. The new implementation provides answers within to 2 ulp
of the correct value.
Regtested on x86_64-apple-darwin13, comes with a testcase. OK to commit?
FX
erfc_scaled.Change
This attach patch adds an assert() in the library to fix PR 51828, i.e. silence
a “may be used uninitialized” warning.
Built and regtested on x86_64-apple-darwin13. OK to commit?
FX
libwarning.ChangeLog
Description: Binary data
libwarning.diff
Description: Binary data
ss than approximately -8192, then erfc(x)*exp(x*x)
> overflows.
Hum, I get roughly -106 where you have -8192, so I’ll not commit immediately
with the value I have, and let you check it first.
OK to commit?
FX
erfc_scaled.diff
Description: Binary data
> So, yeah, you're correct. My suggestion was based on the not
> so careful mistake of replacing x*x by x+x and dropping log(2).
> That is, I had x+x = -emax --> x = - emax / 2.
Committed as rev. 205151, thanks for the review!
FX
and without binary128.
Sorry again,
FX
2013-11-20 Francois-Xavier Coudert
PR libfortran/59227
* intrinsics/erfc_scaled.c (erfc_scaled_r16): Don't define if
__float128 is not available.
fix.diff
Description: Binary data
iven a bit of help
(someone to write the assembly code).
Thanks for your feedback,
FX
en’t found any other suitable place :)
I do not see how to specify compiler flags only for Fortran.
> You could also ask Mike Stump to review the testsuite changes.
Mike, in your understanding, is there any place where Fortran-only flags could
be specified in the testsuite?
FX
uivalent to glibc’s:
feclearexcept (exc_clr);
feraiseexcept (exc_set);
So yes, raising an exception is the except action. I’ve attached a new version
of config/fpu-387.h, along with the glibc version (fpu-glibc.h). I’d be glad if
you could review it.
Thanks a lot!
FX
fpu-387.h
Description: Binary data
fpu-glibc.h
Description: Binary data
>> A quick grep through the front-end indicates that
>> gfc_open_intrinsic_module() is never used. Should it have been
>> removed when module file reading/writing was overhauled?
>
> I suspect the answer is "yes”.
Here’s a patch that removes it. It buils fine.
OK
> OK. Thanks for the patch!
Committed as rev. 205335.
> Patch
Patch cleaning up the testsuite (while Tobias is curing is cold :) is
pre-approved.
It comes from the last-minute wording change I suggested, I suppose.
FX
Committed as trivial, rev. 216006
2014-10-08 Francois-Xavier Coudert
PR libquadmath/63487
* libquadmath.texi (sincosq): Fix typo.
Index: libquadmath.texi
===
--- libquadmath.texi(revision 215645)
+++ libquad
The attached patch prevents libquadmath from installing its info file if the
library is not actually built.
Tested on x86_64-linux, both on a built with libquadmath (normal) and without
(tweaking configure so it thinks _float128 is not supported).
OK to commit?
quadmath.ChangeLog
Description
> The attached patch prevents libquadmath from installing its info file if the
> library is not actually built.
> Tested on x86_64-linux, both on a built with libquadmath (normal) and without
> (tweaking configure so it thinks _float128 is not supported).
>
> OK to commit?
Again, with correct C
> Ok, thanks for the patch!
Committed as rev. 216036.
Thanks for the review.
FX
Version 2 of the patch, now handling the darwin case (thanks Iain) and
expressely noting in the documentation the implications on redistribution
(thanks Joseph).
Bootstrapped and regtested on x86_64-apple-darwin14.
OK to commit?
I need a C/driver options maintainer, or global reviewer, to OK th
> But it still needs to be OK'd by either a global reviewer or one of the
> listed Darwin maintainers ;) ...
> ... (ccing Mike)
Duh me. I thought you were a darwin maintainer. Sorry.
FX
egtested on x86_64-apple-darwin14. OK to commit?
FX
intrinsics.ChangeLog
Description: Binary data
intrinsics.diff
Description: Binary data
After the compile-time simplification, this patch fixes the handling of special
values (infinities and NaNs) by intrinsics EXPONENT, FRACTION, SPACING,
RRSPACING & SET_EXPONENT on the code generation side.
Bootstrapped and regtested on x86_64-linux.
OK to commit?
intrinsics.ChangeLog
Descri
ping
Patch needs:
- C/driver options maintainer, or global reviewer, to OK the C changes
(outside darwin). They are really simple
- Fortran maintainer to OK the Fortran part
> Version 2 of the patch, now handling the darwin case (thanks Iain) and
> expressely noting in the documentation th
ping
> After the compile-time simplification, this patch fixes the handling of
> special values (infinities and NaNs) by intrinsics EXPONENT, FRACTION,
> SPACING, RRSPACING & SET_EXPONENT on the code generation side.
>
> Bootstrapped and regtested on x86_64-linux.
> OK to commit?
intrinsics.
later in the process, and let the existing F2003 / F2008
parts mature & be tested for now.
FX
ixing just one of the use cases is not sufficient.
FX
> I think it is really weird if a coding style warning is included in -Wall.
Same here. It’s not a very commonly shared coding style, so I don’t think it
should be included in -Wall.
Other than that, I like the idea (but cannot review the patch).
FX
existence is specified in C & C++ standards, but
not in the Fortran standard). If I understand correctly, Joost’s patch just
adapts this to a new flag handling mechanism.
FX
bably not such a
big deal.
FX
m. I’m open to moving some of the IEEE handling towards the
front-end, but we need to think clearly about that…
FX
7;t handle this setting.
Yeah, that’s also why I prefer for now to have it declared as unsupported: the
Fortran standard doesn’t really allow for partial support such as this, so I’m
still trying to figure out what The Right Thing To Do is.
FX
Hi all,
Our Fortran 2003 status page [1] says gfortran does not support "Kind type
parameters of integer specifiers”. This item is defined thusly (item 4.9 in
[2]):
> Some of the integer specifiers (e.g. NEXTREC) were limited to default kind in
> Fortran 95. Any kind of integer is permitted in
-apple-darwin13, OK to commit?
FX
io_diagnostics.ChangeLog
Description: Binary data
io_diagnostics.diff
Description: Binary data
ommitted as rev. 211323.
FX
safe enough to me to proceed first, and let John test in his
next build of trunk (bootstrap on those machines probably isn’t fast).
OK to commit?
FX
hpux.diff
Description: Binary data
hpux.ChangeLog
Description: Binary data
gfc_finish_var_decl().
Bootstrapped and regtested on x86_64-apple-darwin13, includes a testcase.
OK to commit?
FX
cray.diff
Description: Binary data
cray.ChangeLog
Description: Binary data
?
FX
PS: you may notice I have had some time to hack at gfortran these past few
days... it feels good!
bind_c.ChangeLog
Description: Binary data
bind_c.diff
Description: Binary data
, but not
> on hpux10. It seems safe enough to me to proceed first, and let John test in
> his next build of trunk (bootstrap on those machines probably isn’t fast).
>
> OK to commit?
>
> FX
hpux.ChangeLog
Description: Binary data
hpux.diff
Description: Binary data
Committed as rev. 211685, thanks for the review.
FX
ping
To reinforce the message in my earlier email: we can fine-tune the list of
allowed characters in identifiers later, but I’d like to get this patch in
already (so it gets large exposure before the 4.10 release).
FX
> Binding label can be any initialisation expression. Well, only sca
win13.
OK to commit?
FX
pr61454.diff
Description: Binary data
pr61454.ChangeLog
Description: Binary data
> Not only is it 'obvious' but it can do no harm in any circumstances
> :-) OK to commit
True! Committed as rev. 211822
FX
much hope there).
Thanks again,
FX
ping*2
> ping
>
> To reinforce the message in my earlier email: we can fine-tune the list of
> allowed characters in identifiers later, but I’d like to get this patch in
> already (so it gets large exposure before the 4.10 release).
>
> FX
>
>
>
>> Bin
> This may raise inexact, see C11 7.6.2.3. Installed as obvious.
Thanks!
FX
> Works as advertized and even fixes pr38838.
> Thanks for the patch.
Thanks for the review, committed to trunk as rev. 212123
FX
FE_MAP_DMZ FE_MAP_DMZ
>
>FE_MAP_UMZ =1UL << 13, /* Map underflowed outputs to zero */
> #define FE_MAP_UMZ FE_MAP_UMZ
> };
> #endif
>
> FX, if you care for this option, I can help test the patch and
> corresponding testcases.
Yes, that’s in
Hi all,
The attached patch provides support for underflow control in the
IEEE_ARITHMETIC module, for x86/x86_64 targets (our main user base).
Bootstrapped and regtested on x86_64-apple-darwin13. Comes with a testcase.
OK to commit?
FX
underflow.ChangeLog
Description: Binary data
> (I don't think -O0 is needed, but have to check with a testsuite run.)
On x86_64-apple-darwin, -O0 or -O1 are needed: at -O2 my “use_real” call is
optimized out anyway, and the division simplified at compile time.
FX
libgfortran/config/fpu-glibc.h file on alpha?
> You can mark variables with “volatile”
Indeed, I should have thought of that. Once you report the results of the alpha
modification, I’ll propose an updated patch with all of those remarks.
Thanks,
FX
fpu-glibc.h
Description: Binary data
Here’s an updated patch, providing support for underflow control in the
IEEE_ARITHMETIC module, for x86/x86_64 targets and alpha-glibc.
Bootstrapped and regtested on x86_64-apple-darwin13, tested by Uros on alpha.
OK to commit?
underflow.ChangeLog
Description: Binary data
underflow.diff
Des
> Also, for that page having 2-3(-4) words as a short title are necessary.
> What would be appropriate here? "Fortran IEEE intrinsic modules”?
Sounds good to me.
FX
of sense to change these into static assertions: this
way, any target-specific issues with FP-state buffer size will show up at
libgfortran-building-time, rather than be swept under the rug.
Since libgfortran is compiled with GCC, which supports _Static_assert since
4.6, I propose the attached
ibgfortran.h to c99_intrinsics.c, which is the only place they’re ever used.
Built and tested on x86_64-linux, OK to commit?
FX
clean.ChangeLog
Description: Binary data
clean.diff
Description: Binary data
PS: I didn’t touch libcaf, as I assume this might be compiled with a different
co
nly thing I can see is that libgfortran/config/fpu-sysv.h assumes that
FP_RM and others are macros, checking them with "#ifdef FP_RM”. Is that the
reason?
If so, we might just want to use them unconditionally… unless it creates a mess
on some other SysV target!
FX
an actual
review).
Also, related to that: could you also confirm that FP_X_INV (and others) are
indeed macros, on solaris?
FX
bgfortran is compiled with the freshly-built
compiler, not the host compiler.
FX
> Right, that's what I (vaguelly) remembered. Please consider a patch
> removing the ifndef __GNUC__ stuff from libgfortran.h pre-approved.
The only occurrence (outside of libcaf) is in libgfortran.h. Committed attached
patch as rev. 212328, after building on x86_64-linux.
FX
x
ntifiers,
but normal strings.)
Russell, you said “tested on x86_64-linux”. Could you explicitly confirm that
you have bootstrapped it and regression-tested the full gfortran testsuite ?
Cheers,
FX
1 - 100 of 632 matches
Mail list logo
