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 to
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 t
> 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 c
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 targ
> 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:
On Mon, Jul 7, 2014 at 12:16 PM, FX 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__ stuff?
>
> Ev
Janne Blomqvist wrote:
> On Mon, Jul 7, 2014 at 11:29 AM, FX 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 it against th
> 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 compile
On Mon, Jul 7, 2014 at 11:29 AM, FX 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 .
>
> Committed as re
FX writes:
>> FWIW, those FP_* values are also enum values in IRIX 6.5 , 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 te
> FWIW, those FP_* values are also enum values in IRIX 6.5 , 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 sparc-s
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 ha
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 hardc
FX 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 fix.
No wo
> 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 th
On Sun, Jul 6, 2014 at 11:13 PM, FX 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 libgfortran is compil
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: gf
Steve Kargl 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 re-arrangement s
> This may raise inexact, see C11 7.6.2.3. Installed as obvious.
Thanks!
FX
FX 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 @@
> +! { dg-do run }
> +!
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 tests
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.
>> 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
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. Th
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 plac
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.
Tobi
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_ex
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 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
> ...
> --
> |I
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 Thu, Jun 5, 2014 at 1:13 PM, Rainer Orth
wrote:
> Rainer Orth writes:
>
>> Janne Blomqvist writes:
>>
>>> On Thu, Jun 5, 2014 at 1:04 AM, FX wrote:
2. Your review of the patch!
>>>
>>> Not a full review, just a few quick comments.
>>>
>>> - Wrt. libgfortran/gfortran.map: You have add
Rainer Orth writes:
> Janne Blomqvist writes:
>
>> On Thu, Jun 5, 2014 at 1:04 AM, FX wrote:
>>> 2. Your review of the patch!
>>
>> Not a full review, just a few quick comments.
>>
>> - Wrt. libgfortran/gfortran.map: You have added the GFORTRAN_1.6
>> symbol node, as you're the first one to e
On Thu, Jun 5, 2014 at 11:35 AM, FX wrote:
>> Please look at libgcc/config/i386/crtfastmath.c for how to set
>> MXCSR_FTZ from mxcsr. You already have all necessary bits in place,
>> the function is basically only:
>>
>> + if (has_sse())
>> + {
>> +unsigned int cw_sse;
>> +
>> +__asm__ _
> Please look at libgcc/config/i386/crtfastmath.c for how to set
> MXCSR_FTZ from mxcsr. You already have all necessary bits in place,
> the function is basically only:
>
> + if (has_sse())
> + {
> +unsigned int cw_sse;
> +
> +__asm__ __volatile__ ("%vstmxcsr\t%0" : "=m" (cw_sse));
> +
Hello!
> 0. Gradual underflow control is implemented as "not supported by the
> processor" (its SUPPORT
> function returns false, and the GET and SET procedures abort if you call
> them). That’s explicitly
> allowed by the standard, so it’s not actually “missing". We can improve on
> this in th
Hi Janne,
Thanks for the quick feedback.
> - Wrt. libgfortran/gfortran.map: You have added the GFORTRAN_1.6
> symbol node, as you're the first one to export new symbols in the 4.10
> cycle. I've seen occasional confusion from users when they have symbol
> version mismatches and e.g. "1.4" doesn't
Janne Blomqvist writes:
> On Thu, Jun 5, 2014 at 1:04 AM, FX wrote:
>> 2. Your review of the patch!
>
> Not a full review, just a few quick comments.
>
> - Wrt. libgfortran/gfortran.map: You have added the GFORTRAN_1.6
> symbol node, as you're the first one to export new symbols in the 4.10
>
Hello!
> +int
> get_fpu_except_flags (void)
> {
>unsigned short cw;
>int excepts;
>int result = 0;
>
> - __asm__ __volatile__ ("fnstsw\t%0" : "=a" (cw));
> + __asm__ __volatile__ ("fnstsw\t%0" : "=m" (cw));
>excepts = cw;
>
>if (has_sse())
You can use "=am" constraint here
On Thu, Jun 5, 2014 at 1:04 AM, FX wrote:
> 2. Your review of the patch!
Not a full review, just a few quick comments.
- Wrt. libgfortran/gfortran.map: You have added the GFORTRAN_1.6
symbol node, as you're the first one to export new symbols in the 4.10
cycle. I've seen occasional confusion f
39 matches
Mail list logo
