o
give only the relevant 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
)
- 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
Thus: OK to commit with adjusted error message (and testcase pattern).
FX
> 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
>
> PR fortran/66040
> * parse.c(verify_st_order): Replace a gfc_internal_error with your
> generic gfc_error.
>
> 2015-05-XX Steven G. Kargl
>
> PR fortran/66040
> * gfortran.dg/misplaced_statement.f90: New test.
OK
> 2015-05-XX Steven G. Kargl
>
> PR fortran/66039
> * io.c (match_filepos): Check for incomplete/mangled REWIND, FLUSH,
> BACKSPACE, and ENDFILE statements
>
> 2015-05-XX Steven G. Kargl
>
> PR fortran/66039
> * gfortran.dg/filepos1.f90: New test
OK
> 2015-05-XX Steven G. Kargl
>
> PR fortran/66044
> * decl.c(gfc_match_entry): Change a gfc_internal_error() into
> a gfc_error()
>
> 2015-05-XX Steven G. Kargl
>
> PR fortran/66044
> * gfortran.dg/entry_21.f90: New test.
OK
> 2015-05-XX Steven G. Kargl
>
> 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
>
> PR fortran/64925
> * gfortran.dg/pr64925.f90: New test.
OK
>PR fortran/66045
>* expr.c (gfc_check_assign): Check for assignment of NULL() instead
>of the (intended) pointer assignment.
OK
> Yes, the patch appears to catch those as well.
Then: OK to commit.
Thanks!
FX
> 2015-05-27 Steven G. Kargl
>
> * simplify.c (gfc_simplify_reshape): Convert assert into returning
> NULL, which triggers an error condition.
OK to commit.
>equivalence-objects
>
>
> 2015-06-03 Steven G. Kargl
>
>PR fortran/66377
>gfortran.dg/equiv_9.f90: New test.
OK. I agree the other test case is not suitable for the testsuite.
FX
gt;* io/read.c (read_f): Likewise.
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
to use.
Moreover, 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
c.gnu.org/wiki/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
* gcc.dg/darwin-cfstring-format-1.c: Adjust dg-error.
Index: gcc.dg
Committed as trivial.
And also, fixed wrong date on my earlier ChangeLog entry :)
FX
2014-11-15 Francois-Xavier Coudert
* gcc.dg/pubtypes-3.c: Include .
* 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
* gcc.dg/tree-ssa/pr61144.c: Add dg-require-alias.
Index: gcc.
Don’t run gcc.target/i386/sibcall-1.c on PIC targets.
2014-11-15 Francois-Xavier Coudert
PR target/60104
* gcc.target/i386/sibcall-1.c: Don't run on pic targets.
Index: gcc.target/i386/sibcall-1.c
===
--- gcc.ta
> 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
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
* c-c++-common/asan/h
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
PR sanitizer/62132
* c-c++-common/asan/misalign-1.c: Pass -fno-omit-frame-pointe
> 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
PR sanitizer/63939
* g++.dg/asan/large-func-test-1.C: Ajust dg-output.
Index
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
> 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.
bootstrap with clang 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
full bootstrap), obviously doesn’t affect other
targets.
OK to commit to trunk and 4.9?
FX
2014-11-24 Rohit
PR bootstrap/63703
* config/rs6000/darwin.h (REGISTER_NAMES): Update based on 32 newly
added GCC hard register numbers for SPE high registers.
ppc.diff
but their
> webpage only mentions read-only CVS.
>
> Could someone do it for me?
>
> Thanks,
> FX
>
>
>
>
> commit 8d25b840ce688bfa601b0ad5f53c4185627c8975
> Author: FX
> Date: Wed Nov 12 13:26:06 2014 +0100
>
>* libtool.m4: Fix gl
>> 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!
touch any other target.
After further confirmations that it restores full bootstrap on
powerpc-apple-darwin9, I’ve committed (r218058).
I’ll backport to the 4.9 branch shortly.
FX
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
OK
> (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
itionally, I mentioned
> this fact in the man page.
Cool stuff! Thanks for doing this, and OK to commit.
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
t_cst (TREE_TYPE (tmp), 1)” instead of
"build_int_cst (type, 1)” in that last line. 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
e, then I 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
mined in a processor-dependent fashion. Except our
process-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
ay and failed.
Well, it fixes things and seems safe, so let’s do it.
OK to commit.
FX
submodules)?
Cheers, and thanks for this patch!
FX
> 2015-07-03 Steven G. Kargl
>
> * io.c (is_char_type): New function to test for BT_CHARACTER
> (gfc_match_open, gfc_match_close, match_dt_element): Use it.
>
> 2015-07-03 Steven G. Kargl
> * gfortran.dg/pr66725.f90: New test.
OK to commit. Thanks!
FX
indicate any real use in
existing build systems, but quite a few cases of people confused by its
existence and purpose.
I’m saying we get rid of it. Attached patch bootstrapped and tested on
x86_64-apple-darwin.
OK to commit?
FX
libgfortranbegin.diff
Description: Binary data
>
> * gfortran.dg/iomsg_2.f90: New test.
OK to commit, thanks!
FX
support 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
standard 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
assuming
someone is volunteering to make offloading work nicely for Fortran code and
maintain it.
FX
tage 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:
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
ner 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
ether allocators are always 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+
> 2014-11-11 Kyrylo Tkachov
>
>PR fortran/63701
>* trans-expr.c (gfc_get_tree_for_caf_expr): Initialise found to
> false.
OK, thanks for the patch.
FX
ctly. I’ve filed a bug
for libgo (https://code.google.com/p/go/issues/detail?id=9089).
FX
d classpath should 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
that all 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
Thanks,
FX
commit 8d25b840ce688bfa601b0ad5f53c4185627c8975
Author: FX
Date: Wed Nov 12 13:26:06 2014 +0100
* libtool.m4: Fix globbing of darwin versions.
diff --git a/ChangeLog b/ChangeLog
index 32b3c15..5ed8242 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2014-11-12 Fr
OK for Fortran indeed.
> Le 10 août 2016 à 19:14, Paul Richard Thomas
> a écrit :
>
> Dear Joseph,
>
> The fortran part is OK. I have put FX in copy since he was
> instrumental in the fortran implementation. However, I find it hard to
> imagine that he will object to t
ive” tests too? To be sure we still catch
malformed parenthesized formats?
FX
> 2016-06-01 Paul Thomas
>
>PR fortran/71156
>* decl.c (copy_prefix): Add checks that the module procedure
>declaration prefixes are compliant with the interface. Invert
>order of existing elemental and pure checks.
>* resolve.c (resolve_fl_procedure): Invert order of elemen
e_type_node.
If fact, if there is a long double type with precision of 128, then
float128_type_node is NULL.
Would that match the (new) C behavior? I think it does.
FX
> Fortran note: the float128_type_node used in the Fortran front end is
> renamed to gfc_float128_type_node, since the semantics are different:
> in particular, if long double has binary128 format, then the new
> language-independent float128_type_node is a distinct type that also
> has binary128 f
well as other
platforms). OK to commit?
FX
parallel.ChangeLog
Description: Binary data
parallel.diff
Description: Binary data
e/2017-08/msg00034.html), but didn’t
get any. So I cannot prove it (and fix it), but there is overwhelming evidence
that the problem is in libstdc++.
FX
t that doesn’t work:
In file included from
/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/bits/exception_ptr.h:39:0,
from
/Users/fx/devel/gcc/trunk/libstdc++-v3/libsupc++/exception:143,
from
/Users/fx/devel/gcc/ibin/x86_64
ild where
x86_64-apple-darwin17.0.0/libstdc++-v3 was entirely removed, can be found here:
https://gist.github.com/fxcoudert/b621465a794d968593bc7ed90c0fc1fb
FX
ed any help or
advice in identifying or debugging the issue.
FX
Thanks Jonathan. I tried, and it does not work, I still get the same error:
Making all in include
mkdir -p ./x86_64-apple-darwin17.0.0/bits/stdc++.h.gch
mkdir -p ./x86_64-apple-darwin17.0.0/bits/stdc++.h.gch
/Users/fx/devel/gcc/ibin/./gcc/xgcc -shared-libgcc
-B/Users/fx/devel/gcc/ibin/./gcc
The output of “make -j4” in a build at stage1, where I have just run "rm -rf
x86_64-apple-darwin17.0.0/**/libstdc++-v3”, with the patch applied:
https://gist.github.com/fxcoudert/46f0026c44eb3db2937ac0e92a477338
FX
lexity
of this build machinery puts it out of my reach.
FX
Hi,
I’m suggesting we apply the following patch to provide links to macOS package
managers, where users can download binaries for GCC on macOS. I have included
the two major ones, Homebrew and MacPorts.
FX
mac.diff
Description: Binary data
mac.ChangeLog
Description: Binary data
or so years.)
Done.
Does the website get rebuilt automatically, or does it need to be triggered?
FX
> 2016-12-21 Janne Blomqvist
>
> PR fortran/78867
> * trans-expr.c (gfc_conv_procedure_call): Emit DECL_EXPR also for
> non-pointer character results.
>
> testsuite ChangeLog:
>
> 2016-12-21 Janne Blomqvist
>
> PR fortran/78867
> * gfortran.dg/string_length_4
tps://gcc.gnu.org/wiki/LibgfortranAbiCleanup> which I feel comfortable
addressing.
FX
ftell.ChangeLog
Description: Binary data
ftell.diff
Description: Binary data
=70311)
The attached patch, bootstrapped and regtested on x86_64-apple-darwin16.3.0,
fixes the issue by including the proper header.
Committed as revision 243843.
FX
strings.diff
Description: Binary data
x86_64-apple-darwin16.3.0.
OK to commit?
FX
PS: after that patch, the most often used header (not included in
libgfortran.h) is stdlib.h, used in 351 out of 436 library source files. Maybe
that warrants including it in libgfortran.h? (next are string.h with 129
includes and limits.h with 113
?view=revision&revision=243847
I have not touched caf/* files, as duplication of includes there seems
intentional.
FX
hy do we now need to include trans.h?
Thanks again for working on that!
FX
file ‘omp_lib.mod’ for reading at (1): No such
> file or directory
> compilation terminated.
>
>
>
> Bootstrapped and tested on x86_64-apple-darwin15. OK to commit?
>
> FX
>
>
>
>
>
>
> 2016-05-03 Francois-Xavier Coudert
>
> PR
ormatting.
OK. Thanks for taking care of that.
FX
me of the new .c files including trans-types.h
> but not trans.h and failing to compile. AFAIU the convention is that
> headers should include whatever is necessary to use said header. So
> this is some latent bug that has been exposed by my other changes.
If, with the final version of the patch, you can remove it, please do. And if
you don’t, please remove the trans.h includes from source files that already
include trans-types.h
FX
ype_node in the Fortran front-end is only used for
intermediate values and temporaries; it is used every time we build a
COND_EXPR. It is not part of the ABI.
FX
ms), and thus from 32-bit
to 8-bit on “typical” targets, the optimizer might be able to emit more compact
code. I am not sure this was tested.
So: maybe it is a case of "Profile. Don't speculate.”
FX
elated change
along?
FX
Given lack of review of this Fortran-specific patch for libgomp, can a Fortran
maintainer approve it please?
FX
Index: libgomp/Makefile.am
===
--- libgomp/Makefile.am (revision 235843)
+++ libgomp/Makefile.am (working copy
the
> failures
Patch approved. The old code used gfc_extract_int, which bails out if a
non-constant expression is passed, so this is the right thing to do.
FX
t, with an additional comment and a link to the PR.
Thanks!
FX
seems reasonable, but I am not sure about the wording (“truncated” in
particular). “Integer exponentiation truncated to constant 0”? Why not
“Negative integer exponent has result value zero”?
Other than that, OK to commit.
FX
t a candidate for inclusion in trunk nonetheless.
Bootstrapped and regtested on x86_64-apple-darwin16. OK to commit?
FX
lto_darwin.ChangeLog
Description: Binary data
lto_darwin.diff
Description: Binary data
> We choose mpich as a default only because it is very stable.
Why are why tying ourselves to one MPI implementation?
FX
?
FX
for inclusion in trunk nonetheless.
Bootstrapped and regtested on x86_64-apple-darwin16. OK to commit?
FX
lto_darwin.ChangeLog
Description: Binary data
lto_darwin.diff
Description: Binary data
ve not much experience with EINTR, but is it garanteed that those EINTR
loops will never cycle forever?
Apart from that, OK to commit.
FX
der of
>>>>> m2-m1+m3 is not fixed, I think the statement is not defined whethever
>>>>> (m2-m1), (m1+m3) or (m2-m1)+m3
In the Fortran standard, (m2-m1+m3)/m3 is a mathematical expression, not a
“construct”. So it cannot be “undefined”.
If you have explicit cases where you are asking “is this valid or invalid”
please post them here (fortran@) and we will tell you.
FX
> 2016-07-11 Jerry DeLisle
>
> PR fortran/66310
> * simplify.c (gfc_simplify_repeat): Set max repeat to huge - 1 to allow
> one byte for null terminating the resulting string constant.
OK, thanks
101 - 200 of 633 matches
Mail list logo
