[Bug tree-optimization/43769] [4.3/4.4 regression] ICE in bitfield_overlaps_p, at tree-sra.c:2937

[ebotcazou at gcc dot gnu dot org]

--- Comment #9 from ebotcazou at gcc dot gnu dot org  2010-04-18 07:15 
---
Present on x86 and x86-64/Linux, as well as on the 4.4 branch.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet|i686-pc-cygwin  |
   GCC host triplet|i686-pc-cygwin  |
 GCC target triplet|i686-pc-cygwin  |
Summary|[4.3 regression] ICE in |[4.3/4.4 regression] ICE in
   |bitfield_overlaps_p, at |bitfield_overlaps_p, at
   |tree-sra.c:2937 |tree-sra.c:2937


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

[Bug tree-optimization/43771] [4.5/4.6 Regression] ICE on valid when compiling ParMetis with gcc 4.5.0 and -O3

[irar at il dot ibm dot com]

-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |irar at il dot ibm dot com
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-04-16 21:16:37 |2010-04-18 08:12:31
   date||


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

[Bug c++/43775] g++ parser rejects valid code.

[pluto at agmk dot net]

--- Comment #5 from pluto at agmk dot net  2010-04-18 08:35 ---
(In reply to comment #4)
> How do we know if this is valid code or not?
> 

comeau online testdriver accept this code.


-- 


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

[Bug fortran/43227] [4.5 Regression] ICE: segmentation fault in mio_expr

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2010-04-18 11:09 ---
It turns out this problem is not specific to the OOP stuff on fortran-dev, but
instead is due to an underlying problem with PROCEDURE statements (which
affects procedure pointers as well as PPCs), demonstrated by this test case:


module m_string

  procedure(string_to_char) :: char1! segfault

!   procedure(string_to_char),pointer :: char2  ! segfault

!   type t_string
! procedure(string_to_char),pointer,nopass :: char3 ! segfault
!   end type t_string

contains

  function string_to_char (s) result(res)
character, dimension(:), intent(in) :: s
character(len=size(s)) :: res
  end function string_to_char

end module m_string


All of the three forms of the PROCEDURE statement shown above trigger the same
ICE (which is also the same ICE as in comment #0 and #1, due to fortran-dev's
usage of PPCs in the implementation of polymorphic TBPs).

The above test case segfaults with 4.3, works with 4.4, and then fails again
with 4.5, 4.6 and fortran-dev. Therefore this PR is rather a 4.5 regression
than a fortran-dev regressions.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2010-04-18 11:09:35
   date||
Summary|[fortran-dev Regression]|[4.5 Regression] ICE:
   |ICE: segmentation fault in  |segmentation fault in
   |mio_expr|mio_expr


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

[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2010-04-18 11:48 ---
Marked as a 4.5/4.6 regression.


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

Summary|[4.5 Regression] ICE:   |[4.5/4.6 Regression] ICE:
   |segmentation fault in   |segmentation fault in
   |mio_expr|mio_expr


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

[Bug tree-optimization/43771] [4.5/4.6 Regression] ICE on valid when compiling ParMetis with gcc 4.5.0 and -O3

[irar at gcc dot gnu dot org]

--- Comment #4 from irar at gcc dot gnu dot org  2010-04-18 12:20 ---
Subject: Bug 43771

Author: irar
Date: Sun Apr 18 12:20:34 2010
New Revision: 158484

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

PR tree-optimization/43771
* tree-vect-slp.c (vect_supported_load_permutation_p): Check that
load permutation doesn't have gaps.


Added:
trunk/gcc/testsuite/g++.dg/vect/pr43771.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c


-- 


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

[Bug c++/6709] [DR743] decltype cannot be used with the :: operator

[faisalv at yahoo dot com]

--- Comment #15 from faisalv at yahoo dot com  2010-04-18 12:56 ---
I had (In reply to comment #14)
> *** Bug 43780 has been marked as a duplicate of this bug. ***
> 

The DR 743 has been voted into FCD (CD2) - shouldn't this be unsuspended?
thanks!


-- 


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

[Bug fortran/42353] [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...

[janus at gcc dot gnu dot org]

--- Comment #26 from janus at gcc dot gnu dot org  2010-04-18 13:13 ---
(In reply to comment #25)
> A provisional fix for this PR

Actually, what's the issue here? At rev. 158483 the fortran-dev testsuite runs
cleanly on x86_64-unknown-linux-gnu, and the test cases in this PR
(gfcbug96.f90, gfcbug96b.f90 and gfcbug96c.f90) all compile without error. Am I
missing something?


-- 


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

[Bug other/39979] possible wrong code at all -0x levels.

[pluto at agmk dot net]

--- Comment #3 from pluto at agmk dot net  2010-04-18 13:34 ---
Created an attachment (id=20408)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20408&action=view)
some tree dumps from 4.3/4.5.


-- 


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

[Bug other/39979] possible wrong code at all -0x levels.

[pluto at agmk dot net]

--- Comment #4 from pluto at agmk dot net  2010-04-18 13:44 ---
during analysis the boost::thread::start_thread() function which causes
invalid writes detected by valgrind i've noticed that gcc-4.5 generates
bigger and more complex code of this function with few more lock'ed opcodes.
afaics gcc-4.5 produces some mess for boost::shared_ptr.
could please someone look at this? it may be a missed optimization or other
bug.


-- 


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

[Bug fortran/42353] [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...

[pault at gcc dot gnu dot org]

--- Comment #27 from pault at gcc dot gnu dot org  2010-04-18 13:50 ---
(In reply to comment #26)
> (In reply to comment #25)
> > A provisional fix for this PR
> 
> Actually, what's the issue here? At rev. 158483 the fortran-dev testsuite runs
> cleanly on x86_64-unknown-linux-gnu, and the test cases in this PR
> (gfcbug96.f90, gfcbug96b.f90 and gfcbug96c.f90) all compile without error. Am 
> I
> missing something?
>

Janus,

I am still getting the message:

Error: The element in the derived type constructor at (1), for pointer
component
 '$extends', is DERIVED but should be DERIVED

for gfcbug96.f90.

I'd better check that it's still there when I remove my patch!

Cheers

Paul 


-- 


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

[Bug fortran/42353] [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...

[dominiq at lps dot ens dot fr]

--- Comment #28 from dominiq at lps dot ens dot fr  2010-04-18 13:55 ---
> I am still getting the message:

Me too with a clean fortran-dev r158481.

Note that the patch in comment #25 fixes it without regression for the test
suite and my own tests.


-- 


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

[Bug c++/9335] repeated diagnostic when maximum template depth is exceeded

[jason at gcc dot gnu dot org]

--- Comment #20 from jason at gcc dot gnu dot org  2010-04-18 14:42 ---
(In reply to comment #19)
> Well, the patch is mostly done, it reduces the output from 11 to 1 lines and 
> it
> neatly points out where is the recursive instantiation. So I hope you may
> reconsider, unless you think the 101 lines are useful to the user somehow.

101 lines? Is that a typo?

If this change only applies to the case where all 11 lines would be
instantiations of the same template I guess it sounds reasonable, though the
11-line output seems a bit clearer as to where the recursion is happening. 
Perhaps two instantiation lines in this case so we see the first recursion?


-- 


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

[Bug c++/43608] Boost.MPL code doesn't get the placeholders substituted anymore

[jason at gcc dot gnu dot org]

--- Comment #8 from jason at gcc dot gnu dot org  2010-04-18 15:04 ---
*** Bug 43775 has been marked as a duplicate of this bug. ***


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pluto at agmk dot net


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

[Bug c++/43775] g++ parser rejects valid code.

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2010-04-18 15:04 ---
Dup of 43608.

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


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/39991] wrong locus in error message

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2010-04-18 15:04 ---
Confirmed for gcc version 4.4.2, but this pr seems to be fixed for 4.5 (at
least since revision 154654) and trunk. Unless someone is able to point when it
has been fixed and want to backport the fix to 4.4, this pr could be closed as
fixed.


-- 


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

[Bug c++/43775] g++ parser rejects valid code.

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2010-04-18 15:08 ---
That is, the problem is that template_arity_impl calls
arity_helper(type_wrapper,...) in a way that uses arg-dependent lookup,
which means looking up arity_helper within F, which means instantiating F,
which in this case is use_simple_repeat.  4.5 is the first version of G++ to
implement this behavior.  As for 43608, the fix is to change
template_arity_impl to not use arg-dependent lookup.


-- 


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

[Bug testsuite/25763] objc.dg/stubify-*.m, and obj-c++.dg/stubify-*.mm fail on i686-darwin

[iains at gcc dot gnu dot org]

--- Comment #3 from iains at gcc dot gnu dot org  2010-04-18 15:17 ---
see:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00585.html
and:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00131.html


-- 

iains at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||iains at gcc dot gnu dot org


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

[Bug c/43781] ice: verify_ssa failed

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-04-18 15:20 ---
It is caused by revision 158380:

http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00486.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-04-18 15:20:10
   date||
   Target Milestone|--- |4.6.0
Version|unknown |4.6.0


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

[Bug fortran/40728] Bogus error "Error: Can't convert UNKNOWN to REAL(8) at (1)"

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2010-04-18 15:28 ---
Both the bogus error and the ICE (also with std=f95) are still there. The PR
should be marked NEW.


-- 


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

[Bug fortran/30802] out of bounds error array I/O not picked up with -fbounds-check

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2010-04-18 15:31 
---
Re-confirmed.

We have no bounds checking code in fortran/io.c nor in the I/O library.


-- 


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

[Bug fortran/41023] Inconsistent error locations for wrong interfaces with overloaded operators

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2010-04-18 15:37 ---
Confirmed. Note that between 4.4 and 4.5 the error from the second test of
comment #0 has changed from:

MODULE PROCEDURE myplus
   1
Error: Intrinsic operator interface at (1) must be a FUNCTION

to

  SUBROUTINE myplus (a, b)
   1
Error: Intrinsic operator interface at (1) must be a FUNCTION

So the errors for the two tests are now consistent. However I am not sure of
where is the best location for them (probably in both places).


-- 


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

[Bug fortran/41829] [OOP] Runtime error with dynamic dispatching

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2010-04-18 15:42 ---
Confirmed with trunk, fixed with fortran-dev.


-- 


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

[Bug fortran/40994] ICE with BIND(C)

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2010-04-18 15:49 ---
Still there on trunk -> should be marked as NEW.


-- 


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

[Bug tree-optimization/43783] New: [4.5 regression] -O -ftree-pre options compile libbid wrong

[roman at binarylife dot net]

$ cat test.c
#include 
int main() {
  _Decimal128 const a=1.1dl;
  _Decimal128 const b=1.111e-6158dl;
  _Decimal128 volatile x=a;
  _Decimal128 volatile y=b;
  double ab=a*b*1.0e6000dl;
  double xy=x*y*1.0e6000dl;
  printf("ab=%g\n",ab);
  printf("xy=%g\n",xy);
}

$ gcc test.c && ./a.out
ab=9.64506e-159
xy=9.64506e-159

$ gcc -O test.c && ./a.out
ab=1.23457e-158
xy=9.64506e-159

$ gcc --version | head -1
gcc (GCC) 4.5.1 20100418 (prerelease)

The correct value is 1.23457e-158:

$ echo "1.1*1.111" | bc
1.234567888

A simple modification of test.c can show that it is x*y and a*b, when computed
by libbid, are incorrect. The a*b expression, when computed by gcc (with -O),
is correct.

To further diagnose, I extracted libbid from the gcc source tree and compiled
it outside of gcc to link it with the above test.c program. I added some
#defines to compile the library and renamed some functions to call them
directly from the test.

I found that if compiled with -O only, libbid multiplies correctly. With -O
-ftree-pre, it multiplies incorrectly.

The real job is done by bid128_ext_fma() (about 3000 C lines).


-- 
   Summary: [4.5 regression] -O -ftree-pre options compile libbid
wrong
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roman at binarylife dot net
 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=43783

[Bug tree-optimization/43769] [4.3/4.4 regression] ICE in bitfield_overlaps_p, at tree-sra.c:2937

[ebotcazou at gcc dot gnu dot org]

--- Comment #10 from ebotcazou at gcc dot gnu dot org  2010-04-18 15:56 
---
Subject: Bug 43769

Author: ebotcazou
Date: Sun Apr 18 15:56:32 2010
New Revision: 158490

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158490
Log:
PR tree-optimization/43769
* tree-sra.c (bitfield_overlaps_p): If the length of the element is
self-referential, try to compute an upper bound.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gnat.dg/rep_clause5.adb
  - copied unchanged from r158489,
trunk/gcc/testsuite/gnat.dg/rep_clause5.adb
branches/gcc-4_4-branch/gcc/testsuite/gnat.dg/rep_clause5.ads
  - copied unchanged from r158489,
trunk/gcc/testsuite/gnat.dg/rep_clause5.ads
branches/gcc-4_4-branch/gcc/testsuite/gnat.dg/rep_clause5_pkg.ads
  - copied unchanged from r158489,
trunk/gcc/testsuite/gnat.dg/rep_clause5_pkg.ads
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-sra.c


-- 


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

[Bug fortran/41580] [OOP] SAME_TYPE_AS and EXTENDS_TYPE_OF - add compile-time simplifcation

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2010-04-18 15:56 ---
I cannot reproduce the error at
http://gcc.gnu.org/ml/fortran/2009-09/msg00298.html neither with trunk nor with
fortran-dev. Could this PR be more explicit about the problem?


-- 


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

[Bug tree-optimization/43769] [4.3/4.4 regression] ICE in bitfield_overlaps_p, at tree-sra.c:2937

[ebotcazou at gcc dot gnu dot org]

--- Comment #11 from ebotcazou at gcc dot gnu dot org  2010-04-18 15:57 
---
Subject: Bug 43769

Author: ebotcazou
Date: Sun Apr 18 15:56:56 2010
New Revision: 158491

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158491
Log:
PR tree-optimization/43769
* tree-sra.c (bitfield_overlaps_p): If the length of the element is
self-referential, try to compute an upper bound.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gnat.dg/rep_clause5.adb
  - copied unchanged from r158489,
trunk/gcc/testsuite/gnat.dg/rep_clause5.adb
branches/gcc-4_3-branch/gcc/testsuite/gnat.dg/rep_clause5.ads
  - copied unchanged from r158489,
trunk/gcc/testsuite/gnat.dg/rep_clause5.ads
branches/gcc-4_3-branch/gcc/testsuite/gnat.dg/rep_clause5_pkg.ads
  - copied unchanged from r158489,
trunk/gcc/testsuite/gnat.dg/rep_clause5_pkg.ads
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-sra.c


-- 


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

[Bug tree-optimization/43769] [4.3/4.4 regression] ICE in bitfield_overlaps_p, at tree-sra.c:2937

[ebotcazou at gcc dot gnu dot org]

--- Comment #12 from ebotcazou at gcc dot gnu dot org  2010-04-18 16:00 
---
On all branches.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||04/msg01135.html
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.5


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

[Bug c++/9335] repeated diagnostic when maximum template depth is exceeded

[manu at gcc dot gnu dot org]

--- Comment #21 from manu at gcc dot gnu dot org  2010-04-18 16:16 ---
(In reply to comment #20)
> (In reply to comment #19)
> > Well, the patch is mostly done, it reduces the output from 11 to 1 lines 
> > and it
> > neatly points out where is the recursive instantiation. So I hope you may
> > reconsider, unless you think the 101 lines are useful to the user somehow.
> 
> 101 lines? Is that a typo?

Yes, sorry. I meant 11 lines.

> If this change only applies to the case where all 11 lines would be
> instantiations of the same template I guess it sounds reasonable, though the
> 11-line output seems a bit clearer as to where the recursion is happening. 
> Perhaps two instantiation lines in this case so we see the first recursion?

My current patch prints:

/home/manuel/src/pr9335.C:2:36: error: template instantiation depth exceeds
maximum of 1024 (use -ftemplate-depth= to increase the maximum) instantiating
'struct X<-0x00018>'
/home/manuel/src/pr9335.C:2:36:   recursively instantiated from 'const int
X<1000>::value'
/home/manuel/src/pr9335.C:4:17:   instantiated from here

Is that ok or you would prefer the following?

/home/manuel/src/pr9335.C:2:36: error: template instantiation depth exceeds
maximum of 1024 (use -ftemplate-depth= to increase the maximum) instantiating
'struct X<-0x00018>'
/home/manuel/src/pr9335.C:2:36:   recursively instantiated from 'const int
X::value'
/home/manuel/src/pr9335.C:2:36:   recursively instantiated from 'const int
X<1000>::value'
/home/manuel/src/pr9335.C:4:17:   instantiated from here

I think with some tinkering I can reach that output but I don't see which
useful information provides, since the location of the extra line is the same
as the error line and the recursive instantiation line.


-- 


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

[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2010-04-18 16:18 ---
What about pr42274? Is it a duplicate or not?


-- 


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

[Bug fortran/41580] [OOP] SAME_TYPE_AS and EXTENDS_TYPE_OF - add compile-time simplifcation

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-04-18 16:21 ---
> Could this PR be more explicit about the problem?

No it cannot; as written: For SAME_TYPE_AS and EXTENDS_TYPE_OF one should add a
compile-time simplification to simplify.c.
Currently, only the run-time version is implemented.


-- 


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

[Bug fortran/41600] [OOP] SELECT TYPE with associate-name => exp: Arrays not supported

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2010-04-18 16:24 ---
The tests in comments #0 and #1 give a "Segmentation fault" with trunk or
fortran-dev.


-- 


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

[Bug tree-optimization/43784] New: [4.6 Regression] -Os -fkeep-inline-functions causes FAIL: gcc.c-torture/execute/builtins/pr22237.c execution

[zsojka at seznam dot cz]

Tested revisions:
r158486 - fail
r158225 - OK
4.5 r158131 - OK
4.4 r158133 - OK

Compiler output:
$ /mnt/svn/gcc-trunk/binary-158486-lto-fortran/bin/gcc -Os
-fkeep-inline-functions testcase.c && ./a.out
Aborted


-- 
   Summary: [4.6 Regression] -Os -fkeep-inline-functions causes
FAIL: gcc.c-torture/execute/builtins/pr22237.c execution
   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=43784

[Bug tree-optimization/43784] [4.6 Regression] -Os -fkeep-inline-functions causes FAIL: gcc.c-torture/execute/builtins/pr22237.c execution

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-04-18 16:26 ---
Created an attachment (id=20409)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20409&action=view)
reduced testcase (from gcc.c-torture/execute/builtins/pr22237.c)

Command line:
gcc -Os -fkeep-inline-functions pr43784.c && ./a.out


-- 


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

[Bug c++/43785] New: very basic regression in std::make_pair

[navin dot kumar at gmail dot com]

in GCC 4.4.2, the following compiles, but in GCC 4.5.0, it does not:
#include 
#include 

int main(int argc, char** argv)
{
uint32_t x = 1;
uint32_t y = 2;
std::make_pair(x, y);
return 0;
}

In GCC4.5.0 the error is:
test.cpp: In function ‘int main(int, char**)’:
test.cpp:8:40: error: no matching function for call to ‘make_pair(uint32_t&,
uint32_t&)’


-- 
   Summary: very basic regression in std::make_pair
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: navin dot kumar at gmail dot com


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

[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr

[janus at gcc dot gnu dot org]

--- Comment #6 from janus at gcc dot gnu dot org  2010-04-18 16:42 ---
(In reply to comment #5)
> What about pr42274? Is it a duplicate or not?

I don't think so.


-- 


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

[Bug c++/43785] very basic regression in std::make_pair

[navin dot kumar at gmail dot com]

--- Comment #1 from navin dot kumar at gmail dot com  2010-04-18 16:43 
---
Arguments: g++ -Wall -std=c++0x


-- 

navin dot kumar at gmail dot com changed:

   What|Removed |Added

 CC||navin dot kumar at gmail dot
   ||com
  Known to fail||4.5.0
  Known to work||4.4.2


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

[Bug fortran/41922] Diagnostic: No location shown for overlappingly initialized EQUIVALENCEd character vars

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2010-04-18 16:44 ---
Confirmed. Related to pr24978. Should probably be marked as blocking  pr31392
and pr33056.


-- 


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

[Bug fortran/41580] [OOP] SAME_TYPE_AS and EXTENDS_TYPE_OF - add compile-time simplifcation

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2010-04-18 16:47 ---
> Currently, only the run-time version is implemented.

So could the pr marked as NEW?


-- 


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

[Bug c++/9335] repeated diagnostic when maximum template depth is exceeded

[jason at gcc dot gnu dot org]

--- Comment #22 from jason at gcc dot gnu dot org  2010-04-18 17:09 ---
(In reply to comment #21)
> Is that ok or you would prefer the following?
> 
> /home/manuel/src/pr9335.C:2:36: error: template instantiation depth exceeds
> maximum of 1024 (use -ftemplate-depth= to increase the maximum) instantiating
> 'struct X<-0x00018>'
> /home/manuel/src/pr9335.C:2:36:   recursively instantiated from 'const int
> X::value'
> /home/manuel/src/pr9335.C:2:36:   recursively instantiated from 'const int
> X<1000>::value'
> /home/manuel/src/pr9335.C:4:17:   instantiated from here

I was thinking just

/home/manuel/src/pr9335.C:2:36:   recursively instantiated from 'const int
X<999>::value'
/home/manuel/src/pr9335.C:2:36:   instantiated from 'const int X<1000>::value'

I think seeing one iteration would make it clearer.


-- 


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

[Bug c/43781] [4.6 Regression] ice: verify_ssa failed

[rguenth at gcc dot gnu dot org]

-- 

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|NEW |ASSIGNED
   Last reconfirmed|2010-04-18 15:20:10 |2010-04-18 17:23:26
   date||


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

[Bug fortran/42353] [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...

[pault at gcc dot gnu dot org]

--- Comment #29 from pault at gcc dot gnu dot org  2010-04-18 17:24 ---
Subject: Bug 42353

Author: pault
Date: Sun Apr 18 17:24:35 2010
New Revision: 158492

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158492
Log:
2010-04-18  Paul Thomas  

PR fortran/42353
* resolve.c (resolve_structure_cons): Make the initializer of
the vtab component 'extends' the same type as the component.

2010-04-18  Paul Thomas  

PR fortran/42353
* gfortran.dg/class_14.f03: New test.


Added:
branches/fortran-dev/gcc/testsuite/gfortran.dg/class_14.f03
Modified:
branches/fortran-dev/gcc/fortran/resolve.c


-- 


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

[Bug fortran/42353] [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...

[pault at gcc dot gnu dot org]

--- Comment #30 from pault at gcc dot gnu dot org  2010-04-18 17:25 ---
Subject: Bug 42353

Author: pault
Date: Sun Apr 18 17:25:41 2010
New Revision: 158493

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158493
Log:
2010-04-18  Paul Thomas  

PR fortran/42353
* resolve.c (resolve_structure_cons): Make the initializer of
the vtab component 'extends' the same type as the component.

2010-04-18  Paul Thomas  

PR fortran/42353
* gfortran.dg/class_14.f03: New test.


Modified:
branches/fortran-dev/gcc/fortran/ChangeLog.fortran-dev
branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev


-- 


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

[Bug fortran/42353] [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...

[pault at gcc dot gnu dot org]

--- Comment #31 from pault at gcc dot gnu dot org  2010-04-18 17:29 ---
Fixed on fortran-dev.

Thanks for the report, Harald.

Paul


-- 


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

[Bug fortran/42353] [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...

[pault at gcc dot gnu dot org]

--- Comment #32 from pault at gcc dot gnu dot org  2010-04-18 17:29 ---
Hmmm better mark it as fixed

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr

[pault at gcc dot gnu dot org]

--- Comment #7 from pault at gcc dot gnu dot org  2010-04-18 17:33 ---
Created an attachment (id=20410)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20410&action=view)
Fix for the problem

This needs to be regtested but I believe it to be bombproof.

However, I should attempt to find out why the resolution is not being done else
where.

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


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

[Bug c++/9335] repeated diagnostic when maximum template depth is exceeded

[manu at gcc dot gnu dot org]

--- Comment #23 from manu at gcc dot gnu dot org  2010-04-18 17:40 ---
Oh, that is not very difficult to do. But notice that you will still get the
last line:

/home/manuel/src/pr9335.C:4:17:   instantiated from here

so we go from 11 to 3 lines. I think that is ok.

So go ahead, commit your patch and I will update mine to produce that.


-- 


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

[Bug lto/43786] New: lto crash and/or infinite loop

[baronchaos at ymail dot com]

- was trying to compile bc on gentoo
- lto1 process didnt finish after over an hour

- i "cat" as many c-files as possible into my.c and used resulting my.i

- different flags result in different reaction.

a)
x86_64-pc-linux-gnu-gcc -c -o my.o my.i -flto 
x86_64-pc-linux-gnu-gcc -c -o numeric.o numeric.i -flto -fshort-double
x86_64-pc-linux-gnu-gcc -o dc my.o numeric.o -flto

lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper:
/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.1-pre/x86_64-pc-linux-gnu-gcc returned
1 exit status
collect2: lto-wrapper returned 1 exit status


b)
x86_64-pc-linux-gnu-gcc -c -o my.o my.i -flto
x86_64-pc-linux-gnu-gcc -c -o numeric.o numeric.i -flto -O1
x86_64-pc-linux-gnu-gcc -o dc my.o numeric.o -flto -finline-small-functions

... infinite loop (or taking hours)


- x86_64-pc-linux-gnu-gcc -v

Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.1-pre/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.1-pre/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.5.1_pre/work/gcc-4.5.1-/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.1-pre
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1-pre/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.1-pre
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.1-pre/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.1-pre/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1-pre/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-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.5.1-pre/python
--disable-libgcj --enable-languages=c,c++,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo SVN'
--enable-lto --disable-checking
Thread model: posix
gcc version 4.5.1-pre 20100417 (prerelease) rev. 158475 (Gentoo SVN)


-- 
   Summary: lto crash and/or infinite loop
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baronchaos at ymail dot com
 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=43786

[Bug c++/43787] New: regression on copy-constructor of empty class

[navin dot kumar at gmail dot com]

The following code compiles & runs fine on GCC 4.4.2,  it compiles & segfaults
on GCC 4.5.0,  arguments: -std=c++0x -g -fno-inline
#include 
#include 
#include 

class empty_t {};
static_assert(std::is_empty::value, "sanity check");

int main(int argc, char** argv)
{
empty_t* x = NULL;
empty_t y = *x;
return 0;
}

Core stack trace:
Program terminated with signal 11, Segmentation fault.
#0  0x0040060b in main (argc=1, argv=0x7fff9ae7e848) at test.cpp:11
11  empty_t y = *x;


-- 
   Summary: regression on copy-constructor of empty class
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: navin dot kumar at gmail dot com


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

[Bug lto/43786] lto crash and/or infinite loop

[baronchaos at ymail dot com]

--- Comment #1 from baronchaos at ymail dot com  2010-04-18 17:54 ---
Created an attachment (id=20411)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20411&action=view)
my.i


-- 


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

[Bug lto/43786] lto crash and/or infinite loop

[baronchaos at ymail dot com]

--- Comment #2 from baronchaos at ymail dot com  2010-04-18 17:55 ---
Created an attachment (id=20412)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20412&action=view)
numeric.i


-- 


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

[Bug c++/43787] [4.5/4.6 Regression] regression on copy-constructor of empty class

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-04-18 18:13 ---
I'm not sure the testcase is valid.  We copy a single byte at 0.


-- 

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-04-18 18:13:57
   date||
Summary|regression on copy- |[4.5/4.6 Regression]
   |constructor of empty class  |regression on copy-
   ||constructor of empty class
   Target Milestone|--- |4.5.1


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

[Bug tree-optimization/43784] [4.6 Regression] -Os -fkeep-inline-functions causes FAIL: gcc.c-torture/execute/builtins/pr22237.c execution

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

[Bug tree-optimization/43783] [4.5 regression] -O -ftree-pre options compile libbid wrong

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-04-18 18:22 ---
This needs a testcase.  The libdecnumber code is a mess (and I can't find
an implementation for bid128_ext_fma()).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Target Milestone|--- |4.5.1


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

[Bug c++/43779] Parts of message not available for translation

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-04-18 18:24 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|translation |c++
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2010-04-18 18:24:42
   date||


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

[Bug other/39979] possible wrong code at all -0x levels.

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-04-18 18:30 ---
(In reply to comment #4)
> during analysis the boost::thread::start_thread() function which causes
> invalid writes detected by valgrind i've noticed that gcc-4.5 generates
> bigger and more complex code of this function with few more lock'ed opcodes.
> afaics gcc-4.5 produces some mess for boost::shared_ptr.
> could please someone look at this? it may be a missed optimization or other
> bug.

It seems to be a completely different implementation.

This bug lacks a testcase.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr

[pault at gcc dot gnu dot org]

--- Comment #8 from pault at gcc dot gnu dot org  2010-04-18 18:30 ---
(In reply to comment #6)
> (In reply to comment #5)
> > What about pr42274? Is it a duplicate or not?
> 
> I don't think so.
> 

My patch fixes pr42274 comment #9 but not the main part of it.  Janus is quite
right that the bugs are different.

The patch regtests OK, as expected.  I will do some investigating as to the
right place to do the resolution.  module.c does not look right :-)


Cheers

Paul
Cheers

Paul


-- 


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

[Bug c++/43787] [4.5/4.6 Regression] regression on copy-constructor of empty class

[navin dot kumar at gmail dot com]

--- Comment #2 from navin dot kumar at gmail dot com  2010-04-18 18:31 
---
Only GCC4.5.0 is emitting a copy-constructor that copies 1 byte of data
(probably because sizeof(empty_t) == 1 according to the C++ ABI).   The
copy-constructor *should* be a noop, and indeed GCC4.4.2 issues a noop for
copying empty classes.


-- 


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

[Bug c/43778] C/C++ __attribute__((deprecated)) does not appear to wrap declarations as implied from the doc.

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-04-18 18:32 ---
"warnings should be issued when a
deprecated entity is used and not when that deprecation is declared."

it is not "that" deprecation that is declared in your examples but "a"
deprecation that is declared.


-- 


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

[Bug c++/43787] [4.5/4.6 Regression] regression on copy-constructor of empty class

[navin dot kumar at gmail dot com]

--- Comment #3 from navin dot kumar at gmail dot com  2010-04-18 18:33 
---
At the very least, you'd agree that it's a performance bug to be copying bytes
from memory when the class is empty.  At the severe use-case, it breaks
existing code.


-- 


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

[Bug tree-optimization/43783] [4.5 regression] -O -ftree-pre options compile libbid wrong

[roman at binarylife dot net]

--- Comment #2 from roman at binarylife dot net  2010-04-18 18:34 ---
(In reply to comment #1)
> This needs a testcase.  The libdecnumber code is a mess (and I can't find
> an implementation for bid128_ext_fma()).
> 

bid128_ext_fma() is in libgcc/config/libbid/bid128_fma.c


-- 


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

[Bug other/39979] possible wrong code at all -0x levels.

[pluto at agmk dot net]

--- Comment #6 from pluto at agmk dot net  2010-04-18 19:01 ---
Created an attachment (id=20413)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20413&action=view)
testcase.#0.


-- 

pluto at agmk dot net changed:

   What|Removed |Added

  Attachment #20408|0   |1
is obsolete||


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

[Bug c++/43785] very basic regression in std::make_pair

[bangerth at gmail dot com]

--- Comment #2 from bangerth at gmail dot com  2010-04-18 19:02 ---
Confirmed. Including  doesn't help.


-- 

bangerth at gmail dot com changed:

   What|Removed |Added

 CC||bangerth at gmail dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-04-18 19:02:12
   date||


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

[Bug c/43778] C/C++ __attribute__((deprecated)) does not appear to wrap declarations as implied from the doc.

[iains at gcc dot gnu dot org]

--- Comment #3 from iains at gcc dot gnu dot org  2010-04-18 19:03 ---
(In reply to comment #2)
> "warnings should be issued when a
> deprecated entity is used and not when that deprecation is declared."
> 
> it is not "that" deprecation that is declared in your examples but "a"
> deprecation that is declared.

With that I agree  - however, my comment on the inconsistency of the semantics
remains.  

I appreciate that, since this is a gnu extension, there is no spec to follow.  
It is a question of what is most useful behavior.

At present:
typedef int INT1 __attribute__((deprecated));

INT1 func(void )__attribute__((deprecated));

produces no warning -- to me this makes sense - it is unimportant that INT1 is
deprecated, unless one tries to call "func()" in which case a warning is given
for the use of func().

At present, this produces a warning (C) for the argument:
INT1 func(INT1 )__attribute__((deprecated));

However, one asks what's the purpose of the warning?
func() is deprecated, a warning would be issued if one were to try and use
it...

===

In a practical sense - one could have deprecated interfaces in a header.
I would expect that those interfaces should not produce any warnings *unless* I
were to use them in my code.   

The fact that deprecated interface A depends on deprecated interface B is not
relevant unless one tries to use A.

or at least, that was my understanding of the intention of the behavior.

Incidentally, C++ does not produce a warning for INT1 func(INT1
)__attribute__((deprecated));


-- 


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

[Bug other/39979] possible wrong code at all -0x levels.

[pluto at agmk dot net]

--- Comment #7 from pluto at agmk dot net  2010-04-18 19:04 ---
(In reply to comment #5)
> (In reply to comment #4)
> > during analysis the boost::thread::start_thread() function which causes
> > invalid writes detected by valgrind i've noticed that gcc-4.5 generates
> > bigger and more complex code of this function with few more lock'ed opcodes.
> > afaics gcc-4.5 produces some mess for boost::shared_ptr.
> > could please someone look at this? it may be a missed optimization or other
> > bug.
> 
> It seems to be a completely different implementation.
> 
> This bug lacks a testcase.
> 

i've atatched the first testcase for this bug. gcc43 and gcc44/45 generate
completely different code for the boost::thread::start_thread function.


-- 


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

[Bug c/43781] [4.6 Regression] ice: verify_ssa failed

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-04-18 20:14 ---
Loop invariant motion breaks this.

 :
-  g_313.0_6 = pretmp.4_9;
-  *g_313.0_6 = 0B;

 :
   # m_21 = PHI <0(11), m_3(D)(2)>
+  g_313.8_12 = *g_313.0_6;
+  g_313.0_6 = pretmp.4_9;
   goto ;

we insert stmts not preserving ordering.


-- 


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

[Bug other/39979] possible wrong code at all -0x levels.

[pluto at agmk dot net]

--- Comment #8 from pluto at agmk dot net  2010-04-18 20:28 ---
debbuging 4.3 vs 4.5 start_thread() shows different results:

4.3:

182x void thread::start_thread()
183x {
184x thread_info->self=thread_info;
185t>int const res = pthread_create(&thread_info->thread_handle, 0,
&thread_proxy, thread_info.get());

(gdb) p *this->thread_info.pn.pi_
{
  _vptr.sp_counted_base = 0x7767e6d0,
  use_count_ = 1,
  weak_count_ = 2
}
(gdb) n
(gdb) p *this->thread_info.pn.pi_
{
  _vptr.sp_counted_base = 0x7767e6d0,
  use_count_ = 2,
  weak_count_ = 2
}

on 4.5:

(gdb) p *this->thread_info.pn.pi_
{
  _vptr.sp_counted_base = 0x7767ead0,
  use_count_ = 1,
  weak_count_ = 2
}
(gdb) n
(gdb) p *this->thread_info.pn.pi_
Cannot access memory at address 0x30

as you can see, the 4.5 code does bad things.


-- 


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

[Bug lto/43788] New: ICE: verify_stmts failed: statement marked for throw, but doesn’t

[zsojka at seznam dot cz]

Command line:
g++ -fwhopr -r -nostdlib -ftoplevel-reorder 20081204-1_1.C

--- 20081204-1_1.C ---
struct Foo { virtual ~Foo(); };
struct Bar:public Foo { Bar() { } };
void Func() { new Bar(); }
--
g++.dg/lto/20081204-1_1.C

Tested revisions:
r158486 - crash
r157877 - crash
4.5 r158486 - crash

Output:
$ /mnt/svn/gcc-trunk/binary-158486-lto-fortran/bin/g++ -fwhopr -r -nostdlib
-ftoplevel-reorder 20081204-1_1.C
In file included from :1:0:
20081204-1_1.C: In function 'Func':
20081204-1_1.C:3:6: error: statement marked for throw, but doesn't
__comp_ctor  (D.2138_3);

20081204-1_1.C:3:6: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto1: fatal error: /mnt/svn/gcc-trunk/binary-158486-lto-fortran/bin/g++
terminated with status 256
compilation terminated.
lto-wrapper: /mnt/svn/gcc-trunk/binary-158486-lto-fortran/bin/g++ returned 1
exit status
collect2: lto-wrapper returned 1 exit status

valgrind doesn't report any invalid access


-- 
   Summary: ICE: verify_stmts failed: statement marked for throw,
but doesn’t
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
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=43788

[Bug other/39979] possible wrong code at all -0x levels.

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-04-18 20:32 ---
(In reply to comment #8)
> debbuging 4.3 vs 4.5 start_thread() shows different results:
> 
> 4.3:
> 
> 182x void thread::start_thread()
> 183x {
> 184x thread_info->self=thread_info;
> 185t>int const res = pthread_create(&thread_info->thread_handle, 0,
> &thread_proxy, thread_info.get());
> 
> (gdb) p *this->thread_info.pn.pi_
> {
>   _vptr.sp_counted_base = 0x7767e6d0,
>   use_count_ = 1,
>   weak_count_ = 2
> }
> (gdb) n
> (gdb) p *this->thread_info.pn.pi_
> {
>   _vptr.sp_counted_base = 0x7767e6d0,
>   use_count_ = 2,
>   weak_count_ = 2
> }
> 
> on 4.5:
> 
> (gdb) p *this->thread_info.pn.pi_
> {
>   _vptr.sp_counted_base = 0x7767ead0,
>   use_count_ = 1,
>   weak_count_ = 2
> }
> (gdb) n
> (gdb) p *this->thread_info.pn.pi_
> Cannot access memory at address 0x30
> 
> as you can see, the 4.5 code does bad things.

it just means that the debugger uses a this variable which is currently NULL.
So maybe wrong-debug information.

The testcase is btw a too twisted maze.  Can you wrap up a simple main()
so that it fails at runtime?


-- 


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

[Bug other/39979] possible wrong code at all -0x levels.

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2010-04-18 20:33 
---
Oh, and does it fail with http://gcc.gnu.org/bugzilla/attachment.cgi?id=20394
applied?


-- 


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

[Bug middle-end/43654] Very long compile time with -O2 -floop-block

[zsojka at seznam dot cz]

--- Comment #2 from zsojka at seznam dot cz  2010-04-18 22:14 ---
-floop-block -fstrict-aliasing also makes
gfortran.fortran-torture/execute/forall_1.f90 to timeout at -O[123s]


-- 

zsojka at seznam dot cz changed:

   What|Removed |Added

   Keywords||compile-time-hog


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

[Bug c++/43787] [4.5/4.6 Regression] regression on copy-constructor of empty class

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-04-18 22:29 ---
This is invalid because you access a null pointer


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug c++/9335] [4.3/4.4/4.5/4.6 regression] repeated diagnostic when maximum template depth is exceeded

[jason at gcc dot gnu dot org]

--- Comment #24 from jason at gcc dot gnu dot org  2010-04-18 22:35 ---
We didn't get the error cascade in 2.95; we did in 3.4.  I don't have any
releases in between handy.


-- 

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|NEW |ASSIGNED
  Known to fail||3.4.6
  Known to work||2.95.4
   Last reconfirmed|2005-12-18 20:18:56 |2010-04-18 22:35:23
   date||
Summary|repeated diagnostic when|[4.3/4.4/4.5/4.6 regression]
   |maximum template depth is   |repeated diagnostic when
   |exceeded|maximum template depth is
   ||exceeded


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

[Bug c++/43787] [4.5/4.6 Regression] regression on copy-constructor of empty class

[navin dot kumar at gmail dot com]

--- Comment #5 from navin dot kumar at gmail dot com  2010-04-19 00:22 
---
Andrew,

What about the performance bug?

empty_t x; // line1
empty_t y = x;  // line2

Line2 should not result in copying memory for empty classes.  And that was the
old behavior pre-4.5.0


-- 


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

[Bug c++/43787] [4.5/4.6 Regression] regression on copy-constructor of empty class

[navin dot kumar at gmail dot com]

--- Comment #6 from navin dot kumar at gmail dot com  2010-04-19 00:22 
---
Andrew,

What about the performance bug?

empty_t x; // line1
empty_t y = x;  // line2

Line2 should not result in copying memory for empty classes.  And that was the
old behavior pre-4.5.0


-- 

navin dot kumar at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |


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

[Bug c++/43787] [4.5/4.6 Regression] memory copy of empty class (sizeof is one)

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2010-04-19 00:30 ---
Well at least change the summary to say what the issue is about.  There is
always a copy constructor for classes including POD in C++.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |minor
 Status|REOPENED|NEW
   Keywords||missed-optimization
Summary|[4.5/4.6 Regression]|[4.5/4.6 Regression] memory
   |regression on copy- |copy of empty class (sizeof
   |constructor of empty class  |is one)


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

[Bug c++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2010-04-19 01:06 ---
With C++0x we have:
  template
inline pair::__type,
  typename __decay_and_strip<_T2>::__type>
make_pair(_T1&& __x, _T2&& __y)

Which is correct that lvalues cannot be bound to rvalue reference variables.

So this is a libstdc++ bug if it is a bug at all.  See PR 40486 about the
change to C++ front-end and the changes done to the library part.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |libstdc++


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

[Bug c/43774] option -O2 generates wrong assembly code

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2010-04-19 01:08 ---
Just a littke more: alignof (struct _x_t) is 4 therefor so is the alignof(_x_t
::data).


-- 


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-04-19 02:06 
---
Andrew, the situation isn't *that* simple as you seem to believe, because
make_pair is *templatized*, thus in general it works perfectly well with
lvalues. For example, this works:

  std::make_pair/**/(x, y);

that is, the problem is with the *explicit* template arguments. As far as I can
see, this can be either invalid or a defect in the standard, because we are
implementing quite closely the letter of N3035. In general, the C++0x std::pair
is still in flux, and we should be very careful. And I disagree about
considering this a regression.


-- 


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2010-04-19 02:08 
---
Of course by "standard" I meant the current working draft, the FCD. We are in
the realm of the still *highly* experimental C++0x mode.


-- 


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2010-04-19 02:13 
---
In any case, Andrew is right (if I understand correctly the gist of his
message), that a conforming implementation of the FCD can *only* fail to
compile the provided snippet *when* the types are explicitely provided like
that: we boil down to uint32_t&& which *cannot* bind to an lvalue.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC|navin dot kumar at gmail dot|
   |com |


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

[Bug c/43774] option -O2 generates wrong assembly code

[dirtysalt1987 at gmail dot com]

--- Comment #7 from dirtysalt1987 at gmail dot com  2010-04-19 02:25 ---
(In reply to comment #6)
> Just a littke more: alignof (struct _x_t) is 4 therefor so is the alignof(_x_t
> ::data).
> 
3ku very much,with your explanation I think I can understand it..3ku very much.


-- 


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

[Bug c++/43789] New: warn about pointer aritmetic in sizeof

[aep at exys dot org]

Gcc already contains useful warnings for almost certainly incorrect code. I
propose adding a warning when pointer arithmetic is used inside sizeof, that
degrades an array to a pointer.


char a[]="blabla";
sizeof(a-1);

If the intention was _actually_ to get sizeof(char), it is a really awful way
to do so. Instead, it is very likely a typo.
Hence i suggest adding a warning.
thanks.


-- 
   Summary: warn about pointer aritmetic in sizeof
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aep at exys dot org


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

[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair

[bangerth at gmail dot com]

--- Comment #7 from bangerth at gmail dot com  2010-04-19 02:59 ---
I think the point Andrew wanted to make is that it's a regression
*from the user perspective*. I had a half dozen places in our code
that now no longer compile in c++0x mode. Apparently others do too.

If the standard is not finished yet, I would think it rather useful
if we could implement something that is at least backward compatible.
In my eyes, the fact that we reject working code from previous standards
is a defect in the current draft.

W.


-- 


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

[Bug tree-optimization/43783] [4.5 regression] -O -ftree-pre options compile libbid wrong

[roman at binarylife dot net]

--- Comment #3 from roman at binarylife dot net  2010-04-19 04:25 ---
Starting from r150519 gcc compiles its own internal libbid wrong.

With the previous revision of gcc, the output of the above test.c is correct:

$ gcc -O test.c && ./a.out
ab=1.23457e-158
xy=1.23457e-158


-- 


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

[Bug c++/43790] New: In lambda express, calling member function of non-captured class gives internal compiler error

[darlingm at gmail dot com]

The below at the bottom of this comment gives:

/usr/local/bin/g++ -v -save-temps -std=gnu++0x -o
CMakeFiles/gccError.dir/gccError.cpp.o -c
/home/darlingm/code.gccerror/testing/gccError/gccError.cpp

Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
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-multilib --enable-language=c,c++
--disable-nls
Thread model: posix
gcc version 4.6.0 20100418 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu++0x' '-o'
'CMakeFiles/gccError.dir/gccError.cpp.o' '-c' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -E -quiet -v
-D_GNU_SOURCE /home/mdarling/code.gccerror/testing/gccError/gccError.cpp
-mtune=generic -march=x86-64 -std=gnu++0x -fpch-preprocess -o gccError.ii
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/x86_64-unknown-linux-gnu

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/backward
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu++0x' '-o'
'CMakeFiles/gccError.dir/gccError.cpp.o' '-c' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -fpreprocessed
gccError.ii -quiet -dumpbase gccError.cpp -mtune=generic -march=x86-64
-auxbase-strip CMakeFiles/gccError.dir/gccError.cpp.o -std=gnu++0x -version -o
gccError.s
GNU C++ (GCC) version 4.6.0 20100418 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20100418 (experimental), GMP version
4.3.1, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.6.0 20100418 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20100418 (experimental), GMP version
4.3.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: 7af0c1b1da9d8e649a58d85fd58b2bfb
/home/mdarling/code.gccerror/testing/gccError/gccError.cpp: In lambda function:
/home/mdarling/code.gccerror/testing/gccError/gccError.cpp:25:14: error:
'classInstance' is not captured
/home/mdarling/code.gccerror/testing/gccError/gccError.cpp:26:4: internal
compiler error: tree check: expected class 'type', have 'exceptional'
(error_mark) in cv_unqualified, at cp/tree.c:937
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.



The original internal compiler error was of course in a much larger project,
and had a bunch of other code errors on it being the first compile attempt.  I
got tunnel visioned at the first sight of an internal compiler error and spent
hours re-checking out the svn gcc source and recompiling, in case my svn
version from a week ago had a fixed bug in it.

After removing irrelevant portions of the program to get down to a small test
case, it appears that calling a member function of a non-captured class gives
an internal compiler error.  Properly changing the lambda expression line to
"function lambdaExpression = [&classInstance] () {" prevents the
internal compiler error.

I know it's invalid c++0x code that's causing the internal compiler error, but
removing the internal compiler error and only showing the message "error:
'classInstance' is not captured" might save someone else a few hours who gets
tunnel visioned on the one error.  :)


==
#include 
#include 
#include 
using namespace std;

class theClass {
   public:
  theClass();
  string getA();
   private:
  string a;
};

theClass::theClass() 
: a("theData") {
}

string theClass::getA() {
   return a;
}

int main() {
   theClass classInstance;
   function lambdaExpression = [] () {
  return classInstance.getA();
   }; 
   cout << lambdaExpression() << endl;
}


-- 
   Summary: In lambda express, calling member function of non-
captured class gives internal compiler error
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: darlingm at gmail dot com


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

[Bug tree-optimization/43771] [4.5/4.6 Regression] ICE on valid when compiling ParMetis with gcc 4.5.0 and -O3

[irar at gcc dot gnu dot org]

--- Comment #5 from irar at gcc dot gnu dot org  2010-04-19 06:02 ---
Subject: Bug 43771

Author: irar
Date: Mon Apr 19 06:02:27 2010
New Revision: 158503

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

PR tree-optimization/43771
* tree-vect-slp.c (vect_supported_load_permutation_p): Check that
load permutation doesn't have gaps.


Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/vect/pr43771.cc
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/tree-vect-slp.c


-- 


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

[Bug tree-optimization/43771] [4.5/4.6 Regression] ICE on valid when compiling ParMetis with gcc 4.5.0 and -O3

[irar at gcc dot gnu dot org]

--- Comment #6 from irar at gcc dot gnu dot org  2010-04-19 06:18 ---
Subject: Bug 43771

Author: irar
Date: Mon Apr 19 06:17:56 2010
New Revision: 158504

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

PR tree-optimization/43771
* tree-vect-analyze.c (vect_supported_load_permutation_p): Check
that load permutation doesn't have gaps.


Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/vect/pr43771.cc
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-vect-analyze.c


-- 


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

[Bug other/43791] New: kernel/rtmutex.c:1138:1: internal compiler error: in cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009

[justinmattock at gmail dot com]

building the latest kernel(2.6.34-rc4-00082-g250541f)
I'm hitting this:

kernel/rtmutex.c: At top level:
kernel/rtmutex.c:1138:1: internal compiler error: in
cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[1]: *** [kernel/rtmutex.o] Error 1
make: *** [kernel] Error 2

as for gcc etc.. the only patch that I applied was the pure64 patch from:
http://patches.cross-lfs.org/dev/gcc-4.4.2-pure64-1.patch


-- 
   Summary: kernel/rtmutex.c:1138:1: internal compiler error: in
cgraph_decide_inlining_of_small_functions, at ipa-
inline.c:1009
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: justinmattock at gmail dot com
 GCC build triplet: x86_64


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