Re: Including GMP/MPFR in GCC repository?
First, please note that having gfortran testresults for one platform
only means that "some version of the compiler was able to correctly
compile GMP & MPFR", not that "GCC trunk is able to correctly compile
GMP & MPFR". Nevertheless:
* i386-unknown-freebsd (alpha-unknown-freebsd5.4)
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01072.html
I can confirm that GMP & MPFR build fine and run their testsuite
cleanly on i386-unknown-freebsd{4.7,5.4,5.11}. I know Steve Kargl uses
this on x86_64-unknown-freebsd6.1 and it works fine.
As for other BSDs, I can confirm that GMP & MPFR build and run their
testsuite fine on i386-unknown-netbsd2.0.2,
i386-unknown-openbsd{3.7,3.8}.
* sparc-sun-solaris2.10
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01273.html
I can also confirm that GMP & MPFR build and run fine on
i386-unknown-solaris2.9.
* ia64-unknown-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01826.html
I my experience, GMP & MPFR do also work fine on ia64-hpux, but that
requires a recent GMP version (>= 4.2.0, if I remember correctly;
before that, the configury didn't work well for ia64-hpux).
Also, I have had GMP & MPFR building and testing fine on alpha-linux
for some time.
Finally, as S/390 GNU/Linux seems to be considered for inclusion into
this list, it is worthy to note that gfortran is built & regtested on
this platform and variants regularly.
FX
[bugzilla] Remove libf2c component
Hi all, I'm not sure whom to write about the workings of the GCC bugzilla database, so I'm writing here and CCing Daniel Berlin, since IIRC he handles part of that work. I think it would be nice (although not high priority) to remove the libf2c component in bugzilla, since we don't ship libf2c anymore now that 3.4 branch is extinct. There are no active bugs in it, the last open bugs were closed as WONTFIX by Gabriel dos Reis. Technically, I don't know what will happen to old bugs with this component, but at least we shouldn't propose that as a component to people reporting new bugs. FX
Re: libgfortran still fails to build for sh-elf
And why would you think (twice) that the best place for reporting this
is neither the gfortran mailing-list, nor bugzilla?
I suggest that you test the following patch and report back to us:
Index: libgfortran/runtime/error.c
===
--- libgfortran/runtime/error.c (revision 118806)
+++ libgfortran/runtime/error.c (working copy)
@@ -285,7 +285,7 @@
if (!options.locus || cmp == NULL || cmp->filename == NULL)
return;
- st_printf ("At line %d of file %s\n", cmp->line, cmp->filename);
+ st_printf ("At line %ld of file %s\n", (long int) cmp->line, cmp->filename);
}
Re: libgfortran still fails to build for sh-elf
I suggest that you test the following patch and report back to us:
I got the patch wrong (it's not a real printf function we have there):
Index: libgfortran/runtime/error.c
===
--- libgfortran/runtime/error.c (revision 118806)
+++ libgfortran/runtime/error.c (working copy)
@@ -285,7 +285,7 @@
if (!options.locus || cmp == NULL || cmp->filename == NULL)
return;
- st_printf ("At line %d of file %s\n", cmp->line, cmp->filename);
+ st_printf ("At line %d of file %s\n", (int) cmp->line, cmp->filename);
}
Re: [RFC] Our release cycles are getting longer
[sorry for breaking the thread; stupid gmail doesn't want to add custom References headers] It may be that not too many people pick up 4.2.0. But, if 4.3 isn't looking very stable, there will be a point when people decide that 4.2.0 is looking very attractive. The worst outcome of trying to do a 4.2.0 release is that we'll fix some things that are also bugs in 4.3; most 4.2 bugs are also in 4.3. From the Fortran point of view, and however limited it might be, skipping the 4.2.0 release would be very unfortunate. We've been working hard on it, and especially in recent time, many bug fixes have been deemed to risky to backport to the 4.1 branch. 4.3 is still a long way down the road, and the 4.2 branch has interesting features even from the non-Fortran point of view. About the other points of the discussion, maybe getting more exposure for the mainline branch (4.3.0) could get us more feedback? People are more involved in fixing bugs when they come just after their patch commit than when the report comes one month after. (and I can thing of examples in our bugzilla that confort this view :) Now, how to get greater exposure? We (some of the gfortran maintainers) have been making available regular binaries of the compiler for common archs; most of the bug reports are made from people using these binaries, so I suppose it's a way that works for us. There are a few people that help with gfortran development, not by patching, but by testing/filing detailed bug reports/writing testcases/etc. (They even tend to get involved in gfortran patching at some point :) Can it work for GCC as a whole? Maybe not for all types of bugs and users (the Fortran users mostly have mainstream archs), but we could nonetheless use more feedback and maybe have more people testing their apps with the latest mainline state. Sorry for being so long, but maybe the gfortran experience can help here, FX
Who should fix platforms broken by extern inline hack?
Hi all, There are two platforms on which mainline is broken: * bootstrap is broken for i386-netbsd, see PR30058 * the compiler built on i386-mingw32 is unusable, see PR30589 Both regressions were introduced by Geoffrey Keating (http://gcc.gnu.org/ml/gcc-patches/2006-11/msg3.html) in a "C99 extern inline" patch. Fixincludes were then created for glibc systems. In both cases, I'm ready to debug (I attached the full preprocessed source of minimal examples to both PR) and test patches, but I simply don't know whom I should ping to get bootstrap working again: Geoffrey, who introduced the change that broke so many platforms, or the maintainers for these branches? (it might be worth noting at that point that netbsd doesn't have a maintainer listed) There has been some amount of chatting recently about the development plan for GCC, and I think we can all agree that having broken bootstrap for months on some platform don't help us get more testing :) Thanks for helping me understand the workings of the GCC community, FX
Re: Who should fix platforms broken by extern inline hack?
As it turns out, I do now have access to a NetBSD system, and will look at that problem when I next get time. Thanks. When you provid a patch, I will test it. (If someone else ever wants access to a netbsd system, it's worth noting there's one on the GCC compile farm!) My understanding from 30589 is that a sufficiently recent version of mingw32 has solved the problem. The CVS version of mingw32 has the workaround, but most people aren't using the CVS mingw32 (most people aren't using the last released version anyway), so there'll be a need for a fix anyway. FX
Coldfire doc glitch
Hi Richard, I found the following in my build logs, and thought it was worth reporting to you. Although I don't speak texinfo, the lines in questions are the ones introduced by your ColdFire 9/63 patch (commited as rev. 120713): perl /home/fxcoudert/gfortran_nightbuild/trunk/gcc/../contrib/texi2pod.pl /home/fxcoudert/gfortran_nightbuild/trunk/gcc/doc/invoke.texi > gcc.pod @table ended by @end multitable at line 10424 make[3]: [gcc.pod] Error 9 (ignored) Thanks, FX
Performance regression on the 4.3 branch?
I noticed a performance regression on the following code:
$ cat a.c
#include
#include
void
add256 (uint64_t x[4], const uint64_t y[4])
{
unsigned char carry;
x[0] += y[0];
carry = (x[0] < y[0]);
x[1] += y[1]+carry;
carry = carry ? (x[1] <= y[1]) : (x[1] < y[1]);
x[2] += y[2]+carry;
carry = carry ? (x[2] <= y[2]) : (x[2] < y[2]);
x[3] += y[3]+carry;
}
int
main (void)
{
int i;
uint64_t x[4], y[4];
x[0] = 0; x[1] = 0; x[2] = 0; x[3] = 0;
y[0] = 0x0123456789abcdefULL;
y[1] = 0xfedcba9876543210ULL;
y[2] = 0xdeadbeeff001baadULL;
y[3] = 0x001001001001ULL;
for ( i=0 ; i<1 ; i++ )
add256 (x, y);
printf ("%016llx%016llx%016llx%016llx\n",
(unsigned long long)x[3],
(unsigned long long)x[2],
(unsigned long long)x[1],
(unsigned long long)x[0]);
return 0;
}
$ gcc -march=pentium4 -O3 a.c && time ./a.out
064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00
./a.out 1.81s user 0.00s system 99% cpu 1.818 total
$ gcc-4.3 -march=pentium4 -O3 a.c && time ./a.out
064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00
./a.out 2.40s user 0.01s system 87% cpu 2.746 total
where gcc is gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) and gcc-4.3
is gcc version 4.3.0 20070209 (experimental). I don't have a 4.1 or
4.2 compiler at hand, so I don't know if it's a 4.2 or 4.3 regression,
or even if there's a special patch in redhat 4.1 that makes it
lightning fast. But in any case, I wondered if it was known, and if it
was worth opening a PR.
Thanks,
FX
Re: Detemining the size of int_fast8_t etc. in the frontend
Hi Tobias, What is the proper way to obtain this information? I fear the answer to this question is "there's no way". We already discussed that a few months ago, at the thread starting here: http:// gcc.gnu.org/ml/gcc/2006-10/msg00346.html From private discussion, with Paul Brook & Joseph Myers IIRC, the conclusion is that GCC can't do that right now, but it could if target-specific files provided the information. Maybe there's a PR open for that, otherwise you can open it, and we can try to get people implement the framework for this... Christopher's original ISO_C_BINDING patch used autoconf to guess it, and I remove that (before creating the fortran-experiments branch). Currently, there's no other option than to return -2 for the corresponding ISO_C_BINDING constants. FX smime.p7s Description: S/MIME cryptographic signature
Re: symbol names are not created with stdcall syntax: MINGW, (GCC) 4.3.0 20061021
Thus we may consider adding a -fstdcall option to gfortran, which
appends the @n. The -mrtd would be needed additionally and it seems to
work. (That I don't get @n in C for __stdcall might because I tested
under Linux.)
On mingw, I get the following:
$ cat a.c
int foo(int x) { return x+1; }
$ gcc.exe -mrtd a.c -shared -o a.dll
$ nm a.dll | grep foo
100011c0 T _foo
$ cat b.c
int __stdcall foo(int x) { return x+1; }
$ gcc.exe b.c -shared -o b.dll
$ nm b.dll | grep foo
100011c0 T [EMAIL PROTECTED]
$ gcc.exe b.c -shared -o b.dll -mrtd
$ nm b.dll | grep foo
100011c0 T [EMAIL PROTECTED]
I think -mrtd doesn't change the name. Maybe GCC needs another option
to add the name decoration automatically? CCing the GCC list and Danny
S. for this question.
FX
Re: symbol names are not created with stdcall syntax: MINGW, (GCC) 4.3.0 20061021
It might be considered a backend issue, but in general it is a binutils (so OP is in the wrong list!). I beg to disagree with the "in general it is a binutils issue" part. One of the posters explained why the information needed for name decoration can't be determined at link-time (nor at assembly-time, from what I understood). I think it's completely a compiler issue: if there's a switch (-mrtd) to change the calling convention of the generated code, there should probably be another one to also change the naming convention accordingly. On a related note, I found in gcc/config/i386/i386.c the following comment: "The attribute stdcall is equivalent to RTD on a per module basis." I think it's not true wrt to naming convention. I otherwise perfectly agree with you about not adding yet another extension to the Fortran front-end. FX
Find the longest float type nodes
Hi all, I'm working on implementing a correct Fortran rounding (rounding to nearest-integer, with half integer values rounded to the integer of maximum absolute value) in the Fortran front-end, following ada/trans.c (convert_with_check) and http://gcc.gnu.org/ml/fortran/2005-04/msg00139.html The code Ada uses to do it has the following comments: /* The following calculations depend on proper rounding to even of each arithmetic operation. In order to prevent excess precision from spoiling this property, use the widest hardware floating-point type. FIXME: For maximum efficiency, this should only be done for machines and types where intermediates may have extra precision. */ calc_type = longest_float_type_node; /* FIXME: Should not have padding in the first place */ if (TREE_CODE (calc_type) == RECORD_TYPE && TYPE_IS_PADDING_P (calc_type)) calc_type = TREE_TYPE (TYPE_FIELDS (calc_type)); I have the three following questions, probably best directed to middle-end experts and Ada maintainers: * How can I know the longest float type? My first patch uses the long_double_type_node unconditionally, but it surely isn't a generic solution * How can I determine if a given type may have extra precision? * What is this padding code doing, and is it necessary? Thanks, FX
Has insn-attrtab.c been growing in size recently?
Hi all, A bootstrap attempt of GCC mainline on a i386-unknown-netbsdelf2.0.2 with: Memory: 378M Act, 264M Inact, 3520K Wired, 4664K Exec, 633M File, 151M Free Swap: 129M Total, 129M Free failed due to a compilation error in stage1: cc1: out of memory allocating 138677280 bytes after a total of 31484356 bytes make: *** [insn-attrtab.o] Error 1 The system compiler is gcc version 3.3.3 (NetBSD nb3 20040520). Last time I tried on this same computer was on 2006-12-03, and it passed stage1 OK. So I wonder what recent changes could have affected insn-attrtab.c on this target, and whether there could be a way to get it down in size. Thanks, FX
Re: 4.3 bootstrap broken on i386-linux
My nightly bootstrap of mainline on i386-linux failed tonight, on revision 123192. This issue is still not fixed as of now. A diff was posted to PR31344 with the mention "This isn't a real patch." Is a real patch planned in the near future, or is there any other short-time plan to get i386-linux bootstrap back? FX
Re: 4.3 bootstrap broken on i386-linux
is there any other short-time plan to get i386-linux bootstrap back? Just configure gcc with --disable-decimal-float. I don't think dfp works on x86 very well. Thanks for suggesting --disable-decimal-float. Note that, in my above sentence, "any other short-time plan" includes disabling it by default on that arch (temporarily or forever), as long as it allows bootstrap with the "configure && make". FX
Re: Google Summer of Code: Mentor wanted for Fortran project
I tried to apply on the SoC website, but the application form only reloaded when I hit "Become a mentor", neither saying if it worked or didn't work. So, I hope it worked. Can someone check it (Ian, maybe?) Problem fixed. The Google form doesn't work if you 1) use Safari and 2) come from a country with no notion of State or Province. FX smime.p7s Description: S/MIME cryptographic signature
Build a function call with variable number of arguments
Hi all, Could someone give me a pointer to doc or code about building a function decl and function call expr that take a variable number of arguments (like printf)? Thanks, FX
Bootstrap broken on i386-pc-mingw32
Hi Zack, hi all, A bootstrap of GCC mainline, rev. 123324, fails because of: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../trunk/gcc -I../../trunk/gcc/build -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I/home/coudert/local/include -I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/dpd -I../libdecnumber-o build/rtl.o ../../trunk/gcc/rtl.c In file included from ../../trunk/gcc/ggc.h:40, from ../../trunk/gcc/rtl.c:35: ./gtype-desc.h:64: error: expected identifier before ',' token Line 64 of gtype-desc.h is the line with "gt_ggc_e_10stmt_gr,," in the following: gt_ggc_e_18gnat_binding_level, gt_ggc_e_9elab_info, gt_ggc_e_10stmt_gr,, gt_ggc_e_20ssa_operand_memory_d, gt_ggc_e_6subvar, The ",," is clearly wrong; there's another one later in this same file: gt_ggc_e_13convert_optab, gt_ggc_e_5optab, gt_ggc_e,,, gt_ggc_e_10real_value, gt_ggc_e_10VEC_rtx_gc, I'm CCing Zack, as there was a change in that code recently (last time I did a mingw32 build was on 2007-03-22, ie before that patch, and the bootstrap was successful). I'm willing to help and provide any generated files that may help to track this one down. PS: I've launched a cross build to see if I can reproduce it there, which would of course make it easier for tracking down. FX
Re: Bootstrap broken on i386-pc-mingw32
I'm CCing Zack Away on vacation until March 31st, said the automated reply. PS: I've launched a cross build to see if I can reproduce it there, which would of course make it easier for tracking down. Works OK on the cross. So, it's probably a host problem in gengtype. It appears to exist on HPUX as well, as Steve noted. FX
Re: Bootstrap broken on i386-pc-mingw32
Yeah, it appears I was overly optimistic in hoping vsnprintf() would do what C99 says it does. I do not have access to any system that shows the problem, but I've attached a patch that should fix it (it just reverts the oprintf() changes, which were not really necessary, I was just trying to be more efficient). Thanks, that fixes it for me on i386-pc-mingw32. FX
Re: Gcc and gfortran installation on MacBook Pro
Hi Aurélien, A few remarks: 1. you don't show us the actual compilation error message: why is make failing? 2. maybe you don't know, but there are binaries available from http://gcc.gnu.org/wiki/GFortranBinaries, if that helps. 3. you should definitely quote the system compiler and cctools version you use. FX
Re: Gcc and gfortran installation on MacBook Pro
out_make is the output of the make. In fact it is the output of the make launch a second time. (To big otherwise.) Yes, but it's missing the standard error file. Please use: make > out_make 2> err_make or something similar. FX
Re: GCC 4.2.0 Status Report (2007-04-15)
You want more bugs fixed, it would seem a better way would be to build a better sense of community (Have bugfix-only days, etc) and encourage it through good behavior, not through negative reinforcement. I do agree with that in a general way, but I think there should also be a real effort done by the various maintainers to make sure people indeed fix the few PRs they created. Maintainers should be able to say, "please think of fixing this PR before submitting a patch for that feature". That doesn't introduce administrative overhead, because maintainers should keep track of the various PRs and patches of their area. I think it works already for some areas of the compiler, but doesn't work fine for the "most common" areas. A few examples of that (maybe I'm always quoting the same examples, but those are the ones I know that impact my own work on GCC): -- how can bootstrap stay broken (with default configure options) on i386-linux for 3 weeks? -- how could i386-netbsd bootstrap be broken for months (PR30058), and i386-mingw still be broken after 6 months (PR30589), when the cause of failure is well known? These are not rethorical "How", or finger-pointing. I think these are cases of failure we should analyze to understand what in our development model allows them to happen. FX
Re: GCC 4.2.0 Status Report (2007-04-15)
The "mea culpa" is to permit for long time to modify "configure" instead of "configure.ac" or "configure.in" that is used by "autoconf" and/or "automake". [...] I'm sorry, but I don't understand at all what you propose, what your proposal is supposed to fix or how that is related to the mail you're answering to. FX
Re: GCC 4.2.0 Status Report (2007-04-15)
libdecnumber/aclocal.m4:# generated automatically by aclocal 1.9.5 -*- Autoconf -*- That's a problem in the last regeneration of this file. I'm CCing M. Meissner, H. J. Lu and M. Cornea, since they appear to have last changed this file, although there's no ChangeLog entry for it in their commit. PS: it appears that it has been update two days ago by bonzini, and the new version has been generated with aclocal 1.9.6. 1) To update the generated configure scripts of the tarball before than distributing it. It could be done, but there's the risk that an automated process like that might introduce problems. I'd be more in favour of a nightly tester that check the "Generated by" headers to see if anything has an unexpected version number. 2) Or to remove the non-updated configure scripts. That's a annoyance, because it would require the autotools to build the GCC source, which is inconvenient. FX
New option: -fstatic-libgfortran
Hi all,
Attached is a first draft of a patch to add a -fstatic-libgfortran
option. This new option is recognized by the driver and instead of
adding "-lgfortran" to the various subprocesses, it adds "-Wl,-Bstatic
-lgfortran -Wl,-Bdynamic". I have two questions about this:
+ linkers other than the GNU linker might have problems with that.
is there a more general way of doing this? or should it be conditional
on some macro, like HAVE_LD_STATIC_DYNAMIC?
+ when -static is used later in the command line, this trick doesn't
work; would "%{!static:-Wl,-Bstatic} -lgfortran
%{!static:-Wl,-Bdynamic}" be a good replacement?
Thanks for the help, I'm a bit a loss with non-GNU linkers... :(
FX
Index: lang.opt
===
--- lang.opt (revision 123942)
+++ lang.opt (working copy)
@@ -249,6 +249,10 @@
Fortran
Use the narrowest integer type possible for enumeration types
+fstatic-libgfortran
+Fortran
+Statically link the GNU Fortran helper library (libgfortran)
+
funderscoring
Fortran
Append underscores to externally visible names
Index: options.c
===
--- options.c (revision 123942)
+++ options.c (working copy)
@@ -549,6 +549,9 @@
gfc_option.flag_second_underscore = value;
break;
+case OPT_fstatic_libgfortran:
+ break;
+
case OPT_fimplicit_none:
gfc_option.flag_implicit_none = value;
break;
Index: gfortranspec.c
===
--- gfortranspec.c (revision 123942)
+++ gfortranspec.c (working copy)
@@ -82,6 +82,7 @@
-nodefaultlibs. */
OPTION_o, /* Aka --output. */
OPTION_S, /* Aka --assemble. */
+ OPTION_static_libgfortran, /* -fstatic-libgfortran. */
OPTION_syntax_only, /* -fsyntax-only. */
OPTION_v, /* Aka --verbose. */
OPTION_version, /* --version. */
@@ -170,6 +171,8 @@
opt = OPTION_nostdlib;
else if (!strcmp (text, "-fsyntax-only"))
opt = OPTION_syntax_only;
+ else if (!strcmp (text, "-fstatic-libgfortran"))
+ opt = OPTION_static_libgfortran;
else if (!strcmp (text, "-dumpversion"))
opt = OPTION_version;
else if (!strcmp (text, "-fversion")) /* Really --version!! */
@@ -265,6 +268,9 @@
/* By default, we throw on the math library if we have one. */
int need_math = (MATH_LIBRARY[0] != '\0');
+ /* Whether we should link a static libgfortran. */
+ int static_lib = 0;
+
/* The number of input and output files in the incoming arg list. */
int n_infiles = 0;
int n_outfiles = 0;
@@ -323,6 +329,10 @@
library = 0;
break;
+ case OPTION_static_libgfortran:
+ static_lib = 1;
+ break;
+
case OPTION_l:
++n_infiles;
break;
@@ -468,11 +478,28 @@
append_arg (FORTRAN_INIT);
use_init = 1;
}
+
+ if (static_lib)
+ append_arg ("-Wl,-Bstatic");
append_arg (FORTRAN_LIBRARY);
+ if (static_lib)
+ append_arg ("-Wl,-Bdynamic");
}
}
else if (strcmp (argv[i], FORTRAN_LIBRARY) == 0)
- saw_library = 1; /* -l. */
+ {
+ saw_library = 1; /* -l. */
+
+ if (static_lib)
+ append_arg ("-Wl,-Bstatic");
+
+ append_arg (argv[i]);
+
+ if (static_lib)
+ append_arg ("-Wl,-Bdynamic");
+
+ continue;
+ }
else
{ /* Other library, or filename. */
if (saw_library == 1 && need_math)
@@ -498,7 +525,12 @@
append_arg (FORTRAN_INIT);
use_init = 1;
}
+
+ if (static_lib)
+ append_arg ("-Wl,-Bstatic");
append_arg (library);
+ if (static_lib)
+ append_arg ("-Wl,-Bdynamic");
case 1:
if (need_math)
append_arg (MATH_LIBRARY);
Re: New option: -fstatic-libgfortran
Sorry about the (possibly off) question: would this apply also to GMP/MPFR, if not, wouldn't it make sense? GMP and MPFR are host libraries, so it is actually an independent issue. However, it might be worth having --with-static-gmp and --with-static-mpfr to request static linking of these libraries into the compiler. I think I suggested the idea (maybe even a patch, but I can't find it in the mailing-list archives) when gmp/mpfr was still only used by Fortran. In the end, some people will think it's stretching the configury too much for a specific purpose, and some people will think it's just a good option to have. (I'm in the second group.) Let's wait and see what people think of the idea. FX
Re: Processor-specific code
Can you explain in a little more detail what you are trying to accomplish? gfortran can already pass the -m and -f options suppported by gcc. For example, -ffast-math works. Runtime library reads GFORTRAN_FPU_* environment variables if they exist, and set up the FPU accordingly. One other thing to keep in mind, at some point we'll want to implement TR 15880. Are there any potential conflicts? No, since reading GFORTRAN_FPU_* variables changes the FPU mode when the library is loaded, while TR 15580 commands will be ran afterwards (during execution). Of course, when the code for GFORTRAN_FPU_* is written (which is much easier than full TR 15580 support), we can use it for TR 15580. FX
Re: Processor-specific code
[speaking of an environnement variable used to set IEEE rounding mode] You'll find that globally changing the rounding mode will screw up libm functions. Which is pretty much going to make this useless. Further, when folks need rounding modes other than round-to-nearest, they tend to need to switch rounding modes during the program too. For instance, to perform the same calculation with both round-up and round-down to get error bounds on the calculation. Thus I think an environment variable to do this is doubly useless. Understood. I only tried to write that code because the mechanism for reading these environment variables is already in the source (as well as documentation on what effect they should have). Currently, when the runtime library is loaded, it look at: GFORTRAN_FPU_ROUND: Set floating point rounding. Values are NEAREST, UP, DOWN, ZERO. GFORTRAN_FPU_PRECISION: Precision of intermediate results. Values are 24, 53 and 64. GFORTRAN_FPU_INVALID: Raise a floating point exception on invalid FP operation. GFORTRAN_FPU_DENORMAL: Raise a floating point exception when denormal numbers are encountered. GFORTRAN_FPU_ZERO: Raise a floating point exception when dividing by zero. GFORTRAN_FPU_OVERFLOW: Raise a floating point exception on overflow. GFORTRAN_FPU_UNDERFLOW: Raise a floating point exception on underflow. GFORTRAN_FPU_PRECISION: Raise a floating point exception on precision loss. So, if we all agree that some of those are useless, we should remove them from the code. My humble opinion is: 1. I don't think GFORTRAN_FPU_PRECISION is useful 2. GFORTRAN_FPU_INVALID and all other FPE control options are very useful, and we want to implement those ones (this is really something one could want to turn on at runtime, perhaps just to debug one's code). 3. GFORTRAN_FPU_ROUND: I have no precise idea (in the long term, we will provide subroutines so that the code can control rounding mode). All that said, C99 has to control just about anything you could want about the fpu. As the linux manpage for "The C99 standard does not define a way to set individual bits in the floating point mask, e.g. to trap on specific flags." So, unless I am mistaken, if you want to raise a FPE on dividing by zero, there is no C99 way to do it. So I guess we will have to write some non-standard C at some point. Linux provide feenableexcept, but on darwin I don't know any way to do that without using assembly code. See Arnaud's link for a compilation of tricks people have used to do this. FX
Re: Processor-specific code
I believe that you understand incorrectly. Of course, you're right. We can choose not to support alteration of rounding mode, but we might want to add that nice feature into gfortran. So, I'll stop invoking the standard, but I still think it would be interesting. Of course, since noone seems to think that way, I won't bother you anymore with my FPU-related whims. FX
Re: Cygwin build failure
> Knowing that you do regular Cygwin builds of gcc, I wonder can you advise > me, please? For the better part of a month, I have not succeeded in > building gcc from the CVS tree under Cygwin_NT-5.1 for one reason or > another. That's PR 21766 (appropriately named "Bootstrap failure on i686-pc-cygwin"). Opened almost a month ago. GCC mainline doesn't build on cygwin or mingw since that time. Seeing that almost no comment had been made by the maintainers on it, and no correct patch proposed, it looks like we're gonna have to live with it for a long time... :( Short-time answer: patches provided in bugzilla don't fix the problem, but they should enable you to build successfully (and then, the problem shouldn't really appear in gfortran). Long-time answer: well, I cc this mail to gcc@gcc.gnu.org and maintainers so that we can have a hint whether this is going to be fixed soon or not. FX PS: Detailled info on your problems: > /usr/include/stdint.h:18: error: conflicting types for 'int8_t' > ../../../gcc/libgfortran/libgfortran.h:63: error: previous declaration of > 'int8_t' was here This one is because you're reconfiguring in a non-empty tree. There is a PR number for it, but I don't remember it... > ../../../gcc/libgfortran/runtime/environ.c:104: error: invariant not > recomputed when ADDR_EXPR changed > &_ctype_D.1954[1]; This one is due to the bootstrap failure (PR 21766).
Add clog10 to builtins.def, round 2
The fortran front-end needs to recognize clog10, clog10f and clog10l a proper built-ins. Attached patch tries to add them to clog10, under a new category: DEF_EXT_C99RES_BUILTIN (as suggested by jsm28). Can someone review this? Is it OK? Thanks, François-Xavier Index: gcc/builtins.def === RCS file: /cvsroot/gcc/gcc/gcc/builtins.def,v retrieving revision 1.104 diff -u -3 -p -r1.104 builtins.def --- gcc/builtins.def 25 Jun 2005 01:59:13 - 1.104 +++ gcc/builtins.def 29 Jun 2005 21:25:38 - @@ -119,6 +119,13 @@ Software Foundation, 51 Franklin Street, DEF_BUILTIN (ENUM, "__builtin_" NAME, BUILT_IN_NORMAL, TYPE, TYPE, \ true, true, !flag_isoc99, ATTRS, TARGET_C99_FUNCTIONS, true) +/* Builtin that C99 reserve the name for future use. We can still recognize + the builtin in C99 mode but we can't produce it implicitly. */ +#undef DEF_EXT_C99RES_BUILTIN +#define DEF_EXT_C99RES_BUILTIN(ENUM, NAME, TYPE, ATTRS) \ + DEF_BUILTIN (ENUM, "__builtin_" NAME, BUILT_IN_NORMAL, TYPE, TYPE, \ + true, true, true, ATTRS, false, true) + /* Allocate the enum and the name for a builtin, but do not actually define it here at all. */ #undef DEF_BUILTIN_STUB @@ -436,6 +443,9 @@ DEF_C99_BUILTIN(BUILT_IN_CIMAGL, DEF_C99_BUILTIN(BUILT_IN_CLOG, "clog", BT_FN_COMPLEX_DOUBLE_COMPLEX_DOUBLE, ATTR_MATHFN_FPROUNDING) DEF_C99_BUILTIN(BUILT_IN_CLOGF, "clogf", BT_FN_COMPLEX_FLOAT_COMPLEX_FLOAT, ATTR_MATHFN_FPROUNDING) DEF_C99_BUILTIN(BUILT_IN_CLOGL, "clogl", BT_FN_COMPLEX_LONGDOUBLE_COMPLEX_LONGDOUBLE, ATTR_MATHFN_FPROUNDING) +DEF_EXT_C99RES_BUILTIN (BUILT_IN_CLOG10, "clog10", BT_FN_COMPLEX_DOUBLE_COMPLEX_DOUBLE, ATTR_MATHFN_FPROUNDING) +DEF_EXT_C99RES_BUILTIN (BUILT_IN_CLOG10F, "clog10f", BT_FN_COMPLEX_FLOAT_COMPLEX_FLOAT, ATTR_MATHFN_FPROUNDING) +DEF_EXT_C99RES_BUILTIN (BUILT_IN_CLOG10L, "clog10l", BT_FN_COMPLEX_LONGDOUBLE_COMPLEX_LONGDOUBLE, ATTR_MATHFN_FPROUNDING) DEF_C99_BUILTIN(BUILT_IN_CONJ, "conj", BT_FN_COMPLEX_DOUBLE_COMPLEX_DOUBLE, ATTR_CONST_NOTHROW_LIST) DEF_C99_BUILTIN(BUILT_IN_CONJF, "conjf", BT_FN_COMPLEX_FLOAT_COMPLEX_FLOAT, ATTR_CONST_NOTHROW_LIST) DEF_C99_BUILTIN(BUILT_IN_CONJL, "conjl", BT_FN_COMPLEX_LONGDOUBLE_COMPLEX_LONGDOUBLE, ATTR_CONST_NOTHROW_LIST)
Re: Add clog10 to builtins.def, round 2
>> * builtins.def: Add DEF_EXT_C99RES_BUILTIN to define builtins >> that C99 reserve for future use. Use it to define clog10, clog10f >> and clog10l. > > Ok. Commited. Thanks, FX
Re: PING [4.1 regression, patch] build i686-pc-mingw32
Coming back to this topic. Nobody has answered to one of my questions: if the mingw/cygwin maintainers can't approve such a patch, who can? FX
Middle-end and optimization regressions: what should we do?
Hi all, PR 22619 and PR 22509 are two examples of recent 4.1 regressions that showed up in gfortran, due to middle-end or optimization bugs (only happen at -O3). Since these are regressions, they should be treated before a long time passes, but since both source codes are Fortran, I guess people don't (and won't) want to look at them. How can we help here? Is there a way to make gfortran output a complete GIMPLE tree, that could be used for middle-end hackers to determine where the problem is? Or are we doomed to a dichotomy to know which patch caused these regressions? FX PS: PR 22619 appeared somewhere between 20050716 and 20050717, so patches that could possible have messed up are: 005-07-17 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/22531 * tree-ssa-pre.c (do_eustores): Make sure LHS is a decl for the moment. 2005-07-17 Daniel Berlin <[EMAIL PROTECTED]> * tree-promote-statics.c (pass_promote_statics): Change dump file name. 2005-07-17 Daniel Berlin <[EMAIL PROTECTED]> * tree-optimize.c (init_tree_optimization_passes): Add pass_eliminate_useless_stores pass. * tree-pass.h (pass_eliminate_useless_stores): New pass structure. * tree-ssa-pre.c (is_copy_stmt): New function. (follow_copies_till_vuse): Ditto. (do_eustores): Ditto. (gate_eustores): Ditto. 2005-07-16 Richard Henderson <[EMAIL PROTECTED]> * gcc.c (MFWRAP_SPEC): Don't wrap pthread_join or pthread_exit. 2005-07-16 Danny Berlin <[EMAIL PROTECTED]> Kenneth Zadeck <[EMAIL PROTECTED]> * Makefile.in: Added rules for ipa-pure-const.c, ipa-reference.c, ipa-reference.h, ipa-utils.c, ipa-utils.h, ipa-type-escape.c, ipa-type-escape.h, tree-promote-statics.c * ipa-pure-const.c, ipa-reference.c, ipa-reference.h, ipa-utils.c, ipa-utils.h, ipa-type-escape.c, ipa-type-escape.h, tree-promote-statics.c: new files. * alias.c: (nonlocal_mentioned_p_1, nonlocal_mentioned_p, nonlocal_referenced_p_1, nonlocal_referenced_p, nonlocal_set_p_1, int nonlocal_set_p, mark_constant_function): Deleted. (rest_of_handle_cfg): Removed call to mark_constant_function. (nonoverlapping_component_refs_p): Added calls to support type based aliasing. * tree-ssa-alias.c (may_alias_p, compute_flow_insensitive_aliasing): Ditto. * calls.c (flags_from_decl_or_type): Removed reference to cgraph_rtl_info. * c-typeck.c (convert_arguments): Make builtins tolerant of having too many arguments. This is necessary for Spec 2000. * cgraph.h (const_function, pure_function): Removed. * common.opt: Added "fipa-pure-const", "fipa-reference", "fipa-type-escape", and "ftree-promote-static". * opts.c: Ditto. * passes.c: Added ipa and tree-promote-statics passes. * timevar.def: Added TV_IPA_PURE_CONST, TV_IPA_REFERENCE, TV_IPA_TYPE_ESCAPE, and TV_PROMOTE_STATICS. * tree-dfa.c (referenced_var_lookup_if_exists): New function. * tree-flow.h: Added exposed sra calls and addition of reference_vars_info field for FUNCTION_DECLS. * tree-pass.h: Added passes. * tree-sra.c: (sra_init_cache): New function. (sra_insert_before, sra_insert_after) Made public. (type_can_be_decomposed_p): Renamed from type_can_be_decomposed_p and made public. * tree-ssa-alias.c (dump_alias_stats): Added stats for type based aliasing. (may_alias_p): Added code to use type escape analysis to improve alias sets. * tree-ssa-operands.c (add_call_clobber_ops): Added parameter and code to prune clobbers of static variables based on information produced in ipa-reference pass. Changed call clobbering so that statics are not marked as clobbered if the call does not clobber them. 2005-07-16 Daniel Berlin <[EMAIL PROTECTED]> * tree-ssa-structalias.c (need_to_solve): Need to check for preds, too. 2005-07-16 Eric Botcazou <[EMAIL PROTECTED]> * doc/install.texi (*-*-solaris2*): Document recommended version of GNU binutils and mention GNU linker problem on Solaris 10. 2005-07-16 Joseph S. Myers <[EMAIL PROTECTED]> PR c/22421 * c-decl.c (c_build_bitfield_integer_type): New function. (finish_struct): Call it. * c-pretty-print.c (pp_c_type_specifier): Handle bit-field types. 2005-07-16 Kaveh R. Ghazi <[EMAIL PROTECTED]> * c-typeck.c (digest_init): Call 'convert_for_assignment' before returning. 2005-07-16 Jan Hubicka <[EMAIL PROTECTED]> * cfg.c (update_bb_profile_for_threading): Fix profile updating. (scale_bbs_frequencies_int): Watch roundoff errors. * predict.c (return_prediction): Initialize return_stmt. 2005-07-16 Jan Hubicka <[EMAIL PROTECTED]
using multiple trees with subversion
Hi all, I've been playing with the svn test repo during the last few days, updating my own (few) scripts and all, and it's been going very smoothly. The only thing that's worrying me is disk usage. I do only have small involvement in gcc, preparing few patches (never more than 5 at a time) on limited areas (gcc/fortran, libgfortran and gcc/testsuite), always on mainline or 4.0 branch. The way I manage to keep mind sanity right now is to have a few complete trees (one for 4.0 and 3-4 for mainline, each one with a local changes), called gcc-newintrinsics, gcc-fpe, ... Having 5 subversion trees will need much more space (for local pristine copies), which I don't really have. Is there any way to force subversion use one pristine tree for all modified trees, or is my way of handling things completely rotten? I welcome any advice... Thanks! FX
Re: using multiple trees with subversion
> Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably have > support for checking out repositories with compressed local copies (or no copy > at all -- but I wouldn't suggest this, as you'd start to be slow in "svn > diff", > "svn stat", etc). I guess no local copy would be fine with me. diff and stat should not be much slower than in CVS, and since very rarely do a full tree diff/stat, this is quite acceptable. Is that so hard to implement that it's not done already? Or am I the only person to find that disk is expensive (or working on his own hardware, maybe)? > You may want to look into svk though Thanks for the link, I'll give it a try. FX
Re: A couple more subversion notes
Since there is a big brainstorming, I will sum up my opinion here (and then stop spending time on this issue). From the discussion, it looks like the switch seems the most important constraint imposed by the switch is about hardware/software requirements, and I do strongly second this point. For example, some of us have to work on machines on which they're not root. I asked my sysadmin to install subversion, and it was done a month and a half later (two weeks ago). I know will have to ask him for svk, then again a newer svn (and perhaps a updated openssh, but that surely will be refused). And I'd rather not install all that myself, cause users are on shared disks with quotas. Another example: ever tried asking the sourceforge compile farm team for an update? they're still "considering" updating MacOS 10.1. So yes, there are solutions for some of the issues some of us have, but they all look a bit complicated. Well, maybe gcc this discussion would be spared if gcc contributors were only people supported by their company. But that's not the case. FX
Re: [gfortran] fortran preprocessing, round 2
>> PR fortran/18452 >> * gcc/c.opt: Add a -lang-fortran option. >> * gcc/c-opts.c: Add a lang_fortran flag. >> (c_common_init_options): Handling the -lang-fortran option. >> (c_common_handle_option): Add a case for Fortran options in >> preprocessing. Remove cases for -ffixed-form and >> -ffixed-line-length. Add a case for -lang-fortran. > > Ok. I'll commit when 4.1 unfreezes before branching. Could that apply to branch 4.0 as well? FX
Re: toplevel Makefile.tpl hacking
>> - with this patch, the libgfortran is built, but the gfortran >> testsuite doesn't run; why isn't $(RPATH_ENVVAR) including HOST_LIB_PATH >> for the testsuite? > > It should Well, it doesn't. The problem is that the gfortran testsuite is not run with the toplevel Makefile, but by going into the $builddir/gcc directory and typing "make check-fortran". I'm not sure whether this is another deficiency (after all, make check-gcc and make check-g++ can be run from the toplevel makefile), and how to fix it. FX
Re: toplevel Makefile.tpl hacking
> You can use "make check-target-libgfortran", which is what I thought you > were using to test. There's no testsuite for libgfortran (the command you mentionned does not test anything). The only way I'm aware of to run the gfortran testsuite is "make check-fortran" inside $builddir/gcc. I think I will soon have a patch ready to fix that last problem. FX
Build using --with-gmp and shared libraries
Here is a patch to fix PR libfortran/21547: when building with
--with-gmp=/foo/bar and a shared libgmp in /foo/bar, the
$(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set
correctly when using the freshly built gfortran to build libgfortran.
The same thing happens for the gfortran testsuite, and the fix is also
included in this patch.
Basic testing done on i686-linux (built with --languages=c,fortran and
a shared libgmp in /foo/bar, and regtested). Extended testing (which
takes ages on my computer) in progress.
OK for mainline? OK for 4.0?
:ADDPATCH build:
Index: Makefile.tpl
===
--- Makefile.tpl (revision 106019)
+++ Makefile.tpl (working copy)
@@ -157,6 +157,7 @@
OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \
TOPLEVEL_CONFIGURE_ARGUMENTS="$(TOPLEVEL_CONFIGURE_ARGUMENTS)"; export TOPLEVEL_CONFIGURE_ARGUMENTS; \
GMPLIBS="$(HOST_GMPLIBS)"; export GMPLIBS; \
+ GMPLIBSDIR="$(HOST_GMPLIBSDIR)"; export GMPLIBSDIR; \
GMPINC="$(HOST_GMPINC)"; export GMPINC; \
@if gcc-bootstrap
$(RPATH_ENVVAR)=`echo "$(TARGET_LIB_PATH)$$$(RPATH_ENVVAR)" | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \
@@ -216,6 +217,7 @@
# Where to find GMP
HOST_GMPLIBS = @gmplibs@
+HOST_GMPLIBSDIR = @gmplibsdir@
HOST_GMPINC = @gmpinc@
# --
@@ -615,7 +617,7 @@
# Define HOST_LIB_PATH_gcc here, for the sake of TARGET_LIB_PATH, ouch
@if gcc
-HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/gcc:$$r/$(HOST_SUBDIR)/prev-gcc:
+HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/gcc:$$r/$(HOST_SUBDIR)/prev-gcc:$(HOST_GMPLIBSDIR):
@endif gcc
[+ FOR host_modules +][+ IF lib_path +]
Index: configure.in
===
--- configure.in (revision 106019)
+++ configure.in (working copy)
@@ -1058,6 +1058,7 @@
# Check for GMP and MPFR
gmplibs=
gmpinc=
+gmplibsdir=
have_gmp=yes
# Specify a location for mpfr
# check for this first so it ends up on the link line before gmp.
@@ -1075,6 +1076,7 @@
if test "x$with_mpfr" != x; then
gmplibs="-L$with_mpfr/lib $gmplibs"
gmpinc="-I$with_mpfr/include"
+ gmplibsdir="$with_mpfr/lib"
fi
# Specify a location for gmp
@@ -1097,6 +1099,11 @@
if test "x$with_gmp" != x; then
gmplibs="-L$with_gmp/lib $gmplibs"
gmpinc="-I$with_gmp/include $gmpinc"
+ if test "x$gmplibsdir" != x; then
+gmplibsdir="$gmplibsdir:$with_gmp/lib"
+ else
+gmplibsdir="$with_gmp/lib"
+ fi
fi
saved_CFLAGS="$CFLAGS"
@@ -1125,6 +1132,7 @@
# Flags needed for both GMP and/or MPFR
AC_SUBST(gmplibs)
AC_SUBST(gmpinc)
+AC_SUBST(gmplibsdir)
# By default, C is the only stage 1 language.
stage1_languages=c
Index: gcc/configure.ac
===
--- gcc/configure.ac (revision 106019)
+++ gcc/configure.ac (working copy)
@@ -3402,6 +3402,8 @@
AC_ARG_VAR(GMPLIBS,[How to link GMP])
AC_ARG_VAR(GMPINC,[How to find GMP include files])
+AC_ARG_VAR(GMPLIBSDIR,[Where to find the GMP library])
+AC_ARG_VAR(RPATH_ENVVAR,[How the systems locates libraries])
# Configure the subdirectories
# AC_CONFIG_SUBDIRS($subdirs)
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 106019)
+++ gcc/Makefile.in (working copy)
@@ -294,6 +294,8 @@
# How to find GMP
GMPLIBS = @GMPLIBS@
GMPINC = @GMPINC@
+GMPLIBSDIR = @GMPLIBSDIR@
+RPATH_ENVVAR = @RPATH_ENVVAR@
CPPLIB = ../libcpp/libcpp.a
CPPINC = -I$(srcdir)/../libcpp/include
@@ -3906,6 +3908,7 @@
srcdir=`cd ${srcdir}; ${PWD_COMMAND}` ; export srcdir ; \
cd $(TESTSUITEDIR); \
EXPECT=${EXPECT} ; export EXPECT ; \
+ $(RPATH_ENVVAR)=`echo "$(GMPLIBSDIR):$$$(RPATH_ENVVAR)" | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'` ; export $(RPATH_ENVVAR) ; \
if [ -f $${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWD_COMMAND}` ; \
export TCL_LIBRARY ; fi ; \
libgmp.ChangeLog
Description: Binary data
Re: Build using --with-gmp and shared libraries
>> Here is a patch to fix PR libfortran/21547: when building with >> --with-gmp=/foo/bar and a shared libgmp in /foo/bar, the >> $(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set >> correctly when using the freshly built gfortran to build libgfortran. >> The same thing happens for the gfortran testsuite, and the fix is also >> included in this patch. > > Why wouldn't mpfr have the same problem? Sorry not to mention that. It can (although it usually doesn't, because the default for libmpfr is to build only a static library), and this is fix by the same patch. In fact, in the gcc configury, all occurences of GMPLIBS, GMPINCS always take care of both gmp and mpfr. I followed this lead, and GMPLIBSDIR points to the directories where gmp and mpfr are installed, if different. All this is done in the toplevel configure. FX
Re: Build using --with-gmp and shared libraries
> The newest version of mpfr will build a shared library. > In fact, we should move to using the newest version, > but I think some/many people would object to having two > external library dependencies. What advantages have the newest version? And (sorry for the obvious question) why isn't it kept in sync with gmp? FX
Re: Build using --with-gmp and shared libraries
> Basic testing done on i686-linux (built with --languages=c,fortran and > a shared libgmp in /foo/bar, and regtested). Extended testing (which > takes ages on my computer) in progress. > > OK for mainline? OK for 4.0? *ping* This patch has both a toplevel part and a part in gcc/, so I don't know exactly who can approve it. FX
Re: Build using --with-gmp and shared libraries
> Or did I miss the point entirely? Right now, having the GMP/MPFR libraries (later refered as GMP) in /home/gmp and typing: configure --with-gmp=/home/gmp --enable-languages=c,fortran does configure fine but running "make" then fails when it attempts to build libgfortran. This is PR 21547, see the audit trail for more details. The general opinion is that it is normal to have to set your LD_LIBRARY_PATH to run the installed compiler, but using --with-gmp should be enough to build it in any case. This is what the toplevel part of my patch does. Moreover, I think that running the testsuite shouldn't require setting LD_LIBRARY_PATH either, which is what the gcc/ part of the patch is about. FX
Re: Build using --with-gmp and shared libraries
>> Basic testing done on i686-linux (built with --languages=c,fortran and >> a shared libgmp in /foo/bar, and regtested). Extended testing (which >> takes ages on my computer) in progress. >> >> OK for mainline? OK for 4.0? > > *ping* > > This patch has both a toplevel part and a part in gcc/, so I don't > know exactly who can approve it. ping**2 I know the ideal world solution is to have a GMP/MPFR in-tree, but nobody proposed a patch to do it and we do have a build failure with the current situation. -- FX
Re: Build using --with-gmp and shared libraries
>>> Testing done on i686-linux (built with --languages=c,fortran and >>> a shared libgmp in /foo/bar, and regtested). >>> OK for mainline? OK for 4.0? ping**3, build machinery maintainers in Cc. This patch makes --with-gmp and --with-mpfr similar to --with-as and others, where you don't need to have the as program in your PATH if explicitly specified. FX
mips-irix6.5 and complex.h
Hi, I am stuck with PR libfortran/22097 because currently, the libgfortran configury isn't clever enough to get cabsl (among others) right on mips-irix6.5. config.h has #define HAVE_CABSF 1 and /* #undef HAVE_COMPLEX_H */ while the correct definition of cabsl is provided in complex.h. Can someone who knows mips-irix or has experience with such broken C99 complex implementations give some help? The problem I have is comment #9 from PR 22097. Thanks, FX
Re: Massive FORTRAN test failures
> I have got massive FORFRAN test failures on Linux/ia64 and > Linux/x86-64: > > http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00730.html > http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00729.html > > Most of failures look like: > > /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/char_result_11.f90:0: > internal compiler error: Segmentation fault^M > Please submit a full bug report,^M > with preprocessed source if appropriate.^M > See http://gcc.gnu.org/bugs.html> for instructions.^M > compiler exited with status 1 I did see the following on my nightly regtest on x86_64-linux: FAIL: gfortran.dg/char_transpose_1.f90 -O3 -g (test for excess errors) WARNING: gfortran.dg/char_transpose_1.f90 -O3 -g compilation failed to produce executable FX
gfortran and -mlong-double-128
Hi all, I'm sending this mail because I'm a bit confused about the -mlong-double-128 option on (for example) ppc64-linux, and its impact on gfortran/libgfortran. When I simply bootstrap a compiler with "configure --with-cpu=default32", I get a gfortran that does only have kind=4 and kind=8 reals (corresponding to C types float and double) by default. When I use this gfortran with the -mlong-double-128 option, the real(kind=16) floating point type is accepted at compile-time, but the I/O library in libgfortran doesn't know how to deal with it (since, when libgfortran was compiled, it did not detect that real(kind=16) was available), and the code fails at runtime. What should we do about that? I see a few options: 1. refuse -mlong-double-128 for Fortran code; easiest, but not exactly satisfying 2. build multiple instances of the library, as is currently done for the -m32/-m64 options 3. build only one instance of the library, but build it with -mlong-double-128 enabled, since as far as libgfortran is concerned, it only adds a new floating-point type. I may be confused about how all this is supposed to be handled, so any pointer to further reading is welcome, as well as opinion on the problem and options above. Thanks, FX
Re: gfortran and -mlong-double-128
> I guess libgfortran has configury to figure out if kind=16 is available? Yes. > If so then libgfortran should be built with -mlong-double-128, as this > should only add extra symbols that do not conflict with kind=4 and kind=8 > ones. Hum, that has to be done early in the configury (before all autodetection). Do you think it's better suited at the beginning of libgfortran/configure.ac (a special test, to see if -mlong-double-128 is available, and if it is add it to CFLAGS), or should it be done in an upper level (and here is the limit of my understanding of the build mechanism)? > Am I correct that for gfortran there is no such thing as long double > == double for -mlong-double-64? This is right. Fortran has a list of available floating-point modes, and they are chosen by a unique numbering scheme (the number is called a "kind"). FX
Re: gfortran and -mlong-double-128
> Having gfortran magically know about certain ABI breaking options, and doing > funny things on certain targets seems a very bad precedent to me. Then, I think we should have the front-end refuse the option. It's annoying to have a compiler accept code, and only tell you at runtime (at the end of your simulation!) that it can't work. FX
[libgomp] patch for -pthread on Tru64
Hi all,
libgomp currently doesn't configure well on Tru64 (PR
bootstrap/26161), because the configury is testing the usability of
pthread.h system headers, while on Tru64 this can only work when the
compiler is used with the -pthread option.
While this flag could be added on a per-target basis (it might be
needed on AIX too, but I can't confirm) in the configure.ac file
(configure.tgt is called to late for that), I thought about something
more general. In libgomp/configure.ac, why do we have the two
following tests:
AC_CHECK_HEADER([pthread.h],[],
[AC_MSG_ERROR([Pthreads are required to build libgomp])])
and
# Check to see if -pthread or -lpthread is needed. Prefer the former.
XPCFLAGS=""
CFLAGS="$CFLAGS -pthread"
AC_LINK_IFELSE(
[AC_LANG_PROGRAM(
[#include
void *g(void *d) { return NULL; }],
[pthread_t t; pthread_create(&t,NULL,g,NULL);])],
[XPCFLAGS=" -Wc,-pthread"],
[CFLAGS="$save_CFLAGS" LIBS="-lpthread $LIBS"
AC_LINK_IFELSE(
[AC_LANG_PROGRAM(
[#include
void *g(void *d) { return NULL; }],
[pthread_t t; pthread_create(&t,NULL,g,NULL);])],
[],
[AC_MSG_ERROR([Pthreads are required to build libgomp])])])
It looks to me that the second alone should be enough because, if
pthread.h is not available, both AC_LINK_IFELSE will fail and we will
have the AC_MSG_ERROR, which is exactly what happens during the
AC_CHECK_HEADER test.
Moreover, removing the first test makes libgomp build on targets (as
Tru64) where the -pthread option is required to include pthread.h.
Is this analysis wrong? If not, could someone OK the attached patch
(tested on alphaev68-dec-osf5.1b)?
Thanks,
FX
:ADDPATCH build:
Index: configure.ac
===
--- configure.ac(revision 10)
+++ configure.ac(working copy)
@@ -139,8 +139,6 @@
AC_STDC_HEADERS
AC_HEADER_TIME
AC_CHECK_HEADERS(unistd.h semaphore.h sys/loadavg.h sys/time.h)
-AC_CHECK_HEADER([pthread.h],[],
- [AC_MSG_ERROR([Pthreads are required to build libgomp])])
GCC_HEADER_STDINT(gstdint.h)
pr26161.ChangeLog
Description: Binary data
Re: Segmentation fault in openmp simple routine from libgomp testsuite.
> I might be missing out on something but I get a segmentation fault when > manualy executing omp_hello.f from libgomp testsuite > (libgomp/testsuite/libgomp.fortran/omp_hello.f)... > > Compiled using gfortran -static -fopenmp -g omp_hello.f -o omp_hello Hum... for trunk on i686-linux, I do see the following. Dynamic linking works fine: $ gfortran -fopenmp omp_hello.f && OMP_NUM_THREADS=2 ./a.out Hello World from thread =0 Number of threads =2 Hello World from thread =1 Static linking fails: $ gfortran -fopenmp omp_hello.f -static /tmp/cc697VvU.o(.text+0x24): In function `MAIN__': omp_hello.f: undefined reference to `GOMP_parallel_start' /tmp/cc697VvU.o(.text+0x39):omp_hello.f: undefined reference to `GOMP_parallel_end' /tmp/cc697VvU.o(.text+0x49): In function `MAIN__.omp_fn.0': omp_hello.f: undefined reference to `omp_get_thread_num_' /tmp/cc697VvU.o(.text+0xe3):omp_hello.f: undefined reference to `omp_get_num_threads_' collect2: ld returned 1 exit status The reading of the libgomp.spec lead me to give it explicitly the needed libraries (although it shouldn't be necessary, I guess). But then, it segfaults: $ gfortran -fopenmp omp_hello.f -static -lgomp -lrt && OMP_NUM_THREADS=2 ./a.out zsh: segmentation fault OMP_NUM_THREADS=2 ./a.out And the backtrace is: Program received signal SIGSEGV, Segmentation fault. 0x08048466 in initialize_team () at ../../../gcc/libgomp/config/posix/sem.h:75 75 ../../../gcc/libgomp/config/posix/sem.h: No such file or directory. in ../../../gcc/libgomp/config/posix/sem.h (gdb) where #0 0x08048466 in initialize_team () at ../../../gcc/libgomp/config/posix/sem.h:75 #1 0x080aff5e in __do_global_ctors_aux () #2 0x08048109 in _init () #3 0x080613ed in __libc_csu_init () #4 0x08061138 in __libc_start_main () #5 0x08048141 in _start () PS: Some details on the static linking failure: Driving: gfortran -fopenmp omp_hello.f -static -v -lgfortranbegin -lgfortran -lm Using built-in specs. Target: i386-linux Configured with: ../gcc/configure --prefix=/cosmic/coudert/tmp/gfortran-20060228/irun --enable-languages=c,fortran --host=i386-linux --with-gmp=/cosmic/coudert/tmp/gfortran-20060228/gfortran_libs Thread model: posix gcc version 4.2.0 20060228 (experimental) /tmpdir/opt/gfortran/gfortran-20060228/bin/../libexec/gcc/i386-linux/4.2.0/f951 omp_hello.f -ffixed-form -quiet -dumpbase omp_hello.f -mtune=i386 -auxbase omp_hello -version -fopenmp -I /tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0/finclude -o /tmp/ccGKM8HT.s GNU F95 version 4.2.0 20060228 (experimental) (i386-linux) compiled by GNU C version 4.2.0 20060228 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 as -V -Qy -o /tmp/cc08jqIE.o /tmp/ccGKM8HT.s GNU assembler version 2.15.94.0.2.2 (i386-redhat-linux) using BFD version 2.15.94.0.2.2 20041220 Reading specs from /tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0/../../../libgomp.spec /tmpdir/opt/gfortran/gfortran-20060228/bin/../libexec/gcc/i386-linux/4.2.0/collect2 -m elf_i386 -static /usr/lib/crt1.o /usr/lib/crti.o /tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0/crtbeginT.o -lgomp -lrt -L/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0 -L/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc -L/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0/../../.. /tmp/cc08jqIE.o -lgfortranbegin -lgfortran -lm --start-group -lgcc -lgcc_eh -lpthread -lc --end-group /tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/4.2.0/crtend.o /usr/lib/crtn.o /tmp/cc08jqIE.o(.text+0x24): In function `MAIN__': omp_hello.f: undefined reference to `GOMP_parallel_start' /tmp/cc08jqIE.o(.text+0x39):omp_hello.f: undefined reference to `GOMP_parallel_end' /tmp/cc08jqIE.o(.text+0x49): In function `MAIN__.omp_fn.0': omp_hello.f: undefined reference to `omp_get_thread_num_' /tmp/cc08jqIE.o(.text+0xe3):omp_hello.f: undefined reference to `omp_get_num_threads_' collect2: ld returned 1 exit status -- FX
Re: Successful Build: gcc-4.1-20051230 i686-pc-mingw32
[sorry for breaking the thread, stupid gmail interface doesn't allow
adding custom headers]
> i tried to compile gcc 4.1.0 (the final release) on windows, too. I'm using
> msys and configured the buildprocess with "--enable-threads=win32
> --with-win32-nlsapi=unicode". On the msys console i type "make" and after a
> while i get the error with the Makefile on line 1277. I make the fix and
> continue, then I get the error "*** No rule to make target
> `/mingw/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../mingw32/bin/ld.exe',
> needed by `stamp-collect-ld'. Stop." in the folder gcc.
This is a known bug (PR bootstrap/24382,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24382). You need to
specify a path for ld by configuring with:
${srcdir}/configure --with-ld=/path/to/ld
As an example, I usually build gcc/gfortran with:
../gcc/configure --prefix=/mingw --enable-languages=c,fortran
--with-gmp=$HOME/local --disable-nls --with-ld=/mingw/bin/ld
--with-as=/mingw/bin/as --disable-werror --enable-bootstrap
I don't know of any attempt to fix this bug, maybe Paolo made some
progress since his comment in the PR :)
I scanned the host/target specific installation notes on gcc.gnu.org,
but found to my surprise that there is no mention of i386-mingw32
there. I guess something this could be noted there.
FX
Re: Successful Build: gcc-4.1-20051230 i686-pc-mingw32
> I started again (deleted the generated files) and configured with "sh > ../gcc-4.1.0/configure --prefix=/home/gcc41 --enable-threads=win32 > --with-ld=/mingw/bin/ld --with-win32-nlsapi=unicode" and fired "make > bootstrap". I think this time make made more than the last time, but ejected > an error again I don't know for sure but, if I remember correctly my many unsuccessful attempts at building on mingw32, using --prefix=/mingw makes these go away. I'd like to stress that there is not much testing of gcc trunk under i386-mingw32 with MSYS. The configury and build system is widely "broken" for that platform. FX
Bug with SSE on mingw32
Hi all,
I'm experiencing a strange gfortran bug, i686-pc-mingw32 specific,
with options -march=pentium4 -mfpmath=sse -msse. I reproduce it below,
and post it here before filing it because I can't manage to create a C
testcase, and have no idea if this is something already known (though
my bugzilla searches didn't return successful results).
$ cat a.f90
real(8) :: x
x = 2._8
print *, sqrt(x)
end
$ gfortran.exe a.f90 -mfpmath=sse -msse -march=i686 -O0 && a
1.41421356237310
$ gfortran.exe a.f90 -mfpmath=sse -msse -march=pentium4 -O0 && a
[pops up a crash window, win32 equivalent of a segfault]
Debugging leads to an endless loop of:
> gdb: do_initial_child_stuff: process 2284
> gdb: kernel event for pid=2284 tid=2264 code=CREATE_PROCESS_DEBUG_EVENT)
> gdb: child_resume.SetThreadContext: thread 2284.0x8d8
> ContinueDebugEvent (cpid=2284, ctid=2264, DBG_CONTINUE);
The difference in the assembly created in both cases:
$ diff -pu a.s.working a.s.crashing
--- a.s.working Mon Apr 24 16:11:00 2006
+++ a.s.crashingMon Apr 24 16:11:12 2006
@@ -13,8 +13,8 @@ _MAIN__:
pushl %ebp
movl%esp, %ebp
subl$312, %esp
- fldlLC0
- fstpl -8(%ebp)
+ movsd LC0, %xmm0
+ movsd %xmm0, -8(%ebp)
movl$LC1, -280(%ebp)
movl$3, -276(%ebp)
movl$6, -284(%ebp)
@@ -22,9 +22,8 @@ _MAIN__:
leal-288(%ebp), %eax
movl%eax, (%esp)
call__gfortran_st_write
- fldl-8(%ebp)
- fsqrt
- fstpl -16(%ebp)
+ sqrtsd -8(%ebp), %xmm0
+ movsd %xmm0, -16(%ebp)
movl$8, 8(%esp)
leal-16(%ebp), %eax
movl%eax, 4(%esp)
I tried to make C testcases based on the generated code/original dump:
MAIN__ ()
{
real8 x;
x = 2.0e+0;
x = __builtin_sqrt (x);
}
but they all work. Does anyone have any idea why all this is happening?
Thanks,
FX
Re: Bug with SSE on mingw32
> I'm experiencing a strange gfortran bug, i686-pc-mingw32 specific, > with options -march=pentium4 -mfpmath=sse -msse. Some more input... the bug appears when SSE sqrtsd is called, but only if libgfortran contrusctors have been run: cat a.s .file "a.f90" .section .rdata,"dr" .align 8 LC0: .long 0 .long 1073741824 .text .globl _MAIN__ .def_MAIN__;.scl2; .type 32; .endef _MAIN__: pushl %ebp movl%esp, %ebp subl$16, %esp movsd LC0, %xmm0 movsd %xmm0, -8(%ebp) sqrtsd -8(%ebp), %xmm0 movsd %xmm0, -8(%ebp) leave ret $ gcc a.s -lgfortranbegin -lgfortran && ./a.exe [popus up crash dialog] $ diff a.s a_nolibgfortran.s 8,10c8,10 < .globl _MAIN__ < .def_MAIN__;.scl2; .type 32; .endef < _MAIN__: --- > .globl _main > .def_main; .scl2; .type 32; .endef > _main: $ gcc a.s && ./a.exe [works ok] The problem appears to be inside the libgfortran constructor and functions called herein. I'll try to narrow it, but I don't really know what to look for... What kind of code can be expected to generate such bad behaviour? FX
gfortran testsuite regression, gfortran.dg/entry_3.f90
Hi all, The following regression appeared between 20060504 and 20060505 on i686-linux. It is filed as PR 27443,and appears to be a consequence of a new optimization pass introduced by revision 113518. FAIL: gfortran.fortran-torture/execute/entry_3.f90 compilation, -O3 -fomit-frame-pointer FAIL: gfortran.fortran-torture/execute/entry_3.f90 compilation, -O3 -fomit-frame-pointer -funroll-loops FAIL: gfortran.fortran-torture/execute/entry_3.f90 compilation, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gfortran.fortran-torture/execute/entry_3.f90 compilation, -O3 -g Regards, FX
Re: gfortran testsuite regression, gfortran.dg/entry_3.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437 Humpf. Does that mean that the patch wasn't regtested before being applied? FX
Re: OpenMP bug with gfortran when compile under Windows platform
[CCing the OpenMP experts] Henry, The -fopenmp option doesn't work under mingw32. Since I am the one building the Windows (mingw32) binary packages you downloaded, I'm rather interesting in getting it to work... So here are a few things we could sort out: 1. currently, using the -fopenmp options gives: $ gfortran -fopenmp a.f gfortran.exe: unrecognized option '-pthread' gfortran.exe: libgomp.spec: No such file or directory Could we have a clearer error message? (perhaps saying that openmp is not available on that platform) The current message is clearly... not clear for users! 2. I looked at pthreads win32 (http://sources.redhat.com/pthreads-win32/), an opensource thread support for win32, including mingw32. Not all POSIX functions are implemented, but a fair amount of them. I'll try to get libgomp compiling with against those, and report progress here. 3. why is libgomp building conditional on target triplet, and not on detecting a working pthread implementation? Thanks, FX
Re: OpenMP bug with gfortran when compile under Windows platform
you just port libgomp to mingw32 + pthreads-win32
and assuming pthreads-win32 is sufficiently rich and not too buggy, it will
just work.
With the attached patch, I can compile libgomp with
../gcc/configure --prefix=/mingw --disable-nls --with-ld=/mingw/bin/ld
--with-as=/mingw/bin/as --disable-werror --enable-bootstrap
--enable-threads=posix --with-win32-nlsapi=unicode
--host=i386-pc-mingw32 --enable-languages=c,fortran --enable-libgomp
and the resulting compiler and generated executables seem to work (I
tried a few C and Fortran toy codes). The main changes are to
libgomp/config/posix/time.c, which used functions not available on
mingw32. Would they be acceptable in this form (protected with #ifdef
_WIN32)? If so, I'll do some more testing, and officially submit the
patch.
FX
Index: libgomp/configure
===
--- libgomp/configure (revision 114196)
+++ libgomp/configure (working copy)
@@ -8397,7 +8397,9 @@
# Check for functions needed.
-for ac_func in getloadavg clock_gettime
+
+
+for ac_func in getloadavg clock_gettime gettimeofday sysconf
do
as_ac_var=`echo "ac_cv_func_$ac_func" | $as_tr_sh`
echo "$as_me:$LINENO: checking for $ac_func" >&5
Index: libgomp/configure.ac
===
--- libgomp/configure.ac (revision 114196)
+++ libgomp/configure.ac (working copy)
@@ -162,7 +162,7 @@
[AC_MSG_ERROR([Pthreads are required to build libgomp])])])
# Check for functions needed.
-AC_CHECK_FUNCS(getloadavg clock_gettime)
+AC_CHECK_FUNCS(getloadavg clock_gettime gettimeofday sysconf)
# Check for broken semaphore implementation on darwin.
# sem_init returns: sem_init error: Function not implemented.
Index: libgomp/config.h.in
===
--- libgomp/config.h.in (revision 114196)
+++ libgomp/config.h.in (working copy)
@@ -18,6 +18,9 @@
/* Define to 1 if you have the `getloadavg' function. */
#undef HAVE_GETLOADAVG
+/* Define to 1 if you have the `gettimeofday' function. */
+#undef HAVE_GETTIMEOFDAY
+
/* Define to 1 if you have the header file. */
#undef HAVE_INTTYPES_H
@@ -42,6 +45,9 @@
/* Define to 1 if the target supports __sync_*_compare_and_swap */
#undef HAVE_SYNC_BUILTINS
+/* Define to 1 if you have the `sysconf' function. */
+#undef HAVE_SYSCONF
+
/* Define to 1 if you have the header file. */
#undef HAVE_SYS_LOADAVG_H
Index: libgomp/config/posix/time.c
===
--- libgomp/config/posix/time.c (revision 114196)
+++ libgomp/config/posix/time.c (working copy)
@@ -48,32 +48,52 @@
double
omp_get_wtime (void)
{
-#ifdef HAVE_CLOCK_GETTIME
+#ifdef HAVE_GETTIMEOFDAY
+# ifdef HAVE_CLOCK_GETTIME
struct timespec ts;
-# ifdef CLOCK_MONOTONIC
+# ifdef CLOCK_MONOTONIC
if (clock_gettime (CLOCK_MONOTONIC, &ts) < 0)
-# endif
+# endif
clock_gettime (CLOCK_REALTIME, &ts);
return ts.tv_sec + ts.tv_nsec / 1e9;
-#else
+# else
struct timeval tv;
gettimeofday (&tv, NULL);
return tv.tv_sec + tv.tv_usec / 1e6;
+# endif
+#else
+# ifdef _WIN32
+
+#include
+ struct _timeb timebuf;
+ _ftime (&timebuf);
+ return (timebuf.time + (long)(timebuf.millitm) / 1e3);
+# else
+# error "Either clock_gettime or gettimeofday are required"
+# endif
#endif
}
double
omp_get_wtick (void)
{
-#ifdef HAVE_CLOCK_GETTIME
+#ifdef HAVE_SYSCONF
+# ifdef HAVE_CLOCK_GETTIME
struct timespec ts;
-# ifdef CLOCK_MONOTONIC
+# ifdef CLOCK_MONOTONIC
if (clock_getres (CLOCK_MONOTONIC, &ts) < 0)
-# endif
+# endif
clock_getres (CLOCK_REALTIME, &ts);
return ts.tv_sec + ts.tv_nsec / 1e9;
+# else
+ return 1.0 / sysconf(_SC_CLK_TCK);
+# endif
#else
- return 1.0 / sysconf(_SC_CLK_TCK);
+# ifdef _WIN32
+ return 1e-3;
+# else
+# error "Either clock_getres or sysconf are required"
+# endif
#endif
}
Index: gcc/config/i386/mingw32.h
===
--- gcc/config/i386/mingw32.h (revision 114196)
+++ gcc/config/i386/mingw32.h (working copy)
@@ -108,3 +108,8 @@
/* Define as short unsigned for compatibility with MS runtime. */
#undef WINT_TYPE
#define WINT_TYPE "short unsigned int"
+
+/* The mingw32 compiler doesn't know the -pthread option, but requires
+ explicitly linking the libpthread. */
+#undef GOMP_SELF_SPECS
+#define GOMP_SELF_SPECS "-lpthread"
GCC missed optimization?
I've been doing some benchmarking of gfortran, and reducing the
testcase leads to what seems a missed optimization in the following
code:
$ cat a.c
void foo (float * restrict x, float * restrict y)
{
int i;
for (i = 0; i < 1; i++)
x[i] = y[i] * y[i];
}
$ gcc a.c -O1 -ffast-math -msse -mfpmath=sse -ftree-vectorize
-ftree-vectorizer-verbose=5 -std=c99 -c
a.c:5: note: Alignment of access forced using peeling.
a.c:5: note: Vectorizing an unaligned access.
a.c:5: note: not vectorized: relevant stmt not supported: D.1353_14 =
__builtin_powf (D.1352_13, 2.0e+0)
a.c:5: note: vectorized 0 loops in function.
I find in fold-const.c:fold_binary, around line 9091, I found the following:
/* Optimize x*x as pow(x,2.0), which is expanded as x*x. */
Should I file it as a missed-optimization bug in bugzilla, or is there
some clever reason for that behaviour?
FX
Where does tree-ssa.c read the variable names for -Wuninitialized messages?
Hi,
I'm trying to understand PR 13615, where a used-uninitialized Fortran
character string induces the following diagnostic:
'c[1]{lb: 1 sz: 1}t.f: In function 'warn_character':
t.f:33: warning: ' is used uninitialized in this function
I see that this error message is emitted from tree-ssa.c, but I'm not
skilled enough in middle-end magic to understand whether the fault is
on the front-end not setting something correctly, or the middle-end
not understanding what this variable is. I hope someone here could,
without too much trouble, help me.
Thanks,
FX
Re: Where does tree-ssa.c read the variable names for -Wuninitialized messages?
I'd say the FE is not setting the name properly into whatever _DECL we found. unit size align 8 symtab 0 alias set 4 precision 8 min max pointer_to_this > used unsigned QI file pr13615.f line 7 size unit size align 8 context > I'll try to understand why this $1 behaves so badly in the error message, and why it is set that way in the first place. FX
Re: Volunteer for bug summaries?
Hi, When the commit which introduced the regression is known, why not simply assign the bug to the committer? Surely, people do follow regularly the bugs that are assigned to them, don't they? In my opinion, all regressions should always be assigned to someone, at all times. Either to the identified guilty party, or to a volunteer or maintainer of that field, who is then responsible for identifying the guilty party, or finding someone who accepts to do it. This sounds like a reasonable way of making sure some regressions don't get forgotten, doesn't it? FX
Re: Volunteer for bug summaries?
CCing the person who caused the regression is more appropriate. Assigning bugs to them detracts others from fixing the bug. We already do that, and in lots of cases it doesn't work. CCing is not coercive enough, you only receive a few more mails (and some people don't even read their bugzilla mail). Take PR31095, for example. It's a 4.3 regression on x86 and x86_64 that is triggered on the GCC testsuite, it has been known for more than 2 months, Janis kindly did a reghunt a month ago to attribute it, the patch author was added in the CC list. Since then, nothing happened. I'm taking this example because I was remembered about it by a mail on the fortran list, but it has nothing specific, there are scores of these kind out there. I think assigning regressions to people who introduced them is only fair, after all, they are supposed to take care of it or find someone else to do it! FX
Re: Volunteer for bug summaries?
We already do that, and in lots of cases it doesn't work. CCing is not coercive enough, you only receive a few more mails (and some people don't even read their bugzilla mail). Coercion isn't an option that is available to us. Hum, I checked the Merriam-Webster dictionary, and clearly "coercive" was stronger than I thought it was :( I only mean to say: things can get fixed by *gentling* pressuring people responsible for it, while also accepting the pressure when it is applied to yourself. This implies that you think it is the patch author's job to fix the problem. I think it was the patch author's job to either (a) fix the problem or (b) identify it clearly, and hand it over to the responsible maintainer. And if the patch were incorrect, you'd have an argument. But in this case, it seems that the patch is correct, but it exposes a problem elsewhere in the compiler (one of Kenner's famous "latent bugs"). [...] Andrew's comment suggests that the real bug is elsewhere, and I don't get why the author of the above patch is responsible for fixing that other breakage. My first problem with your reasoning is with "suggests": someone has to do the analysis so that the bug can be correctly assigned and fixed. If noone is deemed responsible for doing this, then that regression might stay for years. It sounds not unreasonable to me to ask the person who committed the patch to do this analysis. After all, if he had seen it during his regtesting (in that particular case, testing with Fortran would have probably shown the regression), I don't think the patch would have been approved, would it? Reverting the patch is an option, but that would re-open whatever problems the patch fixed. And the second issue I see is: unless the patch was actually fixing a more important regression, which is not the most common case (and not the case here), you have actually traded a bug (or sometimes, even only a missed-optimization) for a regression. FX
Re: [gnu.org #220291] Copyright assignment
Hello, It too is possible that you have completed your assignment process with the FSF, but have yet to be removed from the list of outstanding assignments. If this is the case please let me know so that I can update the record. This is the case: I have had a copyright assignment on file for almost two years, and have been contributing actively during that time. You can remove me from the list of outstanding assignments. Regards, FX
Bootstrap broken on i386-pc-mingw32; ICE while building libgfortran
Hi all,
Bootstrap including gfortran has been broken on native i386-pc-mingw32
for at least 10 days, with the C compiler having an ICE while
compiling libgfortran/io/write.c. I finally found the opportunity to
reduce the ICE to the following code:
$ cat write.i
extern void fflush (int);
extern __attribute__ ((__dllimport__)) int _iob[];
static int __gthrw_pthread_once () __attribute__
((__weakref__("pthread_once")));
void flush_if_preconnected ()
{
fflush (_iob[0]);
}
$ C:/msys/1.0.10/home/FX/ibin/gcc/cc1.exe write.i -quiet
write.i:8: internal compiler error: Segmentation fault
The backtrace I could get from gdb can be found at the bottom of this
mail, and looks seriously garbled. I was wondering:
1. if someone else sees this issue? (for native compilers? for cross
compilers?)
2. what to do next? I've filed PR32915 , but I don't know what I
could do to debug further... I've nether done much programming or
debugging with Windows
Thanks for advice,
FX
-
Program received signal SIGSEGV, Segmentation fault.
decl_assembler_name_equal (decl=0x2ae2360, asmname=0x2ae1930)
at ../../trunk/gcc/tree.c:323
323 if (IDENTIFIER_POINTER (decl_asmname)[0] == '*')
(gdb) where
#0 decl_assembler_name_equal (decl=0x2ae2360, asmname=0x2ae1930)
at ../../trunk/gcc/tree.c:323
#1 0x00512973 in decl_assembler_name_equal (decl=0x2ae1930,
asmname=0x290f200) at ../../trunk/gcc/tree.c:314
#2 0x00512973 in decl_assembler_name_equal (decl=0x0, asmname=0x3d2412)
at ../../trunk/gcc/tree.c:314
#3 0x00512973 in decl_assembler_name_equal (decl=0x3d2412, asmname=0x0)
at ../../trunk/gcc/tree.c:314
#4 0x00512973 in decl_assembler_name_equal (decl=0x3d2412, asmname=0x0)
at ../../trunk/gcc/tree.c:314
#5 0x00512973 in decl_assembler_name_equal (decl=0x0, asmname=0x0)
at ../../trunk/gcc/tree.c:314
#6 0x00512973 in decl_assembler_name_equal (decl=0x3, asmname=0x3d24a0)
at ../../trunk/gcc/tree.c:314
#7 0x00512973 in decl_assembler_name_equal (decl=0x3a, asmname=0x4)
at ../../trunk/gcc/tree.c:314
#8 0x00512973 in decl_assembler_name_equal (decl=0x1, asmname=0x9)
at ../../trunk/gcc/tree.c:314
#9 0x00512973 in decl_assembler_name_equal (decl=0x0, asmname=0x2)
at ../../trunk/gcc/tree.c:314
#10 0x00512973 in decl_assembler_name_equal (decl=0x401280, asmname=0x0)
at ../../trunk/gcc/tree.c:314
#11 0x00512973 in decl_assembler_name_equal (decl=)
at ../../trunk/gcc/tree.c:314
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Re: Fortran regressions on Cygwin_NT
> FAIL: gfortran.dg/g77/980310-3.f (internal compiler error) > FAIL: gfortran.dg/g77/980310-3.f (test for excess errors) I saw this one on x86_64-linux with -m32, and filed it as PR33074. I asked about it on IRC yesterday, and if I understood Andrew Pinksi, it probably is a middle-end problem, as people have been messing with reload recently. > FAIL: gfortran.fortran-torture/execute/intrinsic_integer.f90 execution, -O0 This one apparently appeared between rev. 127178 and 2007-08-06 (see http://gcc.gnu.org/ml/gcc-testresults/2007-08/msg00161.html and http://gcc.gnu.org/ml/gcc-testresults/2007-08/msg00278.html; there is no revision number for the second one), and it is also seen on a few platforms. It probably was introduced by me (recent NINT patch) and fixed as per http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00902.html FX
Re: Failure in bootstrapping GFortran 4.3.0 on Cygwin
Well, at least the culprit is easy to find! 2007-08-16 H.J. Lu <[EMAIL PROTECTED]> * Makefile.in (REVISION): New. (REVISION_c): New. (REVISION_s): New. (version.o): Also depend on $(REVISION). Add -DREVISION=$(REVISION_s). * version.c (version_string): Add REVISION.
Re: Someone has caused regressions in gfortran
> Because of the famous duplicated declaration problem This sentence is reminding me that I forgot to send the following update: As I said I was going to give it a shot over the week-end, here's an update on this: it won't make it into 4.3, because it's a big change and my current patch is triggering a very long string of ice-on-invalid-code bugs (all type mismatches in Fortran interfaces for procedures end up dying badly) as well as a few ice-on-valid-code that are currently hard to track (and might be preexisting front-end bugs exposed by the patch). I intend to work slowly on this, and hopefully will have put a complete patch together when 4.4 stage1 opens. > I am not sure if > inlining is not completely unsafe for fortan and we would not be forced > to disable it completely (not just partly as before the patch). This > would be rather sad. I think the current situation is safe: we can online local functions (functions declared and inside other functions), which are the Fortran CONTAIN'ed functions. This should be safe, while all other inlining is currently impossible. FX
Re: Someone has caused regressions in gfortran
>> As I said I was going to give it a shot over the week-end, here's an >> update on this: it won't make it into 4.3, because it's a big change >> and my current patch is triggering a very long string of > Huh, still I would be interested in seeing the patch. It's based on Michal Matz's patch at http://gcc.gnu.org/ml/gcc/2007-08/msg00236.html I'll send it tomorrow, I don't have my laptop with me today. > Can we trick fotran to set DECL_UNINLINABLE in the non CONTAIN'ed > functions? Yes, I think we can do that. Grep the front-end sources for FUNCTION_DECL as argument to build_decl: * the decl built in gfc_get_intrinsic_lib_fndecl (trans-intrinsic.c) can be made DECL_UNINLINABLE unconditionally * in trans-decl.c, the decls built in gfc_get_extern_function_decl and gfc_build_library_function_decl can also be made DECL_UNINLINABLE unconditionally * finally, in build_function_decl (trans-decl.c), you can do something like Index: trans-decl.c === --- trans-decl.c(revision 127902) +++ trans-decl.c(working copy) @@ -1217,6 +1217,8 @@ build_function_decl (gfc_symbol * sym) type = gfc_get_function_type (sym); fndecl = build_decl (FUNCTION_DECL, gfc_sym_identifier (sym), type); + if (!sym->attr.contained) +DECL_UNINLINABLE (fndecl) = 1; /* Perform name mangling if this is a top level or module procedure. */ if (current_function_decl == NULL_TREE) I have neither built nor regtested this, and I won't be able to do it in the next few days. If you feel like trying, please go ahead. FX
Re: Someone has caused regressions in gfortran (c_char_tests_red.f03, now PR33330)
> Does anyone knows the answer? or should it be asked on comp.lang.fortran? It's very specific to the problem at hand, so I doubt c.l.f could give us much input on that. As I understand, in this case, it actually is the right thing to do. FX
Recent (middle-end?) regressions in the Fortran testsuite
The last few days have seen a regression in the Fortran testsuite on
i386-linux and x86_64-linux (filed as PR33391). The following code
gives wrong results at -O2 while it works at -O1:
program test
integer(kind=1) :: i
do i = -128, 127
end do
if (i /= -128) call abort
end program test
Also of interest, gfortran.dg/vect/vect-{1,2,4}.f90 have started
failing on ia64 and i386 (but not x86_64 and i686, apparently).
FX
Fwd: MetaHTML and the GCC web site
Hi all, I'm currently rewriting the fortran/ part of the GCC website and trying to use the website preprocessor locally, to check my modifications (which include bringing fortran/ to the website common style). The script needs mhc, which seems to be the metahtml compiler. I tried to compile metahtml-5.08 as well as metahtml-5.091 (tarbal from the sources on sourceware, kindly provided by Ian Taylor) but both compilations dies in a subdirectory. I then wanted to ask for help on the metahtml mailing-list, but noticed that there has been no activity on those since 1999, which brings two questions: how was metahtml compiled for the current webserver (the error I see is certainly not target-specific), and should we use a tool that has been deceased for 8 years to produce our website? FX PS: The compilation error I get, if that rings a bell to someone who installed metahtml on the webserver, is in libmhtml: Compiling pagefuncs.c into pagefuncs.o gcc -Wall -Wstrict-prototypes -Wshadow -g -DHAVE_CONFIG_H -I. -I.. - I../libutils -I../libutils/regex -I/tmp/gdbm-1.8.3/include -I..- DCOMPILE_TIME_MODULE_DIRECTORY='"/opt/metahtml-5.091/lib"' -c pagefuncs.c pagefuncs.c:1070:1: error: unterminated argument list invoking macro "DEFINE_SECTION" pagefuncs.c:135: error: parse error at end of input where pagefuncs.c contains at line 135: DEFINE_SECTION (PAGE-VARIABLES, , "[... here was multiline text ...]", "[... and here was also multiline text like that ...]")
Add a symlink for each branch in online docs
The documentation for different releases of GCC in the same branch vary only slightly. For that reason, I think it would be nice to be able to have a URL for "the doc of a given branch", meaning "the doc of the last released version of this branch". For example, that would be achieved by creating a symlink http://gcc.gnu.org/onlinedocs/gcc-4.2 -> http://gcc.gnu.org/onlinedocs/gcc-4.2.1 Would that be considered useful? And if yes, how to implement it? FX
Bootstrap broken on mips-sgi-irix6.5
Hi there,
Mainline currently doesn't bootstrap on mips-sgi-irix6.5 due to an ICE
while compiling mips-sgi-irix6.5/64/libgcc/_powitf2.o at stage 1. This
happens, afaict, with any use of the TF mode with either -mabi=64 or
-mabi=n32:
$ cat foo.i
void __powitf2 (float x __attribute__ ((mode (TF {}
$ /usr/people/francois/devel/ibin/./gcc/cc1 -fpreprocessed foo.i -quiet
zsh: segmentation fault /usr/people/francois/devel/ibin/./gcc/cc1
-fpreprocessed foo.i -quiet
The backtrace for the segfault is:
Program received signal SIGSEGV, Segmentation fault.
0x104d7d50 in reg_classes_intersect_p (c1=32, c2=MD0_REG)
at ../../trunk/gcc/regclass.c:2481
2481{
(gdb) where
#0 0x104d7d50 in reg_classes_intersect_p (c1=32, c2=MD0_REG)
at ../../trunk/gcc/regclass.c:2481
#1 0x102323cc in mips_cannot_change_mode_class (from=TFmode, to=DImode,
class=FP_REGS) at ../../trunk/gcc/config/mips/mips.c:9346
#2 0x10823a38 in simplify_subreg (outermode=DImode, op=0x40b4c80,
innermode=TFmode, byte=0) at ../../trunk/gcc/simplify-rtx.c:5014
#3 0x10824968 in simplify_gen_subreg (outermode=DImode, op=0x40b4c80,
innermode=TFmode, byte=0) at ../../trunk/gcc/simplify-rtx.c:5211
#4 0x1027a700 in operand_subword (op=0x40b4c80, offset=0,
validate_address=1, mode=TFmode) at ../../trunk/gcc/emit-rtl.c:1425
#5 0x1027a76c in operand_subword_force (op=0x40b4c80, offset=0, mode=TFmode)
at ../../trunk/gcc/emit-rtl.c:1438
#6 0x10337484 in emit_move_multi_word (mode=TFmode, x=0x4c84200, y=0x40b4c80)
at ../../trunk/gcc/expr.c:3275
#7 0x10337980 in emit_move_insn_1 (x=0x4c84200, y=0x40b4c80)
at ../../trunk/gcc/expr.c:3347
#8 0x10337dc0 in emit_move_insn (x=0x4c84200, y=0x40b4c80)
at ../../trunk/gcc/expr.c:3407
#9 0x102b4894 in copy_to_reg (x=0x40b4c80) at ../../trunk/gcc/explow.c:617
#10 0x1027a7cc in operand_subword_force (op=0x40b4c80, offset=0, mode=TFmode)
at ../../trunk/gcc/emit-rtl.c:1448
I'm keeping the build tree so that I can investigate more if needed,
please tell me what to do. PR33635 has been opened to keep track of
this problem.
Thanks,
FX
Re: [RFC,wwwdocs] Ditch MetaHTML and use our own Perl preprocessor
ping? Gerald, being web pages maintainers, what's your opinion? Answering to Janne's comment, I'm certainly not opposed to any preprocessor/templating system. My own goal is to rewrite the fortran pages, including the common navigation bar, and I can't use MetaHTML to do that. On 9/29/07, FX Coudert <[EMAIL PROTECTED]> wrote: > Hi, > > I am in the process of rewriting the Fortran part of our website > (http://gcc.gnu.org/), part of which consists of adding the GCC > navigation bar. To do so, I had to install localy MetaHTML, our > current web preprocessor, and my experiences with it have left me > less than impressed [1]. We currently use it for including headers > and footer, making them depend on whether we are preprocessing HTML > or XHTML, modifying in place a few tags (, , ) and > adding navigation bar on files that need it. This can easily be done > by a simple preprocessing script, and seeing that MetaHTML was last > released 1999 and apparently unsupported since then, I suggest that > we do this move right now. > > This patch includes the new preprocessor, changes to the script, and > quite a few new files (footer, navigation bars, etc.) split from the > MetaHTML file, style.mhtml. I chose to write the preprocessor script > in Perl, since Perl is already used for the wwwdocs/bin/preprocess > script, so I'm sure it will be available on the webserver. The > preprocessor does what MetaHTML was needed, but it can be extended in > the future if we need more functionality. Also, we can in the future > offload some of its work, such as and modifications and > part of the navigation bar to CSS, which is obviously better suited > for the job. I intend to do so as a follow-up to the preprocessor > change, if/when it is accepted. > > This change shouldn't change the website, but I can't check since I > don't have MetaHTML, so I'd appreciate if someone with shell access > to the webserver could check it. Oh, there is one thing that I > changed: the detailled search page, http://gcc.gnu.org/search.html, > currently has a "Database last updated -MM-DD" line that doesn't > work (it displays "1900--"), so I removed it. > > Comments are highly welcome, both on the idea itself, and on the Perl > script (my Perl is a bit rusty since I haven't used it for years). > > Thanks, > FX > > > [1] As a record, here's what my "final" status is: in addition to > Gerald's patch and script provided by Joel Sherrill (thanks guys), I > needed to patch of few more (~ 15) occurences of multilines strings, > force the Makefiles to use the version of readline included in > metahtml instead of the system one (too recent, apparently there's > been an ABI change), and tweak the Makefiles for the shared modules, > which aren't portable (at least, not to Mac OS). As of yesterday, > I've managed to compile it, but the resulting binary acts as an > endless cpu-consuming loop. At that point, I gave up.
i386-linux bootstrap failure
Bootstrap on i386-linux has been broken for a week now, from what I can see. I have reported it as PR33679 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33679), but AFAIK noone has reproduced it, as most people now build for i686-linux. Could someone please spare a cycle to confirm this problem? I configure with --enable-languages=c,fortran --build=i386-pc-linux-gnu --enable-checking=release Thanks, FX
Re: Using crlibm as the default math library in GCC sources
Hi Uros, It sounds like a great idea! I'm forwarding this to the Fortran list, because I think it might raise quite some interest there also : http://gcc.gnu.org/ml/gcc/2007-11/msg00164.html FX
