How can a front-end know what integer mode corresponds to int_fastN_t?

Hi all, For Fortran 2003 standard conformance, the Fortran front-end has to know at compile-time what integer mode corresponds to some C99 types, like intmax_t, intN_t, int_leastN_t, int_fastN_t. For intN_t and int_leastN_t, I can see how to get them by looking at the width of the differe

Re: regeneration of files

I commited the regenerated libgfortran files on mainline (rev. 118140): 2006-10-29 Francois-Xavier Coudert <[EMAIL PROTECTED]> * configure: Regenerate. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. Maybe you have an old version of libgfortran/config.h.in, becaus

How to grow the Fortran I/O parameter struct and keep ABI compatibility

Hi all, [Cc general gcc list for people with ABI-compatibility experience, and Jakub because he's the one who introduced the scheme currently used by the library] The plans for the libgfortran library is to stabilize things from now on, and keep ABI compatibility. But I have to admit that

Re: How to grow the Fortran I/O parameter struct and keep ABI compatibility

Suggestion: We should make sure we can accommodate F2003 with 4.2 and 4.3 by increasing the possible number of flags as needed. I'm in favour of that, and I already started writing the necessary patch. But it looks like we'll have to bump the so number a last time, for 4.3, and then make th

Re: How to grow the Fortran I/O parameter struct and keep ABI compatibility

What's the problem with just adding a new 'extended private stuff' field to the very end of the struct and allocating one of the remaining flag bits to say if it's present or not? That requires to have a version of the library that can work without it, and it's one more requirement on th

Re: Polyhedron performance regression

Just wanted to note to the list that Tobias spotted a performance regression on Polyhedron ac. http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron- summary.txt-2-0.html Hum, the performance change on ac is significant. Anyway we can get the revision numbers before and after the jump

Re: gfortran year end status report

Thanks a lot Steve for taking time to prepare and write this mail. FX

lib{gomp,decnumber}/autom4te.cache

Is there any reason why libgomp and libdecnumber don't have a svn:ignore property containing autom4te.cache? I noticed the following always showing up in my "svn status" after a maintainer- mode build: ? libdecnumber/autom4te.cache ? libgomp/autom4te.cache Thanks, FX

Re: Performance regression on the 4.3 branch?

Then it's filed as PR 30801. FX

Re: Who should fix platforms broken by extern inline hack?

I'd like to ping these two problems :) i386-unknown-netbsdelf2.0.2 (and possibly newer versions) and i386-pc- mingw32 (latest released version) are still completely broken on mainline, as they have been for more that three months. As it turns out, I do now have access to a NetBSD system, an

Re: symbol names are not created with stdcall syntax: MINGW, (GCC) 4.3.0 20061021

IMO, anybody who uses -mrtd (with or without decorations) is asking for trouble. Unless you are planning to use a gfortran dll in a VisualBasic app, I can see little reason to change from the default "C" calling convention. That precise reason is, as far as I understand, important for some

AC_LIBTOOL_WIN32_DLL for libgfortran

Hi all, I've been trying to use tweak the libgfortran build machinery to get it generate a libgfortran.dll on windows systems, but I have no luck. I tried adding AC_LIBTOOL_WIN32_DLL to configure.ac (just before AM_PROG_LIBTOOL) and -no-undefined to libgfortran_la_LDFLAGS, as is indicated

Re: AC_LIBTOOL_WIN32_DLL for libgfortran

In any case, I think efforts would be better spent helping get a modern libtool into the tree, since the one there now is ancient and I wouldn't be surprised if the mingw/cygwin-specific parts have bitrotted from years of neglect. There is effort to get that done, as you can see in the recen

Re: AC_LIBTOOL_WIN32_DLL for libgfortran

Did you put it in the toplevel configure.in or in libgfortran/configure.ac? I suspect it needs to be in the former, because the latter probably shares the same config.cache and thus it won't be checked a second time when running configure for libgfortran. Tried to put it into the toplevel confi

4.3 bootstrap broken on i386-linux

Hi all, My nightly bootstrap of mainline on i386-linux failed tonight, on revision 123192, with: /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/ decLibrary.c: In function ?isinfd64?: /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/ decLibrary.c:65: error:

Re: Google Summer of Code: Mentor wanted for Fortran project

Now I learned that there are currently no Fortran developers signed up as SoC mentors for GCC. It would be really great if someone with a decent knowledge of gfortran would be willing to be my mentor, so I can work on this project. This really wouldn't take up too much of your time. I just

Bootstrap is broken on i[345]86-linux

Bootstrap has been broken since 2007-03-25 on i[345]86-linux. This is a decimal float issue reported as PR31344, and is due to a decimal float patch, probably the following: 2007-03-23 Michael Meissner <[EMAIL PROTECTED]> H.J. Lu <[EMAIL PROTECTED]> I've asked a few times alre

Call to arms: testsuite failures on various targets

Hi all, I reviewed this afternoon the postings from the gcc-testresults mailing-list for the past month, and we have a couple of gfortran testsuite failures showing up on various targets. Could people with access to said targets (possibly maintainers) please file PRs in bugzilla for each

Re: Call to arms: testsuite failures on various targets

wrt to the Subject of the mail, I'm not sure "Call to arms" means what I thought it meant, after all... I really wanted it to sound like "call for help" or "call for more arms". Sorry if there was any confusion in the tone. FX

Segfault on OpenMP program

Someone reported on bug on a trivial statically-linked Fortran progam with OpenMP and a I/O operation. I can reproduce the segfault, which happens at: (gdb) where #0 0x in ?? () #1 0x0804cdbb in get_external_unit (n=6, do_create=1) at /home/fxcoudert/gfortran_nightbuild/trunk/li

[doc,patch] Fortran compiler on Ultrix and clobbered registers

I noted in the GCC docs (see for example http://gcc.gnu.org/ onlinedocs/gcc/Interoperation.html) that we have the following text in the section "Known Causes of Trouble with GCC": On Ultrix, the Fortran compiler expects registers 2 through 5 to be saved by function calls. However, the C comp

Re: Processor-specific code

You'll find that globally changing the rounding mode will screw up libm functions. Which is pretty much going to make this useless. OK. I didn't know that, and it's going to be annoying. So, the GNU libm doesn't enable us to call mathematical function with non-default rounding mode? IIUC, this i

Re: Regressions

Jerry DeLisle wrote: There appears to be numerous regression failures this evening. I suppose these are back end related. On i686-freebsd, i386-linux and x86_64-linux, I see failures for gfortran.dg/pr19657.f and gfortran.dg/select_2.f90 at -O3, gfortran.dg/vect/vect-2.f90 at -O. And gfortra

Re: Add clog10 to builtins.def, round 2

The fortran front-end needs to recognize clog10, clog10f and clog10l a proper built-ins. Attached patch tries to add them to clog10, under a new category: DEF_EXT_C99RES_BUILTIN (as suggested by jsm28). Can someone review this? Is it OK? Just realized I forgot the ChangeLog entry to go with it.

Re: Someone broke complex arithmetic

There are regressions involving complex aritmetic in the testsuite too: > FAIL: gfortran.dg/real_const_1.f (test for excess errors) > WARNING: gfortran.dg/real_const_1.f compilation failed to produce > executable The regression appeared between 20050716 and 20050717 on i686-linux and i386-freeb

Re: Add clog10 to builtins.def, round 2

OK to commit? Ping. This problem is really blocking a very nice gfortran feature (support for large real kinds). Since it is very short, could someone review it? FX 2005-07-19 Francois-Xavier Coudert <[EMAIL PROTECTED]> * builtins.def: Add DEF_EXT_C99RES_BUILTIN to define builtins

PING [4.1 regression, patch] build i686-pc-mingw32

PING. Could one of the mingw/cygwin maintainers review this patch? Or can someone else do it? http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00086.html

Re: PING [4.1 regression, patch] build i686-pc-mingw32

I'd prefer that Danny review this but neither of us has the right to approve this patch. Well, then, who has the right to approve such a patch? However, it seems like you're adding extra stuff to the Makefile where it is already trying to do the right thing if $(LN) fails. Couldn't LN just be

[patch] Fix i386-mingw32 build failure

PING ** 2 Attached patch fixes PR bootstrap/22259 (right now, a simple ./configure && make build fails on i386-mingw32). It creates a special case for in-tree as, collect-ld and nm scripts: since mingw32 cannot spawn shell scripts, it copies $(ORIGINAL_AS_FOR_TARGET), $(ORIGINAL_LD_FOR_TARGET)

Re: [patch] Fix i386-mingw32 build failure

I have only tested it on Linux, can you give it a try? Ok if FX's testing succeeds? Testing succeeded on i686-mingw32. Configures and builds fine. Can someone review this patch? FX

Re: [gfortran] add ISATTY and TTYNAM intrinsics

One other question. Do you know much c++? I had to make one change to some buggy c++ code to allow gcc 4.0 and main branch to compile xplor-nih... I'm sorry but i don't know anything more about c++ than its name. About your problem, i'd guess that you could try to create a reduced preproce

Re: Old machine cluster for GCC compile/testing

That's a very nice offer. I think the idea of an automated patch boostrap & regtester is of much interest, and i can volunteer to set up the systems (if need be, i can move to the machines since i live in Paris). Furthermore, it would be interesting if we could install, on some of those, a rat

[gfortran] Change language name from "f95" to "fortran"

Attached patch changes the name of the language in --enable-languages from "f95" to "fortran", and in a few other places. There are still lots of places which are refered to as f95 (such as f951 ;-), but they are all internal uses. I'm not very familiar with the mechanism of language names, so

Re: gcc 4.1 FAIL: gfortran.dg/large_integer_kind_1.f90 on sparc/sparc64 linux...

This testcase should only be run if there is a 128-bit integer kind available. This looks like it's not the case here, but then why is check_effective_target_fortran_large_int returning true? I can't really understand that. What are you tcl/expect/dejagnu versions?

Re: gcc 4.1 FAIL: gfortran.dg/large_integer_kind_1.f90 on sparc/sparc64 linux...

is there anything I can provide you with to have a better guess? I'm definately willing to debug if you direct me... Unfortunately, I think we need a dejagnu expert here, I have no idea how to debug these things... If nobody can provide help in the next few days, please file a bug-report. Th

Re: GCC 4.1 Status Report (2005-10-02)

I have two separate questions to ask: 1. what is the status on 21766 (a 4.1 regression)? bootstrap has been broken on Windows (cygwin and mingw) for more that 4 months now, is it expected to be fixed before branch? 2. what's the status for fortran wrt the quality push? can we still check

Re: RFC: future gfortran development and subversion

A regression is a bug that was not in release N - M and was discovered in release N. You are then free to fix N - M + 1 to N. Like you have a testcase that crashes gfortran on 4.1.0, but did not on 4.0.2. But then, you'll explain people that they won't have a decent fortran compiler in distro

Re: Vectorizing HIRLAM NN.

Steven Bosscher wrote: Als je wil, kan ik wel een handje helpen door e.e.a. te analyzeren voordat je de problemen voorlegt aan de mailing-list. Erg interessant, als dit werkt. Gaat het KNMI ook daadwerkelijk gfortran gebruiken of zijn we nog lang niet ver genoeg daarvoor? For [EMAIL PROTECTED

[libgfortran] Patch to handle statically linked libgfortran

:ADDPATCH testsuite: Attached patch fixes a bug (PR libfortran/22298) where the libgfortran constructor function wasn't linked in when libgfortran was statically linked. The patch itself is straightforward and well commented, and it could go under the "obvious rule". I added a test for the t

[gfortran] gfortran options and cc1 warnings

This is a patch proposal about PR fortran/18452. In short, to preprocess fortran source files, gfortran calls cc1 with its own options, which gives warnings like: $ gfortran -fdollar-ok a.F90 cc1: warning: command line option "-fdollar-ok" is valid for F95 but not for C A few (two exactly) o

Re: [gfortran] gfortran options and cc1 warnings

New version of the patch attached, to answer Joseph's remark. Original questions still apply, including: What should "gfortran -fdollar-ok a.f b.c" do, if -fdollar-ok if a fortran-only option? FX

Re: [gfortran] gfortran options and cc1 warnings

New version of the patch attached (this time), to answer Joseph's remark. Original questions still apply, including: What should "gfortran -fdollar-ok a.f b.c" do, if -fdollar-ok if a fortran-only option? FX 2005-10-31 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/18452

Re: [gfortran] gfortran options and cc1 warnings

What should "gfortran -fdollar-ok a.f b.c" do, if -fdollar-ok if a fortran-only option? It shouldn't pass -fdollar-ok to cc1, IMHO. I'm not sure about how other languages handle that. Trying to mix java and C gives: $ gcj -c Example.java a.c -Wredundant-modifiers cc1: warning: command line

[gfortran] fortran preprocessing, round 2

This is an updated version of my patch taking care of warnings when cc1 is called from gfortran to preprocess fortran source. I used a different (and in my view, cleaner) approach: Fortran options are not marked as C, but when preprocessing fortran source, cc1 is given a -lang-fortran flag, whi

Re: [libgfortran] Patch to handle statically linked libgfortran

How does the test in check_effective_target_static_libgfortran check for use of static libgfortran? Shouldn't it pass -static or something? If it's really doing it already by a means that is not apprarent, please add a comment. That proc has a comment that was copied from another proc, please f

toplevel Makefile.tpl hacking

I've been working on PR libfortran/21547: f951 is linked with libgmp, but when this library is shared and located in a non-standard path, building with ./configure --with-gmp=/foo/bar fails because the correct $(RPATH_ENVVAR) is not set when building the libgfortran. The conclusions I draw afte

GMP on IA64-HPUX

Hi all, Below is the answer I got from the developer of GMP when I asked about support for ia64-hpux. So, in short, my questions are: is gmp-4.1.4 supposed to work on ia64-hpux? No, it is not. It might be possible to get either the LP64 or the ILP32 ABI to work, but even that requires t

Re: gfc_build_addr_expr vs. build_fold_addr_expr{,_with_type}

The only downside I see with this type of patch is that backporting fixes from trunk to 4.1 will be more difficult. With only a small group of active gfortran hackers, this may place 4.1 into position of low maintenance. Unless I am mistaken, this patch doesn't touch anything outside the fort

long double on ppc-darwin

I'm trying to understand the gfortran failure large_real_kind_2.F90 on ppc-darwin7.9, which can be reduced to: $ cat large_real_kind_2.F90 real(kind=16) :: x real(8) :: y x = 1 y = x x = cos (x) y = cos (y) print *, x, y, y-x end $ ./usr/local/gfortran/bin/gfortran -g large_rea

Re: [libgomp] patch for -pthread on Tru64

Moreover, removing the first test makes libgomp build on targets (as Tru64) where the -pthread option is required to include pthread.h. Commited after approval by Alexandre Oliva on IRC. The exact patch commited is attached. FX libgomp.diff Description: Binary data

Re: Segmentation fault in openmp simple routine from libgomp testsuite.

Should I file a bug ? I think it might be better to wait for the opinion of the gomp maintainers, as I'm fairly new to that stuff and could have missed something important. Jakuk, Diego? Is this a bug or a feature? :) Hum... for trunk on i686-linux, I do see the following. Dynamic linkin

Re: Segmentation fault in openmp simple routine from libgomp testsuite.

The only sure-fire fix I can think of is to actually build two static versions of libgfortran -- one threaded and one not threaded. I'm not sure this is worth the effort, really. I'd be more inclined to put a couple of checks in such that the static libgfortran only runs non-threaded, and force p

mingw32 subtle build failure

Hi all, hi mingw32 maintainers, I'm experiencing a strange bug building mainline as a native compiler on i386-pc-mingw32 (with MSYS). It builds fine with the following configure line: ../gcc/configure --prefix=/mingw --with-gmp=/home/coudert/local -- disable-nls --with-ld=/mingw/bin/ld -

Re: mingw32 subtle build failure

And I forgot to ask: who the heck is supposed to set USE_MINGW_MSYS? (grep is soo sloow on my win32 machine) FX

Re: mingw32 subtle build failure

xgcc.exe: CreateProcess: No such file or directory^M This looks to me like a side effect of some file somewhere being generated with DOS line endings. Sorry I didn't remove that ^M when posting. It's purely an effect of the way I copied my config.log file over the network before posting it

TLS on windows (was: Re: Gfortran on Windows (mingw32) with OpenMP)

[First, a warning: I'm neither an expert in TLS, nor in Windows nor in GCC guts can we have chance to solve the problem of threadprivate by adding the TLS support to mingw32? The support for TLS (Thread Local Storage) would probably come from the compiler itself. Windows has TLS (see for e

Re: Recent VCG changes break gfortran's -std=f95 option

Something is marking random_seed as noreturn. As far as I understand, symbols are marked as noreturn by use of TREE_THIS_VOLATILE, which is done on a few selected trees and is also done whenever a symbol has the noreturn attribute. This noreturn attribute can be set to 1 by make_noreturn,

Re: Recent VCG changes break gfortran's -std=f95 option

My first patch didn't even compile :( Here's a new one. Something is marking random_seed as noreturn. As far as I understand, symbols are marked as noreturn by use of TREE_THIS_VOLATILE, which is done on a few selected trees and is also done whenever a symbol has the noreturn attribute. T

Fwd: Lots of gfortrans testsuite failuers on sparc64-linux: undefined reference to `_gfortran_reshape_r8

[Transfering this to the fortran list] Hi Christian, I did the commit that introduced these new symbols _gfortran_{reshape,transpose}_r{4,8}. They come from ${srcdir}/libgfortran/generated/{reshape,transpose}_r{4,8}.c and this file should be present indeed at revision 114896: $ svn info libg

Re: Lots of gfortrans testsuite failuers on sparc64-linux: undefined reference to `_gfortran_reshape_r8

well, I didn't do a full bootstrap, I did a "bubblestrap" ... maybe that was the issue then. before running the next bubblestrap, what files do you recommend me to remove so that they get stage wise properly rebuilt? Hum... I'm not sure, but I think the safe steps here are: - check the origina

Re: ICE in complex division

div_comp_red_2.f90: In function 'MAIN__': div_comp_red_2.f90:1: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. I reported this bug as PR 28151. It's not target-specific (it happens

GCC dejagnu testsuite: how to check for non-zero exit code?

I'd like to include cases in the gfortran testsuite to check that we correctly issue a run-time error, and exit with non-zero code. I have the following example: $ cat runtime_error.f90 ! { dg-do run } ! { dg-options "-fbounds-check" } integer :: x(5), y(5) x = y((/0,2,3,4,6/)) end $ gfor

Re: Darwin -m64 results

The bug hits about 38 other test in gfortran. These include... FAIL: gfortran.dg/actual_array_constructor_1.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/assign.f90 -O3 -g (test for excess errors) [...SNIP...] Just in case, you can detect any sort of pattern from that set of tests

Re: Problem with libiberty's hash tables

Sure it's faster this way, but what's wrong with valgrind? ;- valgrind (and mtrace) are OS-specific. Also, tracking memory allocations has other benefits, like allowing to give memory statistics (what are the largest allocations, how much is used for compiler-generated temporaries, etc.).

bootstrap broken on mingw (was: Re: AVR port broken on 4.3 20080215 snapshot)

Hi all, I also see this failure on a native build for i386-pc-mingw32, so this is probably a mingw issue. Since i686-pc-mingw32 is a seconday platform, this makes it a release blocker (I've marked it as such in bugzilla, and gave it P1 status; I hope that was the right thing to do). The e

Re: bootstrap broken on mingw (was: Re: AVR port broken on 4.3 20080215 snapshot)

Actually there seems to be a recent change "backward" to that logic: 2008-02-13 Ralf Wildenhues <[EMAIL PROTECTED]> PR other/35148 * Makefile.in (gcc-vers.texi): Use abs_srcdir for the value of srcdir. Doesn't look too good for mingw. and we have PR35218 which seems

Re: bootstrap broken on mingw

gcc/ChangeLog: 2008-02-17 Ralf Wildenhues <[EMAIL PROTECTED]> PR bootstrap/35218 * Makefile.in (build_file_translate): New. * config.build (build_file_translate): Set to `CMD //c' on MinGW. * configure.ac (build_file_translate): Substitute it. * configure

Re: bootstrap broken on mingw

One question I have, Eric and FX: do you both have self-built texinfo on MinGW? Yes, because the one provided with MSYS is from texinfo 4.3, which GCC finds too old. Apparently, MSYS-1.0.11 will come with texinfo 4.11, but it's still labeled "technology preview" for now. Because the spe

Re: RFC: GCC 4.4 criteria - add Fortran as primary language?

[adding fortran list to CC] According to the GCC 4.4 Release Criteria, http://gcc.gnu.org/gcc-4.4/criteria.html, only C and C++ are primary languages. And thus only C and C++ regressions can be release critical. I propose to add Fortran to these languages. My first thought is does gfortran

[patch,target] Fix ppc-darwin issue with long double intrinsics (PR25477)

Thanks to Andrew's code, Mike's and Geoff's comments in the PR, help from Uros, Paolo and Jack, and Dominique's machine for testing, here is a patch for fixing this PR. It has three independent parts, joined together because I regtested them together: 1. the target part, in gcc/config/dar

Re: [patch,target] Fix ppc-darwin issue with long double intrinsics (PR25477)

nanl strtold are missing. In addition, there are some lessor functions like err, errc, errx, strtold_l, swprintf, vfwscanf missing. I assume this is due to no builtins for them or Fortran not using them. If Ada or other non-C languages might, might make sense to add them too. I've

Re: Some help with fold_convert() on RECORD_TYPEs

Works for me. Ok if that passes bootstrap / regtest and with a proper changelog entry. Committed as rev. 132780 with the following ChangeLog, thanks! 2008-02-29 Francois-Xavier Coudert <[EMAIL PROTECTED]> * fold-const.c (fold_convertible_p): Correct the logic to follow th

Re: [PATCH][4.3] Deprecate -ftrapv

C: integer overflow undefined, checking desirable at least for debugging purposes. I think latest Fortran is same as C, can someone confirm? Yes, it is. Overflow undefined and no checking required; I think very few Fortran users actually use (or would use) checking on signed overflow. FX

Re: Interoperability of Fortran array and C vector?

But the remaining question is: can we support type introperability from Fortran array to C vector? I think this is more a middle-end issue that a Fortran issue, so I'm following there: can the middle-end VIEW_CONVERT_EXPR between and ARRAY_REF of, say, INTEGER_TYPE (which is what the Fortran

Re: [PATCH][4.3] Deprecate -ftrapv

In Fortran, integers are used to index arrays. So if you want integer overflow checking, use -fbounds-check :-) I know there is a smiley here, but it seems to me that range checking is quite different from overflow checking. I think what Toon was alluding to is that "real" Fortran programmer

RFC: adding knowledge of the int_fastN_t types to the compiler

Hi all, The Fortran 2003 standard requires that Fortran compilers be able to know, at compile-time, what size the various int_fastN_t types have on the target (for N = 8, 16, 32 and 64). I've discussed that issue before on this list, and was told it's a known issue, tracked as PR 448. For

Re: RFC: adding knowledge of the int_fastN_t types to the compiler

I suggest runtime-variable values depending on a target-independent macro such as LONG_TYPE_SIZE. Also remember the various GNU/Linux targets that do not use config/linux.h (alpha, rs6000, sparc). Thanks for both hints, I'll update the patch. Note that the size is not enough for implementin

Re: RFC: adding knowledge of the int_fastN_t types to the compiler

it's just targets that might have them but haven't had the relevant information recorded in GCC that I think should not have the types defined by default in GCC. (How this relates to Fortran is up to the Fortran maintainers.) Fortran requires that a negative value be returned if the "int

Re: Regression with ltrans-7.f90

Hi Steve, I don't think you should send mail directly to gcc-bugs ("gcc-bugs is a relatively high volume list with mails from our Bugzilla bug- tracking system"). I think, apart from Andrew, noone's subscribed to it :) FAIL: gfortran.dg/ltrans-7.f90 -O scan-tree-dump-times ltrans "tran

Re: Copyright assignment wiki page

That's true in the US as well, but what happens later on if your employer comes by later on and claims you DID use employer resources? Where would that leave the FSF? Very few employees have deep enough pockets to indemnify the FSF from their employer! Then, I think the FSF has no solution

Re: Copyright assignment wiki page

I'm afraid I have to ask to remove the form from that Wiki. :-( You're welcome to remove it yourself, but please replace them with appropriate, *clear* documentation of the copyright assignment process. The recent past (including my own experience some years ago) has shown that http://gcc.

Re: Copyright assignment wiki page

Moreover, our contribute page says "the GCC maintainer that is taking care of your contributions" and there is no documentation to maintainers, so that part at least is wrong: maintainers don't know what to do. Or else, I just didn't receive the maintainer welcome package including the appr

Mainline doesn't bootstrap on i386-linux

With revision 124738: cc1: warnings being treated as errors /home/fxcoudert/gfortran_nightbuild/trunk/gcc/print-rtl.c: In function ‘print_rtx’: /home/fxcoudert/gfortran_nightbuild/trunk/gcc/print-rtl.c:397: error: format ‘%lx’ expects type ‘long unsigned int’, but argument 3 has type ‘long

bootstrap problem with trunk on i386-mingw32: target multi-do in libiberty

Bootstrapping today's trunk (rev. 125180) on i386-mingw32 (native) leads me to the following error at the end of stage3: make[3]: Leaving directory `/home/coudert/ibin/i386-pc-mingw32/ libiberty/testsuite' make[3]: Entering directory `/home/coudert/ibin/i386-pc-mingw32/ libiberty' make[3]: *

Re: Large number of fortran testsuite failures

The problem is between r125620 and r125628 but is NOT, as I suspected, r125621. Is nobody else seeing it, or is it a Cygwin specific problem? ia64-linux testresults with rev. 12640 appear to be fine (http:// gcc.gnu.org/ml/gcc-testresults/2007-06/msg00572.html). Doh, wait, it appears that

Re: [patch,committed] Make Fortran maintainers "Non-Autopoiesis Maintainers"

Mostly what I want is some discussion about what we expect this to mean as a formal rule, and how strictly we're expecting to interpret it. For values of "we" meaning both the GFortran maintainers, and the wider GCC maintainer community. I agree with your intrepretation of this rule exactl

Help on emitting static constant arrays

Hi all, I'm modifying the Fortran front-end to emit code such as: static int4 options.2[5] = {102, 127, 1, 1, 1}; _gfortran_set_options (5, options.2); where _gfortran_set_options is a library function with prototype "void _gfortran_set_options (int , int [])". This works well (the pseu

Re: Help on emitting static constant arrays

It's probably a beginner mistake, but I never wrote code to emit GIMPLE arrays before, and don't know where to look exactly. I'll continue looking for the reason, but if someone thinks of something trivial I'd be interested in knowing! I am pretty sure you should pass the array as a pointer

Re: Ongoing bootstrap failures on ppc64 since 2007-07-02

Starting 2007-07-02 my daily ppc64 tester has failed bootstrap with a SEGV in libgfortran: libtool: compile: /home/dnovillo/perf/sbox/gcc/local.ppc64/bld/./ gcc/gfortran -B/home/dnovillo/perf/sbox/gcc/local.ppc64/bld/./gcc/ - B/home/dnovillo/perf/sbox/gcc/local.ppc64/inst/powerpc64-unknown-

Bootstrap failure on i386-pc-linux-gnu

My automated nightly build failed to bootstrap this evening on i386- pc-linux-gnu. This is for trunk rev. 127311, and the error is: /home/fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/xgcc -B/home/ fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/ -B/home/fx/ gfortran_nightbuild/irun-20070809

[RFC,wwwdocs] Ditch MetaHTML and use our own Perl preprocessor

Hi, I am in the process of rewriting the Fortran part of our website (http://gcc.gnu.org/), part of which consists of adding the GCC navigation bar. To do so, I had to install localy MetaHTML, our current web preprocessor, and my experiences with it have left me less than impressed [1].

Possible Fortran testsuite failures for default_format_*.f90

Hi, A reworking of Fortran testcases might lead to the following cases failing (or starting to fail): * gfortran.dg/default_format_1.f90 * gfortran.dg/default_format_2.f90 * gfortran.dg/default_format_denormal_1.f90 * gfortran.dg/default_format_denormal_2.f90 This would indicate an i

Re: ARM testsuite failures

gfortran has 7442 unexpected failures. Most of them are due to "test for excess errors". Many are simply because of this: | warning: 'const' attribute directive ignored | warning: 'nothrow' attribute directive ignored which seems to be mentioned in PR21185 (comment #20). Is that problem sti

gcc/config.in was not regenerated

Hi, Building GCC in maintainer mode leads to changes in gcc/config.in : > diff --git a/gcc/config.in b/gcc/config.in > index 4cad077bfbe..25442c59aec 100644 > --- a/gcc/config.in > +++ b/gcc/config.in > @@ -67,6 +67,12 @@ > #endif > +/* Define to larger than one set the n

Hundreds of gcc.dg/guality failures on both 14 and 13.1 branches

Hi, I am finding it very hard to reliably compare test results and regressions with the very large number of gcc.dg/guality test failures that are apparently the new norm on x86_64-linux: more than one hundred on 13.1, and several hundreds on 14. Is there any on-going discussion about this? I

Re: Hundreds of gcc.dg/guality failures on both 14 and 13.1 branches

Hi, > Which is why people should just compare testsuite results from earlier run > on the same configuration to watch for regressions, especially in the > guality testsuite. All this gives the idea of a test framework that is too rigid, or tests that are too fragile. I mean, The accumulation of

Testsuite issue and warning about floating-point conversion

Hello, On the WIP aarch64-darwin port of GCC (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite failures which are due to the following: 1. The testsuite check_effective_target_has_q_floating_suffix check tries to compile the code "float dummy = 1.0q;” to determine if th

Re: Testsuite issue and warning about floating-point conversion

Hi Jakub, I should have pinged you, I see you recently touched that code. FX > Le 18 août 2023 à 21:07, FX Coudert a écrit : > > Hello, > > On the WIP aarch64-darwin port of GCC > (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite > failures

Re: Testsuite issue and warning about floating-point conversion

Hi, > I don't know why 1.0q is _Float128 on aarch64 instead of __float128. That’s weird. I create it in this way: + /* Populate the float128 node if it is not already done so that the FEs + know it is available. */ + if (float128_type_node == NULL_TREE) +{ + float128_type_node =

Re: Testsuite issue and warning about floating-point conversion

Hi, > That seems like a bug in the aarch64-darwin port. > 1.0q should definitely be __float128 rather than _Float128. Is there a simple way to test what type 1.0q is, in C? I tried using _Generic, but it says > a.c:7:52: error: ‘_Generic’ specifies two compatible types > 7 | int i = _Gene

  1   2   >