libgo patch committed: Reject surrogate pair in range over string
Similar to the last patch, this rejects a surrogate pair, which is
invalid UTF-8, when doing a range over a string. Bootstrapped and ran
Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline and 4.7
branch.
Ian
diff -r 2a400cc3eae6 libgo/runtime/go-rune.c
--- a/libgo/runtime/go-rune.c Fri Sep 21 23:51:25 2012 -0700
+++ b/libgo/runtime/go-rune.c Fri Sep 21 23:57:48 2012 -0700
@@ -53,6 +53,14 @@
*rune = (((c & 0xf) << 12)
+ ((c1 & 0x3f) << 6)
+ (c2 & 0x3f));
+
+ if (*rune >= 0xd800 && *rune < 0xe000)
+ {
+ /* Invalid surrogate half; return replace character. */
+ *rune = 0xfffd;
+ return 1;
+ }
+
return 3;
}
Re: add typedef printers to libstdc++
On Fri, 2012-09-21 at 14:59 -0600, Tom Tromey wrote: > This patch adds some typedef printers to libstdc++. > > This relies on a gdb patch that hasn't yet gone in (pending on the list). > If the gdb patch changes, I'll change these printers as well. > > The basic idea is that you can now have gdb substitute a name of your > choice when printing a type's name. This lets a library pretend that > some typedefs are canonical. > > This includes a fairly comprehensive test case for the new type > printers. I have not tested it, but when looking at the test case and also on the code I couldn't help but ask myself how it handles other derivations. How does it display the types of the variables us, s and ss in the following code: --- #include typedef std::basic_string ustring; ustring us; std::string s; std::basic_string ss; --- I would expect it to say std::basic_string, std::string and std::basic_string, but I thought a test case here couldn't hurt? /MF
*ping* [patch, fortran] Fix an issue found by Coverity scan
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?
Re: *ping* [patch, fortran] Fix an issue found by Coverity scan
Hi Thomas, > 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? looks good to me. Thanks for the patch! Cheers, Janus
Re: [PATCH, middle-end]: Fix g++.dg/other/vector-compare.C testsuite failure on alpha
> Vector compare testcases can't be compiled with 4.7- - vector compares > are not implemented for C++ there. As observed, BLKmode compare is not > triggered for alpha in the whole testsuite, as far as release branches > are concerned. Then there is no real reason to touch the release branches in my opinion. The second hunk is OK for mainline (without the now useless label). -- Eric Botcazou
Re: [PATCH, middle-end]: Fix g++.dg/other/vector-compare.C testsuite failure on alpha
On Sat, Sep 22, 2012 at 12:54 PM, Eric Botcazou wrote: >> Vector compare testcases can't be compiled with 4.7- - vector compares >> are not implemented for C++ there. As observed, BLKmode compare is not >> triggered for alpha in the whole testsuite, as far as release branches >> are concerned. > > Then there is no real reason to touch the release branches in my opinion. OK. > The second hunk is OK for mainline (without the now useless label). I will adjust the patch accordingly and commit it to mainline only. Thanks for the review, Uros.
Remove duplicated block of code
Hello,
this patch removes one copy of a block of code that somehow ended up
duplicated. Richard Henderson apparently already fixed part of the problem
here:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00120.html
but missed this bit (or was it a different patch?).
Not yet tested (seems obvious enough), but I'll still do it after I get an
ok.
2012-09-24 Marc Glisse
* expr.c (do_store_flag): Remove duplicated code.
--
Marc GlisseIndex: expr.c
===
--- expr.c (revision 191640)
+++ expr.c (working copy)
@@ -10679,33 +10679,22 @@ do_store_flag (sepops ops, rtx target, e
/* For vector typed comparisons emit code to generate the desired
all-ones or all-zeros mask. Conveniently use the VEC_COND_EXPR
expander for this. */
if (TREE_CODE (ops->type) == VECTOR_TYPE)
{
tree ifexp = build2 (ops->code, ops->type, arg0, arg1);
tree if_true = constant_boolean_node (true, ops->type);
tree if_false = constant_boolean_node (false, ops->type);
return expand_vec_cond_expr (ops->type, ifexp, if_true, if_false,
target);
}
- /* For vector typed comparisons emit code to generate the desired
- all-ones or all-zeros mask. Conveniently use the VEC_COND_EXPR
- expander for this. */
- if (TREE_CODE (ops->type) == VECTOR_TYPE)
-{
- tree ifexp = build2 (ops->code, ops->type, arg0, arg1);
- tree if_true = constant_boolean_node (true, ops->type);
- tree if_false = constant_boolean_node (false, ops->type);
- return expand_vec_cond_expr (ops->type, ifexp, if_true, if_false,
target);
-}
-
/* Get the rtx comparison code to use. We know that EXP is a comparison
operation of some type. Some comparisons against 1 and -1 can be
converted to comparisons with zero. Do so here so that the tests
below will be aware that we have a comparison with zero. These
tests will not catch constants in the first operand, but constants
are rarely passed as the first operand. */
switch (ops->code)
{
case EQ_EXPR:
code = EQ;
git-svn: Unable to connect to a repository
"Huh?" Sorry. Don't know what else to say:
Per: http://gcc.gnu.org/wiki/GitMirror
$ git svn init -Ttrunk --prefix=origin/ svn+ssh://gcc.gnu.org/svn/gcc
Network connection closed unexpectedly: Unable to connect to a repository at \
URL 'svn+ssh://gcc.gnu.org/svn/gcc': To better debug SSH connection problems,
remove the -q option from 'ssh' in the [tunnels] section of your Subversion
configuration file. at /usr/lib/git/git-svn line 2299.
2287 sub init_remote_config {
2288 my ($self, $url, $no_write) = @_;
2289 $url =~ s!/+$!!; # strip trailing slash
2290 my $r = read_all_remotes();
2291 my $existing = find_existing_remote($url, $r);
2292 if ($existing) {
2293 unless ($no_write) {
2294 print STDERR "Using existing ",
2295 "[svn-remote \"$existing\"]\n";
2296 }
2297 $self->{repo_id} = $existing;
2298 } elsif ($_minimize_url) {
2299 my $min_url = Git::SVN::Ra->new($url)->minimize_url;
2300 $existing = find_existing_remote($min_url, $r);
Re: git-svn: Unable to connect to a repository
On 09/22/12 12:49, Bruce Korb wrote: > "Huh?" Sorry. Don't know what else to say: Similar results using straight up svn: $ bash contrib/gcc_update Updating SVN tree svn: E155036: Please see the 'svn upgrade' command svn: E155036: Working copy '/u/gnu/proj/gcc-svn' is too old (format 10, created by Subversion 1.6) Adjusting file timestamps Touching Makefile.in... SVN update of full tree failed. $ svn ls svn+ssh://usern...@gcc.gnu.org/svn/gcc svn: E210002: Unable to connect to a repository at URL 'svn+ssh://usern...@gcc.gnu.org/svn/gcc' svn: E210002: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file. svn: E210002: Network connection closed unexpectedly SVN is behaving unexpectedly. Help, please?
Re: [PATCH] rs6000: Tighten register predicates
On Fri, Sep 21, 2012 at 10:11 PM, Segher Boessenkool wrote: > Currently, the register predicates allow a subreg of anything, > including memory or the wrong kind of register. Most other ports > do not allow this. As far as I can see, this doesn't help the > compiler generate better code, potentially the opposite. > > This also causes a problem for my (upcoming) add-with-carry work. > The patterns for the add-with-carry instructions are each a parallel > of two sets, one of a GPR and one of CA. Sometimes one of those > sets isn't used, for example for most ADDE instructions, and combine > will try e.g. (set (reg:P xxx) (reg:P CA_REGNO)) which fails > because that isn't an existing instruction. But when it tries > (set (reg:SI xxx) (subreg:SI (reg:DI CA_REGNO) 4)) it currently > succeeds, because it looks like movsi2; but of course it ICEs > later on. > > This patch tightens the register predicates to only allow a subreg > of the kind of registers the predicates allows. The generated code > for e.g. gpc_reg_operand looks a bit worse, but benchmarking shows > it to be a wash (average of three runs on combine.ii: original > 0m13.014s, patched 0m13.003s). > > Tested on powerpc64-linux --enable-languages=c,c++,fortran; > no regressions. Okay to apply? > > > Segher > > > 2012-09-21 Segher Boessenkool > > gcc/ > * config/rs6000/predicates.md (altivec_register_operand, > vsx_register_operand, vfloat_operand, vint_operand, > vlogical_operand, gpc_reg_operand, cc_reg_operand, > cc_reg_not_cr0_operand, cc_reg_not_micro_cr0_operand): > If op is a SUBREG, consider its SUBREG_REG instead. Okay. Thanks, David
Re: git-svn: Unable to connect to a repository
On Sat, Sep 22, 2012 at 2:59 PM, Bruce Korb wrote: > On 09/22/12 12:49, Bruce Korb wrote: >> "Huh?" Sorry. Don't know what else to say: > > Similar results using straight up svn: > > $ bash contrib/gcc_update > Updating SVN tree > svn: E155036: Please see the 'svn upgrade' command > svn: E155036: Working copy '/u/gnu/proj/gcc-svn' is too old (format 10, > created by Subversion 1.6) > Adjusting file timestamps > Touching Makefile.in... > SVN update of full tree failed. > $ svn ls svn+ssh://usern...@gcc.gnu.org/svn/gcc > svn: E210002: Unable to connect to a repository at URL > 'svn+ssh://usern...@gcc.gnu.org/svn/gcc' > svn: E210002: To better debug SSH connection problems, remove the -q option > from 'ssh' in the [tunnels] section of your Subversion configuration file. > svn: E210002: Network connection closed unexpectedly > > > SVN is behaving unexpectedly. Help, please? Have you upgraded your system or SVN recently? If yes, you need to issue the command $ svn upgrade in the toplevel directory of your GCC working directory. (this has nothing to do with GCC. It is a general SVN thingy.) -- Gaby
Re: [patch] split FRAME variables back into pieces
> Well, the current code assumes that the replacements are gimple > register types and, perhaps more importantly, it assumes there are no > to-be-replaced pieces within to-be-replaced pieces. If we were to put > a structure outside of a frame structure and scalarize some field > within it at the same time... a lot of places would probably need to > be slightly re-thought. Yes, IIRC I came to the conclusion that the splitting of the FRAME variables and the splitting (or not) of its aggregate fields couldn't be (easily) done in one pass with SRA. After that, it's easy to understand why I wrote the special sub-pass instead of patching SRA. > OTOH, I assume the frame structure is never being assigned to or read as a > whole so that would simplify a lot of things. Yes, that's one of the special properties of the FRAME variables, in addition to the addressability thing. > Please CC me in the bug. I probably won't be able to try anything > myself for a few weeks but I'm interested in helping. Sure, but, as I said, I don't plan to work on it myself either. The current patch is small, localized, straightforward to understand and we haven't had a single bug reported for it since its inception 2 years ago, so... -- Eric Botcazou
Re: git-svn: Unable to connect to a repository
Hi Gaby,
On 09/22/12 13:07, Gabriel Dos Reis wrote:
>> SVN is behaving unexpectedly. Help, please?
>
> Have you upgraded your system or SVN recently?
Not deliberately. :) Switched openSuSE releases (12.2 now).
> If yes, you need to issue the command
>
> $ svn upgrade
It's been crunching on that for over 20 minutes now.
I suppose it will finish eventually. [finished while writing this]
Nonetheless, I do prefer to work with GIT over SVN, but that means
I would need to debug the issues from my first missive
on this topic. [now fixed, see below]
> (this has nothing to do with GCC. It is a general SVN thingy.)
Still, dealing with anticipatable failures makes for good grist
for the GCC wiki. Error messages like, "remove the -q option"
are not helpful when you haven't used any -q option. And it
was similar to the message from "git svn":
> $ git svn init -Ttrunk --prefix=origin/ svn+ssh://gcc.gnu.org/svn/gcc
> Network connection closed unexpectedly: Unable to connect to a repository at \
> URL 'svn+ssh://gcc.gnu.org/svn/gcc': To better debug SSH connection
> problems,
> remove the -q option from 'ssh' in the [tunnels] section of your Subversion
> configuration file. at /usr/lib/git/git-svn line 2299.
>
>
> 2287 sub init_remote_config { [...]
I surely don't see any "-q" on line 2299. Perhaps I need a "korbb@" inserted
before the "gcc.gnu.org" in the command?
[a moment passes]
Yep. That's it. the "git svn init" command should be augmented with my
login id at gcc.gnu.org. Thank you!
> $ git svn init -Ttrunk --prefix=origin/ svn+ssh://logi...@gcc.gnu.org/svn/gcc
So, "remove the -q option" really means, "provide your login id."
Not especially obvious. :(
Thank you!! - Bruce
Fix PR tree-optimization/54669
As demonstrated by the testcase, the new propagate_constants_for_unrolling can
change the EH properties of a statement when it turns array accesses with
variable index into array accesses with fixed index if -fnon-call-exception is
enabled.
The proposed fix is to call maybe_clean_or_replace_eh_stmt on the modified
statement. There is already a call to cleanup_tree_cfg at the end so this
should be sufficient.
Tested on x86-64/Linux, OK for the mainline?
2012-09-22 Eric Botcazou
PR tree-optimization/54669
* tree-ssa-loop-ivcanon.c (propagate_into_all_uses): Invoke
maybe_clean_or_replace_eh_stmt on the modified use statements.
2012-09-22 Eric Botcazou
* gcc.dg/pr54669.c: New test.
--
Eric BotcazouIndex: tree-ssa-loop-ivcanon.c
===
--- tree-ssa-loop-ivcanon.c (revision 191387)
+++ tree-ssa-loop-ivcanon.c (working copy)
@@ -531,6 +531,7 @@ propagate_into_all_uses (tree ssa_name,
fold_stmt_inplace (&use_stmt_gsi);
update_stmt (use_stmt);
+ maybe_clean_or_replace_eh_stmt (use_stmt, use_stmt);
}
}
/* PR tree-optimization/54669 */
/* Testcase by Zdenek Sojka */
/* { dg-compile } */
/* { dg-options "-O2 -fexceptions -fnon-call-exception" } */
int a[10];
void
foo (void)
{
int x;
int i;
for (i = 0; i < 1;)
{
int b[3];
for (i = 0; i < 1; i++)
b[i] = a[i];
if (&x)
a[0] = b[0];
}
}
Re: git-svn: Unable to connect to a repository
On Sat, Sep 22, 2012 at 3:29 PM, Bruce Korb wrote:
> Hi Gaby,
>
> On 09/22/12 13:07, Gabriel Dos Reis wrote:
>>> SVN is behaving unexpectedly. Help, please?
>>
>> Have you upgraded your system or SVN recently?
>
> Not deliberately. :) Switched openSuSE releases (12.2 now).
yeah, I have been running suse since 6.2, and I was a little bit
disappointed when I upgraded a couple of weeks ago to 12.2;
there were a few surprises :-(
>> If yes, you need to issue the command
>>
>> $ svn upgrade
>
> It's been crunching on that for over 20 minutes now.
Wow; mine took about 2 min -- but admittedly I had only trunk to
worry about trunk. It is a local operation so it does not use any network;
maybe a slower harddrive?
I used to use SVK over SVN, but the change in format threw
SVK to the coucouland; it is a bit painful.
> I suppose it will finish eventually. [finished while writing this]
>
> Nonetheless, I do prefer to work with GIT over SVN, but that means
> I would need to debug the issues from my first missive
> on this topic. [now fixed, see below]
I was addicted to SVK, but now I am painfully back to plain SVN.
>
>> (this has nothing to do with GCC. It is a general SVN thingy.)
>
> Still, dealing with anticipatable failures makes for good grist
> for the GCC wiki. Error messages like, "remove the -q option"
> are not helpful when you haven't used any -q option. And it
> was similar to the message from "git svn":
I fully agree. I suspect it might be that:
(1) many GCC developers use plain SVN; or
(2) the change in SVN format (version 1.7.x) is relatively
recent so it hasn't affected enough people yet.
>
>> $ git svn init -Ttrunk --prefix=origin/ svn+ssh://gcc.gnu.org/svn/gcc
>> Network connection closed unexpectedly: Unable to connect to a repository at
>> \
>> URL 'svn+ssh://gcc.gnu.org/svn/gcc': To better debug SSH connection
>> problems,
>> remove the -q option from 'ssh' in the [tunnels] section of your Subversion
>> configuration file. at /usr/lib/git/git-svn line 2299.
>>
>>
>> 2287 sub init_remote_config { [...]
>
> I surely don't see any "-q" on line 2299. Perhaps I need a "korbb@" inserted
> before the "gcc.gnu.org" in the command?
> [a moment passes]
>
> Yep. That's it. the "git svn init" command should be augmented with my
> login id at gcc.gnu.org. Thank you!
>
>> $ git svn init -Ttrunk --prefix=origin/ svn+ssh://logi...@gcc.gnu.org/svn/gcc
>
> So, "remove the -q option" really means, "provide your login id."
> Not especially obvious. :(
>
> Thank you!! - Bruce
Thank *you* for debugging this. Would you mind patching this part of
the script along with suggestion for running `svn upgrade'?
-- Gaby
forwprop: bit_field_ref(constructor)
Hello,
this patch lets forwprop fold bit_field_refs of constructors. It is
particularly useful in forwprop4, which happens after the pass that lowers
unsupported vector operations. Indeed, that pass keeps breaking vectors
into pieces and reconstructing them for each operation, which is a waste
when there are several operations in a row. This happens fairly late
though, and dead constructors are left lying around (no dead code
elimination after forwprop4) for the rtl layer to remove, so we are
probably missing possible optimizations.
Bootstrap+testsuite ok (well, still about a thousand FAILs, but it doesn't
increase with my patch).
2012-09-24 Marc Glisse
gcc/
* tree-ssa-forwprop.c: Include tree-ssa-propagate.h.
(simplify_bitfield_ref): Handle constructors.
* Makefile.in (tree-ssa-forwprop.o): Depend on tree-ssa-propagate.h.
gcc/testsuite/
* gcc.dg/tree-ssa/forwprop-23.c: New testcase.
--
Marc GlisseIndex: Makefile.in
===
--- Makefile.in (revision 191644)
+++ Makefile.in (working copy)
@@ -2239,21 +2239,21 @@ tree-outof-ssa.o : tree-outof-ssa.c $(TR
$(TREE_SSA_LIVE_H) $(BASIC_BLOCK_H) $(BITMAP_H) $(GGC_H) \
$(EXPR_H) $(SSAEXPAND_H) $(GIMPLE_PRETTY_PRINT_H)
tree-ssa-dse.o : tree-ssa-dse.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
$(TM_H) $(GGC_H) $(TREE_H) $(TM_P_H) $(BASIC_BLOCK_H) \
$(TREE_FLOW_H) $(TREE_PASS_H) domwalk.h $(FLAGS_H) \
$(GIMPLE_PRETTY_PRINT_H) langhooks.h
tree-ssa-forwprop.o : tree-ssa-forwprop.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
$(TM_H) $(TREE_H) $(TM_P_H) $(BASIC_BLOCK_H) $(CFGLOOP_H) \
$(TREE_FLOW_H) $(TREE_PASS_H) $(DIAGNOSTIC_H) \
langhooks.h $(FLAGS_H) $(GIMPLE_H) $(GIMPLE_PRETTY_PRINT_H) $(EXPR_H) \
- $(OPTABS_H)
+ $(OPTABS_H) tree-ssa-propagate.h
tree-ssa-phiprop.o : tree-ssa-phiprop.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
$(TM_H) $(TREE_H) $(TM_P_H) $(BASIC_BLOCK_H) \
$(TREE_FLOW_H) $(TREE_PASS_H) $(DIAGNOSTIC_H) \
langhooks.h $(FLAGS_H) $(GIMPLE_PRETTY_PRINT_H)
tree-ssa-ifcombine.o : tree-ssa-ifcombine.c $(CONFIG_H) $(SYSTEM_H) \
coretypes.h $(TM_H) $(TREE_H) $(BASIC_BLOCK_H) \
$(TREE_FLOW_H) $(TREE_PASS_H) $(DIAGNOSTIC_H) \
$(TREE_PRETTY_PRINT_H)
tree-ssa-phiopt.o : tree-ssa-phiopt.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
$(TM_H) $(GGC_H) $(TREE_H) $(TM_P_H) $(BASIC_BLOCK_H) \
Index: tree-ssa-forwprop.c
===
--- tree-ssa-forwprop.c (revision 191644)
+++ tree-ssa-forwprop.c (working copy)
@@ -27,20 +27,21 @@ along with GCC; see the file COPYING3.
#include "basic-block.h"
#include "gimple-pretty-print.h"
#include "tree-flow.h"
#include "tree-pass.h"
#include "langhooks.h"
#include "flags.h"
#include "gimple.h"
#include "expr.h"
#include "cfgloop.h"
#include "optabs.h"
+#include "tree-ssa-propagate.h"
/* This pass propagates the RHS of assignment statements into use
sites of the LHS of the assignment. It's basically a specialized
form of tree combination. It is hoped all of this can disappear
when we have a generalized tree combiner.
One class of common cases we handle is forward propagating a single use
variable into a COND_EXPR.
bb0:
@@ -2575,39 +2576,49 @@ simplify_bitfield_ref (gimple_stmt_itera
enum tree_code code;
op = gimple_assign_rhs1 (stmt);
gcc_checking_assert (TREE_CODE (op) == BIT_FIELD_REF);
op0 = TREE_OPERAND (op, 0);
if (TREE_CODE (op0) != SSA_NAME
|| TREE_CODE (TREE_TYPE (op0)) != VECTOR_TYPE)
return false;
+ def_stmt = get_prop_source_stmt (op0, false, NULL);
+ if (!def_stmt || !can_propagate_from (def_stmt))
+return false;
+
+ op1 = TREE_OPERAND (op, 1);
+ op2 = TREE_OPERAND (op, 2);
+ code = gimple_assign_rhs_code (def_stmt);
+
+ if (code == CONSTRUCTOR)
+{
+ tree tem = fold_ternary (BIT_FIELD_REF, TREE_TYPE (op),
+ gimple_assign_rhs1 (def_stmt), op1, op2);
+ if (!tem || !valid_gimple_rhs_p (tem))
+ return false;
+ gimple_assign_set_rhs_from_tree (gsi, tem);
+ update_stmt (gsi_stmt (*gsi));
+ return true;
+}
+
elem_type = TREE_TYPE (TREE_TYPE (op0));
if (TREE_TYPE (op) != elem_type)
return false;
size = TREE_INT_CST_LOW (TYPE_SIZE (elem_type));
- op1 = TREE_OPERAND (op, 1);
n = TREE_INT_CST_LOW (op1) / size;
if (n != 1)
return false;
-
- def_stmt = get_prop_source_stmt (op0, false, NULL);
- if (!def_stmt || !can_propagate_from (def_stmt))
-return false;
-
- op2 = TREE_OPERAND (op, 2);
idx = TREE_INT_CST_LOW (op2) / size;
- code = gimple_assign_rhs_code (def_stmt);
-
if (code == VEC_PERM_EXPR)
{
tree p, m, index, tem;
unsigned nelts;
m = gimple_assign_rhs3 (def_stmt);
if (TREE_CODE (m) != VECTOR_CST)
return false;
nelts = VECTOR_CST_NELTS (m);
idx = TREE_INT_CST_LOW (VECT
[Patch, Fortran, OOP] PR 54667: gimplification failure with c_f_pointer
Hi all, this patch fixes an ICE recently reported by Andrew Benson. It does so by rejecting polymorphic arguments to the C_F_POINTER intrinsic. For discussion and standard references, please refer to the PR and today's email thread. Apart from fixing this PR, the patch modifies two other error messages related to C_F_POINTER (adding the name of the formal arg in the message and applying correct Fortran terminology through the replacement 'parameter' -> 'argument'). It also fixes the grammar in the documentation of C_F_POINTER. Regtested on x86_64-unknown-linux-gnu. Ok for trunk? Cheers, Janus 2012-09-22 Janus Weil PR fortran/54667 * intrinsic.texi (C_F_POINTER): Fix description. * resolve.c (gfc_iso_c_sub_interface): Add a check for FPTR argument of C_F_POINTER. Modify two error messages. Cleanup. 2012-09-22 Janus Weil PR fortran/54667 * gfortran.dg/c_funloc_tests_6.f90: Modified error message. * gfortran.dg/c_f_pointer_shape_test.f90: Ditto. * gfortran.dg/c_f_pointer_tests_5.f90: New. pr54667.diff Description: Binary data c_f_pointer_tests_5.f90 Description: Binary data
Re: [Patch, Fortran] PR54618 fix some INTENT(OUT) issues for CLASS
Hi Tobias, > This patch fixes a couple of issues, I run into when working on FINAL > subroutines. > > > a) PR54618: > > (i) For a nonallocatable CLASS(...),INTENT(OUT), gfortran is setting the the > _def_init; however, for OPTIONAL this has to be guarded by an is-present > check. > > (ii) For CLASS(...),ALLOCATABLE, INTENT(OUT), gfortran didn't deallocate the > dummy argument - nor did it reset the var->_vtab to the declared type. > > Note: (ii) for polymorphic arrays has still to be implemented, currently, > only scalars are handled. There are also some other issues related to > OPTIONAL with polymorphic arrays. (See PR.) > > b) When working on FINAL, I also run into the problem that attr.alloc_comp > is set, when there is a pointer component, which only in turn has > allocatable components. That lead to an ICE (segfault) with my FINAL patch. > > c) I also include three coverity patches: > (i) resolve.c: "nl->sym" is many times dereferenced (before and after that > check), thus it cannot be NULL. > (ii) simplify.c: There is an "if (extremum == NULL) ... continue;", hence, > one always loops at least once before one reaches that line; but then "last" > gets set. Thus, the code is unreachable. > (iii) trans-array.c: Here, class_expr is NULL_TREE if the condition is > false, but TREE_TYPE(NULL_TREE) won't work. Hence, an assert is better. > > I intent to do two commits: One for (a) and one for the rest. > > Build and regtested on x86-64-linux. > OK for the trunk? yes, looks good to me. Thanks for the patch! Cheers, Janus
Re: Top Level GCC change questions
On Wed, 19 Sep 2012, sell...@mips.com wrote: > 2012-09-17 Ian Lance Taylor > > * MAINTAINERS (Various Maintainers): Add libbacktrace. > * configure.ac (host_libs): Add libbacktrace. > (target_libraries): Add libbacktrace. > * Makefile.def (host_modules): Add libbacktrace. > (target_modules): Likewise. > * configure, Makefile.in: Rebuild. I am still looking at it, but since this patch (but at least from a timing perspective), it looks like "make install" uses the build compiler, not the just built compiler, and hence fails when the former is older and does not grok flags supported in newer versions of GCC. (This may also predate this change, and for some reason now make install invokes builds when it did not do so earlier, or it is something different, but something's odd.) Gerald
[PATCH] fix gcc.dg/torture/pr53922.c on darwin
The attached patch eliminates the failures in linkage of the new
gcc.dg/torture/pr53922.c testcase on darwin by passing
-Wl,-undefined,dynamic_lookup
to the linker as recommended by the darwin linker developer...
http://gcc.gnu.org/ml/gcc-bugs/2012-09/msg01802.html
Tested on x86_64-apple-darwin11. Okay for gcc trunk and 4.7?
Jack
2012-09-22 Jack Howarth
gcc.dg/torture/pr53922.c: Use -Wl,-undefined,dynamic_lookup on darwin.
Index: gcc/testsuite/gcc.dg/torture/pr53922.c
===
--- gcc/testsuite/gcc.dg/torture/pr53922.c (revision 191648)
+++ gcc/testsuite/gcc.dg/torture/pr53922.c (working copy)
@@ -1,5 +1,6 @@
/* { dg-do run } */
/* { dg-require-weak "" } */
+/* { dg-options "-Wl,-undefined,dynamic_lookup" { target *-*-darwin* } } */
int x(int a)
{
