[Bug c++/43126] "at this point in file" warnings are upside down

2010-06-01 Thread pzhao at gcc dot gnu dot org


--- Comment #9 from pzhao at gcc dot gnu dot org  2010-06-02 06:53 ---
*** Bug 38468 has been marked as a duplicate of this bug. ***


-- 

pzhao at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ian at airs dot com


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



[Bug c++/38468] Bad order of error messages for function call with wrong number of arguments

2010-06-01 Thread pzhao at gcc dot gnu dot org


--- Comment #2 from pzhao at gcc dot gnu dot org  2010-06-02 06:53 ---


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


-- 

pzhao at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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



[Bug fortran/44353] rejects legal fortran

2010-06-01 Thread pault at gcc dot gnu dot org


--- Comment #2 from pault at gcc dot gnu dot org  2010-06-02 06:44 ---
The fix regtests fine.  I will take the PR and apply the fix on friday, when I
return from a trip.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Keywords||rejects-valid
   Last reconfirmed|2010-06-01 04:51:22 |2010-06-02 06:44:55
   date||


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



[Bug debug/43119] debug info vs. scheduling

2010-06-01 Thread aoliva at gcc dot gnu dot org


--- Comment #2 from aoliva at gcc dot gnu dot org  2010-06-02 06:43 ---
My mid-term vision to address this sort of problem does not involve adding more
debug bind insns (I don't quite see how to get them right), but rather emit a
new kind of debug stmt/insn so as to emit is_stmt notes in lineno, so we can
set breakpoints at the right spot for line 19, rather than at the moved-ahead
insns, avoiding all the bouncing back-and-forth when stepping in optimized
programs.  I ought to go ahead and implement this one of these days.


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |aoliva at gcc dot gnu dot
   |dot org |org


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



[Bug debug/43222] two DEBUG i => 0 generated after loop copy header

2010-06-01 Thread aoliva at gcc dot gnu dot org


--- Comment #6 from aoliva at gcc dot gnu dot org  2010-06-02 06:28 ---
Andrew, the debug stmts are indeed originally from the loop header's PHI nodes.
Before ch we have:

i_1 = ;
# i => i_1
goto ;

:
i_3 = (i_2);
# i => i_3

:
i_2 = PHI ;
# i => i_2
if () goto ; else goto ;

copy_loop_header turns this into:

i_1 = ;
# i => i_1

:
i_4 = PHI ;
# i => i_4
if () goto ; else goto ;

:
i_3 = (i_2);
# i => i_3

:
i_2 = PHI ;
# i => i_2
if () goto ; else goto ;

and that's correct.  Then cfgcleanup realizes the headers can be merged with
their preds, and that kills the PHI nodes, but there's no reason why this
should kill the debug stmts.

Of course we could arrange for some cleanup passes to detect and remove debug
stmts in case they become redundant, but I don't see that we have a bug here.


-- 


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



[Bug fortran/44360] wrong-code: host-associated procedure wrongly favoured to use-associated one

2010-06-01 Thread burnus at gcc dot gnu dot org


--- Comment #7 from burnus at gcc dot gnu dot org  2010-06-02 06:07 ---
FIXED on the trunk (4.6) and the 4.4 and 4.5 branches.

Thanks for the bug report!


-- 

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=44360



[Bug fortran/44360] wrong-code: host-associated procedure wrongly favoured to use-associated one

2010-06-01 Thread burnus at gcc dot gnu dot org


--- Comment #6 from burnus at gcc dot gnu dot org  2010-06-02 06:06 ---
Subject: Bug 44360

Author: burnus
Date: Wed Jun  2 06:06:27 2010
New Revision: 160140

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

PR fortran/44360
* parse.c (gfc_fixup_sibling_symbols): Do not "fix"
use-associated symbols.

2010-06-02  Tobias Burnus  

PR fortran/44360
* gfortran.dg/use_13.f90: New test case.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/use_13.f90
Modified:
branches/gcc-4_4-branch/gcc/fortran/ChangeLog
branches/gcc-4_4-branch/gcc/fortran/parse.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug fortran/44360] wrong-code: host-associated procedure wrongly favoured to use-associated one

2010-06-01 Thread burnus at gcc dot gnu dot org


--- Comment #5 from burnus at gcc dot gnu dot org  2010-06-02 06:06 ---
Subject: Bug 44360

Author: burnus
Date: Wed Jun  2 06:06:07 2010
New Revision: 160139

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

PR fortran/44360
* parse.c (gfc_fixup_sibling_symbols): Do not "fix"
use-associated symbols.

2010-06-02  Tobias Burnus  

PR fortran/44360
* gfortran.dg/use_13.f90: New test case.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/use_13.f90
Modified:
branches/gcc-4_5-branch/gcc/fortran/ChangeLog
branches/gcc-4_5-branch/gcc/fortran/parse.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug fortran/44360] wrong-code: host-associated procedure wrongly favoured to use-associated one

2010-06-01 Thread burnus at gcc dot gnu dot org


--- Comment #4 from burnus at gcc dot gnu dot org  2010-06-02 05:55 ---
Subject: Bug 44360

Author: burnus
Date: Wed Jun  2 05:55:19 2010
New Revision: 160138

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

PR fortran/44360
* parse.c (gfc_fixup_sibling_symbols): Do not "fix"
use-associated symbols.

2010-06-02  Tobias Burnus  

PR fortran/44360
* gfortran.dg/use_13.f90: New test case.


Added:
trunk/gcc/testsuite/gfortran.dg/use_13.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/parse.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/44358] [C++0x] initializer list can't convert to map

2010-06-01 Thread jason at gcc dot gnu dot org


--- Comment #4 from jason at gcc dot gnu dot org  2010-06-02 05:39 ---
Subject: Bug 44358

Author: jason
Date: Wed Jun  2 05:39:23 2010
New Revision: 160137

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160137
Log:
PR c++/44358
* call.c (build_list_conv): Set list-initialization flags properly.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/initlist36.C
Modified:
branches/gcc-4_5-branch/gcc/cp/ChangeLog
branches/gcc-4_5-branch/gcc/cp/call.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug debug/43478] Missing DW_AT_location for a variable

2010-06-01 Thread aoliva at gcc dot gnu dot org


--- Comment #15 from aoliva at gcc dot gnu dot org  2010-06-02 05:27 ---
The debug info machinery is doing the best it can given the behavior of
reassoc, so I'm stepping away from this bug.  Getting reassoc to generate stmts
at a different place may have improvement of debug info as a side effect, but
I'll leave that to someone more familiar with reassoc.


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|aoliva at gcc dot gnu dot   |unassigned at gcc dot gnu
   |org |dot org


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



[Bug rtl-optimization/44013] VTA produces wrong code

2010-06-01 Thread aoliva at gcc dot gnu dot org


--- Comment #8 from aoliva at gcc dot gnu dot org  2010-06-02 05:19 ---
Created an attachment (id=20804)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20804&action=view)
Patch that fixes the problem

Here's the patch I'm regstrapping now.  It avoids relying on the implied
dependency.


-- 


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



[Bug rtl-optimization/44013] VTA produces wrong code

2010-06-01 Thread aoliva at gcc dot gnu dot org


--- Comment #7 from aoliva at gcc dot gnu dot org  2010-06-02 05:08 ---
Mine


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |aoliva at gcc dot gnu dot
   |dot org |org


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



