On 10/07/2011 12:18 PM, Janus Weil wrote:
Regtested successfully on x86_64-unknown-linux-gnu (except for failure
on entry_4 and select_type_12, which are known middle-end
regressions). Ok for trunk and 4.6?
OK. Thanks for the patch - and for telling me that select_type_12 is a
middle end
On 07.10.2011 23:19, Janus Weil wrote:
Yes, please backport to 4.6. If you want, you can also backport to
4.5. However, I do not think that -fwhole-file gets used in 4.5 -
especially, as it has some issues.
Fixed on the 4.6 branch with r179696. It's probably not worth to
backport to 4.5 ...
On 07.10.2011 16:38, Mikael Morin wrote:
The full patchset has passed the fortran testsuite successfully.
OK for trunk?
OK for the whole patch set. Thanks for finding and fixing the issue!
Tobias
Patches layout
01..04/14: Add support for non-full arrays in descriptor initialization code.
On 08.10.2011 11:51, Janus Weil wrote:
Thanks! What's about the .texi change for -fwhole-file?
Will do. Should I include a note about deprecation? And if yes, do you
have a suggestion for the wording?
How about the following attachment?
Tobias
diff --git a/gcc/fortran/invoke.texi
On 02.10.2011 01:43, Janus Weil wrote:
Hi all,
while working on PR50547, I noticed some strange things about
resolve_formal_arglist, so I decided to clean it up a little. The
attached patch does a couple of things:
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
OK. Thanks for the
Hi Thomas,
the attached patch fixes the PR by removing common function elimination
in FORALL statements.
I think that part is OK. However, you do more - you also avoid the handling
for DO CONCURRENT.
However, I do not see why it could fail for DO CONCURRENT or rather: I do
not see a case
; turning it off is a missed-optimization bug.)
The patch was build and regtested on x86-64-linux.
OK for the trunk?
Tobias
PS: I will also update the release notes after the patch has been committed.
2011-10-12 Tobias Burnus bur...@net-b.de
* gfortran.texi (Fortran 2008 status, TS 29113 status
On 10/09/2011 07:01 PM, Tobias Burnus wrote:
On 08.10.2011 11:51, Janus Weil wrote:
Thanks! What's about the .texi change for -fwhole-file?
Will do. Should I include a note about deprecation? And if yes, do you
have a suggestion for the wording?
How about the following attachment?
Index: ChangeLog
2011-10-14 Tobias Burnus bur...@net-b.de
PR fortran/50718
* trans-expr.c (gfc_conv_procedure_call): Fix -fcheck=pointer
for dummy arguments with VALUE attribute.
2011-10-14 Tobias Burnus bur...@net-b.de
PR fortran/50718
* gfortran.dg/pointer_check_11.f90: New.
* gfortran.dg
On 10/14/2011 12:19 PM, Tobias Burnus wrote:
while testing my constructor draft patch with FGSL, I found two bugs
(4.6/4.7 regressions): PR target/50721 (segfault on x86-64 after
execution - one of the rare -O0 only bugs)
That bug turned out to be a out-of-bounds problem between Fortran and C
*ping*
http://gcc.gnu.org/ml/fortran/2011-10/msg00073.html
On 12.10.2011 15:57, Tobias Burnus wrote:
Hello all,
this patch does two things:
a) It updates the Fortran 2003 and TR/TS 29113 status in the GNU
Fortran manual.
b) It changes all references to Technical Report 29113 to Technical
Am 15.10.2011 14:04, schrieb Thomas Koenig:
Am 15.10.2011 13:36, schrieb Jakub Jelinek:
This looks wrong. Threadprivate variables aren't completely cheap,
much better would be an automatic variable instead.
As Fortran FE IL doesn't have block local variables, I guess you want
to create the var
On 10/16/2011 09:38 PM, Steve Kargl wrote:
The attach patch fixes the construction of a format string
from a user-defined operator or from a string with a kind
type prefix.
OK. Thanks for the patch.
Tobias
2011-10-16 Steven G. Karglka...@gcc.gnu.org
* io.c (match_dt_format): Match
On 10/15/2011 11:21 PM, Steve Kargl wrote:
OK for trunk?
2011-10-15 Steven G. Karglka...@gcc.gnu.org
* gfortran.dg/ishft_3.f90: Update test.
I am not so happy with complete test replacements. How about adding it
as new test case?
2011-10-15 Steven G. Karglka...@gcc.gnu.org
if the
issue first occurred with INQUIRE (PR 44698). Thus, it is independent
from whether one calls stat() for an open file or whether one uses a
different method like seek(SEEK_END) + tell() to obtain the file size.
2011-10-17 Tobias Burnus bur...@net-b.de
PR fortran/50016
* intrinsic.texi
Hi Janne,
On 10/17/2011 05:30 PM, Janne Blomqvist wrote:
On Mon, Oct 17, 2011 at 15:49, Tobias Burnusbur...@net-b.de wrote:
This patch adds a call to _commit() on _WIN32 for the FLUSH subroutine and
the FLUSH statement. It removes the _commit from gfortran's buf_flush.
Like I argued in this
This patch changes Technical Report 29113 to Technical Specification
29113 as ISO/SC22 decided that the TR29113 draft should be submitted as
TS; it reflects the recently committed patch to gfortran itself. [1]
Tobias
[1] http://gcc.gnu.org/ml/fortran/2011-10/msg00088.html
Index: changes.html
On 10/17/2011 11:37 PM, Janus Weil wrote:
here is another patch for PR47023, which takes care of comment #1,
i.e. rejecting polymorphic variables in a C-binding context.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
OK. Thanks for the patch.
If I saw it correctly, one still needs to
On 10/17/2011 07:02 PM, Steve Kargl wrote:
On Mon, Oct 17, 2011 at 12:22:03PM +0200, Tobias Burnus wrote:
I am not so happy with complete test replacements. How about adding it
as new test case?
Well, the old testcase is
[...]
The only line that would survive is the first line, which
/ChangeLog (revision 180134)
+++ libgfortran/ChangeLog (working copy)
@@ -1,3 +1,14 @@
+2011-10-18 Tobias Burnus bur...@net-b.de
+ Janne Blomqvist j...@gcc.gnu.org
+
+ PR fortran/50016
+ * io/file_pos.c (st_flush): Call _commit on MinGW(-w64).
+ * io/intrinsics.c (flush_i4, flush_i8): Ditto
the 4.6.2 process a bit.
Tobias
libgfortran/
2011-10-19 Janne Blomqvist j...@gcc.gnu.org
Kai Tietz kti...@redhat.com
Tobias Burnus bur...@net-b.de
PR fortran/50016
* io/unix.h (flush_sync): Add new libgfortran-internal prototype.
* io/unix.c (flush_sync): New function, which
Pre-remark: Jakub (4.6.2 RM) had no objects - and thus I have committed
it to the branch.
Steve Kargl wrote:
I don't have an objection, just a question. Does this issue appear on
trunk?
Yes and no. The MinGW build issue this patch fixes was unique to the branch.
However, the actual issue -
or Fortran. But without binding name, that's not possible from C,
hence, that's fine.
Build and regtested on x86-64-linux. (And currently regtesting again -
after a minor modification.)
OK for the trunk?
Tobias
2012-04-03 Tobias Burnus bur...@net-b.de
PR fortran/52751
* trans-decl.c
Janne Blomqvist wrote:
the attached patch implements a few fixes and cleanups for the MOD and
MODULO intrinsics.
The patch adds notes to the documentation about the usage of fmod, so
users interested in corner-case behavior can look up how that function
is supposed to behave on their target.
Thomas Koenig wrote:
this fixes a 4.7/4.8 regression with a bogus warning for variables
which were excluded from being imported by use, only if they
were in a common block inside the module.
Regression-tested. OK for trunk and for 4.7 after a few days?
OK and thanks for the patch.
! {
No patch review - but and answer to a question and a comment.
Janus Weil wrote:
I am aware that it will break the ABI, but only for programs involving
procedure pointers (which still is a 'relatively' new feature,
supported since gfortran 4.4).
Btw, speaking of ABI breaking: What are the
Ping.
On 04/03/2012 01:59 PM, Tobias Burnus wrote:
A rather obvious patch.
The module procedure had the FL_PROCEDURE due its use (CALL sub or
func()) - but no interface and no type. Thus, there was no attempt
to search for the symbol in the parent namespace, which causes failures.
Build
Hi Janus,
On 04/11/2012 10:58 AM, Janus Weil wrote:
Hence, we should really think about -fabi-version=n (and .mod compatibility).
Unless, we are positive that we will break the ABI for the array descriptor in
4.8, I am in favour of adding -fabi-version=n already for the proc-pointer
patch.
also didn't try to optimize for private DT,
private generics etc. First, I think it is not needed. And secondly,
through inheritance, it can get extremely complicated.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-04-11 Tobias Burnus bur...@net-b.de
PR fortran/52916
PR
-64-linux.
OK for the trunk and the 4.6/4.7 branch?
Tobias
20012-04-12 Tobias Burnus bur...@net-b.de
PR fortran/52864
* expr.c (gfc_check_vardef_context): Fix assignment check for
pointer components.
20012-04-12 Tobias Burnus bur...@net-b.de
PR fortran/52864
* gfortran.dg
, an accepts-invalid bug,
cleans up the code a bit and adds a test case for existing checks
(besides testing the bug fixes).
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
20012-04-12 Tobias Burnus bur...@net-b.de
PR fortran/52864
* interface.c (compare_parameter_intent
* PING *
It is a rather serious rejects-valid regression. It also affects SPEC
CPU 2006 and the patch has been confirmed (cf. PR) to fix the regression.
Tobias
Tobias Burnus wrote:
Dear all,
my recent patch for setting PRIVATE module variables and procedures to
TREE_PUBLIC()=0 had a flaw
H.J. Lu wrote:
The testcase failed with
/export/gnu/import/git/gcc-test-ia32/src-trunk/gcc/testsuite/gfortran.dg/public_private_module_4.f90:11.4:^M
^M
use m^M
1^M
Fatal Error: Can't open module file 'm.mod' for reading at (1): No
such file or directory^M
compiler exited with status 1
Janus Weil wrote:
here is a small patch for an OOP problem. For discussion see the PR.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
OK and thanks for the patch. Note, however, that since Bernhard's patch*,
using cleanup-modules is usually not needed.
*
Dear all,
first, I would like to ping my patch:
- [Patch, Fortran] PR52864 - fix actual/formal checks
http://gcc.gnu.org/ml/fortran/2012-04/msg00059.html
Other patches with pending review:
- [Patch, Fortran, F03] PR52909: Procedure pointers not private to modules
Thomas Koenig wrote:
- [patch, fortran] Trim spaces on list-directed reads
http://gcc.gnu.org/ml/fortran/2012-04/msg00040.html
That one was committed:
http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00417.html
Jerry indicated that this would also be OK for a backport; I'll
do that within a few
Updated patch enclosed.
On 02/14/2012 12:42 PM, Tobias Burnus wrote:
in order to gain an overview for our code whether the recent RESHAPE
(and friends) bug affects us and to determine for which assignment a
reallocation happens, useful to mitigate performance issues, I added
-Wrealloc-lhs
*ping*
Tobias
PS: I know I should be also faster in reviewing patches of others...
On 04/12/2012 05:23 PM, Tobias Burnus wrote:
This patch is a kind of follow up to the other one for the same PR -
though this one is for a separate test case, it is not a regression
and it's about actual
Dear all,
I seriously struggle with the following patch. It replaces a library
call by inline code for
C_F_POINTER(C-pointer, Fortran-array-pointer, shape-of-the-array)
(Purpose: (a) The current library version fails for SHAPE with strides.
(b) For the new array descriptor (fortran-dev
Dear all,
some compilers support using q to indicate quad precision, e.g.
4.0q0. Since GCC 4.7, gfortran supports this vendor extension in the
source code. However, READing the floating-point number 4.0q0 was not
supported.
The attached patch adds this support, which some users expect (cf.
Small follow up.
On 04/20/2012 11:18 AM, Tobias Burnus wrote:
Testing other compilers, the result is:
- 'q' not supported: g95, NAG f95, PGI, PathScale, Crayftn
- 'q' supported: g77, ifort, sunf95
It seems to be also supported by IBM's xlf - at least it supports such
literals in the source
Thomas: Please write branch changes not in libgfortran/ChangeLog but in
libgfortran/ChangeLog.fortran-dev; that avoids merge problems when
updating from the trunk.
The branch (rev. 186674) now matches the trunk (Rev. 185178-186672).
Unfortunately, there are still about a dozen failures.
Hello Mikael,
thanks for the review. Regarding:
Mikael Morin wrote:
is there a reason to guard the class_pointer condition with
attr.class_ok in the first conditional and with CLASS_DATA(...) !=
NULL in the two other ones? Not that it matters much, and in fact, I
think the patch as is is
Dear Paul,
Paul Richard Thomas wrote:
Find attached a revised patch to fix PR 41600.
Thanks for the patch. I think it is OK.
Regarding:
! if (ref ref-type != REF_ARRAY seen_array)
! {
! gfc_error (CLASS selector at %L is an array with CLASS
!
a couple of other bugs, e.g. related to namelist reads, which
should be get some attention.
Tobias
2012-05-03 Tobias Burnus bur...@net-b.de
PR fortran/53111
* resolve.c (resolve_fl_derived): Fix -std=f95
diagnostic for generic vs. DT names.
2012-05-03 Tobias Burnus bur...@net-b.de
PR
not seem to save the specification expression in the .mod
file.)
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-05-03 Tobias Burnus bur...@net-b.de
PR fortran/53175
* resolve.c (resolve_variable): Set public_used
if a private module variable is used in a (public
Dear Janne,
sorry for the really slow review.
Janne Blomqvist wrote:
the attached patch implements some fixes for handling STATUS=SCRATCH files.
...
Currently, we check [...] but not the POSIX and GNU standard TMPDIR [...]
If the program is privileged, we shouldn't trust path style
Andreas Schwab wrote:
Janne Blomqvistblomqvist.ja...@gmail.com writes:
On Sat, May 5, 2012 at 2:31 PM, Andreas Schwabsch...@linux-m68k.org wrote:
mpfr 2.3.1 doesn't have mpfr_fmod.
I know, but since GCC requires at least mpfr 2.4.2 we're ok.
No, it doesn't.
From 4.8's ./configure:
#
?
As it is a nasty wrong-code bug (but no regression), I wonder whether it
should be backported - and, if so, to which version - 4.7 only?
(Affected are GCC 4.5 to 4.8.)
Tobias
2012-05-06 Tobias Burnus bur...@net-b.de
PR fortran/53255
* resolve.c (resolve_typebound_static): Fix handling
of overridden
call gfc_build_class_symbol.
Committed (Rev. 187214) after building and regtesting it on
x86-64-gnu-linux.
Tobias
2012-05-06 Tobias Burnus bur...@net-b.de
PR fortran/41587
* decl.c (build_struct): Don't ignore FAILED status.
2012-05-06 Tobias Burnus bur...@net-b.de
PR fortran/41587
Hello,
On 05/06/2012 09:37 PM, Alessandro Fanfarillo wrote:
The patch is bootstrapped and tested on x86_64-unknown-linux-gnu - gcc
version 4.8.0 20120506 (experimental)
2012-05-06 Alessandro Fanfarillofanfarillo@gmail.com
Paul Thomaspa...@gcc.gnu.org
Tobias
Hello Thomas,
below a very timely review - your patch is not even a month old
and was never pinged, besides, you have chosen an unlucky day.
(In other words: Sorry for the slow review.)
Thomas Koenig wrote on Fri, 13 Apr 2012:
this patch replaces a != '' with len_trim(a) != 0, to
speed up the
187394)
+++ libgfortran/ChangeLog (working copy)
@@ -1,17 +1,23 @@
+2012-05-11 Tobias Burnus bur...@net-b.de
+
+ PR fortran/53310
+ * intrinsics/eoshift2.c (eoshift2): Do not leak
+ memory by allocating it in the loop.
+
2012-05-05 Janne Blomqvist j...@gcc.gnu.org
-* config.h.in
?
The attached patch builds and regtests.
OK for the trunk?
Tobias
2012-05-11 Tobias Burnus bur...@net-b.de
PR fortran/49110
PR fortran/51055
* trans-expr.c (gfc_trans_assignment_1): Fix allocation
handling for assignment of function results to allocatable
deferred-length strings.
2012-05
On 18 April 2012 at 18:57, Bernhard Reutner-Fischer wrote:
On Tue, Apr 17, 2012 at 12:47:48AM +0200, Tobias Burnus wrote:
Approved but not yet committed:
Bernhard:
- [PATCH] gfortran testsuite: implicitly cleanup-modules, part 2
http://gcc.gnu.org/ml/fortran/2012-04/msg00065.html
Before
Burnus bur...@net-b.de
PR fortran/49110
PR fortran/52843
* resolve.c (resolve_fl_procedure): Don't regard
character(len=:) as character(*) in the diagnostic.
2012-05-12 Tobias Burnus bur...@net-b.de
PR fortran/49110
PR fortran/52843
* gfortran.dg/deferred_type_param_5.f90: New.
diff
Hello Alessandro,
Alessandro Fanfarillo wrote:
in attachment there's the new candidate patch, revisited by Tobias,
for PR fortran/45170, PR fortran/52158 and PR fortran/49430
(unexpectedly).
Please, check the Changelog, I don't know whether the descriptions are ok.
The patch is bootstrapped and
Tobias Burnus wrote:
I think the ChangeLog is okay - as is the whole patch.
I wouldn't mind if someone else (Paul? Janus?) could also glance at
the patch; however, if there are no comments, I intent to commit the
patch soon.
Committed as Rev. 187436. Thanks for the patch and congratulation
Tobias Burnus wrote:
Note that the patch assumes that the function's result variable's
length specification expression is completely known to the caller. I
think that's always the case in gfortran - or is it not?
Thinking about it, I came to the conclusion has explicitly been designed
Dear Paul,
On 05/14/2012 03:31 PM, Paul Richard Thomas wrote:
OK for trunk - just a wee typo to correct:
Fixed. Thanks for the review! I have now committed the attached patch as
Rev. 187472.
Tobias
2012-05-14 Tobias Burnus bur...@net-b.de
PR fortran/49110
PR fortran/51055
PR fortran
for the trunk? (Is there a need for backporting?)
Tobias
[1] http://pubs.opengroup.org/onlinepubs/95399/functions/open.html
[2]
http://www-kryo.desy.de/documents/vxWorks/V5.5/vxworks/ref/ioLib.html#open
2012-05-15 Tobias Burnus bur...@net-b.de
* io/unix.c (fallback_access): Pass mode to open
A rather simple patch.
Build and regtested on x86-64-linux.
OK for the trunk?
I think that is the last patch required for commonly used code.
Remaining are issues with array constructors and concatenations - and,
of course, deferred-length components.
Tobias
2012-05-15 Tobias Burnus bur
Dear Janne,
On 05/16/2012 08:45 AM, Janne Blomqvist wrote:
IMHO it would be cleaner if you instead somewhere in the beginning of unix.c did
#ifdef __VXWORKS__
/* open is not a variadic function on vxworks (or something...) */
#define open(path, flags) open(path, flags, 0666)
#endif
Untested,
*ping*
On Tue, 15 May 2012 12:26, Tobias Burnus wrote:
A rather simple patch.
Build and regtested on x86-64-linux.
OK for the trunk?
I think that is the last patch required for commonly used code.
Remaining are issues with array constructors and concatenations - and,
of course, deferred
Hi Alessandro,
Alessandro Fanfarillo wrote:
in attachment there's a patch for PR 48831, it also includes a new
test case suggested by Tobias Burnus.
The patch is bootstrapped and tested on x86_64-unknown-linux-gnu.
Please try to ensure that your patch has a text mime type - it shows up
committing the patch even
without. However, it might not harm to have it in the test suite.
Build and regtested on x86-64-linux.
OK for the trunk and 4.6/4.7?
Tobias
2012-05-21 Tobias Burnus bur...@net-b.de
PR fortran/53389
* trans-array.c (gfc_add_loop_ss_code): Don't evaluate expression
? (I think it is really obvious.)
Tobias
fixincludes/
2012-05-22 Tobias Burnus bur...@net-b.de
* configure.ac: Use GCC_AC_FUNC_MMAP_BLACKLIST
instead of gcc_AC_FUNC_MMAP_BLACKLIST.
* aclocal.m4: Regenerate.
* configure: Regenerate.
diff --git a/fixincludes/configure.ac b/fixincludes
the committal, I will re-generate them with 1.11.1.)
Tobias
2012-05-22 Tobias Burnus bur...@net-b.de
PR libfortran/53445
* intrinsics/chmod.c (chmod_func): Ignore S_ISVTX on VxWorks.
diff --git a/libgfortran/intrinsics/chmod.c b/libgfortran/intrinsics/chmod.c
index 9156303..e8a81d5 100644
On 05/22/2012 03:06 PM, Tobias Burnus wrote:
The attached patches fix compilation issues on VxWorks.
a) VxWorks has strerror_r but contrary to POSIX, the function in
VxWorks (at least in older versions) takes only two arguments: errnum
and buf and not also the buffer length. I added
Hi Janne,
On 05/23/2012 04:44 PM, Janne Blomqvist wrote:
some targets such as VXWorks don't provide gettimeofday but do provide
clock_gettime. The attached patch allows such targets to get better
resolution for the DATE_AND_TIME (up to the 1 millisecond limit of the
API) intrinsic than the 1
*ping*
On 20 May 2012 10:34, Tobias Burnus wrote:
*ping*
On Tue, 15 May 2012 12:26, Tobias Burnus wrote:
A rather simple patch.
Build and regtested on x86-64-linux.
OK for the trunk?
I think that is the last patch required for commonly used code.
Remaining are issues with array
.
- PR 51976: Deferred-string components. Needs a hidden component for the
string length. Tricky: expr-ts.u.cl-backend_decl is wrong as that
points to the component - missing the component ref (var-comp).
Similar to the issue of PR49954.
Tobias
2012-05-24 Tobias Burnus bur...@net-b.de
PR
On 05/23/2012 10:43 PM, Janne Blomqvist wrote:
the attached patch allows the use of clock_gettime() with
CLOCK_PROCESS_CPUTIME_ID or CLOCK_THREAD_CPUTIME_ID if the target
doesn't have getrusage() or times().
It's not completely clear to me whether CLOCK_PROCESS_CPUTIME_ID or even
} }
Index: ChangeLog
===
--- ChangeLog (Revision 189724)
+++ ChangeLog (Arbeitskopie)
@@ -1,3 +1,7 @@
+2012-07-20 Tobias Burnus bur...@net-b.de
+
+ * gfortran.dg/assumed_rank_12.f90: Update dg-error.
+
2012-07-20 Jason
I have now merged the trunk into the branch (Rev. 189727).
Tobias
TS 29113 adds (a bit hidden in 9.9 Edits to clause 15) a new
ISO_C_Binding parameter: C_PTRDIFF_T.
Build, tested, and currently regtesting on x86-64-gnu-linux.
OK for the trunk?
Tobias
2012-07-21 Tobias Burnus bur...@net-b.de
* iso-c-binding.def (C_PTRDIFF_T): New TS29113 parameter
@@
+2012-07-21 Tobias Burnus bur...@net-b.de
+
+ * trans-expr.c (gfc_conv_derived_to_class): Fix argument passed
+ to class_array_data_assign.
+
2012-07-20 Tobias Burnus bur...@net-b.de
* decl.c (gfc_verify_c_interop_param): Allow assumed-shape
===
--- gcc/fortran/ChangeLog (Revision 189739)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,5 +1,10 @@
2012-07-21 Tobias Burnus bur...@net-b.de
+ * resolve.c (resolve_formal_arglist): Put variable
+ declaration before the first assignment.
+
+2012-07-21 Tobias
Mikael Morin wrote:
On 20/07/2012 12:19, Tobias Burnus wrote:
Build and regtested on x86-64-linux.
OK for the trunk?
OK.
Thanks! Committed as Rev. 189743.
Mikael: I wouldn't mind if you could have a look at the scalarizer - you
seem to have an idea how one can implement it with minimal
Mikael Morin wrote:
Here is another attempt.
I moved the diagnostic code from gfc_resolve_iterator to
resolve_array_list, so that it doesn't trigger for do loops.
Regression test in progress. OK?
The patch looks OK:
Though, I wonder why you only get a warning (which is fine); I thought
that
Committed as obvious (Rev. 189859).
Tobias
2012-07-25 Tobias Burnus bur...@net-b.de
* trans-types.c (gfc_real16_is_float128): Fix spelling
in a comment.
* trans.h (struct gfc_array_info): Ditto.
* gfortran.h (gfc_expr): Ditto.
* simplify.c (gfc_count
Fanfarillo fanfarillo@gmail.com
Tobias Burnus bur...@net-b.de
* module.c (mio_array_spec): Don't read as-lower for
assumed-rank arrays.
diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index a3b9088..51b7059 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
Tobias Burnus wrote:
The following issue was found by Alessandro. (It got triggered by a
larger test case, which is required for a larger patch by Alessandro,
which is not yet finished.)
Accessing the lower[-1] is probably not the best idea …
Build on x86-64-linux.
OK for the trunk?
I
+1,9 @@
+2012-07-26 Alessandro Fanfarillo fanfarillo@gmail.com
+ Tobias Burnus bur...@net-b.de
+
+ * module.c (mio_array_spec): Don't read as-lower for
+ assumed-rank arrays.
+
2012-07-25 Tobias Burnus bur...@net-b.de
* trans-types.c (gfc_real16_is_float128): Fix spelling
Index
On 07/25/2012 08:04 PM, Tobias Burnus wrote:
Committed as obvious (Rev. 189859).
I just saw that I missed the testsuite changes. I have now committed
them as Rev. 189887.
Tobias
Index: testsuite/gfortran.dg/contiguous_1.f90
as the current implementation
has several rejects-valid/wrong-code bugs (cf. the existing PRs). For
the full to-do list of TS29113, see
http://gcc.gnu.org/ml/fortran/2012-07/msg00115.html
2012-07-26 Tobias Burnus bur...@net-b.de
* interface.c (gfc_procedure_use): Return gfc_try instead of void
On 07/26/2012 05:12 PM, Mikael Morin wrote:
On 26/07/2012 16:53, Mikael Morin wrote:
Here is a draft for those. Lightly tested with print *, ...
Looks rather nice. The output for test1 is also good:
integer :: a(1:3,-2:5)
gives
lbound(arg) == [1, 1]
ubound(arg) == [3, 8]
shape(arg)
*PING*
Tobias Burnus wrote:
TS29113 allows also non interoperable procedures with
c_funloc/c_f_procpointer; hence, this patch allows them with
-std=f2008ts:
The function C F PROCPOINTER from the intrinsic module ISO C BINDING
has the restriction in ISO/IEC 1539-1:2010 that CPTR and FPTR
On 07/29/2012 11:24 AM, Thomas Koenig wrote:
here is an updated patch for PR 54033, this time with test cases.
Thanks to Janis for pointing me in the right direction with these.
Regression-tested. OK for trunk?
Ok. Thanks for the patch - and to Janis for the first review.
Can you eliminate
On 07/31/2012 11:50 AM, Janus Weil wrote:
The patch was regtested successfully on x86_64-unknown-linux-gnu. Ok for trunk?
The patch looks okay. I assume, the patch doesn't help to get PR 54035
fixed,does it? (That PR is about TBP binding to the generic instead of
the specific name.)
On 07/27/2012 06:06 PM, Mikael Morin wrote:
The offset field is never set; this patch removes it.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
OK. Thanks for the nice clean-up patch.
Tobias
On 07/27/2012 07:26 PM, Mikael Morin wrote:
do you have a test case exhibiting the problem? It seems fine to me.
Your second test case was too convoluted for me - and as I wasn't at
home, I couldn't test it. I now believe that your patch is okay; I will
later formally review it.
Do you
On 08/01/2012 01:37 PM, Mikael Morin wrote:
However, I found another spot where one needs to have a scalarizer;
possibly a poor man's version is enough. Namely INTENT(OUT) handling.
Indeed.
Do you have an idea how to best handle that case?
It seems some new code is necessary. I don't know how
On 08/02/2012 10:54 AM, Richard Guenther wrote:
Seems to break testing, all testcases emit
Warning: Nonexistent include directory finclude^M
now and thus all testcases fail like
FAIL: gfortran.dg/alloc_comp_basics_1.f90 -O0 (test for excess errors)
First, I actually wonder why it only
Hello Mikael,
thanks for your patch series, which not only implements missing parts of
the assumed-rank support but also fixes some buglets such as the
set_loop_bounds setting or the shape setting for assumed ranks. The
patch is okay.
Tobias
On 08/02/2012 04:17 PM, Mikael Morin wrote:
On 08/05/2012 11:12 PM, Janus Weil wrote:
here is a patch for a rather old PR, which deals with correctness
checking for several cases, such as:
1) dummy procedures
2) proc-ptr assignments
3) type-bound procedure overloading
The patch adds a new function 'check_result_characteristics' to do
and gfortran didn't.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2012-08-08 Tobias Burnus bur...@net-b.de
PR fortran/40881
* error.c (gfc_notify_std): Reset cur_error_buffer-flag flag
when the error/warning has been printed.
* gfortran.h (gfc_sl_type): Add ST_LABEL_DO_TARGET
-linux.
OK for the trunk?
Tobias
2012-08-09 Tobias Burnus bur...@net-b.de
PR fortran/54199
* intrinsic.c (gfc_warn_intrinsic_shadow): Better warning
for internal procedures.
2012-08-09 Tobias Burnus bur...@net-b.de
PR fortran/54199
* gfortran.dg/intrinsic_shadow_4.f90: New.
diff --git
only included a test case for module variables; for module procedures,
one runs into PR54224.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-08-11 Tobias Burnus bur...@net-b.de
PR fortran/54221
* trans-decl.c (gfc_finish_var_decl, build_function_decl):
Fix setting private
the vtab.
(resolve_symbol): Also allow assumed-rank arrays with CONTIGUOUS.
2012-08-13 Alessandro Fanfarillo fanfarillo@gmail.com
Tobias Burnus bur...@net-b.de
PR fortran/37336
* gfortran.dg/coarray_poly_3.f90: Update dg-error.
* gfortran.dg/auto_dealloc_2.f90: Update scan-tree
401 - 500 of 3338 matches
Mail list logo
