[Bug c++/48859] [4.6/4.7 Regression] incorrect "uninitialized const member" error on new without new-initializer

[fabien at gcc dot gnu.org]

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

--- Comment #10 from fabien at gcc dot gnu.org 2011-05-11 06:03:42 UTC ---
Author: fabien
Date: Wed May 11 06:03:38 2011
New Revision: 173644

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

2011-05-11  Fabien Chene  
PR c++/48859
* init.c (diagnose_uninitialized_cst_or_ref_member_1): stop the
recursion if there is user defined constructor.

gcc/testsuite/ChangeLog:

2011-05-11  Fabien Chene  
PR c++/48859
* g++.dg/init/pr48859.C: New.


Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/init/pr48859.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/init.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/46865] [4.3 Regression] Using -save-temps (or ccache, distcc) produces different results with multiline macros containing asm code

[feedback at launchpad dot net]

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

--- Comment #10 from Launchpad  2011-05-11 
04:22:42 UTC ---
Christian Reis added the following comment to Launchpad bug report 687406:

Is this bug now resolved, or is it pending any other backports?

-- 
http://launchpad.net/bugs/687406

[Bug preprocessor/48957] New: GCC's handling of include-fixed does not work well with --sysroot

[psmith at gnu dot org]

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

   Summary: GCC's handling of include-fixed does not work well
with --sysroot
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: psm...@gnu.org


When GCC builds, it creates and stows away internally an "include-fixed"
directory containing "fixed-up" versions of the system headers files on the
system it was built with.  This feels wrong to me: it gives GCC a hard
dependency on the specific set of system header files present when GCC was
built.  It's potentially incorrect even for straightforward installations,
where a newer header file provided with a package upgrade might be ignored in
preference to an older "fixed" version.  However, when attempting to create a
relocatable version of GCC it's even more problematic.