[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code

2010-06-01 Thread jvdelisle at gcc dot gnu dot org


--- Comment #11 from jvdelisle at gcc dot gnu dot org  2010-06-02 05:02 
---
Subject: Bug 44371

Author: jvdelisle
Date: Wed Jun  2 05:02:07 2010
New Revision: 160135

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160135
Log:
2010-06-01  Jerry DeLisle  

PR fortran/44371
* gfortran.dg/error_stop_2.f08: Minor update.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/error_stop_2.f08


-- 


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



[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code

2010-06-01 Thread sgk at troutmask dot apl dot washington dot edu


--- Comment #10 from sgk at troutmask dot apl dot washington dot edu  
2010-06-02 04:53 ---
Subject: Re:  [4.6 Regression] STOP parsing rejects valid code

On Wed, Jun 02, 2010 at 04:52:03AM -, sgk at troutmask dot apl dot
washington dot edu wrote:
> 
> Neither testcase includes the original problem report.
> In error_stop_2.f08, you have 
> 
>  if (c=='x') stop size(i); if (c=='X') stop
> 
> which contains and initialization expression.  Please 
> the original test without the expression, ie.,

Grr.  s/Please/Please add/

> 
>  if (c=='x') stop ; if (c=='X') stop


-- 


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



[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code

2010-06-01 Thread sgk at troutmask dot apl dot washington dot edu


--- Comment #9 from sgk at troutmask dot apl dot washington dot edu  
2010-06-02 04:52 ---
Subject: Re:  [4.6 Regression] STOP parsing rejects valid code

On Wed, Jun 02, 2010 at 04:46:56AM -, jvdelisle at gcc dot gnu dot org
wrote:
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160134
> Log:
> 2010-06-01  Jerry DeLisle  
> 
> PR fortran/44371
> * gfortran.dg/error_stop_1.f08: New test.
> * gfortran.dg/error_stop_2.f08: New test.
> 
> Added:
> trunk/gcc/testsuite/gfortran.dg/error_stop_1.f08
> trunk/gcc/testsuite/gfortran.dg/error_stop_2.f08

Neither testcase includes the original problem report.
In error_stop_2.f08, you have 

 if (c=='x') stop size(i); if (c=='X') stop

which contains and initialization expression.  Please 
the original test without the expression, ie.,

 if (c=='x') stop ; if (c=='X') stop



-- 


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



[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code

2010-06-01 Thread jvdelisle at gcc dot gnu dot org


--- Comment #8 from jvdelisle at gcc dot gnu dot org  2010-06-02 04:46 
---
Subject: Bug 44371

Author: jvdelisle
Date: Wed Jun  2 04:46:38 2010
New Revision: 160134

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160134
Log:
2010-06-01  Jerry DeLisle  

PR fortran/44371
* gfortran.dg/error_stop_1.f08: New test.
* gfortran.dg/error_stop_2.f08: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/error_stop_1.f08
trunk/gcc/testsuite/gfortran.dg/error_stop_2.f08
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code

2010-06-01 Thread jvdelisle at gcc dot gnu dot org


--- Comment #7 from jvdelisle at gcc dot gnu dot org  2010-06-02 04:43 
---
Subject: Bug 44371

Author: jvdelisle
Date: Wed Jun  2 04:42:41 2010
New Revision: 160133

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160133
Log:
2010-06-01  Jerry DeLisle  

PR fortran/44371
* match.c (gfc_match_stopcode): Move gfc_match_eos call inside 
condition block.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c


-- 


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



[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code

2010-06-01 Thread sgk at troutmask dot apl dot washington dot edu


--- Comment #6 from sgk at troutmask dot apl dot washington dot edu  
2010-06-02 04:36 ---
Subject: Re:  [4.6 Regression] STOP parsing rejects valid code

On Wed, Jun 02, 2010 at 04:17:56AM -, jvdelisle at gcc dot gnu dot org
wrote:
> 
> I plan to commit the following as simple and obvious. Sorry for the breakage.
> 
> Index: match.c
> ===
> --- match.c (revision 160130)
> +++ match.c (working copy)
> @@ -2018,10 +2018,11 @@
> goto cleanup;
>if (m == MATCH_NO)
> goto syntax;
> +
> +  if (gfc_match_eos () != MATCH_YES)
> +   goto syntax;
>  }
> 
> -  if (gfc_match_eos () != MATCH_YES)
> -goto syntax;
> 
>if (gfc_pure (NULL))
>  {
> 

I assume that you will add appropriate testcases as well.


-- 


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



[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code

2010-06-01 Thread jvdelisle at gcc dot gnu dot org


--- Comment #5 from jvdelisle at gcc dot gnu dot org  2010-06-02 04:17 
---
Some additional tests/results:

Because we are using gfc_match_init_expr: leaving the ; out.

pr44371.f90:5.18:

  if (c=='y') stop if (c=='Y') stop
  1
Error: Function 'if' in initialization expression at (1) must be an intrinsic
function

This makes no sense in the context, so I want to change the above error
message.

The following message is given after I fix the eos match issue:

  if (c=='y') stop 123 if (c=='Y') stop
  1
Error: Syntax error in STOP statement at (1)

Simply deleting the match_eos leaves the invalid undetected.

I plan to commit the following as simple and obvious. Sorry for the breakage.

Index: match.c
===
--- match.c (revision 160130)
+++ match.c (working copy)
@@ -2018,10 +2018,11 @@
goto cleanup;
   if (m == MATCH_NO)
goto syntax;
+
+  if (gfc_match_eos () != MATCH_YES)
+   goto syntax;
 }

-  if (gfc_match_eos () != MATCH_YES)
-goto syntax;

   if (gfc_pure (NULL))
 {


-- 


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



[Bug middle-end/44373] [4.6 regression] FAIL: gcc.dg/array-init-1.c

2010-06-01 Thread hjl dot tools at gmail dot com


--- Comment #1 from hjl dot tools at gmail dot com  2010-06-02 04:16 ---
It is caused by revision 160125:

http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00037.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||steven at gcc dot gnu dot
   ||org
Summary|[4.6 regression] FAIL:  |[4.6 regression] FAIL:
   |gcc.dg/array-init-1.c   |gcc.dg/array-init-1.c


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



[Bug c++/44358] [C++0x] initializer list can't convert to map

2010-06-01 Thread jason at gcc dot gnu dot org


--- Comment #3 from jason at gcc dot gnu dot org  2010-06-02 03:55 ---
Subject: Bug 44358

Author: jason
Date: Wed Jun  2 03:55:28 2010
New Revision: 160131

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160131
Log:
PR c++/44358
* call.c (build_list_conv): Set list-initialization flags properly.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist36.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code

2010-06-01 Thread jvdelisle at gcc dot gnu dot org


--- Comment #4 from jvdelisle at gcc dot gnu dot org  2010-06-02 03:52 
---
Mine. The problem is the misplacement of the closing bracket.   I will fix
shortly.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-02 03:52:50
   date||


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



[Bug middle-end/44373] New: [4.6 regression] FAIL: gcc.dg/array-init-1.c

2010-06-01 Thread hjl dot tools at gmail dot com
On Linux/x86, revision 160125 gave

FAIL: gcc.dg/array-init-1.c scan-assembler-not abcdefghi
FAIL: gcc.dg/array-init-1.c scan-assembler-times
7017280452245743464|7523094288207667809|6867666564636261|1684234849|64636261 2

Revision 160122 is OK.


-- 
   Summary: [4.6 regression] FAIL: gcc.dg/array-init-1.c
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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



[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code

2010-06-01 Thread kargl at gcc dot gnu dot org


--- Comment #3 from kargl at gcc dot gnu dot org  2010-06-02 02:03 ---
Here's a dejagnu testcase.

! { dg-do run }
  character(1) c, y
  y = 'y'
  read(y,*) c
  if (c=='y') stop; if (c=='Y') stop
  call abort()
  end

The 'dg-do run' could be changed to 'dg-do compile'


-- 


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



[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code

2010-06-01 Thread sgk at troutmask dot apl dot washington dot edu


--- Comment #2 from sgk at troutmask dot apl dot washington dot edu  
2010-06-02 01:57 ---
Subject: Re:  [4.6 Regression] STOP parsing rejects valid code

On Wed, Jun 02, 2010 at 12:42:11AM -, kargl at gcc dot gnu dot org wrote:
> }
> #if 0
>   if (gfc_match_eos () != MATCH_YES)
> goto syntax;
> #endif
> 
> If the first gfc_match_eos () does not match an end-of-statement,
> gfortran immediate calls gfc_match_eos () again.  With the #if 0
> above the code in comment #1 compiles and executes.  So, why is
> there a 2nd call to gfc_match_eos().
> 

Removing this chunk of code causes no testsuite regressions
on x86_64-*-freebsd.

Is leftover from the STOP/ALL_STOP churn?


-- 


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



[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code

2010-06-01 Thread kargl at gcc dot gnu dot org


--- Comment #1 from kargl at gcc dot gnu dot org  2010-06-02 00:42 ---
The problem is caused by gfc_match_stopcode().


  if (gfc_match_eos () != MATCH_YES)
{
  m = gfc_match_init_expr (&e);
  if (m == MATCH_ERROR)
goto cleanup;
  if (m == MATCH_NO)
goto syntax;
}
#if 0
  if (gfc_match_eos () != MATCH_YES)
goto syntax;
#endif

If the first gfc_match_eos () does not match an end-of-statement,
gfortran immediate calls gfc_match_eos () again.  With the #if 0
above the code in comment #1 compiles and executes.  So, why is
there a 2nd call to gfc_match_eos().


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sgk at troutmask dot apl dot
   ||washington dot edu


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



[Bug tree-optimization/44372] [4.6 Regression] ICE: verify_cgraph_node failed: edge points to wrong declaration with -fipa-cp-clone

2010-06-01 Thread zsojka at seznam dot cz


--- Comment #2 from zsojka at seznam dot cz  2010-06-01 23:59 ---
Probably a dup of PR44295


-- 

zsojka at seznam dot cz changed:

   What|Removed |Added

   Keywords||ice-on-valid-code


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



[Bug tree-optimization/44372] [4.6 Regression] ICE: verify_cgraph_node failed: edge points to wrong declaration with -fipa-cp-clone

2010-06-01 Thread zsojka at seznam dot cz


--- Comment #1 from zsojka at seznam dot cz  2010-06-01 23:57 ---
Created an attachment (id=20803)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20803&action=view)
reduced testcase


-- 


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



[Bug tree-optimization/44372] New: [4.6 Regression] ICE: verify_cgraph_node failed: edge points to wrong declaration with -fipa-cp-clone

2010-06-01 Thread zsojka at seznam dot cz
Command line:
$ g++ -O[123] -fipa-cp -fipa-cp-clone testcase.C

Compiler output:
$ /mnt/svn/gcc-trunk/binary-160112-lto-fortran/bin/g++ -O1 -fipa-cp
-fipa-cp-clone testcase.C
testcase.C: In function 'void f(S3)':  
testcase.C:13:5: error: edge points to wrong declaration:   
 >  
QI  
size 
unit size
align 8 symtab 0 alias set -1 canonical type 0x7fa6d85f0150 method
basetype 
arg-types  
chain >>
pointer_to_this >  
asm_written nothrow static autoinline decl_5 QI file testcase.C line 23 col
3 align 16 context  initial  abstract_origin
arguments   
readonly unsigned type_6 DI 
size
unit size
align 64 symtab 0 alias set -1 canonical type 0x7fa6d85f>   
readonly used unsigned DI file testcase.C line 23 col 12 size
 unit size 
align 64 context 
abstract_origin  
(reg/f:DI 5 di [orig:110 this ] [110]) arg-type 
incoming-rtl (reg:DI 5 di [ this ])>
result
used ignored VOID file testcase.C line 24 col 5 
align 8 context 
abstract_origin >
full-name "S2::S2()"
pending-inline-info 0x7fa6d85f60e0  
(mem:QI (symbol_ref:DI ("_ZN2S2C2Ei.constprop.1") [flags 0x3]
) [0 S1 A8])>  
 Instead of: >  
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x7fa6d85f0150 method
basetype 
arg-types 
chain 
chain >>>
pointer_to_this >
addressable used nothrow public static weak autoinline decl_5 QI
defer-output file testcase.C line 23 col 3 align 16 context  initial  abstract_origin

arguments 
readonly unsigned type_6 DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x7fa6d85f>
readonly used unsigned DI file testcase.C line 23 col 12 size
 unit size 
align 64 context 
abstract_origin  arg-type 
chain 
used SI file testcase.C line 23 col 11
size 
unit size 
align 32 context 
abstract_origin 
arg-type >>
result 
ignored VOID file testcase.C line 24 col 5
align 8 context >
full-name "S2::S2(int)"
pending-inline-info 0x7fa6d85f61c0
struct-function 0x7fa6da9bc870>
void f(S3)/16(-1) @0x7fa6d8612000 (asm: _ZL1f2S3IiE) (inline copy in void
f(S3)/6) (clone of void f(S3)/18) availability:local analyzed 13
time, 11 benefit 10 size, 2 benefit (26 after inlining) 404 bytes stack usage
reachable body local finalized inlinable
  called by: void f(S3)/6 (0.00 per call) (inlined)
  calls: void f(S3)/17 (inlined) (0.00 per call) (nested in 6 loops)
S2::S2()/12 (0.00 per call) (nested in 6 loops)
  References:  var:bool m (read)
  Refering this function:
testcase.C:13:5: internal compiler error: verify_cgraph_node failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r160122 - crash
r160112 - crash
r160052 - crash
r159696 - OK


-- 
   Summary: [4.6 Regression] ICE: verify_cgraph_node failed: edge
points to wrong declaration with -fipa-cp-clone
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  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=44372



[Bug target/44218] Improve powerpc -mrecip support

2010-06-01 Thread meissner at gcc dot gnu dot org


--- Comment #1 from meissner at gcc dot gnu dot org  2010-06-01 23:30 
---
Created an attachment (id=20802)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20802&action=view)
Patch to improve powerpc -mrecip support

This patch updates and expands the -mrecip support on the powerpc.


-- 


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



[Bug c++/44358] [C++0x] initializer list can't convert to map

2010-06-01 Thread 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-06-01 23:01:55
   date||


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



[Bug tree-optimization/44368] ICE: SIGSEGV in remove_insn (emit-rtl.c:3859) with -ftree-vectorize

2010-06-01 Thread zsojka at seznam dot cz


--- Comment #2 from zsojka at seznam dot cz  2010-06-01 22:56 ---
No longer crashes in r160122, most likely fixed by r160121


-- 

zsojka at seznam dot cz changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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



[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code

2010-06-01 Thread burnus at gcc dot gnu dot org


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.6.0
  Known to work||4.5.0
   Target Milestone|--- |4.6.0


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



[Bug fortran/44371] New: [4.6 Regression] STOP parsing rejects valid code

2010-06-01 Thread burnus at gcc dot gnu dot org
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b2e1f15014d76daf

There, Al Greynolds reports that the following program fails to compile with:

  if (c=='y') stop; if (c=='Y') stop
   1
Error: Syntax error in STOP statement at (1)


I assume it is due to the new expression parsing for (ALL) STOP, which gets
confused if no expression is matched because of a semicolon rather than because
of EOL.


  character(1) c
  read(*,*) c
  if (c=='y') stop; if (c=='Y') stop
  end


-- 
   Summary: [4.6 Regression] STOP parsing rejects valid code
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  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=44371



[Bug middle-end/44370] [4.6 Regression] Revision 160111 caused many test failures

2010-06-01 Thread dominiq at lps dot ens dot fr


--- Comment #1 from dominiq at lps dot ens dot fr  2010-06-01 21:17 ---
Likely a duplicate of pr44368 and pr44369. Likely fixed by revision 160121.


-- 


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



[Bug middle-end/44369] [4.6 Regression] ICE with -O3 at revision 160112

2010-06-01 Thread dominiq at lps dot ens dot fr


--- Comment #2 from dominiq at lps dot ens dot fr  2010-06-01 21:11 ---
Fixed at revision 160121.


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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



[Bug middle-end/44370] New: [4.6 Regression] Revision 160111 caused many test failures

2010-06-01 Thread hjl dot tools at gmail dot com
On Linux/x86, revision 160111:

http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00022.html

caused:

FAIL: gcc.c-torture/compile/900116-1.c  -O3 -fomit-frame-pointer  (internal
compiler error)
FAIL: gcc.c-torture/compile/900116-1.c  -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.c-torture/compile/900116-1.c  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gcc.c-torture/compile/900116-1.c  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
FAIL: gcc.c-torture/compile/900116-1.c  -O3 -fomit-frame-pointer -funroll-loops
 (internal compiler error)
FAIL: gcc.c-torture/compile/900116-1.c  -O3 -fomit-frame-pointer -funroll-loops
 (test for excess errors)
FAIL: gcc.c-torture/compile/900116-1.c  -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/compile/900116-1.c  -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/execute/2801-1.c compilation,  -O3 -fomit-frame-pointer
 (internal compiler error)
FAIL: gcc.c-torture/execute/2801-1.c compilation,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gcc.c-torture/execute/2801-1.c compilation,  -O3 -fomit-frame-pointer
-funroll-loops  (internal compiler error)
FAIL: gcc.c-torture/execute/2801-1.c compilation,  -O3 -g  (internal
compiler error)
FAIL: gcc.c-torture/execute/builtins/pr22237.c compilation,  -O3
-fomit-frame-pointer  (internal compiler error)
FAIL: gcc.c-torture/execute/builtins/pr22237.c compilation,  -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler
error)
FAIL: gcc.c-torture/execute/builtins/pr22237.c compilation,  -O3
-fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gcc.c-torture/execute/builtins/pr22237.c compilation,  -O3 -g  (internal
compiler error)
FAIL: gcc.c-torture/execute/memcpy-1.c compilation,  -O3 -fomit-frame-pointer 
(internal compiler error)
FAIL: gcc.c-torture/execute/memcpy-1.c compilation,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gcc.c-torture/execute/memcpy-1.c compilation,  -O3 -fomit-frame-pointer
-funroll-loops  (internal compiler error)
FAIL: gcc.c-torture/execute/memcpy-1.c compilation,  -O3 -g  (internal compiler
error)
FAIL: gcc.c-torture/execute/mode-dependent-address.c compilation,  -O3
-fomit-frame-pointer  (internal compiler error)
FAIL: gcc.c-torture/execute/mode-dependent-address.c compilation,  -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler
error)
FAIL: gcc.c-torture/execute/mode-dependent-address.c compilation,  -O3
-fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gcc.c-torture/execute/mode-dependent-address.c compilation,  -O3 -g 
(internal compiler error)
FAIL: gcc.c-torture/execute/va-arg-22.c compilation,  -O3 -fomit-frame-pointer 
(internal compiler error)
FAIL: gcc.c-torture/execute/va-arg-22.c compilation,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gcc.c-torture/execute/va-arg-22.c compilation,  -O3 -fomit-frame-pointer
-funroll-loops  (internal compiler error)
FAIL: gcc.c-torture/execute/va-arg-22.c compilation,  -O3 -g  (internal
compiler error)
FAIL: gcc.dg/lto/noreturn-1 c_lto_noreturn-1_0.o assemble, -O0 -flto
FAIL: gcc.dg/lto/noreturn-1 c_lto_noreturn-1_0.o assemble, -O2 -flto
FAIL: gcc.dg/lto/noreturn-1 c_lto_noreturn-1_0.o assemble, -O2 -fwhopr
FAIL: gcc.dg/lto/noreturn-1 c_lto_noreturn-1_1.o assemble, -O0 -flto
FAIL: gcc.dg/lto/noreturn-1 c_lto_noreturn-1_1.o assemble, -O0 -fwhopr
FAIL: gcc.dg/lto/noreturn-1 c_lto_noreturn-1_1.o assemble, -O2 -flto
FAIL: gcc.dg/lto/noreturn-1 c_lto_noreturn-1_1.o assemble, -O2 -fwhopr
FAIL: gcc.dg/torture/pr24626-4.c  -O3 -fomit-frame-pointer  (internal compiler
error)
FAIL: gcc.dg/torture/pr24626-4.c  -O3 -fomit-frame-pointer  (test for excess
errors)
FAIL: gcc.dg/torture/pr24626-4.c  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  (internal compiler error)
FAIL: gcc.dg/torture/pr24626-4.c  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  (test for excess errors)
FAIL: gcc.dg/torture/pr24626-4.c  -O3 -fomit-frame-pointer -funroll-loops 
(internal compiler error)
FAIL: gcc.dg/torture/pr24626-4.c  -O3 -fomit-frame-pointer -funroll-loops 
(test for excess errors)
FAIL: gcc.dg/torture/pr24626-4.c  -O3 -g  (internal compiler error)
FAIL: gcc.dg/torture/pr24626-4.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/pr24750-1.c  -O3 -fomit-frame-pointer  (internal compiler
error)
FAIL: gcc.dg/torture/pr24750-1.c  -O3 -fomit-frame-pointer  (test for excess
errors)
FAIL: gcc.dg/torture/pr24750-1.c  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  (internal compiler error)
FAIL: gcc.dg/torture/pr24750-1.c  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  (test for excess errors)
FAIL: gcc.dg/torture/pr24750-1.c  -O3 -fomit-frame-pointer -funroll

[Bug fortran/44354] incorrect output at run time

2010-06-01 Thread dfranke at gcc dot gnu dot org


--- Comment #21 from dfranke at gcc dot gnu dot org  2010-06-01 21:02 
---
(In reply to comment #18)
> Expected:
> a) Allow it as extension (-std=gnu or -std=legacy; especially, for -std=gnu 
> one
> could consider a default-enabled warning)
> b) Reject it for -std=f(95,2003,2008)

I'd vote to reject it for any -std=*. This extension just asks for trouble.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
   GCC host triplet|x86_64-unknown-linux-gnu|


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



[Bug fortran/24978] ICE in gfc_assign_data_value_range

2010-06-01 Thread dfranke at gcc dot gnu dot org


--- Comment #38 from dfranke at gcc dot gnu dot org  2010-06-01 20:53 
---
*** Bug 44351 has been marked as a duplicate of this bug. ***


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||zeccav at gmail dot com


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



[Bug fortran/44351] [4.3/4.4/4.5] ICE in gfc_assign_data_value_range

2010-06-01 Thread dfranke at gcc dot gnu dot org


--- Comment #2 from dfranke at gcc dot gnu dot org  2010-06-01 20:53 ---
This was recently fixed.

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


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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



[Bug libstdc++/24196] Using string instances to pass arguments to dlls fails

2010-06-01 Thread steven at gcc dot gnu dot org


--- Comment #26 from steven at gcc dot gnu dot org  2010-06-01 20:50 ---
May become relevant to GCC itself again if GCC wants to link to a static
libstdc++


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||steven at gcc dot gnu dot
   ||org


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



[Bug bootstrap/42798] --enable-build-with-cxx bootstrap fails on i686-pc-linux-gnu (Fedora12)

2010-06-01 Thread rwild at gcc dot gnu dot org


--- Comment #6 from rwild at gcc dot gnu dot org  2010-06-01 20:46 ---
Update: 
GCC patch: 


-- 


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



[Bug fortran/44359] -Wall / -Wconversion: Too verbose warning for DATA BOZ conversions

2010-06-01 Thread dfranke at gcc dot gnu dot org


--- Comment #2 from dfranke at gcc dot gnu dot org  2010-06-01 20:43 ---
(In reply to comment #1)
> http://gcc.gnu.org/ml/fortran/2010-05/msg00229.html

With this patch:

$> gfortran-svn -Wall pr44359.f90
[no warning]

$> gfortran-svn -Wall -fno-range-check pr44359.f90
pr44359.f90:3.34:

  DATA  a  /  Z'F'  /,  b  /  Z'3'  /
  1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4)
at (1)
pr44359.f90:3.18:

  DATA  a  /  Z'F'  /,  b  /  Z'3'  /
  1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4)
at (1)


-- 

dfranke 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-06-01 20:43:41
   date||


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



[Bug middle-end/44369] [4.6 Regression] ICE with -O3 at revision 160112

2010-06-01 Thread zsojka at seznam dot cz


--- Comment #1 from zsojka at seznam dot cz  2010-06-01 20:32 ---
Doesn't crash with "-O3 -fno-tree-vectorize", crashes with "-O2
-ftree-vectorize" - likely related to PR44368


-- 


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



[Bug middle-end/44369] New: [4.6 Regression] ICE with -O3 at revision 160112

2010-06-01 Thread dominiq at lps dot ens dot fr
The following test

  function bar (i) result(yy)
integer i, j, k
character (len = i) :: yy(2)
do j = 1, size (yy, 1)
  do k = 1, i
yy(j)(k:k) = char (96+k)
  end do
end do
  end function bar

ICE when compiled at revision 160112:

[macbook] f90/bug% gfc -O3 char_result_13_red.f90
char_result_13_red.f90: In function 'bar':
char_result_13_red.f90:6:0: internal compiler error: Segmentation fault

The test has been extracted gcc/testsuite/gfortran.dg/char_result_13.f90 which
passed at revision 160060. The backtrace is:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0010
remove_insn (insn=0x141e71828) at ../../work/gcc/emit-rtl.c:3859
3859  PREV_INSN (next) = NULL;
(gdb) bt
#0  remove_insn (insn=0x141e71828) at ../../work/gcc/emit-rtl.c:3859
#1  0x0001008cf0d0 in expand_vselect (target=, op0=, perm=,
nelt=8) at ../../work/gcc/config/i386/i386.c:29419
#2  0x0001008cf342 in expand_vec_perm_1 (d=0x7fff5fbfc730) at
../../work/gcc/config/i386/i386.c:29686
#3  0x0001009024a6 in ix86_expand_vec_extract_even_odd (targ=, op0=, op1=, odd=0) at ../../work/gcc/config/i386/i386.c:30480
#4  0x000100295b18 in gen_vec_pack_trunc_v4si (operand0=0x141e70fe0,
operand1=,
operand2=0x141e70f80) at sse.md:6651
#5  0x00010060df27 in expand_binop_directly (mode=V4SImode,
binoptab=0x100ca4ed8, op0=0x141e70f00, op1=0x141e70f80, target=0x0,
unsignedp=0, methods=OPTAB_LIB_WIDEN, last=0x141e71798) at
../../work/gcc/optabs.c:1513
#6  0x000100609827 in expand_binop (mode=V4SImode, binoptab=0x100ca4ed8,
op0=0x141e70f00, op1=0x141e70f80, target=0x0, unsignedp=0,
methods=OPTAB_LIB_WIDEN) at ../../work/gcc/optabs.c:1579
#7  0x000100475695 in expand_expr_real_2 (ops=, target=0x0, tmode=VOIDmode,
modifier=EXPAND_NORMAL) at ../../work/gcc/expr.c:8263
#8  0x000100466b93 in expand_expr_real_1 (exp=0x141e6fb98, target=, tmode=VOIDmode,
modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../work/gcc/expr.c:9660
#9  0x00010046c7ef in expand_expr_real (exp=0x141e6fb98, target=, tmode=, modifier=, alt_rtl=) at ../../work/gcc/expr.c:7198
#10 0x0001004684e3 in expand_expr_real_1 (exp=0x141e49f20, target=, tmode=VOIDmode,
modifier=EXPAND_NORMAL, alt_rtl=0x0) at expr.h:558
#11 0x00010046cb0a in expand_operands (exp0=0x141e49f20, exp1=0x141e4f000,
target=0x0, op0=0x7fff5fbfcea8, op1=0x7fff5fbfcea0, modifier=EXPAND_NORMAL) at
expr.h:558
#12 0x00010047565a in expand_expr_real_2 (ops=, target=0x141e72150, tmode=V16QImode,
modifier=EXPAND_NORMAL) at ../../work/gcc/expr.c:8256
#13 0x000100466b93 in expand_expr_real_1 (exp=0x141e6fb60, target=, tmode=V16QImode,
modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../work/gcc/expr.c:9660
#14 0x00010046c7ef in expand_expr_real (exp=0x141e6fb60, target=, tmode=, modifier=, alt_rtl=) at ../../work/gcc/expr.c:7198
#15 0x0001004684e3 in expand_expr_real_1 (exp=0x141e4f0b0, target=, tmode=V16QImode,
modifier=EXPAND_NORMAL, alt_rtl=0x7fff5fbfd2c8) at expr.h:558
#16 0x0001004732aa in store_expr (exp=0x141e4f0b0, target=0x141e72150,
call_param_p=0, nontemporal=0 '\0') at ../../work/gcc/expr.c:4688
#17 0x000100479749 in expand_assignment (to=0x141e4fd68, from=0x141e4f0b0,
nontemporal=0 '\0') at ../../work/gcc/expr.c:4472
#18 0x00010038ce72 in expand_gimple_stmt (stmt=0x141e48460) at
../../work/gcc/cfgexpand.c:1873
#19 0x00010038e3b7 in expand_gimple_basic_block (bb=0x141d59a90) at
../../work/gcc/cfgexpand.c:3403
#20 0x0001003930d1 in gimple_expand_cfg () at
../../work/gcc/cfgexpand.c:3855
#21 0x000100622624 in execute_one_pass (pass=0x100bfa320) at
../../work/gcc/passes.c:1576
#22 0x0001006228fd in execute_pass_list (pass=0x100bfa320) at
../../work/gcc/passes.c:1631
#23 0x00010074f7cc in tree_rest_of_compilation (fndecl=0x141e15300) at
../../work/gcc/tree-optimize.c:410
#24 0x00010090e8c0 in cgraph_expand_function (node=0x141d2a560) at
../../work/gcc/cgraphunit.c:1632
#25 0x000100911799 in cgraph_optimize () at
../../work/gcc/cgraphunit.c:1711
#26 0x000100911e2a in cgraph_finalize_compilation_unit () at
../../work/gcc/cgraphunit.c:1171
#27 0x0001005b3176 in write_global_declarations () at
../../work/gcc/langhooks.c:310
#28 0x0001006ea493 in toplev_main (argc=3, argv=0x7fff5fbfd920) at
../../work/gcc/toplev.c:1054
#29 0x00010df4 in start ()


