Re: [PATCH] Fix PR63152

); So do we want to test (sym-attr.allocatable), or (!sym-attr.pointer)? Or, asked another way: should we NULLIFY in the case of sym_has_alloc_comp || has_finalizer? FX

Re: [patch i386]: Sibcall tail-call improvement and partial fix PR/60104

suitable. If there is a patch submitted that fixes the issue, of course reversion is bad. I was unaware of that. FX

Re: [patch i386]: Sibcall tail-call improvement and partial fix PR/60104

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61387 comment #9. It doesn't apply anymore due current version of predicate was altered. Nevertheless I could easily update patch for current trunk version. Sure, please send that and I’ll test it on darwin. Thanks, FX

Re: [PR libfortran/62768] Handle filenames with embedded nulls

to think of other characters we might want to sanitize/special case, but at least on Unix/POSIX only NUL and / are fundamentally different. It might make sense to think about it for Windows targets. FX

Re: [patch i386]: Sibcall tail-call improvement and partial fix PR/60104

Perhaps it would be safer simply to revert that hunk of the original patch unless/until (1) and (2) above are addressed? Given that the original patch addresses “only” a missed-optimization (and causes ice-on-valid), it makes sense to me. FX

Re: [PATCH v4 1/2] Fix __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__

Committed as rev. 215251 Thanks for the review. FX

Re: [PATCH v4 1/2] Fix __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__

know why the exact size of new_flag should be sizeof(…)+6, but it makes sense to widen it with the new version. Given the above, could a darwin maintainer please approve this patch (either with or without my addition)? FX PS: James, for the sanitizer bits, they should be (IIUC) submitted

Re: [PATCH v4 1/2] Fix __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__

That should be allocated in darwin_find_version_from_kernel, using asprintf, and static doesn't make sense either. Does this look sane? (I don’t often use asprintf, so I might have done something stupid) FX darwin.diff 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

Re: Lots of C++ failures

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

Re: [PATCH v4 1/2] Fix __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__

I don't think you need strdup here. Updated version, bootstraps and regtests. OK to commit? gcc/ChangeLog: * config/darwin-c.c (version_as_macro): Added extra 0 for OS X 10.10 and above * config/darwin-driver.c (darwin_find_version_from_kernel): Removed kernel version check to

Re: Fix some more decl types in the Fortran frontend

So, after a six-year break (was it so long?), I’m back among the maintainers. Committed as rev. 215237 FX 2014-09-13 Francois-Xavier Coudert fxcoud...@gcc.gnu.org * MAINTAINERS: Move myself to reviewers (Fortran). Index: MAINTAINERS

Re: Fix some more decl types in the Fortran frontend

have seen regressions). Cheers, FX

Re: Fix some more decl types in the Fortran frontend

So it looks like the following patch would be the right thing? I would think so. FX

Re: Fix some more decl types in the Fortran frontend

And thanks for the review, FX. Do you want to undo your Fortran-maintainer → mere-contributor status, given that you are now again a bit more involved in the GCC development? Yeah, why not. I promise I'll be careful and only review things in my comfort zone (which isn't so large). I'll

Re: PR 60414: Patch proposal

”. In that particular case, it might also be nice to indicate that not only the testcase doesn’t crash the compiler any more, but to confirm that it now generates the correct code (i.e. that we don’t turn an ice-on-valid bug into a wrong-code bug!). Cheers, FX

Re: [PATCH, fortran testsuite]: A couple of fixes in gfortran.dg/ieee directory

And yes, I learned in a hard way that there is a difference between f90 and F90 file extension. Yup, pre-processing. Sorry I wasn’t fast enough to reply to your earlier email, and thanks for doing this. FX

Re: [fortran, patch] IEEE intrinsic modules (ping)

0, i.e. a nonexisting rounding mode flag, which is more appropriate (though it should never happen in practice). Committed as rev. 212423 after testing on x86_64-apple-darwin13. Thanks, FX z Description: Binary data

Re: [fortran,patch] Support for IEEE underflow control on x86/x86_64

of view, I’ve committed the patch as revision 212407. FX underflow.diff Description: Binary data underflow.ChangeLog Description: Binary data

Re: [fortran, patch] IEEE intrinsic modules (ping)

to c99_intrinsics.c, which is the only place they’re ever used. Built and tested on x86_64-linux, OK to commit? FX clean.ChangeLog Description: Binary data clean.diff Description: Binary data PS: I didn’t touch libcaf, as I assume this might be compiled with a different compiler. Am I

