headers
Arjen Markus | 1 Jul 2011 14:39
Picon

Re: Problem building GCC

Hello,

Eric Botcazou concluded from all this mishap that the make utility under MinGW
was to blame. However, when I tried to build it on a Linux machine, I got this
error message:

make[3]: Leaving directory `/u/markus/tmp/gcc4.6.1/build-gcc/gcc'
mkdir -p -- x86_64-unknown-linux-gnu/libgcc
Checking multilib configuration for libgcc...
Configuring stage 1 in x86_64-unknown-linux-gnu/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for x86_64-unknown-linux-gnu-ar... ar
checking for x86_64-unknown-linux-gnu-lipo... lipo
checking for x86_64-unknown-linux-gnu-nm...
/u/markus/tmp/gcc4.6.1/build-gcc/./gcc/nm
checking for x86_64-unknown-linux-gnu-ranlib... ranlib
checking for x86_64-unknown-linux-gnu-strip... strip
checking whether ln -s works... yes
checking for x86_64-unknown-linux-gnu-gcc...
/u/markus/tmp/gcc4.6.1/build-gcc/./gcc/xgcc
-B/u/markus/tmp/gcc4.6.1/build-gcc/./gcc/
-B/u/markus/tmp/gcc4.6.1.bin/x86_64-unknown-linux-gnu/bin/
-B/u/markus/tmp/gcc4.6.1.bin/x86_64-unknown-linux-gnu/lib/ -isystem
/u/markus/tmp/gcc4.6.1.bin/x86_64-unknown-linux-gnu/include -isystem
/u/markus/tmp/gcc4.6.1.bin/x86_64-unknown-linux-gnu/sys-include
(Continue reading)

Permalink | Reply | 5 comments |
headers
Axel Freyn | 1 Jul 2011 15:53
Picon
Picon

Re: Problem building GCC


Hi Arjen,
On Fri, Jul 01, 2011 at 02:39:37PM +0200, Arjen Markus wrote:
> checking for suffix of object files... configure: error: in
> `/u/markus/tmp/gcc4.6.1/build-gcc/x86_64-unknown-linux-gnu/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.
> make[2]: *** [configure-stage1-target-libgcc] Error 1
> make[2]: Leaving directory `/u/markus/tmp/gcc4.6.1/build-gcc'
> make[1]: *** [stage1-bubble] Error 2
> make[1]: Leaving directory `/u/markus/tmp/gcc4.6.1/build-gcc'
> make: *** [all] Error 2
> 
> I am rather surprised that all of a sudden configure runs into a problem.
Look at
http://gcc.gnu.org/wiki/FAQ#Configuration_fails_with_.27.27configure:_error:_cannot_compute_suffix_of_object_files:_cannot_compile.27.27._What_is_the_problem.3F

your problem is well-known and spread ;-) Probably you're missing some
libraries like mpfr, gmp or mpc.
You should have an explanation of the error in 
/u/markus/tmp/gcc4.6.1/build-gcc/x86_64-unknown-linux-gnu/libgcc/config.log

Axel
Permalink | Reply | 4 comments |
headers
Arjen Markus | 1 Jul 2011 17:30
Picon

Re: Problem building GCC

Hi Axel,

no, I have built mpfr and the like already. I am now retrying with the
source code
of these packages copied into the GCC directory - that is a suggestion
in the installation
instructions (which I found after a hint by somebody else). Hope that
brings the
solution ;)

Regards,

Arjen

2011/7/1 Axel Freyn <axel-freyn <at> gmx.de>:
>
> Hi Arjen,
> On Fri, Jul 01, 2011 at 02:39:37PM +0200, Arjen Markus wrote:
>> checking for suffix of object files... configure: error: in
>> `/u/markus/tmp/gcc4.6.1/build-gcc/x86_64-unknown-linux-gnu/libgcc':
>> configure: error: cannot compute suffix of object files: cannot compile
>> See `config.log' for more details.
>> make[2]: *** [configure-stage1-target-libgcc] Error 1
>> make[2]: Leaving directory `/u/markus/tmp/gcc4.6.1/build-gcc'
>> make[1]: *** [stage1-bubble] Error 2
>> make[1]: Leaving directory `/u/markus/tmp/gcc4.6.1/build-gcc'
>> make: *** [all] Error 2
>>
>> I am rather surprised that all of a sudden configure runs into a problem.
> Look at
(Continue reading)