In particular, it seems very wrong (and, in fact, it often doesn't work) to
search the include-fixed directory when the user has specified a --sysroot
flag, choosing to compile against a wholly different set of headers and
libraries than the ones on the host system.

I think that the include-fixed directory should be associated with the sysroot,
somehow, not embedded deeply into the compiler internals, and when --sysroot is
provided there should be a well-known location inside the sysroot which will be
searched for include-fixed headers.

Also, the fixinc.sh script should be better documented and enhanced to be
simpler to run, so that it can be invoked more easily against a given sysroot
to construct the include-fixed directory for that sysroot.

[Bug target/47755] VSX code generates a TOC reference to clear memory

[amodra at gcc dot gnu.org]

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

--- Comment #10 from Alan Modra  2011-05-11 04:29:21 
UTC ---
Author: amodra
Date: Wed May 11 04:29:13 2011
New Revision: 173643

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173643
Log:
PR target/47755
* gcc.target/powerpc/pr47755-2.c: Require vsx_hw.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr47755-2.c

[Bug middle-end/48953] [4.7 Regression] ICE: verify_gimple failed: type mismatch in array reference with -flto and struct with vararray

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.11 04:01:47
 CC||matz at gcc dot gnu.org
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2011-05-11 04:01:47 
UTC ---
It is caused by revision 172516:

http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00711.html

[Bug lto/48954] [4.7 Regression] ICE: SIGSEGV in bitmap_count_bits (bitmap.c:719) with -O2 -flto -fno-early-inlining -fkeep-inline-functions

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.11 03:11:56
 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2011-05-11 03:11:56 
UTC ---
It is caused by revision 172914:

http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg01110.html

[Bug c/48956] New: -Wconversion should warn when a complex value is assigned to a real result

[stevenj at alum dot mit.edu]

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

   Summary: -Wconversion should warn when a complex value is
assigned to a real result
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: stev...@alum.mit.edu


Consider the following C snippet:

  #include 
  double foo(complex double x) {
 return x;
  }

This is valid C code: it assigns the complex "x" value to the real result of
"foo", which implicitly returns the real part of "x".  However, the implicit
conversion from complex to real has altered a value by discarding the imaginary
part of x.  Therefore, I would expect -Wconversion to issue a warning.

Compiling this with "gcc -c -Wconversion foo.c" issues no warning, however, nor
can I find any other -W option that causes a warning to be emitted.

Please consider issuing a warning when implicitly converting complex to real
(NOT the reverse) on -Wconversion.  (In fact, -Wconversion already does this in
Fortran as noted below.)

A warning for this type of conversion would be very helpful, since silently
discarding the imaginary part in this way often indicates a bug in my
experience.  (One can come up with many similar examples, e.g. writing sqrt(x)
rather than csqrt(x) currently silently succeeds for complex x, again
discarding the imaginary part.)  If the programmer meant to take the real part,
she probably would have written "creal(x)" explicitly.

Regards,
Steven G. Johnson

PS. Note -Wconversion already DOES emit a warning for conversion to complex to
real in gfortran.  e.g.

  subroutine foo(z)
  complex z
  real x
  x = z
  write(*,*) x
  return
  end

compiles without error with gfortran -c, but gfortran -c -Wconversion emits:

  x = z 
 1
Warning: Conversion from COMPLEX(4) to REAL(4) at (1)

[Bug c/48956] -Wconversion should warn when a complex value is assigned to a real result

[stevenj at alum dot mit.edu]

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

--- Comment #1 from stevenj at alum dot mit.edu 2011-05-11 00:01:32 UTC ---
PPS. I have reproduced this problem in gcc versions 3.3.6, 3.4.6, 4.1.3, 4.3.2,
and 4.6.0 running on an x86_64 Debian GNU/Linux system.

[Bug c/48951] probably, it is a bug.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Resolution|INVALID |WORKSFORME

--- Comment #6 from Paolo Carlini  2011-05-10 
22:21:06 UTC ---
Let's close this more correctly as WORKSFORME: for sure no currently active
branch is affected by such a devastating bug.

[Bug c++/48930] [C++0x] Invalid implicitly declared default c'tor

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0

--- Comment #8 from Jason Merrill  2011-05-10 
21:09:54 UTC ---
Fixed.

[Bug c++/48736] [C++0x] ICE during list-initialization with variadics

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0

--- Comment #2 from Jason Merrill  2011-05-10 
21:13:17 UTC ---
Fixed.

[Bug fortran/48955] [4.6/4.7 Regression] Wrong result for array assignment due to missing temporary

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

  Known to work||4.3.4, 4.4.0, 4.5.3
   Target Milestone|--- |4.6.1
  Known to fail||4.1.2, 4.6.0, 4.7.0

--- Comment #1 from Tobias Burnus  2011-05-10 
21:10:10 UTC ---
Works: 2010-08-02  r162824  cca7236e5fabb3791d494683d1f53f3c09d545e5
Fails: 2010-08-02  r162829  644e9dad11b9ba317bd11726569b5d8bc648950f

Thus, the culprit is:

New Revision: 162829
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162829

2010-08-02  Thomas Koenig  

PR fortran/45159
* depencency.c (gfc_dep_resolver):  Fix logic for when a loop
can be reversed.

2010-08-02  Thomas Koenig  

PR fortran/45159
* gfortran.dg/dependency_29.f90:  New test.

[Bug lto/48952] ICE in inline_merge_summary during linux kernel LTO build

[andi-gcc at firstfloor dot org]

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

--- Comment #2 from Andi Kleen  2011-05-10 
20:49:28 UTC ---
I uploaded a (large) test case to 
http://firstfloor.org/~andi/lto-kernel.tar.bz2

Run R2 in the directory after pointing the script to the right gcc binary.

[Bug fortran/48955] New: [4.6/4.7 Regression] Wrong result for array assignment due to missing temporary

[burnus at gcc dot gnu.org]

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

   Summary: [4.6/4.7 Regression] Wrong result for array assignment
due to missing temporary
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: critical
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: pa...@gcc.gnu.org, tkoe...@gcc.gnu.org


As reported on IRC.

The following program should print:

-10. -20. -20. -10.  10.  20.  20.  10. 
-10. -20. -20. -10.  10.  20.  20.  10. 


It does so with gfortran 4.3.4, 4.4.0, 4.5.3, ifort, NAG. However, using
gfortran 4.6.0, 4.7.0 (and for that matter 4.1.2) the first line is wrong:

-10. -20. -25. -17.5000   6.2500  18.1250  24.0625  10.
-10. -20. -20. -10.  10.  20.  20.  10.


program ala
   implicit none

   integer, parameter  :: n = 8
   real, dimension(n) :: v0, v1

   v0 = [-10.0, -10., -10., -10., 10., 10., 10., 10.]
   v1 = v0

   v1(2:n-1) = 0.5*(v1(1:n-2) + v1(3:n) + 2.0*v1(2:n-1))
   write(*,'(8(F8.4,1X))') v1
   v1 = v0
   v1(2:n-1) = 0.5*(v0(1:n-2) + v0(3:n) + 2.0*v0(2:n-1))
   write(*,'(8(F8.4,1X))') v1
end program ala


First regression hunting shows:
  Works: 2010-07-16-r162255
  Fails: 2010-08-28-r163612

[Bug libfortran/48950] a patch from 4.4.x not backported to 4.3.x

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution||WONTFIX

--- Comment #8 from kargl at gcc dot gnu.org 2011-05-10 20:03:46 UTC ---
(In reply to comment #5)
> OK, if everything is backported you get the current version... I agree this
> does not make sense. But this has a maintained status, which gives people a
> false sense of security.

Given Tobias's comment 1, which indicates that this would
be a large intrusive patch with the potential of causing
other problems, and given the limited available resources
(gfortran developers and hours in a day), I'll suggest that
you may have an unrealistic expectation of the word "maintained".

[Bug libfortran/48950] a patch from 4.4.x not backported to 4.3.x

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  2011-05-10 
19:23:57 UTC ---
4.5 may be a test version as far as Cygwin folks downstream of us, but 4.5 and
4.6 are "Released" and perfectly useable from our view from here. Both are
better than any of the older versions as far as we know. (ie many bugs fixed
since)

I hope that you can upgarde to a more current version.

[Bug libfortran/48950] a patch from 4.4.x not backported to 4.3.x

[sliwa at blue dot cft.edu.pl]

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

--- Comment #6 from Cezary Sliwa  2011-05-10 
19:11:22 UTC ---
PS. The gfortran version of ACML 4.4.0 appears to be built with 4.3.x.

[Bug libfortran/48950] a patch from 4.4.x not backported to 4.3.x

[sliwa at blue dot cft.edu.pl]

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

--- Comment #5 from Cezary Sliwa  2011-05-10 
19:08:34 UTC ---
OK, if everything is backported you get the current version... I agree this
does not make sense. But this has a maintained status, which gives people a
false sense of security. You build all the libraries, then the application does
not work. It rather could be nice to take a look what had been wrong in the old
version, and I don't know how to do it (as you mentioned the patch is large).

Cygwin has 4.5 as a test version, installing it takes a click. But still, it is
a test version.

Nightly build of gfortran did not work for me (it failed to compile LAPACK if I
remember correctly).

[Bug c/48951] probably, it is a bug.

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-05-10 
18:33:13 UTC ---
it works correctly for me

you need to provide the "What we need" info requested at
http://gcc.gnu.org/bugs/ (no need for preprocessed source) and try with a
current version of the compiler

[Bug c/48951] probably, it is a bug.

[ufo008ahw at 163 dot com]

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

--- Comment #4 from ufo008ahw  2011-05-10 18:11:04 
UTC ---
(In reply to comment #3)
> So, your expectations are wrong, because of course 4 < 1 is false, thus 0 as 
> an
> integer.

??
my expectation is (4 < 1) output 0. but program output 1

[Bug libfortran/48950] a patch from 4.4.x not backported to 4.3.x

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2011-05-10 
18:16:41 UTC ---
(In reply to comment #2)
> 4.4 is available in cygwin. Just search through the setup and you will see it
> listed with 4.4 appended to the name, something like gfortran-4.4.

(In reply to comment #3)
> I am mistaken.

As written in comment 1, there are official GCC 4.5.0 binaries. I do not know
how they integrate into the package manager of Cygwin, but one can at least
download them from the official FTP server. I wouldn't be surprised if those
will install the compiler as "gfortran-4.5".

As libgfortran of GCC 4.5 is backward compatible with GCC 4.3/4.4, you could
consider to just install the newer library. But you could also use the newer
version of the compiler. For the new features, cf.
http://gcc.gnu.org/wiki/GFortran#news

[Bug rtl-optimization/48374] ICE: in single_succ_edge, at basic-block.h:562 with -fselective-scheduling2 and __builtin_unreachable()

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  2011-05-10 18:05:57 
UTC ---
Thanks for the suggestion, Andrey. Using lower values for --param
max-sched-extend-regions-iters might reduce the compilation time in some cases.

I tested your patch on top of r173588 and it fixes the ICE on all testcases I
have.

[Bug c++/48930] [C++0x] Invalid implicitly declared default c'tor

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  2011-05-10 
17:58:49 UTC ---
Author: jason
Date: Tue May 10 17:58:46 2011
New Revision: 173628

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173628
Log:
PR c++/48930
* class.c (type_build_ctor_call): New.
* cp-tree.h: Declare it.
* decl.c (check_initializer): Use it instead of
TYPE_NEEDS_CONSTRUCTING.
* init.c (build_value_init, build_value_init_noctor): Likewise.
(perform_member_init, expand_aggr_init_1, build_new_1): Likewise.
(build_vec_init): Likewise.
* typeck2.c (process_init_constructor_array): Likewise.
(process_init_constructor_record): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/defaulted25.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/init.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/template/crash7.C

[Bug c++/48736] [C++0x] ICE during list-initialization with variadics

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2011-05-10 
17:58:41 UTC ---
Author: jason
Date: Tue May 10 17:58:38 2011
New Revision: 173627

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173627
Log:
PR c++/48736
* pt.c (tsubst_copy_and_build): Handle substitution of a pack
expansion producing another expansion.

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

[Bug c/48951] probably, it is a bug.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #3 from Paolo Carlini  2011-05-10 
17:47:04 UTC ---
So, your expectations are wrong, because of course 4 < 1 is false, thus 0 as an
integer.

[Bug middle-end/48954] New: [4.7 Regression] ICE: SIGSEGV in bitmap_count_bits (bitmap.c:719) with -O2 -flto -fno-early-inlining -fkeep-inline-functions

[zsojka at seznam dot cz]

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

   Summary: [4.7 Regression] ICE: SIGSEGV in bitmap_count_bits
(bitmap.c:719) with -O2 -flto -fno-early-inlining
-fkeep-inline-functions
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 24220
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24220
reduced testcase

Compiler output (run under valgrind):
$ g++ -O2 -flto -fno-early-inlining -fkeep-inline-functions testcase.C
==3584== 
==3584== Invalid read of size 8
==3584==at 0x507DE6: bitmap_count_bits (bitmap.c:719)
==3584==by 0x7491C2: output_cgraph (lto-cgraph.c:1591)
==3584==by 0x759C91: lto_output (lto-streamer-out.c:)
==3584==by 0x7940E2: ipa_write_optimization_summaries_1 (passes.c:1760)
==3584==by 0x794C2F: ipa_write_optimization_summaries (passes.c:1806)
==3584==by 0x4F59DA: lto_main (lto.c:1996)
==3584==by 0x880F69: toplev_main (toplev.c:570)
==3584==by 0x644AB6C: (below main) (in /lib64/libc-2.11.3.so)
==3584==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==3584== 
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r173586 - crash
4.6 r173059 - OK (yes,rtl,df checking)

[Bug target/48495] ICE in in reload_cse_simplify_operands

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Michael Meissner  2011-05-10 
17:23:35 UTC ---
The fix for 48857 (subversion id 173624) is believed to fix this bug as well.

[Bug middle-end/48953] New: [4.7 Regression] ICE: verify_gimple failed: type mismatch in array reference with -flto and struct with vararray

[zsojka at seznam dot cz]

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

   Summary: [4.7 Regression] ICE: verify_gimple failed: type
mismatch in array reference with -flto and struct with
vararray
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 24219
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24219
reduced testcase

Compiler output:
$ gcc -O -flto -fno-tree-dce testcase.c 
In file included from :0:0:
testcase.c: In function 'main':
testcase.c:11:5: error: type mismatch in array reference
struct S

struct S

# .MEM_11 = VDEF <.MEM_10>
MEM[(struct S[2] *)s.1_7][0]{lb: 0 sz: 12}.value = 0;

testcase.c:11:5: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /mnt/svn/gcc-trunk/binary-latest/bin/gcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status

Tested revisions:
r173586 - crash
4.6 r173059 - OK (yes,rtl,df checking)

[Bug c/48951] probably, it is a bug.

[ufo008ahw at 163 dot com]

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

--- Comment #2 from ufo008ahw  2011-05-10 17:26:31 
UTC ---
(In reply to comment #1)
> (gcc 3.4.2 is ancient, even if there is a bug noone will fix it in that
> version)
> 
> what is the program's input?
> what is its output?
> what output are you expecting?

input is 1。
output is:
1

1
1

1
0

expected output is:
1

1
0

1
0

so, the difference is forth line.

[Bug c++/48948] [C++0x] constexpr friend function cannot be defined in-class

[schaub.johannes at googlemail dot com]

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

--- Comment #6 from Johannes Schaub  
2011-05-10 17:20:31 UTC ---
(In reply to comment #4)
> (In reply to comment #0)
> > gcc 4.7.0 20110507 (experimental) in C++0x mode rejects the following code 
> > at
> > the line marked with #:
> > 
> > //---
> > struct B {
> >   friend constexpr int f(B) { return 0; } // #
> > };
> > //---
> > 
> > "error: invalid type for parameter 1 of constexpr function 'constexpr int
> > f(B)'"
> > 
> > This code should be accepted. 
> > 
> 
> I remember that Gaby (I hope I remember correctly, hehe) argued that the body
> of "f" is late-parsed. Hence, the argument, until after the end of definition
> of "B", "f" is only considered declared but not defined.
> 
> I don't share that view though. That view is an implementation detail. In the
> language, the function marked by "#" is defined as soon as its body has been
> completely seen. If something else is intended, the specification needs to be
> explicit about this. Unless I've missed the text, it is not explicit about
> that.

But I can live with that. Having remembered the intent as described, I see that
the friend function you already showed is valid, because when the body is late
parsed, and the function is then considered defined only when the enclosing
class is complete, it makes sense. I wouldn't intuitively get to this result
though, but I think it's an interpretation I can live with!

I'm sorry for that load of nonsense in the comment boxes. I promise this is the
last comment in this row of this PR! :)

[Bug target/48857] V2DI arguments are not passed like other vectors

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Michael Meissner  2011-05-10 
17:21:48 UTC ---
Fixed in subversion revision 173624.

[Bug libfortran/48950] a patch from 4.4.x not backported to 4.3.x

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  2011-05-10 
17:12:30 UTC ---
I am mistaken.  However you can get fairly recent Cygwin (or MingW):

http://gcc.gnu.org/wiki/GFortranBinaries

[Bug libfortran/48906] Wrong rounding results with -m32

[thenlich at users dot sourceforge.net]

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

--- Comment #4 from Thomas Henlich  
2011-05-10 17:16:47 UTC ---
Way to go! I'll be happy to test.

[Bug c++/48948] [C++0x] constexpr friend function cannot be defined in-class

[schaub.johannes at googlemail dot com]

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

--- Comment #5 from Johannes Schaub  
2011-05-10 17:07:30 UTC ---
(In reply to comment #4)
> (In reply to comment #0)
> > gcc 4.7.0 20110507 (experimental) in C++0x mode rejects the following code 
> > at
> > the line marked with #:
> > 
> > //---
> > struct B {
> >   friend constexpr int f(B) { return 0; } // #
> > };
> > //---
> > 
> > "error: invalid type for parameter 1 of constexpr function 'constexpr int
> > f(B)'"
> > 
> > This code should be accepted. 
> > 
> 
> I remember that Gaby (I hope I remember correctly, hehe) argued that the body
> of "f" is late-parsed. Hence, the argument, until after the end of definition
> of "B", "f" is only considered declared but not defined.
> 

Consider also this, which I think demonstrates that position:

struct A {
  struct B;
  void f(B) { }
  struct B { };
};

I think this is ill-formed by the spec, because "B" is incomplete in f's
parameter and f is defined at that point. And this is not one of the contexts
that B is allowed to be incomplete by 8.3.5p9.

However, clang, gcc and comeau online all accept this. Apparently, they
consider "f" only declared and not defined.

I would be glad if someone points me to the rule that says that "f" is only
considered defined at the closing "}" of A though.

[Bug c++/48948] [C++0x] constexpr friend function cannot be defined in-class

[schaub.johannes at googlemail dot com]

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

--- Comment #4 from Johannes Schaub  
2011-05-10 16:59:50 UTC ---
(In reply to comment #0)
> gcc 4.7.0 20110507 (experimental) in C++0x mode rejects the following code at
> the line marked with #:
> 
> //---
> struct B {
>   friend constexpr int f(B) { return 0; } // #
> };
> //---
> 
> "error: invalid type for parameter 1 of constexpr function 'constexpr int
> f(B)'"
> 
> This code should be accepted. 
> 

I remember that Gaby (I hope I remember correctly, hehe) argued that the body
of "f" is late-parsed. Hence, the argument, until after the end of definition
of "B", "f" is only considered declared but not defined.

I don't share that view though. That view is an implementation detail. In the
language, the function marked by "#" is defined as soon as its body has been
completely seen. If something else is intended, the specification needs to be
explicit about this. Unless I've missed the text, it is not explicit about
that.

[Bug c/48951] probably, it is a bug.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.05.10 16:53:39
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-05-10 
16:53:39 UTC ---
(gcc 3.4.2 is ancient, even if there is a bug noone will fix it in that
version)

what is the program's input?
what is its output?
what output are you expecting?

[Bug libfortran/48950] a patch from 4.4.x not backported to 4.3.x

[jvdelisle at gcc dot gnu.org]

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

--- Comment #2 from Jerry DeLisle  2011-05-10 
16:39:28 UTC ---
4.4 is available in cygwin. Just search through the setup and you will see it
listed with 4.4 appended to the name, something like gfortran-4.4.

[Bug lto/48938] [4.7 Regression] ICE: in lto_wpa_write_files, at lto/lto.c:1992 with -O -flto --param lto-min-partition=1

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  2011-05-10 16:40:46 
UTC ---
Thanks for the reply. You are right, the assert described in PR48246 is at the
same place. However, I have 4.6 configured with --enable-checking=yes,rtl,df -
so checking_assert() should be triggered.

[Bug c++/48948] [C++0x] constexpr friend function cannot be defined in-class

[schaub.johannes at googlemail dot com]

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

--- Comment #3 from Johannes Schaub  
2011-05-10 16:46:18 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> 
> I don't think that this is intended, but I would like to await feedback from
> the developer group before submitting a corresponding core issue. IMO there 
> are
> some core wordings in regard to type completeness that are not intended to be
> read strictly, e.g. 3.2 p.4
> 
> "— a function with a return type or argument type of type T is defined (3.1)
> [..]"
> 
> can be read to disallow any of the following function definitions:
> 
> struct A {
>   A f(A a) { return a; }
>   friend A g(A a) { return a; }
> };
> 
> I haven't seen a compiler who rejects this code, because they all contribute
> more weight to 9.2 p.2. 

Within "A a" (the parameters) and within "A f" / "A g" (the return types), the
class A is incomplete. Only within the function bodies, the class A is complete
by 9.2p2. 

The compilers accept that code because of 8.3.5p9. 3.2 p4 is a non-normative
big note, which can impossibly achieve the precision of covering every detail.
It only provides a rough description.

[Bug lto/48952] ICE in inline_merge_summary during linux kernel LTO build

[andi-gcc at firstfloor dot org]

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

--- Comment #1 from Andi Kleen  2011-05-10 
16:37:17 UTC ---
Some more information from gdb. So it follows some pointer in the VEC
that is NULL

(gdb) p edge
$1 = (struct cgraph_edge *) 0x7f1ce05d90d0
(gdb) p edge->uid
$2 = 38701
(gdb) disp/3i $pc
1: x/3i $pc
=> 0x859bdc : mov0x8(%rbx,%rdx,1),%ecx
   0x859be0 : test   %ecx,%ecx
   0x859be2 :
je 0x859cdb 
(gdb) p $rbx
$3 = 0
(gdb) p $rdx
$4 = 619216
(gdb)

[Bug libfortran/48950] a patch from 4.4.x not backported to 4.3.x

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org,
   ||jvdelisle at gcc dot
   ||gnu.org

--- Comment #1 from Tobias Burnus  2011-05-10 
16:28:25 UTC ---
> It is not clear to me to what extent I can mix libgfortran from
> different versions of GCC.

In principle, the libgfortran is downward compatible - as long as the library
version remains the same:
- GCC 4.1 has libgfortran.so.1
- GCC 4.2 has libgfortran.so.2
- GCC 4.3/4.4/4.5/4.6/4.7 have libgfortran.so.3

Thus, a program compiled with 4.3 should work with libgfortran
4.3/4.4/4.5/4.6/4.7, a program compiled with 4.4 should work with libgfortran
4.4/4.5/4.6/4.7 etc.


> As the 4.3.x series are still maintained (and used, e.g., in Cygwin),
> I would like to ask about backporting to 4.3.x.

The commit is: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00864.html
That's a rather huge patch, which completely modifies the I/O system and fixes
the bugs PR 22423, PR 25561, PR 37754, PR 38654, PR 38668, PR 39664, PR 39665,
PR 39667, PR 39702, PR 39709 and PR 39782.

As the patch is rather large, I don't think it makes sense to backport it. The
chance that something breaks is rather high compared to the benefit.
Especially, as it does not seem to be a simple regression fix.

I am also not sure that how likely it is that the patch ends up in some vendor
version - I think most vendors try to be very conservative with old versions
and rather add technical previews than modifying the old version.

Regarding Cygwin: The last version I have seen was 4.5.0,
cf. http://ftp.gwdg.de/pub/linux/sources.redhat.com/cygwin/release/gcc4/
Though, admittedly, Cygwin seems to still maintain 4.3.x (file modification
date 22 March 2011); however, the file name "gcc4-4.3.4-4.tar.bz2" indicates
that it is based on 4.3.4, which was released 2009-08-04. Thus, they do not
include the fixes of 4.3.5 released 2010-05-22 - nor changes which were
committed afterwards to the branch.

(Actually, I also do not understand why they have only 4.5.0 and not the .1, .2
or .3 release - usually, the .1 release is a bit more stable/better tested than
the .0 release.)

For frequent/nightly GCC builds, see also
http://gcc.gnu.org/wiki/GFortranBinaries

[Bug c++/48948] [C++0x] constexpr friend function cannot be defined in-class

[daniel.kruegler at googlemail dot com]

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

--- Comment #2 from Daniel Krügler  
2011-05-10 16:33:39 UTC ---
(In reply to comment #1)

I don't think that this is intended, but I would like to await feedback from
the developer group before submitting a corresponding core issue. IMO there are
some core wordings in regard to type completeness that are not intended to be
read strictly, e.g. 3.2 p.4

"— a function with a return type or argument type of type T is defined (3.1)
[..]"

can be read to disallow any of the following function definitions:

struct A {
  A f(A a) { return a; }
  friend A g(A a) { return a; }
};

I haven't seen a compiler who rejects this code, because they all contribute
more weight to 9.2 p.2. In regard to constexpr functions the clear intention is
that these can be forward-declared and are only required to be completely
defined, if used in a manner that requires a constant expression. The example
in 7.1.5 with the constexpr function "small" and it's usage in the constexpr
constructor of pixel make this intention very clear. Now to me, the 3.2 p.4
requirement was always supposed to be interpreted as "complete as it would be
required to be complete within the function body" for both function parameters
and function return types within this function definition, so I don't see any
reason why the compiler needs to validate the constraints on literal types at
the point where the class type is still incomplete and *does* not need to be
complete.

If the gcc developer feedback indeed points to an intended conservative reading
of 3.2 p.4 for constexpr functions as in this example I will surely require to
open a core issue for this situation, because this severely constraints
constexpr function definitions within classes. In this case a simple workaround
is to replace the "by-value" parameter by "by-reference", but the need for such
a change looks like an artifact to me. It seems to me that both functions f()
and g() defined in class A above could be constexpr functions.

[Bug c++/48859] [4.6/4.7 Regression] incorrect "uninitialized const member" error on new without new-initializer

[fabien at gcc dot gnu.org]

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

--- Comment #9 from fabien at gcc dot gnu.org 2011-05-10 16:27:42 UTC ---
(In reply to comment #8)
> Thanks! Is this patch ok for the 4.6 branch too? 

Yes, as it is a 4.6 regression, and Jason also approved it for 4.6.

> If you don't have time to backport it, I can.

I was planning to backport it this evening, thanks.

[Bug lto/48952] New: ICE in inline_merge_summary during linux kernel LTO build

[andi-gcc at firstfloor dot org]

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

   Summary: ICE in inline_merge_summary during linux kernel LTO
build
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andi-...@firstfloor.org


When running a Linux kernel LTO build with recent mainline
(gcc version 4.7.0 20110510 (experimental) (GCC))
I get a segfault during the final lto-wpa phase

In gdb I get

Program received signal SIGSEGV, Segmentation fault.
inline_merge_summary (edge=0x7f1ce05d90d0)
at ../../gcc/gcc/ipa-inline-analysis.c:2025
2025  && ipa_get_cs_argument_count (IPA_EDGE_REF (edge
(gdb) bt
#0  inline_merge_summary (edge=0x7f1ce05d90d0)
at ../../gcc/gcc/ipa-inline-analysis.c:2025
#1  0x0085b079 in inline_call (e=0x7f1ce05d90d0,
update_original=Unhandled dwarf expression opcode 0xf3
)
at ../../gcc/gcc/ipa-inline-transform.c:185
#2  0x00854561 in inline_small_functions ()
at ../../gcc/gcc/ipa-inline.c:1451
#3  ipa_inline () at ../../gcc/gcc/ipa-inline.c:1643
#4  0x0063c509 in execute_one_pass (pass=0xfff720)
at ../../gcc/gcc/passes.c:1556
#5  0x0063cbca in execute_ipa_pass_list (pass=0xfff720)
at ../../gcc/gcc/passes.c:1922
#6  0x0049ffe5 in do_whole_program_analysis ()
at ../../gcc/gcc/lto/lto.c:2517
#7  lto_main () at ../../gcc/gcc/lto/lto.c:2629
#8  0x006ccc4a in compile_file (argc=76, argv=0x12c8470)
at ../../gcc/gcc/toplev.c:570
#9  do_compile (argc=76, argv=0x12c8470) at ../../gcc/gcc/toplev.c:1928
#10 toplev_main (argc=76, argv=0x12c8470) at ../../gcc/gcc/toplev.c:2000
#11 0x003bc6e1ee5d in __libc_start_main (main=0x4a29e0 , argc=16, 
ubp_av=0x7fff62bc8e28, init=, 
fini=, rtld_fini=, 
stack_end=0x7fff62bc8e18) at libc-start.c:226
#12 0x00486f99 in _start ()
(gdb) 


The input files are very large. I can supply them on demand.
They also require special binutils currently (HJ's latest version)

[Bug middle-end/48770] [4.7 Regression] wrong code with -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |law at redhat dot com
   |gnu.org |

--- Comment #6 from Jeffrey A. Law  2011-05-10 15:52:15 
UTC ---
We have a block-local equivalence between a pseudo and a memory location:

(insn 86 85 87 9 (set (reg/f:DI 0 ax [113])
(const:DI (plus:DI (symbol_ref:DI ("*.LPBX1") [flags 0x2] )
(const_int 8 [0x8] 62 {*movdi_internal_rex64}
 (expr_list:REG_EQUIV (const:DI (plus:DI (symbol_ref:DI ("*.LPBX1") [flags
0x2] )
(const_int 8 [0x8])))
(nil)))
(insn 87 86 88 9 (set (reg:DI 114 [ *.LPBX1+8 ])
(mem/s/j/c:DI (reg/f:DI 0 ax [113]) [0 *.LPBX1+8 S8 A64])) 62
{*movdi_internal_rex64}
 (expr_list:REG_DEAD (reg/f:DI 0 ax [113])
(expr_list:REG_EQUIV (mem/s/j/c:DI (reg/f:DI 0 ax [113]) [0 *.LPBX1+8
S8 A64])
(nil
(insn 88 87 91 9 (parallel [
(set (reg:DI 2 cx [orig:95 *.LPBX1_I_lsm.5 ] [95])
(plus:DI (reg:DI 114 [ *.LPBX1+8 ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) 253 {*adddi_1}
 (expr_list:REG_DEAD (reg:DI 114 [ *.LPBX1+8 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (plus:DI (mem/s/j/c:DI (const:DI (plus:DI
(symbol_ref:DI ("*.LPBX1") [flags 0x2] )
(const_int 8 [0x8]))) [0 *.LPBX1+8 S8 A64])
(const_int 1 [0x1]))
(nil)


reg114 is marked as equivalent to (mem (reg 113)); reg114 does not get a hard
reg.  As usual, reload deletes the insn that creates the equivalence between
reg114 and its memory location (insn 87).  delete_dead_insn decides to peek at
insn86 and decides that insn86 is dead as well, which removes the
initialization of reg113.

Later reg114 is replaced with its equivalent memory location which results in
an uninitialized reference to reg113 and reading from an invalid memory
location and the segfault.

What's interesting here is delete_dead_insn's behavior -- it's been like this
since circa 1991, well before we ran any kind of real dead code elimination
after reload.  The solution *may* be to remove the recursion in
delete_dead_insn.  I'm still investigating.

[Bug c/48951] New: probably, it is a bug.

[ufo008ahw at 163 dot com]

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

   Summary: probably, it is a bug.
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ufo008...@163.com


I have written a program.I have use long long a type variable and scanf("%lld")
for input，but when i compare it with a int type one, the Conditional expression
is wrong.thanks for your reply.

My code is:

#include "stdio.h"

int main()
{
int  i;
long long n;
scanf("%lld", &n);

printf("\n");
printf("%lld\n", n);
i = 4;
printf("%d\n", (long long)i < n);

printf("\n");
n = (long long)1;
printf("%lld\n", n);
printf("%d\n", (long long)i < n);
}

[Bug libfortran/48950] New: a patch from 4.4.x not backported to 4.3.x

[sliwa at blue dot cft.edu.pl]

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

   Summary: a patch from 4.4.x not backported to 4.3.x
   Product: gcc
   Version: 4.3.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sl...@blue.cft.edu.pl


Quantum Espresso 4.3 compiled with gfortran 4.3.5 (and with the 4.3 snapshot I
tried) fails reading a data file. The same issue was present in the 4.4.x
series, but this has been fixed in rev 147887. As the 4.3.x series are still
maintained (and used, e.g., in Cygwin), I would like to ask about backporting
to 4.3.x. If you are willing to take care of this, please let me know how to
help.

It is not clear to me to what extent I can mix libgfortran from different
versions of GCC.

[Bug target/48949] [4.6/4.7 Regression] gcc-4.6.0 regression with complex.h on i386-pc-solaris2.10

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

  Component|c   |target
   Target Milestone|--- |4.6.1
Summary|gcc-4.6.0 regression with   |[4.6/4.7 Regression]
   |complex.h on|gcc-4.6.0 regression with
   |i386-pc-solaris2.10 |complex.h on
   ||i386-pc-solaris2.10

--- Comment #2 from Joseph S. Myers  2011-05-10 
15:57:13 UTC ---
I can't confirm whether this problem exists or is a regression, but if it does
then it's a fixincludes bug since fixincludes (fix solaris_complex) is supposed
to make the system complex.h header suitable for GCC.

[Bug c/48949] gcc-4.6.0 regression with complex.h on i386-pc-solaris2.10

[mariah.lenox at gmail dot com]

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

Mariah Lenox  changed:

   What|Removed |Added

 Target||i386-pc-solaris2.10
  Known to work||4.5.1
   Host||i386-pc-solaris2.10
  Known to fail||4.6.0
  Build||i386-pc-solaris2.10
   Severity|normal  |critical

--- Comment #1 from Mariah Lenox  2011-05-10 
15:37:00 UTC ---
Found while trying to compile mpc-0.9 with gcc-4.6.0.

[Bug c++/48859] [4.6/4.7 Regression] incorrect "uninitialized const member" error on new without new-initializer

[jyasskin at gcc dot gnu.org]

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

--- Comment #8 from Jeffrey Yasskin  2011-05-10 
15:42:54 UTC ---
Thanks! Is this patch ok for the 4.6 branch too? If you don't have time to
backport it, I can.

[Bug c/48949] New: gcc-4.6.0 regression with complex.h on i386-pc-solaris2.10

[mariah.lenox at gmail dot com]

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

   Summary: gcc-4.6.0 regression with complex.h on
i386-pc-solaris2.10
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mariah.le...@gmail.com


/* gcc-4.6.0 regression with complex.h on i386-pc-solaris2.10

% gcc -c foo.c
foo.c: In function ‘foo’:
foo.c:5:11: error: ‘_Imaginary_I’ undeclared (first use in this function)
foo.c:5:11: note: each undeclared identifier is reported only once for each
function it appears in
%
% gcc-4.5.1 -c foo.c
%
% gcc -v 
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.6.0/x86_64-SunOS-core2/libexec/gcc/i386-pc-solaris2.10/4.6.0/lto-wrapper
Target: i386-pc-solaris2.10
Configured with: /usr/local/gcc-4.6.0/src/gcc-4.6.0/configure
--enable-languages=c,c++,fortran --with-gnu-as
--with-as=/usr/local/binutils-2.21/x86_64-SunOS-gccc-4.5.1/bin/as --with-gnu-ld
--with-ld=/usr/local/binutils-2.21/x86_64-SunOS-gccc-4.5.1/bin/ld
--with-gmp=/usr/local/mpir-2.3.0/x86_64-SunOS-core2-gcc-4.5.1-abi32
--with-mpfr=/usr/local/mpfr-3.0.0/x86_64-SunOS-core2-mpir-2.3.0-gcc-4.5.1-abi32
--with-mpc=/usr/local/mpc-0.9/x86_64-SunOS-core2-mpir-2.3.0-mpfr-3.0.0-gcc-4.5.1-abi32
--prefix=/usr/local/gcc-4.6.0/x86_64-SunOS-core2
Thread model: posix
gcc version 4.6.0 (GCC) 
%
*/

#include 

double _Complex
foo () {
   return I;
}

[Bug debug/48159] [4.6/4.7 Regression] ICE: SIGSEGV in build2_stat (tree.c:3802) with -ftree-loop-distribution -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|4.7.0   |4.6.1

[Bug libffi/48944] build error: "libffi has not been ported to avr-unknown-none."

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  2011-05-10 15:10:57 UTC ---
When I configure for this target I get:

*** This configuration is not supported in the following subdirectories:
 target-libmudflap target-libgomp target-libssp target-libiberty 
target-libstdc++-v3 gnattools target-libada target-libgfortran 
target-libgo target-libffi target-zlib target-libjava target-libobjc 
target-boehm-gc
(Any other directories should still work fine.)

and then the generated Makefile contains:

TARGET_CONFIGDIRS =  libgcc libquadmath

Do you get some different list of unsupported directories (not including 
libffi) and of directories to build (including libffi), or do you get the 
same lists that I do but still find it tries to build libffi later?

[Bug c++/48948] [C++0x] constexpr friend function cannot be defined in-class

[schaub.johannes at googlemail dot com]

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

Johannes Schaub  changed:

   What|Removed |Added

 CC||schaub.johannes at
   ||googlemail dot com

--- Comment #1 from Johannes Schaub  
2011-05-10 14:49:18 UTC ---
(In reply to comment #0)
> gcc 4.7.0 20110507 (experimental) in C++0x mode rejects the following code at
> the line marked with #:
> 
> //---
> struct B {
>   friend constexpr int f(B) { return 0; } // #
> };
> //---
> 
> "error: invalid type for parameter 1 of constexpr function 'constexpr int
> f(B)'"
> 
> This code should be accepted. 
> 
> The same problem occurs with friend operators, like this case
> 
>   friend constexpr int operator+(B) { return 0; }
> 
> within B resulting in:
> 
> "error: invalid type for parameter 1 of constexpr function 'constexpr int
> operator+(B)'"
> 

Well, class "B" is incomplete in the parameter type list of f. The spec allows
B to be incomplete for that parameter type (8.3.5p9), but it doesn't say
anything what that means for determining whether or not the parameter has
literal class type (several of the bullets of 3.9p10 require a complete class
type to be checked). I don't know whether an implementation is supposed to
reject the code, or supposed to wait until B is complete. Same would apply for
non-static member functions.

Any hints?

[Bug debug/48159] [4.6/4.7 Regression] ICE: SIGSEGV in build2_stat (tree.c:3802) with -ftree-loop-distribution -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  2011-05-10 
14:29:32 UTC ---
First of all, it surprises me that tree-loop-distribution.c and stmts_from_loop
don't do anything special about debug stmts, I'd say stmts_from_loop should
ignore debug stmts like it ignores GIMPLE_LABELs and
generate_loops_for_partition and generate_builtin match that, the first
by keeping all DEBUG stmts in all loops and generate_builtin to just ignore
them.  Otherwise I think we risk -fcompare-debug failures.

The second problem is in generate_loops_for_partition, it wants to remove
all stmts that are not in that partition, and going in the order of stmts
queued
from stmts_from_loop, by walking the loop bbs sequentially and first going
through not marked phis, removing each of them, then going through stmts from
first to last in the bb, again removing unneeded stmts.

insert_debug_temp_for_var_def though assumes I think that within one bb stmts
are removed from the end towards beginning and that bbs are traversed during
removal in the right order according to dominator info.  Not sure what we want
to do there, perhaps reset all the debug stmts that use values set by stmts
that are not in the current partition?  Alex, any ideas?  In particular, the
problematic DEBUG stmt uses a SSA_NAME which is not in partition bitmap, whose
definition is a PHI node result again not in the partition, and where one of
the PHI arguments again uses the SSA_NAME also used in the DEBUG stmt.

[Bug fortran/48889] [4.6/4.7 Regression] f951: internal compiler error: in gfc_is_constant_expr, at fortran/expr.c:906

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot
   ||gnu.org, mikael at gcc dot
   ||gnu.org
   Target Milestone|--- |4.6.1

--- Comment #5 from Tobias Burnus  2011-05-10 
13:47:15 UTC ---
  Works:2010-11-09  r166519
  Fails:2010-11-09  r166520

that's the commit

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

2010-11-09  Jerry DeLisle  
Mikael Morin   

PR fortran/46331
* intrinsic.c: Correctly set the pure attributes for intrinsic
functions.
* expr.c (check_specification_function): Remove this function and move
its code into gfc_is_constant_expr. (gfc_is_constant_expr): Change the
order of checks by checking for non-constant arguments first.  Then,
check for initialization functions, followed by intrinsics.

[Bug middle-end/48770] [4.7 Regression] wrong code with -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #5 from Jeffrey A. Law  2011-05-10 13:13:33 
UTC ---
Thanks.  I'm more than happy to take it from here...

[Bug debug/48159] [4.6/4.7 Regression] ICE: SIGSEGV in build2_stat (tree.c:3802) with -ftree-loop-distribution -g

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-05-10 
13:08:31 UTC ---
Further reduced testcase for -O3 -g:

void
foo (double x, int y, double *__restrict z, double *__restrict w)
{
  while (y--)
*z++ = (*w++ = 0) * x;
}

[Bug libfortran/48906] Wrong rounding results with -m32

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  2011-05-10 
12:53:07 UTC ---
Status: I have managed to eliminate the OUTPUT_FLOAT_G macro completely and all
floating point operations.  What remains is to adjust the trailing blanks.  The
patch is simple looking once you get there, though a bit subtle to sort out
initially, especially when I get only 20 or 30 minute intervals to work on this
every two or three days.  ;)

Stay tuned.

[Bug target/48896] avr.o warnings

[eric.weddington at atmel dot com]

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

Eric Weddington  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug c++/48948] New: [C++0x] constexpr friend function cannot be defined in-class

[daniel.kruegler at googlemail dot com]

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

   Summary: [C++0x] constexpr friend function cannot be defined
in-class
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com


gcc 4.7.0 20110507 (experimental) in C++0x mode rejects the following code at
the line marked with #:

//---
struct B {
  friend constexpr int f(B) { return 0; } // #
};
//---

"error: invalid type for parameter 1 of constexpr function 'constexpr int
f(B)'"

This code should be accepted. 

The same problem occurs with friend operators, like this case

  friend constexpr int operator+(B) { return 0; }

within B resulting in:

"error: invalid type for parameter 1 of constexpr function 'constexpr int
operator+(B)'"

It seems to me that this defect is *not* a dup of bug 48945, where the compiler
incorrectly attempts to add a const-qualifier to a static member function. I
can only assume that the compiler considers the argument as incomplete and thus
not being a valid literal type, because other non-friend constexpr functions
don't cause such problems, but I'm not sure.

Finally, the problem does not occur, if the friend function is defined
out-of-class, like so:

class C {
  friend constexpr int g(C);
};

constexpr int g(C) { return 0; }

[Bug fortran/48889] [4.6/4.7 Regression] f951: internal compiler error: in gfc_is_constant_expr, at fortran/expr.c:906

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

  Attachment #24205|application/octet-stream|text/plain
  mime type||

--- Comment #4 from Tobias Burnus  2011-05-10 
12:35:23 UTC ---
Comment on attachment 24205
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24205
Small test exhibiting the problem.

Works: 4.6.0  2010-09-28  r164677
Fails: 4.6.0  2010-11-27  r167218

[Bug target/48896] avr.o warnings

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||gjl at gcc dot gnu.org
 Resolution||FIXED

--- Comment #2 from Georg-Johann Lay  2011-05-10 
12:23:47 UTC ---
Closed as of respective patch.

However, I do not see the C++ warnings

"argument 4 of ‘expand_expr’ is invalid in C++ [-Werror=c++-compat]"

even though -Wc++-compat is on:

gcc -c   -g  -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../../gcc.gnu.org/trunk/gcc -I../../../gcc.gnu.org/trunk/gcc/.
-I../../../gcc.gnu.org/trunk/gcc/../include
-I../../../gcc.gnu.org/trunk/gcc/../libcpp/include
-I/mnt/nfs/home/georg/gnu/build/gcc-4.6-avr/./gmp
-I/mnt/nfs/home/georg/gnu/gcc.gnu.org/trunk/gmp
-I/mnt/nfs/home/georg/gnu/build/gcc-4.6-avr/./mpfr
-I/mnt/nfs/home/georg/gnu/gcc.gnu.org/trunk/mpfr
-I/mnt/nfs/home/georg/gnu/gcc.gnu.org/trunk/mpc/src 
-I../../../gcc.gnu.org/trunk/gcc/../libdecnumber
-I../../../gcc.gnu.org/trunk/gcc/../libdecnumber/dpd -I../libdecnumber\
../../../gcc.gnu.org/trunk/gcc/config/avr/avr.c -o avr.o


The build compiler I use identifies itself as:

Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.3
--enable-linux-futex --without-system-libunwind --with-cpu=generic
--build=i586-suse-linux
Thread model: posix
gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux)

Is there anything broken in that version?

[Bug lto/48947] 4.6.0 fails to link ffmpeg with LTO and gold

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.05.10 12:06:14
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-05-10 
12:06:14 UTC ---
Please make sure the ffmpeg makefiles properly pass compiler options,
including -fPIC, to the gcc driver used at link time.  It looks like it
does not do so (especially using libtool or cmake may have issues here).

[Bug middle-end/48770] [4.7 Regression] wrong code with -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-05-10 
11:46:34 UTC ---
*.asmcons is identical in between r171110 and r17, *.ira already looks
wrong (no setting of %rax to 24+.LPBX1, or changing the (%rax) address to
24+.LPBX1).

[Bug target/48896] avr.o warnings

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  2011-05-10 
12:16:15 UTC ---
Author: gjl
Date: Tue May 10 12:16:09 2011
New Revision: 173617

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173617
Log:
PR target/48896
* config/avr/avr.c (avr_ret_register): Return unsigned int
instead of int.
(avr_function_value): Mark fn_decl_or_type as unused, don't pass
it to avr_libcall_value.
avr_expand_builtin): Use EXPAND_NORMAL as arg 4 in calls to
expand_expr.
(avr_expand_binop_builtin): Ditto.
(avr_expand_unop_builtin): Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c

[Bug debug/48159] [4.6/4.7 Regression] ICE: SIGSEGV in build2_stat (tree.c:3802) with -ftree-loop-distribution -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  2011-05-10 
12:15:55 UTC ---
Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167697

[Bug c++/44160] [C++0x] a mysterious error on __func__ in a lambda expression

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  2011-05-10 
11:42:41 UTC ---
A do_pushlevel(sk_block) missing?

[Bug middle-end/18041] OR of two single-bit bitfields is inefficient

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-05-10 
11:38:50 UTC ---
With a patch I have we now optimize at the tree level to

:
  D.2686_2 = b_1(D)->bit0;
  D.2688_4 = b_1(D)->bit1;
  D.2693_10 = D.2688_4 ^ D.2686_2;
  b_1(D)->bit0 = D.2693_10;
  return;

and with bitfield lowering applied to

:
  BF.0_2 = MEM[(struct B *)b_1(D)];
  D.2694_6 = BF.0_2 >> 1;
  D.2701_18 = D.2694_6 ^ BF.0_2;
  D.2696_12 = BF.0_2 & 4294967294;
  D.2697_13 = D.2701_18 & 1;
  BF.2_14 = D.2697_13 | D.2696_12;
  MEM[(struct B *)b_1(D)] = BF.2_14;
  return;

[Bug middle-end/48770] [4.7 Regression] wrong code with -O -fprofile-arcs -fPIC -fno-dce -fno-forward-propagate -fno-tree-forwprop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2011-05-10 
11:37:33 UTC ---
Started with:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=17

[Bug c++/44160] [C++0x] a mysterious error on __func__ in a lambda expression

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2011-05-10 
10:54:31 UTC ---
More debugging: fname_decl, called by finish_fname, returns error_mark_node,
whereas it doesn't for, eg, 'const char* f() { return __func__; }'. Note the
argument to finish_fname is completely similar in the two cases.

[Bug lto/48947] New: 4.6.0 fails to link ffmpeg with LTO and gold

[gmarkhor at gmail dot com]

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

   Summary: 4.6.0 fails to link ffmpeg with LTO and gold
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gmark...@gmail.com


I am trying to make ffmpeg snapshot. I configure ffmpeg with the following
line:

../configure --enable-shared --cc='gcc -flto -fuse-linker-plugin -fPIC'
--prefix=/home/markhor/ffmpeg/install --arch=x86_64

It fails to build with
LDlibavcodec/libavcodec.so.53
ffmpeg/libavcodec/jpegls.h:46:0: warning: type of ‘ff_log2_run’ does not match
original declaration [enabled by default]
ffmpeg/libavcodec/jpegls.h:46:0: warning: type of ‘ff_log2_run’ does not match
original declaration [enabled by default]
ffmpeg/libavcodec/bitstream.c:35:15: note: previously declared here
x86_64-unknown-linux-gnu/bin/ld.gold: error: /tmp/ccla9ktI.ltrans3.ltrans.o:
requires dynamic reloc which may overflow at runtime; recompile with -fPIC
x86_64-unknown-linux-gnu/bin/ld.gold: error: /tmp/ccla9ktI.ltrans10.ltrans.o:
requires dynamic reloc which may overflow at runtime; recompile with -fPIC
x86_64-unknown-linux-gnu/bin/ld.gold: error: /tmp/ccla9ktI.ltrans16.ltrans.o:
requires dynamic reloc which may overflow at runtime; recompile with -fPIC
x86_64-unknown-linux-gnu/bin/ld.gold: error: /tmp/ccla9ktI.ltrans21.ltrans.o:
requires dynamic reloc which may overflow at runtime; recompile with -fPIC
collect2: ld returned 1 exit status


--cc='gcc -flto -fPIC' fails the same way. Snapshot is successfully built
without LTO with the BFD linker.

[Bug c++/44160] [C++0x] a mysterious error on __func__ in a lambda expression

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #6 from Paolo Carlini  2011-05-10 
11:10:21 UTC ---
I found where exactly things go wrong first: in cp_make_fname_decl,
current_binding_level->kind is sk_function_parms, thus error_mark_node is
returned. In the aforementioned case of f(), it's sk_block, makes sense.

Jason, any tip about this meaningless binding level?

[Bug lto/48725] 4.6.0 fails to link p7zip 9.20.1 with LTO and gold

[gmarkhor at gmail dot com]

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

--- Comment #6 from Vadim Markovtsev  2011-05-10 
11:01:14 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > Does it work with BFD linker in CVS?
> 
> I will check that out tomorrow.

Sorry for such a delay,

I checked out binutils from CVS on May, 10. p7zip is built flawlessly with the
BFD linker. The gold linker (when building with LTO) fails the same way.

[Bug c++/48940] GCC fails to issue expected error

[vanceza at gmail dot com]

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

--- Comment #5 from Zachary Vance  2011-05-10 
10:27:08 UTC ---
As long as folks are aware of this behavior and consider it proper, I
personally have no objection.  I don't see any large benefit from changing it;
I was just confused when other people couldn't reproduce the error my compiler
was giving.

[Bug lto/48938] [4.7 Regression] ICE: in lto_wpa_write_files, at lto/lto.c:1992 with -O -flto --param lto-min-partition=1

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
 Depends on||48246
   Target Milestone|--- |4.7.0

--- Comment #1 from Richard Guenther  2011-05-10 
10:32:06 UTC ---
I think we have a dup for this.  On the 4.6 branch I "fixed" this by
turning the assert into a checking-assert.

Thus, this seems related to PR48246.

[Bug libffi/48944] build error: "libffi has not been ported to avr-unknown-none."

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #1 from Richard Guenther  2011-05-10 
10:30:05 UTC ---
Sounds like some of the toplevel configure re-org may have caused this?
C and C++ should not result in libffi being built (I think).

[Bug debug/48670] [4.6 regression] explosion in time and stack usage when using -ggdb on a class with many members

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-05-10 
10:34:52 UTC ---
Anyway, most likely PR48190, i.e.
http://gcc.gnu.org/viewcvs?view=revision&revision=171655

[Bug c++/48940] GCC fails to issue expected error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2011-05-10 
10:07:16 UTC ---
No, -std=c++98 and -std=c++03 are aliases, both described as:
Conform to the ISO 1998 C++ standard revised by the 2003 technical corrigendum

[Bug c++/48940] GCC fails to issue expected error

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2011-05-10 
10:07:53 UTC ---
(In reply to comment #2)
> Sorry to be cryptic as to the part of the standard I was talking about.  Yes, 
> I
> was referring to report 391/589.
> 
> Yes, I agree that g++ should not issue an error for this file running in C++03
> mode.

(I assume you mean C++0x here)

DR 391 was resolved in 2005 and G++'s behaviour was changed intentionally, see
PR 25950

> What I am filing a bug about is that g++ used to issue an error running in
> C++98 mode, and now g++ does not issue an error running in C++98 mode.  I 
> claim
> that it should issue an error, because I understood issue the defect reports
> only to affect the C++03 standardization.  Is this correct?

Technically yes, but the intent of the committee is that it should work, and
implementing that is more useful for users.  Does it actually serve any
advantage to reject the code, other than strict conformance?  With extended
SFINAE in C++0x you could make use of it, but the code is valid in C++0x, and
extended SFINAE isn't part of C++98.

There are lots of DRs that G++ implements, counter to the exact wording in
C++98 or C++03.

Jason, as the author of the fix for PR 25950, do you have an opinion?

[Bug c++/44160] [C++0x] a mysterious error on __func__ in a lambda expression

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2011-05-10 
10:09:15 UTC ---
Things go wrong well before check_return_expr: in cp_parser_lambda_body,
cp_parser_expression returns error_mark_node.

[Bug fortran/48946] New: [OOP] Deferred Overloaded Assignment

[burnus at gcc dot gnu.org]

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

   Summary: [OOP] Deferred Overloaded Assignment
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: rejects-valid, wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org


The FE wrongly resolves the operator, leading to "wrong code" in the sense that
the linker cannot find the symbol:

undefined reference to `assign_interface_' 


Reported by Andrew Baldwin and reported to work with XLF and NAG.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/32602f115b24e19d

Test case:


   module foo_module
implicit none

type, abstract :: foo
contains
  procedure (assign_interface), deferred :: assign
  generic :: assignment(=) => assign
end type

abstract interface
  subroutine assign_interface(lhs,rhs)
import :: foo
class(foo), intent(inout) :: lhs
class(foo), intent(in) :: rhs
  end subroutine
end interface
   end module

   module bar_module
use foo_module
implicit none

type, extends(foo) :: bar
  real :: x
contains
  procedure :: assign => assign_bar
end type

   contains
subroutine assign_bar(lhs,rhs)
  class(bar), intent(inout) :: lhs
  class(foo), intent(in) :: rhs
  select type(rhs)
type is (bar)
  lhs%x = rhs%x
  end select
end subroutine
   end module

   program main
use foo_module
use bar_module
implicit none
type(bar) :: one, two
one%x = 1
two%x = 2
one = two
   end program

[Bug c++/48945] New: [C++0x] static constexpr member function cannot be defined out-of class

[daniel.kruegler at googlemail dot com]

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

   Summary: [C++0x] static constexpr member function cannot be
defined out-of class
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com


gcc 4.7.0 20110507 (experimental) in C++0x mode rejects the following code:

//---
struct A {
  static constexpr bool is();
};

constexpr bool A::is() { return true; }
//---

"error: static member function 'constexpr bool A::is() const' declared with
type qualifiers"

According to 7.1.5 [dcl.constexpr] p. 1

"If any declaration of a function or function template has constexpr specifier,
then all its declarations shall contain the constexpr specifier."

the constexpr specifier is required as part of the function definition and the
code should be accepted. It seems that gcc incorrectly attempts to reapply a
const-qualifier to the static member.

[Bug c/31983] Add option to gcc to display specific language manual section reference for error/warning encountered.

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #13 from Manuel López-Ibáñez  2011-05-10 
09:57:55 UTC ---
I have come around on this issue (and the color output). I now think it would
be useful to have an extra verbose mode. It is clear it won't be implemented by
existing GCC devs and probably it won't be accepted in mainline GCC, so it will
have to be a plugin. 

The first step is to have a significant number of verbose descriptions. I have
started a list but it needs a lot more contributions:

http://gcc.gnu.org/wiki/VerboseDiagnostics

The second step would be to enable plugins to intercept warning/error messages
and add their own actions (in this case, just printing the verbose output).
Even if nobody bothers to finish this second step, the list itself would be
helpful.

[Bug c++/44160] [C++0x] a mysterious error on __func__ in a lambda expression

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.10 09:51:19
 Ever Confirmed|0   |1

--- Comment #3 from Paolo Carlini  2011-05-10 
09:51:19 UTC ---
Oops, indeed. Thanks.

[Bug fortran/38199] missed optimization: I/O performance

[jb at gcc dot gnu.org]

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

--- Comment #13 from Janne Blomqvist  2011-05-10 
09:41:08 UTC ---
Here's something for formatted writes; consider the write-many.f (from some
other PR, I'm too lazy to check which now)

program main
  open(10,status='SCRATCH')
  a = 0.3858204
  do i=1,100
 a = a + 0.4761748164
 write(10, '(G12.5)'),a
  end do
end program main

Profiling this with 'perf' shows the top offenders as

# Overhead Command 
Shared Object  Symbol
#   .. 
.  ..
#
21.56%  write-many  /lib/libc-2.11.1.so
   [.] __mpn_divrem
14.72%  write-many  /lib/libc-2.11.1.so
   [.] ___printf_fp
13.42%  write-many  /lib/libc-2.11.1.so
   [.] hack_digit.15661
 7.75%  write-many  /lib/libc-2.11.1.so
   [.] __GI_vfprintf
 3.81%  write-many 
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3.0.0  [.]
output_float.isra.7.constprop.16
 2.81%  write-many 
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3.0.0  [.]
write_float
 2.38%  write-many  /lib/libc-2.11.1.so
   [.] _IO_default_xsputn_internal
 2.10%  write-many 
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3.0.0  [.]
data_transfer_init
 1.96%  write-many 
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3.0.0  [.]
formatted_transfer
 1.37%  write-many 
/home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3.0.0  [.]
next_format0


That is, most of the time seems to be spent somewhere related to the libc
formatting (as we're using snprintf to convert the real numbers to ascii).
Next, consider

#include 
#include 

int main(int argc, char *argv[])
{
int ndigits = atoi(argv[1]);
printf("Doing test with %d digits\n", ndigits);
size_t bufsz = ndigits + 9;
char *buf = malloc(bufsz);
for (int i = 0; i < 1000; i++)
snprintf(buf, bufsz, "%#-.*e", ndigits, 1./3);
printf("%s\n", buf);
return 0;
}

$ time ./snprintfbench 0
Doing test with 0 digits
3.e-01

real0m2.608s
user0m2.610s
sys 0m0.000s

$ time ./snprintfbench 20
Doing test with 20 digits
3.33314830e-01

real0m4.746s
user0m4.740s
sys 0m0.010s

$ time ./snprintfbench 40
Doing test with 40 digits
3.3331482961625624739099293947e-01

real0m6.362s
user0m6.360s
sys 0m0.000s

$ time ./snprintfbench 60
Doing test with 60 digits
3.33314829616256247390992939472198486328125000e-01

real0m8.155s
user0m8.160s
sys 0m0.000s

That is, while there is a constant cost for snprintf(), each additional digit
increases the time approximately linearly. 

Now, in io/write_float.def we always convert with a constant 41 digits (when
REAL(16) is available). Instead, we could first figure out how many digits we
need, and only then call snprintf(), generating only as many digits as needed.
Or as many as requested + 1, if the user has chosen a non-default rounding
mode, that is we need an extra digit in order to do the rounding in that case.

[Bug ada/48943] [gcc-4.6.0] opt.adb compiled error while multilib enabled

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Andreas Schwab  2011-05-10 09:18:42 
UTC ---
.

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

[Bug c++/48940] GCC fails to issue expected error

[vanceza at gmail dot com]

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

--- Comment #2 from Zachary Vance  2011-05-10 
09:48:47 UTC ---
Sorry to be cryptic as to the part of the standard I was talking about.  Yes, I
was referring to report 391/589.

Yes, I agree that g++ should not issue an error for this file running in C++03
mode.

What I am filing a bug about is that g++ used to issue an error running in
C++98 mode, and now g++ does not issue an error running in C++98 mode.  I claim
that it should issue an error, because I understood issue the defect reports
only to affect the C++03 standardization.  Is this correct?

[Bug driver/44273] Using -save-temps and @file should also save the intermediate @file used by the driver.

[ibolton at gcc dot gnu.org]

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

Ian Bolton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ibolton at gcc dot gnu.org
 Resolution||WONTFIX

--- Comment #1 from Ian Bolton  2011-05-10 09:38:15 
UTC ---
This can be achieved by specifying "-Wl,-debug", so the behaviour of
--save-temps does not need to change.

[Bug ada/48942] [gcc-4.6.0] opt.adb compiled error while multilib enabled

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Andreas Schwab  2011-05-10 09:24:52 
UTC ---
You need a newer host compiler to build Ada as a cross compiler.  Generally the
host compiler should be the same version, see the installation instructions.

[Bug libffi/48944] build error: "libffi has not been ported to avr-unknown-none."

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Priority|P3  |P2
   Host||i586-suse-linux
  Build||i586-suse-linux
   Severity|normal  |blocker

[Bug ada/32164] [4.3/4.6/4.7 Regression] ICE when renaming predefined "=" and "/="

[ludo...@ludovic-brenta.org]

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

--- Comment #10 from Ludovic Brenta  2011-05-10 
08:48:53 UTC ---
(In reply to comment #9)
> This works with 4.4.x and 4.5.x:
> 
> pak1.ads:2:09: prefix of "Unrestricted_Access" attribute cannot be intrinsic

I wouldn't qualify this as "working".  The test program does not use
Unrestricted_Access and I think it is legal, so GCC should not reject it.  I
think this is in fact another bug which hides PR32164.

[Bug c++/48940] GCC fails to issue expected error

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-05-10 
09:08:39 UTC ---
I assume you're talking about binding the A& to a B object without an
accessible copy constructor?
That was the subject of a Defect Report against C++03 so has been fixed in G++,
therefore not a bug.

No temporary is created, so no copy constructor is needed

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#589

[Bug libffi/48944] New: build error: "libffi has not been ported to avr-unknown-none."

[gjl at gcc dot gnu.org]

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

   Summary: build error: "libffi has not been ported to
avr-unknown-none."
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libffi
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org


gcc from current trunk (SVN 173608)

configured:

../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7 --disable-nls --disable-shared
--enable-languages=c,c++

runs into following bug during build:

configure: error: "libffi has not been ported to avr-unknown-none."
make[1]: *** [configure-target-libffi] Fehler 1
make[1]: Leaving directory `/local/gnu/build/gcc-4.7-avr'
make: *** [all] Fehler 2

[Bug ada/48942] [gcc-4.6.0] opt.adb compiled error while multilib enabled

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  2011-05-10 09:18:43 
UTC ---
*** Bug 48943 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/48837] [4.4/4.5/4.6 Regression] Wrong optimization of recursive function calls

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||FIXED

--- Comment #13 from Jakub Jelinek  2011-05-10 
08:49:41 UTC ---
Fixed.

[Bug ada/48942] New: [gcc-4.6.0] opt.adb compiled error while multilib enabled

[ray_linn at hotmail dot com]

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

   Summary: [gcc-4.6.0] opt.adb compiled error while multilib
enabled
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ray_l...@hotmail.com


I am using MinGW (GCC-4.5.2 i686-pc-mingw32) to compiled a 64bit ada from
GCC-4.6.0。 the configure command is as following:

mkdir gcc-build
cd gcc-build
../gcc-4.6.0/configure --target=x86_64-w64-mingw32 --enable-targets=all
--enable-multilib --enable-64bit --prefix=/mingw32 --with-sysroot=/mingw32
--disable-shared --enable-static --enable-version-specific-runtime-libs
--with-dwarf2 --enable-fully-dynamic-string --enable-languages=c,ada
--disable-libgomp --enable-libada

then:

make all-gcc && make install-gcc   sucesss, no problem.

make all-target-libgcc && make install-target-libgcc ---sucess, lib32 and lib64
installed.

make all-target-libada && make install-target-libada --- sucess, lib32 and
lib64 installed

but when i running make all-gnattools , the compile stop with the following
error:

# gnattools1-re
make -C ../gcc/ada/tools -f ../Makefile \
  "CC=gcc" "CFLAGS=-g -O2 -D__USE_MINGW_ACCESS -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes" "LDFLAGS=-Wl,--stack,12582912"
"ADAFLA
GS=-gnatpg -gnata" "ADA_CFLAGS=" "INCLUDES=-I. -I.. -I../..
-I/home/beta/gcc-4.6
.0/gcc/ada -I/home/beta/gcc-4.6.0/gcc/config
-I/home/beta/gcc-4.6.0/gcc/../inclu
de -I/home/beta/gcc-4.6.0/gcc"
"ADA_INCLUDES=-ID:/mingw/lib/gcc/mingw32/4.5.2/ad
alib/../adainclude -ID:/mingw/lib/gcc/mingw32/4.5.2/adalib/ -I.
-I/home/beta/gcc
-4.6.0/gcc/ada" "exeext=.exe" "fsrcdir=/home/beta/gcc-4.6.0/gcc"
"srcdir=/home/b
eta/gcc-4.6.0/gcc" "GNATMAKE=gnatmake" "GNATLINK=gnatlink" "GNATBIND=gnatbind"
"
TOOLSCASE=cross" "LIBGNAT=" INCLUDES="" \
  gnatmake-re gnatlink-re
make[2]: Entering directory `/home/beta/gcc-build/gcc/ada/tools'
gnatmake -ID:/mingw/lib/gcc/mingw32/4.5.2/adalib/../adainclude
-ID:/mingw/lib/gc
c/mingw32/4.5.2/adalib/ -I. -I/home/beta/gcc-4.6.0/gcc/ada -u sdefault
--GCC="gc
c "
gnatmake: objects up to date.
gnatmake -c -ID:/mingw/lib/gcc/mingw32/4.5.2/adalib/../adainclude
-ID:/mingw/lib
/gcc/mingw32/4.5.2/adalib/ -I. -I/home/beta/gcc-4.6.0/gcc/ada gnatmake
--GCC="gc
c -g -O2 -D__USE_MINGW_ACCESS -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmis
sing-prototypes  -gnatpg -gnata"
gcc -c -I.\ -ID:/mingw/lib/gcc/mingw32/4.5.2/adalib/../adainclude
-ID:/mingw/lib
/gcc/mingw32/4.5.2/adalib/ -I. -IC:/msys/1.0/home/beta/gcc-4.6.0/gcc/ada -g -O2
-D__USE_MINGW_ACCESS -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prot
otypes -gnatpg -gnata -I- C:\msys\1.0\home\beta\gcc-4.6.0\gcc\ada\opt.adb
opt.ads:120:11: warning: unrecognized pragma "Ordered"
opt.ads:1393:11: warning: unrecognized pragma "Ordered"
gnatmake: "C:\msys\1.0\home\beta\gcc-4.6.0\gcc\ada\opt.adb" compilation error
make[2]: *** [gnatmake-re] Error 4
make[2]: Leaving directory `/home/beta/gcc-build/gcc/ada/tools'
make[1]: *** [gnattools-cross] Error 2
make[1]: Leaving directory `/home/beta/gcc-build/gnattools'
make: *** [all-gnattools] Error 2

I am not familiar with ada, could someone help me to check this problem. 

if any logs is needed just let me know.

[Bug tree-optimization/48837] [4.4/4.5/4.6 Regression] Wrong optimization of recursive function calls

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  2011-05-10 
08:45:09 UTC ---
Author: jakub
Date: Tue May 10 08:45:00 2011
New Revision: 173609

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173609
Log:
Backported from mainline
2011-05-07  Zdenek Dvorak  

PR tree-optimization/48837
* tree-tailcall.c (tree_optimize_tail_calls_1): Do not mark tailcalls
when accumulator transformation is performed.

* gcc.dg/pr48837.c: New testcase.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48837.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/tree-tailcall.c

[Bug ada/48943] New: [gcc-4.6.0] opt.adb compiled error while multilib enabled

[ray_linn at hotmail dot com]

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

   Summary: [gcc-4.6.0] opt.adb compiled error while multilib
enabled
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ray_l...@hotmail.com


I am using MinGW (GCC-4.5.2 i686-pc-mingw32) to compiled a 64bit ada from
GCC-4.6.0。 the configure command is as following:

mkdir gcc-build
cd gcc-build
../gcc-4.6.0/configure --target=x86_64-w64-mingw32 --enable-targets=all
--enable-multilib --enable-64bit --prefix=/mingw32 --with-sysroot=/mingw32
--disable-shared --enable-static --enable-version-specific-runtime-libs
--with-dwarf2 --enable-fully-dynamic-string --enable-languages=c,ada
--disable-libgomp --enable-libada

then:

make all-gcc && make install-gcc   sucesss, no problem.

make all-target-libgcc && make install-target-libgcc ---sucess, lib32 and lib64
installed.

make all-target-libada && make install-target-libada --- sucess, lib32 and
lib64 installed

but when i running make all-gnattools , the compile stop with the following
error:

# gnattools1-re
make -C ../gcc/ada/tools -f ../Makefile \
  "CC=gcc" "CFLAGS=-g -O2 -D__USE_MINGW_ACCESS -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes" "LDFLAGS=-Wl,--stack,12582912"
"ADAFLA
GS=-gnatpg -gnata" "ADA_CFLAGS=" "INCLUDES=-I. -I.. -I../..
-I/home/beta/gcc-4.6
.0/gcc/ada -I/home/beta/gcc-4.6.0/gcc/config
-I/home/beta/gcc-4.6.0/gcc/../inclu
de -I/home/beta/gcc-4.6.0/gcc"
"ADA_INCLUDES=-ID:/mingw/lib/gcc/mingw32/4.5.2/ad
alib/../adainclude -ID:/mingw/lib/gcc/mingw32/4.5.2/adalib/ -I.
-I/home/beta/gcc
-4.6.0/gcc/ada" "exeext=.exe" "fsrcdir=/home/beta/gcc-4.6.0/gcc"
"srcdir=/home/b
eta/gcc-4.6.0/gcc" "GNATMAKE=gnatmake" "GNATLINK=gnatlink" "GNATBIND=gnatbind"
"
TOOLSCASE=cross" "LIBGNAT=" INCLUDES="" \
  gnatmake-re gnatlink-re
make[2]: Entering directory `/home/beta/gcc-build/gcc/ada/tools'
gnatmake -ID:/mingw/lib/gcc/mingw32/4.5.2/adalib/../adainclude
-ID:/mingw/lib/gc
c/mingw32/4.5.2/adalib/ -I. -I/home/beta/gcc-4.6.0/gcc/ada -u sdefault
--GCC="gc
c "
gnatmake: objects up to date.
gnatmake -c -ID:/mingw/lib/gcc/mingw32/4.5.2/adalib/../adainclude
-ID:/mingw/lib
/gcc/mingw32/4.5.2/adalib/ -I. -I/home/beta/gcc-4.6.0/gcc/ada gnatmake
--GCC="gc
c -g -O2 -D__USE_MINGW_ACCESS -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmis
sing-prototypes  -gnatpg -gnata"
gcc -c -I.\ -ID:/mingw/lib/gcc/mingw32/4.5.2/adalib/../adainclude
-ID:/mingw/lib
/gcc/mingw32/4.5.2/adalib/ -I. -IC:/msys/1.0/home/beta/gcc-4.6.0/gcc/ada -g -O2
-D__USE_MINGW_ACCESS -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prot
otypes -gnatpg -gnata -I- C:\msys\1.0\home\beta\gcc-4.6.0\gcc\ada\opt.adb
opt.ads:120:11: warning: unrecognized pragma "Ordered"
opt.ads:1393:11: warning: unrecognized pragma "Ordered"
gnatmake: "C:\msys\1.0\home\beta\gcc-4.6.0\gcc\ada\opt.adb" compilation error
make[2]: *** [gnatmake-re] Error 4
make[2]: Leaving directory `/home/beta/gcc-build/gcc/ada/tools'
make[1]: *** [gnattools-cross] Error 2
make[1]: Leaving directory `/home/beta/gcc-build/gnattools'
make: *** [all-gnattools] Error 2

I am not familiar with ada, could someone help me to check this problem. 

if any logs is needed just let me know.

[Bug ada/48942] [gcc-4.6.0] opt.adb compiled error while multilib enabled

[ray_linn at hotmail dot com]

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

ray linn  changed:

   What|Removed |Added

Version|unknown |4.6.0
   Severity|normal  |major