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

2014-06-19 Thread FX
. 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)

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

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

2014-06-24 Thread FX
, FX

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

2014-06-28 Thread FX
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)

2014-06-29 Thread FX
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

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

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

2014-07-02 Thread FX
, /* 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

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

2014-07-03 Thread FX
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

2014-07-03 Thread FX
(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

2014-07-03 Thread FX
/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

2014-07-03 Thread FX
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: [wwwdocs,Fortran] Announce IEEE intrinsic modules support for Fortran

2014-07-04 Thread FX
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

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

2014-07-06 Thread FX
-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: [fortran, patch] IEEE intrinsic modules (ping)

2014-07-07 Thread FX
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)

2014-07-07 Thread FX
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)

2014-07-07 Thread FX
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)

2014-07-07 Thread FX
with the freshly-built compiler, not the host compiler. FX

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

2014-07-07 Thread FX
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] Support for IEEE underflow control on x86/x86_64

2014-07-09 Thread FX
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)

2014-07-10 Thread FX
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: [PATCH, fortran testsuite]: A couple of fixes in gfortran.dg/ieee directory

2014-07-15 Thread FX
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: PR 60414: Patch proposal

2014-07-18 Thread FX
”. 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

Fix libtool.m4 for Darwin = 10.10

2014-11-11 Thread FX
OS 10.10), incorporates this fix into our libtool.m4 and regenerates the configures under our control. OK to commit? This touches so many area it probably needs a build maintainer or global maintainer to approve it. FX PS: Let me know what the procedure is for the toplevel files (libtool.m4

Re: Fix libtool.m4 for Darwin = 10.10

2014-11-11 Thread FX
or global maintainer to approve it. FX libtool.diff Description: Binary data libtool.ChangeLog Description: Binary data

Re: [PATCH][Revisedx2] Fix PR63750

2014-11-11 Thread FX
Ok. Committed as rev. 217342. Thanks for the review! FX

Re: libstdc++ new deque failures

2014-11-11 Thread FX
equal. (_Deque_base::_M_move_impl()): Implement move-from state. In file included from /Users/fx/devel/gcc/ibin2/x86_64-apple-darwin14.0.0/libstdc++-v3/include/deque:64:0, from /Users/fx/devel/gcc/trunk2/libstdc++-v3/include/precompiled/stdc++.h:67: /Users/fx/devel/gcc/ibin2

Re: [PATCH][fortran] PR 63701 Make sure variable is always used initialised

2014-11-11 Thread FX
2014-11-11 Kyrylo Tkachov kyrylo.tkac...@arm.com PR fortran/63701 * trans-expr.c (gfc_get_tree_for_caf_expr): Initialise found to false.init-found.patch OK, thanks for the patch. FX

Re: Fix libtool.m4 for Darwin = 10.10

2014-11-11 Thread FX
for libgo (https://code.google.com/p/go/issues/detail?id=9089). FX

Re: Fix libtool.m4 for Darwin = 10.10

2014-11-11 Thread FX
be patched in GCC, or whether I should report them to be patched somewhere else (like libgo and zlib, for example). It’s important to do it properly, otherwise codebases diverge and maintance becomes difficult. FX

[patch, v2] Fix libtool.m4 for Darwin = 10.10

2014-11-11 Thread FX
Here’s v2 of the patch, including libjava/configure and libjava/classpath/configure, as well as zlib/configure (since it has some adaptations from upstream, documented in zlib/ChangeLog.gcj). OK to commit? Bootstrapped with all supported languages on x86_64-apple-darwin14. FX

Re: [patch, v2] Fix libtool.m4 for Darwin = 10.10

2014-11-11 Thread FX
further invocations of autoconf to regenerate configure files will lead to any regression. FX

Re: [patch, v2] Fix libtool.m4 for Darwin = 10.10

2014-11-11 Thread FX
Totally agree with Mike here. If you look at the patch it's clear it's just hitting Darwin and it's absolutely safe. Thanks everyone for the comments and review. Committed as r217366 FX

Re: [patch, v2] Fix libtool.m4 for Darwin = 10.10

2014-11-12 Thread FX
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

Re: [PATCH, libgfortran] PR 60324 Unbounded stack allocations in libgfortran

2014-11-13 Thread FX
. Is the known upper bound you have chosen (#define READF_TMP 50) compatible with the largest float we support, i.e. real(16)? So that we avoid using allocation for reading data we have written ourselves in default format :) FX

Re: [Patch, Fortran] Convert gfc_fatal_error to common diagnostics

2014-11-15 Thread FX
, if the transition will not be complete soon (or indeterminate), it should be added to the wiki’s list of partial transitions. Other than that, OK, and thanks for doing this tedious work. FX

Re: [Patch, Fortran] Convert gfc_fatal_error to common diagnostics

2014-11-15 Thread FX
/Partial_Transitions) FX

[committed,testsuite] Fix dg-error for a darwin testcase

2014-11-15 Thread FX
Committed as trivial, as the error wording changed due to more precise diagnostics: it now says ‘CFStringRef {aka const struct __CFString *}’ instead of just ‘CFStringRef’ FX 2014-10-19 Francois-Xavier Coudert fxcoud...@gcc.gnu.org * gcc.dg/darwin-cfstring-format-1.c: Adjust dg

[committed,testsuite] Fix missing includes for darwin testcases

2014-11-15 Thread FX
Committed as trivial. And also, fixed wrong date on my earlier ChangeLog entry :) FX 2014-11-15 Francois-Xavier Coudert fxcoud...@gcc.gnu.org * gcc.dg/pubtypes-3.c: Include string.h. * gcc.dg/pubtypes-4.c: Likewise. Index: gcc.dg/pubtypes-3.c

[committed,testsuite] Only run gcc.dg/tree-ssa/pr61144.c when aliases are supported

2014-11-15 Thread FX
All other tests in gcc.dg/ that use __attribute__((__alias__())) are guarded by dg-require-alias. Let’s do the same for gcc.dg/tree-ssa/pr61144.c, otherwise it complains on darwin. 2014-11-15 Francois-Xavier Coudert fxcoud...@gcc.gnu.org * gcc.dg/tree-ssa/pr61144.c: Add

[committed,testsuite] Not run gcc.target/i386/sibcall-1.c on PIC targets

2014-11-15 Thread FX
Don’t run gcc.target/i386/sibcall-1.c on PIC targets. 2014-11-15 Francois-Xavier Coudert fxcoud...@gcc.gnu.org PR target/60104 * gcc.target/i386/sibcall-1.c: Don't run on pic targets. Index: gcc.target/i386/sibcall-1.c

Re: [committed,testsuite] Not run gcc.target/i386/sibcall-1.c on PIC targets

2014-11-15 Thread FX
This looks wrong. This test should pass for 64-bit or ia32 nonpic. It was Kai’s original testcase, so I don’t want to modify it too much, other than make it skip where it clearly fails. FX

[patch, asan, testsuite] Adjust asan expected backtrace

2014-11-19 Thread FX
The attached patch fixes 23 asan testsuite failures on x86_64-apple-darwin14, where the backtrace features e.g. wrap_malloc instead of interceptor_malloc. So I adjusted the dg-output patterns to match. OK to commit to trunk? 2014-11-19 Francois-Xavier Coudert fxcoud...@gcc.gnu.org

[patch, committed]

2014-11-19 Thread FX
Committed as pre-approved by Jakub in PR62132. It took me three commits (revisions ) to get it right. I apologize for that, and I’ll stop coding for the day :( 2014-11-19 Francois-Xavier Coudert fxcoud...@gcc.gnu.org PR sanitizer/62132 * c-c++-common/asan/misalign-1.c: Pass

Re: [patch, asan, testsuite] Adjust asan expected backtrace

2014-11-19 Thread FX
Ok. If anyone has a better idea, feel free to suggest it. Thanks, committed along with the same trivial patch for g++.dg/asan/large-func-test-1.C. FX 2014-11-19 Francois-Xavier Coudert fxcoud...@gcc.gnu.org PR sanitizer/63939 * g++.dg/asan/large-func-test-1.C: Ajust dg

Re: [patch, asan, testsuite] Adjust asan expected backtrace

2014-11-19 Thread FX
Third and final patch of the series, dealing this time with the test output patterns for darwin when llvm-symbolizer is not present. Here, the only issue is cosmetic: we have an extra space after each frame pointer, i.e. #0 0x106ddaf14 (/Users/fx/devel/gcc/irun2/./a.out+0x10f14) #1

Re: [Patch, Fortran] -Wtabs cleanup

2014-11-23 Thread FX
Build and regtested on x86-64-gnu-linux. OK for the trunk? OK. One question: I don’t understand why you need two separate Wtabs lines in lang.opt. FX

Re: [Patch, Fortran] -Wtabs cleanup

2014-11-23 Thread FX
Because EnabledByLanguage(Fortran,Wall || Wpedantic) isn't supported – using two separate Wtabs is the work around. Cf. https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02895.html You’re the best :) FX

Re: [Patch, Fortran] Remove gfc_fatal_error_1

2014-11-23 Thread FX
I will build and regtest it after Manuel's commit. OK, when it succeeds? OK indeed.

[patch, build] Restore bootstrap in building libcc1 on darwin

2014-11-23 Thread FX
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

[patch] Restore bootstrap on powerpc*-apple-darwin*

2014-11-24 Thread FX
the full bootstrap), obviously doesn’t affect other targets. OK to commit to trunk and 4.9? FX 2014-11-24 Rohit rohitarul...@freescale.com PR bootstrap/63703 * config/rs6000/darwin.h (REGISTER_NAMES): Update based on 32 newly added GCC hard register numbers for SPE high

Pushing recent libtool fix to binutils-gdb and newlib/libgloss

2014-11-24 Thread FX
mentions read-only CVS. Could someone do it for me? Thanks, FX commit 8d25b840ce688bfa601b0ad5f53c4185627c8975 Author: FX fxcoud...@gmail.com Date: Wed Nov 12 13:26:06 2014 +0100 * libtool.m4: Fix globbing of darwin versions. diff --git a/ChangeLog b/ChangeLog index

Re: [PATCH] Don't unilaterally include ieeefp.h when checking for fpsetmask

2014-11-24 Thread FX
The attached change fixes the build of libgfortran on hppa1.1-hp-hpux10.20 (I know I'm going for the oldest system that will build gfortran). OK

Re: Pushing recent libtool fix to binutils-gdb and newlib/libgloss

2014-11-24 Thread FX
Done: https://sourceware.org/ml/binutils/2014-11/msg00318.html Thanks!

Re: [patch] Restore bootstrap on powerpc*-apple-darwin*

2014-11-25 Thread FX
confirmations that it restores full bootstrap on powerpc-apple-darwin9, I’ve committed (r218058). I’ll backport to the 4.9 branch shortly. FX

Re: [Patch, Fortran] Move gfc_internal_error to common diagnostics

2014-11-25 Thread FX
Build and regtested on x86-64-gnu-linux. OK for the trunk? OK

Re: [Patch, Fortran] convert almost all {warning,error}_now to common diagnostic

2014-11-25 Thread FX
(a) those majority which might need buffering (gfc_error, gfc_warning); Is there a plan for those in the longer term? Bootstrapped and regtested on x86-64-gnu-linux. OK for the trunk? OK

[fortran,patch] Emit code for some IEEE functions in the front-end

2014-09-26 Thread FX
. This regresses ieee_2.f90, at -m32 -fno-float-store only, where we seem to trigger a missimplification of __builtin_rint(). I’ll send, just after this one, a mail to gcc to get some help on that, and track the issue separately. OK to commit? FX ieee.ChangeLog Description: Binary data ieee.diff

[fortran,patch] Forbid assignment of different character kinds

2014-09-28 Thread FX
it or tested it) to do so. Bootstrapped and regtested on x86_64-apple-darwin14. OK to commit? FX PS: given the little feedback we get on that feature, I suppose nobody actually uses nondefault character kinds. Just like it seems nobody uses the IEEE modules (no feedback received, at all

Re: [fortran,patch] Forbid assignment of different character kinds

2014-09-29 Thread FX
on gfc_current_form != FORM_FIXED, as diagnostics should be emitted based on language/pedantic options, not source form. Regtested on x86_64-apple-darwin14, comes with a testcase. OK to commit? FX pr36534.ChangeLog Description: Binary data pr36534.diff Description: Binary data

Re: [PATCH v4 1/2] Fix __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__

2014-09-29 Thread FX
and regtests fine on x86_64-apple-darwin14 (I’ve got unrelated objc/obj-c++ failures, see PS). I suggest we backport it to 4.9, so that when 4.9.2 is released it builds fine on Yosemite. OK? FX PS: I’ve got quite a few objc/obj-c++ failures on x86_64-apple-darwin14, but I assume it’s because

Re: [PATCH, i386]: Enable reminder{sd,df,xf} and fmod{sf,df,xf} only for flag_finite_math_only.

2014-09-30 Thread FX
The patch will be committed to mainline and other release branches. Thanks! FX

Re: [Fortran, Patch] Implement IMPLICIT NONE

2014-10-04 Thread FX
Build and regtested on x86-64-gnu-linux. OK for the trunk? Looks mostly OK, but I have one question: I don’t understand what the wording Type IMPLICIT NONE statement” is supposed to mean. Why “type”? FX

Re: [Fortran, Patch] Implement IMPLICIT NONE

2014-10-04 Thread FX
If you have a better suggestion for the wording … I’d suggest “IMPLICIT NONE (TYPE) statement at %C following an IMPLICIT statement” (and the other way around). OK, with or without the wording change, I let you decide

Re: [fortran,patch] Emit code for some IEEE functions in the front-end

2014-10-04 Thread FX
on x86_64-apple-darwin14. This regresses ieee_2.f90, at -m32 -fno-float-store only, where we seem to trigger a missimplification of __builtin_rint(). I’ll send, just after this one, a mail to gcc to get some help on that, and track the issue separately. OK to commit? FX ieee.ChangeLog

Re: [fortran,patch] Forbid assignment of different character kinds

2014-10-04 Thread FX
for the review. FX

[patch] Add -static-libquadmath option

2014-10-04 Thread FX
and regtested on x86_64 linux. OK to commit? FX static_quadmath.ChangeLog Description: Binary data static_quadmath.diff Description: Binary data

Re: [Fortran, Patch] Implement IMPLICIT NONE

2014-10-08 Thread FX
Patch Patch cleaning up the testsuite (while Tobias is curing is cold :) is pre-approved. It comes from the last-minute wording change I suggested, I suppose. FX

[libquadmath,committed] Fix typo in doc

2014-10-08 Thread FX
Committed as trivial, rev. 216006 2014-10-08 Francois-Xavier Coudert fxcoud...@gcc.gnu.org PR libquadmath/63487 * libquadmath.texi (sincosq): Fix typo. Index: libquadmath.texi === --- libquadmath.texi

[patch] Don't install libquadmath.info if libquadmath is not actually built

2014-10-09 Thread FX
The attached patch prevents libquadmath from installing its info file if the library is not actually built. Tested on x86_64-linux, both on a built with libquadmath (normal) and without (tweaking configure so it thinks _float128 is not supported). OK to commit? quadmath.ChangeLog

Re: [patch] Don't install libquadmath.info if libquadmath is not actually built

2014-10-09 Thread FX
The attached patch prevents libquadmath from installing its info file if the library is not actually built. Tested on x86_64-linux, both on a built with libquadmath (normal) and without (tweaking configure so it thinks _float128 is not supported). OK to commit? Again, with correct

Re: [fortran,patch] Emit code for some IEEE functions in the front-end

2014-10-09 Thread FX
Ok, thanks for the patch! Committed as rev. 216036. Thanks for the review. FX

Re: [patch] Add -static-libquadmath option

2014-10-09 Thread FX
Version 2 of the patch, now handling the darwin case (thanks Iain) and expressely noting in the documentation the implications on redistribution (thanks Joseph). Bootstrapped and regtested on x86_64-apple-darwin14. OK to commit? I need a C/driver options maintainer, or global reviewer, to OK

Re: [patch] Add -static-libquadmath option

2014-10-09 Thread FX
But it still needs to be OK'd by either a global reviewer or one of the listed Darwin maintainers ;) ... ... (ccing Mike) Duh me. I thought you were a darwin maintainer. Sorry. FX

[patch,fortran] Handle (signed) zeros, infinities and NaNs in some intrinsics

2014-10-11 Thread FX
-apple-darwin14. OK to commit? FX intrinsics.ChangeLog Description: Binary data intrinsics.diff Description: Binary data

[fortran,patch]

2014-10-11 Thread FX
After the compile-time simplification, this patch fixes the handling of special values (infinities and NaNs) by intrinsics EXPONENT, FRACTION, SPACING, RRSPACING SET_EXPONENT on the code generation side. Bootstrapped and regtested on x86_64-linux. OK to commit? intrinsics.ChangeLog

Re: [patch] Add -static-libquadmath option

2014-10-15 Thread FX
ping Patch needs: - C/driver options maintainer, or global reviewer, to OK the C changes (outside darwin). They are really simple - Fortran maintainer to OK the Fortran part Version 2 of the patch, now handling the darwin case (thanks Iain) and expressely noting in the documentation the

[fortran,patch] Handle infinities and NaNs in intrinsics code generation

2014-10-16 Thread FX
ping After the compile-time simplification, this patch fixes the handling of special values (infinities and NaNs) by intrinsics EXPONENT, FRACTION, SPACING, RRSPACING SET_EXPONENT on the code generation side. Bootstrapped and regtested on x86_64-linux. OK to commit?

Re: [fortran,patch] Handle infinities and NaNs in intrinsics code generation

2014-10-19 Thread FX
/ F2008 parts mature be tested for now. FX

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

2014-05-26 Thread FX
, 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)

2014-05-26 Thread FX
). 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)

2014-05-26 Thread FX
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)

2014-05-26 Thread FX
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)

2014-05-26 Thread FX
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)

2014-05-27 Thread FX
/coreutils/src/longlong.h). FX

Re: Darwin bootstrap failure following wide int merge

2014-05-28 Thread FX
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

2014-05-28 Thread FX
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

2014-05-28 Thread FX
-darwin13. Thanks! FX patch Description: application/applefile CL Description: Binary data

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

2014-06-02 Thread FX
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

2014-06-02 Thread FX
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: [PATCH] Add support for OpenMP fortran user defined reductions

2014-06-03 Thread FX
not such a big deal. FX

Re: [fortran, patch] IEEE intrinsic modules

2014-06-05 Thread FX
, but we need to think clearly about that… FX

Re: [fortran, patch] IEEE intrinsic modules

2014-06-05 Thread FX
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

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

2014-06-06 Thread FX
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

2014-06-06 Thread FX
-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

2014-06-06 Thread FX
. FX

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

2014-06-07 Thread FX
. 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] Fix Cray pointers in modules

2014-06-08 Thread FX
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

2014-06-08 Thread FX
? 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

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

2014-06-14 Thread FX
, 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

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

2014-06-15 Thread FX
Committed as rev. 211685, thanks for the review. FX

  1   2   3   4   >