Re: [fortran, patch] IEEE intrinsic modules (ping)

is that libgfortran/config/fpu-sysv.h assumes that FP_RM and others are macros, checking them with #ifdef FP_RM”. Is that the reason? If so, we might just want to use them unconditionally… unless it creates a mess on some other SysV target! FX

Re: [fortran, patch] IEEE intrinsic modules (ping)

review). Also, related to that: could you also confirm that FP_X_INV (and others) are indeed macros, on solaris? FX

Re: [fortran, patch] IEEE intrinsic modules (ping)

with the freshly-built compiler, not the host compiler. FX

Re: [fortran, patch] IEEE intrinsic modules (ping)

Right, that's what I (vaguelly) remembered. Please consider a patch removing the ifndef __GNUC__ stuff from libgfortran.h pre-approved. The only occurrence (outside of libcaf) is in libgfortran.h. Committed attached patch as rev. 212328, after building on x86_64-linux. FX x Description

Re: [fortran, patch] IEEE intrinsic modules (ping)

-specific issues with FP-state buffer size will show up at libgfortran-building-time, rather than be swept under the rug. Since libgfortran is compiled with GCC, which supports _Static_assert since 4.6, I propose the attached patch. Built and tested on x86_64-linux, OK to commit? FX

Re: [wwwdocs,Fortran] Announce IEEE intrinsic modules support for Fortran

Also, for that page having 2-3(-4) words as a short title are necessary. What would be appropriate here? Fortran IEEE intrinsic modules”? Sounds good to me. FX

[fortran,patch] Support for IEEE underflow control on x86/x86_64

Hi all, The attached patch provides support for underflow control in the IEEE_ARITHMETIC module, for x86/x86_64 targets (our main user base). Bootstrapped and regtested on x86_64-apple-darwin13. Comes with a testcase. OK to commit? FX underflow.ChangeLog Description: Binary data

Re: [fortran,patch] Support for IEEE underflow control on x86/x86_64

(I don't think -O0 is needed, but have to check with a testsuite run.) On x86_64-apple-darwin, -O0 or -O1 are needed: at -O2 my “use_real” call is optimized out anyway, and the division simplified at compile time. FX

Re: [fortran,patch] Support for IEEE underflow control on x86/x86_64

/fpu-glibc.h file on alpha? You can mark variables with “volatile” Indeed, I should have thought of that. Once you report the results of the alpha modification, I’ll propose an updated patch with all of those remarks. Thanks, FX fpu-glibc.h Description: Binary data

Re: [fortran,patch] Support for IEEE underflow control on x86/x86_64

Here’s an updated patch, providing support for underflow control in the IEEE_ARITHMETIC module, for x86/x86_64 targets and alpha-glibc. Bootstrapped and regtested on x86_64-apple-darwin13, tested by Uros on alpha. OK to commit? underflow.ChangeLog Description: Binary data underflow.diff

Re: [PATCH, libgfortran]: Fix support_fpu_rounding_mode and add -mieee flags for alpha

, /* Map underflowed outputs to zero */ #define FE_MAP_UMZ FE_MAP_UMZ }; #endif FX, if you care for this option, I can help test the patch and corresponding testcases. Yes, that’s interesting. What libc function do you call with those FE_MAP_{D,U}MZ values? I would also like

Re: [fortran, patch] IEEE intrinsic modules (ping)

This may raise inexact, see C11 7.6.2.3. Installed as obvious. Thanks! FX

Re: [fortran,patch] Binding label can be any initialisation expression

Works as advertized and even fixes pr38838. Thanks for the patch. Thanks for the review, committed to trunk as rev. 212123 FX

Re: [fortran,patch] Binding label can be any initialisation expression

ping*2 ping To reinforce the message in my earlier email: we can fine-tune the list of allowed characters in identifiers later, but I’d like to get this patch in already (so it gets large exposure before the 4.10 release). FX Binding label can be any initialisation expression

Re: [fortran, patch] IEEE intrinsic modules (ping)

, FX

[fortran,patch] One-line fix to PR61454 (init expression simplification)

. OK to commit? FX pr61454.diff Description: Binary data pr61454.ChangeLog Description: Binary data

Re: [fortran,patch] One-line fix to PR61454 (init expression simplification)

Not only is it 'obvious' but it can do no harm in any circumstances :-) OK to commit True! Committed as rev. 211822 FX

