Committed as obvious as Rev. 211806.
Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 211805)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2014-06-18 Tobias Burnus bur...@net-b.de
@@
+2014-06-19 Tobias Burnus bur...@net-b.de
+
+ * trans-intrinsic.c (conv_co_minmaxsum): Fix argument
+ passing.
+
2014-06-18 Tobias Burnus bur...@net-b.de
* gfortran.texi (OpenMP): Update refs to OpenMP 4.0.
Index: gcc/fortran/trans-intrinsic.c
Tobias Burnus wrote:
This patches fixes a few bugs related to CO_MIN/MAX/SUM:
Committed as Rev. 211816.
That patch required also the attached testsuite changes, committed as
Rev. 211833.
Tobias
Index: gcc/testsuite/ChangeLog
Jakub Jelinek wrote:
Bootstrap/regtest pending, does this look ok?
Except for the module/resolved issues discussed elsewhere, it look good
to me.
Thanks!
Tobias
2014-06-20 Jakub Jelinek ja...@redhat.com
* gimplify.c (gimplify_scan_omp_clauses) case OMP_CLAUSE_MAP,
have included those bits of the patch already.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
gcc/fortran/
2014-06-21 Tobias Burnus bur...@net-b.de
* check.c (check_co_minmaxsum): Add definable check.
* expr.c (gfc_check_vardef_context): Fix context == NULL case.
* trans
to the Fortran front end. It is
-maintained by Tobias Burnus
-lt;a href=mailto:bur...@gcc.gnu.orgbur...@gcc.gnu.org/agt;./dd
-
dtfortran-dev/dt
ddThis branch is for disruptive changes to the Fortran front end,
especially for OOP development and
@@ -1178,6 +1173,12 @@ be prefixed
Tobias Burnus bur...@net-b.de
* trans-decl.c (gfc_trans_deferred_vars): Fix handling of
explicit-size arrays with -fcoarray=lib.
gcc/testsuite/
2014-06-23 Tobias Burnus bur...@net-b.de
* gfortran.dg/coarray_32.f90: New.
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index
.
OK for the trunk?
Tobias
gcc/fortran/
2014-06-21 Tobias Burnus bur...@net-b.de
* interface.c (check_intents): Fix diagnostic with
coindexed coarrays.
gcc/testsuite/
2014-06-21 Tobias Burnus bur...@net-b.de
* gfortran.dg/coarray_33.f90: New.
diff --git a/gcc/fortran/interface.c b/gcc
This patch broke bootstrapping for me on x86-64-gnu-linux:
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
i386 architecture of input file `/usr/lib/crti.o' is incompatible with
i386:x86-64 output
If I revert the patch, it works for me.
Tobias
Paul Gortmaker
Jakub Jelinek wrote:
So, either we need something like the following patch (incremental), or
another possibility for the problem is not do the value.function.name
related change in module.c in the UDR patch, and instead fix up the UDR
combiner/initializer expressions when they are loaded from
Steve Kargl wrote:
On FreeBSD (and perhaps other *BSD), there is no fpsetsticky(). The function
is fpresetsticky().
Solaris has fpsetsticky() (requires ieeefp.h) and BSD has
fpresetsticky() – thus, like at other places in that file, one needs to
conditionally enable one or the other.
Bernd Schmidt wrote:
I discovered that create_tmp_var is used in the gfortran frontend to
create static variables. IMO the function is not intended to do this,
and it causes problems for a modification I need to make to it which
assumes that it only creates local variables. So I've made a
.
Also to be done are more type-conversion checks (beyond those which are
implicitly checked by this patch) – and the handling of vector subscripts.
2014-06-29 Tobias Burnus bur...@net-b.de
* resolve.c (resolve_assoc_var): Fix corank setting.
* trans-array.c (gfc_conv_descriptor_token): Change
Hi Bill,
Bill Schmidt wrote:
The test in gfortran.dg/round_4.f90, introduced in GCC 4.9, checks for
correct behavior of different rounding modes. However, for
quad-precision floating-point, it requires that the number
0.100481 be exactly represented. Since
On June 29, 2014, Tobias Burnus wrote:
This patch fixes some issues with polymorphic coarrays. I still have
to fix at least one issue.
Fixed by the patch:
a) The temporary pointer generated with SELECT TYPE has to be a
coarray. That's fixed with the resolve.c patch. The comment is also
===
--- gcc/testsuite/ChangeLog (Revision 212219)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,3 +1,9 @@
+2014-07-02 Tobias Burnus bur...@net-b.de
+
+ * gfortran.dg/coarray/get_array.f90: Add missing SYNC ALL.
+ * gfortran.dg/coarray
Jakub Jelinek wrote:
As the testcase shows, we ICE on old style initialization of derived type
components. ifort also rejects these, I think it doesn't make sense to
support such initializations of derived type components.
Side remark: Cray ftn also rejects it, while PGI's compiler accepts
Hello Kirill,
Kirill Yukhin wrote:
This branch should be capable to perform offload to Intel targets (Xeon PHI)
Which Xeon PHI does it support? Knights Corner, Knights Landing, both?
Tobias
Hello Kirill,
On Wed, Jul 02, 2014 at 04:35:01PM +0400, Kirill Yukhin wrote:
However, GCC (main trunk and this branch) does not support code generation
for KNC
and we don't plan to do that.
Hmm, I had hoped that the work would include the forward porting of HJ's
patches from
Thomas Schwinge wrote:
Reopening this oldie:
index 5fa42f4..68440d18 100644
--- a/libgomp/testsuite/libgomp.fortran/fortran.exp
+++ b/libgomp/testsuite/libgomp.fortran/fortran.exp
@@ -14,6 +14,7 @@ set quadmath_library_path ../libquadmath/.libs
dg-init
if { $blddir != } {
+lappend
Cesar Philippidis wrote:
I couldn't find anything obvious in gcc/fortran/parse.c; is someone
able to have a more in-depth look than I have?
First, some minor point, I think one should crosswise reset the
{openmp,openacc}_flag, i.e.
--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@
Another somewhat early PING**2
On June 29, 2014, Tobias Burnus wrote:
This patch fixes some issues with polymorphic coarrays. I still have
to fix at least one issue.
Fixed by the patch:
a) The temporary pointer generated with SELECT TYPE has to be a
coarray. That's fixed with the resolve.c
Paul Richard Thomas wrote:
This PR is caused by a rather unfortunate cast for the pointer to the
return value from matmul:
[...]
The fix is obvious (ie use its natural kind)
[...]
Dominique points out that the patch fixes PR58883 as well. I'll
enhance the testcase appropriately.
Nice!
Janne Blomqvist wrote:
On Mon, Jul 7, 2014 at 11:29 AM, FX fxcoud...@gmail.com wrote:
PS: I didnât touch libcaf, as I assume this might be compiled with a
different compiler. Am I right?
My understanding is that libcaf is delivered in source form, and the
end user is expected to compile
Cesar Philippidis wrote:
Thomas, is this OK for gomp-4_0-branch?
...
* gcc/fortran/scanner.c (gfc_next_char_literal): Fix the scan for
*$acc.
This changes looks good to me.
* parse.c (next_fixed): Don't handle openmp pragmas when scanning
for openacc pragmas.
with -fcoarray=lib and -lcaf_single.
The patch has been build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2014-07-10 Tobias Burnus bur...@net-b.de
gcc/fortran/
* libgfortran.h (libcaf_atomic_codes): Add.
* trans-decl.c (gfor_fndecl_caf_atomic_def,
gfor_fndecl_caf_atomic_ref
)
@@ -1,5 +1,11 @@
2014-07-12 Tobias Burnus bur...@net-b.de
+ PR fortran/61628
+ * trans-types.c (gfc_init_types): Fix data-type bug
+ with gfc_max_array_element_size.
+
+2014-07-12 Tobias Burnus bur...@net-b.de
+
* libgfortran.h (libcaf_atomic_codes): Add.
* trans-decl.c
===
--- libgomp/ChangeLog (Revision 212489)
+++ libgomp/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2014-07-13 Tobias Burnus bur...@net-b.de
+
+ * testsuite/libgomp.fortran/pr34020.f90: Make compile
+ with TS 18508/Fortran 2015
+
2014-07-06 Marek Polacek pola...@redhat.com
PR c/6940
(Revision 212490)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2014-07-13 Tobias Burnus bur...@net-b.de
+
+ * gfortran.dg/coarray_atomic_4.f90: Avoid using a kind=16
+ integer.
+
2014-07-12 Paul Thomas pa...@gcc.gnu.org
PR fortran/61780
Index: gcc/testsuite/gfortran.dg
for the trunk?
Tobias
2014-06-14 Tobias Burnus bur...@net-b.de
* trans-intrinsic.c (conv_intrinsic_atomic_ref): Fix handling
for kind mismatch with -fcoarray=lib.
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 57b7f4d..3de0b09 100644
--- a/gcc/fortran/trans
C526 plus
C528 still seem to permit integer, save, pointer :: caf[*]. I have now
asked at the J3 mailing list for a pointer to the right constraint. At
least Cray's compiler (correctly?!?) rejects coarrays with pointer
attribute.
Tobias
2014-06-14 Tobias Burnus bur...@net-b.de
gcc/fortran
I have now committed it as obvious.
The constraint, I couldn't find, was/is C546 (thanks to Reinhard Bader).
With coarrays, I tend to have the problem whether the best search term
is coarray or codimension (or sometimes also: coindexed, corank).
Committed as Rev. 212540
Tobias
Tobias
it as obvious
(to the trunk, i.e. GCC 5 alias GCC 4.10 only) once building and
regtesting has finished.
Thanks for reporting the bug – and sorry for the inconvenience.
Tobias
2014-07-25 Tobias Burnus bur...@net-b.de
* simplify.c (gfc_simplify_storage_size): Use proper
integer kind for the returned
Tobias Burnus wrote:
The problem is fixed by the attached patch. I will commit it as
obvious (to the trunk, i.e. GCC 5 alias GCC 4.10 only) once building
and regtesting has finished.
As I only saw later in Steve's email, it is a regression. Thus, I will
also apply it to the GCC 4.9 branch
has been used [extend GNU extension]
- Fix SIZEOF with assumed-rank [fix GNU extension]
- Document that SIZEOF's result are not well defined for noncontiguous
arrays. [fix GNU extension]
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2014-07-26 Tobias Burnus bur...@net-b.de
Dear Paul,
Paul Richard Thomas wrote:
Whilst I am aware that we can now use the single line C++ comment,
would it perhaps be a better idea to stick with the C style comments
just for uniformity?
Okay.
+ if (arg-ts.type == BT_CLASS)
+{
+ tmp = gfc_vtable_size_get (TREE_OPERAND
Tobias Burnus wrote:
Assuming that the second part is okay, I have now committed it with
the comment-style change as Rev. 213079.
Dominique has pointed out (thanks!) that the patch fixed PR57305 - and
reading that PR, I saw that I missed the declared - dynamic type
change. Hence, I have
on the language, the technical description and on the API
itself are welcome.
Tobias
2014-07-27 Tobias Burnus bur...@net-b.de
* gfortran.texi (Coarray Programming): Add first ABI
documentation.
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 66e78e8..5f6bf5d 100644
components of coarrays; co_reduce and co_broadcast
Tobias
2014-07-28 Tobias Burnus bur...@net-b.de
* gfortran.texi (caf_register_t): Add CAF_REGTYPE_CRITICAL.
(_gfortran_caf_register): Update for locking/critical.
(_gfortran_caf_lock, _gfortran_caf_unlock): Add.
* resolve.c (resolve_critical
This patch adds the files gcc-5/{changes,criteria}.html - and populates
the former with Fortran changes; the latter is a copy of the GCC 4.9 file.
Is the patch OK?
Tobias
gcc-5/changes.html | 60 +
gcc-5/criteria.html | 144
the attached patch does. I
intent to commit it tomorrow as obvious, if there are no objections.
Tobias
2014-11-11 Tobias Burnus bur...@net-b.de
contrib/
* download_prerequisites: Stop downloading CLooG.
gcc/
* doc/install.texi (Prerequisites): Remove CLooG.
diff --git a/contrib
Cesar Philippidis wrote:
This patch adds support for OpenACC 2.0a, with some omissions, to the
fortran front end. It only contains the fortran changes from
gomp-4_0-branch, therefore the middle end and runtime changes are a
necessary prerequisite for this patch.
I'd assume that one could
Cesar Philippidis wrote:
This patch contains compile-time tests for OpenACC in gfortran. Is this
patch OK for mainline trunk after the OpenACC fortran front end changes
make their way in?
I browsed the test cases – and they look okay. I didn't try hard to see
whether every single one is valid
for gcc.dg/graphite/vect-pr43423.c, but that seems to be
independent as I see it also with the yesterday's GCC; for Sparc/arm/aarch64,
it's PR62630.]
Tobias
2014-11-11 Tobias Burnus bur...@net-b.de
* config/cloog.m4: Remove.
* Makefile.def: Remove CLooG.
* Makefile.tpl
Ilya Verbin wrote:
On 11 Nov 08:10, Jakub Jelinek wrote:
For the middle-end and libgomp changes, can you talk to the Intel folks to
update their git branch to latest trunk (so that you have the nvptx bits in
there) and send middle-end and libgomp diffs against that?
As far as I
On Tue, Nov 11, 2014 at 02:01:47PM +0100, Tobias Burnus wrote:
Now that CLooG is no longer used by GCC, it makes sense to also remove it from
the main configure file. Especially as the in-tree build currently only works
if also CLooG is available.
I saw that there were still some traces
Hi all, hi Gerald, hi Tobias and Roman,
the patch updates gcc-5/changes.html; the Fortran bits are obvious.
For CLooG:
* That CLooG is no longer needed is the main reason for writing this
Caveat item.
* Regarding ISL 0.12.2: The recommended version already changed
2014-02-13 and thus for
Tobias Burnus wrote:
Now that CLooG is no longer used by GCC, it makes sense to also remove it from
the main configure file. Especially as the in-tree build currently only works
if also CLooG is available.
Turned out that I missed a dependency. One previously had all-gcc -
depends on all
Jakub Jelinek wrote:
-* libgomp: (libgomp).GNU OpenMP runtime library
+* libgomp: (libgomp).GNU OpenACC and OpenMP runtime
library
@end direntry
See Dave Malcolm's patch, please integrate it into your patchset.
Namely,
Hi all,
since everyone seems to agree that it makes in principle sense to have a
reduce libgfortran (even though a full one is nicer, if the system
permits), let's look at the patch itself ;-)
Bernd Schmidt wrote:
The ptx port by its nature is lacking features that are expected on
normal
Am 14.11.2014 um 16:56 schrieb Thomas Schwinge:
Hi!
On Wed, 12 Nov 2014 11:06:26 +0100, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 11, 2014 at 01:53:23PM +, Julian Brown wrote:
[OpenACC libgomp changes][openacc.f90, and exporting symbols in libgomp.map]
Somebody recently
Cesar Philippidis wrote:
On 11/13/2014 02:32 AM, Janne Blomqvist wrote:
I hit an error when building intrinsics/random.c:
error: expression in static assertion is not constant
Joseph told me that static const variables cannot be used in constant
expressions in C, so I've replaced the
Hi Tobias,
Bernd Schmidt wrote:
Does printf work? I thought I/O is not supported? Or does it just accept
it for linking and drop it? I think Janne's patch has already dealt with
the issue of stack allocation.
printf (or more accurately vprintf) is supported by ptx as a magic
builtin
gfc_intrinsic_error and the remaining gfc_{error,warning}_now
(all which do not use %L).
PPS: Turning on colors comes too late for the command-line diagnostic -
they always come up in blank and white.
[1] See https://gcc.gnu.org/gcc-5/changes.html under Fortran and under
C family.
2014-11-15 Tobias Burnus
FX wrote:
Please document, in the source, the difference between gfc_fatal_error
and gfc_fatal_error_1. They currently have the same generic
description, which wouldn’t help people writing new front-end code to
know which one to use. Moreover, if the transition will not be
complete soon (or
Alessandro Fanfarillo wrote:
The sum of the three indexes, k, j and i returns a wrong image index.
Fixed as confirmed off list by the attached patch.
I intent to commit it as obvious once building and regtesting has
finally finished.
Comments are nontheless welcome.
Tobias
* trans-expr.c
(minus re-indenting) and once with re-indenting.
OK for the trunk?
Tobias
gcc/
2014-11-22 Tobias Burnus net-b.de
* optc-gen.awk: Support || in EnabledBy.
diff --git a/gcc/optc-gen.awk b/gcc/optc-gen.awk
index ecb225c..0707db2 100644
--- a/gcc/optc-gen.awk
+++ b/gcc/optc-gen.awk
@@ -25,63
On 19 November 2014 at 23:20, Tobias Burnus wrote:
Alessandro Fanfarillo wrote:
The sum of the three indexes, k, j and i returns a wrong image index.
Fixed as confirmed off list by the attached patch.
I intent to commit it as obvious once building and regtesting has
finally finished
Tobias Burnus bur...@net-b.de
Manuel López-Ibáñez m...@gcc.gnu.org
gcc/fortran/
* gfortran.h (gfc_option_t): Remove warn_tabs.
* lang.opt (Wpedantic): Add.
(Wtabs): Use Var and LangEnabledBy.
* options.c (gfc_init_options, gfc_post_options,
set_Wall): Remove -Wtabs handling
FX wrote:
OK. One question: I don’t understand why you need two separate Wtabs
lines in lang.opt.
Thanks for the review!
Because EnabledByLanguage(Fortran,Wall || Wpedantic) isn't supported –
using two separate Wtabs is the work around.
Cf.
Manuel López-Ibáñez wrote:
Exactly what the subject says. I'm not sure if this is appropriate for
stage3, I'll leave that to the Fortran maintainers.
Bootstrapped regression tested on x86_64-linux-gnu.
Looks good to me - and is a rather simple patch.
Thanks!
Tobias
gcc/fortran/ChangeLog:
This patch depends on Manuel's %L patch.
It converts the remaining fatal error calls to the common diagnostic
infrastructure and retires (removes) the old gfc_fatal_error_1.
I will build and regtest it after Manuel's commit.
OK, when it succeeds?
Tobias
2014-11-23 Tobias Burnus bur...@net
with checking that the resulting options.c
remains the same.
OK for the trunk?
Tobias
2014-11-23 Tobias Burnus bur...@net-b.de
Manuel López-Ibáñez m...@gcc.gnu.org
gcc/c-family/
* c.opt (Wdelete-non-virtual-dtor, Wenum-compare, Wnarrowing,
Wpointer-sign, Wvariadic-macros): Combine
)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,4 +1,9 @@
2014-11-23 Tobias Burnus bur...@net-b.de
+
+ * error.c (gfc_diagnostic_build_prefix): Correct coloring
+ of the colon of the prefix.
+
+2014-11-23 Tobias Burnus bur...@net-b.de
Manuel López-Ibáñez m...@gcc.gnu.org
Fix -Wtabs description, matching current implementation. Committed as
Rev. 217990.
Tobias
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index 12ec7e2..41169a8 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,5 +1,10 @@
2014-11-23 Tobias Burnus bur...@net-b.de
/gfortran.dg/dollar_sym_3.f
+++ b/gcc/testsuite/gfortran.dg/dollar_sym_3.f
@@ -10,0 +11 @@ c Segmentation fault in gfc_restore_last_undo_checkpoint
+! { dg-excess-errors compilation terminated }
2014-11-24 Tobias Burnus bur...@net-b.de
* error.c: Update comments.
(gfc_internal_error): Convert to common
Tobias Burnus wrote:
It converts the remaining fatal error calls to the common diagnostic
infrastructure and retires (removes) the old gfc_fatal_error_1.
I will build and regtest it after Manuel's commit.
OK, when it succeeds?
The patch needed additionally a '...' added in two test-suite
With this patch – and the still pending patch for gfc_internal_error at
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03003.html – all
error/warning messages have been converted to the common diagnostic,
except for:
(a) those majority which might need buffering (gfc_error, gfc_warning);
(b)
FX:
(a) those majority which might need buffering (gfc_error, gfc_warning);
Is there a plan for those in the longer term?
Well, the long-term solution is of course to support them. That requires
adding buffering+discarding support to the common machinery and to use
it then in gfortran. It's
if some others could run additional tests.
PPS: If the patch is in, can someone put ISL 0.14 to infrastructure? Then
one can update contrib/download_prerequisites - such that the graphite
failure is at least fixed for in-tree builds (cf. PR64017, PR62289).
2014-11-26 Tobias Burnus bur...@net-b.de
On Wed, Nov 26, 2014 at 04:55:40PM +0100, Tobias Burnus wrote:
This patch adds a configure check for
isl_schedule_constraints_compute_schedule,
which is new in ISL 0.13 - and uses it for conditional compilation.
Repeating the test on a massively multicore system, it fails at stage2
Hi Manuel,
Manuel López-Ibáñez wrote:
I think the changes to the common diagnostics part could be as simple as:
Good – that's simpler than I had feared.
However, I'm less familiar with the Fortran buffering mechanism.
I am not sure you find someone who really is. At least I also have
Manuel López-Ibáñez wrote:
* Fortran devs: Is this approach acceptable? The main idea is to have
an output_buffer called pp_warning_buffer with the flush_p bit unset
if we are buffering. When printing buffered warnings, use this
output_buffer in the global_dc-printer instead of the (unbuffered
Manuel López-Ibáñez wrote:
Oh, I didn't notice that the _now versions override the buffered
messages. Where do you see that?
I think I messed up a bit - they do not seem to get cleared. I was
reading gfc_error_now_1, which has:
error_buffer.flag = 1;
error_buffer.index = 0;
Manuel López-Ibáñez wrote:
On 27 November 2014 at 23:58, Tobias Burnus bur...@net-b.de wrote:
Hmm, theoretically, it would be possible. However, my feeling is that there
is no such case. What would be needed is something which is ambiguous, the
compiler assumes first the wrong kind of statement
Hi FX,
FX wrote:
When I added support for nondefault initial character kinds, I thought they
could be assigned freely to each other. It turns out it’s not the case:
Am am vaguely remembering that some interpretation request/change now
allows this.
And if I look at the current Fortran 2015
Dominique Dhumieres wrote:
The failures for the gfortran.dg/coarray_collectives_9.f90 are fixed
with the following patch:
Looks good to me. The patch is OK with a ChangLog.
Thanks for the patch and sorry for the test fails.
Tobias
On Mon, Sep 29, 2014 at 10:17:04AM +0200, Tobias Burnus wrote:
Dominique Dhumieres wrote:
The failures for the gfortran.dg/coarray_collectives_9.f90 are fixed
with the following patch:
Looks good to me. The patch is OK with a ChangLog.
Actually, I missed the following part:
...
- call
FX wrote:
Now, here's a tiny patch to silence the related warning in PR36534.
I also remove the condition on gfc_current_form != FORM_FIXED, as diagnostics
should be emitted based on language/pedantic options, not source form.
Looks good to me. However:
In the test case, could you also add a
is IMPLICIT implicit-spec-list
or IMPLICIT NONE [ ( [ implicit-none-spec-list ] ) ]
R566 implicit-none-spec is EXTERNAL
or TYPE
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2014-10-02 Tobias Burnus bur...@net-b.de
gcc
Tobias Burnus wrote:
IMPLICIT NONE (external)
While I have implemented is as vendor extension (-std=gnu)
Ups, I forgot to include the gcc/fortran/libgfortran.h change in the
patch. See updated attachment.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2014-10-02
FX wrote:
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”?
Well, I want to distinguish IMPLICIT NONE (external) which only
applies to
Hi Marek, hi all,
Tobias Burnus:
Seems that gcc/fortran/libgfortran.h part is not committed, after
r215914 I get
gcc/fortran/decl.c:2960:28: error: âGFC_STD_F2015â was not declared in this
scope
Committing patches when having a cold doesn't seem to work. I don't have
access to the computer
, I have modified the code to
provide a better error message.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2014-10-09 Tobias Burnus bur...@net-b.de
gcc/fortran/
* gfortran.h (gfc_set_implicit_none):
Update prototype.
* symbol.c (gfc_set_implicit_none): Take and
use
FX wrote:
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
[...]
We have a -static-libgfortran option, but on targets where we support
quad-prec math through
Manuel López-Ibáñez wrote:
This patch is mostly cleanups, sorry for the churn. The next one will
be far more interesting.
Bootregtested on x86_64-linux-gnu.
OK?
Looks good to me. Thanks!
Tobias
gcc/fortran/ChangeLog:
2014-10-16 Manuel López-Ibáñez m...@gcc.gnu.org
PR fortran/44054
Manuel López-Ibáñez wrote:
This patch adds handling of Fortran %C using the common diagnostics
machinery. This is achieved by dynamically generating a location given
a location and an offset. This only works for non-macro line-maps (for
now), but this is OK since Fortran does not have virtual
Hi FX,
FX wrote:
After the compile-time simplification, this patch fixes the handling of
special values
(infinities and NaNs) by intrinsics EXPONENT, FRACTION, SPACING, RRSPACING
SET_EXPONENT
Bootstrapped and regtested on x86_64-linux.
OK to commit?
Looks good to me. Thanks for taking
are allocatable components and
finalization – the latter also still has to be addressed in the standard
itself.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2014-10-20 Tobias Burnus bur...@net-b.de
gcc/fortran
* check.c (check_co_collective): Reject coindexed A args
Hi Ilmir,
Ilmir Usmanov wrote:
For DO CONCURRENT, it is not.
I always forget about this kind of loops.
And I tend to forget about the issues with mask as I don't use do
concurrent with mask.
* And do concurrent also supports masks:
logical :: my_mask(3)
integer :: i, b(3)
b(i) = [5, 5,
Paolo Bonzini wrote:
Il 11/03/2014 07:42, Tobias Burnus ha scritto:
+XPCFLAGS=
+CFLAGS=$CFLAGS -pthread
+AC_LINK_IFELSE(
...
+ [XPCFLAGS= -Wc,-pthread],
XPCFLAGS is dead, I think?
Yes - contrary to libgomp, from which I have taken that code block. I
have now removed it.
Also, should
Thomas Koenig wrote:
Hello world,
print *, 'Hello Thomas'
the attached patch fixes the regression (after some thought
of what might still be optimized, which isn't much :-)
Regression-tested. OK for trunk?
Looks good to me. (I wonder whether one should also include Mikael's
test case,
Steve Kargl wrote:
On Wed, Mar 26, 2014 at 06:56:15PM +0100, Dominique Dhumieres wrote:
Updated patch. OK to commit?
OK.
I have a minor nit: can you add a @code{} around the second VOLATILE?
+Some Fortran compilers, including @command{g77}, let the user declare
+@code{COMMON} with the
H.J. Lu wrote:
All cilk-plus link tests failed with
xgcc: error: libcilkrts.spec: No such file or directory
Don't you need to add -B/libcilkrts for this?
Hmm, I really wonder why it fails for you while it works for me:
Running
Rainer Orth wrote:
Tobias Burnus bur...@net-b.de writes:
H.J. Lu wrote:
xgcc: error: libcilkrts.spec: No such file or directory
Hmm, I really wonder why it fails for you while it works for me:
Do you happen to have the same/a recent version installed at the same
prefix your build under test
An early * PING* for this wrong-code issue.
Tobias Burnus wrote:
This patch fixes part of the problems of the PR. The problem is that
one assigns an array descriptor to an assumed-rank array descriptor.
The latter has for BT_CLASS the size of max_dim (reason: we have first
the data array
* PING*
Tobias Burnus wrote:
Hi all,
this patch fixes a problem with the conversion of scalars to
descriptors. There one assigns the address of the scalar to the
base_address field of the descriptor. The ICE occurred when the RHS
(the scalar) wasn't a pointer.
It does not fully solve
/ChangeLog.fortran-caf (Revision 208886)
+++ gcc/fortran/ChangeLog.fortran-caf (Arbeitskopie)
@@ -1,3 +1,10 @@
+2014-03-28 Tobias Burnus bur...@net-b.de
+
+ * trans-intrinsic.c (caf_get_image_index, conv_caf_send): New.
+ (gfc_conv_intrinsic_subroutine): Call it.
+ * resolve.c (resolve_ordinary_assign): Enable
/fortran/ChangeLog.fortran-caf (Revision 208918)
+++ gcc/fortran/ChangeLog.fortran-caf (Arbeitskopie)
@@ -1,5 +1,9 @@
2014-03-28 Tobias Burnus bur...@net-b.de
+ * trans-intrinsic.c (conv_caf_send): Fix offset calculation.
+
+2014-03-28 Tobias Burnus bur...@net-b.de
+
* trans-intrinsic.c
is a warning-removal patch.
OK for the trunk?
Regarding invoke.texi: It had (nearly) the same @menu twice, once under
@chapter where it belongs to and once under a @section where it doesn't.
Tobias
2014-03-29 Tobias Burnus bur...@net-b.de
PR other/59055
* doc/bugreport.texi (Bugs): Remove nodes
1 - 100 of 3305 matches
Mail list logo
