[Bug middle-end/42930] [graphite] crash when compiling scummvm on Ubuntu 9.10/amd64 with -floop-block

[spop at gcc dot gnu dot org]

--- Comment #4 from spop at gcc dot gnu dot org  2010-02-11 06:00 ---
Fixed on the Graphite branch, I will commit this to trunk after automatic
tests.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |spop at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-11 06:00:42
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42930

[Bug middle-end/42930] [graphite] crash when compiling scummvm on Ubuntu 9.10/amd64 with -floop-block

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2010-02-11 05:57 ---
Subject: Bug 42930

Author: spop
Date: Thu Feb 11 05:57:30 2010
New Revision: 156682

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156682
Log:
Fix PR42930.

2010-02-10  Sebastian Pop  

PR middle-end/42930
* graphite-scop-detection.c (graphite_can_represent_scev): Call
graphite_can_represent_init for MULT_EXPR.

Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/graphite-scop-detection.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42930

[Bug c++/41796] ambiguous subobject diagnostic given too early

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2010-02-11 05:29 ---
Thanks for pointing out that this has changed since C++03, though the change
was to fix to something that was clearly broken.

In any case, I disagree with issue 983.  The point of the example is that it
doesn't matter what subobject it refers to, as the type of &D::i is 'int B::*'.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796

[Bug middle-end/42973] [4.4/4.5 regression] IRA apparently systematically making reload too busy on 2 address instructions with 3 operands

[law at redhat dot com]

--- Comment #12 from law at redhat dot com  2010-02-11 04:49 ---
Subject: Re:  [4.4/4.5 regression] IRA apparently systematically
 making reload too busy on 2 address instructions with 3 operands

On 02/10/10 02:46, steven at gcc dot gnu dot org wrote:
> --- Comment #9 from steven at gcc dot gnu dot org  2010-02-10 09:46 
> ---
> What is the purpose of regmove these days, anyway? Isn't it all useless code
> thanks to IRA?
>
Not quite.  There were some hunks that were removed shortly after IRA 
was integrated.  The majority of what's left are things not handled by 
IRA.The code most likely to be useless right now is 
optimize_reg_copy_2.With some IRA work, optimize_reg_copy_1 might 
disappear.

optimize_reg_copy_3 optimizes zero & sign extensions.  One could argue 
this should be handled elsewhere.

fixup_match_2 optimizes constants in arithmetic insns -- the net result 
is some lifetimes may be shortened and autoinc opportunities may be 
exposed.  This could be handled by more modern techniques, but certainly 
isn't something IRA should be doing.
Jeff


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42973

[Bug c++/43024] ICE on template code with -O2 or -O3, regression from 4.4.2

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-02-11 03:20 ---
It is caused by revision 153881:

http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00097.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||jason at redhat dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-11 03:20:37
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43024

[Bug c++/41896] [c++0x] Segfault because of a nested lambda function

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2010-02-11 02:13 ---
Subject: Bug 41896

Author: jason
Date: Thu Feb 11 02:12:53 2010
New Revision: 156678

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156678
Log:
PR c++/41896
* semantics.c (outer_lambda_capture_p): Revert.
(add_capture): Only finish_member_declaration if
we're in the lambda class.
(register_capture_members): New.
* cp-tree.h: Declare it.
* parser.c (cp_parser_lambda_expression): Call it.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/parser.c
trunk/gcc/cp/semantics.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41896

[Bug preprocessor/43027] #pragma rejected inside enum defn

[PHHargrove at lbl dot gov]

--- Comment #2 from PHHargrove at lbl dot gov  2010-02-11 02:09 ---
(In reply to comment #1)
> Looks related to PR 37267 but that talks about #pragma inside struct.  Hmm.

Indeed this shares w/ PR 37267 the fact that the original code looks roughly
like:
   enum {
 #include "enum_body.h"
   };
and in my case the #pragma was inserted by a program that processes a .i file
and inserts #pragmas following #line directives that match certain criteria.

If, as with PR 37267, it is decided to resolve this as INVALID, I'd appreciate
a reference to the rules for what constitutes legal placement of #pragmas in
general (i.e. I don't need all the pragma-specific rules for placement).  Then
I can (hopefully) modify my .i-munging code to conform.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43027

[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *

[howarth at nitro dot med dot uc dot edu]

--- Comment #6 from howarth at nitro dot med dot uc dot edu  2010-02-11 
02:04 ---
This section in darwin.c seems a bit strange...

  if (!DECL_EXTERNAL (decl)
  && (!TREE_PUBLIC (decl) || !DECL_WEAK (decl))
  && ! lookup_attribute ("weakref", DECL_ATTRIBUTES (decl))
  && ((TREE_STATIC (decl)
   && (!DECL_COMMON (decl) || !TREE_PUBLIC (decl)))
  || (!DECL_COMMON (decl) && DECL_INITIAL (decl)
  && DECL_INITIAL (decl) != error_mark_node)))
SYMBOL_REF_FLAGS (sym_ref) |= MACHO_SYMBOL_FLAG_DEFINED;

Since they already test against...

  !DECL_WEAK (decl))

, I wonder if it might also need to test against...

 ! lookup_attribute ("weak", DECL_ATTRIBUTES (decl))


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854

[Bug libstdc++/42819] [DR 1315][C++0x] std::async fails to compile with simple tests, including N3000 example

[paolo dot carlini at oracle dot com]

--- Comment #29 from paolo dot carlini at oracle dot com  2010-02-11 01:59 
---
Thanks to the recent fixes and all the good work Jason did, I'm pretty sure
that now a normal enable_if or decltype on the return type would work just
fine. I'm wondering if we should just do that, for 4.5.0 and allow people to
experiment more easily with these facilities... I don't think we are risking
much, in any sense, wrt the actual resolution of 1315...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819

[Bug preprocessor/43027] #pragma rejected inside enum defn

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-02-11 01:54 ---
Looks related to PR 37267 but that talks about #pragma inside struct.  Hmm.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43027

[Bug preprocessor/43027] New: #pragma rejected inside enum defn

[PHHargrove at lbl dot gov]

Given the 3-line C file below, compilation with gcc-4.4.2 produces the output
that follows the code ("gcc -v" output provided as well).  I am not providing
the corresponding .i file under bug reporting guidelines "excuse ii": small
file that doesn't include any other file.

==begin code==
enum {
#pragma message "Hello from enum"
VALUE1, VALUE2 };
==end code==

$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr/local/pkg/gcc-4.4.2
--with-gmp=/usr/local/pkg/gmp-4.2.4 --with-mpfr=/usr/local/pkg/mpfr-2.3.2
--disable-nls --disable-bootstrap --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.4.2 (GCC)

$ gcc -c bug.c
bug.c:2: error: expected identifier before '#pragma'

I have tried a few other gcc versions (on both 32- and 64-bit targets) and any
I can find that are new enough to support "#pragma message" produce similar
results.  It is my suspicion that any supported (non-ignored) pragma is going
to trigger the same error.

While the utility of the #pragma inside the enum definition is questionable, I
am not aware of anything that would prohibit its placement there (but am
willing to be enlightened).  In fact, the struct and union definitions below
appear to work just fine:
   struct S {
  #pragma message "Hello from struct"
  int i;
  float f;
};
union U {
  #pragma message "Hello from union"
  int i;
  float f;
};

$ gcc -c notbug.c
notbug.c:2: note: #pragma message: Hello from struct
notbug.c:7: note: #pragma message: Hello from union


-- 
   Summary: #pragma rejected inside enum defn
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: PHHargrove at lbl dot gov


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43027

[Bug c++/41796] ambiguous subobject diagnostic given too early

[schaub-johannes at web dot de]

--- Comment #3 from schaub-johannes at web dot de  2010-02-11 01:08 ---
Well this is certainly not valid C++03, so i have tagged it c++0x (class member
name lookup was completely rewritten in c++0x, which made it valid and which
also added 10.2). In '03, the following should fail i think, instead of
re-declaring the member name as an alias to the declaration of "a" in A:

struct A { int a; }; 
struct B : A {}; 
struct C : A {}; 
struct D : B, C { }; 
struct E : D { using D::a; };

The example in 10.2/13 (n3000) is missing an ambiguity check: It's impossible
for GCC to figure out to which sub-object the member pointer address is
associated with. I think the example is wrong (see
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#983 for the issue
report about it).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796

[Bug tree-optimization/43026] ICE in sese.c with -fgraphite-identity in 447.dealII

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2010-02-11 01:02 ---
Created an attachment (id=19837)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19837&action=view)
minimized testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43026

[Bug tree-optimization/43026] New: ICE in sese.c with -fgraphite-identity in 447.dealII

[janis at gcc dot gnu dot org]

GCC trunk gets an internal compiler error when building SPEC CPU2006 test
447.dealII on powerpc64-linux with "-O2 -fgraphite-identity" or "-O2
-floop-parallelize-all" for either -m32 or -m64, as demonstrated by a minimized
testcase that I'll attach to this PR.  Perhaps someone else will be able to
minimize it more.

elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/g++ -c -O2
-fgraphite-identity bug.cc
bug.cc: In member function ‘void Base::getf2d(vector >&)
const [with int dim = 3]’:
bug.cc:38:6: internal compiler error: in expand_scalar_variables_expr, at
sese.c:907
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The testcase and dealII compile correctly with GCC 4.4.2 using "-O2
-fgraphite-identity".  The failure starts with this patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=155739

r155739 | spop | 2010-01-08 16:07:18 + (Fri, 08 Jan 2010)


-- 
   Summary: ICE in sese.c with -fgraphite-identity in 447.dealII
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc64-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43026

[Bug middle-end/42344] [4.5 Regression] ICE in rs6000.md with ipa-sra for 252.eon

[janis at gcc dot gnu dot org]

--- Comment #9 from janis at gcc dot gnu dot org  2010-02-11 00:50 ---
I tried the patch and it fixes both of the problems with eon.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42344

[Bug tree-optimization/42771] [4.5 Regression][graphite] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2)