Permalink | Reply | 3 comments |
headers
Paul van Delst | 1 Jul 2011 19:02
Picon
Favicon

Re: SIGFPE, Arithmetic exception. "Value optimized out" when using --ffast-math

Hello,

Daniel Franke wrote:
> On Thursday 30 June 2011 21:34:19 Paul van Delst wrote:
>> Is there any other investigative work you could recommend I do to find the
>> root cause of the exception?
> 
> Hi Paul.
> 
> Besides a self contained testcase for everyone to check, depending on your 
> patience it might help to identify the exact offender; -ffast-math simply 
> enables a bunch of potentially unsafe options [1]:
> 
> -ffast-math
>     Sets -fno-math-errno, -funsafe-math-optimizations,
>     -fno-trapping-math, -ffinite-math-only, -fno-rounding-math, 
>     -fno-signaling-nans and fcx-limited-range. 
> 
> Try the options individually, all but one, other groups if required. 
> Identifying the bad one might give a clue?!

Trying the options one-by-one, it was the -funsafe-math-optimizations option that caused the program to
crash using
gfortran 4.4.4. We will give it a shot on gfortran 4.6.

I guess just the name of that option should raise a red flag, hey? :o)

cheers,

paulv
(Continue reading)

Permalink | Reply | 3 comments |
headers
Thomas Koenig | 1 Jul 2011 20:33
Picon
Favicon

Re: SIGFPE, Arithmetic exception. "Value optimized out" when using --ffast-math

Hi Paul,

> Trying the options one-by-one, it was the -funsafe-math-optimizations option that caused the program
to crash using
> gfortran 4.4.4. We will give it a shot on gfortran 4.6.
>
> I guess just the name of that option should raise a red flag, hey? :o)

Like the name says: It's fun, it's safe, and it does math optimizations.

	Thomas
Permalink | Reply | 0 comments |
headers
Tobias Burnus | 1 Jul 2011 20:39
Picon

Re: SIGFPE, Arithmetic exception. "Value optimized out" when using --ffast-math

Paul van Delst wrote:
> Trying the options one-by-one, it was the -funsafe-math-optimizations 
> option that caused the program to crash using gfortran 4.4.4. We will 
> give it a shot on gfortran 4.6.
>
> I guess just the name of that option should raise a red flag, hey? :o)

Maybe - depends how safe your code is ;-)

For this topic, I like to refer to the last item of "Manuals and other 
documentation" at http://gcc.gnu.org/wiki/GFortran#manuals

In particular: "Semantics of Floating Point Math in GCC" at 
http://gcc.gnu.org/wiki/FloatingPointMath
That page gives an overview about the level of IEEE 754 compliance of 
GCC with the different optimization flags. It should give an idea about 
which optimizations the compiler will do depending on the passed flag.

Usually, one wants to allow the compiler to do all optimizations, except 
those few which lead to relevant changes in the output - unfortunately, 
no such -foptimize_as_I_want flag exists. Thus, the solution is either 
to play save and avoid, e.g., -ffast-math - or to really carefully use 
such options. I think, only for benchmarks one can use -ffast-math 
without further thinking, though one might still need to tune the 
settings, if some threshold of the benchmark's result checking gets 
exceeded - or if one wants to get the maximal performance by turning on 
even more fast-math flags.

Tobias
(Continue reading)

Permalink | Reply | 1 comment |
headers
N.M. Maclaren | 2 Jul 2011 09:56
Picon
Picon
Favicon

Re: SIGFPE, Arithmetic exception. "Value optimized out" when using --ffast-math