-- 
   Summary: [4.6 Regression] ICE with -O3 at revision 160112
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: x86_64-apple-darwin10
  GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10


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



[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86

2010-06-01 Thread changpeng dot fang at amd dot com


--- Comment #13 from changpeng dot fang at amd dot com  2010-06-01 19:59 
---
(In reply to comment #12)
> Ok. So I will let you continue to look into that and wait for your results?
> 
> Do you have any feedback on separate.patch and its influence on performance?
> 

+   for (; groups; groups = groups->next)
+ for (ref = groups->refs; ref; ref = ref->next)
+   {
+   if (cst_and_fits_in_hwi (ref->group->step))
+ continue;
+ if (!ref->issue_prefetch_p)
+ continue;
+   insn_to_prefetch_ratio = (unroll_factor * ninsns) / prefetch_count;
+   if (insn_to_prefetch_ratio < MIN_INSN_TO_SPECULATIVE_PREFETCH)
+ {
+   ref->issue_prefetch_p = false;
+   if (dump_file && (dump_flags & TDF_DETAILS))
+ fprintf (dump_file,
+  "Ignoring %p-- insn to prefetch ratio (%d) too small\n",
+  (void *) ref, insn_to_prefetch_ratio);
+ }
+   }
+ }

The patch should fix the tonto regression caused by non-constant step
prefetching. It is just that you should move the computation and comparison
outside  (before) the loop and the debug dump after the loop.

I am just thinking that for such loop, we should do nothing: non-non-temporal
stores and no constant step prefetching because nothing could be trusted.

I am doing some experiemnts and let you know what I could find. Thanks.


-- 


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



[Bug fortran/44359] -Wall / -Wconversion: Too verbose warning for DATA BOZ conversions

2010-06-01 Thread dfranke at gcc dot gnu dot org


--- Comment #1 from dfranke at gcc dot gnu dot org  2010-06-01 19:50 ---
Haven't checked with the testcase from this PR, but it should be handled by:
http://gcc.gnu.org/ml/fortran/2010-05/msg00229.html


-- 


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



[Bug tree-optimization/44368] ICE: SIGSEGV in remove_insn (emit-rtl.c:3859) with -ftree-vectorize

2010-06-01 Thread zsojka at seznam dot cz


--- Comment #1 from zsojka at seznam dot cz  2010-06-01 19:38 ---
Created an attachment (id=20801)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20801&action=view)
reduced testcase (from gcc.c-torture/compile/900116-1.c)