Re: [libgfortran, patch] Fix compilation on HP/UX 10

Committed as rev. 211685, thanks for the review. FX

Re: [fortran,patch] Binding label can be any initialisation expression

ping To reinforce the message in my earlier email: we can fine-tune the list of allowed characters in identifiers later, but I’d like to get this patch in already (so it gets large exposure before the 4.10 release). FX Binding label can be any initialisation expression. Well, only scalar

Re: [libgfortran, patch] Fix compilation on HP/UX 10

, but not on hpux10. It seems safe enough to me to proceed first, and let John test in his next build of trunk (bootstrap on those machines probably isn’t fast). OK to commit? FX hpux.ChangeLog Description: Binary data hpux.diff Description: Binary data

[fortran,patch] Fix Cray pointers in modules

in gfc_finish_var_decl(). Bootstrapped and regtested on x86_64-apple-darwin13, includes a testcase. OK to commit? FX cray.diff Description: Binary data cray.ChangeLog Description: Binary data

[fortran,patch] Binding label can be any initialisation expression

? FX PS: you may notice I have had some time to hack at gfortran these past few days... it feels good! bind_c.ChangeLog Description: Binary data bind_c.diff Description: Binary data

[libgfortran, patch] Fix compilation on HP/UX 10

. It seems safe enough to me to proceed first, and let John test in his next build of trunk (bootstrap on those machines probably isn’t fast). OK to commit? FX hpux.diff Description: Binary data hpux.ChangeLog Description: Binary data

[fortran, patch] F2003 non-default kind specifiers compliance

Hi all, Our Fortran 2003 status page [1] says gfortran does not support Kind type parameters of integer specifiers”. This item is defined thusly (item 4.9 in [2]): Some of the integer specifiers (e.g. NEXTREC) were limited to default kind in Fortran 95. Any kind of integer is permitted in

[fortran, patch] Audit and patch of F95 and F2003 non-default kind specifiers warnings

-apple-darwin13, OK to commit? FX io_diagnostics.ChangeLog Description: Binary data io_diagnostics.diff Description: Binary data

Re: [fortran, patch] Audit and patch of F95 and F2003 non-default kind specifiers warnings

. FX

Re: [fortran, patch] IEEE intrinsic modules

, but we need to think clearly about that… FX

Re: [fortran, patch] IEEE intrinsic modules

standard doesn’t really allow for partial support such as this, so I’m still trying to figure out what The Right Thing To Do is. FX

Re: [PATCH] Add support for OpenMP fortran user defined reductions

not such a big deal. FX

Re: [PATCH, Fortran] PR61234: -Wuse-no-only

I think it is really weird if a coding style warning is included in -Wall. Same here. It’s not a very commonly shared coding style, so I don’t think it should be included in -Wall. Other than that, I like the idea (but cannot review the patch). FX

Re: [PATCH, Fortan] fix initialization of flag_errno_math and flag_associative_math

is specified in C C++ standards, but not in the Fortran standard). If I understand correctly, Joost’s patch just adapts this to a new flag handling mechanism. FX

Re: Darwin bootstrap failure following wide int merge

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

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

Re: Darwin bootstrap failure following wide int merge

-darwin13. Thanks! FX patch Description: application/applefile CL Description: Binary data

Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)

/coreutils/src/longlong.h). FX

Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)

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

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

Re: Darwin bootstrap failure following wide int merge (was: we are starting the wide int merge)

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)

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: [RFC, patch] Detect lack of 32-bit devel environment on x86_64-linux targets

and a serialization point, no? There you can do the check even for when cross-compiling. Well, you’ve already built a whole stage, so it’s not so early, is it? FX

Re: [RFC, patch] Detect lack of 32-bit devel environment on x86_64-linux targets

check. I argued for an earlier check, because it was a particular annoying and particularly un-user-friendly error, and wrote the check in a way to minimize the number of false negatives. But, as you say, it is not possible to write a perfect check at that early point. FX

Re: [RFC, patch] Detect lack of 32-bit devel environment on x86_64-linux targets

in into it. FX

Re: [RFC, patch] Detect lack of 32-bit devel environment on x86_64-linux targets

sucks. It comes late in the compilation, and the message itself isn’t helpful. FX

Re: fatal error: gnu/stubs-32.h: No such file

