Re: Complex arithmetic in Fortran

> So, I think we could ignore signed zeros (from the Fortran standard > perspective) > > - for complex arithmetic, always > - for real arithmetic, if none of the IEEE modules is USEd That seems like a very backward-incompatible change to introduce :( I might break a lot of existing codes. FX

Re: LIBGCC14 fails to build on MacOS Sequoia x64

Hi Samuele, The gcc-patches list is for submission and review of patches to GCC. For general help, please use the generic gcc mailing-list (gcc@gcc.gnu.org ), and/or file a bug directly at https://gcc.gnu.org/bugzilla/ The issue you’re referring to, a failure to build l

Re: GCC Quad-Precision Math Library Manual: Errors

Hi Peter, You are right, thanks for reporting these issues in the libquadmath documentation. I am CC’ing the GCC mailing-list. Does the following patch seem right? diff --git a/libquadmath/libquadmath.texi b/libquadmath/libquadmath.texi index dc2a9ff374b..ce4accf6421 100644 --- a/libquadmath/li

Re: Nonbootstrap build with Apple clang broken in gm2

> Ah yes indeed it is systematic. Many thanks for spotting this - git > pushed GNU flex required > https://gcc.gnu.org/pipermail/gcc-cvs/2024-July/406305.html Couldn’t the generated files be committed to the tree, so that flex is not needed (unless one modifies the source). This is what is done

Re: Nonbootstrap build with Apple clang broken in gm2

Another quick m2-related question: I am seeing, in a build of GCC 14.1.0 on Linux, that flex is called when building with the modula-2 front-end. It was not the case in previous builds, and the only difference is that I added m2 to the languages. Is that systematic? If so, the prerequisites page

Nonbootstrap build with Apple clang broken in gm2

Hi, I am unable to perform a nonbootstrap build when gm2 is included, with Apple clang 15 as compiler. The error is due to incorrect inclusion of headers ( and ) which are included after GCC’s system.h has been included, and macros like abort() are redefined or poisoned. I think the correct id

Re: What is the purpose of these two fixincludes?

> Laugh or cry. Wow. But how does any other compiler deal with them? I’ve pushed the change as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=66d6b1861ec57ba29540a5fa7854df3978ba5409 Please let me know if you see any issue in the next tests. FX

Re: What is the purpose of these two fixincludes?

Hi, > I usually just install with install-no-fixedincludes, but really this > should probably be a configure option and default to on. It would be great if we could measure what fixincludes are still needed, on which targets. Could we possibly modify contrib/test_summary to list the fixincluded

What is the purpose of these two fixincludes?

Hi, I am trying to reduce the number of unneeded fixincludes that are used on darwin (because fixincluded headers make it impossible to change SDK once the compiler is built, which is common practice in the macOS world, and quite useful). There are currently two generic (not darwin-specific) f

Re: Updated Sourceware infrastructure plans

> I regenerate auto* files from time to time for libgfortran. Regenerating > them has always been very fragile (using --enable-maintainer-mode), > and difficult to get right. I have never found them difficult to regenerate, but if you have only a non maintainer build, it is a pain to have to make

Analyzer test failures

Hi, I’m seeing the following analyzer test failures on darwin. They were introduced in December, when the tests were moved around: FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c FAIL: c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c FAIL: c-c++-common/analyzer/fd-mappage-getaddri

Re: Analyzer failure due to missing header

> std::max and std::min, introduced by d99d73c77d1e and 2bad0eeb5573, are not > available because is not included. I originally thought this was only seen in cross-compilers, but it actually broke bootstrap on darwin. Attached patch restores it, OK to commit? FX 0001-Analyzer-include-algori

Analyzer failure due to missing header

Hi David, I’m seeing the following failures on building GCC with Apple’s clang: > /Users/fx/devel/gcc/gcc-repo-write/gcc/analyzer/region-model.cc:3426:16: > error: unexpected type name 'byte_size_t': expected expression >std::max (bytes.m_size_in_bytes, >

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

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 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

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: 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

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

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

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

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

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: 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: 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: 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

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: [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

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

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: 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,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

[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: 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

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: 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

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: 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.).

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

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

[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].

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

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-

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

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: [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

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

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]: *

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

[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

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

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

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

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

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

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: 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

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

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: 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

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: Performance regression on the 4.3 branch?

Then it's filed as PR 30801. 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: gfortran year end status report

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

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: 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: 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

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: 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 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: 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

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: 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

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

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: 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

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,

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: 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

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

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: 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

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: [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

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: 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

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

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

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

[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: [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

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

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

[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

[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

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

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: 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: 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

  1   2   >