*PING*
On 06/16/2011 08:27 AM, Tobias Burnus wrote:
This patch adds ISO_Fortran_Env's LOCK_TYPE, tons of constraint checks
and a simple implementation for -fcoarray=single.
With the implementation of LOCK_TYPE and (UN)LOCK, gfortran can now
parse all coarrays constructs of Fortran
Dear Paul,
Paul Richard Thomas wrote:
I have checked out the code for any obvious style or other minor
errors and all looks well. However, I had a look at 8.5.6 "LOCK and
UNLOCK statements" in the standard and can only confess to feeling
very stupid tonight because I could not make head nor tai
On 06/29/2011 11:35 PM, Jakub Jelinek wrote:
Bootstrapped/regtested on x86_64-linux and i686-linux. Ok for trunk
and after a while for 4.6 too?
OK - thanks for the quick patch!
@@ -4608,29 +4608,56 @@ gfc_conv_array_initializer (tree type, g
index = gfc_conv_mpz_to_tree (c->off
Daniel Carrera wrote:
On 07/05/2011 09:57 AM, Tobias Burnus wrote:
On 07/04/2011 11:34 PM, Daniel Carrera wrote:
The test compiles, but there are "expected failures" because gcc
doesn't think that allocatable scalar coarrays are supported. [...]
I really don't want to add
BUGS.txt
Build and regtested on x86-64-linux.
OK for the trunk?
(Daniel Carrera, I would be happy if you could also have a look at the
patch.)
Tobias
2011-07-06 Tobias Burnus
* trans.c (gfc_allocate_with_status): Call _gfortran_caf_register
with NULL arguments for (new) stat=/errmsg= ar
Dear Mikael,
On 07/07/2011 12:42 PM, Mikael Morin wrote:
this is the patch I posted yesterday on bugzilla at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49648#c8
This patch calls gfc_resolve_array_spec on sym->result, which calls
gfc_resolve_expr on every bound, which in turn calls resolve_ref
On 07/07/2011 01:35 PM, Mikael Morin wrote:
if (type == CAF_REGTYPE_COARRAY_STATIC)
{
This will return the same error (memory allocation failure) as in the case
just above. Is this expected or should it have an error of its own?
I think it is OK in either case. CAF_REFTYPE_COARRAY_ST
Daniel Carrera wrote:
I'd like to submit the attached patch. This patch was just discussed
in the gfortran list. It fixes a couple of TODO items in the MPI
library. It is a simple patch.
OK with the following nits fixed.
* As you have now an SVN account, can you add yourself to the
./MAINTAI
the committal of the patch at
http://gcc.gnu.org/ml/fortran/2011-07/msg00074.html - or they can be
handled by a replacement patch for the latter.
OK for the trunk?
Tobias
2011-07-09 Tobias Burnus
* caf/mpi.c (runtime_error): New function.
(_gfortran_caf_register): Use it.
diff --git a
Tobias Burnus wrote:
This patch adds a run-time error function to mpi.c, which gives a
proper error message including the image number. Additionally, it
allows to clean up the error handling, avoiding the duplicated
declaration of strings.
I have not touched the SYNC functions
Well, I did
th handler == and handler == proc-pointer> are pointers, it seems to be simplest to translate the
second argument as "void *" (BT_VOID).
Build and regtested on x86-64-linux.
OK for the trunk and the 4.6 branch?
Tobias
2011-07-09 Tobias Burnus
PR fortran/49690
* intrinsic.c (add_
===
--- libgfortran/ChangeLog (Revision 176108)
+++ libgfortran/ChangeLog (Arbeitskopie)
@@ -1,4 +1,9 @@
2011-07-09 Tobias Burnus
+
+ * runtime/error.c (sys_abort): Change argument list
+ from "()" to "(void)".
+
+2011-
patch was build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2011-07-10 Tobias Burnus
* expr.c (gfc_ref_this_image): New function.
(gfc_is_coindexed): Use it.
* gfortran.h (gfc_ref_this_image): New prototype.
* resolve.c (resolve_deallocate_expr,
resolve_allocate_expr): Sup
On 07/10/2011 09:56 PM, Tobias Burnus wrote:
This patch implemented the trans*.c part of allocatable scalar
coarrays; contrary to noncoarray allocatable scalars, they have
cobounds and thus use an array descriptor.
I found a test case (part of Reinhold Bader's fortran_tests), which gav
+ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2011-07-11 Tobias Burnus
+
+ PR fortran/18918
+ * gfortran.dg/coarray_lock_3.f90: Remove bogus dg-error.
+
2011-07-11 Georg-Johann Lay
* lib/target-supports.exp (check_effective_target_scheduling):
On 07/11/2011 06:24 PM, Jakub Jelinek wrote:
As the attached testcase (on x86-64) shows, inner_size is initialized to
1 of a wrong type, which results in verify_stmt ICEs because a PLUS has
one 64-bit and one 32-bit operand.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux.
Ok
. (At least one vendor is implementing __float128 support
and plans to modify ISO_C_BINDING.) The proper name would be
C___FLOAT128, but that looks awkward!
2011-09-28 Tobias Burnus
* Make-lang.in (F95_PARSER_OBJS, GFORTRAN_TRANS_DEPS): Add
dependency on iso-c-binding.def and iso-fortran-en
k) on x86-64-linux.
Ok for the trunk, 4.6 and 4.5?
Tobias
2011-09-30 Tobias Burnus
PR fortran/45044
* trans-common.c (translate_common): Fix -Walign-commons
check.
2011-09-30 Tobias Burnus
PR fortran/45044
* gfortran.dg/common_14.f90: Compile with -Wno-align-commons.
* gfortran.dg/com
I intent to commit the attached patch in the next days.
Do you have suggestions for a better wording or other items which should
be listed?
For the current version, see http://gcc.gnu.org/gcc-4.7/changes.html#fortran
Tobias
Index: changes.html
=
On 16.09.2011 01:08, Mikael Morin wrote:
How are cobounds passed to a coarray dummy?
For explicit shape, assumed-size and assumed shape coarrays: The value
is not passed but is set for the dummy argument. While that's not
surprising for explicit shape/assumed shape arrays, e.g.
integer ::
*ping*
http://gcc.gnu.org/ml/fortran/2011-09/msg00160.html
On 09/30/2011 10:50 AM, Tobias Burnus wrote:
Dear all,
with the following change in 4.5, the -Walign-commons warning got
disabled:
"The |COMMON| default padding has been changed – instead of adding the
padding before a variab
*ping*
http://gcc.gnu.org/ml/fortran/2011-09/msg00150.html
On 09/28/2011 04:28 PM, Tobias Burnus wrote:
This patch makes the GCC extension __float128 (_Complex) available in
the C bindings via C_FLOAT128 and C_FLOAT128_COMPLEX.
Additionally, I have improved the diagnostic for explicitly use
On 10/06/2011 03:02 PM, Michael Meissner wrote:
On the x86 (with Fedora 13), I built and tested the C, C++, Objective C, Java,
Ada,
and Go languages with no regressions
On a power6 box with RHEL 6.1, I
have done the same for C, C++, Objective C, Java, and Ada languages with no
regressions.
Hi Janus,
I completely missed that this patch is still pending review as you wrote
"committed". However, it only applied to the ICE and not to the
documentation and backporting.
On 10/01/2011 02:00 PM, Janus Weil wrote:
I have just committed as obvious a one-line patch to fix a regression
wh
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 regre
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 b/gcc/fortra
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 cleanu
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 whe
YNCHRONOUS
semantic; 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
* gfortran.texi (Fortran 2008 status, TS 29
s
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:
h: http://gcc.gnu.org/ml/fortran/2011-10/msg00073.html
2011-10-14 Tobias Burnus
PR fortran/50718
* trans-expr.c (gfc_conv_procedure_call): Fix -fcheck=pointer
for dummy arguments with VALUE attribute.
2011-10-14 Tobias Burnus
PR fortran/50718
* gfortran.dg/pointer_check_11.f90: New.
* gfor
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. Kargl
* io.c (match_dt_format): Match a user-defined op
On 10/15/2011 11:21 PM, Steve Kargl wrote:
OK for trunk?
2011-10-15 Steven G. Kargl
* 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. Kargl
* check.c (less_than_bitsize
ch as rather independent of INQUIRE even 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
Hi Janne,
On 10/17/2011 05:30 PM, Janne Blomqvist wrote:
On Mon, Oct 17, 2011 at 15:49, Tobias Burnus 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 message
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 fi
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
is
--- libgfortran/ChangeLog (revision 180134)
+++ libgfortran/ChangeLog (working copy)
@@ -1,3 +1,14 @@
+2011-10-18 Tobias Burnus
+ Janne Blomqvist
+
+ PR fortran/50016
+ * io/file_pos.c (st_flush): Call _commit on MinGW(-w64).
+ * io/intrinsics.c (flush_i4, flush_i8): Ditto.
+ * io/unix.
the 4.6.2 process a bit.
Tobias
libgfortran/
2011-10-19 Janne Blomqvist
Kai Tietz
Tobias Burnus
PR fortran/50016
* io/unix.h (flush_sync): Add new libgfortran-internal prototype.
* io/unix.c (flush_sync): New function, which calls sflush and
on MinGW(-w64) also _commit
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 - t
Am 28.10.2011 01:27, schrieb Steve Kargl:
The attached patch tightens the checking of the arguments
of the dshiftl and dshiftr argument. It also does a kind
type conversion when either I or J is a BOZ to the kind
type of the non-BOZ I or J.
OK for trunk?
OK with a changelog entry for the NEAR
Mikael Morin wrote:
Let's keep Jakub CC-ed for mixes of OpenMP and frontend optimizations. ;-)
There are two commented lines in the testcase. Is it expected?
Otherwise doesn't look too bad...
I had also a glance at the patch - and it looks reasonable; in
particular, I failed to generate a fai
Tobias Burnus wrote:
I had also a glance at the patch - and it looks reasonable; in
particular, I failed to generate a failing test case.
Actually, the test case is *not* OK.
If one compiles the original test case of the PR (or your
workshare2.f90) with "-O" and looks at &q
on),
gfortran.fortran-torture/execute/entry_4.f90 (P1 regression) and
gfortran.dg/realloc_on_assign_5.f03 (failed since committal).
NOTE: The following patch does not regtest. Hence, I do not seek approval
for this patch.
2011-11-01 Tobias Burnus
* symbol.c (all_marked): New file-gl
tly simple, fast and solid.
Tobias
2011-11-02 Tobias Burnus
* symbol.c (clear_sym_mark, traverse_ns): Remove functions.
(count_st_nodes, do_traverse_symtree, fill_st_vector): New functions.
(gfc_traverse_symtree, gfc_traverse_ns): Call do_traverse_symtree.
diff --git a/gcc/fortran/symb
Hi all,
at the GSoC Mentor summit, I had a chat with Joel, who asked me whether
he should try to crosscompile also Fortran. Well, at the end I created
the attached patch (based on what one had to do for libquadmath) and he
successfully build fortran to target RTEMS for i386, sparc64, powerpc,
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.
Tob
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 good
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 "
!
e current count is 12. There
are also a couple of other bugs, e.g. related to namelist reads, which
should be get some attention.
Tobias
2012-05-03 Tobias Burnus
PR fortran/53111
* resolve.c (resolve_fl_derived): Fix -std=f95
diagnostic for generic vs. DT names.
2012-05-03 Tobias Bu
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
PR fortran/53175
* resolve.c (resolve_variable): Set public_used
if a private module variable is used in a (public)
specification
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 enviro
Andreas Schwab wrote:
Janne Blomqvist writes:
On Sat, May 5, 2012 at 2:31 PM, Andreas Schwab 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:
# If we have GMP, check the MPFR version.
...
inux.
OK for the trunk?
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
PR fortran/53255
* resolve.c (resolve_typebound_static): Fix ha
catable or pointer
Thus, I decided to always call gfc_build_class_symbol.
Committed (Rev. 187214) after building and regtesting it on
x86-64-gnu-linux.
Tobias
2012-05-06 Tobias Burnus
PR fortran/41587
* decl.c (build_struct): Don't ignore FAILED status.
2012-05-06 Tobias
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 Fanfarillo
Paul Thomas
Tobias Burnus
PR fortran/52158
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 th
libgfortran/ChangeLog (revision 187394)
+++ libgfortran/ChangeLog (working copy)
@@ -1,17 +1,23 @@
+2012-05-11 Tobias Burnus
+
+ PR fortran/53310
+ * intrinsics/eoshift2.c (eoshift2): Do not leak
+ memory by allocating it in the loop.
+
2012-05-05 Janne Blomqvist
-* con
and array constructors are known to be broken.)
Comments?
The attached patch builds and regtests.
OK for the trunk?
Tobias
2012-05-11 Tobias Burnus
PR fortran/49110
PR fortran/51055
* trans-expr.c (gfc_trans_assignment_1): Fix allocation
handling for assignment of function results to allocatable
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
2-05-12 Tobias Burnus
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
PR fortran/49110
PR fortran/52843
* gfortran.dg/deferred_type_param_5.f90: New.
diff --git a/gcc
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 congratul
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
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
PR fortran/49110
PR fortran/51055
PR fortran/53329
* trans
on VxWorks
and on systems without mkstemp.
OK 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
* io/uni
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
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, b
*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
ould consider 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
PR fortran/53389
* trans-array.c (gfc_add_loop_ss_code): Don't evaluate
for the trunk? (I think it is really obvious.)
Tobias
fixincludes/
2012-05-22 Tobias Burnus
* 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/confi
e the committal, I will re-generate them with 1.11.1.)
Tobias
2012-05-22 Tobias Burnus
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
--- a/libgfo
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 a
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 sec
*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
e some extra issues.
- PR 50221: Some odd array assignment issues.
- 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
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
CLOCK_THREAD_
hecking .c files a relatively quick task.)
2012-05-29 Tobias Burnus
* decl.c: Fix comment typos.
* expr.c: Ditto.
* frontend-passes.c: Ditto.
* match.c: Ditto.
* resolve.c: Ditto.
* trans-array.c: Ditto.
* trans-common.c: Ditto.
* trans-intrinsic.c: Ditto.
* trans-types.c: Ditto.
2012
Log (Revision 188000)
+++ ChangeLog (Arbeitskopie)
@@ -1,5 +1,10 @@
2012-05-30 Tobias Burnus
+ PR c/53502
+ * decl.c (match_attr_spec): Remove "typedef".
+
+2012-05-30 Tobias Burnus
+
* decl.c: Fix comment typos.
* expr.c: Ditto.
* frontend-
This patch rejects actual arguments to MOVE_ALLOC which are coindexed or
have a corank.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-05-30 Tobias Burnus
* check.c (gfc_check_move_alloc): Reject coindexed actual arguments
and those with corank.
2012-05-30 Tobias
On 05/30/2012 11:09 AM, Tobias Burnus wrote:
This patch rejects actual arguments to MOVE_ALLOC which are coindexed
or have a corank.
Updated version (cf. below). Build and regtested on x86-64-linux.
OK for the trunk?
I asked at J3 and John Reid kindly pointed me to the pending
interpretation
ation)
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-05-30 Tobias Burnus
PR fortran/53526
* trans-intrinsic.c (conv_intrinsic_move_alloc): Handle coarrays.
2012-05-30 Tobias Burnus
PR fortran/53526
* gfortran.dg/coarray_lib_move_alloc_1.f90: New.
* gfortran.dg
to remove the extra argument.
Committed as Rev. 188048.
Tobias
Index: libgfortran/ChangeLog
===
--- libgfortran/ChangeLog (Revision 188023)
+++ libgfortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,10 @@
+2012-05-31 Tobias Burnus
+
+ Rever
ost's example and the test suite.
Which version do you prefer? OK for the trunk?
I like the second version more. (And I would even consider to get rid of
the os_error.)
Tobias
2012-05-31 Tobias Burnus
PR fortran/53521
* trans.c (gfc_deallocate_scalar_with_status): Properly
handle the c
that "dim" is always >= 0.)
Build on x86-64-gnu-linux.
OK for the trunk?
Tobias
2012-06-01 Tobias Burnus
* intrinsics/chmod.c (chmod_func): On MinGW, don't set is_dir and
fix octal-mode handling.
* io/unit.c (get_internal_unit): Add cast.
* io/unix.c (min): Undef &
Aldy Hernandez wrote:
PR tree-optimization/52558
* cfg.c (alloc_aux_for_edge): Fix comment.
(alloc_aux_for_edge): Remove static.
* basic-block.h (alloc_aux_for_edge): Protoize.
* tree-ssa-loop-im.c (execute_sm_if_changed): New.
(execute_sm_if_change
Janus Weil wrote:
The patch actually gives a few warnings:
Looking at those warnings, they seem to be valid C++ but invalid C89. As
Stages 2 and 3 are, by default, compiled by C++, I assume that
Alessandro does not see those.
By contrast, I assume that you (Janus) build GCC with the C compi
Alessandro Fanfarillo wrote:
The gfortran.dg/dynamic_dispatch_4.f03 had this problem in the past
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986); currently it
calls the __free_s_bar_mod_S_bar function instead of the proper
doit().
That kind of makes sense: "foo" has no allocatable component
Hi Alessandro, hi all,
Alessandro Fanfarillo wrote:
in attachment the patch which includes the review comments provided by Tobias.
Thanks for the patch, which I committed as Rev. 188152. Congratulation
to your second committed patch.
Nit: You forgot twice to add the prefix "gfc_" in the Cha
not a regression and it
requires a nondefault flag; on the other hand, it can be rather
suprising wrong-code bug and the fix is simple.
Tobias
2012-06-04 Tobias Burnus
PR fortran/50619
* resolve.c (build_default_init_expr): Don't initialize
ASSOCIATE names.
2012-06-04 Tobias Burnus
Thomas Koenig wrote:
his rather simple patch makes sure that only memset is used for
assigning empty strings when front-end optimization is used.
Regression-tested. OK for trunk?
OK, thanks for the quick patch.
Tobias
2012-06-06 Thomas König
PR fortran/52861
* frontend-
Hi,
Janus Weil wrote:
here is a patch for an ICE-on-invalid bug, which concerns the
allocation of CLASS variables. The ICE is fixed by changing the order
of the checks which are done in gfc_match_allocate, so that an error
is triggered before the ICE can occur.
Regtested on x86_64-unknown-linux
Janus Weil wrote:
In any case, for those two, it does not trigger but one
gets later (resolve?) the error:
Error: Allocate-object at (1) must be ALLOCATABLE or a POINTER
Then I guess one can just remove the FIXME.
That's fine with me.
Regarding the error:
Error: Allocate-object at (1) is
601 - 700 of 1343 matches
Mail list logo
