[Bug libfortran/48958] New: Add runtime diagnostics for SIZE intrinsic function

[thenlich at users dot sourceforge.net]

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

   Summary: Add runtime diagnostics for SIZE intrinsic function
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


As has been brought up before (Bug 20406), the SIZE intrinsic returns an
unpredictable result if the argument is an unallocated allocatable or a pointer
that is not associated.

While this is perfectly standard-conforming behaviour, it would be helpful in
program development to have SIZE throw a runtime error if this condition
occurs.

I.e. SIZE should first check if an array is ALLOCATED or a pointer is
ASSOCIATED and abort with a runtime error if that is not the case.

Fortran 2008:

13.7.156 SIZE (ARRAY [, DIM, KIND])
3 Arguments.
ARRAY shall be an array of any type. It shall not be an unallocated allocatable
variable or a pointer that is not associated. If ARRAY is an assumed-size
array, DIM shall be present with a value less than the rank of ARRAY.

[Bug fortran/48959] New: Dummy procedure: Argument mismatch not diagnosed

[burnus at gcc dot gnu.org]

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

   Summary: Dummy procedure: Argument mismatch not diagnosed
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Found at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1a40cc3e6e4546de/

The dummy procedure has as first dummy argument:
  real, intent(in) :: p(:)
whereas the procedure which is passed as actual argument has as dummy argument:
  real, intent(in) :: param(3)

However, gfortran fails to diagnose this. I think the reason is that as dummy
argument "p" and "param" are compatible; however, as dummy argument of a
procedure they are not.


The check has to be added into interface.c's gfc_compare_interfaces - which
should be rather simple.

Currently, for each argument rank, optional attribute and intent is checked.
One there as to add a check that either both or neither is an assumed-shape
array. (Deferred-shape can be handled via an ALLOCATABLE/POINTER attribute
check.) Additionally, one should check for other characteristics (cf. 12.3.2):
CONTIGUOUS, VALUE, ALLOCATABLE, POINTER, TARGET, ASYNCHRONOUS, VOLATILE, type
parameters (currently, only: string lengths), corank. The procedure itself
should be checked for BIND(C) and PUREness.

Cf. also:

"12.5.2.9 Actual arguments associated with dummy procedure entities

"If the interface of a dummy procedure is explicit, its characteristics as a
procedure (12.3.1) shall be the same as those of its effective argument, except
that a pure effective argument may be associated with a dummy argument that is
not pure and an elemental intrinsic actual procedure may be associated with a
dummy procedure (which cannot be elemental)."


NAG diagnoses the problem as:
  Error: line 31: Dummy proc SUBR arg 1 is assumed-shape, actual proc
  MYSUB arg is not
  Error: line 31: Incompatible procedure argument for SUBR (no. 2) of MINIM


Example program by Clive Page:

module mymod
implicit none
contains
!-
subroutine mysub(param, result)
real, intent(in) :: param(3)
real, intent(out) :: result
print *,'param=', param
result = 0.0
end subroutine mysub
!-
subroutine minim(param, subr, result)
real, intent(in) :: param(:)
interface
subroutine subr(p, r)
  real, intent(in) :: p(:)
  real, intent(out) :: r
end subroutine subr
end interface
real, intent(out):: result
!
call subr(param, result)
end subroutine minim
end module mymod
!--

program main
use mymod
implicit none
real :: param(3) = [1.0, 2.0, 3.0], result
call minim(param, mysub, result)
end program main

[Bug c++/48869] [4.5/4.6/4.7 Regression] OpenMP task construct fails to instantiate copy constructor(same as Bug 36523)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #7 from Jakub Jelinek  2011-05-11 
08:05:31 UTC ---
Created attachment 24221
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24221
gcc46-pr48869.patch