On Jul 1 2011, Tobias Burnus wrote:
>Paul van Delst wrote:
>
>> Trying the options one-by-one, it was the -funsafe-math-optimizations 
>> option that caused the program to crash using gfortran 4.4.4. We will 
>> give it a shot on gfortran 4.6.
>>
>> I guess just the name of that option should raise a red flag, hey? :o)
>
>Maybe - depends how safe your code is ;-)

Precisely.  This is one area whether the effect of IEEE 754 has been
extremely harmful, by encouraging mistaken thinking.  Back in the days
when we wrote code to run unchanged on a truly bizarre collection of
compilers and floating-point units, every experienced programmer of
portable code knew how to write (fairly) safe code.  That skill is now
rare.

Despite common belief, what constitutes an arithmetically exceptional
condition is undefined in all languages except Java and a few others,
and the Fortran standard clearly states that it allows aggressive
optimisations and does not define behaviour on exceptions.  That is
also true for C and C++, though it is less clear or well-understood.

>Usually, one wants to allow the compiler to do all optimizations, except 
>those few which lead to relevant changes in the output - unfortunately, 
>no such -foptimize_as_I_want flag exists. ...

Largely because of the lack of the DWIM instruction :-)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Richard Thomas | 2 Jul 2011 10:29
Picon

Re: [Patch, Fortran, F08] PR 49562: [4.6/4.7 Regression] [OOP] assigning value to type-bound function

OK for trunk and 4.6.

Thanks for the patch

Paul

On Tue, Jun 28, 2011 at 5:40 PM, Janus Weil <janus <at> gcc.gnu.org> wrote:
> Hi all,
>
> here is a patch for a problem which was originally reported as an
> ICE-on-invalid regression (assigning to a type-bound function).
>
> In the course of fixing it, I noticed that it becomes valid according
> to F08 if the function is pointer-valued, and modified the patch such
> that it will accept this variant. I also adapted the original test
> case to be a run-time test of this F08 feature (in fact it is just a
> very complicated way of performing an increment from 0 to 1, and would
> still segfault without the patch).
>
> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.6.2?
>
> Cheers,
> Janus
>
>
>
> 2011-06-28  Janus Weil  <janus <at> gcc.gnu.org>
>
>        PR fortran/49562
>        * expr.c (gfc_check_vardef_context): Handle type-bound procedures.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Richard Thomas | 2 Jul 2011 11:38
Picon

Re: gfortran misses uninit vars in contained subroutines

Dear Bill,

Adding another variable within t does generate the uninitialized warning:
        subroutine t
        integer :: z
        y = x * 5 * z
        end subroutine t

Clearly, the declaration of x and y in the containing scope eliminates
the check, presumably, because they could be initialized by another
subroutine and call tree analysis is not being done for this check.

I say 'presumably' because gfortran hitches a ride from gcc for this
check.  The warning is generated in gcc/tree-ssa.c and
gcc/tree-ssa-uninit.c, which I cannot say that I am familiar with.
This is confirmed by the following:

[prt <at> localhost tmp]# cat test.c
static int y;

int
main (void)
{
  int x, z;
  x = y;
  x = z;
}

[prt <at> localhost tmp]# gcc -Wuninitialized -O test.c
test.c: In function ‘main’:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dominique Dhumieres | 2 Jul 2011 14:36
Picon
Picon
Favicon

Re: SIGFPE, Arithmetic exception. "Value optimized out" when using --ffast-math

Paul,

> Trying the options one-by-one, it was the -funsafe-math-optimizations
> option that caused the program to crash using gfortran 4.4.4.

Could you try 
-O3 -funsafe-math-optimizations -ffinite-math-only -fno-reciprocal-math
and
-O3 -funsafe-math-optimizations -ffinite-math-only -fno-tree-vectorize
?

What you describe reminds me pr43716
( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 ).
This pr appeared and disappeared without convincing explanation
and could be a rampant bug exposed by your code. Does it contain
constructs such as the one in comment #13?

> I guess just the name of that option should raise a red flag, hey? :o)

I am not sure that the name has been well chosen. I rather think
that code that are not surviving associative-math or reciprocal-math
are themselves unsafe.

Cheers,

Dominique
Permalink | Reply | 8 comments |

Gmane