Were you waiting for further approval? If so: okay with the change proposed by Andrew. Thanks, committed as rev. 205802 with Andrew’s change. FX

Re: libsanitizer merge from upstream r196090

in the first place? Or is it a “hit and run” approach to maintainership? FX

Re: libsanitizer merge from upstream r196090

time we merge” seems poised for failure. FX

Re: libsanitizer merge from upstream r196090

, as I learnt the hard way.) FX

Re: [PATCH, libgfortran]: Fix PR59313, gfortran.dg/erf_3.F90 FAILs

Currently, gfortran.dg/erf_3.F90 FAILs on targets with 128bit (quadruple) long double, since high-precision erfc_scaled_r16 gets defined only for __float128 quadruple precision. I can’t approve it, but yes, it makes more sense than what I did earlier. FX

Re: [fortran,patch] Remove unused gfc_open_intrinsic_module()

OK. Thanks for the patch! Committed as rev. 205335.

Re: [fortran, patch] Add Fortran 2003 IEEE intrinsic modules

to glibc’s: feclearexcept (exc_clr); feraiseexcept (exc_set); So yes, raising an exception is the except action. I’ve attached a new version of config/fpu-387.h, along with the glibc version (fpu-glibc.h). I’d be glad if you could review it. Thanks a lot! FX fpu-387.h Description: Binary

Re: [patch,libgfortran] Fix binary128 ERFC_SCALED

binary128. Sorry again, FX 2013-11-20 Francois-Xavier Coudert fxcoud...@gcc.gnu.org PR libfortran/59227 * intrinsics/erfc_scaled.c (erfc_scaled_r16): Don't define if __float128 is not available. fix.diff Description: Binary data

Re: [fortran, patch] Add Fortran 2003 IEEE intrinsic modules

the assembly code). Thanks for your feedback, FX

Re: [fortran, patch] Add Fortran 2003 IEEE intrinsic modules

compiler flags only for Fortran. You could also ask Mike Stump to review the testsuite changes. Mike, in your understanding, is there any place where Fortran-only flags could be specified in the testsuite? FX

Re: [patch,libgfortran] Fix binary128 ERFC_SCALED

*x) overflows. Hum, I get roughly -106 where you have -8192, so I’ll not commit immediately with the value I have, and let you check it first. OK to commit? FX erfc_scaled.diff Description: Binary data

Re: [patch,libgfortran] Fix binary128 ERFC_SCALED

So, yeah, you're correct. My suggestion was based on the not so careful mistake of replacing x*x by x+x and dropping log(2). That is, I had x+x = -emax -- x = - emax / 2. Committed as rev. 205151, thanks for the review! FX

[patch,libgfortran] Fix binary128 ERFC_SCALED

12, it simply calls erfcq() then multiplies by expq(x*x). For larger arguments, it uses a power expansion in 1/x. The new implementation provides answers within to 2 ulp of the correct value. Regtested on x86_64-apple-darwin13, comes with a testcase. OK to commit? FX erfc_scaled.ChangeLog

[libgfortran,patch] Silence a warning

This attach patch adds an assert() in the library to fix PR 51828, i.e. silence a “may be used uninitialized” warning. Built and regtested on x86_64-apple-darwin13. OK to commit? FX libwarning.ChangeLog Description: Binary data libwarning.diff Description: Binary data

[fortran,doc] Fix typo in doc

I think the doc says “assumed-shape” where it means “assumed-rank”. Is that OK? FX Index: gfortran.texi === --- gfortran.texi (revision 204389) +++ gfortran.texi (working copy) @@ -2624,7 +2624,7 @@ other hand, assumed

Fwd: [RFC, patch] Detect lack of 32-bit devel environment on x86_64-linux targets