Untested fix.

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

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  2011-05-11 
08:16:18 UTC ---
(In reply to comment #0)
> PS. Note -Wconversion already DOES emit a warning for conversion to complex to
> real in gfortran.  e.g.

Except for very few exceptions, the diagnostic machinery of Fortran is
independent of the diagnostic machinery of C/C++ (in some cases worse, in some
cases better). On the other hand, C/C++ share most of the code for Wconversion,
so implementing it for C will make it available for C++.

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

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.11 08:13:47
 CC||manu at gcc dot gnu.org
 Ever Confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Manuel López-Ibáñez  2011-05-11 
08:13:47 UTC ---
The Wconversion code makes not attempt to identify conversion from/to complex
value but it is probably easy to implement. 

If you are really interested in this, I can give you some hints and advice and
you will probably get it ready for GCC 4.7, but I don't have free time to do it
myself, sorry.

[Bug libfortran/48960] New: OPEN statement modifies NEWUNIT variable on error

[thenlich at users dot sourceforge.net]

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

   Summary: OPEN statement modifies NEWUNIT variable on error
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


If the NEWUNIT= specifier in the OPEN statement is used, the variable is
modified if an error occurs during the execution of the OPEN statement.

This does not conform to Fortran 2008 which demands:

9.5.6.12 NEWUNIT= specifier in the OPEN statement

1 The variable is defined with a processor determined NEWUNIT value if no error
occurs during the execution of the OPEN statement. If an error occurs, the
processor shall not change the value of the variable.

Example:

program test_newunit
integer :: st, un = 0
open (newunit=un, file='nonexisting.dat', status='old', iostat=st)
if (un /= 0) call abort
end program test_newunit

Result: If the file 'nonexisting.dat' does not exist, the program aborts.

Expected result: If the file 'nonexisting.dat' does not exist, the program
should not abort.

[Bug c++/48856] Crash when compiling certain source code with C++0x

[thiago at kde dot org]

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

Thiago Macieira  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME

--- Comment #9 from Thiago Macieira  2011-05-11 08:43:06 
UTC ---
Sorry for the noise. An upgrade from Mandriva fixed the issue.

[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

--- Comment #6 from Tobias Burnus  2011-05-11 
08:49:38 UTC ---
Some more debugging: While e->symtree == NULL, the symbols seems to be properly
resolved as e->value.function contains:

(gdb) p e->value.function->name
$11 = 0x2ac273f0 "sparsity_size"
(gdb) p e->value.function->esym->name
$13 = 0x2ac273f0 "sparsity_size"

And that's the proper specific function.


I was actually wondering whether always either isym or esym exists; however, as
gfortran.dg/graphite/id-2.f90 shows, the case that only e->symtree->n.sym is
set also occurs. Draft patch:

--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -893,6 +893,9 @@ gfc_is_constant_expr (gfc_expr *e)
 case EXPR_FUNCTION:
 case EXPR_PPC:
 case EXPR_COMPCALL:
+  gcc_assert (e->symtree || e->value.function.esym
+ || e->value.function.isym);
+
   /* Call to intrinsic with at least one argument.  */
   if (e->value.function.isym && e->value.function.actual)
{
@@ -901,13 +904,14 @@ gfc_is_constant_expr (gfc_expr *e)
  return 0;
}

-  /* Make sure we have a symbol.  */
-  gcc_assert (e->symtree);
-
-  sym = e->symtree->n.sym;
-
   /* Specification functions are constant.  */
   /* F95, 7.1.6.2; F2003, 7.1.7  */
+  sym = NULL;
+  if (e->symtree)
+   sym = e->symtree->n.sym;
+  if (e->value.function.esym)
+   sym = e->value.function.esym;
+
   if (sym
  && sym->attr.function
  && sym->attr.pure

[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

--- Comment #2 from Tobias Burnus  2011-05-11 
09:06:30 UTC ---
The obvious problem is that there is no temporary needed for either of the
variable expressions on the right hand side - only for their combination.

Thus, one needs to check whether as some point whether one part of the RHS
expression is GFC_DEP_FORWARD while another part is GFC_DEP_BACKWARD.

My impression is that one needs an additional argument to
  gfc_check_dependency
of the type "gfc_reverse *reverse" and two local variables like
  gfc_reverse reverse1, reverse2;
which one passes to gfc_check_dependency/gfc_dep_resolver, and - if "reverse"
is not NULL, propagates it to the caller. Then, for operators, the reverse
setting can be compared.

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

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.11 09:25:24
 AssignedTo|unassigned at gcc dot   |pault at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[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

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #9 from Jakub Jelinek  2011-05-11 
09:29:56 UTC ---
Created attachment 24223
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24223
gcc46-pr48159.patch

Untested fix.

[Bug libfortran/48961] New: EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW

[thenlich at users dot sourceforge.net]

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

   Summary: EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


When calling the EXECUTE_COMMAND_LINE intrinsic on Windows and setting the WAIT
argument to .false., the execution causes a runtime error.

For example:
program hello
print *, "Hello world"
end program hello

program test_execute
call execute_command_line("hello.exe", .false.)
end program test_execute

>test_execute
 Hello world
Fortran runtime error: Could not execute command line

Expected result: 

No runtime error should occur.

Fortran 2008:
13.7.57 EXECUTE_COMMAND_LINE (COMMAND [, WAIT, EXITSTAT, CMDSTAT, CMDMSG ])
...
3   Arguments.
...
WAIT (optional) shall be a default logical scalar. It is an INTENT (IN)
argument. If WAIT is present with the value false, and the processor supports
asynchronous execution of the command, the command is executed asynchronously;
otherwise it is executed synchronously.

5   When the command is executed synchronously, EXECUTE_COMMAND_LINE returns
after the command line has completed execution. Otherwise, EXECUTE_COMMAND_LINE
returns without waiting.

[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

--- Comment #3 from Georg-Johann Lay  2011-05-11 
09:25:37 UTC ---
Created attachment 24222
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24222
pr48944.diff

I get the following output from configure

*** This configuration is not supported in the following subdirectories:
 target-libmudflap target-libgomp target-libssp target-libiberty
target-libobjc
(Any other directories should still work fine.)

And the respective line in the toplevel Makefile reads:

TARGET_CONFIGDIRS =  libgcc libquadmath boehm-gc libffi zlib

With the attached patch applied the result is as expected and stuff looks like
indicated by Joseph.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

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

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from Richard Guenther  2011-05-11 
09:41:45 UTC ---
The rev. allowed inlining to happen.  We end up with two copies of type S
for some reason - inlining is supposed to copy variable-size types but
probably does not adjust reference tree types to those copies.  I'm not sure
why this doesn't trigger without LTO (we inline during early inlining).

I suppose the two types also exist w/o LTO but they are marked compatible
via TYPE_CANONICAL which isn't re-set by copy_node.  Thus, this is an
issue with re-constructing TYPE_CANONICAL.

Mine.

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

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  2011-05-11 10:16:53 UTC ---
On Wed, 11 May 2011, psmith at gnu dot org wrote:

> I think that the include-fixed directory should be associated with the 
> sysroot,

It should be associated with each system include directory (sysroot or 
otherwise) - so there should be a fixed version of /usr/local/include, 
searched immediately before /usr/local/include, and likewise for 
/usr/include.  But there are certainly sysroot uses where include-fixed is 
still relevant - where the sysroot is based on a copy of that used when 
GCC was built, but with extra libraries added.  (That's the case of 
sysroots that works most reliably for other reasons as well; GCC's runtime 
libraries get configured depending on the libc libraries and headers 
present when GCC was built, and in some cases the headers affect the 
configuration of GCC itself as well as GCC's libraries.)

http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02088.html
http://gcc.gnu.org/ml/gcc/2004-11/msg00255.html

[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 #4 from joseph at codesourcery dot com  2011-05-11 10:23:53 UTC ---
On Wed, 11 May 2011, gjl at gcc dot gnu.org wrote:

> I get the following output from configure
> 
> *** This configuration is not supported in the following subdirectories:
>  target-libmudflap target-libgomp target-libssp target-libiberty
> target-libobjc
> (Any other directories should still work fine.)
> 
> And the respective line in the toplevel Makefile reads:
> 
> TARGET_CONFIGDIRS =  libgcc libquadmath boehm-gc libffi zlib

I think you'll need to debug why that happens.  The toplevel configure 
script has logic that looks at what runtime libraries are required by what 
languages, and disables those that are only required by disabled languages 
- and that logic works for me, and I haven't changed it at all.  It should 
see from java/config-lang.in and go/config-lang.in that libffi is only 
needed by those languages, see that neither is being built, and disable 
libffi independently of the target.

> With the attached patch applied the result is as expected and stuff looks like
> indicated by Joseph.

I don't think this is appropriate.  A basic principle of my changes was 
that disabling ${libgcj} is generally not the right thing to do, 
especially based on the target architecture (rather than OS), and that any 
new disabling should have a comment explaining *why* the feature is 
disabled, and pointing to a relevant PR.  Furthermore, for new disablings 
it's better to set unsupported_languages instead of disabling the 
libraries, unless you have some reason why it's useful to build the Java 
compiler for this target without the libraries.

In this case, unsupported_languages is already set to include Java because 
of the lack of libffi support, so no further change should be needed; as I 
said, you need to debug why it doesn't work.  It would not be wrong to add

noconfigdirs="$noconfigdirs target-libffi"

in the same case that disables Java for targets not supporting libffi (see 
my previous comments that you should be able to override 
unsupported_languages with explicit --enable-languages configure options) 
but there's still the question of why you're getting boehm-gc and zlib 
built for your target.

[Bug middle-end/28467] Internal compiler error (ICE) with segmentation fault for valid C++ test case

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.1.2, 4.4.3, 4.5.2, 4.6.0
 Resolution||WORKSFORME

--- Comment #2 from Jonathan Wakely  2011-05-11 
10:24:19 UTC ---
no ICE in current releases

[Bug c++/10634] in-class initialization of static data members no longer allowed

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  2011-05-11 
10:21:05 UTC ---
C++0x supports the desired functionality with 'constexpr'

struct Struct {
  static constexpr unsigned char * pointer = (unsigned char*)0x123;
};

I think this enhancement request should be closed, because it's unlikely that
'constexpr' will be made available in c++98 mode and it's even less likely that
an incompatible non-standard extension will be added

[Bug fortran/48926] gfortran.dg/coarray/image_index_1.f90 -fcoarray=single -O2 (test for excess errors)

[howarth at nitro dot med.uc.edu]

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

--- Comment #3 from Jack Howarth  2011-05-11 
10:28:40 UTC ---
A clean tree at gcc trunk r173643 with a standard non-LTO bootstrap produces
different failures on x86_64-apple-darwin10...

FAIL: gfortran.dg/coarray/image_index_2.f90 -fcoarray=single  -O2  (internal
compiler error)
FAIL: gfortran.dg/coarray/image_index_2.f90 -fcoarray=single  -O2  (test for
excess errors)
WARNING: gfortran.dg/coarray/image_index_2.f90 -fcoarray=single  -O2 
compilation failed to produce executable
FAIL: gfortran.dg/coarray/image_index_2.f90 -fcoarray=lib  -O2  -lcaf_single
(internal compiler error)
FAIL: gfortran.dg/coarray/image_index_2.f90 -fcoarray=lib  -O2  -lcaf_single
(test for excess errors)
WARNING: gfortran.dg/coarray/image_index_2.f90 -fcoarray=lib  -O2  -lcaf_single
compilation failed to produce executable
FAIL: gfortran.dg/coarray_20.f90  -O   (test for errors, line 10)
FAIL: gfortran.dg/coarray_20.f90  -O  (test for excess errors)

which are of the form...

Executing on host:
/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/gcc/testsuite/gfortran/../../gfortran
-B/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/gcc/testsuite/gfortran/../../
-B/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/i386/libgfortran/
/sw/src/fink.build/gcc47-4.7.0-1000/gcc-4.7-20110511/gcc/testsuite/gfortran.dg/coarray/image_index_2.f90
 -fcoarray=single  -O2   
-B/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/i386/libgfortran/.libs
-L/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/i386/libgfortran/.libs
-L/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/i386/libgfortran/.libs
-B/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/i386/libquadmath/.libs
-L/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/i386/libquadmath/.libs
-L/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/i386/libquadmath/.libs
-L/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/i386/libiberty
 -lm   -m32 -o ./image_index_2.exe(timeout = 300)
/sw/src/fink.build/gcc47-4.7.0-1000/gcc-4.7-20110511/gcc/testsuite/gfortran.dg/coarray/image_index_2.f90:
In function 'test':^M
/sw/src/fink.build/gcc47-4.7.0-1000/gcc-4.7-20110511/gcc/testsuite/gfortran.dg/coarray/image_index_2.f90:50:0:
internal compiler error: in gfc_conv_descriptor_dimension, at
fortran/trans-array.c:257

which backtraces as...

[MacPro-2:~/coarray_bug] howarth% gdb
/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/gcc/testsuite/gfortran/../../f951
...
(gdb) break fancy_abortBreakpoint 1 at 0x10042851b: file
../../gcc-4.7-20110511/gcc/diagnostic.c, line 893.(gdb) r
/sw/src/fink.build/gcc47-4.7.0-1000/gcc-4.7-20110511/gcc/testsuite/gfortran.dg/coarray/image_index_2.f90
-fPIC -quiet -dumpbase image_index_2.f90 -mmacosx-version-min=10.6.7 -m32
-mtune=core2 -auxbase image_index_2 -O2 -version -fcoarray=single
-fintrinsic-modules-path finclude -o
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//cczFxApJ.s
Starting program: /sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/gcc/f951
/sw/src/fink.build/gcc47-4.7.0-1000/gcc-4.7-20110511/gcc/testsuite/gfortran.dg/coarray/image_index_2.f90
-fPIC -quiet -dumpbase image_index_2.f90 -mmacosx-version-min=10.6.7 -m32
-mtune=core2 -auxbase image_index_2 -O2 -version -fcoarray=single
-fintrinsic-modules-path finclude -o
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//cczFxApJ.s
...
Breakpoint 1, fancy_abort (file=0x100a74200
"../../gcc-4.7-20110511/gcc/fortran/trans-array.c", line=257,
function=0x100ae7f40 "gfc_conv_descriptor_dimension") at
../../gcc-4.7-20110511/gcc/diagnostic.c:893
893  internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) bt
#0  fancy_abort (file=0x100a74200
"../../gcc-4.7-20110511/gcc/fortran/trans-array.c", line=257,
function=0x100ae7f40 "gfc_conv_descriptor_dimension") at
../../gcc-4.7-20110511/gcc/diagnostic.c:893
#1  0x0001000b25f8 in gfc_conv_descriptor_dimension (desc=0x141e04600,
dim=0x141e0fe00) at ../../gcc-4.7-20110511/gcc/fortran/trans-array.c:257

[Bug c++/48078] gcc accepts-invalid: taking address of private member function from template function

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2011-05-11 
10:35:28 UTC ---
I've just hit another variation of this bug myself.

Reduced:

class F {
  void f();
};

template
void b() {
(void) &F::f;
}

template void b();

[Bug fortran/48926] gfortran.dg/coarray/image_index_1.f90 -fcoarray=single -O2 (test for excess errors)

[howarth at nitro dot med.uc.edu]

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

--- Comment #4 from Jack Howarth  2011-05-11 
10:34:36 UTC ---
Also the failure...

FAIL: gfortran.dg/coarray_20.f90  -O   (test for errors, line 10)
FAIL: gfortran.dg/coarray_20.f90  -O  (test for excess errors)

appears as...

Executing on host:
/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/gcc/testsuite/gfortran/../../gfortran
-B/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/gcc/testsuite/gfortran/../../
-B/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/i386/libgfortran/
/sw/src/fink.build/gcc47-4.7.0-1000/gcc-4.7-20110511/gcc/testsuite/gfortran.dg/coarray_20.f90
  -O  -fcoarray=single -S  -m32 -o coarray_20.s(timeout = 300)
/sw/src/fink.build/gcc47-4.7.0-1000/gcc-4.7-20110511/gcc/testsuite/gfortran.dg/coarray_20.f90:10.9:^M
^M
call bar(A) ! { dg-error "Rank mismatch in argument" }^M
 1^M
Error: Actual argument to 'x' at (1) must be simply contiguous^M

[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 #6 from Richard Guenther  2011-05-11 
10:53:00 UTC ---
Author: rguenth
Date: Wed May 11 10:52:57 2011
New Revision: 173650

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173650
Log:
2011-05-11  Richard Guenther  

PR tree-optimization/18041
* tree-ssa-forwprop.c (simplify_bitwise_and): Rename to ...
(simplify_bitwise_binary): ... this.  Handle operand conversions
by applying them to the result instead.
(tree_ssa_forward_propagate_single_use_vars): Adjust.  CSE tree code.

* gcc.dg/tree-ssa/forwprop-13.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-13.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug c++/48962] New: I am getting an error new.h: No such file or directory on Fedora 13

[pradheepkumark at yahoo dot com]

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

   Summary: I am getting an error  new.h: No such file or
directory on Fedora 13
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pradheepkum...@yahoo.com


I am getting an error  new.h: No such file or directory. I would like to know
what corrective action is to be taken to solve the above problem

[Bug c++/48963] New: I am getting an error new.h in Fedora 13

[pradheepkumark at yahoo dot com]

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

   Summary: I am getting an error new.h in Fedora 13
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pradheepkum...@yahoo.com


I am getting error in new.h in fedora 13

[Bug lto/48947] 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

--- Comment #2 from Vadim Markovtsev  2011-05-11 
11:43:03 UTC ---
I ensured that. ffmpeg does not use cmake, just ordinary GNU make; no libtool
is called at all down to the point where gcc fails (checked it with "make -n"
and "configure --cc='gcc -v ...'"). fPIC is passed correctly to each CC and LD
call, it is always in COLLECT_GCC_OPTIONS.

[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

--- Comment #3 from Richard Guenther  2011-05-11 
12:02:53 UTC ---
Ok.  The error seems to be gold-specific though - what binutils version are
you using?  Does the error persist if you use GNU ld (you need at least
binutils 2.21 for that to support -fuse-linker-plugin)?

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

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-05-11 
12:23:15 UTC ---
Author: rguenth
Date: Wed May 11 12:23:12 2011
New Revision: 173653

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173653
Log:
2011-05-11  Richard Guenther  

PR middle-end/48953
* tree-inline.c (remap_gimple_op_r): Also remap types of MEM_REFs.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr48953.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c

[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

--- Comment #5 from Georg-Johann Lay  2011-05-11 
12:23:00 UTC ---
I followed the recommendations in "Optimize disk usage" of

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

and applied it to the following directories:

libada gnattools gcc/ada gcc/testsuite/ada
libstdc++-v3 libjava libgfortran libgo
gcc/java gcc/go

So the new configure setup don't support mapping non-needed subdirs to emptydir
as the previous configure.

After adding 

libffi boehm-gc zlib

the build passes without errors, but the host zlib then is not build (configure
adds --with-system-zlib to HOST_CONFIGARGS).

Is there a list of compatible directory sets that can be used according to
"Optimize disk usage"?

[Bug fortran/48926] gfortran.dg/coarray/image_index_1.f90 -fcoarray=single -O2 (test for excess errors)

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC|bur...@net-b.de |dominiq at lps dot ens.fr

--- Comment #5 from Tobias Burnus  2011-05-11 
12:40:08 UTC ---
Dominique, I think you also have an x86_64-apple-darwin10. Do you also see
failures - for instance with -m32?

(In reply to comment #2)
> - One failure on ia64-debian-linux-gnu (20110507):

Whatever the reason was, it does not fail anymore. Thus, we have success (no
coarray failures) on i686, powerpc, x86_64, s390x and s390 under Linux,
FreeBSD, Darwin, and with hppa-Linux/hppa-hpux.

I think there might be a true bug - but as long it does not fail with my
system, I cannot debug it. Thus, it needs to be debugged by someone on whose
system it fails.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-05-11 
12:23:49 UTC ---
Fixed on trunk, queued for backporting.

[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 #10 from Jakub Jelinek  2011-05-11 
12:53:49 UTC ---
Author: jakub
Date: Wed May 11 12:53:43 2011
New Revision: 173656

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173656
Log:
PR debug/48159
* tree-ssa.c (reset_debug_uses): New function.
* tree-flow.h (reset_debug_uses): New prototype.
* tree-data-ref.c (stmts_from_loop): Ignore debug stmts.
* tree-loop-distribution.c (generate_loops_for_partition): Call
reset_debug_uses on the stmts that will be removed.  Keep around
all debug stmts, don't count them as bits in partition bitmap.
(generate_builtin): Don't count debug stmts or labels as bits in
partition bitmap.

* gcc.dg/pr48159-1.c: New test.
* gcc.dg/pr48159-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr48159-1.c
trunk/gcc/testsuite/gcc.dg/pr48159-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c
trunk/gcc/tree-flow.h
trunk/gcc/tree-loop-distribution.c
trunk/gcc/tree-ssa.c

[Bug c++/48962] I am getting an error new.h: No such file or directory on Fedora 13

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-05-11 
12:56:14 UTC ---
*** Bug 48963 has been marked as a duplicate of this bug. ***

[Bug c++/48963] I am getting an error new.h in Fedora 13

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Jonathan Wakely  2011-05-11 
12:56:14 UTC ---
dup

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

[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 #6 from joseph at codesourcery dot com  2011-05-11 13:08:05 UTC ---
On Wed, 11 May 2011, gjl at gcc dot gnu.org wrote:

> I followed the recommendations in "Optimize disk usage" of
> 
> http://gcc.gnu.org/wiki/SvnSetup
> 
> and applied it to the following directories:
> 
> libada gnattools gcc/ada gcc/testsuite/ada
> libstdc++-v3 libjava libgfortran libgo
> gcc/java gcc/go
> 
> So the new configure setup don't support mapping non-needed subdirs to 
> emptydir
> as the previous configure.

Indeed, if you're removing front end directories you'll need to deal with 
removing library directories as well.

> Is there a list of compatible directory sets that can be used according to
> "Optimize disk usage"?

Not that I know of.  I think that disk usage optimization is pretty 
obsolete by now (and we similarly ought to eliminate the separate 
release/snapshot tarballs for particular languages, just having the main 
monolithic one) - and there are other ways removing front end directories 
could break things.

[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 #11 from Jakub Jelinek  2011-05-11 
13:07:59 UTC ---
Author: jakub
Date: Wed May 11 13:07:54 2011
New Revision: 173657

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173657
Log:
PR debug/48159
* tree-ssa.c (reset_debug_uses): New function.
* tree-flow.h (reset_debug_uses): New prototype.
* tree-data-ref.c (stmts_from_loop): Ignore debug stmts.
* tree-loop-distribution.c (generate_loops_for_partition): Call
reset_debug_uses on the stmts that will be removed.  Keep around
all debug stmts, don't count them as bits in partition bitmap.
(generate_builtin): Don't count debug stmts or labels as bits in
partition bitmap.

* gcc.dg/pr48159-1.c: New test.
* gcc.dg/pr48159-2.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48159-1.c
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48159-2.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/tree-data-ref.c
branches/gcc-4_6-branch/gcc/tree-flow.h
branches/gcc-4_6-branch/gcc/tree-loop-distribution.c
branches/gcc-4_6-branch/gcc/tree-ssa.c

[Bug bootstrap/48964] New: [4.7 Regression] LTO profiledbootstrap failure

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] LTO profiledbootstrap failure
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: rgue...@gcc.gnu.org


On Linux/x86-64, revision 173650 gave

make[3]: *** [profiledbootstrap] Error 2
make[2]: *** [profiledbootstrap] Error 2
In file included from :241:0:
../../src-trunk/gcc/config/i386/i386.c: In function
'ix86_expand_special_args_builtin.isra.11':
../../src-trunk/gcc/config/i386/i386.c:27051:1: error: type mismatch in array
reference
const struct insn_data_d

const struct insn_data_d

insn_p_3 = &insn_data[icode_2];

../../src-trunk/gcc/config/i386/i386.c:27051:1: internal compiler error:
verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[7]: *** [/tmp/ccvmsPXS.ltrans4.ltrans.o] Error 1
make[7]: *** Waiting for unfinished jobs
lto-wrapper: make returned 2 exit status
/usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
make[6]: *** [f951] Error 1
../../src-trunk/gcc/recog.h:249:26: warning: type of 'recog_data' does not
match original declaration [enabled by default]
../../src-trunk/gcc/recog.h:249:0: warning: type of 'recog_data' does not match
original declaration [enabled by default]
../../src-trunk/gcc/recog.c:84:19: note: previously declared here
../../src-trunk/gcc/langhooks.h:481:0: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:0: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does not
match original declaration [enabled by default]
../../src-trunk/gcc/langhooks.h:481:26: warning: type of 'lang_hooks' does 

[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

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #12 from Jakub Jelinek  2011-05-11 
13:08:40 UTC ---
Fixed.

[Bug middle-end/48965] New: [4.7 Regression] FAIL: gcc.dg/pr45055.c

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] FAIL: gcc.dg/pr45055.c
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/ia32, I got

FAIL: gcc.dg/pr45055.c (test for excess errors)

at random.

[Bug bootstrap/48964] [4.7 Regression] LTO profiledbootstrap failure

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-05-11 
13:43:26 UTC ---
I suspect it's http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173653, maybe
also causing some SPEC2k6 issues that I now run into.

[Bug fortran/48786] [4.6/4.7 Regression][OOP] Generic ambiguity check too strict for polymorphic dummies

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  2011-05-11 
13:45:52 UTC ---
A) Regarding the ambiguity issue (cf. comment 0 and comment 3): As written, I
believe the interface is indeed ambiguous - if that's the case, there is no
regression in gfortran and comment 0 of this bug is INVALID. I have asked at
J3: http://j3-fortran.org/pipermail/j3/2011-May/004366.html

Hence: Regression but diagnostic is probably correct -> INVALID. Asked J3 for
confirmation.


B) Regarding the wrong-code bug (example 2, attachment 24141): See patch at
http://gcc.gnu.org/ml/fortran/2011-04/msg00318.html
The patch fixes the issue but as the review comment suggests, one should
factorize the code into a different function to make it easier to maintain and
to read, cf. http://gcc.gnu.org/ml/fortran/2011-05/msg1.html
(Note: You might need valgrind or malloc perturb to run into the bug.)

Hence: OOP wrong-code issue but no regression; patch exists, but needs to be
cleaned up.


C) Regarding the segfault (test case: attachment 24110 with the patch of
comment 3), see comment 5

Hence: No regression but an OOP ice-on-valid-code (segfault) bug, which still
needs to be investigated and fixed.

[Bug c++/48962] I am getting an error new.h: No such file or directory on Fedora 13

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.05.11 12:58:09
 Ever Confirmed|0   |1
   Severity|critical|normal

--- Comment #2 from Jonathan Wakely  2011-05-11 
12:58:09 UTC ---
Bugzilla is for bugs in GCC, not for asking how to use the compiler.

There is no header called new.h in C++, maybe you want to include  instead

[Bug bootstrap/48964] [4.7 Regression] LTO profiledbootstrap failure

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

--- Comment #2 from H.J. Lu  2011-05-11 13:55:22 
UTC ---
It is caused by revision 173649:

http://gcc.gnu.org/ml/gcc-cvs/2011-05/msg00427.html

[Bug tree-optimization/15256] [tree-ssa] Optimize manual bitfield manipilation.

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-05-11 
14:13:47 UTC ---
Author: rguenth
Date: Wed May 11 14:13:38 2011
New Revision: 173659

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173659
Log:
2011-05-11  Richard Guenther  

PR tree-optimization/15256
* tree-ssa-forwprop.c (simplify_bitwise_binary): Canonicalize
(A & B) | C, combine (A op CST1) op CST2.
(tree_ssa_forward_propagate_single_use_vars): Only bother to
visit assigns that have uses.

* gcc.dg/tree-ssa/forwprop-14.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-14.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug fortran/48786] [OOP] Generic ambiguity check too strict for polymorphic dummies

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords|rejects-valid   |wrong-code
   Target Milestone|4.6.1   |---
Summary|[4.6/4.7 Regression][OOP]   |[OOP] Generic ambiguity
   |Generic ambiguity check too |check too strict for
   |strict for polymorphic  |polymorphic dummies
   |dummies |

--- Comment #7 from Tobias Burnus  2011-05-11 
14:30:36 UTC ---
(In reply to comment #6)
> I have asked at J3: http://j3-fortran.org/pipermail/j3/2011-May/004366.html

IBM's xlf and someone at IBM also regard it as invalid. Thus, I have now
removed the [Regression] marker - and downgraded it to a normal OOP bug.

[Bug bootstrap/48964] [4.7 Regression] LTO profiledbootstrap failure

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.11 15:03:29
 Ever Confirmed|0   |1

--- Comment #3 from Richard Guenther  2011-05-11 
15:03:29 UTC ---
Btw, the refered patch should at most cause more types to be considered
equal by the type verifier, not less ... at least I can't see the obvious
difference.  Hmm.

But, confirmed.

[Bug c/48966] New: gcc 4.5 gets wrong answer at -O2

[geir at cray dot com]

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

   Summary: gcc 4.5 gets wrong answer at -O2
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@cray.com


The following test gets the wrong answer for optimization level -O2 (and -O3)
for GCC 4.5.3.  The correct answer occurs when -O1 is used.  The problem does
occur in GCC 4.6.0:


$ cat ptest.c

#include 

double d0 = 0.4;
double d1 = 0.99320549518091861;
double d2 = 0.00674833952334470;
double d3 = 0.00679450481908144;

int main() {
   double  tmp;
   int answer = 0;

   tmp = d3 - d2/(d1-d0) - d0;
   answer = (*(((int *)&tmp)+1) >> 31) & 1;
   printf("answer = %d\n",answer);
   return answer;
}

$ gcc --version
gcc (GCC) 4.5.3 20110428 (Cray Inc.)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -O1 ptest.c && ./a.out
answer = 1
$ gcc -O2 ptest.c && ./a.out
answer = 0   <--- Wrong answer!!!
$ module swap gcc/4.5.3 gcc/4.6.0
$ gcc --version
gcc (GCC) 4.6.0 20110325 (Cray Inc.)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

geir@kaibab:/lus/scratch/geir/ISU/ISU3475> gcc -O2 ptest.c && ./a.out
answer = 1
$

The processor being used is:

$ grep "model name" /proc/cpuinfo
model name: 6-Core AMD Opteron(tm) Processor 23 (D0)
model name: 6-Core AMD Opteron(tm) Processor 23 (D0)
model name: 6-Core AMD Opteron(tm) Processor 23 (D0)
model name: 6-Core AMD Opteron(tm) Processor 23 (D0)
model name: 6-Core AMD Opteron(tm) Processor 23 (D0)
model name: 6-Core AMD Opteron(tm) Processor 23 (D0)
$

[Bug bootstrap/48964] [4.7 Regression] LTO profiledbootstrap failure

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-05-11 
15:23:28 UTC ---
Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 173655)
+++ gcc/gimple.c(working copy)
@@ -4304,7 +4304,7 @@ iterative_hash_canonical_type (tree type
   m.base.from = type;
   if ((slot = htab_find_slot (canonical_type_hash_cache, &m, INSERT))
   && *slot)
-return iterative_hash_hashval_t (((struct tree_int_map *) *slot)->to, 0);
+return iterative_hash_hashval_t (((struct tree_int_map *) *slot)->to,
val);

   /* Combine a few common features of types so that types are grouped into
  smaller sets; when searching for existing matching types to merge,

[Bug bootstrap/48964] [4.7 Regression] LTO profiledbootstrap failure

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from Richard Guenther  2011-05-11 
15:22:28 UTC ---
Argh.  I have an obvious patch.

[Bug middle-end/48965] [4.7 Regression] FAIL: gcc.dg/pr45055.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||froydnj at gcc dot gnu.org

--- Comment #1 from H.J. Lu  2011-05-11 15:39:18 
UTC ---
The error is

gcc: error: /export/regression/rrs/173633/src/gcc/testsuite/gcc.dg/pr45055.c:
-fcompare-debug failure (length)^M

FAIL: gcc.dg/pr45055.c (test for excess errors)

and it is caused by 173633:

http://gcc.gnu.org/ml/gcc-cvs/2011-05/msg00411.html

[Bug c/48966] gcc 4.5 gets wrong answer at -O2

[geir at cray dot com]

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

--- Comment #1 from Geir Johansen  2011-05-11 15:24:05 
UTC ---
(In reply to comment #0)
> The following test gets the wrong answer for optimization level -O2 (and -O3)
> for GCC 4.5.3.  The correct answer occurs when -O1 is used.  The problem does
> occur in GCC 4.6.0:

The problem does NOT occur in GCC 4.6.0

[Bug c/48966] gcc 4.5 gets wrong answer at -O2

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Richard Guenther  2011-05-11 
15:30:00 UTC ---
You are violating C aliasing rules here:

  answer = (*(((int *)&tmp)+1) >> 31) & 1;
^

[Bug bootstrap/48964] [4.7 Regression] LTO profiledbootstrap failure

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2011-05-11 
15:45:02 UTC ---
Author: rguenth
Date: Wed May 11 15:44:59 2011
New Revision: 173663

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173663
Log:
2011-05-11  Richard Guenther  

PR middle-end/48964
* gimple.c (iterative_hash_canonical_type): Fix typo.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple.c

[Bug bootstrap/48964] [4.7 Regression] LTO profiledbootstrap failure

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Richard Guenther  2011-05-11 
15:46:29 UTC ---
Fixed.

[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2011-05-11 
15:59:45 UTC ---
Question: Does it work with .true.? I think the output is perfectly valid if
the execution itself failed (and not just the asynchronous execution).


On Linux, I would suspect that the current directory (".") is not in the search
path ("$PATH"), but I don't know how it works under windows.

Thus, please double check that (a) the executable is there, (b) it is in the
search patch, and (c) the execution works with ".true.".


In either case (wait=.true. or .false.), the "system" function is called; I do
not see a reason why it should fail for the forked version (wait=.false.) but
work for the not forked one (wait=.true.).

The source code of the function is at:
http://gcc.gnu.org/viewcvs/trunk/libgfortran/intrinsics/execute_command_line.c?view=markup

[Bug middle-end/48965] [4.7 Regression] FAIL: gcc.dg/pr45055.c

[froydnj at codesourcery dot com]

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

--- Comment #2 from froydnj at codesourcery dot com  2011-05-11 16:21:51 UTC ---
I see this too; it happens about 1 out of every 10 tries.

[Bug middle-end/48965] [4.7 Regression] FAIL: gcc.dg/pr45055.c

[froydnj at codesourcery dot com]

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

--- Comment #3 from froydnj at codesourcery dot com  2011-05-11 16:25:24 UTC ---
Differences between the two .gkd dumps for a failing run:

--- pr45055.gkd2011-05-11 12:23:00.260424961 -0400
+++ pr45055.gk.gkd2011-05-11 12:23:00.370420369 -0400
@@ -1,8 +1,8 @@

  Declarations used by foo, sorted by DECL_UID:
-11:   static int colormap[10];
-9:   extern int bar ();
-5:   void ;
+8:   static int colormap[10];
+6:   extern int bar ();
+4:   void ;
  2:   void ;
  1:   void ;
  0:   void ;

[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW

[thenlich at users dot sourceforge.net]

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

--- Comment #2 from Thomas Henlich  
2011-05-11 16:38:52 UTC ---
The program is executed, as the called program "hello.exe" prints "Hello
world". After that hello.exe returns and the runtime error occurs.

Further testing shows that it is executed synchronously, presumably because
asynchronous execution is not implemented (yet?) on Windows.

[Bug middle-end/48965] [4.7 Regression] FAIL: gcc.dg/pr45055.c

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  2011-05-11 17:05:23 
UTC ---
(In reply to comment #3)
> Differences between the two .gkd dumps for a failing run:
> 
> --- pr45055.gkd2011-05-11 12:23:00.260424961 -0400
> +++ pr45055.gk.gkd2011-05-11 12:23:00.370420369 -0400
> @@ -1,8 +1,8 @@
> 
>   Declarations used by foo, sorted by DECL_UID:
> -11:   static int colormap[10];
> -9:   extern int bar ();
> -5:   void ;
> +8:   static int colormap[10];
> +6:   extern int bar ();
> +4:   void ;
>   2:   void ;
>   1:   void ;
>   0:   void ;

Are there some instabilities in DECL_UID?

[Bug middle-end/48965] [4.7 Regression] FAIL: gcc.dg/pr45055.c

[froydnj at gcc dot gnu.org]

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

--- Comment #5 from Nathan Froyd  2011-05-11 
17:12:57 UTC ---
No.  The list is sorted by UID, but the numbers printed out are not the UID;
they are the order in which things were pushed on to the list.  Full diff, with
duplicate entries and UID information:

--- pr45055.gkd2011-05-11 13:07:54.424168821 -0400
+++ pr45055.gk.gkd2011-05-11 13:07:54.600692860 -0400
@@ -1,30 +1,36 @@

 Declarations used by foo, sorted by DECL_UID:
-8, uid 1559:   static int colormap[10];
 11, uid 1559:   static int colormap[10];
-6, uid 1560:   extern int bar ();
-7, uid 1560:   extern int bar ();
+14, uid 1559:   static int colormap[10];
 9, uid 1560:   extern int bar ();
 10, uid 1560:   extern int bar ();
-19, uid 1560:   extern int bar ();
-21, uid 1560:   extern int bar ();
-23, uid 1560:   extern int bar ();
-4, uid 1577:   void ;
-16, uid 1577:   void ;
-18, uid 1577:   void ;
+12, uid 1560:   extern int bar ();
+13, uid 1560:   extern int bar ();
+25, uid 1560:   extern int bar ();
+27, uid 1560:   extern int bar ();
+29, uid 1560:   extern int bar ();
+5, uid 1577:   void ;
+20, uid 1577:   void ;
+24, uid 1577:   void ;
 2, uid 1578:   void ;
 3, uid 1578:   void ;
-5, uid 1578:   void ;
-14, uid 1578:   void ;
-15, uid 1578:   void ;
+4, uid 1578:   void ;
+6, uid 1578:   void ;
+7, uid 1578:   void ;
+8, uid 1578:   void ;
 17, uid 1578:   void ;
-20, uid 1578:   void ;
+18, uid 1578:   void ;
+19, uid 1578:   void ;
+21, uid 1578:   void ;
+22, uid 1578:   void ;
+23, uid 1578:   void ;
+26, uid 1578:   void ;
 1, uid 1581:   void ;
-13, uid 1581:   void ;
-22, uid 1581:   void ;
+16, uid 1581:   void ;
+28, uid 1581:   void ;
 0, uid 2680:   void ;
-12, uid 2680:   void ;
-24, uid 2680:   void ;
+15, uid 2680:   void ;
+30, uid 2680:   void ;

 ;; Function (foo)

[Bug lto/48947] 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

--- Comment #4 from Vadim Markovtsev  2011-05-11 
17:29:32 UTC ---
I checked those errors with both binutils 2.21 release and 2.22 CVS (10th of
May).


gcc -###
Using built-in specs.
COLLECT_GCC=/???/x86_64-gcc-4.6.0/bin/gcc
COLLECT_LTO_WRAPPER=/???/x86_64-gcc-4.6.0/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/???/x86_64-gcc-4.6.0 --enable-shared
--with-arch=native --enable-languages=c,c++ --enable-lto --enable-plugin
--enable-gold --enable-linker-build-id --disable-multilib --enable-ld=default
--with-plugin-ld=ld.gold
Thread model: posix
gcc version 4.6.0 (GCC)

If you mean CC=gcc -flto -fuse-linker-plugin, I get the same errors.

[Bug debug/48967] New: [4.6/4.7 Regression] ICE during use_narrower_mode

[jakub at gcc dot gnu.org]

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

   Summary: [4.6/4.7 Regression] ICE during use_narrower_mode
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
Target: powerpc64-linux


Created attachment 24224
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24224
rh703888.ii

The attached testcase ICEs in 4.6 and 4.7 with -O2 -g -m64.
The problem is that lowpart_subreg returns NULL, as a SImode subreg of DImode
register 32 (fp0) isn't allowed.

--- var-tracking.c.jj 2011-04-13 14:04:00.0 +0200
+++ var-tracking.c 2011-05-11 18:05:41.0 +0200
@@ -739,6 +739,10 @@ use_narrower_mode_test (rtx *loc, void *
 case REG:
   if (cselib_lookup (*loc, GET_MODE (SUBREG_REG (subreg)), 0, VOIDmode))
 return 1;
+  if (!validate_subreg (GET_MODE (subreg), GET_MODE (*loc),
+*loc, subreg_lowpart_offset (GET_MODE (subreg),
+ GET_MODE (*loc
+return 1;
   return -1;
 case PLUS:
 case MINUS:

seems to fix this and doesn't seem to ever trigger in x86_64-linux bootstrap
(this optimization has been added mainly for x86_64).

[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

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #7 from Georg-Johann Lay  2011-05-11 
17:40:15 UTC ---
Closed as resolved+invalid because PR is an artifact of omitting some
directories.

[Bug debug/48967] [4.6/4.7 Regression] ICE during use_narrower_mode

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.05.11 17:57:44
   Target Milestone|--- |4.6.1
 Ever Confirmed|0   |1

[Bug debug/48967] [4.6/4.7 Regression] ICE during use_narrower_mode

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2011-05-11 
17:56:57 UTC ---
Created attachment 24225
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24225
gcc46-pr48967.patch

Fix.

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

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  2011-05-11 
19:00:06 UTC ---
Hmm... I wonder if this does the trick?  It fixes the test case,
and passes all regression tests... Paul, what do you think?

Index: dependency.c
===
--- dependency.c(Revision 173389)
+++ dependency.c(Arbeitskopie)
@@ -1822,7 +1822,6 @@ gfc_dep_resolver (gfc_ref *lref, gfc_ref *rref, gf
  /* Inhibit loop reversal if dependence not compatible.  */
  if (reverse && reverse[n] != GFC_REVERSE_NOT_SET
&& this_dep != GFC_DEP_EQUAL
-   && this_dep != GFC_DEP_BACKWARD
&& this_dep != GFC_DEP_NODEP)
{
  reverse[n] = GFC_CANNOT_REVERSE;

[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2011-05-11 
19:19:40 UTC ---
Created attachment 24226
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24226
Draft patch (untested)

(In reply to comment #2)
> The program is executed, as the called program "hello.exe" prints "Hello
> world". After that hello.exe returns and the runtime error occurs.

As cmdstat is set to -2, there will be an error in set_cmdstat:

  else if (value != 0)
runtime_error ("Could not execute command line");

The check should be > 0.


> Further testing shows that it is executed synchronously, presumably because
> asynchronous execution is not implemented (yet?) on Windows.

Indeed. That seems to be the problem. fork() does not seem to be supported. Kai
suggests to use _spawnvpe with cmd.exe/command.com

[Bug c/48968] incorrect warning about longjmp/vfork clobbering a local (-W -O2, x86-64)

[eggert at gnu dot org]

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

--- Comment #1 from eggert at gnu dot org 2011-05-11 19:35:32 UTC ---
Created attachment 24227
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24227
gzip-compressed u.i program, illustrating incorrect diagnostic

[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2011-05-11 
19:52:02 UTC ---
Created attachment 24228
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24228
async_system - example program for MinGW by Kai

[Bug c/48968] New: incorrect warning about longjmp/vfork clobbering a local (-W -O2, x86-64)

[eggert at gnu dot org]

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

   Summary: incorrect warning about longjmp/vfork clobbering a
local (-W -O2, x86-64)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: egg...@gnu.org


The attached program u.i, derived from the Emacs trunk,
has code of the following form:

  Lisp_Object XXXevent, tem;

  if (idx < 0)
{
  XXXevent = Qnil;
}
  else
{
  Lisp_Object _l; _l.s.val = idx; _l.s.type = Lisp_Int;
  XXXevent = _l;
}

  if enum Lisp_Type) ((XXXevent)).u.type)) == Lisp_Int)
{
  ...
}

These are the only defs and uses of XXXevent, which is a local
variable of union type.  When compiled with -W -O2 on x86-64,
GCC 4.6.0 complains:

  error: variable 'XXXevent' might be clobbered by 'longjmp' or 'vfork'

But no longjmp or vfork is possible between the time that XXXevent is
set, and the time that it is used.

I worry that this bogus warning is a symptom of deeper problems in
GCC 4.6.0's optimizer.

Here is the full output of:

gcc -v -save-temps -S -W -Wno-missing-field-initializers -Wno-sign-compare
-Werror -O2 u.i

  Using built-in specs.
  COLLECT_GCC=gcc
 
COLLECT_LTO_WRAPPER=/usr/local_cs/linux/gcc-4.6.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
  Target: x86_64-unknown-linux-gnu
  Configured with: ../gcc-4.6.0/configure --prefix=/usr/local/cs/gcc-4.6.0
--with-gmp-include=/usr/local/cs/include --disable-nls
--with-stage1-ldflags='-L/usr/local/cs/lib64 -Xlinker
-rpath=/usr/local/cs/lib64' --with-boot-ldflags='-L/usr/local/cs/lib64 -Xlinker
-rpath=/usr/local/cs/lib64' LDFLAGS='-L/usr/local/cs/lib64 -Xlinker
-rpath=/usr/local/cs/lib64'
  Thread model: posix
  gcc version 4.6.0 (GCC)
  COLLECT_GCC_OPTIONS='-v' '-save-temps' '-S' '-Wextra'
'-Wno-missing-field-initializers' '-Wno-sign-compare' '-Werror' '-O2'
'-mtune=generic' '-march=x86-64'
  
/usr/local_cs/linux/gcc-4.6.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1
-fpreprocessed u.i -quiet -dumpbase u.i -mtune=generic -march=x86-64 -auxbase u
-O2 -Wextra -Wno-missing-field-initializers -Wno-sign-compare -Werror -version
-o u.s
  GNU C (GCC) version 4.6.0 (x86_64-unknown-linux-gnu)
  compiled by GNU C version 4.6.0, GMP version 5.0.2, MPFR version
3.0.1-p4, MPC version 0.9
  GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
  GNU C (GCC) version 4.6.0 (x86_64-unknown-linux-gnu)
  compiled by GNU C version 4.6.0, GMP version 5.0.2, MPFR version
3.0.1-p4, MPC version 0.9
  GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
  Compiler executable checksum: 48a4f3d76c3a714a5f5622b4f42440c5
  u.i: In function 'read_char':
  u.i:60167:20: error: variable 'XXXevent' might be clobbered by 'longjmp' or
'vfork' [-Werror=clobbered]
  cc1: all warnings being treated as errors

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

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  2011-05-11 19:57:21 
UTC ---
Created attachment 24229
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24229
A fix for the PR

This fixes the problem in two steps:
(i) It reverts r162289; and
(ii) It adds the correct initialization for loop.reverse[] in
gfc_trans_assignment_1.  This was implemented incorrectly in the fix for
PR24524 (in spite of the correct comment in dependency.c!) and removed at
sometime, I do not know why.

sigh

Bootstraps and regtests on x86_64/FC9.  I will add a testcase and submit
formally tomorrow night.  There are probably other assignements, such as in FOR
and WHERE blocks that could do with reversing being enabled.  I'll put thinking
cap on after I have fixed this PR.

Paul

[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

--- Comment #7 from Tobias Burnus  2011-05-11 
20:08:59 UTC ---
Author: burnus
Date: Wed May 11 20:08:54 2011
New Revision: 173674

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173674
Log:
2011-05-11  Tobias Burnus  

PR fortran/48889
* expr.c (gfc_is_constant_expr): Use e->value.function.esym
instead of e->symtree->n.sym, if available.

2011-05-11  Tobias Burnus  

PR fortran/48889
* gfortran.dg/generic_24.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/generic_24.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[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 #4 from stevenj at alum dot mit.edu 2011-05-11 20:16:57 UTC ---
Created attachment 24230
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24230
patch to add a -Wconversion warning for complex -> real conversions

I believe the attached patch (against gcc 4.6.0) implements the feature I
requested.  It emits a warning for implicit conversions of complex types to
real (or integer) types.  It also emits a warning for similarly converting
complex constants, unless the imaginary part of the constant is zero in which
case it is treated as a real (or integer) constant given by the real part.

Note that complex->complex conversions are still not checked (e.g. no warning
is given in converting a complex double to a complex float, etcetera), but at
least I didn't add any regressions in that regard.

For example, when compiling the following test file:

#include 
#include 

double foo(double complex z)
{
 complex double zc = 1 + 1i;
 complex double zc0 = 1 + 0i;

 float complex zf = z;

 double x = z;
 float xf = z;
 int i = z;

 double xc = 1 + 1i;
 double xc0 = 1 + 0i;
 int ic = 1.1 + 1.1i;
 int ic0 = 1.1 + 0.0i;

 return sqrt(z) + csqrt(z);
}

with "gcc -Wconversion -c", the unpatched gcc gives no warnings whereas the
patched gcc emits:

complex-Wconversion-tst.c: In function ‘foo’:
complex-Wconversion-tst.c:11:6: warning: conversion to ‘double’ from ‘complex
double’ may alter its value [-Wconversion]
complex-Wconversion-tst.c:12:6: warning: conversion to ‘float’ from ‘complex
double’ may alter its value [-Wconversion]
complex-Wconversion-tst.c:13:6: warning: conversion to ‘int’ from ‘complex
double’ may alter its value [-Wconversion]
complex-Wconversion-tst.c:15:6: warning: conversion to ‘double’ alters ‘complex
int’ constant value [-Wconversion]
complex-Wconversion-tst.c:17:6: warning: conversion to ‘int’ alters ‘complex
double’ constant value [-Wconversion]
complex-Wconversion-tst.c:18:6: warning: conversion to ‘int’ alters ‘double’
constant value [-Wconversion]
complex-Wconversion-tst.c:20:6: warning: conversion to ‘double’ from ‘complex
double’ may alter its value [-Wconversion]
complex-Wconversion-tst.c:20:21: warning: conversion to ‘double’ from ‘complex
double’ may alter its value [-Wconversion]

Note that two warnings are emitted for the last line: one for the implicit
conversion of z to a real number in sqrt(z), and the other for the implicit
conversion of the complex sqrt(z)+csqrt(z) to a real return value of foo(z).

Using creal(...) and/or explicit casts silences the warnings.  Note also that
"double xc0 = 1 + 0i;" correctly yields no warning.

As mentioned above, "float complex zf = z;" and similar complex->complex
conversions probably should emit a warning, but I have not implemented that. 
However, that is not a regression.

--SGJ

[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

--- Comment #8 from Tobias Burnus  2011-05-11 
20:31:17 UTC ---
Author: burnus
Date: Wed May 11 20:31:14 2011
New Revision: 173675

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173675
Log:
2011-05-11  Tobias Burnus  

PR fortran/48889
* expr.c (gfc_is_constant_expr): Use e->value.function.esym
instead of e->symtree->n.sym, if available.

2011-05-11  Tobias Burnus  

PR fortran/48889
* gfortran.dg/generic_24.f90: New.


Added:
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/generic_24.f90
Modified:
branches/gcc-4_6-branch/gcc/fortran/ChangeLog
branches/gcc-4_6-branch/gcc/fortran/expr.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[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

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #9 from Tobias Burnus  2011-05-11 
20:32:08 UTC ---
FIXED on the trunk (4.7) and on the 4.6 branch.

[Bug c++/48969] New: ICE with -std=c++0x

[ajrh at ajrh dot net]

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

   Summary: ICE with -std=c++0x
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@ajrh.net


The file below compiles OK if the -std=c++0x flag is not passed

g++ -c -std=c++0x x.cpp
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report, [...]

===

template struct Pair { };
struct Foo { enum { Mask = 1 }; } foo;
template class Pair operator|(const
A &, const B &)
{
foo | foo;
};

[Bug target/48970] New: Inaccurate comments for processor_costs

[hjl.tools at gmail dot com]

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

   Summary: Inaccurate comments for processor_costs
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com
Target: x86


i386.h has

struct processor_costs {
...
  const int sse_load[3];/* cost of loading SSE register
   in SImode, DImode and TImode*/
  const int sse_store[3];   /* cost of storing SSE register
   in SImode, DImode and TImode*/

But i386.c has
 if (SSE_CLASS_P (regclass))
{
  int index;
  switch (GET_MODE_SIZE (mode))
{ 
  case 4:
index = 0;
break;
  case 8:
index = 1;
break;
  case 16:
index = 2;
break;
  default:
return 100;
} 
  if (in == 2) 
return MAX (ix86_cost->sse_load [index], ix86_cost->sse_store [index]);
  return in ? ix86_cost->sse_load [index] : ix86_cost->sse_store [index];
}

SImode, DImode nor TImode aren't used to compute costs.

[Bug lto/48384] lto, linker-plugin and optimization clutter the stack trace

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||iant at google dot com

--- Comment #5 from Paolo Carlini  2011-05-11 
21:14:50 UTC ---
Ian, could you have a look to this issue (in particular Comment #4)? Should
Vincenzo file a GOLD (binutils) PR? Thanks in advance.

[Bug target/48970] Inaccurate comments for processor_costs

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2011-05-11 21:23:45 
UTC ---
Also

 const int mmxsse_to_integer;  /* cost of moving mmxsse register to
   integer and vice versa.  */

isn't limited to integers:

 /* Moves between SSE/MMX and integer unit are expensive.  */
  if (MMX_CLASS_P (class1) != MMX_CLASS_P (class2)
  || SSE_CLASS_P (class1) != SSE_CLASS_P (class2))

/* ??? By keeping returned value relatively high, we limit the number
   of moves between integer and MMX/SSE registers for all targets.
   Additionally, high value prevents problem with x86_modes_tieable_p(),
   where integer modes in MMX/SSE registers are not tieable
   because of missing QImode and HImode moves to, from or between
   MMX/SSE registers.  */
return MAX (8, ix86_cost->mmxsse_to_integer);

Integer register classes aren't checked at all.

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

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  2011-05-11 
21:30:23 UTC ---
Author: jason
Date: Wed May 11 21:30:18 2011
New Revision: 173683

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173683
Log:
PR c++/48948
* semantics.c (validate_constexpr_fundecl): Defer checking if
an argument type is being defined.
(is_valid_constexpr_fn): Add defer_ok parm.
(cxx_eval_call_expression): Adjust.
(check_deferred_constexpr_decls): New.
(literal_type_p): Make sure type isn't being defined.
(ensure_literal_type_for_constexpr_object): Handle type being defined.
* cp-tree.h: Declare check_deferred_constexpr_decls.
* decl.c (grokfndecl): Call validate_constexpr_fundecl here.
(start_preparsed_function, cp_finish_decl): Not here.
* class.c (finalize_literal_type_property): Don't call
validate_constexpr_fundecl.
(finish_struct): Call check_deferred_constexpr_decls.
* pt.c (tsubst_decl): Call validate_constexpr_fundecl.
(instantiate_class_template): Call check_deferred_constexpr_decls.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-friend.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-incomplete1.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/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/48745] [C++0x] Segmentation fault with list-initialization, void initializers and variadics

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-05-11 
21:29:40 UTC ---
Author: jason
Date: Wed May 11 21:29:35 2011
New Revision: 173678

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173678
Log:
PR c++/48745
* pt.c (value_dependent_expr_p): Handle CONSTRUCTOR.

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

[Bug bootstrap/48971] New: sparc-rtems does not build

[joel at gcc dot gnu.org]

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

   Summary: sparc-rtems does not build
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org


As of yesterday's SVN, gcc is very broken for sparc-rtems.  The generated gcc
can't even compile a simple autoconf probe.  I would expect that sparc-elf is
similarly broken.  This was built with a native built from the same source. 
That reports

gcc (GCC) 4.7.0 20110510 (experimental) [trunk revision 173623]


This is from config.log.  Let me know what else I can provide.

configure:3246: checking for suffix of object files
configure:3268: /home2/joel/build/b-sparc-gcc/./gcc/xgcc
-B/home2/joel/build/b-sparc-gcc/./gcc/ -nostdinc
-B/home2/joel/build/b-sparc-gcc/sparc-rtems4.11/soft/newlib/ -isystem
/home2/joel/build/b-sparc-gcc/sparc-rtems4.11/soft/newlib/targ-include -isystem
/users/joel/test-gcc/gcc-svn/newlib/libc/include
-B/home2/joel/build/b-sparc-gcc/sparc-rtems4.11/soft/libgloss/sparc
-L/home2/joel/build/b-sparc-gcc/sparc-rtems4.11/soft/libgloss/libnosys
-L/users/joel/test-gcc/gcc-svn/libgloss/sparc
-B/users/joel/test-gcc/install-svn/sparc-rtems4.11/bin/
-B/users/joel/test-gcc/install-svn/sparc-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-svn/sparc-rtems4.11/include -isystem
/users/joel/test-gcc/install-svn/sparc-rtems4.11/sys-include  -msoft-float -c
-g -O2  conftest.c >&5
conftest.c:1:0: internal compiler error: in setup_pressure_classes, at
ira.c:877
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:3272: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3286: error: in
`/home2/joel/build/b-sparc-gcc/sparc-rtems4.11/soft/libgcc':
configure:3289: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

[Bug fortran/48972] New: OPEN with Unicode file name

[burnus at gcc dot gnu.org]

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

   Summary: OPEN with Unicode file name
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: jvdeli...@gcc.gnu.org


This PR is motivated by the thread which started at
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=COMP-FORTRAN-90;59308f3c.1105


GNU Fortran happily accepts kind=4 character strings to the FILE= argument of
the OPEN statement - and probably also to the other string arguments.

However, the Fortran 2008 standard has:

  R905 connect-spec is
...
   or   FILE = file-name-expr
with
  R906 file-name-expr is scalar-default-char-expr

Thus, such strings should be rejected -- at least with -std=f2008.

 * * *

Independent of that, it would be convenient if as vendor extension passing a
UCS-4 string would be allowed. The only problem is how it should be handled in
the library.

For Unix systems, I think converting the UCS-4 to UTF-8 and using it in the
normal file open should work.

However, for Windows, I think one needs a special solution as Windows seems to
use UTF-16 everywhere [1]. Thus, one should be able to directly pass the UCS-16
file name to CreateFileW [2].

[1] http://msdn.microsoft.com/en-us/library/dd374081%28v=vs.85%29.aspx
[2] http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx



Example program. Sample usage:
  $ gfortran test.f90
  $ ./a.out 
  Enter filename: ファイル
  $

Should create "ファイル.dat" with the content "Hello World and Ni Hao -- 你好" - the
latter works but the file name is as written above "?" (= \343). If one passes
"44", the created file is just "4".


use iso_fortran_env
implicit none
integer, parameter :: ucs4  = selected_char_kind ('ISO_10646')
character(len=30, kind=ucs4) :: str
integer :: unit

open(unit=INPUT_UNIT, encoding='utf-8')
write(*, '(a)', advance='no') 'Enter filename: '
read(*,*) str
open(newunit=unit, file=trim(str)//ucs4_'.dat', encoding='utf-8')
write(unit, '(a)') ucs4_'Hello World and Ni Hao -- ' &
   // char (int (z'4F60'), ucs4) &
   // char (int (z'597D'), ucs4)
close(unit)
end

[Bug lto/48423] crash when using lto, linker plugin with bfd ld

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2011-05-11 
21:19:10 UTC ---
HJ, sorry, I'm not sure to understand the process: do you normally submit this
kind of fix also to the "mainline" binutils? Can Vincenzo do something specific
to help the process? (about the GOLD-related issue (PR48384) I'm asking Ian's
opinion in that audit trail)

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

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |stevenj at alum dot mit.edu
   |gnu.org |

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

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  2011-05-11 
21:57:54 UTC ---
(In reply to comment #4)
> Created attachment 24230 [details]
> patch to add a -Wconversion warning for complex -> real conversions
> 
> I believe the attached patch (against gcc 4.6.0) implements the feature I
> requested.  It emits a warning for implicit conversions of complex types to
> real (or integer) types.  It also emits a warning for similarly converting
> complex constants, unless the imaginary part of the constant is zero in which
> case it is treated as a real (or integer) constant given by the real part.

Nice! The patch looks almost ok but I cannot approve it. 

Some small issues:

* The code must follow GCC style, which is described in detail here
http://gcc.gnu.org/contribute.html#standards, but it is just easier too look
code around and follow the same style for braces, comments (they have to start
uppercase and end with a period), you have to add /* Fall through. */ to mark
deliberate fall-through in switches, etc.

* I would say (TREE_CODE (type) != COMPLEX_TYPE) rather than (!(TREE_CODE
(type) == COMPLEX_TYPE)). Even better, test first that == COMPLEX_TYPE, if so
you can return, otherwise, the zero imaginary part, else warning. Does that
sound right?

* You need to add the testcase to the testsuite. Look in
testsuite/gcc.dg/c-c++-common/Wconversion-real.c for an example. More info:
http://gcc.gnu.org/wiki/HowToPrepareATestcase

* Patches should be always be done against a recent SVN revision. I think this
patch should be safe to backport to GCC 4.6, but perhaps the release managers
may disagree (it does generate new warnings, which some people may find
bothersome if they use -Werror).

* Patches need to be bootstrapped and regression tested:
http://gcc.gnu.org/contribute.html#testing . There are scripts that mostly
automate this process. Take a look at contrib/ or this script of mine:
http://gcc.gnu.org/wiki/ManuelL%C3%B3pezIb%C3%A1%C3%B1ez?action=AttachFile&do=view&target=gccfarming

* Finally, patches should be sent to gcc-patc...@gcc.gnu.org with a Changelog.
Take a look at the archives to have an idea of the proper way:
http://gcc.gnu.org/ml/gcc-patches/2011-05/

[Bug lto/48423] crash when using lto, linker plugin with bfd ld

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  2011-05-11 22:30:32 
UTC ---
(In reply to comment #5)
> HJ, sorry, I'm not sure to understand the process: do you normally submit this
> kind of fix also to the "mainline" binutils? Can Vincenzo do something 
> specific
> to help the process? (about the GOLD-related issue (PR48384) I'm asking Ian's
> opinion in that audit trail)

I think the current binutils in CVS is OK.

[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2011-05-11 
22:27:03 UTC ---
Patch: http://gcc.gnu.org/ml/fortran/2011-05/msg00087.html

Regarding the implementation of true async on Windows: One should also remember
to update
http://gcc.gnu.org/onlinedocs/gfortran/EXECUTE_005fCOMMAND_005fLINE.html, if
one uses _spawnvpe (w/ command.exe/cmd.exe) instead of system() on Windows,
though the current wording might be sufficient.

[Bug c++/48969] ICE with -std=c++0x

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.11 22:30:49
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1

[Bug tree-optimization/48973] New: Inliner bug with one-bit (1-bit) bitfield

[arthur.j.odwyer at gmail dot com]

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

   Summary: Inliner bug with one-bit (1-bit) bitfield
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arthur.j.odw...@gmail.com


Created attachment 24231
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24231
Output of "ajo-gcc -w -O1 -finline-small-functions test.c -v"

This reproduces for me with svn revision 173589 (2011-05-09). Since this
reproduces all the way back to 4.4, it *must* be a duplicate of *something*,
but I didn't find anything likely-looking in a Bugzilla search. I'm on Ubuntu
10.10, x86-64.

cat >test.c < 0;
}
int main() {
func_46(-1);
printf("%x\n", (unsigned int)(g_72.f0));
return 0;
}
EOF
gcc -w -O1 test.c -o a.out ; ./a.out
gcc -w -O2 test.c -o a.out ; ./a.out

REDUCED: gcc -w -O1 -finline-small-functions test.c -o a.out ; ./a.out

With -O1 the output is "". With -O2 the output is "1". g_72.f0 should
evaluate to -1, and then casting that to (unsigned int) should always yield
0x regardless of optimization level. This looks to me like an inliner
bug.

In gcc 4.4.5 and 4.5.1, the bug also reproduces when you use "f4" instead of
"f5" inside func_46(). In trunk, you need to use a global variable to see the
bug.

This test case is reduced from the output of Csmith 2.1.0 (git hash 541a6480,
https://github.com/csmith-project/csmith/), using the following command line:
csmith --no-paranoid --no-longlong --no-pointers --arrays --no-jumps --consts
--no-volatiles --checksum --no-divs --no-muls --bitfields --packed-struct -s
1281232940

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

[jason at gcc dot gnu.org]

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

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 #8 from Jason Merrill  2011-05-12 
01:40:30 UTC ---
Fixed.

[Bug c++/48745] [C++0x] Segmentation fault with list-initialization, void initializers and variadics

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  2011-05-12 
01:41:26 UTC ---
Fixed.

[Bug target/48974] VIS intrinsics improvement opportunities

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.12 05:19:49
 Ever Confirmed|0   |1

[Bug target/48974] New: VIS intrinsics improvement opportunities

[hp at gcc dot gnu.org]

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

   Summary: VIS intrinsics improvement opportunities
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: h...@gcc.gnu.org
Target: sparc64-*-*


While writing a VIS backend for RAPP,
http://savannah.nongnu.org/projects/rapp/ using gcc54 at the compilefarm I
noticed a few omissions and opportunities for improvements.  I just thought
adding some notes here would be better than nothing, before I forget.

1. The insns fone / fones are unused (in contrast to fzero / fzeros).

2. The implicit dependency on the GSR control register from the fpack* and
faligndata insns aren't expressed in the intrinsics. There's also no way to set
GSR other than through an asm (or by __builtin_vis_alignaddr, for the
side-effect of setting the GSR.alignaddr_offset field).  This makes those
intrinsics next to useless compared to naked asms.  An intuitive way to set GSR
for those intrinsics would be as a parameter to the fpack* and faligndata
intrinsics (or rather, new variants), and generating a CSE:able setting of GSR
when expanding the intrinsic (and changing the __builtin_vis_alignaddr to be a
parallel, setting the same pseudo or just clobbering it).  See the
initial-value machinery and its use in various ports for managing a suitable
pseudo for a hard-register; get_hard_reg_initial_val and friends.

[Bug c++/47453] Various non-conforming behaviors with braced-init-list initialization

[schaub.johannes at googlemail dot com]

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

--- Comment #3 from Johannes Schaub  
2011-05-12 05:23:15 UTC ---
I think we have the FDIS clear about these cases now. To update:

// invalid
struct A { int a[2]; A():a({1, 2}) { } };

// invalid
int a({0});

// invalid
int const &b({0});

struct A { explicit A(int, int); A(int, long); };

// invalid
A c({1, 2});

// valid (by copy constructor).
A d({1, 2L});

// valid
A e{1, 2};

struct B { 
  template
  B(initializer_list, T ...); 
};

// invalid (the first phase only considers init-list ctors)
// (for the second phase, no constructor is viable)
B f{1, 2, 3};

// valid (T deduced to <>).
B g({1, 2, 3});

[Bug ada/34898] Excessive memory consumption during compilation

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #18 from Eric Botcazou  2011-05-12 
05:44:25 UTC ---
Too many layers of variant parts with too many components in them.

[Bug fortran/48972] OPEN with Unicode file name

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2011-05-12 
06:15:57 UTC ---
For the diagnostic, the following untested patch should do. For Unicode
file-name support more work needs to be done ...

--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -1478,6 +1478,13 @@ resolve_tag (const io_tag *tag, gfc_expr *e)
   return FAILURE;
 }

+  if (e->ts.type == BT_CHARACTER && e->ts.kind != gfc_default_character_kind)
+{
+  gfc_error ("%s tag at %L must be a character string of default kind",
+tag->name, &e->where);
+  return FAILURE;
+}
+
   if (e->rank != 0)
 {
   gfc_error ("%s tag at %L must be scalar", tag->name, &e->where);

[Bug rtl-optimization/48971] [4.7 regression] ICE with -msoft-float -O2

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Target||sparc-*-*
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
   Last reconfirmed||2011.05.12 06:56:03
  Component|bootstrap   |rtl-optimization
 CC||ebotcazou at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1
Summary|sparc-rtems does not build  |[4.7 regression] ICE with
   ||-msoft-float -O2
   Severity|critical|normal

--- Comment #1 from Eric Botcazou  2011-05-12 
06:56:03 UTC ---
This is -msoft-float though.  Again recent IRA changes I'm afraid...