[sebpop at gmail dot com]

--- Comment #11 from sebpop at gmail dot com  2010-02-11 00:29 ---
Subject: Re:  [4.5 Regression][graphite] ICE: in 
graphite_loop_normal_form, at graphite-sese-to-poly.c (2)

On Wed, Feb 10, 2010 at 12:26, amonakov at gcc dot gnu dot org
 wrote:
> I don't see how this patch makes simple_iv call from number_of_iterations_exit
> return true for j_20.  Could you please kindly explain?

We used to analyze the second scop after the code generation of the
first one.  In that context, the scalar evolution analysis failed to
analyze the code containing scalar computations stored and read from
arrays with 1 element (introduced by the code generation and analysis
part).  We now analyze all the scops before code generating them:
thus, we don't have to invalidate the scalar evolution hash tables
between the analysis of two scops.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42771

Re: [Bug tree-optimization/42771] [4.5 Regression][graphite] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2)

[Sebastian Pop]

On Wed, Feb 10, 2010 at 12:26, amonakov at gcc dot gnu dot org
 wrote:
> I don't see how this patch makes simple_iv call from number_of_iterations_exit
> return true for j_20.  Could you please kindly explain?

We used to analyze the second scop after the code generation of the
first one.  In that context, the scalar evolution analysis failed to
analyze the code containing scalar computations stored and read from
arrays with 1 element (introduced by the code generation and analysis
part).  We now analyze all the scops before code generating them:
thus, we don't have to invalidate the scalar evolution hash tables
between the analysis of two scops.

[Bug target/43025] 32-bit x86 switch table refers to local symbols with -fPIC

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-02-11 00:05 ---
I'd say this is a gas bug, I don't see why if we don't need on x86 the local
symbols in .long .L3 or call .L3 cases, we don't need it for .long @gotoff
either, resolving it to .text +  is perfectly fine.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43025

[Bug target/43025] New: 32-bit x86 switch table refers to local symbols with -fPIC

[ian at airs dot com]

Compile this code for 32-bit using -fPIC:

int fn(int i) {
  switch (i)
{
case 0:
  return 0;
case 1:
  return 1;
case 2:
  return 2;
case 3:
  return 3;
case 4:
  return 4;
case 5:
  return 5;
case 6:
  return 6;
case 7:
  return 7;
case 8:
  return 8;
case 9:
  return 9;
default:
  return 10;
}
}

When I do that, I get a switch table in .rodata.  The switch table has entries
like
.long   @gotoff
Since .L3 is defined in the .text section, this causes the assembler to emit a
R_386_GOTOFF relocation against the local symbol .L3.  This causes the local
symbol to be emitted into the symbol table.  That is undesirable.  It would be
better to write out something like
.long   f...@gotoff+(.L3-fn)
which would not require any additional entries in the symbol table.


-- 
   Summary: 32-bit x86 switch table refers to local symbols with -
fPIC
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43025

