were not walked.
This patch corrects these things. Regression-tested.
OK for trunk? (I will not be able to commit for a few
days due to business travel, unless somebody is _really_
fast :-)
Thomas
2011-10-16 Thomas Koenig
* frontend-passes.c (current_ns): Make static
Steven Bosscher wote:
This patch corrects these things. Regression-tested.
OK for trunk? (I will not be able to commit for a few
days due to business travel, unless somebody is _really_
fast :-)
Looks OK to me. Fast enough for you?
Yes indeed. Committed as rev. 180063.
Thanks a lot!
homas
2011-10-21 Thomas Koenig
PR fortran/50690
* frontend-passes.c (workshare_level): New variable.
(create_var): Put the newly created variable into the block
around the WORKSHARE.
(enclose_workshare): New callback function to enclose
WORKSHAR
trunk?
Thomas
2011-10-21 Thomas Koenig
PR fortran/50690
* frontend-passes.c (workshare_level): New variable.
(create_var): Put the newly created variable into the block
around the WORKSHARE.
(enclose_workshare): New callback function to enclose
WORKSHAREs in blocks.
(optimize_namespace): U
Hi Tobias,
I'm just back from holiday, which it took me a bit longer to reply.
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 "-fdump-tree-original", one finds:
#pragma omp parallel default(shared)
Hello world,
the attached patch warns about comparisions for equality and inequality
of real and complex values if -Wcompare-reals is given. The new
compiler option is included in -Wall.
Regression-tested, tested with "make info" and "make dvi".
OK for trunk?
Thomas
2012-08-19 Thomas
Hi Tobias,
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
I would exclude pointers on the lhs of the pointer assignment, to make
sure that warnings for code such as
program main
integer :: i
integer, pointer :: ip
block
integer, pointer :: jp
allocate (jp)
jp = 3
Hi Tobias,
Am 19.08.2012 21:19, schrieb Thomas Koenig:
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
I would exclude pointers on the lhs of the pointer assignment,
I assume you mean RHS – excluding LHS pointers in pointer assignments is
kind of difficult ;-)
Sometimes I have
Hi Tobias,
do you think that -Wtarget-lifetime should be included with -Wall?
I think so, because the code flagged is certainly invalid, and likely
to cause random errors.
Thomas
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 not warn for comparisons against zero.
Regression-tested, also tested
Hi Tobias,
while -Wcompare-reals is a useful option to find bugs, practical
experience and the discussion here and on c.l.f has shown that this
option has too many false positives. Hence, it is not suitable for -Wall.
With patch, -Wall no longer implies -Wcompare-reals.
Build on x86-64-linu
Hello world,
the attached patch sets -Wcompare-reals from -Wextra. It also
dcouments a few cases (found while browsing the source) of
options included in -Wall in invoke.texi. It also allows easy
adding of other warning options to -Wextra.
Regression-tested. OK for trunk?
Thomas
2012-
Hello world,
pretty self-explanatory. No test case because there is no change
in behavior. OK for trunk?
Thomas
2012-09-18 Thomas König
PR fortran/54599
* dependency.c (gfc_dep_compare_expr): Clarify logic,
remove dead code.
Index: dependency.c
==
Am 18.09.2012 20:46, schrieb Thomas Koenig:
Hello world,
pretty self-explanatory. No test case because there is no change
in behavior. OK for trunk?
I forgot to add: Regression-tested.
Thomas
I wrote:
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01293.html
pretty self-explanatory. No test case because there is no change
in behavior. OK for trunk?
Hello world,
the attatched patch (this time for real!) implements
-Wextra for the Fortran front end, and adds -fcompare-reals
to -Wextra.
@manu: In the PR, you mentioned that it would be nice if
LangEnabledBy was used in the opt files. I tried adding that
to the common.opt file for Wextra, but
Am 23.09.2012 23:46, schrieb Manuel López-Ibáñez:
However, the
actual problem seems to be that gfortran uses their own option
variables and not the ones generated by the common machinery (which
are generated in any case, so it is a bit of a waste to duplicate
them).
It is up to the gfortran mai
Hello world,
not much to say, the patch is pretty straightforward.
Regression-tested. OK for trunk?
Thomas
2012-09-24 Thomas König
PR fortran/52724
* list_read.c (next_char): Handle kind=4 characters.
* unix.c (open_internal4): Correct lenth of internal fil
Hi Tobias,
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
OK.
Thanks a lot for the patch!
Thomas
Hi Tobias,
This patch fixes the stride setting for cshift1; hence, it fixes
gfortran.dg/optional_dim_3.f90.
Build and regtested on x86-64-linux - 13 failing tests remain.
OK?
OK. Thanks for the patch!
Thomas
Hello world,
this fixes an ICE with allocation of coarrays. Regression-tested.
OK for trunk? What about 4.7?
Thomas
2012-07-15 Thomas König
PR fortran/53824
* resolve.c (resolve_allocate_deallocate): If both
start indices are NULL, skip the test for equal
Hello world,
the attached, rather obvious patch emits warnings for several
cases where there is something wrong with include directories.
No test case because I couldn't figure out how to test for a
warning with no line number.
OK for trunk?
Thomas
2012-07-26 Thomas König
P
Hi Janis,
On 07/26/2012 10:16 AM, Thomas Koenig wrote:
No test case because I couldn't figure out how to test for a
warning with no line number.
Try using line number 0.
That didn't work for me. Using
! { dg-do compile }
! { dg-options "-I include_6.f90 -I missing_dir&qu
Hello world,
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?
Thomas
2012-07-29 Thomas König
PR fortran/54033
* scanner.c (add_path_to_list): Emit warning if
Hi Tobias,
> I am not sure whether it is the best solution, but one possibility would
be to ignore -fintrinsic-modules-path for the warning. (That assumes
that the warning is (almost) never needed for an installed compiler.)
I think this is the right approach. The attached patch does this.
Re
Hi,
OK for trunk?
I will be on holiday starting tomorrow, so I would like to commit
this today, if possible (with a mistake in the ChangeLog noted
by Uros fixed. Thanks!)
If not, somebody please commit this (or another fix).
Thomas
Hello world,
I have committed the attached patch as obvious as rev. 186942
after regression-testing. Will also commit to 4.7 in a few
days.
Thomas
2012-04-29 Thomas Koenig
PR fortran/53148
* frontend-passes.c (create_var): If the statement has a label,
put
is why I didn't ping it. So, thanks
for remembering!
Thomas Koenig wrote on Fri, 13 Apr 2012:
this patch replaces a != '' with len_trim(a) != 0, to
speed up the comparison.
I wonder how much it helps - especially for the real world
code. Let's see whether the bug repor
Hi Tobias,
ASSOCIATE names are (wrongly) initialized by -finit-real=*, thus, their
values are wrong.
The fix seems to be rather obvious, but I am not really an associate
expert.
I'd say it is obvious. OK for trunk, also OK for backporting.
I am unsure whether to put it into 4.7.1, though. Opi
Hello world,
this 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?
Thomas
2012-06-06 Thomas König
PR fortran/52861
* frontend-passes (empty_string): Add protot
Hello world,
my recent patch introduced a regression with deferred-length
characters. I have committed the attached patch as obvious
to fix this.
Regards
Thomas
2012-06-07 Thomas König
PR fortran/52861
* frontend-passes.c (optimize_assignment): Don't set the
nt to gfc_target_interpret_expr because for a
TRANSFER, we want a binary copy and not a conversion between wide and
normal characters.
Regression-tested. OK for trunk?
Thomas
2011-08-05 Thomas Koenig
PR fortran/37221
* gfortran.h (gfc_calculate_transfer_sizes): Add prot
Hi Janus,
The patch is rather large, but most of it is just mechanical, due to
the fact that I added an extra argument to 'gfc_dep_compare_expr'. I
use this function to compare the string-length expressions of a
character-valued TBP and an overriding procedure (the standard
requires them to be e
Am 05.08.2011 23:57, schrieb Thomas Koenig:
Committed as rev. 177486.
Looks like this caused a regression in c_ptr_tests_16.f90.
Don't know why, am investigating.
Thomas
2011-08-06 Thomas Koenig
PR fortran/50004
* target-memory.c (gfc_target_expr-size): Don't clobber typespec
for derived types.
* simplify.c (gfc_simplify_transfer): Don't calculate source_size
twice.
In
Hi Janus,
2011/8/5 Mikael Morin:
On Friday 05 August 2011 23:02:33 Thomas Koenig wrote:
The extra
argument controls whether we check variable symbols for equality or
just their names. For the overriding checks it is sufficient to check
for names, because the arguments of the overriding
Am 06.08.2011 18:16, schrieb Janus Weil:
without any regressions. Can anybody think of a case where the names can be
> identical, but the variables different? (I can't).
Well, I'd say this can only happen if both variables reside in
different namespaces (i.e. different modules or procedures).
Hi Janus,
+ /* Check string length. */
+ if (proc_target->result->ts.type == BT_CHARACTER
+ && proc_target->result->ts.u.cl&& old_target->result->ts.u.cl
+ && gfc_dep_compare_expr (proc_target->result->ts.u.cl->length,
+ old_target->resu
Am 06.08.2011 21:26, schrieb Janus Weil:
Hi Thomas,
+ /* Check string length. */
+ if (proc_target->result->ts.type == BT_CHARACTER
+&&proc_target->result->ts.u.cl&&old_target->result->ts.u.cl
+&&gfc_dep_compare_expr (proc_target->result->ts.u.cl->length,
+
Am 06.08.2011 23:10, schrieb Janus Weil:
I'm know that this does not exactly fit in any of your categories.
However, I still think that throwing an error for every case where we
can not prove that the expressions are equal is a good approximation
for the purpose, and everything beyond that is mos
Hi Janus,
Here is a preparational patch (basically a subset of the
previous one), which does not do any real changes yet, only some
preparation and cleanup:
* It moves check_typebound_override to interface.c and prefixes it
with gfc_ (I don't like moving and modifying it at the same time).
* It
Am 07.08.2011 12:56, schrieb Janus Weil:
+ /* Check string length. */
+ if (proc_target->result->ts.type == BT_CHARACTER
+ && proc_target->result->ts.u.cl&& old_target->result->ts.u.cl
+ && gfc_dep_compare_expr (proc_target->result->ts.u.cl->length,
+
Am 07.08.2011 19:05, schrieb Janus Weil:
2011/8/7 Thomas Koenig:
Am 07.08.2011 12:56, schrieb Janus Weil:
+ /* Check string length. */
+ if (proc_target->result->ts.type == BT_CHARACTER
+&&proc_target->result->ts.u.cl&&old_target->result->t
Hello world,
the attached patch extends conversion warnings to assignments.
OK for trunk?
Thomas
011-08-14 Thomas Koenig
PR fortran/46659
* expr.c (gfc_check_assign): Check for type conversions when the
right-hand side is a constant REAL cor COMPLEX
I wrote:
Hello world,
the attached patch extends conversion warnings to assignments.
OK for trunk?
... and forgot to say that this has been regression-tested.
Thomas
Am 14.08.2011 22:54, schrieb Tobias Burnus:
Thomas Koenig wrote:
the attached patch extends conversion warnings to assignments.
OK for trunk?
I get now two warnings for:
complex(8), parameter :: z = cmplx (0.5, 0.5)
r = z
end
The problem is that gfc_check_assign is called twice for this
If we really wanted to do this The Right Way, there would be seven
cases to be considered, best expressed as three flags. I'll call them
CAN_BE_LESS, CAN_BE_EQUAL and CAN_BE_MORE.
Comparing a vs. a+1 would yield CAN_BE_LESS for integers and
CAN_BE_LESS | CAN_BE_EQUAL for floats.
Comparing 3 vs.
Hello everybody,
now that I have found a little time, here is an updated version of
the patch, which incorporates Tobias' suggestions. Regression-tested.
OK for trunk?
Thomas
2011-08-21 Thomas Koenig
PR fortran/47659
* expr.c (gfc_check_assign): Check for
Hello world,
I committed the attached patch as obvious after regression-testing.
Revision is 177940.
Will commit to 4.6 in a few days.
Thomas
2011-08-21 Thomas Koenig
PR fortran/50130
* resolve.c (resolve_array_ref): Don't calculate upper bound
i
Hello Tobias,
OK. Thanks for the patch!
Sende fortran/ChangeLog
Sende fortran/expr.c
Sende testsuite/ChangeLog
Sende testsuite/gfortran.dg/warn_conversion_2.f90
Hinzufügen testsuite/gfortran.dg/warn_conversion_3.f90
Übertrage Daten .
Revision 177942
Hi Tobias,
PPS: I am looking for someone to review my simple regression fix [4.3 to
4.7] at
http://gcc.gnu.org/ml/fortran/2011-08/msg00186.html
it *should* be safe - see last comment in the PR for a bit more context.
That one is OK.
Thanks!
Thomas
Am 25.08.2011 16:39, schrieb Tobias Burnus:
Scalar coarray components didn't use the array descriptor, which caused
all kinds of ICEs.
Fix by this relatively simple patch.
OK for the trunk?
OK (bordering on obvious, although I'm not sure which side of the border :-)
Thanks for the patch!
?
Thomas
2011-08-26 Thomas Koenig
PR libfortran/50192
* intrinsics/string_intrinsics.c (memcmp_char4): New function.
* intrinsics/string_intrinsics_inc.c: New macro MEMCMP, either
set to memcmp or memcmp_char4.
(compare_string): Use MEMCMP, with
Am 26.08.2011 14:40, schrieb Thomas Koenig:
OK for trunk? Which branches should this be backported to?
I forgot - also regression-tested.
Thomas
(just a comment change).
I'll send a separate e-mail about the one inconsistency left in a
few minutes.
Thomas
2011-08-28 Thomas Koenig
PR fortran/40866
* generated/iall_i1.c: Regenerated.
* generated/iall_i16.c: Regenerated.
* generated/iall
Hi Tobias,
I have attached an updated version, which actually implements do
concurrent in trans-stmt.c. Additionally, "CYCLE" without a label did
not work.
I think you also need to add support to frontend-passes.c.
Regards
Thomas
Hello world,
this patch fixes the same kind of problems that PR 49479 addressed,
by applying the same kind of fix to another class of function.
I have not bothered to find a test case. Regression-tested.
OK for trunk and (after a few days) for 4.6?
Thomas
2011-09-08 Thomas Koenig
scope, and the condition never
changes.
Thanks to Tobias for finding the bug and forthe analysis in the PR.
Regression-tested.
OK for trunk?
Thomas
2011-09-10 Thomas Koenig
PR fortran/50327
* frontend-passes.c (dummy_expr_callback): New function
Hi Tobias,
OK. Though, I find the ChangeLog entry a bit misleading: There is a
(zero-sized) return array.
I have changed the entry to
* generated/m4/ifunction.m4: Always call internal_malloc_size
even when there is a zero-sized return array
on commit.
Thanks for the review!
Unless, of course, somebody
else wants to do it *HINT*
Any comments? I was not planning on committing yet, because for the
more simple cases we actually hit an ICE with this patch instead of
a clean error message.
Regards
Thomas
2011-09-19 Thomas Koenig
PR fortran/36313
=1:2)
tmp = f(i)
a(i) = tmp
end forall
did the Wrong Thing. Oh well...
Regression-tested. OK for tunk?
Thomas
2011-10-09 Thomas Koenig
PR fortran/50564
* frontend-passes (forall_level): New variable.
(cfe_register_funcs): Don't register functions
geLog
===
--- fortran/ChangeLog (revision 179768)
+++ fortran/ChangeLog (working copy)
@@ -1,3 +1,12 @@
+2011-10-10 Thomas Koenig
+
+ PR fortran/50564
+ * frontend-passes (forall_level): New variable.
+ (cfe_register_funcs): Don't register functions if we
+ are within a f
Am 10.03.2012 11:19, schrieb Tobias Burnus:
Steven Bosscher wrote:
This cleans up some remnants of the ancestors of fortran's convert.c,
which was copied from GNAT IIRC. I would bootstrap&test this, but
trunk appears to be broken for x86_64-linux right now (ICE in
patch_jump_insn). But I can pos
Hi Tobias,
with that patch, the array descriptor on the fortran-dev branch uses now
the dimension triplet as defined in TS29113. This patch removes
ubound/stride and updates all calls.
Great!
There are still 227 test-suite failures ("FAIL" lines) affecting 27
test-suite files. That's slight
Hello world,
this patch uses division by known sizes (which can usually be replaced
by a simple shift because intrinsics have sizes of power of two) instead
of division by the size extracted from the array descriptor itself.
This should save about 20 cycles for a single calculation.
I'll go thr
Hello world,
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?
Thomas
2012-03-25 Tho
2012-04-06 Thomas Koenig
PR fortran/52893
* frontend-passes.c: Keep track of wether we are in an implicit
DO loop; do not do function elimination if we are.
2012-04-06 Thomas Koenig
PR fortran/52893
* gfortran.dg/function_optimize_11.f90: New test
Hi Paul,
OK for trunk and for 4.7.
Committed as rev. 186213.
As a matter of curiosity, why did you not inhibit common function
extraction when the function arguments contain an implicit loop
variable, rather than when they are in an implicit loop? That would
make the optimisation rather les
each record, and
would mean a major change to the way the code is structured.
The running time for the test case from PR 50673 is reduced
from ~8 s to 0.1 s by this patch.
Regression-tested. OK for trunk?
Thomas
2012-04-09 Thomas Koenig
PR libfortran/38199
PR libfortran/
Hi,
this patch uses division by known sizes (which can usually be replaced
by a simple shift because intrinsics have sizes of power of two) instead
of division by the size extracted from the array descriptor itself.
This should save about 20 cycles for a single calculation.
I'll go through the
Am 11.04.2012 10:01, schrieb Tobias Burnus:
Ping.
OK.
Thanks for the patch!
Thomas
Hi Michael,
could you replace
+ if (shift< 0 || shift>= len)
by
> + if (unlikely(shift< 0 || shift>= len))
? This could save a few more cycles.
Thomas
Am 10.04.2012 14:32, schrieb Thomas Koenig:
Hello world,
this patch effectively trims the spaces from the string on
list-directed reads. This avoids the large overhead on
processing these spaces when reading from long lines.
Ping ** 0.4285714?
Hello world,
this patch replaces a != '' with len_trim(a) != 0, to
speed up the comparison. It also introduces a bit of cleanup
in frontend-passes.c.
Regression-tested. OK for trunk?
Thomas
2012-04-13 Thomas Koenig
PR fortran/52537
* fronten
Hi Janne,
I thought I already approved this a few weeks ago
sorry, I totally missed that. Comes from having a computer
crash on you...
Thanks for the review!
Thomas
Hi Tobias,
* 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.
OK for trunk. Thanks for the patch!
Thomas
Hi Tobias,
- [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 days unless
x86_64-unknown-linux-gnu. OK for trunk?
Thomas
2011-11-28 Thomas Koenig
PR fortran/40958
* module.c (prev_module_line): New variable.
(prev_module_column): New variable.
(prev_character): New variable.
(module_char): Update the new
Hi Janne,
Regression-tested on x86_64-unknown-linux-gnu. OK for trunk?
Nice! Ok for trunk.
Sende ChangeLog
Sende module.c
Übertrage Daten ..
Revision 181810 übertragen.
Thanks for the review!
Thomas
possibly introducing a (future?) logic
error.
Regression-tested. OK for trunk?
Thomas
2011-11-29 Thomas Koenig
PR fortran/51338
* dependency.c (are_identical_variables): Handle case where
end fields of substring references are NULL.
2011-11-29 Thomas Koenig
2011-12-02 Thomas Koenig
PR fortran/50690
* frontend-passes.c (workshare_level): New variable.
(cfe_expr_0): Don't eliminiat common functions within
workshares.
(gfc_code_walker): Keep track of workshare level.
2011-12-02 Thomas Koenig
Hello world,
this is what I hope is the final round of the OMP front-end optimization
patch. This one ignores outer workshares when doing function
elimination within omp do and similar blocks.
Regression-tested. OK for trunk?
Thomas
2011-12-02 Thomas Koenig
PR fortran
Hi Jakub,
Both of these arrays should be really vec.h vectors, it doesn't
make any sense to handcode the same thing everywhere.
You can then start with NULL vectors and push something using VEC_safe_push
only when needed and let it handle reallocation etc.
I tried that originally, but could no
e): Set in_omp_workshare.
(gfc_code_walker): Keep track of OMP PARALLEL and OMP WORKSHARE
constructs.
2011-12-11 Thomas Koenig
PR fortran/50690
* gfortran.dg/gomp/workshare2.f90: New test.
* gfortran.dg/gomp/workshare3.f90: New test.
! { dg-do compile }
! { dg-opt
Hi Toon,
(For gcc-patches: Patch at
http://gcc.gnu.org/ml/fortran/2011-12/msg00080.html )
I would appreciate a review and a regression test by someone who can.
Regression-test passed on trunk.
This one really looks obvious. Unless somebody objects who knows this
field better than I do, OK f
Hello world,
here is the reworked patch for improving function elimination.
It turned out to be much simpler than the original one.
Because real constants (and complex) constants are compared
for equality only, it should be pretty safe.
OK for trunk?
Thomas
2011-12-17 Thomas Koenig
Am 18.12.2011 11:15, schrieb Thomas Koenig:
http://gcc.gnu.org/ml/fortran/2011-12/msg00102.html
Because real constants (and complex) constants are compared
for equality only, it should be pretty safe.
OK for trunk?
Ping ** 0.5714 ?
Thomas
http://gcc.gnu.org/ml/fortran/2011-12/msg00102.html
OK for trunk?
Regards
Thomas
Hello world,
the attached patch fixes PR 51502, where we wrongly recognized a
procedure as implicit pure when we were assigning to a module
variable within a block. This is a potential cause for
wrong-code regressions (although no actual test case
exists).
For the test case, I had to scan for t
Hi Tobias and Steve,
Same here: Not tested, but it looks OK.
Committed (after Steve's mail already). Thanks a lot for the reviews!
Thomas
?
Thomas
2012-01-03 Thomas Koenig
PR fortran/49693
* trans-common.c (create_common): Mark variables as
used to avoid warnings about unused variables in common
blocks.
2012-01-03 Thomas Koenig
PR fortran/49693
* gfortran.dg/common_17.f90: New
Hi Paul,
Dear All,
This is a straightforward patch that adds a last ditch attempt to find
a specific typebound procedure when all that has been found for a
derived type base object is 'deferred'. typebound_operator_7.f03 has
been extended to test derived type as well as class base objects.
Bo
Hi Tobias,
Regression-tested. OK for trunk?
OK. Thanks for the patch.
Committed (rev. 182869). Thanks for the review! (I also updated the
copyright years, as requested in private E-Mail.)
Thomas
Hello world,
the attached patch fixes the PR by converting
if (foo) then
...
else if (bar) then
...
end if
to if (foo) then
else
if (bar) then
end if
end if
so inserting a block for temporary variables around the converted
if statement works.
OK for trunk?
Thomas
2012-01-29 Tho
I wrote:
OK for trunk?
I forgot: Regression-tested.
Thomas
Hi Tobias,
I found a bug in my patch, which I am currently correcting. *grumble*
Watch this space!
Thomas
Hi Tobias,
here is an updated version of the patch, with a more extensive test
case. Also regression-tested.
OK for trunk?
Thomas
2012-01-31 Thomas König
PR fortran/51958
* frontend-passes.c (convert_elseif): New function.
(optimize_namespace): Call it.
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 commit the patch.
Thomas
Hi Steve,
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
Hello world,
the attached, rather obvious patch fixed a bogus "unused parameter"
warning with procedure dummy arguments and warns about these if
they occur.
Regression-tested. OK for trunk? Or rather wait until 4.8?
Thomas
2012-02-05 Thomas König
PR fortran/48847
901 - 1000 of 1494 matches
Mail list logo
