On Thu, Aug 14, 2014 at 07:40:52PM +0200, Thomas Koenig wrote:
Hello world,
the attached patch fixes the regression by making sure we never
try to create a temporary variable from a temporary variable,
which happened in the wrong order.
Regression-tested. OK for trunk and 4.9?
Looks
On Sun, Aug 10, 2014 at 12:27:47AM +0200, Thomas Koenig wrote:
the attached patch fixes the regression by converting the arguments
to dot_product to the proper types.
Regression-tested on x86_64-unknown-linux-gnu.
OK for all affected branches (trunk, 4.9 and 4.8)?
Yes.
--
Steve
On Wed, Jul 02, 2014 at 09:48:18AM +0200, Jakub Jelinek wrote:
Hi!
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.
On Wed, Jun 25, 2014 at 01:41:02AM +0200, FX wrote:
If I remove the previously installed gcc, the failure again occurs.
So, it looks like the testsuite is picking up installed *.mod files
over the freshly built *.mod files. This is not a showstopper.
And this is not all the testsuite,
On Tue, Jun 24, 2014 at 10:11:32AM +0200, FX wrote:
Here?s a patch fixing the diff issue with configure.host and the doc (which
apparently is only triggered by some versions of texinfo).
Apart from that, functionnaly identical, so I?ll paste here the ?history? of
the patch:
On Tue, Jun 24, 2014 at 09:49:36AM -0700, Steve Kargl wrote:
Not yet.
On i386-*-freebsd
In file included from ../../../gcc4x/libgfortran/runtime/fpu.c:29:0:
./fpu-target.h: In function 'set_fpu_trap_exceptions':
./fpu-target.h:31:3: error: unknown type name 'fp_except'
fp_except cw
On Tue, Jun 24, 2014 at 08:34:23PM +0200, Tobias Burnus wrote:
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
On Tue, Jun 24, 2014 at 09:43:06PM +0200, FX wrote:
Thanks for testing on a platform I don?t have access to! I try to
answer to the three main points below:
I suppose I don't understand the logic in libgfortran/configure.host.
It is picking the wrong config/fpu*.h file.
1. This is a
On Tue, Jun 24, 2014 at 10:26:27PM +0200, FX wrote:
3. Does the attached updated patch (libgfortran only, without
regenerated files) fix the problem?
I'll test it when my regtesting is completed. But, a scan of
the configure.host re-arrangement suggests that it should work.
OK.
I meant to look this over this weekend. Unfortnately, baseball
and soccer (both daughter and USA vs Portugal) got in the way.
First issue,
cd gcc4x
patch ieee_withregenerated_2.diff
...
--
|Index: configure.host
On Mon, Jun 23, 2014 at 12:23:39PM -0700, Steve Kargl wrote:
I meant to look this over this weekend. Unfortnately, baseball
and soccer (both daughter and USA vs Portugal) got in the way.
First issue,
cd gcc4x
patch ieee_withregenerated_2.diff
...
--
|Index
On Fri, Jun 06, 2014 at 06:21:02PM +0200, FX wrote:
Hi all,
Our Fortran 2003 status page [1] says gfortran does not support Kind type
parameters of integer specifiers?. This item is defined thusly (item 4.9 in
[2]):
Some of the integer specifiers (e.g. NEXTREC) were limited to default
On Fri, Jun 06, 2014 at 09:38:06PM +0200, FX wrote:
It seems that some of these extensions are not caught by -std=f95
I?ve now audited the I/O specifiers for such warnings too. A warning existed
only for EXIST, which was introduced way back by Steve:
2010-07-05 Steven G. Kargl
On Tue, May 27, 2014 at 09:44:22AM +0200, Uros Bizjak wrote:
... to avoid implicit declaration of function ???free??? warning.
2014-05-27 Uros Bizjak ubiz...@gmail.com
* intrinsics/getcwd.c: Include stdlib.h.
Tested on x86_64-pc-linux-gnu.
OK for mainline?
Yes.
It can also
On Mon, May 26, 2014 at 01:00:56PM +0300, Janne Blomqvist wrote:
On Mon, May 26, 2014 at 1:25 AM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
On Mon, May 26, 2014 at 12:21:21AM +0300, Janne Blomqvist wrote:
Hi,
GFortran currently uses strftime(...,%c,...) to produce the result
On Mon, May 26, 2014 at 12:21:21AM +0300, Janne Blomqvist wrote:
Hi,
GFortran currently uses strftime(...,%c,...) to produce the result
for the CTIME and FDATE intrinsics. Unfortunately, it seems that on
MinGW this does not produce identical output to the C stdlib ctime(),
even in the
On Mon, May 19, 2014 at 11:40:06PM +0300, Janne Blomqvist wrote:
Hello,
some systems such as GNU Hurd, don't define PATH_MAX at all, and on
some other systems many syscalls apparently work for paths longer than
PATH_MAX. Thus GFortran shouldn't truncate paths to PATH_MAX
characters, but
On Wed, Mar 26, 2014 at 06:56:15PM +0100, Dominique Dhumieres wrote:
Updated patch. OK to commit?
Dominique
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (revision 208846)
+++ gcc/fortran/ChangeLog
On Thu, Mar 20, 2014 at 08:24:49PM +0100, Tobias Burnus wrote:
gfortran's modules are since GCC 4.9 zipped. There are two functions,
which test for the existence and absent of strings in the .mod files.
While one was updated to apply gunzip before reading, the other wasn't.
This patch
On Sat, Mar 08, 2014 at 02:44:16PM +0100, Tobias Burnus wrote:
gfortran currently tells the ME that it wants it - even if it is not
needed when only preprocessing a file (-E). This patch fixes this by
telling the ME that no_backend is required - and then by triggering an
early exit in
On Sat, Mar 08, 2014 at 07:50:53PM +0100, Tobias Burnus wrote:
OK for the trunk?
diff --git a/libgfortran/libgfortran.h b/libgfortran/libgfortran.h
index d7e15ad..2664e1f 100644
--- a/libgfortran/libgfortran.h
+++ b/libgfortran/libgfortran.h
@@ -97,6 +97,16 @@ typedef off_t gfc_offset;
On Sun, Mar 02, 2014 at 02:49:20PM -0800, Jerry DeLisle wrote:
For this patch I chose to stay consistent with what we currently do. I can
change it to standard conforming. Anyone else have any comments on this?
I would prefer standard conformance, but I'm not the one doing the
work (so
On Sat, Feb 22, 2014 at 04:38:52PM +0100, Mikael Morin wrote:
+
+bool
+gfc_deferred_strlen (gfc_component *c, tree *decl)
+{
+ char name[GFC_MAX_SYMBOL_LEN+1];
Shouldn't this be +2?
+ gfc_component *strlen;
+ if (!(c-ts.type == BT_CHARACTER c-ts.deferred))
+return false;
On Fri, Feb 14, 2014 at 10:51:14PM +0100, Mikael Morin wrote:
Hello,
this bug is not a regression, but the patch shouldn't wreck the compiler
too much on the other hand.
The problem is a wrong number of arguments while generating code for the
ichar intrinsic. The correct number is 2
On Tue, Feb 11, 2014 at 09:38:20PM +0100, Jakub Jelinek wrote:
Optional dummy arg support vars are often undefined in various paths,
while the predicated uninit analysis can sometimes avoid false positives,
sometimes it can't. So IMHO we should set TREE_NO_WARNING here, it is
already set on
On Mon, Feb 10, 2014 at 05:23:39PM +0200, Janne Blomqvist wrote:
On Sun, Feb 9, 2014 at 2:40 AM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
All,
Here is a potentially contentious patch for PR fortran/52879.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52879
As demonstrated
On Sun, Feb 09, 2014 at 03:31:09PM +0100, Dominique Dhumieres wrote:
Steve,
First, it is needed to remove the line
mpz_t put_size, get_size;
in gcc/fortran/check.c, otherwise compiling the file with -Werror
(default) fails.
OK.
Second, the patch breaks the interface of
On Sat, Feb 08, 2014 at 10:07:23PM +0100, Dominique Dhumieres wrote:
Is the following patch OK?
Dominique
2014-02-08 Dominique d'Humieres domi...@lps.ens.fr
PR fortran/34928
* fortran/gfortran.texi: Document Volatile COMMON as not
suppoerted.
s/suppoerted/supported
All,
Here is a potentially contentious patch for PR fortran/52879.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52879
As demonstrated in that PR, it is possible to provide RANDOM_SEED
with sets of seeds that result in a very poor sequences of PRN.
Gfortran's RANDOM_NUMBER uses 3 independent KISS
On Sat, Jan 11, 2014 at 09:27:44AM -0800, Jerry DeLisle wrote:
My apologies please. I forgot to mention Dominiq for his
superb assistance with this patch and testing. Many thanks!
Add Dominiq to the ChangeLog entry. I think the patch
is OK.
--
Steve
On Mon, Jan 06, 2014 at 11:28:51PM +0100, Janus Weil wrote:
here is a regression fix for polymorphic deallocation. The attached
patch is identical in functionality to the one-liner in comment 13 of
the PR, fixing a bug in the detection of finalizable components (with
include allocatable
On Wed, Jan 01, 2014 at 07:49:16PM -0800, Mike Stump wrote:
On Nov 23, 2013, at 12:16 PM, Steve Kargl s...@troutmask.apl.washington.edu
wrote:
On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote:
Richi has asked the we break the wide-int patch so that the
individual port and front end
On Mon, Dec 30, 2013 at 06:03:30PM +0100, Janus Weil wrote:
I even volunteer to make a start with the one mentioned in the subject
line. The fix is actually easy once you know where to look (which was
simplified a lot by Dominique's efforts to identify the blameworthy
commit).
The rather
I committed the following changes to gfortran's runtime library.
It converts an assert on an invalid floating-point exponent into
a runtime error.
2013-12-18 Steven G. Kargl ka...@gcc.gnu.org
* io/read.c (read_f): Convert assert to runtime error.
2013-12-18 Steven G. Kargl
On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote:
Richi has asked the we break the wide-int patch so that the individual port
and front end maintainers can review their parts without have to go through
the entire patch.This patch covers the fortran front end.
Ok?
+
On Sat, Nov 23, 2013 at 01:31:04PM -0800, Andrew Pinski wrote:
On Sat, Nov 23, 2013 at 12:16 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote:
Richi has asked the we break the wide-int patch so that the individual
port
On Sun, Nov 17, 2013 at 11:29:50AM +0100, FX wrote:
This patch fixes libgfortran?s binary128 [aka real(kind=16)] variant of
ERFC_SCALED. The original code, which I had lifted from netlib, gives only 18
significant decimal digits, which is not enough for binary128 (33 decimal
digits).
I
On Wed, Nov 20, 2013 at 09:13:14PM +0100, FX wrote:
There is a missed optimization in
+ if (x 12)
+{
+ /* Compute directly as ERFC_SCALED(x) = ERFC(x) * EXP(X**2).
+This is not perfect, but much better than netlib. */
+ return erfcq(x) * expq(x*x);
+}
The inlined patch fixes a problem where an array constructor
is used as the shape argument in RESHAPE. The patch is
straightforward and self-explanatory.
Regression tested on x86_64-*-freebsd11
Ok?
2013-11-05 Steven G. Kargl ka...@gcc.gnu.org
PR fortran/58989
* check.c
On Mon, Nov 04, 2013 at 09:58:30PM +0100, Tobias Burnus wrote:
Tobias Burnus wrote:
Gerald Pfeifer wrote:
To make it easier to reproduce builds of software and entire GNU/Linux
distributions, RMS had the idea of adding a warning to GCC that warns
about the use of __DATE__ and __TIME__.
On Fri, Nov 01, 2013 at 04:56:36PM +0100, Paul Richard Thomas wrote:
This one is trivial. The ICE was caused by an assert that turns out
to be spurious and has been removed.
Bootstrapped and regtested on FC17/x86_64 - OK for trunk and 4.8?
OK.
--
Steve
On Tue, Oct 22, 2013 at 08:30:44PM +0200, Tobias Burnus wrote:
Two weeks ago I submitted the patch, available at:
http://gcc.gnu.org/ml/fortran/2013-10/msg00022.html ; while the ME patch
is not yet approved, the C FE was approved (latest C/ME patch:
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 myself yet, but is this
On Mon, Oct 21, 2013 at 09:04:22PM +0200, Tobias Burnus wrote:
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);
(see below)
+c-tb
On Wed, Oct 09, 2013 at 11:51:30PM +0200, Tobias Burnus wrote:
A rather obvious fix; the memory is freed by the caller
(gfc_simplify_compiler_options). It is unlikely that the compiler has no
arguments as the driver tends to send some, e.g. -mtune=generic
-march=x86-64 on my system.
On Wed, Sep 11, 2013 at 09:54:57PM -0700, Brooks Moses wrote:
Ping^3?
There is little to no Fortran specific content, which
requires a Fortran review. If no one steps up, just
commit the change.
--
Steve
On Wed, Jul 24, 2013 at 11:53:09PM +0200, Janus Weil wrote:
Hi all,
here is a straightforward patch for an ICE-on-invalid problem, which
basically adds some checks for 'class_ok'.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
OK.
--
Steve
On Mon, Jul 22, 2013 at 07:17:50PM +0200, Tobias Burnus wrote:
For coarrays, an assignment does not affect the allocation status. That
also implies that the type parameters, shape and effective types between
the LHS and RHS have to match.
For coarrays components, that's handled (since Rev.
On Fri, Jun 07, 2013 at 04:03:52PM +0200, Tobias Burnus wrote:
Unreviewed patches:
* http://gcc.gnu.org/ml/fortran/2013-06/msg00027.html
* http://gcc.gnu.org/ml/fortran/2013-06/msg00048.html
* * *
As with ALLOCATE (type-spec :: ...), also array constructors take as
type-spec a type
On Fri, May 17, 2013 at 03:18:01PM +0300, Janne Blomqvist wrote:
Hi,
the example we provide for the usage of the random_seed intrinsic
could be better. At least one user has already been tripped over by
the fact that on some targets the first call to system_clock returns
0, resulting in a
On Sat, May 04, 2013 at 10:25:19PM -0700, Jerry DeLisle wrote:
On 05/04/2013 06:30 PM, Steve Kargl wrote:
On Sat, May 04, 2013 at 05:13:51PM -0700, Jerry DeLisle wrote:
CASE_SEPARATORS:/* Not a repeat count. */
case EOF:
+ case '!':
if (c
On Sat, May 04, 2013 at 05:13:51PM -0700, Jerry DeLisle wrote:
CASE_SEPARATORS:/* Not a repeat count. */
case EOF:
+ case '!':
if (c == '!')
gfc_warning(GNU Fortran extension: accepting a possibly
corrupted namelist);
goto
On Thu, May 02, 2013 at 05:46:55PM +0200, Tobias Burnus wrote:
Instead of using the return size value directly, the code converted it
first to an int and then back into a GMP number. This patch now directly
uses the mpz value.
Additionally, I added range checks - to print the proper
On Tue, Apr 30, 2013 at 11:47:46PM +0200, Thomas Koenig wrote:
+ e-value.op.op1 = NULL;
+ e-value.op.op2 = NULL;
+ mpz_init_set_si (e-value.integer, 1);
+ /* Typespec cand location are still OK. */
s/cand/and
--
steve
On Sun, Apr 28, 2013 at 10:32:28AM +0200, Thomas Koenig wrote:
Hello world,
the attached patch does some optimization on
power using ishft and iand, as discussed in the PR.
I have left out handling real numbers, that should be left
to the middle-end (PR 57073).
Regression-tested. OK
On Wed, Apr 10, 2013 at 09:18:46AM -0700, Mike Stump wrote:
On Apr 9, 2013, at 11:33 AM, Janne Blomqvist blomqvist.ja...@gmail.com
wrote:
the attached patch reduces the size of module files on disk
Do those modules interoperate with C++ modules flawlessly? :-)
Fortran 2008 became an ISO
On Mon, Mar 11, 2013 at 06:39:37PM +0100, Tobias Burnus wrote:
*ping*
Tobias Burnus:
During the discussion of UNION, I decided to have a look at the
current documentation. UNION is not mentioned (except for some
commented lines), but record structures are. Attached is an attempted
On Wed, Feb 13, 2013 at 07:20:10PM +0100, Tobias Burnus wrote:
*** PING ***
I think it is now a bit late for 4.8. Thus, I change my request to: OK
for the 4.9 trunk?
IMHO, yes. Don't know if others have an opinion, but
waiting any longer would seem to be counter productive.
--
Steve
On Sat, Feb 09, 2013 at 02:14:53PM +0100, Thomas Koenig wrote:
Am 09.02.2013 11:22, schrieb Tobias Burnus:
Why did you put a FIXME there? What's wrong with adding the directory here?
I think module files are different enough from include files that I
would like to have them in different
On Wed, Jan 23, 2013 at 09:18:45PM +0100, Janus Weil wrote:
here is a regression fix for an ICE-on-invalid bug with SELECT CASE.
The check to reject non-scalar selectors had been present in 4.6, but
was apparently removed when CLASS arrays were implemented.
The patch re-inserts the check
On Sun, Jan 20, 2013 at 08:49:38PM +0100, Thomas Koenig wrote:
Hello world,
the attached patch fixes a regression where -J dirpath/ would
issue a warning on Windows because of the trailing dir separator.
Regression-tested, but only on Linux. I would appreciate if
somebody could also test
On Fri, Jan 18, 2013 at 01:19:37AM +0200, Janne Blomqvist wrote:
the attached patch gets rid of the enum try in the Fortran runtime
library, replacing its usage with the standard C99 _Bool/bool.
Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
2013-01-18 Janne Blomqvist
On Tue, Jan 08, 2013 at 10:06:17PM +0100, Mikael Morin wrote:
a small, unexciting bug.
For the case:
subroutine m()
use m
end subroutine m
the USE statement is rejected, but it is not if the subroutine is contained.
In the latter case, the namespace of the symbol of the
On Mon, Jan 07, 2013 at 11:57:27PM +0100, Paul Richard Thomas wrote:
Dear All,
This is a rather 'obvious' fix that returns gfortran to full
compliance in the IVS testsuite. The testcase checks that various
other combinations of arguments to elemental procedures work
correctly.
I gave up
On Tue, Jan 08, 2013 at 07:20:19AM +0100, Paul Richard Thomas wrote:
Dear Steve,
Thanks - committed as revision 195004.
I should also have asked if it's OK for 4.6 and 4.7?
Yes, it is okay with the usual 2 to 3 days
of cooking on trunk before committing. Of
course, as you noted the
On Sun, Jan 06, 2013 at 05:52:23PM +0100, Tobias Burnus wrote:
PS: If there is consensus that this patch is a bad idea, I propose to
reject non-C_BOOL LOGICALs unconditionally as dummy argument or result
variable of BIND(C) procedures. Or do you have a better suggestion?
IMHO, I think
On Mon, Dec 31, 2012 at 01:17:04PM +0100, Tobias Burnus wrote:
The attached patch adds a new - internal only - intrinsic, STRIDE, which
returns the stride of an array with array descriptor; for an integer ::
array(5,5), the stride of dim=2 is 5.
This new intrinsic is only internally
On Mon, Dec 31, 2012 at 08:19:49PM +0100, Tobias Burnus wrote:
Hi Steve,
Steve Kargl:
On Mon, Dec 31, 2012 at 01:17:04PM +0100, Tobias Burnus wrote:
This new intrinsic is only internally available and will be used by the
finalization wrapper to handle noncontiguous arrays.
What
On Mon, Sep 17, 2012 at 07:34:12PM +0200, Tobias Burnus wrote:
gfortran shouldn't simplify SCAN/VERIFY if the BACK= argument is present
but not a constant.
Build and regtested on x86-64-linux.
OK for the trunk?
OK.
--
Steve
On Wed, Sep 05, 2012 at 11:55:54PM +0200, Tobias Burnus wrote:
Rather obvious fix.
Build on x86-64-linux.
OK for the trunk when regtesting has succeeded?
Yes.
--
Steve
On Wed, Aug 22, 2012 at 10:47:34PM +0200, Thomas Koenig wrote:
Am 22.08.2012 11:18, schrieb Tobias Burnus:
Regarding -Wcompare-real, I wonder whether it makes sense to either
ignore comparisions against zero or to put them into a different flag
(-Wcompare-real-zero);
Here is a patch to
On Sat, Jul 07, 2012 at 11:28:25PM +0200, Steven Bosscher wrote:
Currently, gcc/flags.h and fortran/gfortran.h both include
coretypes.h. In many fortran/*.c files, flags.h is included before
gfortran.h, so when flags.h no longer includes coretypes.h (xf.
On Fri, Jun 08, 2012 at 12:40:10PM +0200, Janus Weil wrote:
[Side note: The piece of code which I'm moving contains a FIXME
comment, which I don't quite understand, so I'm not sure whether it is
still valid. It was added by Steve in
http://gcc.gnu.org/viewcvs?view=revisionrevision=145331.
On Fri, Jun 08, 2012 at 07:10:02PM +0200, Janus Weil wrote:
[Side note: The piece of code which I'm moving contains a FIXME
comment, which I don't quite understand, so I'm not sure whether it is
still valid. It was added by Steve in
http://gcc.gnu.org/viewcvs?view=revisionrevision=145331.
On Mon, Mar 26, 2012 at 06:17:08PM +0300, Janne Blomqvist wrote:
currently in libgfortran we have two malloc() wrappers, get_mem and
internal_malloc_size, which abort the program if malloc fails.
internal_malloc_size does
if (size == 0)
size = 1;
and then calls get_mem, which
On Sat, Mar 03, 2012 at 08:44:56AM +0100, FX wrote:
PR 36044 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044) is an
enhancement request for a way to display backtraces from user code. I'm
against adding yet another nonstandard intrinsic for this purpose (which is
how Intel Fortran does
On Sat, Mar 03, 2012 at 10:53:24AM +0100, FX wrote:
Hi all,
Attached patch was triggered by PR 52313
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52313), and tries to improve
error messages for module reading. It fixes one spelling of GFORTRAN --
GNU Fortran and improves the error
On Sat, Mar 03, 2012 at 03:23:01PM +0100, Tobias Burnus wrote:
GNU Fortran warns by default for code like the following:
interface
subroutine sub (n) bind (C)
integer :: n
end subroutine sub
end interface
Namely, it prints:
Warning: Variable 'n' at (1) is a parameter to the
On Wed, Feb 29, 2012 at 08:27:42AM +0100, Paul Richard Thomas wrote:
Regression fix okayed by Tobias Burnus on #gfortran and committed as
revision 184651.
Cheers
Paul
Thanks!
Just a reminder. Did you get approval from the
Release Mananger? The last GCC 4.7.0 status
reported indicated
On Wed, Feb 22, 2012 at 10:55:14AM +0100, Tobias Burnus wrote:
The following patch fixes a 4.4 to 4.7 regression. Already Fortran 95
allows DELIM= in OPEN and INQUIRE. Fortran 2003 only added it to data
transfer statements (i.e. WRITE; not allowed for READ and not possible
for PRINT). Cf.
On Wed, Feb 08, 2012 at 06:46:03PM +0100, Tobias Burnus wrote:
this patch is a follow up to the recent patch on RESHAPE with an
allocatable LHS. It turned out that if the LHS is not allocated or has
the wrong shape, the bounds are not correctly set. Or to be precise: The
just internally
On Wed, Feb 01, 2012 at 12:07:35AM +0100, Thomas Koenig wrote:
Hi Tobias,
here is an updated version of the patch, with a more extensive test
case. Also regression-tested.
OK for trunk?
+ /* Insert the new IF after the ELSE. */
+ else_stmt-expr1 = NULL;
+ else_stmt-next
On Wed, Feb 01, 2012 at 12:47:28AM +0100, Thomas Koenig wrote:
Hi Steve,
+ else_stmt-expr1 = NULL;
+ else_stmt-next = c_if1;
+ else_stmt-block = NULL;
+ else_stmt-next = c_if1;
Is one of the else_stmt-next = c_if1; redundant?
Definitely. I'll take it out when I
On Wed, Jan 25, 2012 at 09:27:51PM +0100, Tobias Burnus wrote:
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
I've committed the following patch after successful
build and regression testing and Tobias' approval
in private email.
2012-01-21 Tobias Burnus bur...@net-b.de
Steven G. Kargl ka...@gcc.gnu.org
PR fortran/50556
* symbol.c (check_conflict): namelist-group-name
On Thu, Jan 19, 2012 at 08:23:58PM +0100, Tobias Burnus wrote:
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.)
Yes. Almost looks obvious (except I've read the
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?
PS: Is there a ChangeLog file for the wwwdoc repository?
--
Steve
Index:
On Sun, Jan 15, 2012 at 01:39:23PM -0500, Zydrunas Gimbutas wrote:
Hi,
Everything seems to be ok in this patch, except for minor typos in
documentation: REAl - REAL, alignement - alignment.
Good catch.
It would also be nice to extend the type conversion facility to
include
On Wed, Nov 09, 2011 at 06:09:58PM -0500, Andreas Kloeckner wrote:
Hi there,
please find attached the patch and the Changelog entry for our work on
the fortran bug #48426.
The attached patch implements the options
-finteger-4-integer-8
-freal-4-real-8
-freal-4-real-10
On Mon, Jan 09, 2012 at 03:38:21PM +0100, Tobias Burnus wrote:
Ok for the trunk? (Build + make pdf tested)
Tobias
The two which clauses in the 1st sentence seem awkward. How
about the following changes? OK, after considering the suggested
changes.
+@item Generic interface name which have
On Mon, Jan 09, 2012 at 08:21:31PM +0100, Tobias Burnus wrote:
With the patch, one can get (cf. PR) an output to STDERR like:
Program received signal 8 (SIGFPE): Floating-point exception.
Backtrace for this error:
#0 0x805891F in _gfortrani_show_backtrace at backtrace.c:261
#1
On Fri, Dec 30, 2011 at 10:38:03AM +0100, Jakub Jelinek wrote:
On Thu, Dec 29, 2011 at 08:12:51PM -0800, Steve Kargl wrote:
The audit trail in the PR pretty much sums up the problem.
OK to commit?
Can you tune up the comments a little bit?
If you look up http://gcc.gnu.org/gcc-4.7
The audit trail in the PR pretty much sums up the problem.
OK to commit?
2011-12-29 Steven G. Kargl ka...@gcc.gnu.org
* inclhack.def: Disgusting hack to workaround brain damage of
defining __cplusplus as 201103L with -std=c++11 when g++ does
not support c++11.
On Wed, Dec 28, 2011 at 04:21:55PM +0100, Thomas Koenig wrote:
http://gcc.gnu.org/ml/fortran/2011-12/msg00102.html
OK for trunk?
I did not test the patch, but it appears correct to me.
OK.
--
Steve
On Tue, Dec 27, 2011 at 12:52:19PM +0100, Dominique Dhumieres wrote:
-freal-4-real-8 is not equivalent to -fdefault-real-8 and
-fdefault-double-8.
-freal-4-real-8 interprets any 4-byte real type, whether it is a
default real type or explicitly declared as 4-byte, as a 8-byte double
On Mon, Dec 26, 2011 at 05:14:46PM +0100, Dominique Dhumieres wrote:
I regression tested the patch on i686-*-freebsd. No problems occurred.
Can one of the other gfortran reviewers/committers cast a quick glance
over the patch. I would like to commit this within next day or two.
I have
On Mon, Dec 26, 2011 at 09:28:01AM -0800, Steve Kargl wrote:
On Mon, Dec 26, 2011 at 05:14:46PM +0100, Dominique Dhumieres wrote:
I regression tested the patch on i686-*-freebsd. No problems occurred.
Can one of the other gfortran reviewers/committers cast a quick glance
over the patch
On Wed, Nov 09, 2011 at 06:09:58PM -0500, Andreas Kloeckner wrote:
please find attached the patch and the Changelog entry for our work on
the fortran bug #48426.
The attached patch implements the options
-finteger-4-integer-8
-freal-4-real-8
-freal-4-real-10
-freal-4-real-16
On Wed, Nov 09, 2011 at 06:09:58PM -0500, Andreas Kloeckner wrote:
Hi there,
please find attached the patch and the Changelog entry for our work on
the fortran bug #48426.
The attached patch implements the options
-finteger-4-integer-8
-freal-4-real-8
-freal-4-real-10
On Mon, Dec 19, 2011 at 06:54:08PM +0100, Toon Moene wrote:
The attached patch makes -finit-type=constant generate default
initialization for automatic arrays.
It was OK for the trunk - is it also OK for the 4.6 branch ?
Strictly speaking, it doesn't fix a regression, it is a fix for a
1101 - 1200 of 1283 matches
Mail list logo