[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to poor register allocation

[steven at gcc dot gnu dot org]

--- Comment #20 from steven at gcc dot gnu dot org  2010-02-10 23:53 ---
I'll leave it to someone else to implement and test the details...


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||steven at gcc dot gnu dot
   ||org
 AssignedTo|steven at gcc dot gnu dot   |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871

[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to poor register allocation

[steven at gcc dot gnu dot org]

--- Comment #19 from steven at gcc dot gnu dot org  2010-02-10 23:47 ---
In r118474, cse.c:find_best_addr makes the replacement here:

  if ((addr_folded_cost < addr_cost
   || (addr_folded_cost == addr_cost
   /* ??? The rtx_cost comparison is left over from an older
  version of this code.  It is probably no longer
helpful.*/
   && (rtx_cost (folded, MEM) > rtx_cost (addr, MEM)
   || approx_reg_cost (folded) < approx_reg_cost (addr
  && validate_change (insn, loc, folded, 0))
addr = folded;

All the costs are the same, except the approx_reg_cost tests:

(gdb) p debug_rtx(addr)
(plus:SI (reg/f:SI 102)
(const_int 4 [0x4]))
$35 = void
(gdb) p debug_rtx(folded)
(plus:SI (reg/f:SI 25 sfp)
(const_int -8 [0xfff8]))
$36 = void
(gdb) p approx_reg_cost(addr)
$37 = 1
(gdb) p approx_reg_cost(folded)
$38 = 0
(gdb) 

The cost difference comes from approx_reg_cost_1, which uses CHEAP_REGNO for
regs. CHEAP_REGNO prefers the frame pointer reg over normal pseudos:

/* Compute cost of X, as stored in the `cost' field of a table_elt.  Fixed
   hard registers and pointers into the frame are the cheapest with a cost
   of 0.  Next come pseudos with a cost of one and other hard registers with
   a cost of 2.  Aside from these special cases, call `rtx_cost'.  */

#define CHEAP_REGNO(N)  \
  (REGNO_PTR_FRAME_P(N) \
   || (HARD_REGISTER_NUM_P (N)  \
   && FIXED_REGNO_P (N) && REGNO_REG_CLASS (N) != NO_REGS))

This shouldn't be very difficult to teach fwprop about, too.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871

[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to poor register allocation

[ramana at gcc dot gnu dot org]

--- Comment #18 from ramana at gcc dot gnu dot org  2010-02-10 23:45 ---
(In reply to comment #16)
> In fwprop.c of r118475, we get to propagate_rtx_1 (fwprop.c:334):
> 
>   /* Copy propagations are always ok.  Otherwise check the costs.  */
>   if (!(REG_P (old) && REG_P (new))
>   && !should_replace_address (op0, new_op0, GET_MODE (x)))
> return true;
> 
> At this point the simplified address has been found, but fwprop decides not to
> substitute the new address:
> 
> (gdb) p debug_rtx(op0)
> (plus:SI (reg/f:SI 102)
> (const_int 4 [0x4]))
> $58 = void
> (gdb) p debug_rtx(new_op0)
> (plus:SI (reg/f:SI 25 sfp)
> (const_int -8 [0xfff8]))
> $59 = void
> (gdb) p should_replace_address(op0,new_op0,SImode)
> $60 = 0 '\000'
> 
> The replacement isn't done because fwprop sees no benefit in doing the
> transformation. Stepping through should_replace_address we get:
> 
> 202   gain = address_cost (old, mode) - address_cost (new, mode);
> (gdb) next
> 208   if (gain == 0)
> (gdb) p gain
> $64 = 0
> (gdb) next
> 209 gain = rtx_cost (new, SET) - rtx_cost (old, SET);
> (gdb) 
> 211   return (gain > 0);
> (gdb) p gain
> $65 = 0
> 
> Perhaps we should prefer addresses based on the frame pointer over other
> addresses?
> 


Why does this sound like some bit of the discussion in this thread here
?http://gcc.gnu.org/ml/gcc/2009-12/msg00347.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871

[Bug fortran/42954] gfortran with libcpp: TARGET_*_CPP_BUILDINS issues (MinGW, FreeBSD, MIPS, Fry)

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2010-02-10 23:40 ---
(In reply to comment #2)
> Daniel: Wouldn't it be enough to duplicate c-cppbuiltin.c's
> builtin_define_with_value and builtin_define_with_int_value for fortran/cpp.c?
> Regarding builtin_define_std: Couldn't one simply define __ and 
> (after stripping leading _) ignoring the unmodified version?

I tried this but it fails on x86-64-linux with:
  cpp.c:(.text+0x1d6b): undefined reference to `ix86_target_macros'
which is the file gcc/config/i386/i386-c.c for
  #define TARGET_CPU_CPP_BUILTINS() ix86_target_macros ()


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954

[Bug middle-end/41290] [4.5 regression] ICE: edge points to wrong declaration

[foom at fuhm dot net]

--- Comment #15 from foom at fuhm dot net  2010-02-10 23:24 ---
Nope, adding -fno-indirect-inlining has no effect.

I'm now using:
g++-4.5 (Debian 4.5-20100202-1) 4.5.0 20100202 (experimental) [trunk revision
156452]

Problem still occurs, -fno-ipa-cp still makes it go away.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41290

[Bug middle-end/42344] [4.5 Regression] ICE in rs6000.md with ipa-sra for 252.eon

[amodra at gmail dot com]

--- Comment #8 from amodra at gmail dot com  2010-02-10 23:20 ---
I haven't tested my patch against eon, just the testcase here and of course the
gcc testsuite.  Latest patch url given above


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42344

[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to poor register allocation

[bonzini at gnu dot org]

--- Comment #17 from bonzini at gnu dot org  2010-02-10 23:11 ---
Subject: Re:  [4.3/4.4/4.5 regression] Code size
 increase on ARM due to poor register allocation


> Perhaps we should prefer addresses based on the frame pointer over other
> addresses?

Yes, that's definitely better from a register pressure point of view. 
(That's however not why CSE was doing that---probably that was just 
hashing luck).

Paolo


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871

[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to poor register allocation

[steven at gcc dot gnu dot org]

--- Comment #16 from steven at gcc dot gnu dot org  2010-02-10 22:50 ---
In fwprop.c of r118475, we get to propagate_rtx_1 (fwprop.c:334):

  /* Copy propagations are always ok.  Otherwise check the costs.  */
  if (!(REG_P (old) && REG_P (new))
  && !should_replace_address (op0, new_op0, GET_MODE (x)))
return true;

At this point the simplified address has been found, but fwprop decides not to
substitute the new address:

(gdb) p debug_rtx(op0)
(plus:SI (reg/f:SI 102)
(const_int 4 [0x4]))
$58 = void
(gdb) p debug_rtx(new_op0)
(plus:SI (reg/f:SI 25 sfp)
(const_int -8 [0xfff8]))
$59 = void
(gdb) p should_replace_address(op0,new_op0,SImode)
$60 = 0 '\000'

The replacement isn't done because fwprop sees no benefit in doing the
transformation. Stepping through should_replace_address we get:

202   gain = address_cost (old, mode) - address_cost (new, mode);
(gdb) next
208   if (gain == 0)
(gdb) p gain
$64 = 0
(gdb) next
209 gain = rtx_cost (new, SET) - rtx_cost (old, SET);
(gdb) 
211   return (gain > 0);
(gdb) p gain
$65 = 0

Perhaps we should prefer addresses based on the frame pointer over other
addresses?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871

[Bug middle-end/42344] [4.5 Regression] ICE in rs6000.md with ipa-sra for 252.eon

[janis at gcc dot gnu dot org]

--- Comment #7 from janis at gcc dot gnu dot org  2010-02-10 22:48 ---
Alan, do you have an update on this?  Does you patch fix just the ICE or also
the runtime segfault described in comment #2?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42344

[Bug c++/41896] [c++0x] Segfault because of a nested lambda function

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2010-02-10 22:46 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
Summary|[cxx0x-lambda] Segfault |[c++0x] Segfault because of
   |because of a nested lambda  |a nested lambda function
   |function|
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41896

[Bug c++/41896] [cxx0x-lambda] Segfault because of a nested lambda function

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2010-02-10 22:45 ---
Subject: Bug 41896

Author: jason
Date: Wed Feb 10 22:45:07 2010
New Revision: 156673

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156673
Log:
PR c++/41896
* semantics.c (outer_lambda_capture_p): Use current_function_decl
instead of current_class_type.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41896

[Bug c++/41896] [cxx0x-lambda] Segfault because of a nested lambda function

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-10 22:01:58
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41896

[Bug c++/43016] [C++0x] Inappropriate multiple definition error for lambda function when inside inline functions

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2010-02-10 22:00 ---
Fixed for 4.5.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43016

[Bug c++/42983] [C++0x] Defaulted virtual destructor isn't virtual

[jason at gcc dot gnu dot org]

--- Comment #20 from jason at gcc dot gnu dot org  2010-02-10 22:00 ---
Fixed (to require defaulting outside the class) for 4.5.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42983

[Bug c++/42983] [C++0x] Defaulted virtual destructor isn't virtual

[jason at gcc dot gnu dot org]

--- Comment #19 from jason at gcc dot gnu dot org  2010-02-10 21:48 ---
Subject: Bug 42983

Author: jason
Date: Wed Feb 10 21:48:35 2010
New Revision: 156672

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156672
Log:
PR c++/42983, core issue 906
* method.c (defaultable_fn_check): Check virtualness.
* include/std/thread (~_Impl_base): Move default out of line.
* libsupc++/nested_exception.h (~nested_exception): Likewise.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/defaulted15.C
trunk/gcc/testsuite/g++.dg/cpp0x/defaulted9.C
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/thread
trunk/libstdc++-v3/libsupc++/nested_exception.h
   
trunk/libstdc++-v3/testsuite/18_support/nested_exception/rethrow_if_nested.cc
   
trunk/libstdc++-v3/testsuite/18_support/nested_exception/throw_with_nested.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42983

[Bug c++/43016] [C++0x] Inappropriate multiple definition error for lambda function when inside inline functions

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2010-02-10 21:48 ---
Subject: Bug 43016

Author: jason
Date: Wed Feb 10 21:48:25 2010
New Revision: 156671

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156671
Log:
PR c++/43016
* semantics.c (maybe_add_lambda_conv_op): Set DECL_INTERFACE_KNOWN.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv.C


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43016

[Bug java/41802] When attempting to compile pdftk-1.41 my machine comes to a grind

[howarth at nitro dot med dot uc dot edu]

--- Comment #6 from howarth at nitro dot med dot uc dot edu  2010-02-10 
21:38 ---
Even if you fix this issue, I don't believe you will be able to compile
pdftk.cc with gcc 4.3 or later...

http://gcc.gnu.org/ml/java/2008-03/msg00028.html

due to the code incorrectly mixing c++ and java exceptions which are no longer
allowed under FSF gcc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41802

[Bug libstdc++/43014] map [] behaviour is inconsistent

[gcc_bugzilla dot 20 dot marcelitom at inboxclean dot com]

--- Comment #8 from gcc_bugzilla dot 20 dot marcelitom at inboxclean dot 
com  2010-02-10 21:23 ---
Thanks Paolo. I did understand that map was passing a . I wrongly
assumed that it was using it to copy the pointed string to the map, but I
learned from your first post that it was only copying the pointer.

May be I did not express myself clear, my surprise was that it was only copying
the pointer and not the string.

And yes, I wanted to use a string in the first place... I don't know where I
got that it was not possible to use string as a template for map, I was wrong.
I will use string then, thanks!


-- 

gcc_bugzilla dot 20 dot marcelitom at inboxclean dot com changed:

   What|Removed |Added

 CC||gcc_bugzilla dot 20 dot
   ||marcelitom at inboxclean dot
   ||com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43014

[Bug java/41802] When attempting to compile pdftk-1.41 my machine comes to a grind

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-02-10 20:47 ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > ecj1 is really the Eclipse frontend which we just inherit, the GCC java
> > > frontend (which just handles bytecode) is called jc1.
> > 
> > Why starting from gcc 4.3 jc1 handles only bytecode and no more java source?
> > 
> > > This bug also misses a testcase to reproduce the problem.
> > 
> > You can reproduce the problem only into x86_64 platform:
> > 1. Download pdftk http://www.pdfhacks.com/pdftk/pdftk-1.41.tar.bz2
> > 2. cd pdftk-1.41/java_libs/com/lowagie/text
> > 3. gcj -O2 -w --classpath="../../../" -c Anchor.java -o Anchor.o
> > 4. ecj1 allocates about 4.2GB of memory
> > 5. If you have enough memory (I have 2GB RAM + 3GB swap), compilation ends
> > successfully, even if after many time due to swapping.
> > 
> > ecj1 on x86_32 (same gcc version and build options) or jc1 on x86_64 (gcc
> > 4.2.4) require only about 85 MB of memory.
> > 
> > > You can a more recent ecj version, like that which is downloaded by
> > > the contrib/download_ecj.
> > 
> > ecj-4.5.jar (actually the latest ecj) does not resolve the problem. 
> > 
> > > Well - not really a GCC bug.
> > 
> > Ok, but we have no other options to compile java sources with gcc 4.3 (only
> > downgrade to 4.2)... 
> 
> Use another Java-to-bytecode compiler and feed gcc with bytecode.

Btw, the symptoms you are seeing hint at not working garbage collection.
You might want to report this to your operating system vendor.

Richard.

> Richard.
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41802

[Bug java/41802] When attempting to compile pdftk-1.41 my machine comes to a grind

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-02-10 20:46 ---
(In reply to comment #3)
> (In reply to comment #2)
> > ecj1 is really the Eclipse frontend which we just inherit, the GCC java
> > frontend (which just handles bytecode) is called jc1.
> 
> Why starting from gcc 4.3 jc1 handles only bytecode and no more java source?
> 
> > This bug also misses a testcase to reproduce the problem.
> 
> You can reproduce the problem only into x86_64 platform:
> 1. Download pdftk http://www.pdfhacks.com/pdftk/pdftk-1.41.tar.bz2
> 2. cd pdftk-1.41/java_libs/com/lowagie/text
> 3. gcj -O2 -w --classpath="../../../" -c Anchor.java -o Anchor.o
> 4. ecj1 allocates about 4.2GB of memory
> 5. If you have enough memory (I have 2GB RAM + 3GB swap), compilation ends
> successfully, even if after many time due to swapping.
> 
> ecj1 on x86_32 (same gcc version and build options) or jc1 on x86_64 (gcc
> 4.2.4) require only about 85 MB of memory.
> 
> > You can a more recent ecj version, like that which is downloaded by
> > the contrib/download_ecj.
> 
> ecj-4.5.jar (actually the latest ecj) does not resolve the problem. 
> 
> > Well - not really a GCC bug.
> 
> Ok, but we have no other options to compile java sources with gcc 4.3 (only
> downgrade to 4.2)... 

Use another Java-to-bytecode compiler and feed gcc with bytecode.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41802

[Bug other/42530] [graphite] ICE in verify_ssa when using -O -g -ffast-math -floop-parallelize-all

[spop at gcc dot gnu dot org]

--- Comment #4 from spop at gcc dot gnu dot org  2010-02-10 20:24 ---
Subject: Bug 42530

Author: spop
Date: Wed Feb 10 20:23:41 2010
New Revision: 156668

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156668
Log:
Fix PR42914 and PR42530.

2010-02-10  Sebastian Pop  

PR middle-end/42914
PR middle-end/42530
* graphite-sese-to-poly.c (remove_phi): New.
(translate_scalar_reduction_to_array): Call remove_phi.

* gcc.dg/graphite/pr42530.c: New.
* gcc.dg/graphite/pr42914.c: New.

Added:
branches/graphite/gcc/testsuite/gcc.dg/graphite/pr42530.c
branches/graphite/gcc/testsuite/gcc.dg/graphite/pr42914.c
Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/graphite-sese-to-poly.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42530

[Bug middle-end/42914] [4.5 Regression][graphite] ICE with -g -ffast-math -fgraphite-identity -O2: verify_ssa failed

[spop at gcc dot gnu dot org]

--- Comment #6 from spop at gcc dot gnu dot org  2010-02-10 20:24 ---
Subject: Bug 42914

Author: spop
Date: Wed Feb 10 20:23:41 2010
New Revision: 156668

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156668
Log:
Fix PR42914 and PR42530.

2010-02-10  Sebastian Pop  

PR middle-end/42914
PR middle-end/42530
* graphite-sese-to-poly.c (remove_phi): New.
(translate_scalar_reduction_to_array): Call remove_phi.

* gcc.dg/graphite/pr42530.c: New.
* gcc.dg/graphite/pr42914.c: New.

Added:
branches/graphite/gcc/testsuite/gcc.dg/graphite/pr42530.c
branches/graphite/gcc/testsuite/gcc.dg/graphite/pr42914.c
Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/graphite-sese-to-poly.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42914

[Bug web/36739] Proposal for clarifications in GCC Bugzilla

[LpSolit at netscape dot net]

--- Comment #7 from LpSolit at netscape dot net  2010-02-10 20:04 ---
(In reply to comment #3)
> We should really upgrade bugzilla to version 3.0

bug 43011. :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36739

[Bug java/41802] When attempting to compile pdftk-1.41 my machine comes to a grind

[lucabon at interfree dot it]

--- Comment #3 from lucabon at interfree dot it  2010-02-10 19:56 ---
(In reply to comment #2)
> ecj1 is really the Eclipse frontend which we just inherit, the GCC java
> frontend (which just handles bytecode) is called jc1.

Why starting from gcc 4.3 jc1 handles only bytecode and no more java source?

> This bug also misses a testcase to reproduce the problem.

You can reproduce the problem only into x86_64 platform:
1. Download pdftk http://www.pdfhacks.com/pdftk/pdftk-1.41.tar.bz2
2. cd pdftk-1.41/java_libs/com/lowagie/text
3. gcj -O2 -w --classpath="../../../" -c Anchor.java -o Anchor.o
4. ecj1 allocates about 4.2GB of memory
5. If you have enough memory (I have 2GB RAM + 3GB swap), compilation ends
successfully, even if after many time due to swapping.

ecj1 on x86_32 (same gcc version and build options) or jc1 on x86_64 (gcc
4.2.4) require only about 85 MB of memory.

> You can a more recent ecj version, like that which is downloaded by
> the contrib/download_ecj.

ecj-4.5.jar (actually the latest ecj) does not resolve the problem. 

> Well - not really a GCC bug.

Ok, but we have no other options to compile java sources with gcc 4.3 (only
downgrade to 4.2)... 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41802

[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5

[LpSolit at netscape dot net]

--- Comment #16 from LpSolit at netscape dot net  2010-02-10 19:48 ---
(In reply to comment #15)
> No such check for adding comments from email replies, but adding a comment 
> doesn't require privileges (and the password for an autocreated account is 
> of course sent to the email address for that account, so an impersonator 
> won't get the password).  I don't know about the functionality for doing 
> anything else by email.

Newer Bugzilla releases no longer send you an email with your password in it.
They send you an email with a URL in it which brings you to a page where you
enter your name and password (this avoids creating fake accounts with invalid
or undesired email addresses).

About what you can do by email, newer releases let you edit almost all aspects
of bugs, including the CC list, assignee, severity, priority, bug status and
resolution, etc... etc You can even attach files if you want to (in
Bugzilla 3.6). :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011

[Bug fortran/37039] Cray pointer with pointee DIMENSION statement after POINTER statement

[langton at gcc dot gnu dot org]

-- 

langton at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |langton at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-03-29 08:26:51 |2010-02-10 19:38:57
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37039

[Bug c++/43024] ICE on template code with -O2 or -O3, regression from 4.4.2

[orzel at freehackers dot org]

--- Comment #1 from orzel at freehackers dot org  2010-02-10 19:33 ---
Created an attachment (id=19836)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19836&action=view)
as provided by -save-temps


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43024

[Bug c++/43024] New: ICE on template code with -O2 or -O3, regression from 4.4.2

[orzel at freehackers dot org]

Upgrading from 4.4.2 to 4.4.3, gcc now segfaults when compiling my file. I've
narrowed both the command line and the cpp file (30 lines, visible at the end
of the *.ii attached). Most of the included code is from eigen
(http://eigen.tuxfamily.org/) and is publicly visible on 
http://bitbucket.org/eigen/eigen

When compiled with -O2 or -O3 the segfaults is triggered, without -O option,
the file compiles fine.

The complete line i use is:
g++ -c -O3 -I../../eigen2-tip -o ice.o ice.cpp -save-temps

The output is:

In file included from ../../eigen2-tip/Eigen/Core:178,
 from
../../eigen2-tip/unsupported/Eigen/NonLinearOptimization:29,
 from ice.cpp:3:
../../eigen2-tip/Eigen/src/Core/DenseStorageBase.h: In member function
‘Eigen::LevenbergMarquardtSpace::Status Eigen::LevenbergMarquardt::minimizeOneStep(Eigen::Matrix&, int)
[with FunctorType = myFunctor, Scalar = double]’:
../../eigen2-tip/Eigen/src/Core/DenseStorageBase.h:516: internal compiler
error: Segmentation fault
Please submit a full bug report, with preprocessed source if appropriate.
See  for instructions.  


The output of gcc -v is (i'm using gentoo) :

Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/usr/data/tmp/portage/sys-devel/gcc-4.4.3/work/gcc-4.4.3/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-ppl --without-cloog --enable-nls
--without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --enable-multilib --enable-libmudflap
--disable-libssp --enable-libgomp --enable-cld
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/python
--disable-libgcj --enable-languages=c,c++ --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.3 p1.0'
Thread model: posix
gcc version 4.4.3 (Gentoo 4.4.3 p1.0)



-- 
   Summary: ICE on template code with -O2 or -O3, regression from
4.4.2
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: orzel at freehackers dot org
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43024

[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to poor register allocation

[steven at gcc dot gnu dot org]

--- Comment #15 from steven at gcc dot gnu dot org  2010-02-10 19:24 ---
The difference between r118474 (left) and r118475 just before register
allocation (in the .life2 dumps) is this:

2 NOTE_INSN_DELETED 2 NOTE_INSN_DELETED
8 NOTE_INSN_BASIC_BLOCK 8 NOTE_INSN_BASIC_BLOCK
6 r101:SI=r0:SI 6 r101:SI=r0:SI
  REG_DEAD: r0:SI REG_DEAD: r0:SI
7 NOTE_INSN_FUNCTION_BEG7 NOTE_INSN_FUNCTION_BEG
   11 r102:SI=sfp:SI-0xc   11 r102:SI=sfp:SI-0xc
   12 r103:SI=[r101:SI]12 r103:SI=[r101:SI]
   13 [sfp:SI-0x8]=r103:SI  |  13 [r102:SI+0x4]=r103:SI
  REG_DEAD: r103:SI   REG_DEAD: r103:SI
   16 r105:SI=[r101:SI+0x4]16 r105:SI=[r101:SI+0x4]
  REG_DEAD: r101:SI   REG_DEAD: r101:SI
   17 r0:SI=r102:SI17 r0:SI=r102:SI
  REG_DEAD: r102:SI   REG_DEAD: r102:SI
  REG_EQUAL: sfp:SI-0xc   REG_EQUAL: sfp:SI-0xc
   18 r1:SI=r105:SI18 r1:SI=r105:SI
  REG_DEAD: r105:SI   REG_DEAD: r105:SI
   19 call [`func'] argc:0x0   19 call [`func'] argc:0x0
  REG_DEAD: r0:SI REG_DEAD: r0:SI
  REG_DEAD: r1:SI REG_DEAD: r1:SI
  REG_UNUSED: lr:SI   REG_UNUSED: lr:SI
   20 NOTE_INSN_FUNCTION_END   20 NOTE_INSN_FUNCTION_END


In r118474 the cse1 pass transforms the code on the left (.jump dump) to the
code on the right (.cse1 dump):

   11 r102:SI=sfp:SI-0xc   11 r102:SI=sfp:SI-0xc
   12 r103:SI=[r101:SI]12 r103:SI=[r101:SI]
   13 [r102:SI+0x4]=r103:SI   |13 [sfp:SI-0x8]=r103:SI

apparently noticing that "sfp-0xc+0x4" == "sfp-0x8". It would be interesting to
know why fwprop is not doing this transformation.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871

[Bug tree-optimization/43012] [4.5 Regression][graphite] wrong code for -floop-strip-mine in 453.povray

[amonakov at gcc dot gnu dot org]

--- Comment #2 from amonakov at gcc dot gnu dot org  2010-02-10 18:41 
---
Confirming. Reproducible on amd64-linux.

This appears to be a bug in CLooG.  Disable CLooG optimizations on graphite
branch fixes the bug.  The problem is that CLooG generates wrong bounds for
parts of strip-mined loop (bounds of the first and the last loops are wrong):

for (scat_3=-51;scat_3<=63;scat_3++) {
  S3(scat_3) ;
  S4(scat_3) ;
}
for (scat_3=64;scat_3<=76;scat_3++) {
  S3(scat_3) ;
  S6(scat_3) ;
}
for (scat_3=77;scat_3<=88;scat_3++) {
  S3(scat_3) ;
  S8(scat_3) ;
}
for (scat_3=89;scat_3<=-1;scat_3++) {
  S3(scat_3) ;
}


-- 

amonakov at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-10 18:41:13
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43012

[Bug c++/43016] [C++0x] Inappropriate multiple definition error for lambda function when inside inline functions

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-02-10 18:40 
---
Thanks.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC|jason at gcc dot gnu dot org|


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43016

[Bug fortran/43019] [F2008] BLOCK (block_6.f08): Scope of implicitly typed variables

[domob at gcc dot gnu dot org]

--- Comment #2 from domob at gcc dot gnu dot org  2010-02-10 18:26 ---
This is part of what I mention in comment 6 of PR 39626, will work on it there.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43019

[Bug tree-optimization/42771] [4.5 Regression][graphite] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2)

[amonakov at gcc dot gnu dot org]

--- Comment #10 from amonakov at gcc dot gnu dot org  2010-02-10 18:26 
---
(In reply to comment #9)
> Fixed as described in 
> http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00436.html
> 

I don't see how this patch makes simple_iv call from number_of_iterations_exit
return true for j_20.  Could you please kindly explain?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42771

[Bug fortran/39626] Correctly implement details of Fortran 2008 BLOCK construct

[domob at gcc dot gnu dot org]

--- Comment #8 from domob at gcc dot gnu dot org  2010-02-10 18:26 ---
*** Bug 43019 has been marked as a duplicate of this bug. ***


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39626

[Bug fortran/43019] [F2008] BLOCK (block_6.f08): Scope of implicitly typed variables

[domob at gcc dot gnu dot org]

--- Comment #1 from domob at gcc dot gnu dot org  2010-02-10 18:26 ---


*** This bug has been marked as a duplicate of 39626 ***


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43019

[Bug tree-optimization/43023] missing SSA_NAME def for -ftree-loop-distribution in 459.GemsFDTD

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-02-10 18:24 ---
Confirmed on i?86.  Latent bug in loop-distribution.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||spop at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
 GCC target triplet|powerpc64-linux |powerpc64-linux, i?86-linux
   Last reconfirmed|-00-00 00:00:00 |2010-02-10 18:24:55
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43023

[Bug middle-end/42914] [4.5 Regression][graphite] ICE with -g -ffast-math -fgraphite-identity -O2: verify_ssa failed

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-02-10 18:19 ---
(In reply to comment #4)
> Debug stmts do not seem to be reachable from basic iterators like:
> 
>   FOR_EACH_IMM_USE_STMT (stmt, imm_iter, def)
> if (is_gimple_debug (stmt))
>   {
> gimple_debug_bind_reset_value (stmt);
> update_stmt (stmt);
>   }
> 
> Is there another way to iterate over all the uses of an SSA_NAME
> that might be used in a debug stmt?

They should - the issue must be elsewhere


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42914

[Bug c++/43016] [C++0x] Inappropriate multiple definition error for lambda function when inside inline functions

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-10 18:11:09
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43016

[Bug middle-end/43020] [4.4 regression] varargs of pointer types triggers coredump

[nix at esperi dot org dot uk]

--- Comment #6 from nix at esperi dot org dot uk  2010-02-10 17:57 ---
That's bizarre. Looking at the 4.4 source code. va_end expands to a NOP.

But, yes, that's a bug, all right. I'm not sure if this is still considered a
regression, given that va_end() is widely ignored and omitted by a large body
of software that works virtually everywhere...


-- 

nix at esperi dot org dot uk changed:

   What|Removed |Added

Summary|[4.3 regression] varargs of |[4.4 regression] varargs of
   |pointer types triggers  |pointer types triggers
   |coredump|coredump


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43020

[Bug tree-optimization/43023] New: missing SSA_NAME def for -ftree-loop-distribution in 459.GemsFDTD

[janis at gcc dot gnu dot org]

GCC trunk gets an internal compiler error when building SPEC CPU2006 test
459.GemsFDTD on powerpc64-linux with "-O2 -ftree-loop-distribution" for either
-m32 or -m64, as demonstrated by this minimized testcase:

-
MODULE NFT_mod

implicit none
integer :: Nangle
real:: Z0
real, dimension(:,:), allocatable :: Angle
real, dimension(:), allocatable :: exth, ezth, hxth, hyth, hyphi

CONTAINS

SUBROUTINE NFT_Init()

real :: th, fi
integer :: n

do n = 1,Nangle
  th = Angle(n,1)
  fi = Angle(n,2)

  exth(n) =  cos(fi)*cos(th)
  ezth(n) = -sin(th)
  hxth(n) = -sin(fi)
  hyth(n) =  cos(fi)
  hyphi(n) = -sin(fi)
end do
END SUBROUTINE NFT_Init

END MODULE NFT_mod
-

elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/gfortran -c -O2
-ftree-loop-distribution bug.f90
bug.f90: In function ‘nft_init’:
bug.f90:11:0: error: missing definition
for SSA_NAME: D.772_61 in statement:
# .MEM_98 = VDEF <.MEM_83>
(*pretmp.25_71)[D.772_61] = D.775_97;
bug.f90:11:0: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The testcase and GemsFTDT compile correctly with GCC 4.4.2.  The failure starts
with this patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=151761

r151761 | matz | 2009-09-16 16:12:18 + (Wed, 16 Sep 2009)


-- 
   Summary: missing SSA_NAME def for -ftree-loop-distribution in
459.GemsFDTD
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc64-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43023

[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to poor register allocation

[steven at gcc dot gnu dot org]

--- Comment #14 from steven at gcc dot gnu dot org  2010-02-10 17:50 ---
Vlad, this is another one that you probably should have a look at, please.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871

[Bug middle-end/42914] [4.5 Regression][graphite] ICE with -g -ffast-math -fgraphite-identity -O2: verify_ssa failed

[spop at gcc dot gnu dot org]

--- Comment #4 from spop at gcc dot gnu dot org  2010-02-10 17:29 ---
Debug stmts do not seem to be reachable from basic iterators like:

  FOR_EACH_IMM_USE_STMT (stmt, imm_iter, def)
if (is_gimple_debug (stmt))
  {
gimple_debug_bind_reset_value (stmt);
update_stmt (stmt);
  }

Is there another way to iterate over all the uses of an SSA_NAME
that might be used in a debug stmt?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42914

[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to poor register allocation

[steven at gcc dot gnu dot org]

--- Comment #13 from steven at gcc dot gnu dot org  2010-02-10 17:23 ---
As comment #12 shows, CSE can't do much about this -- there is no common
subexpression before register allocation.

Vlad, this is another one that you probably should have a look at, please.

I will have a look at the difference between the pre-regalloc RTL in 118474 and
118475. Perhaps there is something that can be recovered. But fundamentally
this is something the register allocator should be able to handle.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
   |dot org |org
 Status|REOPENED|ASSIGNED
   Last reconfirmed|2010-02-10 16:27:56 |2010-02-10 17:23:41
   date||
Summary|[4.3/4.4/4.5 regression]|[4.3/4.4/4.5 regression]
   |Code size increase on ARM   |Code size increase on ARM
   |due to inferior CSE |due to poor register
   ||allocation


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871

[Bug middle-end/42973] [4.4/4.5 regression] IRA apparently systematically making reload too busy on 2 address instructions with 3 operands

[vmakarov at redhat dot com]

--- Comment #11 from vmakarov at redhat dot com  2010-02-10 17:15 ---

(In reply to comment #8)
> 
> Thanks, we should see if this solves the AMMP problem in a day or two.
> Are you going to look at the related PR42961?  Without the regmove hunk
> it does not happen at AMMP but it likely happens elsewhere.  I did some
> work on this years back on old RA so I can play with it too.
> (Simple fix would be to add ? penalizers to integer variant of FP moves,
> but I would like to see some solution where RA actually can use integers
> for mem->mem copies)

  I am working on IRA without usage of cover classes.  For example, IRA could
assign integer or floating point register for mem->mem copies whatever is
possible and whatever is more profitable.  This code is big and not ready yet. 
There are a lot of performance issues (besides IRA speed issues which is a
consequence of dealing with more classes).  I am trying to solve the issues. 
But if the code is ok, it probably will solve the problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42973

[Bug fortran/43022] New: gfc_typenode_for_spec: Conditional jump depends on uninitialised value (intrinsic_product_1.f90)

[burnus at gcc dot gnu dot org]

When compiling gfortran.dg/intrinsic_product_1.f90 under valgrind, one sees the
following valgrind notification; the line referred to is:

gfc_typenode_for_spec (gfc_typespec * spec)
  switch (spec->type)
case BT_INTEGER:
  if (spec->f90_type == BT_VOID)  // <<< Line 1001

 Conditional jump or move depends on uninitialised value(s)
at 0x5854F4: gfc_typenode_for_spec (trans-types.c:1001)
by 0x5654CB: gfc_conv_intrinsic_conversion (trans-intrinsic.c:250)
by 0x56D075: gfc_conv_intrinsic_function (trans-intrinsic.c:5178)
by 0x562C42: gfc_conv_function_expr (trans-expr.c:3887)
by 0x55D9EF: gfc_conv_expr_reference (trans-expr.c:4646)
by 0x56111C: gfc_conv_procedure_call (trans-expr.c:2971)
by 0x564653: gfc_conv_intrinsic_funcall (trans-intrinsic.c:1703)
by 0x56CB2C: gfc_conv_intrinsic_function (trans-intrinsic.c:5042)
by 0x562C42: gfc_conv_function_expr (trans-expr.c:3887)
by 0x54904D: gfc_add_loop_ss_code (trans-array.c:2088)
by 0x549A82: gfc_conv_loop_setup (trans-array.c:3722)
by 0x55D096: gfc_trans_assignment_1 (trans-expr.c:5330)


-- 
   Summary: gfc_typenode_for_spec: Conditional jump depends on
uninitialised value (intrinsic_product_1.f90)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43022

[Bug tree-optimization/42771] [4.5 Regression][graphite] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2)

[spop at gcc dot gnu dot org]

--- Comment #9 from spop at gcc dot gnu dot org  2010-02-10 17:03 ---
Fixed as described in 
http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00436.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42771

[Bug middle-end/42973] [4.4/4.5 regression] IRA apparently systematically making reload too busy on 2 address instructions with 3 operands

[vmakarov at redhat dot com]

--- Comment #10 from vmakarov at redhat dot com  2010-02-10 17:02 ---
  The big chunk of regmove which did the same what IRA is capable to do was
removed when IRA was merged.

  There are still a lot of important transformations (like dealing with
increments, sign/zero extensions etc) which IRA can not do.

  As I remember I benchmarked IRA with regmove and without it on x86/x86_64
some time ago and I got a clear impression that regmove is still important.

  It would be nice to see what regmove transformations are important, try to
rewrite it or move some its functionality to IRA but unfortunately I have no
time for this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42973

[Bug tree-optimization/43017] [4.5 Regression] VRP miscompiles python with -fwrapv, II

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-02-10 16:59 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43017

[Bug middle-end/43020] [4.3 regression] varargs of pointer types triggers coredump

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2010-02-10 16:55 ---
This code is undefined with the va_end. 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43020

[Bug tree-optimization/43017] [4.5 Regression] VRP miscompiles python with -fwrapv, II

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-02-10 16:52 ---
Subject: Bug 43017

Author: rguenth
Date: Wed Feb 10 16:52:07 2010
New Revision: 15

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=15
Log:
2010-02-10  Richard Guenther  

PR tree-optimization/43017
* tree-vrp.c (vrp_int_const_binop): Trust int_const_binop
for wrapping signed arithmetic.

* gcc.dg/torture/pr43017.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr43017.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43017

[Bug middle-end/43020] [4.3 regression] varargs of pointer types triggers coredump

[mikpe at it dot uu dot se]

--- Comment #4 from mikpe at it dot uu dot se  2010-02-10 16:52 ---
(In reply to comment #0)
> static void argy (int foo, ...) {
>   va_list arg;
>   char **sp;
> 
>   va_start(arg, foo);
>   sp = va_arg(arg,char **);
>   /* WHAM. */
>   *sp = "foo";
> }

You're missing a va_end(arg); here. Without that I'm able to reproduce really
weird behaviour in a modified test case. With the va_end, things work.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43020

[Bug fortran/40823] debug info points to unexpected line

[burnus at gcc dot gnu dot org]

--- Comment #10 from burnus at gcc dot gnu dot org  2010-02-10 16:49 ---
FIXED on the trunk (4.5). Thanks for the draft patch!


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40823

[Bug fortran/40823] debug info points to unexpected line

[burnus at gcc dot gnu dot org]

--- Comment #9 from burnus at gcc dot gnu dot org  2010-02-10 16:48 ---
Subject: Bug 40823

Author: burnus
Date: Wed Feb 10 16:48:24 2010
New Revision: 156665

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156665
Log:
2010-02-10  Joost VandeVondele 
Tobias Burnus 

PR fortran/40823
* decl.c (gfc_match_subroutine): Explicitly set
* sym->declared_at.

2010-02-10  Tobias Burnus 

PR fortran/40823
* gfortran.dg/private_type_1.f90: Update error location.
* gfortran.dg/invalid_interface_assignment.f90: Ditto.
* gfortran.dg/typebound_operator_2.f03: Ditto.
* gfortran.dg/assignment_2.f90: Ditto.
* gfortran.dg/redefined_intrinsic_assignment.f90: Ditto.
* gfortran.dg/binding_label_tests_9.f03: Ditto.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/assignment_2.f90
trunk/gcc/testsuite/gfortran.dg/binding_label_tests_9.f03
trunk/gcc/testsuite/gfortran.dg/invalid_interface_assignment.f90
trunk/gcc/testsuite/gfortran.dg/private_type_1.f90
trunk/gcc/testsuite/gfortran.dg/redefined_intrinsic_assignment.f90
trunk/gcc/testsuite/gfortran.dg/typebound_operator_2.f03


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40823

[Bug tree-optimization/42771] [4.5 Regression][graphite] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2)

[spop at gcc dot gnu dot org]

--- Comment #8 from spop at gcc dot gnu dot org  2010-02-10 16:47 ---
Subject: Bug 42771

Author: spop
Date: Wed Feb 10 16:47:04 2010
New Revision: 156664

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156664
Log:
Fix PR42771.

2010-02-10  Sebastian Pop  

PR middle-end/42771
* graphite-clast-to-gimple.c (gloog): Call rename_sese_parameters.
* graphite-clast-to-gimple.h (gloog): Update declaration.
* graphite-poly.c (new_scop): Clear POLY_SCOP_P.
* graphite-poly.h (struct poly_bb): Add missing comments.
(struct scop): Add poly_scop_p field.
(POLY_SCOP_P): New.
* graphite-sese-to-poly.c (build_poly_scop): Set POLY_SCOP_P.
* graphite.c (graphite_transform_loops): Build the polyhedral
representation for each scop before code generation.
* sese.c (rename_variables_in_operand): Removed.
(rename_variables_in_expr): Return the renamed expression.
(rename_sese_parameters): New.
* sese.h (rename_sese_parameters): Declared.

* gcc.dg/graphite/pr42771.c: New.

Added:
branches/graphite/gcc/testsuite/gcc.dg/graphite/pr42771.c
Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/graphite-clast-to-gimple.c
branches/graphite/gcc/graphite-clast-to-gimple.h
branches/graphite/gcc/graphite-poly.c
branches/graphite/gcc/graphite-poly.h
branches/graphite/gcc/graphite-sese-to-poly.c
branches/graphite/gcc/graphite.c
branches/graphite/gcc/sese.c
branches/graphite/gcc/sese.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42771

[Bug driver/43021] [4.5 Regression] Driver no longer handles fancy names

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-02-10 16:45 ---
I have a fix.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-10 16:45:29
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43021

[Bug fortran/43015] ICE with BIND(C) and -fbounds-check in mingw-w64 cross-compiler

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2010-02-10 16:45 ---
FIXED on the trunk (4.5). Thanks again for the report!


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43015

[Bug fortran/43015] ICE with BIND(C) and -fbounds-check in mingw-w64 cross-compiler

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-02-10 16:43 ---
Subject: Bug 43015

Author: burnus
Date: Wed Feb 10 16:43:22 2010
New Revision: 156663

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156663
Log:
2010-02-10  Tobias Burnus  

PR fortran/43015
* trans-decl.c (gfc_generate_function_code): Only check
actual-vs.-dummy character bounds if not bind(C).

2010-02-10  Tobias Burnus  

PR fortran/43015
* gfortran.dg/bind_c_usage_20.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/bind_c_usage_20.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43015

[Bug middle-end/43020] [4.3 regression] varargs of pointer types triggers coredump

[mikpe at it dot uu dot se]

--- Comment #3 from mikpe at it dot uu dot se  2010-02-10 16:28 ---
(In reply to comment #2)
> Checked with GCC 4.3: doesn't happen there. (Maybe I'm not supposed to change
> the summary myself: if so, my apologies.)

Now you've made it look like a bug in 4.3 but not in 4.4 or 4.5. You should've
written "4.4/4.5 regression" or something like that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43020

[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to inferior CSE

[steven at gcc dot gnu dot org]

--- Comment #12 from steven at gcc dot gnu dot org  2010-02-10 16:27 ---
Trying with r156650, I get this before regalloc (in the .184r.asmcons dump):

1 NOTE_INSN_DELETED
4 NOTE_INSN_BASIC_BLOCK
2 r135:SI=r0:SI
  REG_DEAD: r0:SI
3 NOTE_INSN_FUNCTION_BEG
6 r136:SI=sfp:SI-0xc
7 r137:SI=[r135:SI]
8 [r136:SI+0x4]=r137:SI
  REG_DEAD: r137:SI
   10 r139:SI=[r135:SI+0x4]
  REG_DEAD: r135:SI
   11 r0:SI=r136:SI
  REG_DEAD: r136:SI
  REG_EQUAL: sfp:SI-0xc
   12 r1:SI=r139:SI
  REG_DEAD: r139:SI
   13 call [`func'] argc:0x0
  REG_DEAD: r1:SI
  REG_DEAD: r0:SI


To get the same code as gcc 4.2.1 of comment #0, r0 should be assigned to r136.
There is no reason why that should not happen, because there are no conflicts:

+++Allocating 32 bytes for conflict table (uncompressed size 32)
;; a0(r139,l0) conflicts: a1(r136,l0)
;; total conflict hard regs: 0
;; conflict hard regs: 0
;; a1(r136,l0) conflicts: a0(r139,l0) a2(r135,l0) a3(r137,l0)
;; total conflict hard regs:
;; conflict hard regs:
;; a2(r135,l0) conflicts: a1(r136,l0) a3(r137,l0)
;; total conflict hard regs:
;; conflict hard regs:
;; a3(r137,l0) conflicts: a1(r136,l0) a2(r135,l0)
;; total conflict hard regs:
;; conflict hard regs:

There are also no indications (not that I can find anyway) in the IRA dumps,
that suggests that IRA notices a tie between r0-r136 and r1-r139 may be
beneficial (thanks to insns 11 and 12 in the pre-regalloc dump).

IRA has done the following:
  Popping a0(r139,l0)  -- assign reg 1
  Popping a1(r136,l0)  -- assign reg 3
  Popping a2(r135,l0)  -- assign reg 0
  Popping a3(r137,l0)  -- assign reg 2

With this assignment, insn 2 and insn 12 become no-op moves. It looks like r139
ends up in r1 by pure luck, or there would have been another extra move.

After regalloc (in the .187r.ira dump) it looks like this:

1 NOTE_INSN_DELETED
4 NOTE_INSN_BASIC_BLOCK
3 NOTE_INSN_FUNCTION_BEG
6 r3:SI=sp:SI+0x4
  REG_EQUIV: sp:SI+0x4
7 r2:SI=[r0:SI]
  REG_EQUIV: [r0:SI]
8 [r3:SI+0x4]=r2:SI
   10 r1:SI=[r0:SI+0x4]
   11 r0:SI=r3:SI
  REG_EQUAL: sfp:SI-0xc
   13 call [`func'] argc:0x0
   16 NOTE_INSN_DELETED


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet|x86_64-unknown-linux-gnu|
   GCC host triplet|x86_64-unknown-linux-gnu|
  Known to fail||4.4.0 4.5.0
  Known to work|4.5.0   |4.2.1
   Last reconfirmed|2009-05-20 14:17:16 |2010-02-10 16:27:56
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871

[Bug driver/43021] [4.5 Regression] Driver no longer handles fancy names

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.4.3
   Priority|P3  |P1
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43021

[Bug driver/43021] New: [4.5 Regression] Driver no longer handles fancy names

[rguenth at gcc dot gnu dot org]

>From the bison testsuite:

> gcc-4.5 -c @@.c
gcc-4.5: : No such file or directory
gcc-4.5: no input files

> gcc-4.5 -c @{.c
gcc-4.5: : No such file or directory
gcc-4.5: no input files

> gcc-4.5 -c @}.c
gcc-4.5: : No such file or directory
gcc-4.5: no input files

> gcc-4.5 -c '~...@#$%^&*()-=_+{}[]|\:;<>, ..c'
gcc-4.5: ~!: No such file or directory
gcc-4.5: no input files

all these work with the 4.4 driver.


-- 
   Summary: [4.5 Regression] Driver no longer handles fancy names
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43021

[Bug middle-end/43020] [4.3 regression] varargs of pointer types triggers coredump

[nix at esperi dot org dot uk]

--- Comment #2 from nix at esperi dot org dot uk  2010-02-10 16:20 ---
Checked with GCC 4.3: doesn't happen there. (Maybe I'm not supposed to change
the summary myself: if so, my apologies.)


-- 

nix at esperi dot org dot uk changed:

   What|Removed |Added

Summary|varargs of pointer types|[4.3 regression] varargs of
   |triggers coredump   |pointer types triggers
   ||coredump


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43020

[Bug middle-end/43020] varargs of pointer types triggers coredump

[nix at esperi dot org dot uk]

--- Comment #1 from nix at esperi dot org dot uk  2010-02-10 16:19 ---
Created an attachment (id=19835)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19835&action=view)
Preprocessed testcase source

(sans #include , not needed for crash, only for closely-related
non-crashing version).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43020

[Bug middle-end/43020] New: varargs of pointer types triggers coredump

[nix at esperi dot org dot uk]

Testcase:

#include 
#include 

static void argy (int foo, ...) {
  va_list arg;
  char **sp;

  va_start(arg, foo);
  sp = va_arg(arg,char **);
  /* WHAM. */
  *sp = "foo";
}

int main (void)
{
  char *foo;

  /* Comment the next line out for instant crash. */
  /* (fprintf) (stderr, "&foo: %p\n", &foo); */
  argy(0,  &foo);
  return 0;
}

It still crashes if the #include of  is removed, so glibc version is
immaterial. If the fprintf() call is uncommented, it no longer crashes. Only
the 64-bit version crashes.

The tree dumps show no significant differences, so this is presumably an
RTL-or-later problem. Only the caller differs: GDB output confirms that what is
put on the stack is wrong in the crashing case. I have no idea if the problem
is middle-end or target, I'm afraid.

(I find myself wondering how *scanf() is still working in the presence of this
bug. Presumably we're saved by the circumstance that *scanf() use is relatively
rare and that its users tend to use the variable again in non-stdargs context
in the same function?)

Originally spotted in libquvi:
.

Preprocessed testcase (of still-crashing version without #include )
follows.


-- 
   Summary: varargs of pointer types triggers coredump
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nix at esperi dot org dot uk
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43020

[Bug fortran/43019] New: [F2008] BLOCK (block_6.f08): Scope of implicitly typed variables

[burnus at gcc dot gnu dot org]

BLOCK is xfailed and contains:


! Check for correct scope of variables that are implicit typed within a BLOCK.
! This is not yet implemented, thus XFAIL'ed the test.

PROGRAM main
  IMPLICIT INTEGER(a-z)

  BLOCK
! a gets implicitly typed, but scope should not be limited to BLOCK.
a = 42
  END BLOCK

  ! Here, we should still access the same a that was set above.
  IF (a /= 42) CALL abort ()
END PROGRAM main


-- 
   Summary: [F2008] BLOCK (block_6.f08): Scope of implicitly typed
variables
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43019

[Bug fortran/43018] New: alloc_comp_scalar_1.f90: Valgrind Invalid read of size 4

[burnus at gcc dot gnu dot org]

This is either a test-suite error or a compiler bug:

Invalid read of size 1
  at 0x4C276E8: memcpy (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
  by 0x400CB0: MAIN__ (alloc_comp_scalar_1.f90:13)
  by 0x400E4D: main (alloc_comp_scalar_1.f90:17)
  Address 0x58d73d7 is 3 bytes after a block of size 4 alloc'd
  at 0x4C261C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
  by 0x4009E5: MAIN__ (alloc_comp_scalar_1.f90:7)
  by 0x400E4D: main (alloc_comp_scalar_1.f90:17)


-- 
   Summary: alloc_comp_scalar_1.f90: Valgrind  Invalid read of size
4
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
 BugsThisDependsOn: 42647


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43018

[Bug fortran/42309] Problem with a pointer array passed to a subroutine

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2010-02-10 15:14 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42309

[Bug debug/43010] [4.4/4.5 Regression] ICE with -femit-struct-debug-baseonly

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-02-10 15:13 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43010

[Bug fortran/42309] Problem with a pointer array passed to a subroutine

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2010-02-10 15:11 ---
Subject: Bug 42309

Author: jakub
Date: Wed Feb 10 15:11:30 2010
New Revision: 156660

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156660
Log:
PR fortran/42309
* trans-expr.c (gfc_conv_subref_array_arg): Avoid accessing
info->dimen after info has been freed.

Modified:
branches/gcc-4_4-branch/gcc/fortran/ChangeLog
branches/gcc-4_4-branch/gcc/fortran/trans-expr.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42309

[Bug fortran/42309] Problem with a pointer array passed to a subroutine

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2010-02-10 15:11 ---
Subject: Bug 42309

Author: jakub
Date: Wed Feb 10 15:10:53 2010
New Revision: 156659

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156659
Log:
PR fortran/42309
* trans-expr.c (gfc_conv_subref_array_arg): Avoid accessing
info->dimen after info has been freed.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42309

[Bug debug/43010] [4.4/4.5 Regression] ICE with -femit-struct-debug-baseonly

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-02-10 15:09 ---
Subject: Bug 43010

Author: jakub
Date: Wed Feb 10 15:09:06 2010
New Revision: 156658

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156658
Log:
PR debug/43010
* dwarf2out.c (retry_incomplete_types): Don't call gen_type_die
if no debug info should be emitted for it.

* g++.dg/debug/pr43010.C: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/debug/pr43010.C
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/dwarf2out.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43010

[Bug debug/43010] [4.4/4.5 Regression] ICE with -femit-struct-debug-baseonly

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-02-10 15:03 ---
Subject: Bug 43010

Author: jakub
Date: Wed Feb 10 15:02:56 2010
New Revision: 156657

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156657
Log:
PR debug/43010
* dwarf2out.c (retry_incomplete_types): Don't call gen_type_die
if no debug info should be emitted for it.

* g++.dg/debug/pr43010.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/debug/pr43010.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43010

[Bug testsuite/42997] [4.4 Regression] Backported tests fail with checking

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2010-02-10 14:57 ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #1)
> > > Which is a remainder that devs should enable checking when testing 
> > > patches for
> > > branches ...
> > > 
> > 
> > I am using the same configuration for both trunk and release branch:
> > 
> > --enable-clocale=gnu --with-system-zlib --enable-shared 
> > --with-demangler-in-ld
> > 
> > Why should checking be enabled only for release branches?
> 
> Because if you backport ice-checking fixes testcases you should verify if
> they really do not ICE on the branch - which requires checking to be enabled.

I see. Your comment is meant to gcc.c-torture/compile/pr42705.c.
I will keep it in mind.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42997

[Bug testsuite/42997] [4.4 Regression] Backported tests fail with checking

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-02-10 14:49 ---
(In reply to comment #6)
> (In reply to comment #1)
> > Which is a remainder that devs should enable checking when testing patches 
> > for
> > branches ...
> > 
> 
> I am using the same configuration for both trunk and release branch:
> 
> --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld
> 
> Why should checking be enabled only for release branches?

Because if you backport ice-checking fixes testcases you should verify if
they really do not ICE on the branch - which requires checking to be enabled.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42997

[Bug testsuite/42997] [4.4 Regression] Backported tests fail with checking

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2010-02-10 14:39 ---
(In reply to comment #1)
> Which is a remainder that devs should enable checking when testing patches for
> branches ...
> 

I am using the same configuration for both trunk and release branch:

--enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld

Why should checking be enabled only for release branches?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42997

[Bug tree-optimization/43017] [4.5 Regression] VRP miscompiles python with -fwrapv, II

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-02-10 14:30 ---
I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
  Known to work||4.4.3
   Last reconfirmed|-00-00 00:00:00 |2010-02-10 14:30:19
   date||
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43017

[Bug tree-optimization/43017] New: [4.5 Regression] VRP miscompiles python with -fwrapv, II

[rguenth at gcc dot gnu dot org]

Another one.

signed char foo(unsigned char c2)
{
  signed char c2_22;

  if (c2 <= 63 || c2 == 127)
goto bb43;
  else
goto bb20;

bb20:
  if (c2 > 252)
goto bb43;
  else
goto bb21;

bb21:
  /*...*/;

bb24:
  c2_22 = (signed char)c2;
  if (c2_22 >= 0)
goto bb25;
  else
goto bb26;

bb25:
  c2 = (unsigned char)(c2_22 - 64);
  goto bb27;

bb26:
  c2 = (unsigned char)(c2_22 - 65);

bb27:
  if (c2 <= 93)
goto bb28;
  else
goto bb29;

bb28:
  c2 = c2 + 33;
  goto bb30;

bb29:
  c2 = (unsigned char)((signed char)c2 - 61);

bb30:
  return c2;

bb43:
  return -1;
}
extern void abort (void);
int main()
{
  signed char res[256] = {
  -1, -1, -1, -1, -1, -1, -1, -1,
  -1, -1, -1, -1, -1, -1, -1, -1,
  -1, -1, -1, -1, -1, -1, -1, -1,
  -1, -1, -1, -1, -1, -1, -1, -1,
  -1, -1, -1, -1, -1, -1, -1, -1,
  -1, -1, -1, -1, -1, -1, -1, -1,
  -1, -1, -1, -1, -1, -1, -1, -1,
  -1, -1, -1, -1, -1, -1, -1, -1,
  33, 34, 35, 36, 37, 38, 39, 40,
  41, 42, 43, 44, 45, 46, 47, 48,
  49, 50, 51, 52, 53, 54, 55, 56,
  57, 58, 59, 60, 61, 62, 63, 64,
  65, 66, 67, 68, 69, 70, 71, 72,
  73, 74, 75, 76, 77, 78, 79, 80,
  81, 82, 83, 84, 85, 86, 87, 88,
  89, 90, 91, 92, 93, 94, 95, -1,
  96, 97, 98, 99, 100, 101, 102, 103,
  104, 105, 106, 107, 108, 109, 110, 111,
  112, 113, 114, 115, 116, 117, 118, 119,
  120, 121, 122, 123, 124, 125, 126, 33,
  34, 35, 36, 37, 38, 39, 40, 41,
  42, 43, 44, 45, 46, 47, 48, 49,
  50, 51, 52, 53, 54, 55, 56, 57,
  58, 59, 60, 61, 62, 63, 64, 65,
  66, 67, 68, 69, 70, 71, 72, 73,
  74, 75, 76, 77, 78, 79, 80, 81,
  82, 83, 84, 85, 86, 87, 88, 89,
  90, 91, 92, 93, 94, 95, 96, 97,
  98, 99, 100, 101, 102, 103, 104, 105,
  106, 107, 108, 109, 110, 111, 112, 113,
  114, 115, 116, 117, 118, 119, 120, 121,
  122, 123, 124, 125, 126, -1, -1, -1
  };
  unsigned int c;
  for (c = 0; c <= 255; ++c)
{
  if (foo (c) != res[c])
abort ();
}
  return 0;
}


-- 
   Summary: [4.5 Regression] VRP miscompiles python with -fwrapv, II
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43017

[Bug testsuite/42997] [4.4 Regression] Backported tests fail with checking

[sezeroz at gmail dot com]

--- Comment #5 from sezeroz at gmail dot com  2010-02-10 14:29 ---
(In reply to comment #4)
[...]
> > > > FAIL: gcc.c-torture/compile/pr42705.c  -Os  (test for excess errors)
> > > 
> > > It passed for me on Linux/x86.
> > > 
> > 
> > Fails for me both on i686- and x86_64-linux.
> > 
> 
> What are the error messages?
> 

Doesn't fail since rev. 156619:
http://gcc.gnu.org/viewcvs?view=revision&sortby=date&revision=156619


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42997

[Bug testsuite/42997] [4.4 Regression] Backported tests fail with checking

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2010-02-10 14:09 ---
(In reply to comment #3)
> (In reply to comment #2)
> > > FAIL: gcc.c-torture/compile/pr42705.c  -O1  (internal compiler error)
> > > FAIL: gcc.c-torture/compile/pr42705.c  -O1  (test for excess errors)
> > > FAIL: gcc.c-torture/compile/pr42705.c  -O2  (internal compiler error)
> > > FAIL: gcc.c-torture/compile/pr42705.c  -O2  (test for excess errors)
> > > FAIL: gcc.c-torture/compile/pr42705.c  -O3 -fomit-frame-pointer  (internal
> > > compi
> > > ler error)
> > > FAIL: gcc.c-torture/compile/pr42705.c  -O3 -fomit-frame-pointer  (test for
> > > exces
> > > s errors)
> > > FAIL: gcc.c-torture/compile/pr42705.c  -O3 -g  (internal compiler error)
> > > FAIL: gcc.c-torture/compile/pr42705.c  -O3 -g  (test for excess errors)
> > > FAIL: gcc.c-torture/compile/pr42705.c  -Os  (internal compiler error)
> > > FAIL: gcc.c-torture/compile/pr42705.c  -Os  (test for excess errors)
> > 
> > It passed for me on Linux/x86.
> > 
> 
> Fails for me both on i686- and x86_64-linux.
> 

What are the error messages?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42997

[Bug fortran/42309] Problem with a pointer array passed to a subroutine

[burnus at gcc dot gnu dot org]

--- Comment #10 from burnus at gcc dot gnu dot org  2010-02-10 13:54 ---
Patch for 4.4 and the 4.5-trunk by Jakub:
  http://gcc.gnu.org/ml/fortran/2010-02/msg00063.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42309

[Bug c++/43016] Inappropriate multiple definition error for lambda function when inside inline functions

[plaice at cse dot unsw dot edu dot au]

--- Comment #2 from plaice at cse dot unsw dot edu dot au  2010-02-10 13:32 
---
Created an attachment (id=19834)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19834&action=view)
Second file for Bug 43016


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43016