[Bug fortran/42999] [4.5 Regression] bogus error: Parameter 'i' at (1) has not been declared or is a variable, which does not reduce to a constant expression

[jv244 at cam dot ac dot uk]

--- Comment #6 from jv244 at cam dot ac dot uk  2010-02-10 08:52 ---
closing as fixed after the commit by Jerry DeLisle


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/36932] unneeded temporary (2x)

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2010-02-10 08:57 ---
the patch for 41113 fixes one of the two warnings


-- 


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

[Bug fortran/36933] unneeded temporary with derived type containing an array as argument

[jv244 at cam dot ac dot uk]

--- Comment #5 from jv244 at cam dot ac dot uk  2010-02-10 09:03 ---
(In reply to comment #4)
> I believe this is has an origin that could be related to PR41113
this is not fixed by the patch in PR41113, the testcase in comment #3 might
actually be tricky. 


-- 


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

[Bug fortran/41117] spurious _gfortran_internal_pack (II)

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2010-02-10 09:05 ---
this is also fixed for a compiler with the patch for PR41113 applied


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

  BugsThisDependsOn||41113


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

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

[jv244 at cam dot ac dot uk]

--- Comment #7 from jv244 at cam dot ac dot uk  2010-02-10 09:10 ---
still happens with current trunk. I believe the patch below is still fine.


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

   Keywords||patch


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

[Bug middle-end/43013] [4.4/4.5 Regression] "warning: 'saved_stack.1' is used uninitialized in this function" with -fstack-check

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-02-10 09:11 ---
This is actually a regression from 4.3, caused most probably by
http://gcc.gnu.org/viewcvs?view=revision&revision=139159
For VLAs GCC errors out if a goto jumps into a scope with a VLA, for
-fstack-check it obviously can't error out, but probably needs to avoid
emitting the stack checks in that case, or conditionalize them.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-10 09:11:40
   date||
Summary|[4.5 Regression] "warning:  |[4.4/4.5 Regression]
   |'saved_stack.1' is used |"warning: 'saved_stack.1' is
   |uninitialized in this   |used uninitialized in this
   |function" with -fstack-check|function" with -fstack-check
   Target Milestone|4.5.0   |4.4.4


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

[Bug fortran/41113] spurious _gfortran_internal_pack

[burnus at gcc dot gnu dot org]

--- Comment #16 from burnus at gcc dot gnu dot org  2010-02-10 09:17 ---
(In reply to comment #10)
> > For reference, this was Paul's message to the list:
> > http://gcc.gnu.org/ml/fortran/2009-12/msg00164.html
> This was followed by http://gcc.gnu.org/ml/fortran/2009-12/msg00166.html

It seems as if this only occurs on a branch (fortran-dev, see comment 13) thus
I would suggest to go ahead and fix it for the trunk. And worry about the
branch later.

> I would like to commit this patch, so I will try to fix it

Could you also look into:
  pointer%array_component
where the ultimate component ("array_component") is a whole array reference and
_not_ a pointer? In that case one should also have a contiguous array. Cf. PR
36933 and PR 36932.

Note: Your patch seems to also fix PR 41117.


-- 


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

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

[hubicka at ucw dot cz]

--- Comment #8 from hubicka at ucw dot cz  2010-02-10 09:22 ---
Subject: Re:  [4.4/4.5 regression] IRA apparently
systematically making reload too busy on 2 address instructions
with 3 operands

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)

Honza


-- 


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

[Bug middle-end/42961] [4.5 regression] IRA register preferencing bug

[hubicka at ucw dot cz]

--- Comment #2 from hubicka at ucw dot cz  2010-02-10 09:26 ---
Subject: Re:   New: [4.5 regression] IRA register
preferencing bug

Hi,
note that it is related to way we compute cost through alternatives.
I had very old patch for this
http://www.x86-64.org/pipermail/patches/2001-February/001071.html
that would eventually help to remove the '#' constraints on all FP operations
that are there
to avoid RA from mixing integer and FP classes. Perhaps IRA can now do
something similar
and actually propagate the info?

Honza


-- 


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

[Bug fortran/36933] unneeded temporary with derived type containing an array as argument

[jv244 at cam dot ac dot uk]

--- Comment #6 from jv244 at cam dot ac dot uk  2010-02-10 09:29 ---
(In reply to comment #5)
> the testcase in comment #3 might
> actually be tricky. 

Let me clarify:

TYPE T1
 INTEGER :: a(3)
END TYPE T1
TYPE(T1), POINTER :: x,y
x=>y
x%a=y%a
END

in this case x%a and y%a are the same array in memory, which might make this a
somewhat special case? Obviously, they are known to be contiguous 


-- 


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

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

[burnus at gcc dot gnu dot org]

--- Comment #8 from burnus at gcc dot gnu dot org  2010-02-10 09:33 ---
(In reply to comment #6)
> this is bold guess at a patch, which does fix the lineno info for this
> testcase, but no idea if this is even remotely correct. Based on the
> observation that gfc_match_function_decl sets declared_at, but
> gfc_match_subroutine does not.

In principle, it should not be needed to set the declared_at as
gfc_match_subroutine calls gfc_get_symbol, which calls gfc_get_sym_tree which
calls gfc_new_symbol which contains:
  p->declared_at = gfc_current_locus;

At that point, gfc_current_locus should be at the end of the subroutine name.
-- Eureka! I know understand why this is not happening: As the symbol is
already defined (due to the PUBLIC statement), declared_at is not re-set. Thus,
it indeed makes sense to add a sym->declared_at - either as in the patch does
at
  >se<
by simply using "sym->declared_at = gfc_current_locus;".

> +  old_loc = gfc_current_locus;
[...]
> +  sym->declared_at=old_loc;
>return MATCH_YES;


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-10 09:33:30
   date||


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

[Bug c++/40058] C++ FE generates struct assignments with mismatched sizes

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-02-10 09:42 ---
We still have these constructs and expand still properly deals with them
(it uses the size of the LHS).

I'm not sure what's the best thing to do about this bug.  Eventually better
documenting what sizes in an assignment are really relevant.

The FE now indeed emits memcpy whenever there is not a DECL or FIELD_DECL
on the LHS that specifies sizes, like for

void bar (Base *p, Base *q)
{
  *p = *q;
}

;; Function void bar(Base*, Base*) (null)
;; enabled by -tree-original

<, (const struct
Base &) (const struct Base *) NON_LVALUE_EXPR , 5) >>>
>>;


So the langhook was no longer necessary.


-- 


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

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

[steven at gcc dot gnu dot org]

--- 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?


-- 


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

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

[dennis dot wassel at googlemail dot com]

Using the mingw-w64 cross-compiler package
"mingw-w64-bin_i686-linux_20100130.tar.bz2" (which works like a treat
otherwise) I get this ICE

foo.f90: In function ‘foo’:
foo.f90:1:0: internal compiler error: in add_argument_checking, at
fortran/trans-decl.c:3961

when compiling this snippet (which I believe to be valid)

SUBROUTINE foo(msg) BIND(C, name = "Foo")
  USE, INTRINSIC :: iso_c_binding
  IMPLICIT NONE
  CHARACTER (KIND=C_CHAR), INTENT (out) :: msg(*) 
END SUBROUTINE foo


$ x86_64-w64-mingw32-gfortran -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gfortran
COLLECT_LTO_WRAPPER=/localdata/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../../../build/gcc/gcc/configure --target=x86_64-w64-mingw32
--prefix=/extra/mingw64/m64bs/linux-x86-x86_64/build/build/root
--with-sysroot=/extra/mingw64/m64bs/linux-x86-x86_64/build/build/root
--with-gmp=/extra/mingw64/m64bs/linux-x86-x86_64/build/build/gmp/install
--with-mpfr=/extra/mingw64/m64bs/linux-x86-x86_64/build/build/mpfr/install
--with-mpc=/extra/mingw64/m64bs/linux-x86-x86_64/build/build/mpc/install
--enable-languages=all,obj-c++ --enable-fully-dynamic-string --disable-multilib
Thread model: win32
gcc version 4.5.0 20100130 (experimental) (GCC)


-- 
   Summary: ICE with BIND(C) and -fbounds-check in mingw-w64 cross-
compiler
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dennis dot wassel at googlemail dot com
  GCC host triplet: i686-pc-linux
GCC target triplet: x86_64-w64-mingw32


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

[Bug c/43009] segmentation fault with -O3 when accessing byte-aligned array as dwords

[ebotcazou at gcc dot gnu dot org]

--- Comment #8 from ebotcazou at gcc dot gnu dot org  2010-02-10 10:02 
---
> The non-working code is vectorized, and vectorized code can have strict
> alignment requirements.

Yes, the alignment requirements are surreptitiously changed by -ftree-vectorize
on x86 and x86-64.  This ought to be documented in the manual.


-- 


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

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

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2010-02-10 10:16 
---
There are many details to this, but note that if you stay away from c_str(),
and const char*, thus you consistently use C++ style strings, nothing
unexpected happens, *ever*.


-- 


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

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

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2010-02-10 10:18 
---
To be sure: is is fully clear to you that a map stores a pair
of *pointer to const char* and an int? It does *not* store a full string, it
stores an *address* (and an int)!


-- 


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

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

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-02-10 10:35 ---
Confirm - and thanks for the report!

For non-BIND(C), Fortran passes a hidden argument with the string length thus
one can add a bounds check check:
  if (expected_length > passed_length)
print_bound_error
Expected size is here "1" but for BIND(C) there is no hidden argument with the
string length; thus, the compiler crashes.

The following patch should fix it.

Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 156647)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -4367,7 +4370,7 @@ gfc_generate_function_code (gfc_namespac
   /* If bounds-checking is enabled, generate code to check passed in actual
  arguments against the expected dummy argument attributes (e.g. string
  lengths).  */
-  if (gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
+  if ((gfc_option.rtcheck & GFC_RTCHECK_BOUNDS) && !sym->attr.is_bind_c)
 add_argument_checking (&body, sym);

   tmp = gfc_trans_code (ns->code);


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   GCC host triplet|i686-pc-linux   |
 GCC target triplet|x86_64-w64-mingw32  |
   Keywords||ice-on-valid-code
  Known to fail||4.5.0
  Known to work||4.4.3
   Last reconfirmed|-00-00 00:00:00 |2010-02-10 10:35:14
   date||


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

[Bug tree-optimization/31849] [4.3/4.4/4.5 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)

[steven at gcc dot gnu dot org]

--- Comment #51 from steven at gcc dot gnu dot org  2010-02-10 10:42 ---
Could the OP be so kind to see if this is still a problem? And, if this is
still a problem with an unpatched compiler: whether the problem goes away if
arm_arm_address_cost() returns 1 unconditionally (so that this bug can be
re-qualified as a target problem rather than a tree-optimization issue)?


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING


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

[Bug middle-end/40375] redundant register move with scheduler before RA turned off

[steven at gcc dot gnu dot org]

--- Comment #9 from steven at gcc dot gnu dot org  2010-02-10 10:55 ---
Reconfirmed with r156595 and r156650 (with and without -fschedule-insns, and
-fsched-pressure makes no difference either).

Vlad, you added some register pressure awareness to the scheduler. Do you think
there is a way to teach the scheduler to unconditionally move insns, or at
least simple moves, around if it reduces register pressure? (See comment #5 in
this PR.)


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu dot
   ||org
   Last reconfirmed|2009-06-09 08:34:25 |2010-02-10 10:55:07
   date||


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

[Bug rtl-optimization/42502] [4.4/4.5 Regression] Bad register allocation in a very simple code

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2010-02-10 11:01 ---
This is a regression, so let's mark it as such.

Shin-wei, is it possible for you check what GCC 4.3 does. Bonus if you can
check a 4.4 snapshot from just before and just after IRA was merged.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|sliao at google dot com |
  Known to fail||4.4.0 4.5.0
  Known to work||4.2.1
   Last reconfirmed|2010-01-12 09:36:39 |2010-02-10 11:01:00
   date||
Summary|Bad register allocation in a|[4.4/4.5 Regression] Bad
   |very simple code|register allocation in a
   ||very simple code


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

[Bug lto/42985] Internal compiler error: in ipcp_iterate_stage with different opt level

[jamborm at gcc dot gnu dot org]

--- Comment #5 from jamborm at gcc dot gnu dot org  2010-02-10 11:23 ---
Subject: Bug 42985

Author: jamborm
Date: Wed Feb 10 11:22:55 2010
New Revision: 156651

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156651
Log:
2010-02-10  Martin Jambor  

PR lto/42985
* ipa-prop.c (ipa_update_after_lto_read): Count parameters and
check for variable argument counts independently.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c


-- 


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

[Bug lto/42985] Internal compiler error: in ipcp_iterate_stage with different opt level

[jamborm at gcc dot gnu dot org]

--- Comment #6 from jamborm at gcc dot gnu dot org  2010-02-10 11:23 ---
Fixed.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/42502] [4.4/4.5 Regression] Bad register allocation in a very simple code

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.4


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

[Bug c/43007] [4.5 Regression] No longer folds (unsigned int) ((long long unsigned int) spi_bias / 1008)

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-02-10 11:54 ---
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=43007

[Bug c/43007] [4.5 Regression] No longer folds (unsigned int) ((long long unsigned int) spi_bias / 1008)

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-02-10 11:54 ---
Subject: Bug 43007

Author: rguenth
Date: Wed Feb 10 11:54:14 2010
New Revision: 156653

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

PR c/43007
* tree.c (get_unwidened): Handle constants.
* convert.c (convert_to_integer): Handle TRUNC_DIV_EXPR.

* gcc.c-torture/execute/20100209-1.c: New testcase.
* gcc.dg/fold-div-3.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20100209-1.c
trunk/gcc/testsuite/gcc.dg/fold-div-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/convert.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c


-- 


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

[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.

[chrbr at gcc dot gnu dot org]

--- Comment #36 from chrbr at gcc dot gnu dot org  2010-02-10 12:02 ---
(In reply to comment #33)
> Your fix of the middle end looks plausible but I think the target
> shouldn't generate a CP at the eh landing pad anyway.  I'll commit
> the hunk below anyway after your patch for pic problem is installed.
> 

done, you can commit your w/a.

> @@ -4654,6 +4654,13 @@ find_barrier (int num_mova, rtx mova, rt
>if (last_got)
> from = PREV_INSN (last_got);
> 
> +  /* Don't insert the constant pool table at the position which
> +may be the landing pad.  */
> +  if (flag_exceptions
> + && CALL_P (from)
> + && find_reg_note (from, REG_EH_REGION, NULL_RTX))
> +   from = PREV_INSN (from);
> +
>/* Walk back to be just before any jump or label.
>  Putting it before a label reduces the number of times the branch
>  around the constant pool table will be hit.  Putting it before
> 


-- 

chrbr at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

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

[jingyu at google dot com]

--- Comment #9 from jingyu at google dot com  2010-02-10 12:18 ---
I still get the 10-instruction code with trunk GCC I checked out today.

$arm-eabi-gcc -mthumb -mthumb-interwork -fpic -Os code.c -S
test:
push{lr}
sub sp, sp, #20
ldr r2, [r0]
add r3, sp, #4
ldr r1, [r0, #4]
str r2, [r3, #4]
mov r0, r3
bl  func
add sp, sp, #20
@ sp needed for prologue
pop {r0}
bx  r0
.size   test, .-test
.ident  "GCC: (GNU) 4.5.0 20100210 (experimental)"

The toolchain was built with newlib-1.17.0, mpc-0.8.1, mpfr-2.4.1, gmp-4.2.4,
binutils-2.19.
Target: arm-eabi
Configured with:
/usr/local/home/projects/newlib_armtoolchain/gcc-trunk-read/configure
--prefix=/usr/local/home/projects/toolchain_build/newlib_build_trunk/install
--target=arm-eabi --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--with-gmp=/usr/local/home/projects/toolchain_build/newlib_build_trunk/install
--with-mpfr=/usr/local/home/projects/toolchain_build/newlib_build_trunk/install
--with-mpc=/usr/local/home/projects/toolchain_build/newlib_build_trunk/install
--enable-multilib --with-newlib --with-gnu-as --with-gnu-ld
--enable-languages=c,c++
Thread model: single
gcc version 4.5.0 20100210 (experimental) (GCC) 


Steven, could you please share how you build the toolchain which generates the
9-instruction code?

Thanks!


-- 


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

[Bug middle-end/42722] move_by_pieces() incorrectly pushes structures to stack

[shcherbakov at daad-alumni dot de]

--- Comment #11 from shcherbakov at daad-alumni dot de  2010-02-10 12:44 
---
Ok, m32c uses "memcpy" for all block moves (4 ints is a DImode, not BLKmode).
Additionally, it supports pre-decrement addressing mode, that enables a
mutually exclusive case to the one showing the bug.
To reproduce the bug on m32c, change the following:
1. in m32c.h replace "#define HAVE_PRE_DECREMENT 1" with 0
2. Comment out "(define_expand "movmemhi"" in blkmov.md
Then, compiling the example with structure containing 5 integers produces this:
.file   "0.c"
.text
.global _func1
.type   _func1, @function
_func1:
enter   #0
push.w  7[fb]
push.w  5[fb]
mova9[fb],a0
push.w  2[a0]
push.w  [a0]
push.w  4[a0]
jsr.a   _func2
add.w   #10,sp
exitd
.size   _func1, .-_func1
.ident  "GCC: (GNU) 4.4.3"

Obviously, the push order (fp+7,fp+5,fp+11,fp+9,...) is incorrect.

Note that removing hardcoded "memcpy" call and commenting out pre-increment
support was needed ONLY to reproduce the bug normally happening on MSP430 using
a supported M32C platform.


-- 


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

[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 #10 from steven at gcc dot gnu dot org  2010-02-10 13:00 ---
My compiler is configured for arm-elf, I guess that's the difference...


-- 


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 inferior CSE

[steven at gcc dot gnu dot org]

--- Comment #11 from steven at gcc dot gnu dot org  2010-02-10 13:04 ---
Closed for wrong ABI.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

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

[plaice at cse dot unsw dot edu dot au]

When an inline function f() includes a lambda function and f() is called in
more than one compilation site, a multiple definition error for the lambda
function is generated at link time.  This does not correspond to the standard,
section 5.1.1.5, which states that "the closure type for a lambda expression
has a public inline function call operator".


-- 
   Summary: Inappropriate multiple definition error for lambda
function when inside inline functions
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: plaice at cse dot unsw dot edu dot au
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

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

[plaice at cse dot unsw dot edu dot au]

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


-- 


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

[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

[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 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 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 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 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 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 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 #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 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 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 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 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 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 #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 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/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 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 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] [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 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 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 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 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 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 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 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 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 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 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 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 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

[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 #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/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/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 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 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 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/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 #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 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 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 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/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 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 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/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 #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 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 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 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 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 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 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 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 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/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 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 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 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 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 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

[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 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 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