Re: libquadmath
Hello Bienisaz, > I have managed to compile the program using the quadmath, but the > program works only if the libquadmath-0.dll is supplied in a working > directory. I notice that there were some controversies on the internet, > concerning the issue of static linking of the quadmath library, and > there seems to be no clear solution available how to link the library > statically. Is there any way to do this? I would appreciate a hint. You should be able to link directly against libquadmath.a instead of the shared version. > Another problem I see is that it seems impossible to dynamically > allocate __float128 vectors by using "calloc" or "new". Is there > any other way to achieve a dynamic allocation? The following works for me: __float128 *x = calloc(sizeof(__float128), 8); > Yet another difficulty is that the list of available math functions > does not contain some important functions, notably Bessel functions > K0() and K1() (although some other Bessel functions are available). > Are there any plans to extend the library by providing more functions > and more elaborate support for I/O (like streams, for example)? > More generally, are there any plans for further development of the > library? I do not think any further development is planned. > Also, if there is any discussion list or other place where one can > ask questions about the library, can you please indicate the address? > Is there any place where one can contribute procedures to the library? Ask on the gcc general mailing list: gcc@gcc.gnu.org FX
Re: libquadmath
>> The following works for me: >> >> __float128 *x = calloc(sizeof(__float128), 8); > > Well, this does not work for me. The code compiles, but during execution > the program crashes in this place. You will need to investigate the crash in detail, then. Maybe it is due to memory alignment, and you could use aligned_alloc() instead? FX
Making __builtin_signbit type-generic
Hi,
Many of the floating point-related builtins are type-generic, including
__builtin_{isfinite,isinf_sign,isinf,isnan,isnormal,isgreater,islesser,isunordered}.
However, __builtin_signbit is not. It would make life easier for the
implementation of IEEE in Fortran if it were, and probably for some other stuff
too (PR 36757).
I don’t know where to start and how to achieve that, though. Could someone who
knows this middle-end FP stuff help?
Thanks,
FX
Re: Making __builtin_signbit type-generic
> Please look at builtins.def, grep for TYPEGENERIC. Sure, I can define it as TYPEGENERIC in the builtins.def, like this: Index: builtins.def === --- builtins.def(revision 225434) +++ builtins.def(working copy) @@ -489,7 +489,7 @@ DEF_C99_BUILTIN(BUILT_IN_SCALBLN DEF_C99_BUILTIN(BUILT_IN_SCALBN, "scalbn", BT_FN_DOUBLE_DOUBLE_INT, ATTR_MATHFN_FPROUNDING_ERRNO) DEF_C99_BUILTIN(BUILT_IN_SCALBNF, "scalbnf", BT_FN_FLOAT_FLOAT_INT, ATTR_MATHFN_FPROUNDING_ERRNO) DEF_C99_BUILTIN(BUILT_IN_SCALBNL, "scalbnl", BT_FN_LONGDOUBLE_LONGDOUBLE_INT, ATTR_MATHFN_FPROUNDING_ERRNO) -DEF_EXT_LIB_BUILTIN(BUILT_IN_SIGNBIT, "signbit", BT_FN_INT_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST) +DEF_EXT_LIB_BUILTIN(BUILT_IN_SIGNBIT, "signbit", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF) DEF_EXT_LIB_BUILTIN(BUILT_IN_SIGNBITF, "signbitf", BT_FN_INT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST) DEF_EXT_LIB_BUILTIN(BUILT_IN_SIGNBITL, "signbitl", BT_FN_INT_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST) DEF_EXT_LIB_BUILTIN(BUILT_IN_SIGNBITD32, "signbitd32", BT_FN_INT_DFLOAT32, ATTR_CONST_NOTHROW_LEAF_LIST) But does that mean the middle-end will handle it completely? FX
Re: Using libbacktrace in libgfortran: some questions
> You should always get accurate PC values even > on systems where libbacktrace does not yet generate file/line > information. Cool! We’ll be able to use it unconditionaly with all targets, which is very nice. > I don't know why this is not working. Everything looks fine in the > a.out that you sent. Unfortunately, I think you sent the one built > without libbacktrace. Can you send me the one built with libbacktrace? Attached is the a.out with libgfortran (and thus libbacktrace) linked in statically. If this isn’t sufficient, I can send any file necessary (including the whole tree if need be). Thanks for helping with this, FX
Re: Using libbacktrace in libgfortran: some questions
> You might also take a look at the patch posted to PR 54572 which was my > attempt to use libbacktrace a few years ago. While I got symbolic backtraces > working somewhat, unfortunately I never got it to work completely since it > crashed somewhere in libbacktrace in some cases, but maybe whatever bugs > caused that have been fixed in the meantime… I definitely did start from your patch at PR 54572! libbacktrace definitely has improved, and now supports pecoff targets (i.e. Windows, I think). If we can get rid of the last few hurdles, then it will be a perfect solution for libgfortran, given it is already used in the compiler itself (and thus well-maintained). Obviously, the major target for which support is missing is Darwin (Mach-O object files). I have looked at implementing it, but it is well beyond my simple understanding of object files’ inner working :( FX
Re: Using libbacktrace in libgfortran: some questions
> And yet, that patch has absolutely nothing to do with libbacktrace.
> Hmmm. Let's try this one.
Works perfectly with the patch:
Program aborted. Backtrace:
#0 0xf75e5b9b _gfortrani_show_backtrace
../../../../trunk/libgfortran/runtime/backtrace.c:113
#1 0xf75e6aa7 _gfortrani_sys_abort
../../../../trunk/libgfortran/runtime/error.c:176
#2 0xf769a7a7 _gfortran_abort
../../../../trunk/libgfortran/intrinsics/abort.c:33
#3 0x80486e4 bar
/home/fx/gcc/irun/a.f90:9
#4 0x8048706 foo
/home/fx/gcc/irun/a.f90:5
#5 0x80486f2 test
/home/fx/gcc/irun/a.f90:2
#6 0x8048743 main
/home/fx/gcc/irun/a.f90:2
Aborted (core dumped)
Thanks!
FX
Re: Using libbacktrace in libgfortran: some questions
> Patch tested and committed with this ChangeLog entry. > > 2015-08-13 Ian Lance Taylor > > * dwarf.c (read_function_entry): Add vec_inlined parameter. > Change all callers. Thanks, this is great! I am going to submit the libgfortran patch to use libbacktrace today. Cheers, FX
Making __builtin_signbit type-generic
For use in both the Fortran front-end and in libgfortran, it would be really nice to have __builtin_signbit() be type-generic. It makes sense from the C point of view too, because it’s the only built-in from the C99 type-generic floating-point macros that is not type-generic. So far, I have built a compiler with the trivial change attached (marking the built-in type-generic in gcc/builtins.def) on x86_64-apple-darwin14, where I can confirm that the built-in is correctly expanded (without function call) on all floating-point types. Is there something more to do (apart from adjusting the documentation)? Joseph, I’m CC’ing you because of a 7-year old comment in PR 36757, where you said: > It's necessary to avoid the type-generic signbit expanding to call a library > function that may not exist, but as all currently supported floating-point > formats do have a sign bit specified in signbit_ro I believe the case > of failing to expand inline can be made into an abort. I can confirm that even in 2015, the only format which has (signbit_ro < 0) is real_internal_format, which I think doesn’t matter here. So: should I, in addition to the change in gcc/builtins.def, add some aborts() or sorry() in gcc/builtins.c if we can’t expand (which should never happen)? Thanks in advance for your help, FX signbit.diff Description: Binary data
Should we remove remnants of UWIN support in gcc/config.* files?
UWIN support was apparently removed from GCC in 2008. Yet some traces can still be found in gcc/config.* files. Attached patch would remove them. OK to commit? FX PS: gcc/config.host and gcc/config.build include some other such targets… without checking them all, I think the following could be removed: powerpc-*-beos i370-*-opened* | i370-*-mvs* i386-*-vsta i[34567]86-*-udk* i[34567]86-*-sysv4* i[34567]86-sequent-ptx4* | i[34567]86-sequent-sysv4* i[34567]86-*-sco3.2v5* Is there a good reason for not removing those targets? If not, I’ll try to track them down, check that they are indeed unsupported, and propose a patch removing them. uwin.ChangeLog Description: Binary data uwin.diff Description: Binary data
Re: Should we remove remnants of UWIN support in gcc/config.* files?
> Well, they aren't *targets*, but *host* and *build* systems. Yes, but do we maintain a list of support host or build systems, that would be different from our list of supported targets? (That’s a question out of curiosity. I do agree with the rest of your message: in practice, they are not supported.) FX
Re: Repository for the conversion machinery
[context for the Fortran list: the svn repo is about to be converted into a git repo, which will be the official gcc repo onwards] Hi Eric, I realize that some of our Fortran maintainers (and committers) are not listed in the map file: Fortran Janne Blomqvist Fortran Tobias Burnus Fortran Daniel Franke Fortran Daniel Kraft Fortran Mikael Morin Fortran Janus Weil Is that normal? Also, could I ask that the email address used for me be changed from: fxcoudert = François-Xavier Coudert (which has been inactive for many years now) to fxcoudert = François-Xavier Coudert Thanks, FX
Re: Repository for the conversion machinery
>> Fortran Janne Blomqvist >> Fortran Tobias Burnus >> Fortran Daniel Franke >> >> Fortran Daniel Kraft >> Fortran Mikael Morin >> Fortran Janus Weil > > Do they have actual commits in the repository or were their commits shipped > as patches and merged by a core maintainer? > > If the former, then I don't know why they're not in the map. It contains > an entry for every distinct Unix username it could extract. What usernames > should I expect these people to have? No, they did their commits themselves. Their Unix usernames are, in order: jb, burnus, dfranke, domo, mikael, janus In fact, if I just look at the commits to a very small subset of files (gcc/fortran/ChangeLog*), with “svn log”, I get the list of committers (Unix usernames) below. Many of them aren’t in the map at http://thyrsus.com/gitweb/?p=gcc-conversion.git;a=blob_plain;f=gcc.map;hb=HEAD Out of the 10 first usernames, 3 are not (ak, aldot, baldrick). Cheers, FX touille ~/devel/gcc/trunk/gcc/fortran $ for i in ChangeLog* ; do svn log $i |grep '^r[0-9]'|sed 's/.*| \([a-zA-Z0-9]*\) |.*/\1/' ; done | sort | uniq aj ak aldot aldyh amacleod amodra amylaar aoliva baldrick bdavis bernds bje bonzini bothner brooks burnus canqun carlos crowl dberlin dcarrera dfranke dj dje dmalcolm dnovillo dodji doko dominiq domob dorit drow ebotcazou echristo edlinger eedelman espindola fengwang froydnj fxcoudert gchare geoffk george gerald ghazi giovannibajo hjl hp hubicka iains ian jakub jamborm janus jason jb jsm28 jvdelisle kargl kazu kcook kenner krebbel ktietz ktkachov kyukhin langton lauras law lmillward manfred manu marxin matz meissner meyering mikael miyuki mpolacek mrs mueller nathan nickc pault pbrook pinskia pmderodat pzhao rakdver reichelt rguenth ro rsandifo rth rwild saliu sandra sayle schwab simonb sje spop srladd steven tbsaunde tkoenig tobi toon tromey tschwinge uros uweigand vehre vondele vries wilson zack zadeck
Re: Repository for the conversion machinery
> If the former, then I don't know why they're not in the map. In fact, I can look at the output of “svn log” for the MAINTAINERS file, which probably almost everyone with commit rights has modified. This contains 442 usernames, compared to the map’s 290. And there are probably more, which we’ll miss if we have to rely on manual modifications of that list… How was the map generated? FX PS: I found one username that first escaped my scripts because it contained a period, so I am raising a flag here, so the same doesn’t happen to you: m.hayes (commit 34779).
libgomp on 32-bit darwin
Hi all, It seems that, by default, a build of GCC on x86_64-apple-darwin15 will build 64-bit libgomp but not 32-bit libgomp. Is that intended? What should one do to explicitly enable libgomp on 64-bit? my configure is simply: ../gcc-6.1.0/configure --prefix=/usr/local/gfortran --with-gmp=/Users/fx/devel/gcc/deps-static/x86_64 --enable-languages=c,c++,fortran,objc,obj-c++ --build=x86_64-apple-darwin15 Thanks, FX
Re: libgomp on 32-bit darwin
>No problem here x86_64-apple-darwin15 with a build using… True, I didn’t realize libgomp is built… but the Fortran module files are not installed in the right place. $ ls /usr/local/gfortran/lib/**/libgomp.dylib /usr/local/gfortran/lib/i386/libgomp.dylib /usr/local/gfortran/lib/libgomp.dylib $ ls /usr/local/gfortran/lib/**/omp_lib.mod /usr/local/gfortran/lib/gcc/x86_64-apple-darwin15/6.1.0/finclude/omp_lib.mod It’s because the Makefile machinery is wrong. libgomp/Makefile.am has: fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/finclude while the corresponding libgfortran has: fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude notice the extra $(MULTISUBDIR). So this is apparently not a new bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60670), but it probably should be fixed. FX
[patch,libgomp] Make libgomp Fortran modules multilib-aware
The attached patch allows libgomp to install its Fortran modules in the correct multilib-aware directories, just like libgfortran does. Without it, multilib Fortran OpenMP code using the modules fails to compile because the modules are not found: $ gfortran -fopenmp a.f90 $ gfortran -fopenmp a.f90 -m32 a.f90:1:6: use omp_lib 1 Fatal Error: Can't open module file ‘omp_lib.mod’ for reading at (1): No such file or directory compilation terminated. Bootstrapped and tested on x86_64-apple-darwin15. OK to commit? FX 2016-05-03 Francois-Xavier Coudert PR libgomp/60670 * Makefile.am: Make fincludedir multilib-aware. * Makefile.in: Regenerate. Index: libgomp/Makefile.am === --- libgomp/Makefile.am (revision 235843) +++ libgomp/Makefile.am (working copy) @@ -10,7 +10,7 @@ config_path = @config_path@ search_path = $(addprefix $(top_srcdir)/config/, $(config_path)) $(top_srcdir) \ $(top_srcdir)/../include -fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/finclude +fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include vpath % $(strip $(search_path))
Re: [patch,libgomp] Make libgomp Fortran modules multilib-aware
ping > Le 3 mai 2016 à 23:25, FX a écrit : > > The attached patch allows libgomp to install its Fortran modules in the > correct multilib-aware directories, just like libgfortran does. > Without it, multilib Fortran OpenMP code using the modules fails to compile > because the modules are not found: > > $ gfortran -fopenmp a.f90 > $ gfortran -fopenmp a.f90 -m32 > a.f90:1:6: > > use omp_lib > 1 > Fatal Error: Can't open module file ‘omp_lib.mod’ for reading at (1): No such > file or directory > compilation terminated. > > > > Bootstrapped and tested on x86_64-apple-darwin15. OK to commit? > > FX > > > > > > > 2016-05-03 Francois-Xavier Coudert > > PR libgomp/60670 > * Makefile.am: Make fincludedir multilib-aware. > * Makefile.in: Regenerate. > Index: libgomp/Makefile.am === --- libgomp/Makefile.am (revision 235843) +++ libgomp/Makefile.am (working copy) @@ -10,7 +10,7 @@ config_path = @config_path@ search_path = $(addprefix $(top_srcdir)/config/, $(config_path)) $(top_srcdir) \ $(top_srcdir)/../include -fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/finclude +fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include vpath % $(strip $(search_path))
Re: [patch,libgomp] Make libgomp Fortran modules multilib-aware
Richard, Jakub, or any global write maintainer: can I get a review on this one-word patch? -- The attached patch allows libgomp to install its Fortran modules in the correct multilib-aware directories, just like libgfortran does. Without it, multilib Fortran OpenMP code using the modules fails to compile because the modules are not found: $ gfortran -fopenmp a.f90 $ gfortran -fopenmp a.f90 -m32 a.f90:1:6: use omp_lib 1 Fatal Error: Can't open module file ‘omp_lib.mod’ for reading at (1): No such file or directory compilation terminated. Bootstrapped and tested on x86_64-apple-darwin15. OK to commit? FX 2016-05-03 Francois-Xavier Coudert PR libgomp/60670 * Makefile.am: Make fincludedir multilib-aware. * Makefile.in: Regenerate. Index: libgomp/Makefile.am === --- libgomp/Makefile.am (revision 235843) +++ libgomp/Makefile.am (working copy) @@ -10,7 +10,7 @@ config_path = @config_path@ search_path = $(addprefix $(top_srcdir)/config/, $(config_path)) $(top_srcdir) \ $(top_srcdir)/../include -fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/finclude +fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include vpath % $(strip $(search_path))
Re: [patch,libgomp] Make libgomp Fortran modules multilib-aware
> Why? It should look for it first in 32/finclude, sure, but if not found, > should fall back to finclude dir, where it is found. > Does it differ between 32-bit and 64-bit compilation? Module files are target- and ABI-dependent and can differ between multilibs. Thus gfortran only looks for intrinsic .mod files in the 32/finclude, and not the parent. This was the design choice made when we introduced them (the driver passes the one and only valid finclude directory to the compiler through the -fintrinsic-modules-path option.) So, the best practice is for libgomp to store its .mod files into the multilib-specific finclude directory, just like libgfortran does. FX
Re: How do I initialize a __complex128 variable?
> How do I initialize a __complex128 variable? I found no documentation.
$ cat a.c
#include
#include
#include
int main(void)
{
char s1[50], s2[50];
const __complex128 z = -0.3Q + 0.1Qj;
quadmath_snprintf (s1, sizeof(s1), "%20Qe", __real__ z);
quadmath_snprintf (s2, sizeof(s2), "%20Qe", __imag__ z);
printf ("(%s,%s)\n", s1, s2);
return 0;
}
$ gcc a.c -lquadmath -W -Wall && ./a.out
( -3.00e-01,1.00e-01)
Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
> > .././../gcc-4.10-20140518/gcc/wide-int.cc:1274:23: error: invalid use of a > > cast in a inline asm context requiring an l-value: remove the cast or > > build with -fheinous-gnu-extensions > > umul_ppmm (val[1], val[0], op1.ulow (), op2.ulow ()); > > ~~~^ > > This is PR 61146. You can get around it by adding -fheinous-gnu-extensions > to BOOT_CFLAGS. This causes GCC bootstrap to fail on Darwin systems (whose system compiler is clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure it’s the right call, see below), I’ve filed a separate report for the bootstrap issue (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315). Regarding PR 61146, I agree with Marc Glisse (comment #3) that the casts in question look weird and should probably be removed, as was done in GMP. This code should be cleaned up, and it will fix bootstrap on clang-based target coincidentally, without adding another kludge. FX
Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
> This causes GCC bootstrap to fail on Darwin systems (whose system compiler is > clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure it’s > the right call, see below), I’ve filed a separate report for the bootstrap > issue (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315). Since my PR has been closed twice by Andrew Pinski (“it’s clang’s fault, bouh ouh”), I’d ask the maintainers to step in. Can we please provide a GCC that works for the default darwin setup? Or at least drop darwin as secondary target and document the failure? FX
Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
> Please post a patch. How about that? I’m not doing a full clean-up of the longlong.h code outside the area affected. This restores bootstrap on darwin, confirming that both the system compiler and later-stage-gcc accepts it. FX longlong.diff Description: Binary data longlong.ChangeLog Description: Binary data
Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
> So changing just 2 of them doesn't feel right to me… Here’s a patch that removes all the casts on output operands in x86/x86_64 code in longlong.h. Again bootstrapped on x86_64-apple-darwin13, passing both stage1 (system compiler) and stages 2-3 (gcc). OK to commit? Other archs which have such code are arc, arm, hppa, m32r, mc68000, mc68020, ns32000, ibm032, sparc, and vax. Since I don’t have any of those to test on, I can’t test it there. If you or another global reviewer indicate that a patch extending the work attached to these other archs is suitable, I’m willing to do the tedious work of proposing a full patch, but I won’t be able to test it (and I didn’t want to do it if it had no chance of being accepted). Thanks, FX longlong.ChangeLog Description: Binary data longlong.ChangeLog Description: Binary data
Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
> So changing just 2 of them doesn't feel right to me… [Again, with the patch actually attached… sorry] Here’s a patch that removes all the casts on output operands in x86/x86_64 code in longlong.h. Again bootstrapped on x86_64-apple-darwin13, passing both stage1 (system compiler) and stages 2-3 (gcc). OK to commit? Other archs which have such code are arc, arm, hppa, m32r, mc68000, mc68020, ns32000, ibm032, sparc, and vax. Since I don’t have any of those to test on, I can’t test it there. If you or another global reviewer indicate that a patch extending the work attached to these other archs is suitable, I’m willing to do the tedious work of proposing a full patch, but I won’t be able to test it (and I didn’t want to do it if it had no chance of being accepted). Thanks, FX longlong.diff Description: Binary data longlong.ChangeLog Description: Binary data
Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)
> Or, I can ask, any objections? In https://gcc.gnu.org/PR61146 it is stated > that GMP removed the casts in 2005. Among the many many versions of longlong.h that one can find around the web, many have don’t have these casts, including GMP and coreutils (http://code.metager.de/source/xref/gnu/coreutils/src/longlong.h). FX
Re: Darwin bootstrap failure following wide int merge
> After lengthy IRC discussions, what Richard and I can live with is > && !defined(__clang__) in this particular case that uses longlong.h > in GCC sources, with a comment why. I’ll test this patch and commit if there is no problem. But right now, current trunk doesn’t build on x86_64-apple-darwin due to error below. Richard, could this be due to your revision 211013? FX ../../trunk/gcc/rtl.c: In function ‘void cwi_output_hex(FILE*, const_rtx)’: ../../trunk/gcc/rtl.c:239:62: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘long int’ [-Werror=format=] fprintf (outfile, HOST_WIDE_INT_PRINT_HEX, CWI_ELT (x, --i)); ^ ../../trunk/gcc/rtl.c:239:62: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘long int’ [-Werror=format=] ../../trunk/gcc/rtl.c:241:69: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘long int’ [-Werror=format=] fprintf (outfile, HOST_WIDE_INT_PRINT_PADDED_HEX, CWI_ELT (x, i)); ^ ../../trunk/gcc/rtl.c:241:69: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘long int’ [-Werror=format=] cc1plus: all warnings being treated as errors make[3]: *** [build/rtl.o] Error 1 make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2
Re: Darwin bootstrap failure following wide int merge
> I suppose casting the result of CWI_ELT () to uint64_t fixes this. Do > similar errors happen elsewhere? I don’t think you can cast to uint64_t, as host wide int might be some other type, no? There are others: ../../trunk/gcc/print-rtl.c: In function ‘void print_rtx(const_rtx)’: ../../trunk/gcc/print-rtl.c:385:62: error: format ‘%lld’ expects argument of type ‘long long int’, but argument 3 has type ‘long int’ [-Werror=format=] fprintf (outfile, HOST_WIDE_INT_PRINT_DEC, XWINT (in_rtx, i)); ^ ../../trunk/gcc/print-rtl.c:385:62: error: format ‘%lld’ expects argument of type ‘long long int’, but argument 3 has type ‘long int’ [-Werror=format=] ../../trunk/gcc/print-rtl.c:388:48: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘long unsigned int’ [-Werror=format=] (unsigned HOST_WIDE_INT) XWINT (in_rtx, i)); ^ ../../trunk/gcc/print-rtl.c:388:48: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘long unsigned int’ [-Werror=format=] ../../trunk/gcc/genemit.c: In function ‘void gen_exp(rtx, rtx_code, char*)’: ../../trunk/gcc/genemit.c:200:49: error: format ‘%lld’ expects argument of type ‘long long int’, but argument 2 has type ‘long int’ [-Werror=format=] printf (HOST_WIDE_INT_PRINT_DEC_C, INTVAL (x)); ^ ../../trunk/gcc/genemit.c:200:49: error: format ‘%lld’ expects argument of type ‘long long int’, but argument 2 has type ‘long int’ [-Werror=format=] ../../trunk/gcc/genattrtab.c: In function ‘unsigned int write_test_expr(FILE*, rtx, unsigned int, int)’: ../../trunk/gcc/genattrtab.c:3758:61: error: format ‘%lld’ expects argument of type ‘long long int’, but argument 3 has type ‘long int’ [-Werror=format=] fprintf (outf, HOST_WIDE_INT_PRINT_DEC, XWINT (exp, 0)); ^ ../../trunk/gcc/genattrtab.c:3758:61: error: format ‘%lld’ expects argument of type ‘long long int’, but argument 3 has type ‘long int’ [-Werror=format=] ../../trunk/gcc/genattrtab.c: In function ‘void write_attr_value(FILE*, attr_desc*, rtx)’: ../../trunk/gcc/genattrtab.c:4350:61: error: format ‘%lld’ expects argument of type ‘long long int’, but argument 3 has type ‘long int’ [-Werror=format=] fprintf (outf, HOST_WIDE_INT_PRINT_DEC, INTVAL (value)); ^ ../../trunk/gcc/genattrtab.c:4350:61: error: format ‘%lld’ expects argument of type ‘long long int’, but argument 3 has type ‘long int’ [-Werror=format=]
Re: Darwin bootstrap failure following wide int merge
> After lengthy IRC discussions, what Richard and I can live with is > && !defined(__clang__) in this particular case that uses longlong.h > in GCC sources, with a comment why. > If we get too many of these workarounds, we should reconsider. Committed as revision 211023, after bootstrap on x86_64-apple-darwin13. Thanks! FX patch Description: application/applefile CL Description: Binary data
What is "fnspec function type attribute"?
In fortran/trans-decl.c, we have a comment above the code building function decls, saying: >The SPEC parameter specifies the function argument and return type >specification according to the fnspec function type attribute. */ I was away from GCC development for some time, so this is news to me. The syntax is not immediately clear, and neither a Google search nor a grep of the trunk’s numerous .texi files reveals any information. I’m creating new decls, what I am to do with it? FX
Top-level configury
Top-level configure has two quadmath-related options: --disable-libquadmath and
--disable-libquadmath-support . The first disables the building of libquadmath
itself, the second disables quadmath support in the Fortran front-end. They are
currently independent, but it would make a lot of sense for
--disable-libquadmath to imply --disable-libquadmath-support, unless
—enable-libquadmath-support is explicitly stated: Fortran front-end support
without libquadmath will be truly useless, and the current situation is
confusing to users (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55601).
However, my build/configure-foo is lacking, so I don’t know to achieve this.
I’ve tried the code below… is it how this is supposed to work?
Thanks in advance to any build/configure maintainer who can give me a hand with
this!
Index: configure.ac
===
--- configure.ac(revision 211315)
+++ configure.ac(working copy)
@@ -411,7 +411,9 @@ AS_HELP_STRING([--disable-libquadmath-su
ENABLE_LIBQUADMATH_SUPPORT=$enableval,
ENABLE_LIBQUADMATH_SUPPORT=yes)
enable_libquadmath_support=
-if test "${ENABLE_LIBQUADMATH_SUPPORT}" = "no" ; then
+if test "${ENABLE_LIBQUADMATH_SUPPORT}" = "no" ||
+ ( test "${ENABLE_LIBQUADMATH_SUPPORT}" = "" &&
+ test "${ENABLE_LIBQUADMATH}" = "no" ) ; then
enable_libquadmath_support=no
fi
[fortran, committed] IEEE modules added to gfortran and libgfortran
Hi, I’ve just committed support for Fortran 2003’s “IEEE modules” to the Fortran front-end and runtime library (libgfortran) to trunk as revision 212102 (https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=212102). Thanks to Uros, Steve, Jane and everyone who helped review the patch. The libgfortran part is heavily target-dependent, so if you get a new failure in libgfortran on your target, CC me! Non-Intel targets with SysV-style functions for floating-point control (fpsetmask and others) are most likely to be affected, since they sometimes differ in tiny ways (fpsetsticky vs. fpresetsticky, for example) and I could only test on a limited set. Hopefully, the list shouldn’t be that long. Cheers, FX
Identify IEE
I’ve recently added IEEE support for the Fortran front-end and library. As part
of that, the front-end should be able to determine which of the available
floating-point types are IEEE-conforming [1]. Right now, I’ve taken a
conservative approach and only considered the target’s float_type_node and
double_type_node as IEEE modes, but I’d like to improve that (for example, to
include long double and binary128 modes on x86).
How can I determine, from a “struct real_format”, whether it is an IEEE format
or not? I’ve looked through gcc/real.{h,c} but could find no clear solution. If
there is none, would it be okay to add a new bool field to the structure, named
“ieee” or “ieee_format”, to discriminate?
Thanks,
FX
[1] The Fortran standard defines such as types as having an "IEC 60559:1989
floating-point format”. Decimal formats are out, as they are unsupported in
gfortran, so I guess this definition covers binary16 to binary128, as well as
extended and extendable precision formats.
Lots of C++ failures
Hi,
I am testing trunk on darwin14 (Mac OS X Yosemite), and I am seeing a lot of
(800 so far) C++ failures, in the form of internal compiler errors, like this:
> vbase1.C:17:1: error: unrecognizable insn:
> }
> ^
> (call_insn/j 4 3 5 (call (mem/u/c:DI (const:DI (unspec:DI [
> (symbol_ref/i:DI ("_ZN8VDerivedD1Ev") [flags 0x1]
> )
> ] UNSPEC_GOTPCREL)) [0 S8 A8])
> (const_int 0 [0])) vbase1.C:9 -1
> (nil)
> (nil))
> vbase1.C:17:1: internal compiler error: in insn_default_length, at
> config/i386/i386.md:2071
Google and bugzilla search don’t find anything particularly recent like that,
but the scale of it is weird. I have isolated a very small reproducer, attached
(gives the above ICE with no compile options).
Has anyone seen this on another platform? Is it known? Otherwise, I’ll report
it.
FX
vbase1.C
Description: Binary data
Re: Lots of C++ failures
In fact, after looking at the latest gcc-patches messages, I think it may be
due to this commit: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01107.html
(based purely on the fact that the unrecognized insn is a call, and the patch
deals with CALL_EXPR).
FX
> I am testing trunk on darwin14 (Mac OS X Yosemite), and I am seeing a lot of
> (800 so far) C++ failures, in the form of internal compiler errors, like this:
>
>> vbase1.C:17:1: error: unrecognizable insn:
>> }
>> ^
>> (call_insn/j 4 3 5 (call (mem/u/c:DI (const:DI (unspec:DI [
>>(symbol_ref/i:DI ("_ZN8VDerivedD1Ev") [flags 0x1]
>> )
>>] UNSPEC_GOTPCREL)) [0 S8 A8])
>>(const_int 0 [0])) vbase1.C:9 -1
>> (nil)
>>(nil))
>> vbase1.C:17:1: internal compiler error: in insn_default_length, at
>> config/i386/i386.md:2071
>
>
> Google and bugzilla search don’t find anything particularly recent like that,
> but the scale of it is weird. I have isolated a very small reproducer,
> attached (gives the above ICE with no compile options).
>
> Has anyone seen this on another platform? Is it known? Otherwise, I’ll report
> it.
>
> FX
>
>
>
>
Re: Lots of C++ failures
> In fact, after looking at the latest gcc-patches messages, I think it may be > due to this commit: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01107.html > (based purely on the fact that the unrecognized insn is a call, and the patch > deals with CALL_EXPR). Duh. No, it’s not, cause it’s apparently not committed yet (at least, not in rev. 215234 which is the one failing for me). But now, I’ve found it is PR 61387 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61387), already known. FX
Problem with accessing built-ins from Fortran front-end
Hi, I’m trying to make the Fortran front-end emit calls to some builtins we don’t currently use (isfinite, isnormal). However, trying to use the same code as isnan doesn’t work at all. Our gfc_define_builtin does three things: decl = add_builtin_function (name, type, code, BUILT_IN_NORMAL, library_name, NULL_TREE); set_call_expr_flags (decl, attr); set_builtin_decl (code, decl, true); While doing so works with isnan, it fails with isfinite or isnormal. When I try to, I get an ICE in tree checking: * frame #0: 0x000100c02338 f951`build_call_expr_loc_array(loc=0, fndecl=0x, n=2, argarray=0x7fff5fbfeb20) + 24 at tree.h:2846 frame #1: 0x000100c0259a f951`build_call_expr(fndecl=, n=) + 186 at tree.c:10550 frame #2: 0x00010046f671 f951`fold_builtin_interclass_mathfn(loc=, fndecl=, arg=0x00014340c990) + 337 at builtins.c:9393 frame #3: 0x000100485e34 f951`fold_builtin_1(loc=260, fndecl=0x000143449360, arg0=0x00014340c990, ignore=) + 2964 at builtins.c:10050 frame #4: 0x00010049030c f951`fold_builtin_n(loc=, fndecl=, args=, nargs=, ignore=) + 1116 at builtins.c:10409 frame #5: 0x000100491c33 f951`fold_builtin_call_array(loc=260, type=0x000143405690, fn=0x00014351fc40, n=1, argarray=0x7fff5fbfeeb0) + 355 at builtins.c:10575 frame #6: 0x000100c024c5 f951`build_call_expr_loc(loc=, fndecl=, n=) + 181 at tree.c:10533 I don’t understand how the middle-end builtins decl should work, would someone have a hint of how to fix this? Thanks, FX PS: the attached patch emits isfinite instead of isnan to test the built-in changes with minimal. With that patch, the Fortran source attached triggers the ICE above. problem.diff Description: Binary data b.f90 Description: Binary data
Re: Problem with accessing built-ins from Fortran front-end
> Thus, the middle-end assumes that if you have __builtin_{isfinite,isnormal},
> you also have __builtin_is{less,greater}equal builtins too.
Many thanks to both of you! I wasn’t looking into the right place at all. I
defined them, and now it works.
One related question: the __builtin_signbit is not type generic, is there any
reason for it not to be? Is there any reason for it not to be? I ask for two
reasons: 1. it would make my life easier, and 2. it’s generated in the folding
of BUILT_IN_ISINF_SIGN, which is weird because the later is type generic.
Thanks again,
FX
Issue with __builtin_remainder expansion on i386
Hi all, I have just submitted a patch emitting some new floating-point code from the Fortran front-end, improving our IEEE support there: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02444.html However, in one of the cases where we emit a call to __builtin_remainderf(), we get wrong code generation on i386. It is peculiar because: - the wrong code occurs at all optimization levels, and the following flags (any or all) do not affect it: -mfpmath=sse -msse2 -fno-unsafe-math-optimizations -frounding-math -fsignaling-nans - the wrong code does not occur with -ffloat-store - the code generate looks fine by every aspect I could try. I could not generate a direct C testcase, unfortunately, but it is equivalent to: D.2303 = __builtin_remainderf (ieee_value_4 (&C.2299, &D.2301), 1.0e+0); where ieee_value_4() is a function that returns a positive infinity (for the specific values of arguments passed). However, if I split it in: x = ieee_value_4 (&C.2289, &D.2293); D.2297 = __builtin_remainderf (x, 1.0e+0); then the wrong result does not occur anymore either. What’s bugging me is that, with and without -ffloat-store, the same dump trees are generated. So I don’t know how to get further on debugging this. I do think it’s something wrong with the expansion of __builtin_remainderf(), especially as it depends on -ffloat-store. I attach the source code triggering it (built on trunk with my patch at https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02444.html), the tree dumps, and the assembler outputs (a.s without -ffloat-store, and a.s.floatstore with it). I can clearly see, from the assembly diff, that something is indeed changing but I cannot understand what. Thanks in advance if you have any hint to share, or get a minute to look at the dumps/assembly. FX a.f90 Description: Binary data a.f90.003t.original Description: Binary data a.f90.174t.optimized Description: Binary data a.s Description: Binary data a.s.floatstore Description: Binary data
Is "optimize" attribute on fndecl handled differently?
I’m trying to get the Fortran front-end to add function-specific optimization
flags to certain functions (those that request IEEE compliance through use of
the specific Fortran module). It seems simple enough, adding the attribute to
the fndecl, but though I’ve tried to do so at two different places (when we
first build the function decl, and when we later call it), both fail with:
Warning: ‘optimize’ attribute directive ignored [-Wattributes]
I’m getting the feeling that maybe it’s because I gave the attribute a string
value, and it’s expecting a tree already… but the functions to do so are not
generic, they’re in c-family, which probably means I can’t use them.
Any idea how I could get to the result I want? (setting options from the
Fortran front-end)
Thanks,
FX
Index: trans-decl.c
===
--- trans-decl.c(revision 215668)
+++ trans-decl.c(working copy)
@@ -1961,6 +1961,13 @@
TREE_USED (fndecl) = 1;
attributes = add_attributes_to_decl (attr, NULL_TREE);
+
+#define OPT "fno-unsafe-math-optimizations"
+ tree opt = build_tree_list (NULL_TREE, build_string (strlen (OPT), OPT));
+ attributes = tree_cons (get_identifier ("optimize"), opt, attributes);
+#undef OPT
+
decl_attributes (&fndecl, attributes, 0);
/* Figure out the return type of the declared function, and build a
@@ -5760,8 +5767,19 @@
the floating point state. */
ieee = is_ieee_module_used (ns);
if (ieee)
-fpstate = save_fp_state (&init);
+{
+ tree attributes;
+ fpstate = save_fp_state (&init);
+
+#define OPT "fno-unsafe-math-optimizations"
+ tree opt = build_tree_list (NULL_TREE, build_string (strlen (OPT), OPT));
+ attributes = tree_cons (get_identifier ("optimize"), opt, NULL_TREE);
+ decl_attributes (&fndecl, attributes, 0);
+#undef OPT
+}
+
/* Now generate the code for the body of this function. */
gfc_init_block (&body);
Re: Is "optimize" attribute on fndecl handled differently?
> It looks like parse_optimize_options has nothing c-family specific in
> it, so it could be moved to attribs.c. Then you'd use
> build_optimization_node to set DECL_FUNCTION_SPECIFIC_OPTIMIZATION, as
> done in c-common.c:handle_optimize_attribute.
Yep, I’ve done it that way, it works fine.
There’s one surprise: a few flags (flag_finite_math_only, flag_signed_zeros,
flag_trapping_math, flag_unsafe_math_optimizations) seem to appear or disappear
when I set specific flags for a function. What I do is this:
static void
add_ieee_options (tree fndecl)
{
struct cl_optimization cur_opts;
/* Save current options. */
cl_optimization_save (&cur_opts, &global_options);
/* Parse options, and update the vector. */
/* parse_optimize_options (opts, true);*/
DECL_FUNCTION_SPECIFIC_OPTIMIZATION (fndecl)
= build_optimization_node (&global_options);
debug_tree (optimization_current_node);
debug_tree (DECL_FUNCTION_SPECIFIC_OPTIMIZATION (fndecl));
/* Restore current options. */
cl_optimization_restore (&global_options, &cur_opts);
}
So, even if I don’t change anything to the local options (global is: -O3
-ffast-math), I see some differences between “optimization_current_node” and
"DECL_FUNCTION_SPECIFIC_OPTIMIZATION (fndecl)”:
> 1,3d0
> < align_functions (0x10)
> < align_jumps (0x10)
> < align_loops (0x10)
> 26d22
> < flag_finite_math_only (0x1)
> 71a68
> > flag_signed_zeros (0x1)
> 78a76
> > flag_trapping_math (0x1)
> 113d110
> < flag_unsafe_math_optimizations (0x1)
Is that a bug in optimization handling, or am I missing something?
FX
Re: Is "optimize" attribute on fndecl handled differently?
tl;dr: there is a bug in optimization options saving/restoring. See after the
break for simple C testcase.
> Unfortunately I can't find if/where there is some explanation for
> these frontend_set_flag_* options -- how they're supposed to work and
> who's responsible for setting them.
It’s not them, but this got me looking into the right place.
In my case, opts.c’s set_fast_math_flags() is called three times:
1. first, from toplev_main -> decode_options -> default_options_optimization
-> handle_generated_option -> handle_option -> common_handle_option
2. then, from toplev_main -> decode_options -> read_cmdline_option ->
handle_option -> common_handle_option
3. then, from my own build_function_decl -> parse_optimize_options ->
decode_options -> default_options_optimization -> handle_generated_option ->
handle_option -> common_handle_option
At 1 and 3, it’s called with value = 0, and at 2, with value = 1. So it is
indeed a bug: because we re-parse the defaults at 3, we reset some of the flags
dependent on -ffast-math (the ones quoted before), overwriting their earlier
value.
PS: There is also something similar with
align_functions/align_jumps/align_loops flags, but I don’t have time to chase
it right now.
This is easy to see with a simple C test case:
//__attribute__ ((optimize("strength-reduce")))
int foo (float x) { return __builtin_isnan(x); }
Compiled with -O3 -ffast-math, the isnan is simplified out (fast math means no
NaNs). If you uncomment the attribute (chosen because it’s actually useless),
and compile again with -O3 -ffast-math: the isnan test is not simplified any
more. This is because the codepath through default_options_optimization() has
overwritten the value of the flags handled in set_fast_math_flags():
flag_finite_math_only, flag_signed_zeros, flag_trapping_math and
flag_unsafe_math_optimizations.
I’m CC’ing the maintainers who added the optimize attribute in the first place,
as they might have an idea how to fix this. This is way beyond my league!
Thanks Steven for your help!
FX
Re: Is "optimize" attribute on fndecl handled differently?
Filed as PR63401: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63401
> This is easy to see with a simple C test case:
>
> //__attribute__ ((optimize("strength-reduce")))
> int foo (float x) { return __builtin_isnan(x); }
>
> Compiled with -O3 -ffast-math, the isnan is simplified out (fast math means
> no NaNs). If you uncomment the attribute (chosen because it’s actually
> useless), and compile again with -O3 -ffast-math: the isnan test is not
> simplified any more. This is because the codepath through
> default_options_optimization() has overwritten the value of the flags handled
> in set_fast_math_flags(): flag_finite_math_only, flag_signed_zeros,
> flag_trapping_math and flag_unsafe_math_optimizations.
>
> I’m CC’ing the maintainers who added the optimize attribute in the first
> place, as they might have an idea how to fix this. This is way beyond my
> league!
>
>
> Thanks Steven for your help!
> FX
Re: Issue with __builtin_remainder expansion on i386
> The __builtin_remainderf on x86 expands to x87 fprem1 instruction [1].
> According to the table in [1], +inf is not handled, and generates
> division-by-zero exception.
>
> IMO, we have to add "&& flag_finite_math_only" to expander enable
> condition of remainder{sf,df,xf}3 expanders in i386.md
I can confirm that the patch below indeed fixes the issue.
Index: gcc/config/i386/i386.md
===
--- gcc/config/i386/i386.md (revision 215645)
+++ gcc/config/i386/i386.md (working copy)
@@ -13893,7 +13893,7 @@
[(use (match_operand:XF 0 "register_operand"))
(use (match_operand:XF 1 "general_operand"))
(use (match_operand:XF 2 "general_operand"))]
- "TARGET_USE_FANCY_MATH_387"
+ "TARGET_USE_FANCY_MATH_387 && flag_finite_math_only"
{
rtx_code_label *label = gen_label_rtx ();
@@ -13916,7 +13916,7 @@
[(use (match_operand:MODEF 0 "register_operand"))
(use (match_operand:MODEF 1 "general_operand"))
(use (match_operand:MODEF 2 "general_operand"))]
- "TARGET_USE_FANCY_MATH_387"
+ "TARGET_USE_FANCY_MATH_387 && flag_finite_math_only"
{
rtx (*gen_truncxf) (rtx, rtx);
Re: Is "optimize" attribute on fndecl handled differently?
Thanks for the analysis. FYI: I don’t intend to follow up on that middle-end part, it’s much out of my league, and I focus my limited hacking time to the Fortran front-end and runtime library. I’ve filed the PR, so at least the problem is documented. I will affect gfortran in the form of missed optimizations in routines using the IEEE modules, so at least it’s not wrong code for us :) Cheers, FX
Re: [patch] Add -static-libquadmath option
Hi, I sent my last “driver/options” patch to Neil Booth, listed as “option handling” maintainer, but the email bounced back from his daikokuya.co.uk address. Given that he did not commit to the tree since January 2005 (almost 10 years), and that his last commit was to the toplevel ChangeLog: 2005-01-19 Neil Booth * MAINTAINERS: Remove self as cpplib maintainer. I suppose it would make sense to remove it “option handling” maintainer. FX
C++ headers vs safe-ctype.h
Hi, We are currently seeing two cases of C++-related bootstrap failures on Darwin, due to C++ header being included after “system.h” and “safe-ctype.h”: headers, on Darwin, use ctype macros which GCC poisons through safe-ctype.h https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63750 This triggers in libcc1, and in the new ipa-chkp.c file. We can move the #include line higher in the source files (as is already done, e.g., in go/go-system.h), but we probably need to think of a global solution, such as including basic C++ headers directly from the system.h header. I do not know enough about the state of our mixed C/C++ build to understand if that would work or create chaos, so I’m dropping a line here so that “awareness of this general issue is raised”, as they say rather pompously :) Cheers, FX PS: Ilya, I tried to CC you on the bugzilla PR 63750, but you’re not in the database.
How is libtool updated in GCC?
Hi, libtool just released a new version to add support for OS X Yosemite (the old libtool had a poorly designed globbing pattern). It really is a one-line change (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610#c7), but we need to incorporate it into the GCC code base and rebuild all our configure’s. How is libtool handled in GCC? Do we import from upstream, or merge the changes that we need? It looks like it’s done manually and selectively, but I’d like confirmation of that. Thanks, FX
Re: How is libtool updated in GCC?
> If you import rather than selectively merging one change you need (I > think) to revert libtool commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c > (incompatible with GCC handling of sysroots), as well as updating all > three relevant repositories (GCC, binutils-gdb, src - I'm not sure if > anything in binutils-gdb actually uses libtool but it has the files at > toplevel). So I’ve actually chosen to avoid the mess and selectly merge the one change that we need. Looking at the history of libtool.m4 in our tree, it looks like others have done that in the past, too. Thanks for the feedback. On the src repository, is it documented somewhere how to change it? (I have probably done it in the past, but don’t remember) FX
libcc1 breaks bootstrap on darwin
Hi libcc1 team and build maintainers, Since libcc1 isn’t bootstrapped anymore, it breaks bootstrap on darwin with GCC as the system compiler (which isn’t the default, but is still pretty common, notably for people who need to build the Ada compiler): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64023 When libcc1 is built at stage3, the freshly built g++ compiler is used, but it’s not given the proper CXXFLAGS to go with, in particular the -B options pointing towards libstdc++ and libsupc++. I think that’s because, when built from the top-level Makefile, it is made with $(HOST_EXPORTS) but not with $(POSTSTAGE1_HOST_EXPORTS). However, I do not know how to fix that. As I understand it, this part of the Makefile is generated from the information in the toplevel Makefile.def, but I do not know how to enter that information there. Could someone help? Thanks, FX
Re: libcc1 breaks bootstrap on darwin
> -L/opt/gcc/p_build/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs > Why aren't they sufficient for MacOS linker to find libstdc++.a? Because it’s gonna also use -static-libstdc++, which relies on spec substitution, for which -L is not enough. FX
[patch, build] Restore bootstrap in building libcc1 on darwin
tl;dr: One question to build maintainers, and one patch submitted to toplevel configure.ac --- I’m looked into the issue some more, and am comparing two builds of trunk (exact same source), one configured with system compiler (clang) in PATH, the other with GCC 4.9.2 in PATH. At the toplevel configure, the only meaningful difference is that the gcc-based build sets stage1_ldflags='-static-libstdc++ -static-libgcc' while the clang-based has stage1_ldflags='' (clang doesn’t recognized -static-libstdc++). This is included into the toplevel Makefile as STAGE1_LDFLAGS (the comment appropriately says "Linker flags to use on the host, for stage1 or when not bootstrapping”). Those are exported by HOST_EXPORTS, which is are then used by configure-libcc1, all-libcc1, etc. Thus, we end up using STAGE1_LDFLAGS, which correspond to the system compiler, instead of the stage3 compiler (as we should). So, this is “false negative” part of the problem (namely, why we don’t see the failure when bootstrapping with clang): we use STAGE1_LDFLAGS in building libcc1, and with clang as system compiler we don’t use static linking of the C++ library. This part, I don’t know how to fix: it is for the build experts to address. It is a real problem: it leads to libcc1.so being linked dynamically to libstdc++ and libgcc, instead of statically (as it should). --- Second part of the question: when the freshly built g++ is used, we need to pass the appropriate -B options. As I understand it, the appropriate place for that is in the toplevel configure.ac, where we already pass down the respective -L options. Indeed, the attached patch restores bootstrap on x86_64-apple-darwin14 with gcc as system compiler (and doesn’t break the bootstrap with clang as system compiler). OK to commit? FX PS: HJ, the reason only don’t see this on Linux is that only Darwin (AFAIK) plays spec tricks with static-libstdc++ (in gcc/config/darwin.h) libcc1.ChangeLog Description: Binary data libcc1.diff Description: Binary data
Pushing recent libtool fix to binutils-gdb and newlib/libgloss
*ping*
Didn’t get any response to my question so far…
>> Thanks everyone for the comments and review.
>> Committed as r217366
>
> I cannot push the change to binutils-gdb as I don’t have write access there.
> Also, Joseph Myers said I needed to commit to newlib/libgloss, but their
> webpage only mentions read-only CVS.
>
> Could someone do it for me?
>
> Thanks,
> FX
>
>
>
>
> commit 8d25b840ce688bfa601b0ad5f53c4185627c8975
> Author: FX
> Date: Wed Nov 12 13:26:06 2014 +0100
>
>* libtool.m4: Fix globbing of darwin versions.
>
> diff --git a/ChangeLog b/ChangeLog
> index 32b3c15..5ed8242 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,7 @@
> +2014-11-12 Francois-Xavier Coudert
> +
> + * libtool.m4: Fix globbing of darwin versions.
> +
> 2014-10-15 Tristan Gingold
>
>* src-release.sh (do_proto_toplev): Configure with --target.
> diff --git a/libtool.m4 b/libtool.m4
> index 797468f..c96d80c 100644
> --- a/libtool.m4
> +++ b/libtool.m4
> @@ -1006,7 +1006,7 @@ _LT_EOF
> case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
>10.0,*86*-darwin8*|10.0,*-darwin[[91]]*)
> _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
> - 10.[[012]]*)
> + 10.[[012]][[,.]]*)
> _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined
> ${wl}sup
>10.*)
> _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
>
Re: Pushing recent libtool fix to binutils-gdb and newlib/libgloss
> Done: > https://sourceware.org/ml/binutils/2014-11/msg00318.html Thanks!
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
10-days ping This restores bootstrap on a secondary target, target maintainer is OK with it. I think I need build maintainers approval, so please review. > when the freshly built g++ is used, we need to pass the appropriate -B > options. As I understand it, the appropriate place for that is in the > toplevel configure.ac, where we already pass down the respective -L options. > Indeed, the attached patch restores bootstrap on x86_64-apple-darwin14 with > gcc as system compiler (and doesn’t break the bootstrap with clang as system > compiler). > > OK to commit? > > FX > > > > PS: HJ, the reason only don’t see this on Linux is that only Darwin (AFAIK) > plays spec tricks with static-libstdc++ (in gcc/config/darwin.h) libcc1.ChangeLog Description: Binary data libcc1.diff Description: Binary data
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
> While in my testing, 64-bit Mac OS X 10.10.1 (x86_64-apple-darwin14.0.0) > now bootstraps, but 32-bit (i386-apple-darwin14.0.0) does not: Is it due to my patch, or pre-existing bootstrap failure? How do you configure this 32-bit compiler? target/build/host/CFLAGS/CXXFLAGS/etc FX
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
> The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic > the libiberty pic build appends: -fno-common (and not even -fPIC) [NB -fPIC > _won't_ override -mdynamic-no-pic, so that's not a simple way out] > This means that the PIC library is being built with non-pic relocs. config/mh-darwin says that -mdynamic-no-pic is there because it “speeds compiles by 3-5%”. I don’t think we care about speed when the bootstrap fails, so can we remove it altogether? FX darwin.diff Description: Binary data
Re: [patch, build] Restore bootstrap in building libcc1 on darwin
> Can you try adding it as > > T_CFLAGS += -mdynamic-no-pic > > in gcc/config/t-tarwin instead? Nope, doing so fails to link libgcc_s.dylib: /Users/fx/devel/gcc/i/./gcc/xgcc -B/Users/fx/devel/gcc/i/./gcc/ -B/Users/fx/devel/gcc/i2/i386-apple-darwin14.0.0/bin/ -B/Users/fx/devel/gcc/i2/i386-apple-darwin14.0.0/lib/ -isystem /Users/fx/devel/gcc/i2/i386-apple-darwin14.0.0/include -isystem /Users/fx/devel/gcc/i2/i386-apple-darwin14.0.0/sys-include-O2 -g -O2 -DIN_GCC-mdynamic-no-pic -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -dynamiclib -nodefaultlibs -install_name /Users/fx/devel/gcc/i2/lib/libgcc_s.1.dylib -single_module -o ./libgcc_s.dylib -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1 -current_version 1.0 -g -O2 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _fixsfti_s.o _fixdfti_s.o _fixxfti_s.o _fixtfti_s.o _fixunssfti_s.o _fixunsdfti_s.o _fixunsxfti_s.o _fixunstfti_s.o _floattisf_s.o _floattidf_s.o _floattixf_s.o _floattitf_s.o _floatuntisf_s.o _floatuntidf_s.o _floatuntixf_s.o _floatuntitf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-64_s.o cpuinfo_s.o tf-signs_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc ld: warning: could not create compact unwind for __Unwind_RaiseException: does not use EBP or ESP based frame ld: warning: could not create compact unwind for __Unwind_ForcedUnwind: does not use EBP or ESP based frame ld: warning: could not create compact unwind for __Unwind_Resume: does not use EBP or ESP based frame ld: warning: could not create compact unwind for __Unwind_Resume_or_Rethrow: does not use EBP or ESP based frame ld: illegal text-relocation to '4-byte-literal' in _powisf2_s.o from '___powisf2' in _powisf2_s.o for architecture i386 collect2: error: ld returned 1 exit status make[3]: *** [libgcc_s.dylib] Error 1 make[2]: *** [all-stage1-target-libgcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2
Regular darwin builds
Hi all, I’ve set up daily builds and regtests on a darwin box. The results should appear directly on gcc-testresults (https://gcc.gnu.org/ml/gcc-testresults/current/). This should, in the future, help track down regressions affecting darwin (PIC-related, in particular!). The hardware is new, the OS is the latest and greatest (x86_64-apple-darwin14), and will be updated to keep it that way. However, it’s not very powerful (it’s a Mac Mini). Bootstrap (C, C++, Obj-C, Obj-C++, Fortran, Java, LTO) takes about 2 hours, regtesting both 32 and 64-bit takes a bit over 3 hours. I plan to schedule it for: - daily bootstrap + regtest of trunk - weekly bootstrap of latest release branch (currently 4.9) If you have other ideas, I’m open to suggestions. FX
Re: Regular darwin builds
Yes, the ubsan issues are about setting DYLD_LIBRARY_PATH: dyld: Symbol not found: __ZTIN10__cxxabiv117__class_type_infoE Referenced from: /Users/fx/autobuilds/builds/gcc-trunk-218778/x86_64-apple-darwin14.0.0/i386/libsanitizer/ubsan/.libs/libubsan.0.dylib Expected in: /usr/lib/libstdc++.6.dylib in /Users/fx/autobuilds/builds/gcc-trunk-218778/x86_64-apple-darwin14.0.0/i386/libsanitizer/ubsan/.libs/libubsan.0.dylib Another testsuite issue on darwin is that testsuite doesn’t clean up the .dSYM directories it generates. This gets really annoying on my autotester :( FX
Re: GCC 4.8.4 Status Report (2014-12-05)
> Currently gcc 4.8.4 does not bootstrap on darwin14 (Yosemite) due to pr61407. > Would it be possible to apply the patch at > https://gcc.gnu.org/bugzilla/attachment.cgi?id=33932 > before 4.8.4 is released? Results with the patch are posted at > https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg02096.html. If Mike thinks it’s a good idea, I’ll do it. I’ve tested 4.8 with it multiple times, and it works well. FX
Re: GCC 4.8.4 Status Report (2014-12-05)
> Ok. Committed to the 4.8 branch as rev. 218873 FX
GCC 9 linker error, missing GOMP_loop_nonmonotonic_dynamic_next
Hi gcc and gfortran developers, While testing GCC 9.1.0 before shipping it as part of Homebrew for macOS, we’re seeing the following OpenMP-based failure when recompiling several software packages with GCC 9. It includes both C++ and Fortran codes, which were working fine with the exact same setup and GCC 8.3.0. The missing symbols we’re seeing are always in this list: _GOMP_loop_nonmonotonic_dynamic_next _GOMP_loop_nonmonotonic_dynamic_start _GOMP_loop_ull_nonmonotonic_guided_next _GOMP_loop_ull_nonmonotonic_guided_start The linker lines that generate these issues vary, but they are of the form: g++-9 -fopenmp -std=c++14 -DNDEBUG *.o -o foo or: gfortran -fopenmp -ffast-math -funroll-loops -ftree-vectorize -ffree-form -O2 *.o -o foo which I think is valid, since passing -fopenmp to the driver should link the necessary libraries, in which it would find the symbols that the front-ends emitted. I have read the release notes and can’t find anything related. Any advice? Thanks, FX
Re: GCC 9 linker error, missing GOMP_loop_nonmonotonic_dynamic_next
Update on this issue: >> Those are certainly exported from my GCC 9 libgomp.so.1.0.0 (at least on >> Linux but I don't see how it could not be elsewhere). I can confirm they are present. The issue I am having is indeed due to GCC 9 trying to link against the wrong library: it turns out that LLVM’s libomp also ships a libgomp.dylib, as a symlink to libomp.dylib (and same thing with static libraries). This is what is interfering here. So, quick questions: - are LLVM’s libomp and GCC’s libgomp supposed to be 100% compatible? - if not, why is LLVM symlinking its library under another name? Thanks, FX
Multilib seems to fail for mingw-w64 build
Hi, I am trying to compile a multilib-enabled GCC cross-compiler targetting mingw-w64. I have the mingw-w64 headers installed, the CRT built for both 32- and 64-bit, and installed (with libs in $ROOT/x86_64-w64-mingw32/lib32 and $ROOT/x86_64-w64-mingw32/lib respectively). Building the compiler itself work, but it fails to link 32-bit libgcc because it is not looking for the mingw libraries in the right place. The configure line is: ../gcc-src/configure --prefix=$ROOT --with-sysroot=$ROOT --disable-werror --target=x86_64-w64-mingw32 --enable-targets=all but when it gets to link 32-bit libgcc_s_sjlj-1.dll, it fails because it is searching for 32-bit libmingwthrd.a in the 64-bit library directory: /Users/fx/devel/mingw-w64/cross/x86_64-w64-mingw32/bin/ld: skipping incompatible /Users/fx/devel/mingw-w64/cross/x86_64-w64-mingw32/lib/libmingwthrd.a when searching for -lmingwthrd The reason behind that is simply that, when building 32-bit libgcc, the wrong flags are passed to xgcc: -L$ROOT/x86_64-w64-mingw32/lib -L$ROOT/mingw/lib -isystem $ROOT/x86_64-w64-mingw32/include -isystem $ROOT/mingw/include -B$ROOT/x86_64-w64-mingw32/bin/ -B$ROOT/x86_64-w64-mingw32/lib/ -isystem $ROOT/x86_64-w64-mingw32/include -isystem $ROOT/x86_64-w64-mingw32/sys-include These flags all refer to lib instead of lib32. I can reproduce the problem with both GCC trunk and GCC 6.3.0. Have I missed a configuration flag? Otherwise it seems like a bug in the multilib setup, because the target configuration file seems correct: $ cat gcc/config/i386/t-mingw-w64 MULTILIB_OPTIONS = m64/m32 MULTILIB_DIRNAMES = 64 32 MULTILIB_OSDIRNAMES = ../lib ../lib32 Any help in debugging this would be appreciated. Thanks, FX
Re: Multilib seems to fail for mingw-w64 build
Hi,
Help from a build maintainer needed :)
I am trying to find why mingw-w64 won’t build as a GCC cross-compiler with
multilib (see full report below). It fails in building 32-bit libgcc, because
we’re passing it the wrong flags. From toplevel configure, we have:
FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET#' -L${prefix}/${target}/lib
-L${prefix}/mingw/lib -isystem ${prefix}/${target}/include -isystem
${prefix}/mingw/include’
However this is wrong: these flags should be dependent on whether we link 32 or
64-bit, as 32-bit libraries are in ${prefix}/${target}/lib32, and 64-bit
libraries are in ${prefix}/${target}/lib.
Anyone knows how we can make toplevel configure aware of the multilib nature of
the system?
Cheers,
FX
PS: The gcc specs know how to deal with that, as we have in the target
configuration file:
$ cat gcc/config/i386/t-mingw-w64
MULTILIB_OPTIONS = m64/m32
MULTILIB_DIRNAMES = 64 32
MULTILIB_OSDIRNAMES = ../lib ../lib32
> Le 13 janv. 2017 à 13:25, FX a écrit :
>
> Hi,
>
> I am trying to compile a multilib-enabled GCC cross-compiler targetting
> mingw-w64. I have the mingw-w64 headers installed, the CRT built for both 32-
> and 64-bit, and installed (with libs in $ROOT/x86_64-w64-mingw32/lib32 and
> $ROOT/x86_64-w64-mingw32/lib respectively).
>
> Building the compiler itself work, but it fails to link 32-bit libgcc because
> it is not looking for the mingw libraries in the right place. The configure
> line is:
>
>../gcc-src/configure --prefix=$ROOT --with-sysroot=$ROOT --disable-werror
> --target=x86_64-w64-mingw32 --enable-targets=all
>
> but when it gets to link 32-bit libgcc_s_sjlj-1.dll, it fails because it is
> searching for 32-bit libmingwthrd.a in the 64-bit library directory:
>
>/Users/fx/devel/mingw-w64/cross/x86_64-w64-mingw32/bin/ld: skipping
> incompatible
> /Users/fx/devel/mingw-w64/cross/x86_64-w64-mingw32/lib/libmingwthrd.a when
> searching for -lmingwthrd
>
> The reason behind that is simply that, when building 32-bit libgcc, the wrong
> flags are passed to xgcc:
>
>-L$ROOT/x86_64-w64-mingw32/lib -L$ROOT/mingw/lib -isystem
> $ROOT/x86_64-w64-mingw32/include -isystem $ROOT/mingw/include
> -B$ROOT/x86_64-w64-mingw32/bin/ -B$ROOT/x86_64-w64-mingw32/lib/ -isystem
> $ROOT/x86_64-w64-mingw32/include -isystem $ROOT/x86_64-w64-mingw32/sys-include
>
> These flags all refer to lib instead of lib32.
>
> I can reproduce the problem with both GCC trunk and GCC 6.3.0. Have I missed
> a configuration flag? Otherwise it seems like a bug in the multilib setup,
> because the target configuration file seems correct:
>
> $ cat gcc/config/i386/t-mingw-w64
> MULTILIB_OPTIONS = m64/m32
> MULTILIB_DIRNAMES = 64 32
> MULTILIB_OSDIRNAMES = ../lib ../lib32
>
>
> Any help in debugging this would be appreciated.
>
> Thanks,
> FX
>
What is the status of macOS PowerPC support?
Hi, I am trying to determine what is the status of the powerpc-apple-darwin target for GCC. The last released version of GCC for which a successful build is reported is 4.9.1 (https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg02093.html), and the last gcc-testresults post I could find was in April 2015 (https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01438.html), for the GCC 5 branch. Do GCC 5, GCC 6 and current trunk support powerpc-apple-darwin? The target code is still there, apparently, and the compiler is not on the “obsolete” list. FX
Re: [patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran
Hi Jerry, A few questions: - why mpich? doesn’t opencoarrays support any MPI implementation? - I am a bit surprised by the complexity of the script… couldn’t we provide a Makefile for opencoarrays, to be compatible with our other build requirements? - do we want to work towards seamless implementation of coarrays into gfortran, or coexistence as a separate package (as is currently the case, for example in Mac Homebrew, where it ships as a separate — but compatible — package)? FX
Re: [patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran
Hi Damian, > It would be difficult or impossible for several OpenCoarrays > developers to contribute without OpenCoarrays remaining separate for > several reasons. No, I understand that. What I meant is: do want to provide seamless integration, so that libgfortran builds would automatically detect if an MPI environment is available, and if so build opencoarrays. The only “hard" dependency is whether we have an mpicc, it seems. However, the big issue is that of build-time requirements, which are not compatible with GCC: opencoarrays depends on cmake and bash, so it is in that respect very different from GMP and MPFR, which do not have stricter requirement than GCC itself. I’ve started today to look at the OpenCoarrays source, and I admit I am quite lost… it seems that the build machinery is much larger than the source itself. Technically, it seems doable to OpenCoarrays a “Makefile.gfortran” that would build OpenCoarrays, without the need for bash or cmake. Does this sound right to you? >> Ultimately, since multi images is part of the Fortran language, it should >> just >> happen transparently with the gcc regular build process. > > We’re all in agreement here so hopefully Jerry’s submission will be > approved. Currently, I don’t think we can integrate it in this form, due to build requirements. Maybe the threshold is lower for integrating it into GCC’s contrib scripts directory? FX
Re: [patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran
> I have not encountered a system without cmake yet, I did test the script with > my > cmake missing to confirm that it does actually build cmake if needed before it > proceeds, and then uses make. We have bash scripts already in libgfortran that > get invoked either during configuration or by build. 1. We only have portable shell scripts currently in GCC trunk. Introducing a bash dependency would be new. 2. This would introduce a dependency on cmake, just like gmp and mpfr. Yes, it can automatically download it, but only if you’re not offline. Moreover, some package managers (e.g. homebrew) don’t allow installation scripts to download stuff from the network, for safety reasons. So it does count as a dependency. Given that OpenCoarrays is just a few source files, I don’t see why it couldn’t be compiled with a simpler process. I’m not asking the project to switch over, but we should be able to provide, under certain assumptions, a configure / make process that works. > Also keep in mind we have target systems that do not use the common software > packaging methods and must rely on the gcc/gfortran build method, so this > script > is a way to "integrate" with minimal effect on gfortran source. It is in its > own subdirectory, isolated from everything else and for gcc7 only manually > invoked. This gets it out there, gets exposure, and gets it further tested. If we ship it, we support it, and I don’t think we should introduce another whole build system into GCC. There already are scripts that exist, which Damian regularly advertise on comp.lang.fortran, which do this job. If opencoarrays can’t be made to fit within our current build system, I’d rather have that (integrate gcc build into opencoarrays) than the reverse (integrate opencoarrays build into gcc). In any case, thanks for exploring it. I really think we should find a way to integrated tightly the coarray features into gfortran, but we need to find the right technical solution. FX
Re: [patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran
> But ultimately there is a tight coupling between OpenCoarrays and GFortran; > it would be good to integrate OpenCoarrays into the GFortran testing > process... so that you can see when GFortran devs do something that triggers > a bug in OpenCoarrays, or that has a side effect of breaking OpenCoarrays > (GFortran bug, or coordination required to update interface etc. on > OpenCoarrays side.) I read through the OpenCoarrays source code, and I was surprise how tightly integrated it is with gfortran/libgfortran assumptions. Given that, how can it work with other compilers? > (*ducks while someone throws something at me for saying CMake is better than > auto tools*) > Any build system integrated with GCC should just be invoking CMake directly… I have absolutely no religion on the issue of cmake vs. autotools, I am just saying that GCC is a super-complex piece of code, which runs on tons of different platforms, and so is very conservative about its requirements. FX
Re: [patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran
Hi Damian, > If you're able to join our weekly OpenCoarrays teleconference tomorrow at 10 > AM Pacific time, please let me know your gmail address so that I can add you > to the call on Hangouts. I really would like to resolve these issues more > efficiently than is possible by email. I'm reasonably certain we can either > reach a resolution or decide this won't work in the span of a 1-hour > teleconference rather than stretching the discussion out over several days by > email. I won’t be able to attend, sorry. I feel we’ve reached the point where opinion of other maintainers would be good to hear. FX
Re: [patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran
> As a fallback, I'd suggest a script that checks for package management, uses > it if present, let's the user specify the package manager if known, and exit > with an error condition if none of these conditions are satisfied. It still > presents unnecessary roadblocks that our scripts solve, e.g., some macOS > users neither have nor want to install package management, many package > managers require sudo privileges, there are many different package management > systems to check for, etc. Our scripts are long because we attempt to lower > the barrier of entry to rock bottom. I understand that. GCC’s goal is quite different: it wants to build on a majority of systems, with few — but well-defined — prerequisites, and in a large number of configurations. That includes native systems, distributed compilation, cross-compilers, canadian crosses, etc. (I omit here the bare-bones and embedded systems as those are likely not targets for OpenCoarrays anyway). It’s great for OpenCoarrays to work “out of the box” on any compiler, autodetect its environnement and everything. I just don’t think it currently fits within GCC’s view of the build system. Also, there is the question of bootstrap: GCC can be bootstrapped on a compiler with a non-GCC compiler, but on such system libgfortran we be built as part of the compiler, while a GCC-adapted MPI library may not yet be available (because the compiler has not yet finished building). FX
Re: New prerequisites to support multi image COARRAY in gfortran
> We choose mpich as a default only because it is very stable. Why are why tying ourselves to one MPI implementation? FX
Web page for binaries
Hi, I’m suggesting we apply the following patch to provide links to macOS package managers, where users can download binaries for GCC on macOS. I have included the two major ones, Homebrew and MacPorts. FX macos.diff Description: Binary data
JIT status
Hi David, hi GCC team, What is the current status of JIT in GCC ? It does not currently work on macOS, with a bug in libgccjit.so linkage. We can work around it with a hack of the Make-lang.in (https://raw.githubusercontent.com/Homebrew/formula-patches/e9e0ee09389a54cc4c8fe1c24ebca3cd765ed0ba/gcc/6.1.0-jit.patch) but it seems to me that a proper solution would be use --version-script only conditional, with a check for symver support, and check whether -soname or -install_name should be passed to create the shared library. Homebrew (https://brew.sh) has been patching JIT support since GCC 6, and I’m considering simply dropping support for it when GCC 8 comes. Is there a chance I can this issue being fixed, or should I simply drop it? Cheers, FX
Re: JIT status
> I'd like to fix it, but I don't have access to a MacOS box. > > Is there a machine I can SSH into in the GCC compile farm, or similar > public resource? I’m happy to help, I can test stuff, etc. I can also provide (for limited amount of time) remote access to my own box, if you want. Let me know off-list what you need. FX
Re: Broken bootstrap on Cygwin
> GCC maintainers is this OK for your policy? Personally, I don't think it's a good thing to do: a secondary platform that only supports the latest released version of said platform does not indicate high stability. But it's up to the cygwin maintainers to decide, of course. However, the fact should be documented on the installation notes (http://gcc.gnu.org/install/specific.html#x-x-cygwin) and probably on the release notes as well, with something like "The GCC 4.6 series requires Cygwin x.y.z or later". FX
Re: __builtin_clzll and uintmax_t
Salut Marc !
> We have a variable of type uintmax_t and want to count the leading zeros. Can
> we just call __builtin_clzll on it?
Yes.
> In particular, can uintmax_t be larger than unsigned long long in gcc?
uintmax_t is the largest of the standard unsigned C types, so it cannot be
larger than unsigned long long. On x86_64, for example:
> #include
> #include
>
> int main (void)
> {
> printf ("%lu ", sizeof (uintmax_t));
> printf ("%lu ", sizeof (int));
> printf ("%lu ", sizeof (long int));
> printf ("%lu ", sizeof (long long int));
> printf ("%lu\n", sizeof (__int128));
> }
gives : 8 4 8 8 16
> Is __builtin_clzll available on all platforms?
Yes, we emit calls to this built-in unconditionally in the Fortran front-end,
and it has caused no trouble.
FX
Re: GCC 4.6.0 Released
> this is a known issue and strictly cygwin related. Please update your > cygwin environment to newest version, or disable decimal-floating > point by option. Well, maybe this is known, but it is not noted on the GCC 4.6.0 release notes, nor on the target-specific installation information page at http://gcc.gnu.org/install/specific.html#x-x-cygwin Possibly one of the target maintainers might want to update that? FX
Re: question about GCC Quad-Precision Math Library
Dear Samuel,
(I copy this email to the gcc@gcc.gnu.org list, as this is the home for
discussions of this library.)
You can't use the libquadmath library with an ANSI-C compiler. You need a
compiler that supports the __float128 type and operations on it (such as
multiplications, as you mention).
Regards,
FX
> Francois,
>
> I have a question about the GCC Quad-Precision Math Library.
>
> Can I use this library with a regular ANSI-C compiler?
>
> I ask this question because I see in the code (power function)
> that you multiply two 128-bit quad floats using the '*', and I
> could not see how this would work.
>
> -
> __float128 powq (__float128 x, __float128 y)
> {
> __float128 z, ax, z_h, z_l, p_h, p_l;
> __float128 y1, t1, t2, r, s, t, u, v, w;
> __float128 s2, s_h, s_l, t_h, t_l;
> int32_t i, j, k, yisint, n;
> uint32_t ix, iy;
> int32_t hx, hy;
> ieee854_float128 o, p, q;
> ...
> return s * z;// line 439
> -
>
> Regards,
> Samuel Stewart
> Scotch Plains, NJ
libstdc++ breaks bootstrap (at least on x86_64-darwin11, maybe more)
I've filed PR 51026 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51026). In the meantime, how do I build "the old way", with just a C compiler? I tried to configure with "--enable-languages=c,fortran --disable-build-with-cxx", but the configure script still says: > The following languages will be built: c,c++,fortran Thanks! FX
Re: transactional-memory branch has been merged into trunk
The merge breaks bootstrap in 3 different ways (at least) on x86_64-darwin11: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51031 FX
[testsuite] Executing testcases under wine
Hi all,
I'm trying to run the GCC testsuite for the mingw target, on a i686-
darwin host. The cross compiler builds fine, and I have wine
installed, so I'd like testsuite executables, once compiled, to simply
run under wine (that means, instead of running "PR10431.exe", running
"wine PR10431.exe"). I've found a crude way to do this by patching my
system dejagnu config file (/usr/share/dejagnu/config/unix.exp):
--- unix.exp.old2009-07-30 12:08:04.0 +0200
+++ unix.exp2009-07-30 11:57:37.0 +0200
@@ -73,7 +73,7 @@ proc unix_load { dest prog args } {
setenv SHLIB_PATH "$ld_library_path:$orig_ld_library_path"
verbose -log "Setting LD_LIBRARY_PATH to $ld_library_path:
$orig_ld_library_path" 2
- set id [remote_spawn $dest "$command" "readonly"]
+ set id [remote_spawn $dest "wine $command" "readonly"]
if { $id < 0 } {
set output "remote_spawn failed"
set status -1
I've tried to create a new board in the gcc/testsuite/lib directory
(wine.exp) by copying unix.exp and modifying it, but I've not been
able to get any luck at all. I hope maybe a dejagnu expert could point
me in the right direction! (is it possible, what do I put in the
wine.exp, where do I put this file and how to I get it to be called?)
Many thanks in advance,
FX
VTA merge broke i386-apple-darwin bootstrap (a primary platform)
Filed as PR 41245. FX
Re: Large slowdown with gfortran vs f77 (x7)
Hi Jeremy, -- it's unarguably a glibc issue: if exp() is fast and expf() is slow, why doesn't glibc implement expf() by calling exp()? (yes, there can be other issues like rounding or so, but they can also be dealt with separately) -- a similar bug was already reported a year and a half ago, and no activity was recorded on that front (http://sources.redhat.com/bugzilla/show_bug.cgi?id=5997 ); overall, the math lib from glibc can be buggy and slow (and its development is not exactly proceeding at a steady pace) but political reasons prevent GCC to include its own math lib -- there is a GNU Fortran mailing-list where Fortran-related issues are welcome Regards, FX
Need an assembler consult!
Hi all,
I have picked up what seems to be a simple patch from PR36399, but I don't know
enough assembler to tell whether it's fixing it completely or not.
The following function:
#include
__m128i r(__m128 d1, __m128 d2, __m128 d3, __m128i r, int t, __m128i s) {return
r+s;}
is compiled by Apple's GCC into:
pushl %ebp
movl%esp, %ebp
subl$72, %esp
movaps %xmm0, -24(%ebp)
movaps %xmm1, -40(%ebp)
movaps %xmm2, -56(%ebp)
movdqa %xmm3, -72(%ebp) #
movdqa 24(%ebp), %xmm0 #
paddq -72(%ebp), %xmm0 #
leave
ret
Instead of lines marked with #, FSF's GCC gives:
movdqa 40(%ebp), %xmm1
movdqa 8(%ebp), %xmm0
paddq %xmm1, %xmm0
By fixing SSE_REGPARM_MAX in config/i386/i386.h (following Apple's compiler
value), I get GCC now generates:
movdqa %xmm3, -72(%ebp)
movdqa 24(%ebp), %xmm0
movdqa -72(%ebp), %xmm1
paddq %xmm1, %xmm0
The first two lines are identical to Apple, but the last two don't. They seem
OK to me, but I don't know enough assembler to be really sure. Could someone
confirm the two are equivalent?
Thanks,
FX
PS: the patch is:
> Index: gcc/config/i386/i386.h
> ===
> --- gcc/config/i386/i386.h(revision 155505)
> +++ gcc/config/i386/i386.h(working copy)
> @@ -1810,7 +1810,7 @@
> #define X86_64_SSE_REGPARM_MAX 8
> #define X86_64_MS_SSE_REGPARM_MAX 4
>
> -#define X86_32_SSE_REGPARM_MAX (TARGET_SSE ? 3 : 0)
> +#define X86_32_SSE_REGPARM_MAX (TARGET_SSE ? (TARGET_MACHO ? 4 : 3) : 0)
>
> #define SSE_REGPARM_MAX
> \
>(TARGET_64BIT ? (TARGET_64BIT_MS_ABI ? X86_64_MS_SSE_REGPARM_MAX \
Big regression showing up on darwin
I know something is going on with section names, so I thought I'd mention that there is a big regression on darwin (most "-flto -fwhopr -O2" tests fail) at rev. 155544. An example is: FAIL: gcc.c-torture/compile/20010313-1.c -O2 -fwhopr (test for excess errors) Excess errors: /var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc8BGFLD.s:1:Expected comma after segment-name /var/folders/UV/UVACeRu8EU8CKLhygL+1rk+++TM/-Tmp-//cc8BGFLD.s:1:Rest of line ignored. 1st junk character valued 32 ( ). The assembler rejects lines such as the following: .section .gnu.lto_.jmpfuncs Hope this can be fixed quickly, as it seriously hamper other regtesting. FX
Linking libgfortran with libiberty
Hi all, This mail is a request for some help from our local build machinery experts... We have a patch under testing for libgfortran to add runtime memleaks checking, and it uses libiberty's hash tables. So, we now link gfortran programs with libiberty. We also need to link in libiberty while building libgfortran (which I discovered because otherwise we get failures on darwin), by the following patch: Index: Makefile.am === --- Makefile.am (revision 145225) +++ Makefile.am (working copy) @@ -17,7 +17,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la libgfortran_la_LINK = $(LINK) -libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/ libtool-version` $(LTLDFLAGS) -lm $(extra_ldflags_libgfortran) $ (version_arg) +libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/ libtool-version` $(LTLDFLAGS) -L../libiberty -liberty -lm $ (extra_ldflags_libgfortran) $(version_arg) myexeclib_LTLIBRARIES = libgfortranbegin.la myexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$ (MULTISUBDIR) i.e. we add "-L../libiberty -liberty" to libgfortran_la_LDFLAGS. My question is the following: is "-L../libiberty" the right way to tell the build machinery where to find the target libiberty, or is there something more clever to do? I see that libjava uses a variable named $ (here), but I couldn't get it working in libgfortran/Makefile.am, so I reverted to the simpler "../libiberty". Thanks for your help, FX PS: the current draft of the complete patch, if you are interested in it, is attached (it was put together by Tobias Burnus) memleak2.diff Description: Binary data PPS, to Dominique: this is the promised fix for Darwin :)
Re: Linking libgfortran with libiberty
If you wish to use particular files from libiberty in a runtime library, you'll need FSF approval to distribute them under GPL + exception I'm interested only in include/hashtab.h and libiberty/hashtab.c, which are both currently under GPL2. How does one ask for FSF approval to distribute them as GPL + exception? We'd like to be able to use them in the GNU Fortran runtime library. Thanks for your explanations, FX
Re: Linking libgfortran with libiberty
+1. If libgfortran includes a custom allocator of any sort (does it?) instead of using malloc/free, it should use valgrind hooks like those we already have in GCC. libgfortran uses malloc/free. Regarding valgrind, it's not supported on all GCC targets, so it's not a valid alternative to our proposal. I can understand that you have objections based on licence issues to make to that patch, but I'm sure the gfortran maintainers are the best people to make the decision of whether this patch is a good thing for the project (and much demanded by the community); they have already made that choice, so we should focus on talking about how to work around the current licence issue. FX
Re: stdint.h type information needed
>> for some reason identifier_global_value() on it returns NULL.
> ... and this is presumably because it should have /already/ been
declared somehow.
I have exactly the same issue on darwin, it segfaults on:
char16_type_node = TREE_TYPE (identifier_global_value
(char16_type_node));
because identifier_global_value (char16_type_node) is NULL. The patch
I use is attached. Joseph, could you help us to proceed further?
Thanks,
FX
diff -pur trunk.unmodified/gcc/config/darwin.h trunk/gcc/config/darwin.h
--- trunk.unmodified/gcc/config/darwin.h 2009-04-03 10:48:59.0
+0530
+++ trunk/gcc/config/darwin.h 2009-04-03 15:23:31.0 +0530
@@ -72,6 +72,38 @@ Boston, MA 02110-1301, USA. */
#undef WCHAR_TYPE_SIZE
#define WCHAR_TYPE_SIZE 32
+#define INT8_TYPE "signed char"
+#define INT16_TYPE "short int"
+#define INT32_TYPE "int"
+#define INT64_TYPE "long long int"
+#define UINT8_TYPE "unsigned char"
+#define UINT16_TYPE "unsigned short int"
+#define UINT32_TYPE "unsigned int"
+#define UINT64_TYPE "unsigned long long int"
+
+#define INT_LEAST8_TYPE "signed char"
+#define INT_LEAST16_TYPE "short int"
+#define INT_LEAST32_TYPE "int"
+#define INT_LEAST64_TYPE "long long int"
+#define UINT_LEAST8_TYPE "unsigned char"
+#define UINT_LEAST16_TYPE "unsigned short int"
+#define UINT_LEAST32_TYPE "unsigned int"
+#define UINT_LEAST64_TYPE "unsigned long long int"
+
+#define INT_FAST8_TYPE "signed char"
+#define INT_FAST16_TYPE "short int"
+#define INT_FAST32_TYPE "int"
+#define INT_FAST64_TYPE "long long int"
+#define UINT_FAST8_TYPE "unsigned char"
+#define UINT_FAST16_TYPE "unsigned short int"
+#define UINT_FAST32_TYPE "unsigned int"
+#define UINT_FAST64_TYPE "unsigned long long int"
+
+#define INTPTR_TYPE "long int"
+#define UINTPTR_TYPE "unsigned long int"
+
+#define SIG_ATOMIC_TYPE "int"
+
/* Default to using the NeXT-style runtime, since that's what is
pre-installed on Darwin systems. */
pur trunk.unmodified/gcc/config.gcc trunk/gcc/config.gcc
--- trunk.unmodified/gcc/config.gcc 2009-04-03 10:49:00.0 +0530
+++ trunk/gcc/config.gcc2009-04-03 11:04:52.0 +0530
@@ -411,6 +411,7 @@ case ${target} in
extra_objs="darwin.o"
extra_gcc_objs="darwin-driver.o"
default_use_cxa_atexit=yes
+ use_gcc_stdint=wrap
case ${enable_threads} in
"" | yes | posix) thread_file='posix' ;;
esac
Re: stdint.h type information needed
LOL, I forgot to attach mine didn't I? It's basically the same, I
copied
and pasted the newlib version and tweaked a couple of the
definitions so they
were identical to Cygwin's stdint.h. I suspect we're simply missing
some
needed definition somewhere, so I won't send mine now you've sent
yours.
Neither adding /usr/include/uchar.h, nor defining char{16,32}_t in
/usr/include/stdint.h fixed this for me.
It's simpler than that actually: the node for "unsigned short int" is
not defined, but that of "short unsigned int" is. So we have to write
in our target macros the following form: "(short|long|long long)
unsigned int". I don't understand why, but it appears to work :)
FX
Re: stdint.h type information needed
Hum, well, only partially solved. I get a failure on c99-stdint-1.c,
which I can reduce to:
$ cat u.c
#include
void
test_ptr (void)
{
__typeof__(INTPTR_MIN) a;
__typeof__((intptr_t)0 + 0) *b = &a;
}
$ ./gcc/xgcc -B./gcc u.c -std=iso9899:1999 -pedantic-errors -S
u.c: In function ‘test_ptr’:
u.c:7: error: initialization from incompatible pointer type
This is because, for 32-bit for example, intptr_t is "long" and
INTPTR_MIN is (-2147483647-1), which is of type "int".
The same thing happens on 64-bit, because INTPTR_MIN is
(-9223372036854775807LL-1), which is of type "long long", while
intptr_t is still "long".
Is this a bug in darwin's headers?
FX
Patch for stdint support on darwin
This is a patch that should add stdint support on darwin. It should work on both i386 and ppc, for Mac OS >= 10.3 (don't think we support 10.2 or earlier, anyway). Because I only have a laptop at hand and poor connectivity for the next 10 days, the following needs doing: -- bootstrap and regtest on ppc-darwin (Dominique, could you help?) -- regtest on i386-darwin -- review and approval (Dale, Mike, Eric or Stan) What I've done so far is: -- bootstrap on i386-apple-darwin9.6.0 -- checked gcc.dg/c99-stdint-*.c on same with both -m32 and -m64 After the patch, the only remaining stdint-related failure is gcc.dg/ c99-stdint-1.c, which is due to issues in the system headers (see comments #15 and #16 in PR448). I don't know fixincludes and can't help there. I still think the current patch is better than nothing for now, while waiting for fixincludes. Thanks to anyone who can help, FX darwin-stdint.diff Description: Binary data
Patch for mingw stdint information
Hi all, Please find attached a patch I built to add stdint-related information to GCC configuration for the mingw target (see http://gcc.gnu.org/ml/gcc/2009-04/msg0.html for more details about why). I built it from looking at the mingw headers, because I have them on my laptop, I'm in a hotel room far from home and I can get to sleep :) I've not done (and will not do in the foreseeable future) any testing, so they'll need to be bootstrapped and regtest on at least the gcc.dg/c99-stdint-*.c tests. If you find failures of c99-stdint-1.c, it means the mingw headers need fixing (I'm particularly worried about int_fast8_t, which is "char" rather than "signed char", and I suspect this could spell trouble). I hope this can help, FX mingw-stdint.diff Description: Binary data
IRIX stdint patch
Hi Rainer, Here's a patch to add knowledge about C99 stdint.h types to the target configuration for IRIX. I did that from the system headers of a IRIX6.5 box, but can't bootstrap or regtest (I have very limited access, can't run anything on it). If you can bootstrap and confirm that tests gcc.dg/c99-stdint-*.c do not fail. For more information about why this is necessary, see http://gcc.gnu.org/ml/gcc/2009-04/msg00000.html . FX irix-stdint.diff Description: Binary data
Re: Object file for Module is too large
Hi Alison,
This issue is not specific to Fortran, but it's specific to Darwin
(you say that "the large object files have been observed on many other
platforms", but could you give a list of such platforms?):
$ cat a.c
int x[999] = { 0 };
$ gcc -c a.c && ls -lh a.o
-rw-r--r-- 1 fx wheel38M May 12 13:43 a.o
$ size a.o
__TEXT __DATA __OBJC others dec hex
0 39960 0 399626259fc
while on x86_64-linux, I get:
$ cat a.c
int x[999] = { 0 };
$ gcc -c a.c && ls -lh a.o
-rw-r--r-- 1 fx fx 959 May 12 13:44 a.o
$ size a.o
textdata bss dec hex filename
0 0 3996399626259fc a.o
The different between the two is between .bss (x86_64-linux) and .data
(darwin). I don't know enough about Mach-O to tell if it's a bug or a
feature :)
FX
Re: Using MPC Library with GCC
Thanks Kaveh for taking care of this. The Fortran front-end will really benefit from the use of MPC. Regarding your options, #1 seems the most reasonable to me; I'm forwarding to the Fortran list to hear to opinion of Fortran maintainers. FX