Command line:
$ gcc -O[123] -ftree-vectorize pr44368.c


-- 


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



[Bug tree-optimization/44368] New: ICE: SIGSEGV in remove_insn (emit-rtl.c:3859) with -ftree-vectorize

2010-06-01 Thread zsojka at seznam dot cz
Compiler flags:
$ gcc -O[123] -ftree-vectorize testcase.c
(-ftree-vectorize is not needed with -O3)

Tested revisions:
r160112 - crash
r160052 - OK

Valgrind output:
$ valgrind -q --trace-children=yes
/mnt/svn/gcc-trunk/binary-160112-lto-fortran/bin/gcc -O1 -ftree-vectorize
testcase.c
==31407== Invalid write of size 8
==31407==at 0x5F41C8: remove_insn (emit-rtl.c:3859)
==31407==by 0x97633E: expand_vselect (i386.c:29419)
==31407==by 0x97654D: expand_vec_perm_1 (i386.c:29686)
==31407==by 0x9A49FD: ix86_expand_vec_extract_even_odd (i386.c:30480)
==31407==by 0xB405B0: gen_vec_extract_evenv16qi (sse.md:4644)
==31407==by 0x71CAB8: expand_binop_directly (optabs.c:1513)
==31407==by 0x718840: expand_binop (optabs.c:1579)
==31407==by 0x61DC3F: expand_expr_real_2 (expr.c:8179)
==31407==by 0x60F647: expand_expr_real_1 (expr.c:9660)
==31407==by 0x6101AE: expand_expr_real_1 (expr.h:558)
==31407==by 0x620844: expand_assignment (expr.h:558)
==31407==by 0x577591: expand_gimple_stmt (cfgexpand.c:1873)
==31407==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
==31407==
testcase.c: In function 'foo':
testcase.c:12:12: internal compiler error: Segmentation fault