being invisible to a large majority of the power users. So, what do you think? FX Index: configure.ac === --- configure.ac(revision 201292) +++ configure.ac(working copy) @@ -2861,6 +2861,26 @@ case ${target

[RFC, patch] Detect lack of 32-bit devel environment on x86_64-linux targets

majority of the power users. So, what do you think? FX Index: configure.ac === --- configure.ac(revision 201292) +++ configure.ac(working copy) @@ -2861,6 +2861,26 @@ case ${target} in ;; esac +# Special user

Re: fatal error: gnu/stubs-32.h: No such file

like to submit this doc patch formally. Tested by doing make info html pdf. OK to commit to trunk? What about other active release branches? FX Index: install.texi === --- install.texi(revision 201292) +++ install.texi

[fortran, patch] Follow-up widechar error patch

an error is printed. I didn't handle it consistently, which should now be fixed. Bootstrapped and regtested on x86_64-apple-darwin11. OK to commit? FX errorfix.ChangeLog Description: Binary data errorfix.diff Description: Binary data

Re: [Patch, libfortran] Reduce default precision for list-directed and G0 real output

. At least, I'd suggest surveying how other compilers handle the issue (Sun, which I have at hand, does precise round-trip). FX

Re: [fortran, patch] Fix display of locus when source contains wide characters

Looks OK to me except for: - for (; i 0; i--) + for (; i 0;) Might as well just make that a while loop. Indeed! Committed with a while loop, thanks for the review! FX

[fortran, patch] Improve module version error messages

use anyway, and not documented. They're useful only to us, and they're written in the module file anyway. So, bootstrapped and regtested on x86_64-apple-darwin11, OK for trunk? FX module.ChangeLog Description: Binary data module.diff Description: Binary data

[fortran, patch] Fix display of locus when source contains wide characters

. Bootstrapped and regtested on x86_64-apple-darwin11, OK for trunk? FX widechar_locus.ChangeLog Description: Binary data widechar_locus.diff Description: Binary data test.f90 Description: Binary data

Re: [Patch, Fortran] Add -Wc-binding-type warning

be wrong, but probably is OK in most cases. It can have value, but not as a default warning I think. I don't think I can approve patches given that I'm not following gfortran development very closely, but if I could I would approve it, it seems OK :) FX

Re: [fortran, patch] Improve module version error messages

based on Steve approval. Thanks for the review! FX

Re: [fortran, patch] Allow displaying backtraces from user code

the consensus. Thanks, FX

[fortran, patch] Fix handling of backtrace options in the library

-darwin11, but is an area not covered by the testsuite. I have manually checked that running various types of abort, both in a pure Fortran code and a mixed C/Fortran (with C main), with all combinations -fno-backtrace/GFORTRAN_ERROR_BACKTRACE, behaved as expected. OK to commit to trunk? FX

[fortran, patch] Allow displaying backtraces from user code

BIND(C) Patch was bootstrapped and regtested on x86_64-apple-darwin11, also tested with make info html pdf. OK for trunk? FX traceback2.ChangeLog Description: Binary data traceback2.diff Description: Binary data

Re: [fortran, patches] Two short patches to review

Although I suspect you've been lurking in the background, welcome back to the land of gfortran hacking. Your first screw up is free, additional screw ups require you to fix your screw up and fix an additional bug as your reward. Attached patch committed as revision 181200. FX

[libgfortran, patch] Silence a warning in fallback round() implementation

config.h on x86_64-linux to simulate the conditions. OK to commit to trunk? FX round.diff Description: Binary data round.ChangeLog Description: Binary data

[fortran, patch] PR 21881, issue a fatal error instead of an ICE

not for now AFAIU). So, the attached patch simply turns the ICE into a fatal error. The error being fatal, it doesn't trigger double errors as far as I could check. I'm not adding a testcase, though I could if you think that's necessary. Regtested on x86_64-linux, OK to commit to trunk? FX

[libgfortran, patch] Silence a warning in libgfortran's runtime/error.c

This patch for PR 47972 uses __builtin_choose_expr instead of the current if-else, avoiding the type warning for the branch not taken. This was suggested by Jakub in the PR itself. Bootstrapped and regtested on x86_64-linux, OK to commit to trunk? FX typewarning.ChangeLog Description: Binary

[fortran, patch] Add DREAL simplification (last remaining elemental required for initialization expressions)

its last update). Regtested on x86_64-linux, comes with a testcase. OK to commit to trunk? FX dreal.ChangeLog Description: Binary data dreal.diff Description: Binary data

[fortran, patch] Substring simplification fix

zero. But, the actual condition should be: never less than the starting point. So, the attached patch corrects the fix for PR 48876 and fixes PR 50409. It expands the original testcase to include the code triggering the new PR. Regtested on x86_64-apple-darwin11, OK to commit to trunk? FX

[fortran, patches] Two short patches to review

the testcase from the PR and commit. Cheers, FX

Re: [fortran, patches] Two short patches to review

of compliment, I'm sure to screw up and then hide :) I'll get to it tomorrow morning, after some sleep. Thanks, FX

<    1   2   3   4   5   6   7   >