Mikael Morin mik...@gcc.gnu.org
Tobias Burnus bur...@net-b.de
PR fortran/50981
* trans-array.c (gfc_walk_elemental_function_args): Fix
passing of deallocated allocatables/pointers as absent argument.
2012-01-16 Mikael Morin mik...@gcc.gnu.org
Tobias Burnus bur...@net-b.de
PR
to
debug the issue as it can only affect __vtab/__def_init.
Thus, I decided to backout the patch Rev. 181199 (cf. PR, comment 1) -
and implement a simple TREE_READONLY in trans-decl.c.
Build and regtested on x86-64-linux.
OK for the 4.7 trunk?
Tobias
2012-01-16 Tobias Burnus bur...@net-b.de
This patch nullifies (scalar) allocatables after malloc, if (and only
if) they contain allocatable components to make sure that no
uninitialized memory is accessed.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-01-17 Tobias Burnus bur...@net-b.de
PR fortran/51869
On 01/17/2012 01:25 PM, Paul Richard Thomas wrote:
The attached is self-explanatory and fixes the last wrinkles with
PR51634. In addition, the patch incorporates the requirements of class
expressions being used throughout, as reflected in the second
testcase.
Bootstrapped and regtested on
Dear Janne, dear Paul,
thanks for the review - and for the f95-lang.c patch. I have updated the
patch to use calloc, build regtested it, and committed it as Rev. 183247.
Tobias
2012-01-17 Tobias Burnus bur...@net-b.de
Janne Blomqvist j...@gcc.gnu.org
PR fortran/51869
Steve Kargl wrote:
The attached patch documents the new Fortran options
-freal-N-real-M and -finteger-4-integer-8. These
options are used for promoting all entities of the
first type to entities of the second type.
OK to commit?
Looks OK to me. Though, I had made the N and M italic at:
to Kai for some advice - he also stated that the patch looks okay.
Bootstrapped on x86-64-linux, but not (yet) tested on MinGW/MinGW64
OK for the trunk?
Tobias
2012-01-19 Tobias Burnus bur...@net-b.de
PR libgfortran/51899
* configure.ac: Check whether umask is available.
* intrinsics
Tobias Burnus wrote:
Bootstrapped on x86-64-linux, but not (yet) tested on MinGW/MinGW64
OK for the trunk?
MinGW64 was successful - thanks to Brad for testing it and for updating
the version, which is linked from the wiki.
Tobias
Seemingly, resolve and friends are confused if there is no symtree -
thus set it.
Build and regtested on x86-64-linux.
OK for the trunk and the 4.6 branch? (It's a regression.)
Tobias
2012-01-19 Tobias Burnus bur...@net-b.de
PR fortran/51904
*expr.c (gfc_build_intrinsic_call): Also set
DJ Delorie wrote:
I have no problems running make pdf in libiberty.
texi2dvi (GNU Texinfo 4.13) 1.135
That's odd. I have exactly the same version and I get the following TeX
error.
Tobias
texi2pdf /home/tob/projects/gcc-git/gcc/libiberty/libiberty.texi
This is pdfTeX, Version
-Wall was warning about explicitly imported but not used __vtab,
__def_init etc. variables.
Build and regtested on x86-64-linux
OK for the trunk?
Tobias
2012-01-20 Tobias Burnus bur...@net-b.de
Janus Weil ja...@gcc.gnu.org
PR fortran/51056
* module.c (load_needed, read_module
==
formal-ts.u.derived-name). However, that will lead to surprising error
messages - such as that the type does not match while only an
allocatable is missing. (Check ordering issue; cf. class_dummy_3.f03.)
Tobias
2012-01-21 Tobias Burnus bur...@net-b.de
PR fortran/51913
* interface.c
?
Tobias
2012-01-22 Tobias Burnus bur...@net-b.de
PR fortran/41600
* expr.c (gfc_default_initializer): Convert the values if
the type does not match.
2012-01-22 Tobias Burnus bur...@net-b.de
PR fortran/41600
* gfortran.dg/default_initialization_6.f90: New.
diff --git a/gcc/fortran/expr.c
Tobias Burnus wrote:
the middle end does not like to fold_convert a real number to an
integer, but gfortran does not type-convert the expressions of
initialization expressions. This patch fixes the issue
And Tobias Schlüter wrote in the PR:
(In reply to comment #3)
+ if (comp
Dear Paul,
Paul Richard Thomas wrote:
The attached is quite straightforward - for non-variable class STATUS
expressions,
I believe that you mean source-expr (i.e. SOURCE= and MOLD=) and not STATUS.
Note that I have begged off including variables in this process, given
the stage that we are
Tobias Burnus bur...@net-b.de
PR fortran/51948
* check.c (variable_check): Fix checking for
result variables and deeply nested BLOCKs.
2012-01-23 Tobias Burnus bur...@net-b.de
PR fortran/51948
* gfortran.dg/move_alloc_12.f90: New.
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
will commit it tomorrow,
unless I get an OK today or someone finds a reason why the patch is not
the best solution.
2012-01-24 Tobias Burnus bur...@net-b.de
PR fortran/51966
* resolve.c (resolve_structure_cons): Only create an
array constructors for nonscalars.
2012-01-24 Tobias Burnus bur
patch at http://gcc.gnu.org/ml/fortran/2012-01/msg00197.html
2012-01-25 Tobias Burnus bur...@net-b.de
PR fortran/51995
* class.c (gfc_build_class_symbol): Ensure that
fclass-f2k_derived is set.
2012-01-25 Tobias Burnus bur...@net-b.de
PR fortran/51995
* gfortran.dg/typebound_proc_25.f90
Dear all, dear Paul,
Dominique pointed out that the patch does not fully work and that one
gets an ICE:
internal compiler error: in gfc_release_symbol, at fortran/symbol.c:2531
For some odd reason, it didn't occur for my build, which had some
unrelated patch applied. I have not understood
Steve Kargl wrote:
On Wed, Jan 25, 2012 at 09:27:51PM +0100, Tobias Burnus wrote:
I will commit it as obvious after it regtesting it.
JFYI, the patch fixes the ICE.
Yes, it does - and it also regtested. I committed it as Rev. 183541.
Tobias
This patch fixes expressions involving polymorphic arrays and, thus,
MOVE_ALLOC.
I have also two minor fixes (cf. trans-decl.c).
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-01-26 Tobias Burnus bur...@net-b.de
PR fortran/51970
PR fortran/51977
* primary.c
and the remaining actual arguments shall be
conformable with them.
Build and currently regtesting on x86-64-linux.
OK for the trunk?
Tobias
2012-01-27 Tobias Burnus bur...@net-b.de
* resolve.c (resolve_formal_arglist): Fix elemental
constraint checks for polymorphic dummies.
2012-01-27 Tobias
(working copy)
@@ -1,5 +1,12 @@
2012-01-27 Tobias Burnus bur...@net-b.de
+ PR fortran/52016
+ * resolve.c (resolve_formal_arglist): Fix elemental
+ constraint checks for polymorphic dummies also for
+ pointers.
+
+2012-01-27 Tobias Burnus bur...@net-b.de
+
PR fortran/51970
PR fortran/51977
Dear all,
I have committed the attached patch as obvious (Rev. 183643) after
building and regtesting. I intent to backport it to 4.5 and 4.6.
Tobias
2012-01-27 Tobias Burnus bur...@net-b.de
PR fortran/52022
* trans-expr.c (gfc_conv_procedure_call): Fix passing
of functions, which
.
For a generic function, those are ambiguous as generic_name(t=x, i=5)
will match both functions.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-01-28 Tobias Burnus bur...@net-b.de
PR fortran/52024
* gfortran.h (gfc_tbp_generic): Store whether the
generic is an operator
* ping *
http://gcc.gnu.org/ml/fortran/2012-01/msg00197.html
On 22 January 2012, Tobias Burnus wrote:
Dear all,
the middle end does not like to fold_convert a real number to an
integer, but gfortran does not type-convert the expressions of
initialization expressions. This patch fixes
not solve all issues of the PR as there is also a
bug in _copy, which does only an incomplete deep copy. For details and a
possible solution see PR.
Tobias
2012-01-28 Tobias Burnus bur...@net-b.de
PR fortran/51972
* trans-stmt.c (gfc_trans_allocate): Properly check whether
we have a BT_CLASS
The patch fixes a build error. The function was accidentally added Rev.
183620 of 2012-01-27 for PR 52016.
The function is part of the (uncommitted) draft patch for PR 50981.
Committed as Rev. 183675.
Tobias
I forgot to attach the committed patch ...
Tobias Burnus wrote:
The patch fixes a build error. The function was accidentally added
Rev. 183620 of 2012-01-27 for PR 52016.
The function is part of the (uncommitted) draft patch for PR 50981.
Committed as Rev. 183675.
Tobias
Index: ChangeLog
Dear Paul,
thanks for the review!
I cry foul at this point :-) I have gone gallivanting off to try to
fix really horrid regressions like 52012, whilst you are have fun
doing interesting things.
Well, that way my revenge for not getting a review for my
default-initializer patch since
Janne Blomqvist wrote:
Have you tried r183679, which should fix this?
Aha, I missed the follow up patch - that explains why I didn't see it.
While I can speak only for myself, regtesting on x86_64-unknown-linux-gnu. For
some reason this was/is flagged as a warning for me, not an error, so I
Hello Thomas,
I didn't know that you are now also fixing libmudflap problems and
that you work on Some malloc'd inside libc is not being tracked.
Or did you intent to write PR fortran/51958 rather than
PR libmudflap/51858?
Changing else if into else; if ... endif; endif matches what
we already
time, I fixes the hash
function criterion. Since the polymorphic array patch, one some long
module + type names were cropped instead of triggering the hash
mechanism, increasing the chance for name collision.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-01-30 Tobias Burnus
Dear Paul,
thanks for fixing the offset calculation.
Regarding:
If variable is an allocated allocatable variable, it is deallocated if
expr is an array of different shape or any of the corresponding length
type parameter values of variable and expr differ. If variable is or
becomes an
-01-31 Tobias Burnus
PR fortran/52059
* trans-expr.c (gfc_conv_procedure_call): Add array ref
only to variables.
2012-01-31 Tobias Burnus
PR fortran/52059
* gfortran.dg/elemental_function_1.f90: New.
Index: gcc/fortran/trans-expr.c
(and
it compiles with NAG 5.1), but it is rejected with GCC 4.6 and 4.7.
Thus, I will keep the PR open such that we can deal with that issue later.
Build and regtested on x86-64.
OK for the trunk?
Tobias
2012-01-31 Tobias Burnus bur...@net-b.de
PR fortran/52024
* module.c (MOD_VERSION): Bump
Tobias Burnus wrote:
Unfortunately, it turns out that the check does not handle inheritance
well. At least I would expect that the attached test case is valid
(and it compiles with NAG 5.1), but it is rejected with GCC 4.6 and 4.7.
Actually, I withdraw that comment. I now believe that gt_cmp
Dear Paul,
Paul Richard Thomas wrote:
Following our exchanges with Dominique, I think that the attached
patch will have to do for now.
Bootstrapped and regtested on FC9/x86_64 - OK for trunk?
The patch looks fine. Thanks. Can you also back-port to 4.6?
Tobias
2012-02-02 Paul
Dear all,
I have committed the attached patch as obvious (Rev.183848) - after
building and regtesting on x86-64-linux.
I intent to backport it to 4.6 soon. (It's a regression.)
Tobias
2012-02-02 Tobias Burnus bur...@net-b.de
PR fortran/52093
* simplify.c (gfc_simplify_size): Handle
%a)) call abort ()
end subroutine test4
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (Revision 183903)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2012-02-05 Tobias Burnus bur...@net-b.de
+
+ PR
Dear Thomas, dear all,
Thomas Koenig wrote:
the attached patch avoids checks for reallocation on assignment when
the same variable is on both sides of the assignment.
Regression-tested. OK for trunk?
OK and thanks for the patch. (Can you remove the trailing spaces in the
line the first
Thomas Koenig wrote:
the attached patch rejects impure subroutines, such as RANDOM_NUMBER,
within DO CONCURRENT.
Regression-tested. OK for trunk?
Okay - and thanks for the patch. Unrelated to changes in your patch, I
am a bit unhappy about:
* Proliferation of global variables
* Magic
Thomas Koenig wrote:
+Unformatted sequential files are stored using record markers. Each
+full record consists of a leading record marker, the data written
+by the user program, and a trailing record marker. The record markers
+are four-byte integers by default, and eight-byte integers if the
Am 27.08.2013 15:09, schrieb Janus Weil:
here is a patch for PR 55603, which plugs a memory leak with scalar
allocatable function results.
To accomplish this, several things are done:
1) Allocatable scalar function results are passed as argument now and
returned by reference (just like array or
Committed as obvious, Rev. 202416
Tobias
Index: ChangeLog
===
--- ChangeLog (Revision 202415)
+++ ChangeLog (Arbeitskopie)
@@ -1,3 +1,7 @@
+2013-09-09 Tobias Burnus bur...@net-b.de
+
+ * invoke.texi (Error and Warning Options
with
ForTrilinos.
2013-09-10 Tobias Burnus bur...@net-b.de
PR fortran/57697
* resolve.c (generate_component_assignments): Handle unallocated
LHS with defined assignment of components.
2013-09-10 Tobias Burnus bur...@net-b.de
PR fortran/57697
* gfortran.dg/defined_assignment_10.f90: New.
diff --git
Adam Butcher wrote:
From: abutcher abutcher@138bc75d-0d04-0410-961f-82ee72b054a4
* lambda.c (lambda_function): Return template result if call operator is
a template.
I believe that that patch causes the following build failure of cp/lambda.c:
In file included from
A rather obvious patch.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-09-15 Tobias Burnus bur...@net-b.de
PR fortran/58356
* class.c (generate_finalization_wrapper): Init proc_tree if
not yet resolved.
2013-09-15 Tobias Burnus bur...@net-b.de
PR fortran/58356
Now with attachment…
Tobias Burnus wrote:
Fortran 2008 permits assignment to polymorphic variables with some
constraints. The patch, which was sitting in my tree, adds diagnostic
to reject invalid use. For valid code, it runs into the existing
not-yet-implemented error.
Build + regtested
/msg00025.html
Locally, it works as I BCC'ed myself to the emails.
---BeginMessage---
---BeginMessage---
Re-sent as it didn't show up in the archive. (I wonder why this and
another email didn't made it, but the follow-up to that email did.)
Tobias Burnus wrote:
Hi Thomas, hello all
Thomas Koenig wrote:
Build and regtested on x86-64-gnu-linux.
OK?
The patch is OK, also for 4.8. Please add a test case which also
checks for the ForTrilinos failure.
Thanks for the review. I have now committed the current patch as Rev.
202609.
I will later try to create a test case,
There were two related issues with the _vtab of CLASS(*): First, it was
crashing in the generation of the finalization wrapper. Secondly, one
needs to ensure that the _vtab contains a NULL pointer for _final.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
I forgot, again, to attach the patch.
However, to my surprise the email made it through. Contrary to Janus'
second patch review of today which didn't went past GCC's mail server.
(The same problem I had yesterday: Three emails didn't make it.)
Tobias Burnus wrote:
There were two related
Janus Weil wrote:
(The same problem I had yesterday: Three emails didn't make it.)
Any idea what's the reason for this?
No idea. Usually, one gets a bounce message but this time one didn't.
Thus, I have no possibility to debug this from my side. #overseers
didn't see it as their business
that patch to 4.8.]
Tobias
2013-09-15 Tobias Burnus bur...@net-b.de
PR fortran/43366
* primary.c (gfc_variable_attr): Also handle codimension.
* resolve.c (resolve_ordinary_assign): Add invalid-diagnostic for
polymorphic assignment.
2013-09-15 Tobias Burnus bur...@net-b.de
PR fortran/43366
Committed as obvious, Rev. 202722.
Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 202713)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,5 +1,9 @@
2013-09-18 Tobias Burnus bur...@net-b.de
+ * expr.c
===
--- gcc/testsuite/ChangeLog (Revision 202724)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2013-09-18 Tobias Burnus bur...@net-b.de
+
+ PR fortran/57697
+ * gfortran.dg/defined_assignment_11.f90: New.
+
2013-09-18 Vladimir Makarov vmaka
is wrong.
2013-09-19 Tobias Burnus bur...@net-b.de
PR fortran/57697
PR fortran/58469
* resolve.c (generate_component_assignments): Avoid double free
at runtime and freeing a still-being used expr.
2013-09-19 Tobias Burnus bur...@net-b.de
PR fortran/57697
PR fortran/58469
* gfortran.dg
Hi Janus, hi all,
On August 15, 2013, Janus Weil wrote:
Hi Mikael,
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
This looks good to me
but I let Tobias have the final word as he
expressed some concerns in the PR audit trail.
Sorry for the very belated replay. I played with the
*PING* http://gcc.gnu.org/ml/fortran/2013-09/msg00031.html
(Additional early ping for:
http://gcc.gnu.org/ml/fortran/2013-09/msg00039.html )
On September 16, 2013 22:18, Tobias Burnus wrote:
I forgot, again, to attach the patch.
However, to my surprise the email made it through. Contrary
Tom Tromey wrote:
This convert fortran.
Looks good to me, but I am not really a built-system expert. Hence, I
wouldn't mind if also Paolo glances at the patch …
Thanks for the nice patch series!
Tobias
It renames gfortranspec.o to fortran/gfortranspec.o, for uniformity
and to allow
I have merged the trunk into the branch; committed as Rev. 202840
Tobias
* PING * http://gcc.gnu.org/ml/fortran/2013-09/msg00039.html
Additionally pinging for:
http://gcc.gnu.org/ml/fortran/2013-09/msg00031.html
On September 19, 2013 21:11, Tobias Burnus wrote:
This patch fixes two issues:
a) It could happen that no code change has happened. In that case
Bernd Edlinger wrote:
this test case fails very often, and the reason is not in GCC but
in a missing glibc rounding support for strtod.
This patch fixes the test case, to first determine if the
rounding support is available. This is often the case for real(16)
thru the libquadmath. So even in
I have committed the patch after Janne's approval on IRC and fresh
building/regtesting as Rev. 203086. See
http://gcc.gnu.org/ml/fortran/2012-11/msg00092.html
As suggested by Janne, I will backport it to 4.8 in in a bunch of days.
Tobias
On November 29, 2012 12:38, Tobias Burnus wrote
/ChangeLog (Revision 203085)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,9 @@
+2013-10-01 Tobias Burnus bur...@net-b.de
+
+ PR fortran/58579
+ * trans-expr.c (gfc_conv_string_tmp): Correctly obtain
+ the byte size of a single character.
+
2013-09-27 Janne Blomqvist j...@gcc.gnu.org
Richard Biener wrote:
This adds recognition of [sd]axpy and [sd]dot computing partitions
to loop distribution (as an example for a moderately complex kernel
and one kernel involving a reduction).
To make this a reality we have to control this by an option
(-fblas?) and we have to settle to
This patch (rev. 203118) seems to break bootstrapping with Graphite:
g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros
Tobias Burnus wrote:
In gfc_conv_string_tmp, gfortran allocates temporary strings. However,
using TYPE_SIZE (type) didn't yield one byte as intended but 64 -
which means that gfortran allocated 64 times as much memory as needed.
Committed (Rev. ) after building and regtesting on x86-64-gnu
===
--- gcc/fortran/ChangeLog (Revision 203206)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,13 @@
+2013-10-04 Tobias Burnus bur...@net-b.de
+
+ Backport from mainline
+ 2013-09-25 Tobias Burnus bur...@net-b.de
+
+ PR fortran/57697
+ PR
The patch is rather obvious. The question is just why was the check
there at the first place.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-10-07 Tobias Burnus bur...@net-b.de
PR fortran/58658
* expr.c (gfc_check_vardef_context): Fix pointer diagnostic
for CLASS
. there is
no loop versioned for vectorization because of possible aliasing).
(I successfully did an ada,c,c++,fortran,go,java,lto,objc,obj-c++
bootstrap on x86-64-gnu-linux; regtesting is on-going.)
Tobias
2013-08-10 Tobias Burnus bur...@net-b.de
* c-pragma.c (init_pragma) Add #pragma ivdep
Jakub Jelinek wrote:
On Tue, Oct 08, 2013 at 08:51:50AM +0200, Tobias Burnus wrote:
+ if (loop-latch loop-latch-next_bb != EXIT_BLOCK_PTR
+ bb_seq_addr (loop-latch-next_bb))
Why this bb_seq_addr guard?
Without, I get a segfault in the stage 1 (prev-gcc/xg++) compiler when
later). See
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00502.html / The relevant
Cilk Plus patch has been posted at
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01626.html
2013-10-08 Tobias Burnus bur...@net-b.de
PR fortran/44646
* trans-stmt.c (struct forall_info): Add do_concurrent field
Thomas Schwinge wrote:
Meanwhile, here's another series that I assumed had gotten lost, but now
recovered thanks to Âgit fsckÂ. Also OK to commit?
_OPENMP pre-processor checks, openmp_version Fortran instrinsic checks.
Two remarks:
* When Jakub's patch gets it, one needs to update the C/C++
-64-gnu-linux.
OK?
Tobias
2013-10-09 Tobias Burnus bur...@net-b.de
PR fortran/58226
* options.c (gfc_get_option_string): Handle zero arg case.
diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c
index 3a9c508..6e4e7c1 100644
--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
-08-10 Tobias Burnus bur...@net-b.de
PR other/33426
* c-pragma.c (init_pragma) Add #pragma ivdep handling.
* c-pragma.h (pragma_kind): Add PRAGMA_IVDEP.
PR other/33426
* c-parser.c (c_parser_pragma, c_parser_for_statement):
Handle PRAGMA_IVDEP
.)
Another question is how much diagnostic one gives, e.g. when there is no
condition: Should there be an error, a warning or should the pragma then
silently ignored?
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-08-10 Tobias Burnus bur...@net-b.de
PR other/33426
*PING*: http://gcc.gnu.org/ml/fortran/2013-10/msg00018.html
Additionally, I'd like to early ping for the do concurrent patch:
http://gcc.gnu.org/ml/fortran/2013-10/msg00022.html , even if the ME
review is still pending.
Tobias Burnus wrote:
The patch is rather obvious. The question is just
Richard Biener wrote:
This replaces the tree - int hashtable caching hash values by
a pointer_map hashval_t and moves it out-of-GC. Likewise
it moves the actual type hashtable out-of-GC.
LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
I think it's due to this patch that
Pilot error:
rm -rf
doesn't delete the build directory. With a really empty directory works.
Sorry for the noise!
(Besides, the correct patch would have been
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00939.html )
Tobias
-10-15 Tobias Burnus bur...@net-b.de
PR fortran/58652
* trans-intrinsic.c (conv_intrinsic_move_alloc): Fix handling
of CLASS(*) variables.
2013-10-15 Tobias Burnus bur...@net-b.de
PR fortran/58652
* gfortran.dg/unlimited_polymorphic_11.f90: New.
diff --git a/gcc/fortran/trans
Marcus Shawcroft wrote: 2013-10-01 Marcus Shawcroft
marcus.shawcr...@arm.com
* configure.ac (AC_CHECK_FUNCS_ONCE): Add for exit() then make
existing AC_CHECK_FUNCS_ONCE dependent on outcome.
Ping^2
For configure patches, I am never quite sure whether they should be
/fortran/
2013-10-15 Tobias Burnus bur...@net-b.de
* intrinsic.texi (OpenMP Modules): Update to OpenMPv4.
Document omp_proc_bind_kind.
libgomp/
2013-10-15 Tobias Burnus bur...@net-b.de
* libgomp.texi: (Runtime Library Routines): Update references for
OpenMP 4.0. Add omp_get_cancellation
did: ... if unset, cancellation is disabled
Tobias
gcc/fortran/
2013-10-15 Tobias Burnus bur...@net-b.de
* intrinsic.texi (OpenMP Modules): Update to OpenMPv4.
Document omp_proc_bind_kind.
libgomp/
2013-10-15 Tobias Burnus bur...@net-b.de
* libgomp.texi: (Runtime Library Routines): Update
?
Tobias
2013-10-16 Tobias Burnus bur...@net-b.de
PR fortran/58652
* interface.c (compare_parameter): Accept passing CLASS(*)
to CLASS(*).
2013-10-16 Tobias Burnus bur...@net-b.de
PR fortran/58652
* gfortran.dg/unlimited_polymorphic_12.f90: New.
diff --git a/gcc/fortran/interface.c b
Frederic Riss wrote:
Just one question. You describe the pragma in the doco patch as:
+This pragma tells the compiler that the immediately following @code{for}
+loop can be executed in any loop index order without affecting the result.
+The pragma aids optimization and in particular
Paul Richard Thomas wrote:
This patch is fairly obvious and follows a suggestion from Tobias to
use gfc_element_size. He even wrote the testcase!
Bootstrapped and regested on FC17/x86_64 - OK for trunk?
Looks good to me. Thanks for the patch.
PS In writing this, I have just noted that I
on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-10-21 Tobias Burnus bur...@net-b.de
PR fortran/58803
* decl.c (match_ppc_decl): Prevent later
double free.
2013-10-21 Tobias Burnus bur...@net-b.de
PR fortran/58803
* gfortran.dg/proc_ptr_comp_38.f90: New.
diff --git a/gcc/fortran/decl.c b
The issue came up while reviewing the patch for PR58793.
Build and regtested on x86-64-gnu-linux
OK for the trunk?
Tobias
2013-10-21 Tobias Burnus bur...@net-b.de
PR fortran/58793
* interface.c (compare_parameter): Reject passing TYPE(*)
to CLASS(*).
2013-10-21 Tobias Burnus bur...@net
Steve Kargl wrote:
On Mon, Oct 21, 2013 at 07:15:07PM +0200, Tobias Burnus wrote:
- c-tb = tb;
+ if (num == 1)
+ c-tb = tb;
+ else
+ {
+ c-tb = XCNEW (gfc_typebound_proc);
+ c-tb-where = gfc_current_locus;
+ *c-tb = *tb;
I haven't convinced
+ regtesting is
underway.]
Crossrefs: C review comments:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00803.html
OpenMPv4's omp simd wording, see bottom of the email at
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg01194.html
Tobias
2013-08-21 Tobias Burnus bur...@net-b.de
PR other/33426
that individual loop
iterations have no interdependencies. (F2008, Introduction). Still, in
terms of optimizing do concurrent, setting safelen gives the ME all
required information.
On Oct 08, 2013, Tobias Burnus wrote:
This patch requires my pending ME and C FE patch:
http://gcc.gnu.org/ml
*PING* - with a slightly updated patch attached. Changes: New test case
for an error message plus matching the wording to the C version.
Tobias
On October 10, 2013, Tobias Burnus wrote:
This patch depends on the middle-end / C FE patch:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00655.html
A rather simple patch, which tries to implement Fortran 2008's C1116
(see also PR for the wording).
While creating the patch, I found a reject-valid issue, which is now
tracked as PR fortran/58857.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-10-23 Tobias Burnus
PS: Before committal, I will remove the #if 0 code - or enable it, as
preferred.
2013-08-24 Tobias Burnus bur...@net-b.de
PR other/33426
* c-pragma.c (init_pragma) Add #pragma ivdep handling.
* c-pragma.h (pragma_kind): Add PRAGMA_IVDEP.
PR other/33426
* c-parser.c
22, 2013, Tobias Burnus wrote:
*PING* - with a slightly updated patch attached. Changes: New test
case for an error message plus matching the wording to the C version.
Tobias
On October 10, 2013, Tobias Burnus wrote:
This patch depends on the middle-end / C FE patch:
http://gcc.gnu.org/ml/gcc
Dear Gerald, dear all,
the patch adds a quip about the new #pragma GCC ivdep to the release
notes. Additionally, I updated the Fortran section based on the changes
accumulated on http://gcc.gnu.org/wiki/GFortran#news
Any comments? Or is the patch OK?
Tobias
Index:
Hi Jakub and Gerald,
the attached patch updates the gomp project patch.
(Besides adding an item for the OpenMP 4.0 merge, I removed the 95
from Fortran 95 as Fortran is backward compatible and gfortran is
effectively a Fortran 66/77/90/95/2003/2008 compiler [minus bugs and
some missing
Gerald Pfeifer wrote:
On Thu, 24 Oct 2013, Tobias Burnus wrote:
Any comments? Or is the patch OK?
thanks for doing this.
Thanks for looking at the patch. However, the patch has a link problem.
The documentation is at
http://gcc.gnu.org/onlinedocs/gcc/Loop_002dSpecific-Pragmas.html
901 - 1000 of 3338 matches
Mail list logo
