Hi!
On Thu, 28 Feb 2019 20:22:08 +0100, I wrote:
> While looking for something else -- isn't that always how it happens ;-)
> -- I noticed one thing here:
>
> On Wed, 25 Jun 2014 01:41:02 +0200, FX wrote:
> > I’ll wait a few more days to commit, so others can comment/review and I am
> > sure
Hi!
While looking for something else -- isn't that always how it happens ;-)
-- I noticed one thing here:
On Wed, 25 Jun 2014 01:41:02 +0200, FX wrote:
> I’ll wait a few more days to commit, so others can comment/review and I am
> sure to be around if there is fallout.
(This got committed to
Hello!
The only 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?
It is.
If so, we might just want to use them unconditionally… unless it creates a
mess on some other SysV target!
FWIW,
Since all modes are supported, you can unconditionally return 1 in the
code above, as is the case with fpu-387.h.
Indeed. I’ve committed the attached patch, which performs this trivial cleanup,
adds some comments about unreachable cases (I don’t think we want to error out
at runtime, but a
On Sun, Jul 6, 2014 at 11:13 PM, FX fxcoud...@gmail.com wrote:
Actually, it makes a lot 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
Furthermore, on 2014-05-12 I committed a patch changing libgfortran to
be built with -std=gnu11 instead of -std=gnu99, so that we can make
use of C11 functionality; see
https://gcc.gnu.org/ml/fortran/2014-04/msg00101.html .
Committed as rev. 212323, thanks for the review.
I now propose the
FX fxcoud...@gmail.com writes:
Unfortunately, while the patch works fine on Solaris/x86, it broke
Solaris/SPARC bootstrap for trivial reasons: contrary to the ChangeLog,
configure and config.h.in weren't regenerated, thus FPSETSTICKY
wasn't defined.
I apologize. Thanks for checking in the
Hi Rainer,
while the i386/amd64 values are the usual ones. Unfortunately,
gcc/fortran/libgfortran.h hardcodes the more common values for
GFC_FPE_*, and libgfortran/Makefile.am extracts them from there into
fpu-target.inc. I'm unsure what's the best way to handle this.
No, we don’t hardcode
Hi FX,
while the i386/amd64 values are the usual ones. Unfortunately,
gcc/fortran/libgfortran.h hardcodes the more common values for
GFC_FPE_*, and libgfortran/Makefile.am extracts them from there into
fpu-target.inc. I'm unsure what's the best way to handle this.
No, we don’t hardcode
FWIW, those FP_* values are also enum values in IRIX 6.5 ieeefp.h, the
only other SysV target I have around. Seems this file is common between
all of them, so the risk should be manageable.
The following patch does away with the #ifdef stuff and lets all
gfortran.dg/ieee tests PASS on
FX fxcoud...@gmail.com writes:
FWIW, those FP_* values are also enum values in IRIX 6.5 ieeefp.h, the
only other SysV target I have around. Seems this file is common between
all of them, so the risk should be manageable.
The following patch does away with the #ifdef stuff and lets all
On Mon, Jul 7, 2014 at 11:29 AM, FX fxcoud...@gmail.com wrote:
Furthermore, on 2014-05-12 I committed a patch changing libgfortran to
be built with -std=gnu11 instead of -std=gnu99, so that we can make
use of C11 functionality; see
https://gcc.gnu.org/ml/fortran/2014-04/msg00101.html .
What about --disable-bootstrap? Does it just skip stage1 and stage2,
and stage3 is used to compile libgfortran, or is the host compiler
used to build libgfortran as well? If the former, yes I guess we can
remove #ifnderf __GNUC__ stuff?
Even with --disable-bootstrap, libgfortran is compiled
Janne Blomqvist wrote:
On Mon, Jul 7, 2014 at 11:29 AM, FX fxcoud...@gmail.com wrote:
PS: I didnât touch libcaf, as I assume this might be compiled with a
different compiler. Am I right?
My understanding is that libcaf is delivered in source form, and the
end user is expected to compile
On Mon, Jul 7, 2014 at 12:16 PM, FX fxcoud...@gmail.com wrote:
What about --disable-bootstrap? Does it just skip stage1 and stage2,
and stage3 is used to compile libgfortran, or is the host compiler
used to build libgfortran as well? If the former, yes I guess we can
remove #ifnderf __GNUC__
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
Description:
Dear Rainer,
Unfortunately, while the patch works fine on Solaris/x86, it broke
Solaris/SPARC bootstrap for trivial reasons: contrary to the ChangeLog,
configure and config.h.in weren't regenerated, thus FPSETSTICKY
wasn't defined.
I apologize. Thanks for checking in the fix.
FAIL:
Steve Kargl s...@troutmask.apl.washington.edu writes:
On Tue, Jun 24, 2014 at 10:26:27PM +0200, FX wrote:
3. Does the attached updated patch (libgfortran only, without
regenerated files) fix the problem?
I'll test it when my regtesting is completed. But, a scan of
the configure.host
FX fxcoud...@gmail.com writes:
Index: gcc/testsuite/gfortran.dg/ieee/ieee_6.f90
===
--- gcc/testsuite/gfortran.dg/ieee/ieee_6.f90 (revision 0)
+++ gcc/testsuite/gfortran.dg/ieee/ieee_6.f90 (revision 0)
@@ -0,0 +1,78 @@
+! {
This may raise inexact, see C11 7.6.2.3. Installed as obvious.
Thanks!
FX
On Wed, Jun 25, 2014 at 01:41:02AM +0200, FX wrote:
If I remove the previously installed gcc, the failure again occurs.
So, it looks like the testsuite is picking up installed *.mod files
over the freshly built *.mod files. This is not a showstopper.
And this is not all the testsuite,
On Tue, Jun 24, 2014 at 10:11:32AM +0200, FX wrote:
Here?s a patch fixing the diff issue with configure.host and the doc (which
apparently is only triggered by some versions of texinfo).
Apart from that, functionnaly identical, so I?ll paste here the ?history? of
the patch:
On Tue, Jun 24, 2014 at 09:49:36AM -0700, Steve Kargl wrote:
Not yet.
On i386-*-freebsd
In file included from ../../../gcc4x/libgfortran/runtime/fpu.c:29:0:
./fpu-target.h: In function 'set_fpu_trap_exceptions':
./fpu-target.h:31:3: error: unknown type name 'fp_except'
fp_except cw
Steve Kargl wrote:
On FreeBSD (and perhaps other *BSD), there is no fpsetsticky(). The function
is fpresetsticky().
Solaris has fpsetsticky() (requires ieeefp.h) and BSD has
fpresetsticky() – thus, like at other places in that file, one needs to
conditionally enable one or the other.
On Tue, Jun 24, 2014 at 08:34:23PM +0200, Tobias Burnus wrote:
Steve Kargl wrote:
On FreeBSD (and perhaps other *BSD), there is no fpsetsticky(). The
function is fpresetsticky().
Solaris has fpsetsticky() (requires ieeefp.h) and BSD has
fpresetsticky() ? thus, like at other places in
On Tue, Jun 24, 2014 at 09:43:06PM +0200, FX wrote:
Thanks for testing on a platform I don?t have access to! I try to
answer to the three main points below:
I suppose I don't understand the logic in libgfortran/configure.host.
It is picking the wrong config/fpu*.h file.
1. This is a
3. Does the attached updated patch (libgfortran only, without
regenerated files) fix the problem?
I'll test it when my regtesting is completed. But, a scan of
the configure.host re-arrangement suggests that it should work.
OK.
If you have some spare cycles, could you then also check it by
On Tue, Jun 24, 2014 at 10:26:27PM +0200, FX wrote:
3. Does the attached updated patch (libgfortran only, without
regenerated files) fix the problem?
I'll test it when my regtesting is completed. But, a scan of
the configure.host re-arrangement suggests that it should work.
OK.
I meant to look this over this weekend. Unfortnately, baseball
and soccer (both daughter and USA vs Portugal) got in the way.
First issue,
cd gcc4x
patch ieee_withregenerated_2.diff
...
--
|Index: configure.host
On Mon, Jun 23, 2014 at 12:23:39PM -0700, Steve Kargl wrote:
I meant to look this over this weekend. Unfortnately, baseball
and soccer (both daughter and USA vs Portugal) got in the way.
First issue,
cd gcc4x
patch ieee_withregenerated_2.diff
...
--
|Index:
30 matches
Mail list logo
