Re: [Patch, fortran] PR60717 - Wrong code with recursive procedure with unlimited polymorphic dummy argument
Le 02/04/2014 22:29, Paul Richard Thomas a écrit : Dear All, This fix, of itself, is quite obvious. The offset was being set to zero for array segments, rather than that required for unity valued lvalues. I think that the fix could be used to clean up: trans-expr.c(gfc_trans_alloc_subarray_assign) trans-expr.c(gfc_trans_pointer_assign) trans-expr.c(fncall_realloc_result) trans-array.c(trans_associate_var) each of which contains calculation of the offset. However, I do not think that this is the stage to fix things that are not broken! I propose to keep the PR open as a reminder to look into this. Bootstrapped and regtested on X86_64/FC17 - OK for trunk and backporting to 4.8? Hello Paul, this looks good; OK. Thanks. Mikael
Re: Skip gcc.dg/tree-ssa/isolate-*.c for AVR Target
On Fri, Apr 4, 2014 at 5:37 PM, Jeff Law l...@redhat.com wrote: On 03/28/14 04:16, K_s, Vishnu wrote: Hi all, The tests added in gcc.dg/tree-ssa/isolate-*.c is failing for AVR target, Because the isolate erroneous path pass needs -fdelete-null-pointer-checks option to be enabled. For AVR target that option is disabled, this cause the tests to fail. Following Patch skip the isolate-* tests if keeps_null_pointer_checks is true. 2014-03-28 Vishnu K S vishnu@atmel.com * gcc/testsuite/gcc.dg/tree-ssa/isolate-1.c: Skip test for AVR * gcc/testsuite/gcc.dg/tree-ssa/isolate-2.c: Ditto * gcc/testsuite/gcc.dg/tree-ssa/isolate-3.c: Ditto * gcc/testsuite/gcc.dg/tree-ssa/isolate-4.c: Ditto * gcc/testsuite/gcc.dg/tree-ssa/isolate-5.c: Ditto This is fine for the trunk. Please go ahead and install. However, we generally discourage ports from turning off passes like this and particularly so without a comment as to why a pass is turned off. That code was added to the AVR port here: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01968.html If you could add a comment to the AVR port indicating that delete-null-pointer-checks is disabled because the hardware does not fault on a NULL dereference, it would be greatly appreciated. Consider that comment addition pre-approved, just post it to the list for archival purposes. Note that it is recommended (and documented) practice to treat -fdelete-null-pointer-checks that way for targets that support objects starting at 0. Richard. Thanks, Jeff
Re: RFA: Fix PR rtl-optimization/60651
I've added the testcase - and a bit more detail on this issue - in the PR. I've attached an updated patch, which skips past the CODE_LABEL. And this one bootstraps on i686-pc-linuc-gnu. OK for stage 1 modulo the typo (an instead of en) in a comment. -- Eric Botcazou
conditional notes after 'pedwarn'
Hi,
Idem than the previous patchlets, this time concerning 'pedwarn'.
Tested x86_64 linux. OK to commit ?
cp/ChangeLog
2014-04-04 Fabien Chêne fab...@gcc.gnu.org
* pt.c (check_template_variable): Check for the return of pedwarn
before emitting a note.
* parser.c (cp_parser_lambda_introducer): Likewise.
--
Fabien
Index: gcc/cp/pt.c
===
--- gcc/cp/pt.c (révision 209130)
+++ gcc/cp/pt.c (copie de travail)
@@ -2304,10 +2304,10 @@ check_template_variable (tree decl)
%qD is not a static data member of a class template, decl);
else if (template_header_count wanted)
{
- pedwarn (DECL_SOURCE_LOCATION (decl), 0,
- too many template headers for %D (should be %d),
- decl, wanted);
- if (CLASSTYPE_TEMPLATE_SPECIALIZATION (ctx))
+ bool warned = pedwarn (DECL_SOURCE_LOCATION (decl), 0,
+ too many template headers for %D (should be %d),
+ decl, wanted);
+ if (warned CLASSTYPE_TEMPLATE_SPECIALIZATION (ctx))
inform (DECL_SOURCE_LOCATION (decl),
members of an explicitly specialized class are defined
without a template header);
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (révision 209130)
+++ gcc/cp/parser.c (copie de travail)
@@ -8961,10 +8961,10 @@ cp_parser_lambda_introducer (cp_parser*
if (VAR_P (capture_init_expr)
decl_storage_duration (capture_init_expr) != dk_auto)
{
- pedwarn (capture_token-location, 0, capture of variable
- %qD with non-automatic storage duration,
- capture_init_expr);
- inform (0, %q+#D declared here, capture_init_expr);
+ if (pedwarn (capture_token-location, 0, capture of variable
+ %qD with non-automatic storage duration,
+ capture_init_expr))
+ inform (0, %q+#D declared here, capture_init_expr);
continue;
}
[gomp4] Merge trunk r209072 (2014-04-04) into gomp-4_0-branch
Hi! In r209148, I have committed a merge from trunk r209072 (2014-04-04) into gomp-4_0-branch. Compared to trunk, there is one now regression: PASS: gcc.dg/lto/save-temps c_lto_save-temps_0.o assemble, -O -flto -save-temps -PASS: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o link, -O -flto -save-temps +FAIL: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o link, -O -flto -save-temps +UNRESOLVED: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o execute -O -flto -save-temps Executing on host: [...]/build/gcc/xgcc -B[...]/build/gcc/ -fno-diagnostics-show-caret -fdiagnostics-color=never -O -flto -save-temps -c -o c_lto_save-temps_0.o [...]/source/gcc/testsuite/gcc.dg/lto/save-temps_0.c(timeout = 300) spawn [...]/build/gcc/xgcc -B[...]/build/gcc/ -fno-diagnostics-show-caret -fdiagnostics-color=never -O -flto -save-temps -c -o c_lto_save-temps_0.o [...]/source/gcc/testsuite/gcc.dg/lto/save-temps_0.c PASS: gcc.dg/lto/save-temps c_lto_save-temps_0.o assemble, -O -flto -save-temps Executing on host: [...]/build/gcc/xgcc -B[...]/build/gcc/ c_lto_save-temps_0.o -fno-diagnostics-show-caret -fdiagnostics-color=never -O -flto -save-temps -o gcc-dg-lto-save-temps-01.exe(timeout = 300) spawn [...]/build/gcc/xgcc -B[...]/build/gcc/ c_lto_save-temps_0.o -fno-diagnostics-show-caret -fdiagnostics-color=never -O -flto -save-temps -o gcc-dg-lto-save-temps-01.exe [...]/build/gcc/xgcc @/tmp/ccjomvFW [...]/build/gcc/xgcc @/tmp/ccAM0t6j output is: [...]/build/gcc/xgcc @/tmp/ccjomvFW [...]/build/gcc/xgcc @/tmp/ccAM0t6j FAIL: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o link, -O -flto -save-temps UNRESOLVED: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o execute -O -flto -save-temps Grüße, Thomas pgpkjPJee_WnK.pgp Description: PGP signature
Re: [PATCH 1/4] [GOMP4] [Fortran] OpenACC 1.0+ support in fortran front-end
Hi! On Sun, 16 Mar 2014 20:23:48 +0100, Tobias Burnus bur...@net-b.de wrote: Can you or Thomas apply the following patch after my patch* has been committed to the trunk and the branch has been updated? Please mention PR fortran/60283 in the ChangeLog. * http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00782.html --- a/gcc/fortran/parse.c +++ b/gcc/fortran/parse.c @@ -550,8 +550,7 @@ decode_oacc_directive (void) return ST_NONE; } - if (gfc_implicit_pure (NULL)) -gfc_current_ns-proc_name-attr.implicit_pure = 0; + gfc_unset_implicit_pure (NULL); old_locus = gfc_current_locus; After the trunk merge, committed in r209150: commit 83a3b119255d0913d088d652e6caa26026aacb32 Author: tschwinge tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Sat Apr 5 10:36:58 2014 + Use gfc_unset_implicit_pure. PR fortran/60283 gcc/fortran/ * parse.c (decode_oacc_directive): Use gfc_unset_implicit_pure. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@209150 138bc75d-0d04-0410-961f-82ee72b054a4 diff --git gcc/fortran/ChangeLog.gomp gcc/fortran/ChangeLog.gomp index 1ee6a7c..aff672e 100644 --- gcc/fortran/ChangeLog.gomp +++ gcc/fortran/ChangeLog.gomp @@ -1,3 +1,8 @@ +2014-04-05 Tobias Burnus bur...@net-b.de + + PR fortran/60283 + * parse.c (decode_oacc_directive): Use gfc_unset_implicit_pure. + 2014-03-18 Thomas Schwinge tho...@codesourcery.com * f95-lang.c (DEF_FUNCTION_TYPE_10): Define. diff --git gcc/fortran/parse.c gcc/fortran/parse.c index a217c05..79bdc95 100644 --- gcc/fortran/parse.c +++ gcc/fortran/parse.c @@ -550,8 +550,7 @@ decode_oacc_directive (void) return ST_NONE; } - if (gfc_implicit_pure (NULL)) -gfc_current_ns-proc_name-attr.implicit_pure = 0; + gfc_unset_implicit_pure (NULL); old_locus = gfc_current_locus; Grüße, Thomas pgpEBJ02Q8y9J.pgp Description: PGP signature
Re: [gomp4] Merge trunk r209072 (2014-04-04) into gomp-4_0-branch
Hi! On Sat, 05 Apr 2014 12:34:30 +0200, I wrote: In r209148, I have committed a merge from trunk r209072 (2014-04-04) into gomp-4_0-branch. Oh, and Bernd, would you please verify that I correctly merged the trunk and gomp-4_0-branch changes to gcc/Makefile.in:install-driver? Grüße, Thomas pgpLBlg4NQwk3.pgp Description: PGP signature
[Patch, committed] Adjust gfortran.dg/warn_conversion_4.f90
The test gfortran.dg/warn_conversion_4.f90 has to be adjusted after
r209133. Committed as obvious as r209151.
Dominique
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 209150)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2014-04-05 Dominique d'Humieres domi...@lps.ens.fr
+
+ * gfortran.dg/warn_conversion_4.f90: Adjust test.
+
2014-05-04 Pitchumani Sivanupandi pitchuman...@atmel.com
* gcc.target/avr/dev-specific-rmw.c: New test.
Index: gcc/testsuite/gfortran.dg/warn_conversion_4.f90
===
--- gcc/testsuite/gfortran.dg/warn_conversion_4.f90 (revision 209150)
+++ gcc/testsuite/gfortran.dg/warn_conversion_4.f90 (working copy)
@@ -11,8 +11,8 @@
subroutine test
integer :: x
x = int (abs (cmplx(2.3,0.1)))
-x = int (abs (cmplx(2.3_dp,0.1))) ! { dg-warning Conversion from REAL.8.
to default-kind COMPLEX.4. at .1. might loose precision, consider using the
KIND argument }
-x = int (abs (cmplx(2.3,0.1_dp))) ! { dg-warning Conversion from REAL.8.
to default-kind COMPLEX.4. at .1. might loose precision, consider using the
KIND argument }
-x = int (abs (cmplx(2.3_dp,0.1_dp))) ! { dg-warning Conversion from
REAL.8. to default-kind COMPLEX.4. at .1. might loose precision, consider using
the KIND argument }
+x = int (abs (cmplx(2.3_dp,0.1))) ! { dg-warning Conversion from REAL.8.
to default-kind COMPLEX.4. at .1. might lose precision, consider using the KIND
argument }
+x = int (abs (cmplx(2.3,0.1_dp))) ! { dg-warning Conversion from REAL.8.
to default-kind COMPLEX.4. at .1. might lose precision, consider using the KIND
argument }
+x = int (abs (cmplx(2.3_dp,0.1_dp))) ! { dg-warning Conversion from
REAL.8. to default-kind COMPLEX.4. at .1. might lose precision, consider using
the KIND argument }
end subroutine test
end module fft_mod
Warn when returning the address of a temporary (middle-end)
Hello,
we have front-end warnings about returning the address of a local
variable. However, quite often in C++, people don't directly return the
address of a temporary, it goes through a few functions which hide that
fact. After some inlining, the fact that we are returning the address of a
local variable can become obvious to the compiler, to the point where I
have used, for debugging purposes, grep 'return ' on the optimized dump
produced with -O3 -fkeep-inline-functions (I then had to sort through the
global/local variables).
fold_stmt looks like a good place for this, but it could go almost
anywhere. It has to happen after enough inlining / copy propagation to
make it useful though.
One hard part is avoiding duplicate warnings. Replacing the address with 0
is a convenient way to do that, so I did it both for my new warning and
for the existing C/C++ ones. The patch breaks
gfortran.dg/warn_target_lifetime_2.f90 because it ends up warning twice. I
didn't touch that front-end because I don't know fortran, and the warning
message Pointer at .1. in pointer assignment might outlive the pointer
target doesn't seem very confident that the thing really is broken enough
to be replaced by 0. I only tested (bootstrap+regression) the default
languages, so ada/go may have a similar issue, to be handled if the
approach seems ok. (I personally wouldn't care about duplicate warnings,
but I know some people can't help complaining about it)
This doesn't actually fix PR 60517, for that I was thinking of checking
for memory reads if the first stop of walk_aliased_vdefs is a clobber
(could also check __builtin_free), though I don't know in which pass to do
that yet.
2014-04-05 Marc Glisse marc.gli...@inria.fr
PR c++/60517
gcc/c/
* c-typeck.c (c_finish_return): Return 0 instead of the address of
a local variable.
gcc/cp/
* typeck.c (check_return_expr): Likewise.
(maybe_warn_about_returning_address_of_local): Tell the caller if
we warned.
gcc/
* gimple-fold.c (fold_stmt_1): Warn if returning the address of a
local variable.
gcc/testsuite/
* c-c++-common/addrtmp.c: New testcase.
* c-c++-common/uninit-G.c: Adjust.
--
Marc GlisseIndex: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c(revision 209157)
+++ gcc/c/c-typeck.c(working copy)
@@ -9254,23 +9254,25 @@ c_finish_return (location_t loc, tree re
inner = TREE_OPERAND (inner, 0);
while (REFERENCE_CLASS_P (inner)
TREE_CODE (inner) != INDIRECT_REF)
inner = TREE_OPERAND (inner, 0);
if (DECL_P (inner)
!DECL_EXTERNAL (inner)
!TREE_STATIC (inner)
DECL_CONTEXT (inner) == current_function_decl)
- warning_at (loc,
- OPT_Wreturn_local_addr, function returns address
- of local variable);
+ {
+ warning_at (loc, OPT_Wreturn_local_addr,
+ function returns address of local variable);
+ t = build_zero_cst (TREE_TYPE (res));
+ }
break;
default:
break;
}
break;
}
retval = build2 (MODIFY_EXPR, TREE_TYPE (res), res, t);
Index: gcc/cp/typeck.c
===
--- gcc/cp/typeck.c (revision 209157)
+++ gcc/cp/typeck.c (working copy)
@@ -49,21 +49,21 @@ static tree convert_for_assignment (tree
static tree cp_pointer_int_sum (enum tree_code, tree, tree, tsubst_flags_t);
static tree rationalize_conditional_expr (enum tree_code, tree,
tsubst_flags_t);
static int comp_ptr_ttypes_real (tree, tree, int);
static bool comp_except_types (tree, tree, bool);
static bool comp_array_types (const_tree, const_tree, bool);
static tree pointer_diff (tree, tree, tree, tsubst_flags_t);
static tree get_delta_difference (tree, tree, bool, bool, tsubst_flags_t);
static void casts_away_constness_r (tree *, tree *, tsubst_flags_t);
static bool casts_away_constness (tree, tree, tsubst_flags_t);
-static void maybe_warn_about_returning_address_of_local (tree);
+static bool maybe_warn_about_returning_address_of_local (tree);
static tree lookup_destructor (tree, tree, tree, tsubst_flags_t);
static void warn_args_num (location_t, tree, bool);
static int convert_arguments (tree, vectree, va_gc **, tree, int,
tsubst_flags_t);
/* Do `exp = require_complete_type (exp);' to make sure exp
does not have an incomplete type. (That includes void types.)
Returns error_mark_node if the VALUE does not have
complete type when this function returns. */
@@ -8253,79 +8253,81 @@ convert_for_initialization (tree exp, tr
return rhs;
Re: [gomp4] Add tables generation
Hi!
On Fri, 4 Apr 2014 11:30:49 +0200, Bernd Schmidt ber...@codesourcery.com
wrote:
On 03/21/2014 04:20 PM, Jakub Jelinek wrote:
On Fri, Mar 21, 2014 at 04:13:45PM +0100, Bernd Schmidt wrote:
On 03/20/2014 07:56 PM, Jakub Jelinek wrote:
When we were discussing the design last year, my strong preference was
that
either this lives in some other crt object that mkoffload/linker plugin
adds
to link, or that it would be completely mkoffload synthetized.
mkoffload is only concerned with generating target images. These
fragments are for the host tables.
How's this? It moves everything to ompbegin.o/ompend.o and only
links in these files if we have produced at least one target offload
image.
I'd call the files crtompbegin.o/crtompend.o instead.
I'd go with crtoffload* (or similar). ;-)
Also, supposedly if you've used section names without . in them, the linker
itself would provide the symbols automatically and you wouldn't actually
need begin/end, but just one object that would reference the linker created
symbols. Just use say __gnu_offload_whatever__ or similar section names.
I've checked in the following which should address all this.
Is it a linker bug that I need to add something like the following?
--- libgcc/ompstuff.c
+++ libgcc/ompstuff.c
@@ -40,6 +40,12 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#include libgcc_tm.h
#if defined(HAVE_GAS_HIDDEN) defined(ENABLE_OFFLOADING)
+# if 1
+/* TODO: Without the following, will get missing symbols for __start_* and
+ __stop_*. Linker bug? */
+static void *_funcs[0] __attribute__ ((section (__gnu_offload_funcs))) = { };
+static void *_vars[0] __attribute__ ((section (__gnu_offload_vars))) = { };
+# endif
extern void __start___gnu_offload_funcs;
extern void __stop___gnu_offload_funcs;
extern void __start___gnu_offload_vars;
$ ld --version
GNU ld (Sourcery CodeBench 2013.11-17) 2.23.52.20130912
[...]
--- libgcc/ompstuff.c (revision 0)
+++ libgcc/ompstuff.c (working copy)
+extern void __start___gnu_offload_funcs;
+extern void __stop___gnu_offload_funcs;
+extern void __start___gnu_offload_vars;
+extern void __stop___gnu_offload_vars;
+void *__OPENMP_TARGET__[] __attribute__ ((__visibility__ (hidden))) =
+{
+ __start___gnu_offload_funcs, __stop___gnu_offload_funcs,
+ __start___gnu_offload_vars, __stop___gnu_offload_vars
+};
../../../source/libgcc/ompstuff.c:49:3: warning: taking address of
expression of type 'void'
__start___gnu_offload_funcs, __stop___gnu_offload_funcs,
^
../../../source/libgcc/ompstuff.c:49:33: warning: taking address of
expression of type 'void'
__start___gnu_offload_funcs, __stop___gnu_offload_funcs,
^
../../../source/libgcc/ompstuff.c:50:3: warning: taking address of
expression of type 'void'
__start___gnu_offload_vars, __stop___gnu_offload_vars
^
../../../source/libgcc/ompstuff.c:50:32: warning: taking address of
expression of type 'void'
__start___gnu_offload_vars, __stop___gnu_offload_vars
^
s%void%char makes this go away.
Grüße,
Thomas
pgpPQxXD1zF2u.pgp
Description: PGP signature
Re: [gomp4] Add tables generation
On 04/05/2014 05:04 PM, Thomas Schwinge wrote:
Is it a linker bug that I need to add something like the following?
--- libgcc/ompstuff.c
+++ libgcc/ompstuff.c
@@ -40,6 +40,12 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#include libgcc_tm.h
#if defined(HAVE_GAS_HIDDEN) defined(ENABLE_OFFLOADING)
+# if 1
+/* TODO: Without the following, will get missing symbols for __start_* and
+ __stop_*. Linker bug? */
+static void *_funcs[0] __attribute__ ((section (__gnu_offload_funcs))) = { };
+static void *_vars[0] __attribute__ ((section (__gnu_offload_vars))) = { };
+# endif
Things seemed to work over here, but now I'm not certain whether the
__start_/__stop_ functionality is GNU ld specific? Maybe we should just
go back to the previous version of this patch which didn't try to use this.
Bernd
Re: [PATCH] Initialize sanitizer builtins (PR sanitizer/60745)
On Fri, Apr 04, 2014 at 02:53:32PM -0600, Jeff Law wrote:
Presumably when we wrote out the PCH -fsanitize wasn't being used
and thus those builtins are not initialized. Right?
Right. I put a local hack into c_common_write_pch and that said:
wrote x86_64-unknown-linux-gnu/bits/stdc++.h.gch/O2g.gch, sanitize flag: 0
so builtins weren't initialized (see #define DEF_SANITIZER_BUILTIN for
why). O2g.gch is the file that is then read by c_common_read_pch.
Assuming that's correct, your patch is fine with a comment to that effect.
Thanks. I'll wait a day or two for possible comments.
2014-04-05 Marek Polacek pola...@redhat.com
PR sanitizer/60745
* c-ubsan.c: Include asan.h.
(ubsan_instrument_return): Call initialize_sanitizer_builtins.
diff --git gcc/c-family/c-ubsan.c gcc/c-family/c-ubsan.c
index dc4d981..e89ebc1 100644
--- gcc/c-family/c-ubsan.c
+++ gcc/c-family/c-ubsan.c
@@ -29,6 +29,7 @@ along with GCC; see the file COPYING3. If not see
#include ubsan.h
#include c-family/c-common.h
#include c-family/c-ubsan.h
+#include asan.h
/* Instrument division by zero and INT_MIN / -1. If not instrumenting,
return NULL_TREE. */
@@ -185,6 +186,10 @@ ubsan_instrument_vla (location_t loc, tree size)
tree
ubsan_instrument_return (location_t loc)
{
+ /* It is possible that PCH zapped table with definitions of sanitizer
+ builtins. Reinitialize them if needed. */
+ initialize_sanitizer_builtins ();
+
tree data = ubsan_create_data (__ubsan_missing_return_data, loc,
NULL, NULL_TREE);
tree t = builtin_decl_explicit (BUILT_IN_UBSAN_HANDLE_MISSING_RETURN);
Marek
[wwwdocs] Rotate news
Applied. Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.908 diff -u -r1.908 index.html --- index.html 13 Mar 2014 15:30:15 - 1.908 +++ index.html 5 Apr 2014 20:48:31 - @@ -99,59 +99,6 @@ span class=date[2013-10-03]/span/dt ddRegular expression support in a href=libstdc++/libstdc++-v3/a is now available./dd -dtspanSynopsys Designware ARC support/span -span class=date[2013-10-01]/span/dt -ddA port for Synopsys Designware ARC has been contributed by Embecosm and Synopsys Inc./dd - -dtspanTI MSP430 support/span -span class=date[2013-09-12]/span/dt -ddA port for the TI MSP430 has been contributed by Red Hat Inc./dd - -dtspanTwitter and Google+ accounts/span -span class=date[2013-08-08]/span/dt -ddGCC and the GNU Toolchain Project now have accounts on -a href=https://twitter.com/gnutools; target=_blankTwitter/a and -a href=https://plus.google.com/108467477471815191158; rel=publisher target=_blankGoogle+/a - to help developers stay informed of progress./dd - -dtspanIBM POWER8 support/span -span class=date[2013-07-15]/span/dt -ddSupport for the POWER8 processor has been contributed by IBM. -This includes new VSX, HTM and atomic instructions, new intrinsics, -and scheduling improvements. Little Endian support also has been -enhanced, including control over vector element endianness./dd - -dtspana href=gcc-4.8/GCC 4.8.1/a released/span -span class=date[2013-05-31]/span/dt -dd/dd - -dtspana href=gcc-4.6/GCC 4.6.4/a released/span -span class=date[2013-04-12]/span/dt -dd/dd - -dtspana href=gcc-4.7/GCC 4.7.3/a released/span -span class=date[2013-04-11]/span/dt -dd/dd - -dtspana href=gcc-4.8/changes.html#cxxGCC 4.8.1/a -will be a href=projects/cxx0x.htmlC++11/a feature-complete/span -span class=date[2013-04-01]/span/dt -ddSupport for C++11 varref-qualifiers/var was added to the GCC - 4.8 branch, making G++ the first C++ compiler to implement all - the major language features of the C++11 standard. This - functionality will be available in GCC 4.8.1./dd - -dtspana href=gcc-4.8/GCC 4.8.0/a released/span -span class=date[2013-03-22]/span/dt -dd/dd - -dtspanGCC internals documentation/span -span class=date[2013-01-23]/span/dt -ddThe -a href=http://www.cse.iitb.ac.in/grc/;GCC Resource Center/a -at IITB is providing documentation, tutorials and videos -about GCC internals with support from the Government of India./dd - /dl div Index: news.html === RCS file: /cvs/gcc/wwwdocs/htdocs/news.html,v retrieving revision 1.138 diff -u -r1.138 news.html --- news.html 3 Dec 2013 01:04:41 - 1.138 +++ news.html 5 Apr 2014 20:48:32 - @@ -14,6 +14,59 @@ !-- ATTENTION: This page is for *OLD* news! Latest news goes first. -- +dtspanSynopsys Designware ARC support/span +span class=date[2013-10-01]/span/dt +ddA port for Synopsys Designware ARC has been contributed by Embecosm and Synopsys Inc./dd + +dtspanTI MSP430 support/span +span class=date[2013-09-12]/span/dt +ddA port for the TI MSP430 has been contributed by Red Hat Inc./dd + +dtspanTwitter and Google+ accounts/span +span class=date[2013-08-08]/span/dt +ddGCC and the GNU Toolchain Project now have accounts on +a href=https://twitter.com/gnutools; target=_blankTwitter/a and +a href=https://plus.google.com/108467477471815191158; rel=publisher target=_blankGoogle+/a + to help developers stay informed of progress./dd + +dtspanIBM POWER8 support/span +span class=date[2013-07-15]/span/dt +ddSupport for the POWER8 processor has been contributed by IBM. +This includes new VSX, HTM and atomic instructions, new intrinsics, +and scheduling improvements. Little Endian support also has been +enhanced, including control over vector element endianness./dd + +dtspana href=gcc-4.8/GCC 4.8.1/a released/span +span class=date[2013-05-31]/span/dt +dd/dd + +dtspana href=gcc-4.6/GCC 4.6.4/a released/span +span class=date[2013-04-12]/span/dt +dd/dd + +dtspana href=gcc-4.7/GCC 4.7.3/a released/span +span class=date[2013-04-11]/span/dt +dd/dd + +dtspana href=gcc-4.8/changes.html#cxxGCC 4.8.1/a +will be a href=projects/cxx0x.htmlC++11/a feature-complete/span +span class=date[2013-04-01]/span/dt +ddSupport for C++11 varref-qualifiers/var was added to the GCC + 4.8 branch, making G++ the first C++ compiler to implement all + the major language features of the C++11 standard. This + functionality will be available in GCC 4.8.1./dd + +dtspana href=gcc-4.8/GCC 4.8.0/a released/span +span class=date[2013-03-22]/span/dt +dd/dd + +dtspanGCC internals documentation/span +span class=date[2013-01-23]/span/dt +ddThe +a href=http://www.cse.iitb.ac.in/grc/;GCC Resource
Re: [Patch, Fortran] PRs 60495/58880: Fix issues with finalization expressions
On Sat, Apr 05, 2014 at 12:16:23AM +0200, Tobias Burnus wrote:
This patch ensures that the finalization expression is generated and that
use-associated finalizers are properly accessed.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2014-04-04 Tobias Burnus bur...@net-b.de
PR fortran/58880
PR fortran/60495
* resolve.c (gfc_resolve_finalizers): Ensure that vtables
and finalization wrappers are generated.
* trans.c (gfc_build_final_call): Ensure that use_assoc
is set for the finalization wrapper when applicable.
2014-04-04 Tobias Burnus bur...@net-b.de
PR fortran/58880
PR fortran/60495
* gfortran.dg/finalize_25.f90: New.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 6e23e57..38755fe 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -11200,15 +11200,36 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)
the requirements of the standard for procedures used as finalizers. */
static bool
-gfc_resolve_finalizers (gfc_symbol* derived)
+gfc_resolve_finalizers (gfc_symbol* derived, bool *finalizable)
{
gfc_finalizer* list;
gfc_finalizer** prev_link; /* For removing wrong entries from the list. */
bool result = true;
bool seen_scalar = false;
+ gfc_symbol *vtab;
+ gfc_component *c;
+ /* Return early when not finalizable. Additionally, ensure that
derived-type
+ components have a their finalizables resolved. */
if (!derived-f2k_derived || !derived-f2k_derived-finalizers)
-return true;
+{
+ bool has_final = false;
+ for (c = derived-components; c; c = c-next)
+ if (c-ts.type == BT_DERIVED
+ !c-attr.pointer !c-attr.proc_pointer
!c-attr.allocatable)
+ {
+ bool has_final2 = false;
+ if (!gfc_resolve_finalizers (c-ts.u.derived, has_final))
+ return false; /* Error. */
+ has_final = has_final || has_final2;
debugging-leftover? What's the purpose of has_final2?
Did you mean has_final |= true i.e. has_final = true here?
What am i missing? :)
thanks,
+ }
+ if (!has_final)
+ {
+ if (finalizable)
+ *finalizable = false;
+ return true;
+ }
+}
/* Walk over the list of finalizer-procedures, check them, and if any one
does not fit in with the standard's definition, print an error and
remove
@@ -11330,12 +11351,15 @@ gfc_resolve_finalizers (gfc_symbol* derived)
/* Remove wrong nodes immediately from the list so we don't risk any
troubles in the future when they might fail later expectations. */
error:
- result = false;
i = list;
*prev_link = list-next;
gfc_free_finalizer (i);
+ result = false;
}
+ if (result == false)
+return false;
+
/* Warn if we haven't seen a scalar finalizer procedure (but we know there
were nodes in the list, must have been for arrays. It is surely a good
idea to have a scalar version there if there's something to finalize.
*/
@@ -11344,8 +11368,14 @@ error:
defined at %L, suggest also scalar one,
derived-name, derived-declared_at);
- gfc_find_derived_vtab (derived);
- return result;
+ vtab = gfc_find_derived_vtab (derived);
+ c = vtab-ts.u.derived-components-next-next-next-next-next;
+ gfc_set_sym_referenced (c-initializer-symtree-n.sym);
+
+ if (finalizable)
+*finalizable = true;
+
+ return true;
}
@@ -12513,7 +12543,7 @@ resolve_fl_derived (gfc_symbol *sym)
return false;
/* Resolve the finalizer procedures. */
- if (!gfc_resolve_finalizers (sym))
+ if (!gfc_resolve_finalizers (sym, NULL))
return false;
if (sym-attr.is_class sym-ts.u.derived == NULL)
diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
index 5961c26..9ea859e 100644
--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -869,6 +869,9 @@ gfc_build_final_call (gfc_typespec ts, gfc_expr
*final_wrapper, gfc_expr *var,
gcc_assert (final_wrapper-expr_type == EXPR_VARIABLE);
gcc_assert (var);
+ if (final_wrapper-symtree-n.sym-module)
+final_wrapper-symtree-n.sym-attr.use_assoc = 1;
+
gfc_start_block (block);
gfc_init_se (se, NULL);
gfc_conv_expr (se, final_wrapper);
diff --git a/gcc/testsuite/gfortran.dg/finalize_25.f90
b/gcc/testsuite/gfortran.dg/finalize_25.f90
new file mode 100644
index 000..73dc568
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/finalize_25.f90
@@ -0,0 +1,55 @@
+! { dg-do run }
+!
+! PR fortran/58880
+! PR fortran/60495
+!
+! Contributed by Andrew Benson and Janus Weil
+!
+
+module gn
+ implicit none
+ type sl
+ integer, allocatable, dimension(:) :: lv
+ contains
+ final :: sld
+ end type
+ type :: nde
+ type(sl) :: r
+ end type nde
+
+ integer :: cnt = 0
+
+contains
+
+ subroutine sld(s)
+
