[Bug fortran/33271] nint_2.f90 abort compiled with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271 --- Comment #22 from Segher Boessenkool --- Author: segher Date: Wed Mar 15 20:48:49 2017 New Revision: 246174 URL: https://gcc.gnu.org/viewcvs?rev=246174=gcc=rev Log: rs6000: Do not xfail nint_2.f90 on Linux systems It was XFAILed because there was a bug in glibc, but that bug was fixed nine years ago. Nowadays everyone uses a version of glibc with the bug fixed, so we should no longer XFAIL the test. gcc/testsuite/ PR fortran/33271 * gfortran.dg/nint_2.f90: Do not xfail powerpc*-*-linux*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/nint_2.f90
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #19 from dominiq at lps dot ens dot fr 2007-09-11 10:44 --- In order to avoid a too long post, I am splitting my answer in pieces. PS: I should note that the bug in question is a relatively minor one: lround(), on ppc-glibc and AIX, returns a wrong answer for the floating-point number immediately lower than 0.5, Prec(0.5). All values are fine, except Prec(0.5), -Prec(0.5), 4503599627370497 and -4503599627370497. The marketing guys at Intel tried this kind of justification during the divide fiasco and got the following joke: QA: THE PENTIUM FDIV BUG Q: How many Pentium designers does it take to screw in a light bulb? A: 1.99904274017, but that's close enough for non-technical people. More seriously, the test fails for the above values, but this does not mean that it does not fail for other values. The most common mistake when computing nint(x) is to use int(x+0.5) without setting the rounding mode towards 0. If int(x+0.5) is used with the default round to nearest, all the values nearest(real(2**i)-0.5,-1.0) (at least) and all the odd integers between 2**51 and 2**52-1 are not rounded correctly (towards real(2**i) and even integers respectively). So before concluding that only four values give a wrong results, more tests should be performed with these known candidates for failures. This is one of my prejudice against, not the test suite itself, but its use: incorrect conclusions are drawn from incomplete test cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #20 from fxcoudert at gcc dot gnu dot org 2007-09-11 11:06 --- (In reply to comment #19) More seriously, the test fails for the above values, but this does not mean that it does not fail for other values. Sorry, I was posting in a haste and was to affirmative. What I meant is: the AIX and powerpc-glibc routines are only failing for a finite number of values. That's dead annoying, but it will still be working most of the time. If I were using one of these platforms for production work, I'd be dead annoyed and complain heavily to the vendor (especially for AIX, which is not free), but as I'm not, there's only so much I can do. So before concluding that only four values give a wrong results, more tests should be performed with these known candidates for failures. Well, tests certainly need to be conducted and the source code reviewed. But this needs to be done the packages who have incorrect behaviour: GNU libc and AIX libm. This is one of my prejudice against, not the test suite itself, but its use: incorrect conclusions are drawn from incomplete test cases. Well, you're welcome to contribute to the testsuite to extend its coverage. I'm glad it's there, because it keeps us from regressing too much (we *still* regress, and any regression is one too many, and the testsuite could be extended, but we're better off than if it weren't there). Also, to answer your affirmation that XFAILed tests are of no use to users, it's wrong. The testsuite is primarily designed for GCC developers to check on the status of their code, which is why the default reports only contain FAILing and XPASSing testcases. But it can also be used by users to check on what their compiler limitations are, in which case you need to check for XFAILing tests also. These are kept in the test summary, they're just not output in default reports. XFAIL is used to signal a functionality that's not working, due not to defect in GCC but in other software (such as the libc). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #21 from dje at gcc dot gnu dot org 2007-09-11 11:29 --- AIX defect number 628397 opened against the math library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #18 from dominiq at lps dot ens dot fr 2007-09-07 13:49 --- FX, Please don't take my comment on the test suite personally. I think the PR should be resolved as WONTFIX for the reasons you explain and the test case should fail on the platform on which it fails. For the moment, I cannot think of the better way to warn the user that there is something wrong with NINT() even if it is for corner cases. I have to leave right now for 3 days without internet connection. I'll give more specific comments when returning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-09-07 12:06 --- (In reply to comment #16) This way to fix the problem shakes the (little) confidence I have in the test suite! You're, as always, welcome to improve it! (both by submitting code and general ideas to make it better) Would not it be better to let the tests fail for the mentionned platforms until a (real) fix is found (as it is done for large_real_kind_2.F90 and large_real_kind_form_io_2.f90 on Darwin)? I'm not sure I understand what you suggest. nint_2.f90 fails on ppc-aix and ppc-linux because those targets have a system math library that contains a bug. The code that gfortran create is OK, and the testcase would not fail if the AIX and powerpc-glibc didn't have a buggy lround(). In fact, it is passing on all other targets. So, in that case, and contrarily to large_real_kind_2.F90, the bug here is not in GCC, all we can do is really to wait for AIX and glibc to fix their libraries. This is not going to happen soon (especially for AIX), and we certainly have no control over it. This leaves two options: keep the testcase failing on these two platforms, which means that people will probably report the failure again, or at least investigate it. The nice thing in a testsuite is that every single failure should be indicating a bug that we can act on: it's not the case here. The other option is to XFAIL it on these two targets, which means (a) we don't see the failure, (b) there is a record that this should, in a perfect world, pass, but due to circumstances out of our control it is expected to fail, and (c) when it starts passing (because glibc/AIX will have been fixed), it will show up in test results as XPASS, and we can act (remove the xfail). If I understood you, you'd like option 1 above, am I right? Why do you think it is better for the project? PS: I should note that the bug in question is a relatively minor one: lround(), on ppc-glibc and AIX, returns a wrong answer for the floating-point number immediately lower than 0.5, Prec(0.5). All values are fine, except Prec(0.5), -Prec(0.5), 4503599627370497 and -4503599627370497. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #16 from dominiq at lps dot ens dot fr 2007-09-07 11:42 --- This way to fix the problem shakes the (little) confidence I have in the test suite! Would not it be better to let the tests fail for the mentionned platforms until a (real) fix is found (as it is done for large_real_kind_2.F90 and large_real_kind_form_io_2.f90 on Darwin)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-09-06 17:47
---
The following code:
#include math.h
#include stdio.h
int main (void)
{
printf (%ld %ld %ld\n, lround (nextafter(0.5,-9.0)), lround (0.5), lround
(nextafter(0.5,9.0)));
}
should print 0 1 1. On both ppc-aix and ppc-linux (thanks David for testing!)
it says 1 1 1, which is wrong. The powerpc-linux issue is a glibc bug, I
filed it as #4997 (http://www.cygwin.com/bugzilla/show_bug.cgi?id=4997). The
powerpc-aix issue is a AIX libm bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-09-06 17:48 --- Subject: Bug 33271 Author: fxcoudert Date: Thu Sep 6 17:48:32 2007 New Revision: 128196 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128196 Log: PR fortran/33271 * gfortran.dg/nint_2.f90: xfail on powerpc-ibm-aix* and powerpc*-linux-gnu. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/nint_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2007-09-06 17:50 --- Testcase XFAILed on both platforms, should appear as a failure any more. Please reopen the PR if I made a mistake and it still appears. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-09-05 09:47
---
(In reply to comment #9)
By the way, nint_2.f90 also fails at -O0 on AIX.
And it works on powerpc-apple-darwin. David, could you test my C program in
comment #4, and look into ${builddir}/${target_triplet}/libgfortran/config.h to
see what value have the HAVE_LROUND{F,,L} and HAVE_LLROUND{F,,L} macros?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|powerpc-unknown-linux-gnu |powerpc-unknown-linux-gnu,
||powerpc-ibm-aix5.3.0.0
GCC host triplet|powerpc-unknown-linux-gnu |powerpc-unknown-linux-gnu,
||powerpc-ibm-aix5.3.0.0
GCC target triplet|powerpc-unknown-linux-gnu |powerpc-unknown-linux-gnu,
||powerpc-ibm-aix5.3.0.0
Version|4.3.0 |unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #11 from dje at watson dot ibm dot com 2007-09-05 17:13 ---
Subject: Re: nint_2.f90 abort compiled with -O0
fxcoudert at gcc dot gnu dot org writes:
FX look into ${builddir}/${target_triplet}/libgfortran/config.h to
FX see what value have the HAVE_LROUND{F,,L} and HAVE_LLROUND{F,,L} macros?
/* libm includes llround */
#define HAVE_LLROUND 1
/* libm includes llroundf */
#define HAVE_LLROUNDF 1
/* libm includes llroundl */
#define HAVE_LLROUNDL 1
/* libm includes lround */
#define HAVE_LROUND 1
/* libm includes lroundf */
#define HAVE_LROUNDF 1
/* libm includes lroundl */
#define HAVE_LROUNDL 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #12 from dje at watson dot ibm dot com 2007-09-05 17:19 --- Subject: Re: nint_2.f90 abort compiled with -O0 fxcoudert at gcc dot gnu dot org writes: FX David, could you test my C program in comment #4 $ ./xgcc -B./ -W -Wall -O1 fx.c fx.c: In function 'main': fx.c:46: warning: integer constant is too large for 'long' type fx.c:47: warning: integer constant is too large for 'long' type fx.c:51: warning: integer constant is too large for 'long' type fx.c:52: warning: integer constant is too large for 'long' type $ ./a.out 4 4 8 $ ./xgcc -B./ -W -Wall -O0 fx.c fx.c: In function 'main': fx.c:46: warning: integer constant is too large for 'long' type fx.c:47: warning: integer constant is too large for 'long' type fx.c:51: warning: integer constant is too large for 'long' type fx.c:52: warning: integer constant is too large for 'long' type ld: 0711-317 ERROR: Undefined symbol: .lround ld: 0711-317 ERROR: Undefined symbol: .lroundf ld: 0711-317 ERROR: Undefined symbol: .llround $ ./xgcc -B./ -W -Wall -O0 fx.c -lm fx.c: In function 'main': fx.c:46: warning: integer constant is too large for 'long' type fx.c:47: warning: integer constant is too large for 'long' type fx.c:51: warning: integer constant is too large for 'long' type fx.c:52: warning: integer constant is too large for 'long' type $ ./a.out 4 4 8 Abort 1 $ ./xgcc -B./ -maix64 -W -Wall -O1 fx.c $ ./a.out 4 8 8 $ ./xgcc -B./ -maix64 -W -Wall -O0 fx.c -lm $ ./a.out 4 8 8 Abort 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #9 from dje at gcc dot gnu dot org 2007-09-04 19:11 --- By the way, nint_2.f90 also fails at -O0 on AIX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-03 10:04
---
(In reply to comment #3)
A) I see that you and others put a number of patches and regenerations. Do you
want me to rebootstrap and then do it?
I don't think we've touched anything who should affect this since you filed the
PR, so no real need to update.
It starts to sound like a library problem... could you compile and run the
following C source:
#include stdio.h
#include stdlib.h
int main (void)
{
double a;
float b;
int j1, j2;
long long int i1, i2;
printf (%lu %lu %lu\n, sizeof(int), sizeof(long int), sizeof(long long
int));
a = 4.99944488848768742172978818416595459e-1L;
i2 = 0;
i1 = (long long int) __builtin_lround (a);
if (i1 != 0 || i2 != 0)
puts (Abort 1);
a = 5.0e-1L;
i2 = 1;
i1 = (long long int) __builtin_lround (a);
if (i1 != 1 || i2 != 1)
puts (Abort 2);
a = 5.00111022302462515654042363166809082e-1L;
i2 = 1;
i1 = (long long int) __builtin_lround (a);
if (i1 != 1 || i2 != 1)
puts (Abort 3);
b = 4.99701976776123046875e-1;
j2 = 0;
j1 = (int) __builtin_lroundf (b);
if (j1 != 0 || j2 != 0)
puts (Abort 4);
b = 5.0e-1;
j2 = 1;
j1 = (int) __builtin_lroundf (b);
if (j1 != 1 || j2 != 1)
puts (Abort 5);
b = 5.0059604644775390625e-1;
j2 = 1;
j1 = (int) __builtin_lroundf (b);
if (j1 != 1 || j2 != 1)
puts (Abort 6);
a = 4.503599627370497e+15L;
i1 = __builtin_llround (a);
i2 = 4503599627370497;
if (i1 != i2 || i1 != 4503599627370497)
puts (Abort 7);
a = -4.503599627370497e+15L;
i1 = __builtin_llround (a);
i2 = -4503599627370497;
if (i1 != i2 || i1 != -4503599627370497)
puts (Abort 8);
return 0;
}
(gcc a.c -lm -W -Wall; try with -O0 and -O1, I expect it will fail only at
-O0).
One last question: in your build tree, you should have a file named
${builddir}/${target_triplet}/libgfortran/config.h. How does it define the
macros HAVE_LLROUND, HAVE_LLROUNDF, HAVE_LLROUNDL, HAVE_LROUND, HAVE_LROUNDF
and HAVE_LROUNDL?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2007-09-03 10:04:32
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #5 from michelin60 at gmail dot com 2007-09-03 13:49 ---
(gcc a.c -lm -W -Wall; try with -O0 and -O1, I expect it will fail only at
-O0).
One last question: in your build tree, you should have a file named
${builddir}/${target_triplet}/libgfortran/config.h. How does it define the
macros HAVE_LLROUND, HAVE_LLROUNDF, HAVE_LLROUNDL, HAVE_LROUND, HAVE_LROUNDF
and HAVE_LROUNDL?
Let me start off by saying that today is a holiday and that tomoorow I am back
at work and traveling, I am not allowed to use __any__ business assets for GCC
connected activity.
That last question seems beyond my ken. I am running glibc-2.6.1
(the latest official). The GCC tree is just the fairly current svn without any
changes by myself. I am a chemical engineer and computers, compilers are just
tools as far as I am concerned. I certainly do not use the latest for
production work (I have about a dozen compilers that I can make active at any
given time. This is my home machine and completely disconnected from my
company.
We just had an extensive power outage and we just recovering. I will try and
run that program today? the question is with which C compiler ( the latest
Trunk, gcc-4.3.0? 4.1.current? 3.3.6 ? or 3.4.6? and even the junky 4.2.1) I am
not prepared to give you a choice of glibc as going back to earlier versions is
generally discouraged and rather risky.
Regarding the last question just look in your own current svn tree.
You might also look at PR33271 or PR33277 for my latest fiasco with Pinski. He
appears to owe his job to Dr. Edelsohn and was just hanging around a school
where a relative is a department head for several years. (this is documentable)
Do not try to recruit me as a maintainer because I would __never__ consider
working in an organization as politiized and poorly run as GCC. Mark Mitchel is
just not allowed to act as a real release manager.
The exception is the fortran group (minus Kargl). Where Paul Thomas has been
doing herculean work. I would love to see at least part of that work in 4.1.x
as 4.2.x and 4.3.x are completely messed up with things like decimal float
(major marketing tool of IBM). By the way the latest gcc on AIX is 3.3.1. Thus,
the IBM marketing types are pratically stating that they want to see gcc-4
hobbled.
Now if you do not want to work with me any more, just let me know. I am am
pretty hard boiled from the US corporate world and can spot the gcc
manipulations from a mile away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-03 14:09
---
(In reply to comment #5)
Let me start off by saying that today is a holiday and that tomoorow I am back
at work and traveling, I am not allowed to use __any__ business assets for GCC
connected activity.
That's fine, I'm certainly not in a hurry. We'll have this fixed before
release, and of course the sooner the better, a few days on a corner case is
not a big deal (this testcase is really a corner case).
We just had an extensive power outage and we just recovering. I will try and
run that program today? the question is with which C compiler ( the latest
Trunk, gcc-4.3.0? 4.1.current? 3.3.6 ? or 3.4.6? and even the junky 4.2.1)
Try with the same compiler that gave you the Fortran failure. Otherwise, take
any other one, what the code I posted is really testing is your glibc.
One last question: in your build tree, you should have a file named
${builddir}/${target_triplet}/libgfortran/config.h. How does it define the
macros HAVE_LLROUND, HAVE_LLROUNDF, HAVE_LLROUNDL, HAVE_LROUND, HAVE_LROUNDF
and HAVE_LROUNDL?
Regarding the last question just look in your own current svn tree.
No, I'm not referring to the source tree but the build tree (the one where your
object build files are stored in). That's the directory where you run the
configure make in. Could you look into that directory, for a file named
powerpc-unknown-linux-gnu/libgfortran/config.h, and paste the lines of that
file which contain the text HAVE_LROUND and the other ones I was quoting?
PS: Please refrain from comments on individuals. There are numerous media to
express your opinion on how open source projects in general (and GCC in
particular) are run, but this Bugzilla isn't one of them. I'm giving you
technical help, and acknowledge the help you're giving the project by having
access to this specific target. Let's keep it constructive.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-03 14:11 --- And please stop CCing people! I'm taking care of this bug, and there really is no need to bother other people by sending them copies of all comments/investigation we exchange on the issue. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC|dje at watson dot ibm dot | |com, pinskia at gcc dot gnu | |dot org | AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-09-03 10:04:32 |2007-09-03 14:11:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #8 from burnus at gcc dot gnu dot org 2007-09-03 14:25 ---
One last question: in your build tree, you should have a file named
${builddir}/${target_triplet}/libgfortran/config.h. How does it define the
macros HAVE_LLROUND, HAVE_LLROUNDF, HAVE_LLROUNDL, HAVE_LROUND, HAVE_LROUNDF
and HAVE_LROUNDL?
That last question seems beyond my ken. I am running glibc-2.6.1
(the latest official).
That file should be in your case in
/var/tmp/43/build-159/powerpc-unknown-linux-gnu/libgfortran/config.h
- this might be different,
depending where you build gcc/gfortran; this was the
directory used in your bug description (comment #0)
The file is generated at configure time and thus specific to the system where
gcc/gfortran is build.
On my system (x86_64-unknown-linux-gnu, but also glibc-2.6), I have in the
equivalent file:
#define HAVE_LLROUND 1
#define HAVE_LLROUNDF 1
#define HAVE_LLROUNDL 1
#define HAVE_LLROUND 1
#define HAVE_LLROUNDF 1
#define HAVE_LLROUNDL 1
I would expect that your config.h has the same entries (as we both use a recent
glibc), but it would be great if you could confirm this.
The question is with which C compiler ( the latest Trunk, gcc-4.3.0?
4.1.current? 3.3.6 ? or 3.4.6? and even the junky 4.2.1)
As FX wants to check whether the C Library (glibc) works correctly, it should
not matter; but if you have the choice I would use gcc 4.3.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #1 from michelin60 at gmail dot com 2007-08-31 15:36 --- While I am properly logged in I did not even try using the attachment ptocess given the difficulties Torsten and myself had with PR33126 and PR33252 -- michelin60 at gmail dot com changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-31 16:36 --- Could you compile with -O0 -fdump-tree-original and attach the nint_3.f90.003t.original file (or similarly named)? Could you also run with -O1 -fdump-tree-optimized and attach nint_3.f90.115t.optimized (or similarly named)? Thanks! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|powerpc |powerpc-unknown-linux-gnu GCC host triplet|powerpc |powerpc-unknown-linux-gnu GCC target triplet|powerpc |powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
[Bug fortran/33271] nint_2.f90 abort compiled with -O0
--- Comment #3 from michelin60 at gmail dot com 2007-08-31 17:24 ---
Could you compile with -O0 -fdump-tree-original and attach the
nint_3.f90.003t.original file (or similarly named)? Could you also run with
-O1 -fdump-tree-optimized and attach nint_3.f90.115t.optimized (or similarly
named)?
No problem but some questions:
A) I see that you and others put a number of patches and regenerations. Do you
want me to rebootstrap and then do it? If an earlier version is acceptable do
you want using the test command as amended per above can I do outside of the
gcc tree?
If outside the tree I can do it right now. I also hope that the attachment
process works again. personally I had no problems until PR33252. I presume you
are in Europe with a 6 hour time difference.
I will do it on nint_2.f90 right now to try the attachment nint_3.f90 migh have
been a slip on your part. They are small thus not attached.
Original:
MAIN__ ()
{
real8 a;
int4 j2;
int8 i2;
int8 i1;
real4 b;
int4 j1;
static int4 options.0[7] = {68, 127, 0, 0, 0, 1, 0};
_gfortran_set_options (7, (void *) options.0);
a = 4.99944488848768742172978818416595459e-1;
i2 = 0;
i1 = (int8) __builtin_lround (a);
if (i1 != 0 || i2 != 0)
{
_gfortran_abort ();
}
a = 5.0e-1;
i2 = 1;
i1 = (int8) __builtin_lround (a);
if (i1 != 1 || i2 != 1)
{
_gfortran_abort ();
}
a = 5.00111022302462515654042363166809082e-1;
i2 = 1;
i1 = (int8) __builtin_lround (a);
if (i1 != 1 || i2 != 1)
{
_gfortran_abort ();
}
b = 4.99701976776123046875e-1;
j2 = 0;
j1 = (int4) __builtin_lroundf (b);
if (j1 != 0 || j2 != 0)
{
_gfortran_abort ();
}
b = 5.0e-1;
j2 = 1;
j1 = (int4) __builtin_lroundf (b);
if (j1 != 1 || j2 != 1)
{
_gfortran_abort ();
}
b = 5.0059604644775390625e-1;
j2 = 1;
j1 = (int4) __builtin_lroundf (b);
if (j1 != 1 || j2 != 1)
{
_gfortran_abort ();
}
a = 4.503599627370497e+15;
i1 = __builtin_llround (a);
i2 = 4503599627370497;
if (i1 != i2 || i1 != 4503599627370497)
{
_gfortran_abort ();
}
a = -4.503599627370497e+15;
i1 = __builtin_llround (a);
i2 = -4503599627370497;
if (i1 != i2 || i1 != -4503599627370497)
{
_gfortran_abort ();
}
}
Optimized: ?
;; Function MAIN__ (MAIN__)
Analyzing Edge Insertions.
MAIN__ ()
{
static int4 options.0[7] = {68, 127, 0, 0, 0, 1, 0};
bb 2:
_gfortran_set_options (7, options.0);
return;
}
Invalid sum of incoming frequencies 1, should be 9053
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271