-- 
   Summary: ICE: SIGSEGV in remove_insn (emit-rtl.c:3859) with -
ftree-vectorize
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  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=44368



[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86

2010-06-01 Thread borntraeger at de dot ibm dot com


--- Comment #12 from borntraeger at de dot ibm dot com  2010-06-01 19:30 
---
Ok. So I will let you continue to look into that and wait for your results?

Do you have any feedback on separate.patch and its influence on performance?


-- 


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



[Bug lto/42451] 'warning: type of "array" does not match original declaration' with -flto/-fwhopr

2010-06-01 Thread zsojka at seznam dot cz


--- Comment #8 from zsojka at seznam dot cz  2010-06-01 19:22 ---
Testcases from comment #1/#2 and comment #4 no longer fail in r160112. They
stopped failing between r158969 and r159696.

Testcase from comment #6 still fails for me (x86_64-linux)


-- 


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



[Bug bootstrap/42798] --enable-build-with-cxx bootstrap fails on i686-pc-linux-gnu (Fedora12)

2010-06-01 Thread amylaar at gcc dot gnu dot org


--- Comment #5 from amylaar at gcc dot gnu dot org  2010-06-01 19:22 ---
I posted an autoconf patch on the autoconf list, which has not been
reviewed since it was posted in February:
http://lists.gnu.org/archive/html/autoconf/2010-02/msg00057.html

The problem persists with gcc trunk revision 160116 on
i686-pc-linux-gnu (Fedora13).


-- 

amylaar 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-06-01 19:22:08
   date||


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



[Bug c/44355] "\ " at the end of a comment

2010-06-01 Thread pinskia at gcc dot gnu dot org


--- Comment #6 from pinskia at gcc dot gnu dot org  2010-06-01 18:24 ---
Mark as a dup of still opened bug 8270.  Which explains why this is allowed.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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



[Bug preprocessor/8270] [4.3/4.4/4.5/4.6 Regression] back-slash white space newline with comments, no warning

2010-06-01 Thread pinskia at gcc dot gnu dot org


--- Comment #43 from pinskia at gcc dot gnu dot org  2010-06-01 18:24 
---
*** Bug 44355 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||romain dot failliot at gmail
   ||dot com


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



[Bug c/44355] "\ " at the end of a comment

2010-06-01 Thread pinskia at gcc dot gnu dot org


--- Comment #5 from pinskia at gcc dot gnu dot org  2010-06-01 18:24 ---
Reopening to ...


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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



[Bug tree-optimization/44363] [4.6 Regression] gcc fails with ICE when compiling ffmpeg

2010-06-01 Thread spop at gcc dot gnu dot org


--- Comment #10 from spop at gcc dot gnu dot org  2010-06-01 18:18 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00063.html


-- 


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



[Bug c/44365] ICE with -fdump-tree-all

2010-06-01 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
   Keywords||ice-on-valid-code


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



[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86

2010-06-01 Thread changpeng dot fang at amd dot com


--- Comment #11 from changpeng dot fang at amd dot com  2010-06-01 17:40 
---
 (In reply to comment #10)
> Created an attachment (id=20783)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20783&action=view) [edit]
> experimental patch to have separate values for min_insn_to_prefetch_ration
> 
> Changpeng,
> 
> thank you for the feedback.
> Can you confirm that the regression was introduced by a prefetch with an
> unknown step or is there still a bug in the calculation of the "normal"
> prefetches (e.g. by applying the first patch that disables non-constant steps)
> 
> Anyway, here is a patch that increases min_insn_to_prefetch_ratio for
> non-constant steps. Does that make a difference for tonto? Do you prefer other
> intial values?
> Thanks
> 
> Christian
> 
Hi, Christian:

For constant step prefetching only, tonto regressed by ~7%, and for const +
invariant step prefetching combined, it regressed by ~16%.

I should have mentioned earlier that non-constant step prefetching has improved
459.GemsFDTD by 4~5% on amd-linux64 systems, and tonto regression by
non-constant step prefetching should be able to be fixed by re-compute the
prefetch count by considering the unroll_factor. However, I have found the 
non-temporal store problem which can cause 416.gamess degradation by ~50%.
I am not sure whether it is caused by non-constant step prefetching or not.


-- 


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



[Bug debug/44367] -O0 -g wrong DW_AT_location on c++ class retval

2010-06-01 Thread jakub at gcc dot gnu dot org


--- Comment #2 from jakub at gcc dot gnu dot org  2010-06-01 17:14 ---
Created an attachment (id=20800)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20800&action=view)
gcc46-pr44367.patch

Fix.


-- 


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



[Bug c++/44366] g++ crashes when declaring a lambda expression using a typedef'd decltype.

2010-06-01 Thread paolo dot carlini at oracle dot com


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-01 17:04:39
   date||


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



[Bug debug/44367] -O0 -g wrong DW_AT_location on c++ class retval

2010-06-01 Thread jakub at gcc dot gnu dot org


--- Comment #1 from jakub at gcc dot gnu dot org  2010-06-01 16:30 ---
Testing a fix.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-01 16:30:09
   date||


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



[Bug tree-optimization/44363] [4.6 Regression] gcc fails with ICE when compiling ffmpeg

2010-06-01 Thread lists at eitanadler dot com


--- Comment #9 from lists at eitanadler dot com  2010-06-01 16:23 ---
(In reply to comment #8)
> (In reply to comment #7)
...
> That is not what I was asking for. Please add -v to the command line
> used to compile libavutil/crc.o and show its output.
Sorry, I misunderstood. Here is the output with -v

Using built-in specs.
COLLECT_GCC=gcc46
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd8.1/4.6.0/lto-wrapper
Target: i386-portbld-freebsd8.1
Configured with: ./../gcc-4.6-20100529/configure --disable-nls
--libdir=/usr/local/lib/gcc46 --libexecdir=/usr/local/libexec/gcc46
--program-suffix=46 --with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc46/include/c++/
--with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local
--with-system-zlib --disable-rpath --prefix=/usr/local --mandir=/usr/local/man
--infodir=/usr/local/info/gcc46 --build=i386-portbld-freebsd8.1
Thread model: posix
gcc version 4.6.0 20100529 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-DHAVE_AV_CONFIG_H' '-D_FILE_OFFSET_BITS=64'
'-D_LARGEFILE_SOURCE' '-I.' '-I/dta/ports/multimedia/ffmpeg/work/ffmpeg-0.5.2'
'-pipe' '-O3' '-ffast-math' '-fno-finite-math-only' '-fno-strict-aliasing'
'-D_ISOC99_SOURCE' '-D_POSIX_C_SOURCE=200112' '-I/usr/local/include/vorbis'
'-I/usr/local/include' '-std=c99' '-fomit-frame-pointer'
'-Wdeclaration-after-statement' '-Wall' '-Wno-switch' '-Wdisabled-optimization'
'-Wpointer-arith' '-Wredundant-decls' '-Wno-pointer-sign' '-Wcast-qual'
'-Wwrite-strings' '-Wtype-limits' '-Wundef' '-O3' '-fno-math-errno'
'-fno-signed-zeros' '-c' '-o' 'libavutil/crc.o' '-mtune=i386' '-march=i386'
 /usr/local/libexec/gcc46/gcc/i386-portbld-freebsd8.1/4.6.0/cc1 -quiet -v -I.
-I/dta/ports/multimedia/ffmpeg/work/ffmpeg-0.5.2 -I/usr/local/include/vorbis
-I/usr/local/include -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 libavutil/crc.c
-quiet -dumpbase crc.c -mtune=i386 -march=i386 -auxbase-strip libavutil/crc.o
-O3 -O3 -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization
-Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings
-Wtype-limits -Wundef -std=c99 -version -ffast-math -fno-finite-math-only
-fno-strict-aliasing -fomit-frame-pointer -fno-math-errno -fno-signed-zeros -o
- |
 /usr/local/bin/as -v -I. -I/dta/ports/multimedia/ffmpeg/work/ffmpeg-0.5.2
-I/usr/local/include/vorbis -I/usr/local/include -o libavutil/crc.o
GNU assembler version 2.20.1 (i386-portbld-freebsd8.1) using BFD version (GNU
Binutils) 2.20.1.20100303
GNU C (GCC) version 4.6.0 20100529 (experimental) (i386-portbld-freebsd8.1)
compiled by GNU C version 4.6.0 20100529 (experimental), GMP version
5.0.1, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/usr/local/lib/gcc46/gcc/i386-portbld-freebsd8.1/4.6.0/../../../../../i386-portbld-freebsd8.1/include"
ignoring duplicate directory "/dta/ports/multimedia/ffmpeg/work/ffmpeg-0.5.2"
ignoring duplicate directory "/usr/local/include"
  as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
 .
 /usr/local/include/vorbis
 /usr/local/include
 /usr/local/lib/gcc46/gcc/i386-portbld-freebsd8.1/4.6.0/include
 /usr/local/lib/gcc46/gcc/i386-portbld-freebsd8.1/4.6.0/include-fixed
 /usr/include
End of search list.
GNU C (GCC) version 4.6.0 20100529 (experimental) (i386-portbld-freebsd8.1)
compiled by GNU C version 4.6.0 20100529 (experimental), GMP version
5.0.1, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: bb151bb48adc986d2afc1e0bfbd5e86d
libavutil/crc.c: In function 'av_crc_init':
libavutil/crc.c:58:5: internal compiler error: in predicate_bbs, at
tree-if-conv.c:555
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 

lists at eitanadler dot com changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


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



[Bug tree-optimization/44363] [4.6 Regression] gcc fails with ICE when compiling ffmpeg

2010-06-01 Thread hjl dot tools at gmail dot com


--- Comment #8 from hjl dot tools at gmail dot com  2010-06-01 16:09 ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #0)
> > > gcc46 -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> > > -I. -I"/dta/ports/multimedia/ffmpeg/work/ffmpeg-0.5.2" -pipe -mssse3
> > > -mtune=native -O3 -ffast-math -fno-finite-math-only
> > > -fomit-frame-pointer -Wl,-rpath=/usr/local/lib/gcc46
> > > -fno-strict-aliasing -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112
> > > -I/usr/local/include/vorbis -I/usr/local/include -std=c99
> > > -fomit-frame-pointer -Wdeclaration-after-statement -Wall -Wno-switch
> > > -Wdisabled-optimization -Wpointer-arith -Wredundant-decls
> > > -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -Wundef
> > > -O3 -fno-math-errno -fno-signed-zeros  -c -o libavutil/crc.o
> > 
> > When you use -mtune=native, please include output from "gcc -v ..."
> > to show real tune target passed to cc1. Otherwise, people will have
> > a hard time to reproduce your problem since their native machines may
> > be very different from yours.
> > 
> See the top of the description - this was the first piece of information I
> provided.
> 

That is not what I was asking for. Please add -v to the command line
used to compile libavutil/crc.o and show its output.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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



[Bug tree-optimization/44363] [4.6 Regression] gcc fails with ICE when compiling ffmpeg

2010-06-01 Thread lists at eitanadler dot com


--- Comment #7 from lists at eitanadler dot com  2010-06-01 15:58 ---
(In reply to comment #6)
> (In reply to comment #0)
> > gcc46 -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> > -I. -I"/dta/ports/multimedia/ffmpeg/work/ffmpeg-0.5.2" -pipe -mssse3
> > -mtune=native -O3 -ffast-math -fno-finite-math-only
> > -fomit-frame-pointer -Wl,-rpath=/usr/local/lib/gcc46
> > -fno-strict-aliasing -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112
> > -I/usr/local/include/vorbis -I/usr/local/include -std=c99
> > -fomit-frame-pointer -Wdeclaration-after-statement -Wall -Wno-switch
> > -Wdisabled-optimization -Wpointer-arith -Wredundant-decls
> > -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -Wundef
> > -O3 -fno-math-errno -fno-signed-zeros  -c -o libavutil/crc.o
> 
> When you use -mtune=native, please include output from "gcc -v ..."
> to show real tune target passed to cc1. Otherwise, people will have
> a hard time to reproduce your problem since their native machines may
> be very different from yours.
> 
See the top of the description - this was the first piece of information I
provided.


-- 

lists at eitanadler dot com changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


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



[Bug tree-optimization/44363] [4.6 Regression] gcc fails with ICE when compiling ffmpeg

2010-06-01 Thread hjl dot tools at gmail dot com


--- Comment #6 from hjl dot tools at gmail dot com  2010-06-01 15:44 ---
(In reply to comment #0)
> gcc46 -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> -I. -I"/dta/ports/multimedia/ffmpeg/work/ffmpeg-0.5.2" -pipe -mssse3
> -mtune=native -O3 -ffast-math -fno-finite-math-only
> -fomit-frame-pointer -Wl,-rpath=/usr/local/lib/gcc46
> -fno-strict-aliasing -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112
> -I/usr/local/include/vorbis -I/usr/local/include -std=c99
> -fomit-frame-pointer -Wdeclaration-after-statement -Wall -Wno-switch
> -Wdisabled-optimization -Wpointer-arith -Wredundant-decls
> -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -Wundef
> -O3 -fno-math-errno -fno-signed-zeros  -c -o libavutil/crc.o

When you use -mtune=native, please include output from "gcc -v ..."
to show real tune target passed to cc1. Otherwise, people will have
a hard time to reproduce your problem since their native machines may
be very different from yours.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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



[Bug tree-optimization/44357] [4.6 Regression] internal compiler error: in cgraph_decide_inlining_of_small_functions

2010-06-01 Thread vladimir at acm dot org


--- Comment #4 from vladimir at acm dot org  2010-06-01 15:38 ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --disable-bootstrap --enable-gold
Thread model: posix
gcc version 4.6.0 20100523 (experimental) (GCC) 


-- 


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



[Bug middle-end/44324] [4.6 Regression] gcc.dg/tree-ssa/ipa-cp-1.c failed

2010-06-01 Thread hjl dot tools at gmail dot com


--- Comment #3 from hjl dot tools at gmail dot com  2010-06-01 15:34 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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



[Bug c++/44361] -Wunused-but-set-variable vs. explicit void cast

2010-06-01 Thread jakub at gcc dot gnu dot org


--- Comment #2 from jakub at gcc dot gnu dot org  2010-06-01 15:05 ---
Created an attachment (id=20799)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20799&action=view)
gcc46-pr44361.patch

Updated patch.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #20791|0   |1
is obsolete||


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



[Bug tree-optimization/44363] [4.6 Regression] gcc fails with ICE when compiling ffmpeg

2010-06-01 Thread lists at eitanadler dot com


--- Comment #5 from lists at eitanadler dot com  2010-06-01 14:52 ---
This is only caused by -O3. -O2 seems perfectly fine.


-- 


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



[Bug tree-optimization/44357] [4.6 Regression] internal compiler error: in cgraph_decide_inlining_of_small_functions

2010-06-01 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2010-06-01 14:49 ---
At which optimization level?  Works for me at -O[123s].

Please provide output of appending '-v' to your commandline.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING
  Component|c++ |tree-optimization
Summary|internal compiler error: in |[4.6 Regression] internal
   |cgraph_decide_inlining_of_sm|compiler error: in
   |all_functions   |cgraph_decide_inlining_of_sm
   ||all_functions
   Target Milestone|--- |4.6.0


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



[Bug tree-optimization/44363] [4.6 Regression] gcc fails with ICE when compiling ffmpeg

2010-06-01 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2010-06-01 14:43 ---
Looks like caused by Sebs patches.  (I can't reproduce it though, maybe
re-verify with current trunk)


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||spop at gcc dot gnu dot org
  Component|c++ |tree-optimization
Summary|gcc fails with ICE when |[4.6 Regression] gcc fails
   |compiling ffmpeg|with ICE when compiling
   ||ffmpeg
   Target Milestone|--- |4.6.0


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



[Bug c/44365] ICE with -fdump-tree-all

2010-06-01 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2010-06-01 14:38 ---
Confirmed.  C FE issue.  We have a TYPE_DECL that refers to itself.

#1  0x00a519fa in dump_generic_node (buffer=0x1646280, 
node=0x75add690, spc=2, flags=0, is_stmt=0 '\000')
at /space/rguenther/src/svn/gcc-4_5-branch/gcc/tree-pretty-print.c:881
881   dump_generic_node (buffer, TYPE_NAME (node), spc, flags,
false);
(gdb) p node->base.code
$3 = RECORD_TYPE
(gdb) p node->type.name
$4 = (tree) 0x75afd000
(gdb) p node->type.name->base.code
$5 = TYPE_DECL
(gdb) p node->type.name->common.type
$6 = (tree) 0x75add690
(gdb) p node->type.name->common.type->type.name
$7 = (tree) 0x75afd000


-- 

rguenth 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-06-01 14:38:13
   date||


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



[Bug debug/44367] New: -O0 -g wrong DW_AT_location on c++ class retval

2010-06-01 Thread jan dot kratochvil at redhat dot com
struct a
{
  int i;
  int j;
};
static void g (int j)
{
}
static struct a f()
{
  struct a a;
  a.i = 42;
  g (a.i);  /* line 13 */
  return a;
}
int
main ()
{
  f();
  return 0;
}
--
 <2><8a>: Abbrev Number: 8 (DW_TAG_variable)
<8b>   DW_AT_name: a
<93>   DW_AT_location: 2 byte block: 73 0   (DW_OP_breg3: 0)
 <2><96>: Abbrev Number: 9 (DW_TAG_lexical_block)
<97>   DW_AT_low_pc  : 0x80483d3
<9b>   DW_AT_high_pc : 0x80483e3
 <3><9f>: Abbrev Number: 8 (DW_TAG_variable)
   DW_AT_name: a
   DW_AT_location: 2 byte block: 91 6c  (DW_OP_fbreg: -20)
 - but `a' is never located in the frame.
--
g++ -m32 -o a a.C -Wall -g
gdb -nx -ex 'b 13' -ex r -ex 'p/x $pc' -ex 'p a.i' ./a
Actual:
$2 = 5823984
Expected:
$2 = 42
--
FAIL:
g++ (GCC) 4.6.0 20100601 (experimental)
g++ (GCC) 4.5.1 20100601 (prerelease)
g++ (GCC) 4.4.5 20100601 (prerelease)

It affects also x86_64 when it cannot return the whole class in registers.
Failed to reproduce it with plain C.


-- 
   Summary: -O0 -g wrong DW_AT_location on c++ class retval
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: i386-unknown-linux-gnu


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



[Bug c++/44366] g++ crashes when declaring a lambda expression using a typedef'd decltype.

2010-06-01 Thread LindleyF at gmail dot com


--- Comment #3 from LindleyF at gmail dot com  2010-06-01 14:22 ---
Created an attachment (id=20798)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20798&action=view)
Small test case

Small test case file.


-- 


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



[Bug c++/44366] g++ crashes when declaring a lambda expression using a typedef'd decltype.

2010-06-01 Thread LindleyF at gmail dot com


--- Comment #2 from LindleyF at gmail dot com  2010-06-01 14:20 ---
Created an attachment (id=20797)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20797&action=view)
Preprocessed file

Preprocessor output for the small test case.


-- 


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



[Bug c++/44366] g++ crashes when declaring a lambda expression using a typedef'd decltype.

2010-06-01 Thread LindleyF at gmail dot com


--- Comment #1 from LindleyF at gmail dot com  2010-06-01 14:20 ---
Created an attachment (id=20796)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20796&action=view)
g++ -std=c++0x -o test2 test2.cpp -g -save-temps -v &> gcclog.txt

Build log generated by
g++ -std=c++0x -o test2 test2.cpp -g -save-temps -v &> gcclog.txt


-- 


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



[Bug c++/44363] gcc fails with ICE when compiling ffmpeg

2010-06-01 Thread lists at eitanadler dot com


--- Comment #3 from lists at eitanadler dot com  2010-06-01 14:20 ---
After some more testing I could leave all the -f options on as long as I set
-O0. I'm still testing to see if it works with -O1 or -O2.


-- 


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



[Bug c++/44366] New: g++ crashes when declaring a lambda expression using a typedef'd decltype.

2010-06-01 Thread LindleyF at gmail dot com
In the minimal example (to be attached), g++ crashes with a "please submit bug
report" message.

The goal of the original code was to provide a generic multi-label connected
component algorithm. Therefore, I wished to output a label along with each
Component of the same type as the input data 2d arraydecltype(data[0][0]).

However, when I added a lambda expression as part of operating on something
related to this type, g++ began crashing during compile.

I realize that in some cases decltype(data[0][0]) may have a reference type so
this code may be invalid; however, the compiler still should not crash, but
simply report an error.


-- 
   Summary: g++ crashes when declaring a lambda expression using a
typedef'd decltype.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: LindleyF at gmail dot com
 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=44366



[Bug fortran/44354] incorrect output at run time

2010-06-01 Thread mikael at gcc dot gnu dot org


--- Comment #20 from mikael at gcc dot gnu dot org  2010-06-01 14:13 ---
(In reply to comment #19)
> for a case like this :
> 
>   integer j(4)
>   I=5
>   j = (/(i,i=I-1,8)/)
You should read here :
j = (/(i,i=I,8)/)
>   end
> 


-- 


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



[Bug fortran/44354] incorrect output at run time

2010-06-01 Thread mikael at gcc dot gnu dot org


--- Comment #19 from mikael at gcc dot gnu dot org  2010-06-01 14:09 ---
Created an attachment (id=20795)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20795&action=view)
Draft patch, version 2

Also pre-evaluate the lower bound.

for a case like this :

  integer j(4)
  I=5
  j = (/(i,i=I-1,8)/)
  end


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #20787|0   |1
is obsolete||


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



[Bug fortran/44360] wrong-code: host-associated procedure wrongly favoured to use-associated one

2010-06-01 Thread burnus at gcc dot gnu dot org


--- Comment #3 from burnus at gcc dot gnu dot org  2010-06-01 14:01 ---
The issue seems to be parse.c's gfc_fixup_sibling_symbols - the the following
seems to exclude (use-associated) module variables and (use-associated)
functions from being fixed up:

&& !(old_sym->attr.external
  || (old_sym->ts.type != BT_UNKNOWN
&& !old_sym->attr.implicit_type)

Maybe one should check for use-association here?
That is:  || old_sym->attr.use_assoc.


-- 


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



[Bug c++/44362] Bogus set-but-not-used warning

2010-06-01 Thread jakub at gcc dot gnu dot org


--- Comment #1 from jakub at gcc dot gnu dot org  2010-06-01 13:58 ---
More complete testcase:
/* { dg-options "-Wunused" } */
/* { dg-do compile } */

int
f1 (int u, int v)
{
  int a, b, c, d, e, f, g, h, i;
  a = u;
  b = v;
  c = u;
  d = v;
  e = u;
  f = v;
  g = u == 6 ? a : b;
  h = 0 ? c : d;
  i = 1 ? e : f;
  return g + h + i;
}

No warnings with C, two warnings with C++, apparently because
build_conditional_expr folds the created COND_EXPR before it has been marked.

Another testcase, again, no set but not used warnings in C but some in C++.
/* { dg-options "-Wunused" } */
/* { dg-do compile } */

void
f1 (int u, int v)
{
  int a, b, c, d, e, f;
  a = u;
  b = v;
  c = u;
  d = v;
  e = u;
  f = v;
  u == 6 ? a : b; /* { dg-warning "no effect" } */
  0 ? c : d; /* { dg-warning "no effect" } */
  1 ? e : f; /* { dg-warning "no effect" } */
}


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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



[Bug c/44365] New: ICE with -fdump-tree-all

2010-06-01 Thread bmei at broadcom dot com
GCC produces the ICE for the following code with -fdump-tree-all. This happens
in both 4.4.x as well as 4.5.0. It is caused by infinitely recursive call to
dump_generic_node (tree-pretty-print.c)

gcc t.c -fdump-tree-all


int main(int argc, char *argv[]){
int n;
if(argc==2)
n=atoi(argv[1]);
else{
exit(1);
}

#define offset(x,y) ((char *)&(x->y))-((char *)x)

struct {
int a[n];
char b[n];
char c;
}*bar;
printf("%d %d %d %d
\n",offset(bar,a[0]),offset(bar,b[0]),offset(bar,c),sizeof(*bar));
return 0;
}


-- 
   Summary: ICE with -fdump-tree-all
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bmei at broadcom dot com
GCC target triplet: x86_64-unknown-linux-gnu


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



[Bug rtl-optimization/44364] Wrong code with e500 double floating point

2010-06-01 Thread gcc at breakpoint dot cc


--- Comment #2 from gcc at breakpoint dot cc  2010-06-01 13:42 ---
Created an attachment (id=20794)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20794&action=view)
objdump of the compiled testcase


-- 


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



[Bug rtl-optimization/44364] Wrong code with e500 double floating point

2010-06-01 Thread gcc at breakpoint dot cc


--- Comment #1 from gcc at breakpoint dot cc  2010-06-01 13:42 ---
Created an attachment (id=20793)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20793&action=view)
test case


-- 


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



[Bug rtl-optimization/44364] New: Wrong code with e500 double floating point

2010-06-01 Thread gcc at breakpoint dot cc
The testcase (which is stripped down perl code) attached compiled with:
gcc -fPIC -fno-strict-aliasing -pipe \
 -O2 \
 -g -o tc-lossings-floats tc-lossings-floats.c -Wall -mno-isel

results in after executing:
|RESET: 252.00 | 0.00
|RESET: 504.00 | 252.00
|RESET: 756.00 | 504.00
|RESET: 1008.00 | 756.00
|RESET: 1260.00 | 1008.00
|RESET: 1512.00 | 1260.00
|RESET: 1764.00 | 1512.00
|RESET: 2016.00 | 1764.00
|RESET: 2268.00 | 2016.00
 => 2268.00
|RESET: 2520.00 | 0.00
|RESET: 2772.00 | 2520.00

With -O1 instead -O2:
|RESET: 252.00 | 0.00
|RESET: 504.00 | 252.00
|RESET: 756.00 | 504.00
|RESET: 1008.00 | 756.00
|RESET: 1260.00 | 1008.00
|RESET: 1512.00 | 1260.00
|RESET: 1764.00 | 1512.00
|RESET: 2016.00 | 1764.00
|RESET: 2268.00 | 2016.00
 => 2268.00
|RESET: 2520.00 | 2268.00
|RESET: 2772.00 | 2520.00

The "=>" line sets the the second value in the "|RESET" line. With -O1 is
remains where it is, with -O2 it gets overwritten. The original perl code gets
here a totally random values. 

Now. It is getting better. The source compiled with -S and the resulting
assembly file assembled with gcc-4.3 does not show this problem. After diffing
of the two resulting binaries I saw  a difference in __floatdidf() which is
called from Kino_OutStream_tell(). The variant which is attached by the 4.3
compiler does not use floating point instead it uses integer code which calls
other functions (__floatsidf, __muldf3, __floatunsidf, __adddf3) which use also
interger code. The 4.3 compiler was not compiled with --enable-e500_double. 

So after looking at the code I saw now the following:
1c24 <__floatdidf>:
1c6c:   11 23 1a 2c evmergehi r9,r3,r3

This function is touching the complete 64bit r9 register
The code which calls it:

1a40:   91 21 00 20 stw r9,32(r1)
1a44:   4e 80 04 21 bctrl   # tell function which in turn calls
floatdidf

1a7c:   81 21 00 20 lwz r9,32(r1)
1a80:   38 60 00 00 li  r3,0
1a84:   7e 33 8b 78 mr  r19,r17 
1a88:   12 49 92 e1 efdsub  r18,r9,r18
1a8c:   10 80 92 fa efdctsiz r4,r18
1a90:   12 49 4a 17 evmrr18,r9  

So we just save the lower 32bit of r9 before calling the function and the upper
32bit are overwritten by efdsub.


-- 
   Summary: Wrong code with e500 double floating point
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at breakpoint dot cc
 GCC build triplet: powerpc-linux-gnuspe
  GCC host triplet: powerpc-linux-gnuspe
GCC target triplet: powerpc-linux-gnuspe


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



[Bug fortran/44360] wrong-code: host-associated procedure wrongly favoured to use-associated one

2010-06-01 Thread burnus at gcc dot gnu dot org


--- Comment #2 from burnus at gcc dot gnu dot org  2010-06-01 12:44 ---
Some debugging shows that at least for
  gfc_match_call
the correct symtree is picked up via gfc_get_ha_sym_tree and saved into
new_st.symtree (tested via: attr.use_assoc == 1 and formal->sym->name == pvec).


However, the search is thrown over in resolve_call:
  if (csym && gfc_current_ns->parent && csym->ns != gfc_current_ns)
  gfc_find_sym_tree (csym->name, gfc_current_ns, 1, &st);
  And this finds the wrong sym.

... Actually, that's incomplete - already c->symtree->n.sym has the wrong
symbol?!?

In case  of functions/variables, it seems to go through check_host_association
- which somehow avoids this problem (cf. below).

 * * *

As the following test case shows, only use-associated SUBROUTINES are
mishandled, use-associated module variables and use-associated FUNCTIONS are
handled correctly:

! { dg-do run }
!
! PR fortran/44360
!
module m
  integer :: var = 43
contains
 integer function fun()
   fun = 42
 end function fun
 subroutine fun2()
   print *, 'OK'
 end subroutine fun2
end module m

module m2
  integer :: var = -2 ! OK, never accessed
contains
 subroutine test()
   use m
   call fun2()! Calls ABORT()
   if (fun() /= 42) call abort()  ! OK
   if (var /= 43) call abort()! OK
 end subroutine test
 integer function fun()
   call abort() ! OK, never called
   fun = -3  
 end function fun
 subroutine fun2()
   call abort()  ! <<< Should not be called but is
 end subroutine fun2
end module m2

use m2
call test()
end
! { dg-final { cleanup-modules "m m2" } }


-- 


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



[Bug c++/44363] gcc fails with ICE when compiling ffmpeg

2010-06-01 Thread lists at eitanadler dot com


--- Comment #2 from lists at eitanadler dot com  2010-06-01 12:41 ---
Sorry - I forgot to include the following data:
% uname -rms
FreeBSD 8.1-BETA1 i386


-- 


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



[Bug c++/44363] gcc fails with ICE when compiling ffmpeg

2010-06-01 Thread lists at eitanadler dot com


--- Comment #1 from lists at eitanadler dot com  2010-06-01 12:39 ---
Created an attachment (id=20792)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20792&action=view)
preprocessed source of file that fails


-- 


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



[Bug c++/44363] New: gcc fails with ICE when compiling ffmpeg

2010-06-01 Thread lists at eitanadler dot com
% gcc46 -v
Using built-in specs.
COLLECT_GCC=gcc46
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd8.1/4.6.0/lto-wrapper
Target: i386-portbld-freebsd8.1
Configured with: ./../gcc-4.6-20100529/configure --disable-nls
--libdir=/usr/local/lib/gcc46 --libexecdir=/usr/local/libexec/gcc46
--program-suffix=46 --with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc46/include/c++/
--with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local
--with-system-zlib --disable-rpath --prefix=/usr/local --mandir=/usr/local/man
--infodir=/usr/local/info/gcc46 --build=i386-portbld-freebsd8.1
Thread model: posix
gcc version 4.6.0 20100529 (experimental) (GCC) 

gcc46 -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-I. -I"/dta/ports/multimedia/ffmpeg/work/ffmpeg-0.5.2" -pipe -mssse3
-mtune=native -O3 -ffast-math -fno-finite-math-only
-fomit-frame-pointer -Wl,-rpath=/usr/local/lib/gcc46
-fno-strict-aliasing -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112
-I/usr/local/include/vorbis -I/usr/local/include -std=c99
-fomit-frame-pointer -Wdeclaration-after-statement -Wall -Wno-switch
-Wdisabled-optimization -Wpointer-arith -Wredundant-decls
-Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -Wundef
-O3 -fno-math-errno -fno-signed-zeros  -c -o libavutil/crc.o
libavutil/crc.c
libavutil/crc.c: In function 'av_crc_init':
libavutil/crc.c:58:5: internal compiler error: in predicate_bbs, at
tree-if-conv.c:555
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
gmake: *** [libavutil/crc.o] Error 1
gmake: *** Waiting for unfinished jobs
*** Error code 1

This appears to crash at the same point every time which I think rules out HW
error to me.

The following command compiles successfully:
gcc46 -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I.
-I"/dta/ports/multimedia/ffmpeg/work/ffmpeg-0.5.2" -pipe -O3
-Wl,-rpath=/usr/local/lib/gcc46 -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112
-I/usr/local/include/vorbis -I/usr/local/include -std=c99
-Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization
-Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings
-Wtype-limits -Wundef -O0 -c -o libavutil/crc.o libavutil/crc.c 

Note -O0 and removal of all -f* flags. I don't know exactly which flags I could
add and have it still compile.


-- 
   Summary: gcc fails with ICE when compiling ffmpeg
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lists at eitanadler dot com


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



[Bug c++/44362] New: Bogus set-but-not-used warning

2010-06-01 Thread rguenth at gcc dot gnu dot org
#define WORDS_BIG_ENDIAN 0
int foo(int x, int y)
{
  int a = x;
  int b = y;
  int j = WORDS_BIG_ENDIAN ? a : b;
  return j;
}

which actually breaks bootstrap with C++.


-- 
   Summary: Bogus set-but-not-used warning
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
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=44362



[Bug middle-end/43853] [4.6 Regression] FAIL: gcc.dg/lto/20090126-1 c_lto_20090126-1_0.o-c_lto_20090126-1_0.o

2010-06-01 Thread rguenth at gcc dot gnu dot org


--- Comment #6 from rguenth at gcc dot gnu dot org  2010-06-01 12:18 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug middle-end/43853] [4.6 Regression] FAIL: gcc.dg/lto/20090126-1 c_lto_20090126-1_0.o-c_lto_20090126-1_0.o

2010-06-01 Thread rguenth at gcc dot gnu dot org


--- Comment #5 from rguenth at gcc dot gnu dot org  2010-06-01 12:09 ---
Subject: Bug 43853

Author: rguenth
Date: Tue Jun  1 12:09:16 2010
New Revision: 160099

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160099
Log:
2010-06-01  Richard Guenther  

PR lto/43853
* ipa-pure-const.c (get_function_state): Hand back varying state
if we do not have one.
(has_function_state): New function.
(duplicate_node_data): Adjust.
(remove_node_data): Likewise.
(pure_const_write_summary): Likewise.
(propagate): Likewise.  Fix typo.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-pure-const.c


-- 


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



[Bug c++/44361] -Wunused-but-set-variable vs. explicit void cast

2010-06-01 Thread jakub at gcc dot gnu dot org


--- Comment #1 from jakub at gcc dot gnu dot org  2010-06-01 11:16 ---
Created an attachment (id=20791)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20791&action=view)
gcc46-pr44361.patch

Untested fix.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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



[Bug c++/44361] New: -Wunused-but-set-variable vs. explicit void cast

2010-06-01 Thread jakub at gcc dot gnu dot org
As noted by richi, gcc fails to bootstrap with --enable-build-with-cxx:
gcc/tree-flow-inline.h:854:8: error: variable 't' set but not used
[-Werror=unused-but-set-variable]


-- 
   Summary: -Wunused-but-set-variable vs. explicit void cast
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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



[Bug ada/44340] internal error on allocation/initialization

2010-06-01 Thread ebotcazou at gcc dot gnu dot org


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|2010-05-31 18:47:14 |2010-06-01 11:13:09
   date||


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



[Bug middle-end/44356] [4.6 regression] FAIL: gcc.dg/tree-ssa/loadpre6.c

2010-06-01 Thread rguenth at gcc dot gnu dot org


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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



[Bug fortran/44360] wrong-code: host-associated procedure wrongly favoured to use-associated one

2010-06-01 Thread burnus at gcc dot gnu dot org


--- Comment #1 from burnus at gcc dot gnu dot org  2010-06-01 10:09 ---
CONFIRMED. Old bug - dating back to at least 4.1.

Even explicitly importing the symbol does not help:
  use m1, only: sub


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot
   ||org, burnus at gcc dot gnu
   ||dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   GCC host triplet|x86_64-unknown-linux-gnu|
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2010-06-01 10:09:28
   date||
Summary|gfortran gets confused by   |wrong-code: host-associated
   |synonymous procedure names  |procedure wrongly favoured
   ||to use-associated one


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



[Bug c++/44358] [C++0x] initializer list can't convert to map

2010-06-01 Thread paolo dot carlini at oracle dot com


--- Comment #2 from paolo dot carlini at oracle dot com  2010-06-01 08:47 
---
Jason, can you have a look to this?


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org
Summary|initializer list can't  |[C++0x] initializer list
   |convert to map  |can't convert to map


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



  1   2   >