,
but normal strings.)
Russell, you said “tested on x86_64-linux”. Could you explicitly confirm that
you have bootstrapped it and regression-tested the full gfortran testsuite ?
Cheers,
FX
(and testcase pattern).
FX
)
- Maybe not doing all the tests (those after The following if-statements”) if
op == INTRINSIC_NONE, as all the s2 comparisons will be false.
- The PR number in the ChangeLog is wrong (both times)
With the above fixed, it’s OK.
Thanks for taking care of all this!
FX
condition (here, I guess it’s “undefined pointer”)?
Regarding the other example mention in the PR’s comment #2, I guess there’s no
requirement for the compiler to diagnose this, is there?
FX
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/64925
* symbol.c(check_conflict): Check for a conflict between a dummy
argument and an internal procedure name.
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/64925
*
Whoops, sorry about that. As you can see I have small patches
sitting in my tree. I tried to untangle the 'svn diff’
Thanks for cleaning and submitting those! I’ll try to review them over the next
2 days, if nobody beats me to it :)
FX
Does it also catch the other cases shown in the PR? Things like:
generic :: 2
generic :: 2 =
generic :: 1 = x
generic :: ?
etc.
OK if so. If not, maybe it’s worth adding them at the same time?
FX
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66039
* io.c (match_filepos): Check for incomplete/mangled REWIND, FLUSH,
BACKSPACE, and ENDFILE statements
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66039
*
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66044
* decl.c(gfc_match_entry): Change a gfc_internal_error() into
a gfc_error()
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66044
* gfortran.dg/entry_21.f90: New test.
OK
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66040
* parse.c(verify_st_order): Replace a gfc_internal_error with your
generic gfc_error.
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66040
* gfortran.dg/misplaced_statement.f90:
things and seems safe, so let’s do it.
OK to commit.
FX
-dependent value is not a constant, it depends on the file chosen (and
its permissions). I believe that’s still within “processor dependent”. And it
certainly makes more sense that the other possibilities.
Thus, OK to commit.
FX
to the codebase. A quick grep
through the current front-end and middle-end confirms that.
Because it’s not used and not tested, it could bitrot and adds to the
maintainance cost.
FX
If unused on trunk, why would we commit it there?
When your branch is merged, you'll merge it along. Otherwise that defeats the
purpose of working on a branch, unless I misunderstand something...
FX
Le 9 janv. 2015 à 16:37, Tom de Vries tom_devr...@mentor.com a écrit :
Jakub
support to caf.dg
(currently unused).
OK. It’s probably best to commit the two parts as separate commits, though.
FX
2014-12-28 Andre Vehreschild ve...@gmx.de
* trans-decl.c (gfc_finish_var_decl): Fixed displaced comment.
* trans-stmt.c (gfc_trans_allocate): Fixed indentation.
OK to commit. Thanks!
FX
OK for trunk? What about the other open branches?
OK for trunk.
After it’s been in for a bit of time, probably OK for all active branches,
unless someone (or you) think it’s unwise.
FX
This patch below allows ubsan to run when libstdc++ is built but not installed
(something which happens on darwin, in particular). This fixes all 658 ubsan
failures when run in this particular configuration.
OK to commit?
FX
2014-12-20 Francois-Xavier Coudert fxcoud...@gcc.gnu.org
Built and currently regtested on x86-64-gnu-linux.
OK for the trunk?
OK.
I’m not sure exactly why we have a hardcoded minimal value of (2^16-1) for “max
array constructor”, or a default max stack of 2^15. But that’s a separate issue.
Thanks,
FX
Good point, thank you. Updated patch attached.
I guess I still new formal approval by someone with reviewer status …
OK
OK, I think, from the Fortran POV.
I hope I didn't miss some logic issue in the middle of the trivial stuff.
Thanks for doing that work!
FX
Le 12 déc. 2014 à 08:43, Tobias Burnus bur...@net-b.de a écrit :
This patch cleans up Fortran's option handling and moves it closer to the
common way
PING - https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00731.html
OK.
it) keeps
synchronized to the terminal width anyway (as is the case for bash and zsh).
FX
OK. But if we rename the function, why not simply terminal_width() ?
FX
Le 6 déc. 2014 à 23:14, Tobias Burnus bur...@net-b.de a écrit :
This patch fixes a Fortran diagnostic regression.
With the current common diagnostic, the width shown with caret diagnostic is
determined
The attached patch removes some remaining mentions of cloog and ppl in our docs.
Tested with “make info html pdf”. OK for trunk?
FX
PS: with this, the remaining mentions of cloog or ppl are comments in
config/isl.m4, graphite.c and graphite-blocking.c. They should probably go away
too
for that is in the
toplevel configure.ac, where we already pass down the respective -L options.
Indeed, the attached patch restores bootstrap on x86_64-apple-darwin14 with
gcc as system compiler (and doesn’t break the bootstrap with clang as system
compiler).
OK to commit?
FX
PS: HJ, the reason
While in my testing, 64-bit Mac OS X 10.10.1 (x86_64-apple-darwin14.0.0)
now bootstraps, but 32-bit (i386-apple-darwin14.0.0) does not:
Is it due to my patch, or pre-existing bootstrap failure?
How do you configure this 32-bit compiler? target/build/host/CFLAGS/CXXFLAGS/etc
FX
that -mdynamic-no-pic is there because it “speeds
compiles by 3-5%”. I don’t think we care about speed when the bootstrap fails,
so can we remove it altogether?
FX
darwin.diff
Description: Binary data
Can you try adding it as
T_CFLAGS += -mdynamic-no-pic
in gcc/config/t-tarwin instead?
Nope, doing so fails to link libgcc_s.dylib:
/Users/fx/devel/gcc/i/./gcc/xgcc -B/Users/fx/devel/gcc/i/./gcc/
-B/Users/fx/devel/gcc/i2/i386-apple-darwin14.0.0/bin/
-B/Users/fx/devel/gcc/i2/i386-apple
don’t think
it should matter. First, testsuite is now much more efficiently parallelized
than before. Second, testsuite is already so large that one more test isn’t
gonna change things much.
FX
. Probably doesn’t matter much, as
it will be all folded into the same value anyway, but could you test and commit
that change together, while you’re at it?
Thanks,
FX
it in the testsuite, but the testsuite mostly include
simple independent syntax elements. In real-life code, who knows…
b) Do actual buffering as in
https://gcc.gnu.org/ml/fortran/2014-11/msg00128.html
I’d rather stick with buffering, it makes more sense in general.
FX
mentioned
this fact in the man page.
Cool stuff! Thanks for doing this, and OK to commit.
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
(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
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
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
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
Done:
https://sourceware.org/ml/binutils/2014-11/msg00318.html
Thanks!
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
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
I will build and regtest it after Manuel's commit.
OK, when it succeeds?
OK indeed.
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
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
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
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
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
, 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
/Partial_Transitions)
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 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
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
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
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
.
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
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
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
or
global maintainer to approve it.
FX
libtool.diff
Description: Binary data
libtool.ChangeLog
Description: Binary data
Ok.
Committed as rev. 217342.
Thanks for the review!
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
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
for libgo (https://code.google.com/p/go/issues/detail?id=9089).
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
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
further invocations of autoconf to
regenerate configure files will lead to any regression.
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
2.
Richard, I’d appreciate if you could review it.
Cheers,
FX
string.diff
Description: Binary data
string.ChangeLog
Description: Binary data
My knowledge of C++ is limited, but I think this additional patch to
wide-int.h is the proper fix to the issue reported by Jack, no?
I’m bootstrapping it right now, it already passed stage 2.
Boostrapped succeeded on x86_64-apple-darwin14.
OK to commit to trunk?
string.diff
Description:
will be good, I don’t see that we should add to the library
maintainance burden by special-casing targets.
Also: if other targets come along that have this need, how does your strategy
scale up?
Thanks,
FX
is
worthwhile, usually one will just offload the most performance critical
parts of his code.
Do we have the architecture for that in place in GCC in general, and in the
Fortran front-end in particular? I’d be interested to see how it works…
FX
someone is volunteering to make offloading work nicely for Fortran code and
maintain it.
FX
is not sufficient.
FX
/ F2008
parts mature be tested for now.
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?
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
-apple-darwin14. OK to commit?
FX
intrinsics.ChangeLog
Description: Binary data
intrinsics.diff
Description: Binary data
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
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
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
Ok, thanks for the patch!
Committed as rev. 216036.
Thanks for the review.
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
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
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
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
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
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
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
for the review.
FX
and regtested on x86_64 linux. OK to commit?
FX
static_quadmath.ChangeLog
Description: Binary data
static_quadmath.diff
Description: Binary data
The patch will be committed to mainline and other release branches.
Thanks!
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
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
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
. 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
lines. OK for the trunk?
You didn’t say if it was regtested. OK if it was (one can never be too sure!)
Thanks,
FX
Hi Kai,
The patch you sent (copied below) does not fix the darwin regression. It still
fails with the same ICE on attached valid code (in 64-bit mode; it compiles
with -m32).
FX
a.C
Description: Binary data
Index: config/i386/predicates.md
seconds, fixes the issue. See the testresults I posted here:
https://gcc.gnu.org/ml/gcc-testresults/2014-09/msg01449.html (without the
patch, there are 900+ testsuite failures)
Could one of the maintainers (i386 or global) review it, please?
FX
Index: gcc/config/i386/i386.c
it.
One more point, unanswered in what I’ve seen, is this from Iain:
b) I'd like a clear explanation of what it's supposed to do so that we can
examine why it doesn't do that..
c) ..and, until we fix it it, it should be disabled or left out.
FX
testcases involving alloc_comp and finalizers looked good as well. So, I
think the original patch is still fine.
OK to commit, then. Thanks for the thorough answer to my question.
FX
Iain’s request, 3. darwin maintainers have no
idea how to hunt that bug, because of #1 2.
Given that it breaks severely a secondary platform, can we please revert it,
while Iain and Kai (and others) can work on getting it better, on list or in
bugzilla?
FX
PS: And yes, I know it sucks to revert
401 - 500 of 609 matches
Mail list logo
