[Bug fortran/49638] New: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

[boschmann at tp1 dot physik.uni-siegen.de]

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

   Summary: [OOP] length parameter is ignored when overriding type
bound character functions with constant length.
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boschm...@tp1.physik.uni-siegen.de


module world
  implicit none
  type::world_1
   contains
 procedure,nopass::string=>w1_string
  end type world_1
  type,extends(world_1)::world_2
   contains
 procedure,nopass::string=>w2_string
  end type world_2
contains
  function w1_string()
character(6)::w1_string
w1_string=" world"
  end function w1_string
  function w2_string()
character(7)::w2_string
w2_string=" world2"
  end function w2_string
end module world
program hello
  use world
  implicit none
  type(world_1)::w1
  type(world_2)::w2
  print *,"hello world: hello",w1%string()
  print *,"hello world2: hello",w2%string()
end program hello

This program compiles and runs fine with gfortran 4.6.1 and gfortran 4.7.
Nevertheless, the length of an array is a type parameter and all type
parameters of an overriding function shall match the overridden type
parameters.

[Bug middle-end/49628] [4.7 Regression] 447.dealII in SPEC CPU 2006 failed to build

[irar at il dot ibm.com]

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

--- Comment #6 from Ira Rosen  2011-07-05 08:18:09 UTC 
---
Sorry, I was wrong about group size check. It is ok without your patch. So,
this should be enough:

Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c   (revision 175785)
+++ tree-vect-data-refs.c   (working copy)
@@ -2304,7 +2304,10 @@ vect_analyze_data_ref_access (struct dat

   /* Allow invariant loads in loops.  */
   if (loop_vinfo && dr_step == 0)
-return DR_IS_READ (dr);
+{
+  GROUP_FIRST_ELEMENT (vinfo_for_stmt (stmt)) = NULL;
+  return DR_IS_READ (dr);
+}

   if (loop && nested_in_vect_loop_p (loop, stmt))
 {

Thanks,
Ira

[Bug tree-optimization/49632] ICE in compute_affine_dependence (tree-data-ref.c:4038) with -O3

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #1 from Richard Guenther  2011-07-05 
08:28:27 UTC ---
Sebastian should know.

[Bug target/38342] [4.4/4.5/4.6/4.7 Regression] __attribute__((__progmem__)) not propagated from typedef to data

[gjl at gcc dot gnu.org]

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

--- Comment #11 from Georg-Johann Lay  2011-07-05 
08:43:17 UTC ---
(In reply to comment #10)
> I was using documented avr-libc features.  Does that mean that this is an
> avr-libc bug rather than a gcc bug?  Neither of the web pages you reference
> mention "progmem" or even AVR at all...

As I wrote, the linked pages show that progmem is not documented for types.
For progmem on variables, you have to switch to the "Specifying Attributes of
Variables" section of user manual:

trunk:
http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#Variable-Attributes

or, e.g. 4.5.2:
http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Variable-Attributes.html#Variable-Attributes

The AVR section is at the end of the page, dunno why the ordering is not
correct.

I just can speculate about the reason why these types are defined in avr-libc,
I guess it's for historical reasons and legacy code.

avr-libc cannot ensure a feature that avr-gcc does not provide.

It's agreed by the avr maintainers to do nothing about that, so the only thing
that could help you to find respective flaces in your sources would be a
typedef like

typedef char __attribute__((progmem,deprecated("attribute 'progmem' in typedef
is an undocumented feature"))) prog_char;

in avr-libc that triggered a diagnostic:

foo.c:4:17: warning: 'prog_char' is deprecated (declared at foo.c:2): attribute
'progmem' in typedef is an undocumented feature [-Wdeprecated-declarations]

However, that won't help with your own typedefs.

At current, progmem for types appears to work for C and not to work for C++,
but that can change in the future.

[Bug middle-end/49628] [4.7 Regression] 447.dealII in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2011-07-05 
08:53:46 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> 
> > I wonder where we are supposed to set GROUP_SIZE here 
> In vect_analyze_data_ref_access(),
> but your patch does this:
> 
>   /* Allow invariant loads in loops.  */
>   if (loop_vinfo && dr_step == 0)
> return DR_IS_READ (dr);
> 
> preventing detection of interleaving groups for invariant loads. Which is ok,
> since you don't support them anyway.

Yeah, I noticed we don't vectorize loops similar to

struct X { float values[4]; };
void foo (struct X * dst, struct X * src, int n)
{
  int i;
  for (i = 0; i < n; ++i)
{
  dst->values[i*4] = src->values[0];
  dst->values[i*4+1] = src->values[1];
  dst->values[i*4+2] = src->values[2];
  dst->values[i*4+3] = src->values[3];
}
}

with different reasons based on the signedness of i (ugh).  We do vectorize
the above with SLP when LIM/PRE move the loads from src out of the loop
though.

[Bug fortran/49636] Associate construct confused with slightly complicated case

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||burnus at gcc dot gnu.org
 Depends on||37577

--- Comment #2 from Tobias Burnus  2011-07-05 
09:05:46 UTC ---
I think this is one of the bugs, which depend on a new array descriptor (cf.
http://gcc.gnu.org/wiki/ArrayDescriptorUpdate).

The problem is that for
associate (i=>t2%j%i)
the array
  i(1:3)
is not contiguous in memory. In the current array descriptor implementation,
only arrays with strides which are multiples of the block are possible - that's
fine grained enough if there is only "integer :: i" but no longer if there is
also another element ("integer :: k"). In that case, one needs to have strides
which are byte-based ("stride multiplier")

It is rather high on the to-do list of gfortran, but as the patch will be
invasive and will have to be done at once as it breaks the ABI (i.e. the
downward compatibility), it is still pending. The idea is that one will use a
descriptor which is compatible with the upcomming TR 29113. (TR = Technical
Report, small standard extension which will be also integrated in the next
Fortran standard.)

Cf. http://gcc.gnu.org/wiki/ArrayDescriptorUpdate

Given some other larger on-going projects, the lack of time of some core
developers and given that GCC 4.7 will probably already branched in September
combined with the need for ABI breakage [which should happen only once], I fear
it won't be fixed for 4.7 but only later. :-(

[Bug c++/49639] New: [4.7 Regression] 447.dealII in SPEC CPU 2006 runtime fail

[kirill.yukhin at intel dot com]

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

   Summary: [4.7 Regression] 447.dealII in SPEC CPU 2006 runtime
fail
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kirill.yuk...@intel.com


Created attachment 24687
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24687
Build log

Hi,
I've built 447.dealII without optimizations (g++ -O0 -c ...)
And got segmentation fault.
This fail starts from this checkin
http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00832.html

Here is BT
$ gdb ./dealII
^[[?1034hGNU gdb (GDB) Fedora (7.2-51.fc14)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from
/export/users/kyukhin/specs/spec2006_w/benchspec/CPU2006/447.dealII/build/t/dealII...(no
debugging symbo\
ls found)...done.
(gdb) r
Starting program:
/export/users/kyukhin/specs/spec2006_w/benchspec/CPU2006/447.dealII/build/t/dealII

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
Missing separate debuginfos, use: debuginfo-install glibc-2.13-1.x86_64
(gdb) bt
#0  0x in ?? ()
#1  0x0059ac1c in
internal::GridReordering3d::Mesh::build_connectivity() ()
#2  0x0059a805 in
internal::GridReordering3d::Mesh::Mesh(std::vector,
std::allocator > > cons\
t&) ()
#3  0x0059af80 in
internal::GridReordering3d::Orienter::Orienter(std::vector,
std::allocator \
> > const&) ()
#4  0x0059b021 in
internal::GridReordering3d::Orienter::orient_mesh(std::vector,
std::allocator > >&) ()
#5  0x0059bb2e in
GridReordering<3>::reorder_cells(std::vector,
std::allocator > >&) ()
#6  0x0057e839 in GridGenerator::hyper_ball(Triangulation<3>&, Point<3>
const&, double) ()
#7  0x00643aa2 in
Data::Exercise_2_3<3>::create_coarse_grid(Triangulation<3>&) ()
#8  0x00649612 in Data::SetUp,
3>::create_coarse_grid(Triangulation<3>&) const ()
#9  0x00644a8d in Framework<3>::run(Framework<3>::ProblemDescription
const&) ()
#10 0x00643d92 in main ()

Seems we have a zero-pointed call:
(gdb) fr 1
#1  0x0059ac1c in
internal::GridReordering3d::Mesh::build_connectivity() ()
(gdb) disassemble
...
   0x0059ac14 <+574>:   mov%rax,%rdi
   0x0059ac17 <+577>:   callq  0x0
=> 0x0059ac1c <+582>:   movl   $0x0,-0x6c(%rbp)
   0x0059ac23 <+589>:   mov-0x40(%rbp),%esi
...

[Bug target/43052] Inline memcmp is *much* slower than glibc's

[hubicka at ucw dot cz]

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

--- Comment #15 from Jan Hubicka  2011-07-05 11:08:50 
UTC ---
> 
> Do you think you could spin a script which also tests memcmp?
memcmp is different story.  Few years back I rewrote memcpy/memset codegen to
allow choosing
from several basic implementations based on size. The script I attached is
basically
testing the individual algorithm so you can set for each CPU target a table
choosing best
performing one for given size.

memcmp is still produced in very stupid way.  Sane inline implementations of
memcmp are harder than memcpy/memset.  I will try to look into it and how
current recommended codegens look for AMD/Intel chips.

Honza

[Bug middle-end/49628] [4.7 Regression] 447.dealII in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2011-07-05 
11:24:30 UTC ---
Author: rguenth
Date: Tue Jul  5 11:24:26 2011
New Revision: 175847

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

PR tree-optimization/49518
PR tree-optimization/49628
* tree-vect-data-refs.c (vect_enhance_data_refs_alignment): Skip
irrelevant and invariant data-references.
(vect_analyze_data_ref_access): For invariant loads clear the
group association.

* g++.dg/torture/pr49628.C: New testcase.
* gcc.dg/torture/pr49518.c: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr49628.C
trunk/gcc/testsuite/gcc.dg/torture/pr49518.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c

[Bug tree-optimization/49518] [4.6 Regression] ICE in vect_enhance_data_refs_alignment, at tree-vect-data-refs.c:1555

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Known to work||4.7.0
Summary|[4.6/4.7 Regression] ICE in |[4.6 Regression] ICE in
   |vect_enhance_data_refs_alig |vect_enhance_data_refs_alig
   |nment, at   |nment, at
   |tree-vect-data-refs.c:1555  |tree-vect-data-refs.c:1555

--- Comment #8 from Richard Guenther  2011-07-05 
11:25:23 UTC ---
Fixed on trunk sofar.

[Bug middle-end/49628] [4.7 Regression] 447.dealII in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Richard Guenther  2011-07-05 
11:25:45 UTC ---
Fixed.

[Bug tree-optimization/49518] [4.6/4.7 Regression] ICE in vect_enhance_data_refs_alignment, at tree-vect-data-refs.c:1555

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2011-07-05 
11:24:30 UTC ---
Author: rguenth
Date: Tue Jul  5 11:24:26 2011
New Revision: 175847

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

PR tree-optimization/49518
PR tree-optimization/49628
* tree-vect-data-refs.c (vect_enhance_data_refs_alignment): Skip
irrelevant and invariant data-references.
(vect_analyze_data_ref_access): For invariant loads clear the
group association.

* g++.dg/torture/pr49628.C: New testcase.
* gcc.dg/torture/pr49518.c: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr49628.C
trunk/gcc/testsuite/gcc.dg/torture/pr49518.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c

[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #64 from John David Anglin  2011-07-05 
11:31:17 UTC ---
(In reply to comment #61)
> > On Linux/x86, I got
> >
> > FAIL: gfortran.dg/coarray_lock_3.f90  -O   (test for errors, line 72)
> 
> On x86_64-apple-darwin10 too. The following reduced code does not give the
> expected error:
> 
> subroutine lock_test2
>   use iso_fortran_env
>   implicit none
>   type t
>   end type t
>   type(t) :: x
>   type(lock_type), save :: lock[*],lock2(2)[*]
>   lock(lock)
>   lock(lock2(1))
>   lock(lock[1]) ! { dg-error "must be a scalar coarray of type LOCK_TYPE" } !
> <-- no error
> end subroutine lock_test2

Same on hppa64-hp-hpux11.11.

[Bug middle-end/49640] New: Internal compiler in C99 code (using variable-length arrays) and OpenMP

[doriankrause at web dot de]

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

   Summary: Internal compiler in C99 code (using variable-length
arrays) and OpenMP
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: doriankra...@web.de


Hello,

the attached code fails to compile with gcc 4.5.0 when enabling OpenMP:

[kraused@cub ~]$ gcc -c -std=gnu99 test.c
[kraused@cub ~]$ gcc -c -std=gnu99 -fopenmp test.c
test.c: In function 'convert_u8_f32.omp_fn.0':
test.c:31:9: internal compiler error: in expand_one_var, at cfgexpand.c:953
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The gcc version is 4.5.0:

[kraused@cub ~]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/share/apps/gcc/4.5.0/gcc_412/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/share/apps/gcc/4.5.0/gcc_412
--with-mpfr=/share/apps/mpfr/2.4.2/gcc_412
--with-gmp=/share/apps/gmp/5.0.1/gcc_412
--with-mpc=/share/apps/mpc/0.8.2/gcc_412 --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.5.0 (GCC) 


Btw. the code also fails to compile with the 4.1.2 gcc on my RHEL box:

[kraused@icsprec03 ~]$ gcc -c -std=gnu99 -fopenmp convert.c 
convert.c: In function ‘convert_u8_s32.omp_fn.0’:
convert.c:27: internal compiler error: in make_decl_rtl, at varasm.c:893
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/ccsIbyBy.out file, please attach this to
your bugreport.
[kraused@icsprec03 ~]$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --disable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)


Unfortunately I don't have a newer gcc available right now for testing.

[Bug middle-end/49640] Internal compiler in C99 code (using variable-length arrays) and OpenMP

[doriankrause at web dot de]

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

--- Comment #1 from doriankrause at web dot de 2011-07-05 11:49:09 UTC ---
Created attachment 24688
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24688
The test code

[Bug target/49641] New: [ARM] Wrong code for ARMv4T and stmia

[sebastian.hu...@embedded-brains.de]

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

   Summary: [ARM] Wrong code for ARMv4T and stmia
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.hu...@embedded-brains.de
Target: arm-rtemseabi4.11


Created attachment 24689
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24689
Sample code.

The attached source code generates the following assembler code:

 <_Watchdog_Handler_initialization>:
   0:   2200movsr2, #0
   2:   4b06ldr r3, [pc, #24]   ; (1c
<_Watchdog_Handler_initialization+0x1c>)
   4:   601astr r2, [r3, #0]
   6:   4b06ldr r3, [pc, #24]   ; (20
<_Watchdog_Handler_initialization+0x20>)
   8:   601astr r2, [r3, #0]
   a:   4b06ldr r3, [pc, #24]   ; (24
<_Watchdog_Handler_initialization+0x24>)
   c:   601astr r2, [r3, #0]
   e:   4b06ldr r3, [pc, #24]   ; (28
<_Watchdog_Handler_initialization+0x28>)
  10:   1d19addsr1, r3, #4
  12:   c30estmia   r3!, {r1, r2, r3}
  14:   4b05ldr r3, [pc, #20]   ; (2c
<_Watchdog_Handler_initialization+0x2c>)
  16:   1d19addsr1, r3, #4
  18:   c30estmia   r3!, {r1, r2, r3}
  1a:   4770bx  lr

In particular it generates: stmia r3!, {r1, r2, r3}

This instruction leads to UNPREDICTABLE behavior.  According to "ARM
Architecture Reference Manual, Issue I" we have in section "A7.1.57 STMIA",
"Operand restrictions":

"If  is specified in :
 o If  is the lowest-numbered register specified in , the
original value of  is stored.
 o Otherwise, the stored value of  is UNPREDICTABLE."

Since r3 is not the lowest-numbered register specified in {r1, r2, r3} the
stored value of r3 is UNPREDICTABLE.

[Bug c/49642] New: constant part of a macro not optimized away as expected due to splitter

[marcus at jet dot franken.de]

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

   Summary: constant part of a macro not optimized away as
expected due to splitter
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@jet.franken.de


my Linux kernel builds on gcc 4.6 pcc64 fail with:

ERROR: ".ilog2_NaN" [drivers/infiniband/hw/ehca/ib_ehca.ko] undefined!

This comes from include/linux/log2.h which uses a large macro with
builtin_constant_p() to optimize constant ilog2 calls.

I have reduced it to the attached testcase.

$ gcc -m64 -O2 -fno-inline-functions-called-once -c ehca_mrmw.i ; objdump -dr
ehca_mrmw.o |grep NaN
1a8: R_PPC64_REL24  ilog2_NaN
1cc: R_PPC64_REL24  ilog2_NaN
$ 

It should not report NaN as that is in a if
(__builtin_constant_p(shca->hca_cap_mr_pgsize)) expression.

[Bug c/49642] constant part of a macro not optimized away as expected due to splitter

[marcus at jet dot franken.de]

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

--- Comment #1 from marcus at jet dot franken.de 2011-07-05 12:41:05 UTC ---
Created attachment 24690
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24690
ehca_mrmw.i

gcc -m64 -O2 -fno-inline-functions-called-once -c ehca_mrmw.i ; objdump -dr
ehca_mrmw.o |grep NaN

should not report:
1a8: R_PPC64_REL24  ilog2_NaN

[Bug c++/49637] template function overload incorrectly ambiguous

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  2011-07-05 
12:42:26 UTC ---
(In reply to comment #0)
> Earlier version of g++ did not produce this error.

G++ 4.5.2 does, as does Clang++. Comeau online accepts it.

[Bug c/49642] constant part of a macro not optimized away as expected due to splitter

[marcus at jet dot franken.de]

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

--- Comment #2 from marcus at jet dot franken.de 2011-07-05 12:42:28 UTC ---
looking at the assembly, both x() and y() call the assembler functions,
just the static function is still emitted with
 <.ehca_get_max_hwpage_size.part.0>:

name. This instance could probably be safely deleted.

[Bug rtl-optimization/47449] [x32] can’t find a register in class ‘DIREG’ while reloading ‘asm’

[hjl at gcc dot gnu.org]

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

--- Comment #13 from hjl at gcc dot gnu.org  2011-07-05 
12:47:38 UTC ---
Author: hjl
Date: Tue Jul  5 12:47:35 2011
New Revision: 175849

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175849
Log:
Don't propagate hard registers in forward_propagate_subreg.

2011-07-05  H.J. Lu  

PR rtl-optimization/47449
* fwprop.c (forward_propagate_subreg): Don't propagate hard
register nor zero/sign extended hard register.

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

[Bug tree-optimization/49642] constant part of a macro not optimized away as expected due to splitter

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.05 12:59:02
 CC||hubicka at gcc dot gnu.org
  Component|c   |tree-optimization
Version|tree-ssa|4.6.1
 Ever Confirmed|0   |1

--- Comment #3 from Richard Guenther  2011-07-05 
12:59:02 UTC ---
Confirmed.

Honza - we split a __builtin_constant_p guarded section away, not killing off
the not needed constant case as we process final optimizations in the wrong
order (thus we don't see the function is unused soon enough).

I think it isn't a good idea to split away any code dominated by such
call.  The testcase is basically

int foo(int arg)
{
 if (__builtin_constant_p (arg))
   {
 if (arg == 10)
   return 1;
 return unreachable ();
   }
 return arg;
}

and we split it as

int foo (int arg)
{
  if (__builtin_constant_p (arg))
return foo.part (arg);
  return arg;
}

[Bug rtl-optimization/47449] [x32] can’t find a register in class ‘DIREG’ while reloading ‘asm’

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #14 from H.J. Lu  2011-07-05 13:14:59 
UTC ---
Fixed.

[Bug rtl-optimization/36884] ifcvt poor optimization

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay  2011-07-05 
13:20:15 UTC ---
Created attachment 24691
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24691
C Testcase pr36884.c

This testcase shows the dis-optimization in 4.7. trunk

==
Compiled with -O2 -S:

swap:
mov r18,r25
rol r18
clr r18
rol r18
ldi r19,lo8(0)
clr __tmp_reg__
lsr r19
ror r18
ror __tmp_reg__
lsr r19
ror r18
ror __tmp_reg__
mov r19,r18
mov r18,__tmp_reg__
sbrc r25,6
ori r19,hi8(8192)
.L3:
sbrc r25,5
ori r19,hi8(16384)
.L4:
sbrc r25,4
ori r19,hi8(-32768)
.L5:
mov r24,r18
mov r25,r19
ret

==
Compiled with -O2 -S -fno-if-conversion:

swap:
sbrc r25,7
rjmp .L6
ldi r18,lo8(0)
ldi r19,hi8(0)
.L2:
sbrc r25,6
ori r19,hi8(8192)
.L3:
sbrc r25,5
ori r19,hi8(16384)
.L4:
sbrc r25,4
ori r19,hi8(-32768)
.L5:
mov r24,r18
mov r25,r19
ret
.L6:
ldi r18,lo8(64)
ldi r19,hi8(64)
rjmp .L2

==

The compiler does a lengthy extract and reuse of the MSB.

[Bug rtl-optimization/36884] ifcvt poor optimization

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

--- Comment #5 from Georg-Johann Lay  2011-07-05 
13:22:53 UTC ---
I had a look in ifcvt.c.

Obviously, noce_try_sign_mask does it's work unconditionally and does not take
into account costs.  It appears that it assumes that cheap barrel shifter is
available as on most 32-bit machines.

[Bug testsuite/49643] New: FAIL: g++.dg/rtti/anon-ns1.C scan-assembler "*N[^"]+1AE"

[danglin at gcc dot gnu.org]

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

   Summary: FAIL: g++.dg/rtti/anon-ns1.C scan-assembler
"*N[^"]+1AE"
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11


Executing on host: /mnt/gnu/gcc/objdir-test/gcc/testsuite/g++/../../g++
-B/mnt/g
nu/gcc/objdir-test/gcc/testsuite/g++/../../
/mnt/gnu/gcc/gcc/gcc/testsuite/g++.d
g/rtti/anon-ns1.C  -nostdinc++
-I/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libst
dc++-v3/include/hppa2.0w-hp-hpux11.11
-I/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.1
1/libstdc++-v3/include -I/mnt/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/mnt/gnu/gcc/
gcc/libstdc++-v3/include/backward
-I/mnt/gnu/gcc/gcc/libstdc++-v3/testsuite/util
 -fmessage-length=0   -ansi -pedantic-errors -Wno-long-long  -S  -o anon-ns1.s
  (timeout = 300)
PASS: g++.dg/rtti/anon-ns1.C (test for excess errors)
FAIL: g++.dg/rtti/anon-ns1.C scan-assembler "*N[^"]+1AE"

[Bug testsuite/49643] FAIL: g++.dg/rtti/anon-ns1.C scan-assembler "*N[^"]+1AE"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Target|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11
   ||*-apple-darwin*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.05 14:21:08
   Host|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11
   ||*-apple-darwin*
 Ever Confirmed|0   |1
  Build|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11
   ||*-apple-darwin*

--- Comment #1 from Dominique d'Humieres  2011-07-05 
14:21:08 UTC ---
I also see it on *-apple-darwin* (see
http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00277.html and
http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00498.html). The output string
in assembly for *-apple-darwin* is

.ascii "*N12_GLOBAL__N_11AE\0"

[Bug testsuite/49643] FAIL: g++.dg/rtti/anon-ns1.C scan-assembler "*N[^"]+1AE"

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  2011-07-05 
14:33:38 UTC ---
I thought I had attached the hpux assembler.  The string is similar
to darwin:

_ZTSN12_GLOBAL__N_11AE:
.STRING "*N12_GLOBAL__N_11AE\x00"

[Bug c++/49639] [4.7 Regression] 447.dealII in SPEC CPU 2006 runtime fail

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #1 from Jason Merrill  2011-07-05 
14:45:40 UTC ---
Already being looked at.

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

[Bug c++/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  2011-07-05 
14:45:40 UTC ---
*** Bug 49639 has been marked as a duplicate of this bug. ***

[Bug c++/49598] [C++0x] Ice on lambda with implicit capture by value.

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  2011-07-05 
14:47:26 UTC ---
Author: jason
Date: Tue Jul  5 14:47:21 2011
New Revision: 175857

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175857
Log:
PR c++/49598
* semantics.c (finish_id_expression): convert_from_reference.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ref2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/47654] [4.6/4.7 Regression] gcc.dg/vect/no-section-anchors-vect-outer-4h.c FAILs with -floop-block

[spop at gcc dot gnu.org]

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

--- Comment #9 from Sebastian Pop  2011-07-05 14:50:37 
UTC ---
Author: spop
Date: Tue Jul  5 14:50:34 2011
New Revision: 175861

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175861
Log:
Fix PR47654: Loop blocking should strip-mine at least two loops.

PR tree-optimization/47654
* graphite-blocking.c (pbb_strip_mine_time_depth): Do not return bool.
(lst_do_strip_mine_loop): Return an int.
(lst_do_strip_mine): Same.
(scop_do_strip_mine): Same.
(scop_do_block): Loop blocking should strip-mine at least two loops.
* graphite-interchange.c (lst_interchange_select_outer): Return an int.
(scop_do_interchange): Same.
* graphite-poly.h (scop_do_interchange): Update declaration.
(scop_do_strip_mine): Same.

* gcc.dg/graphite/block-pr47654.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/block-pr47654.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-blocking.c
trunk/gcc/graphite-interchange.c
trunk/gcc/graphite-poly.h
trunk/gcc/testsuite/ChangeLog

[Bug c++/49598] [C++0x] Ice on lambda with implicit capture by value.

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  2011-07-05 
14:51:59 UTC ---
Author: jason
Date: Tue Jul  5 14:51:56 2011
New Revision: 175863

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175863
Log:
PR c++/49598
* semantics.c (finish_id_expression): convert_from_reference.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ref2.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/semantics.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/49429] [4.7 Regression] dse.c change (r175063) causes execution failures

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #18 from Steve Ellcey  2011-07-05 15:25:23 
UTC ---
Confirming that the tests no longer fail on ia64-hp-hpux11.23.  Presumably they
are fixed on apple too.

[Bug c/49644] New: [ 4.5/4.6 Regression ] post-increment of promoted operand is incorrect.

[orion at cora dot nwra.com]

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

   Summary: [ 4.5/4.6 Regression ] post-increment of promoted
operand is incorrect.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: or...@cora.nwra.com


#include 
#include 

int main(int argc, char *argv[]) {

 double data[6] = {1.0, 2.0, 3.0, 4.0, 5.0, 6.0},*d;
 double complex *c, s = 3.0 + 0.0I;
 int i;

 d=data;
 for (i = 0; i<6; i++) {
  printf("c(%p), d(%p)=%lf\n",c,d,*d);
  *c++ = *d++ * s;
 }
 return 0;
}


With gcc 4.4.5 (compiles without warnings with -Wall):
c(0x7fff16e86a00), d(0x7fff16e868d0)=1.00
c(0x7fff16e86a10), d(0x7fff16e868d8)=2.00
c(0x7fff16e86a20), d(0x7fff16e868e0)=3.00
c(0x7fff16e86a30), d(0x7fff16e868e8)=4.00
c(0x7fff16e86a40), d(0x7fff16e868f0)=5.00
c(0x7fff16e86a50), d(0x7fff16e868f8)=6.00

With gcc 4.5.1 and 4.6.0:
c(0x7fff5411f2f0), d(0x7fff5411f1c0)=1.00
c(0x7fff5411f300), d(0x7fff5411f1d0)=3.00
c(0x7fff5411f310), d(0x7fff5411f1e0)=5.00
c(0x7fff5411f320), d(0x7fff5411f1f0)=0.00
c(0x7fff5411f330), d(0x7fff5411f200)=0.00
c(0x7fff5411f340), d(0x7fff5411f210)=0.00

It appears that the right hand side  pointer is being incremented at the rate
of its promoted size.  If you remove the " * s" from the increment line, the
code works as expected.  Same problem with 32-bit and 64-bit machines.

[Bug c++/49637] template function overload incorrectly ambiguous

[timothyjgiese at gmail dot com]

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

--- Comment #3 from Timothy J Giese  2011-07-05 
15:40:59 UTC ---
The original minimal test case also fails to compile with g++ 4.5.1.

I can confirm that the following compiles fine with g++ 4.6.0, 4.5.1, and
4.4.3.

struct S { typedef int iterator; };
template  void F( T, U   ) {}
template  void F( T, int ) {}
int main()
{
  S::iterator i(42);
  F< S::iterator >(i,1); // OK 4.6.0, 4.5.1, 4.4.3 
  return 0;
}

Since this works, then (IMO) the original minimal test case should work as
well.

[Bug c/49644] [4.5/4.6 Regression] post-increment of promoted operand is incorrect.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.4.6
   Keywords||wrong-code
   Last reconfirmed||2011.07.05 15:41:41
 CC||jsm28 at gcc dot gnu.org
 Ever Confirmed|0   |1
Summary|[ 4.5/4.6 Regression ]  |[4.5/4.6 Regression]
   |post-increment of promoted  |post-increment of promoted
   |to complex operand is   |operand is incorrect.
   |incorrect.  |
   Target Milestone|--- |4.5.4

--- Comment #2 from Richard Guenther  2011-07-05 
15:41:41 UTC ---
The frontend generates

  *c++  = COMPLEX_EXPR <*d++  * REALPART_EXPR >, *d++  *
IMAGPART_EXPR >>;

and thus increments d twice.

[Bug c/49644] [ 4.5/4.6 Regression ] post-increment of promoted to complex operand is incorrect.

[orion at cora dot nwra.com]

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

Orion Poplawski  changed:

   What|Removed |Added

Summary|[ 4.5/4.6 Regression ]  |[ 4.5/4.6 Regression ]
   |post-increment of promoted  |post-increment of promoted
   |operand is incorrect.   |to complex operand is
   ||incorrect.

--- Comment #1 from Orion Poplawski  2011-07-05 
15:41:08 UTC ---
May only apply to complex variables.  I can't reproduce with promotion of float
to double.

[Bug tree-optimization/49542] [4.7 regression] 2 failures in the vectorization testsuite in 64-bit mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  2011-07-05 
15:42:55 UTC ---
> You wrote (here http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00508.html)
> > They pass on SPARC 64-bit because the operations are 
> > transformed to use the word mode.
> It doesn't work anymore?

No, for pr33804.c the word mode trick isn't invoked anymore because in:

  if (icode == CODE_FOR_nothing)
{
  if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, "op not supported by target.");
  /* Check only during analysis.  */
  if (GET_MODE_SIZE (vec_mode) != UNITS_PER_WORD
  || (vf < vect_min_worthwhile_factor (code)
  && !vec_stmt))
return false;
  if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, "proceeding using word mode.");
}

(gdb) p debug_gimple_stmt(stmt)
D.2015_14 = D.2014_13 + D.2012_9;
(gdb)  p vf
$9 = 2
(gdb) call vect_min_worthwhile_factor (code)
$10 = 4
(gdb) p vec_stmt
$11 = (gimple *) 0x0

vf is 8 on the 4.6 branch instead.  Likewise for slp-multitypes-3.c.

[Bug target/47715] [x32] TLS doesn't work

[hjl at gcc dot gnu.org]

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

--- Comment #12 from hjl at gcc dot gnu.org  2011-07-05 
15:47:44 UTC ---
Author: hjl
Date: Tue Jul  5 15:47:40 2011
New Revision: 175864

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175864
Log:
Promote the function argument before checking non-legitimate constant.

2011-07-05  H.J. Lu  

PR middle-end/47715
* calls.c (precompute_register_parameters): Promote the function
argument before checking non-legitimate constant.

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

[Bug c++/49637] template function overload incorrectly ambiguous

[timothyjgiese at gmail dot com]

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

--- Comment #4 from Timothy J Giese  2011-07-05 
16:04:29 UTC ---
icpc (ICC) 11.1 20091130  compiles the original minimal test case without
warning nor error.

[Bug regression/49498] [4.7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  2011-07-05 16:05:21 
UTC ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/30/11 14:37, xinliangli at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498
> 
> --- Comment #4 from davidxl  2011-06-30 20:37:36 
> UTC ---
> I can to reproduce the problem on x86-64 linux. Can you help provide the
> following dump:
You need to configure for cris-elf.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOEzYmAAoJEBRtltQi2kC74P4H/RrrlfNZtk/e0W26Nr1U4K2G
xZM5Y513BPakr2DyRe4OOtpMquIbRxdOe0aJw0iuUfkDXTEKNaT1h/cePYAJGjYe
Wh8GJhHj7D+WC9OiobOoBiYUmCcF7vIclW0OdcNwPrIfQ328E6zFAr8wJeWvvbGb
gBvB0cu5jMYb7Ls+x7ox7PjdTfqHbrIFZCkMVpKBPe2OYuVtKcyoBErJD7QH1cWs
VeL+bk498CRSQNSHL3j9pr/sTKFp18+I+rrBh/+aKi0FnMfoRYgCpN3/AldQw8Ds
qtzTOCPdR7X5v1Wc19bxlPJvFmes5MQSjEvzMooDmA09JeiW963DA4n08w9NeLg=
=HmIU
-END PGP SIGNATURE-

[Bug regression/49498] [4.7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  2011-07-05 16:05:22 
UTC ---
Created attachment 24693
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24693
k.c.127t.uninit

[Bug c++/49637] template function overload incorrectly ambiguous

[schaub.johannes at googlemail dot com]

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

Johannes Schaub  changed:

   What|Removed |Added

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

--- Comment #5 from Johannes Schaub  
2011-07-05 16:36:14 UTC ---
(In reply to comment #1)
> Created attachment 24686 [details]
> minimal test case

IMO this is ambiguous. When doing partial ordering, in both cases the 'T'
remains undeduced. Recall that partial ordering is, apart from stripping
parameters that have no corresponding argument in a function call context,
independent from the context of the ordering. So you cannot take the 'S' that
you passed explicitly into account. The spec says (FDIS, C++0x)

"In most cases, all template parameters must have values in order for deduction
to succeed, but for partial ordering purposes a template parameter may remain
without a value provided it is not used in the types being used for partial
ordering. [ Note: A template parameter used in a non-deduced context is
considered used. — end note ]"

[Bug testsuite/49643] FAIL: g++.dg/rtti/anon-ns1.C scan-assembler "*N[^"]+1AE"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |WAITING
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |

--- Comment #3 from Jason Merrill  2011-07-05 
16:38:39 UTC ---
I've checked in a tweak to the testcase that ought to fix it, let me know if
you still see the problem.

[Bug testsuite/49643] FAIL: g++.dg/rtti/anon-ns1.C scan-assembler "*N[^"]+1AE"

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11
   |*-apple-darwin* |*-apple-darwin*,
   ||alpha-dec-osf5.1b,
   ||mips-sgi-irix6.5
 CC||ro at gcc dot gnu.org
   Host|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11
   |*-apple-darwin* |*-apple-darwin*,
   ||alpha-dec-osf5.1b,
   ||mips-sgi-irix6.5
  Build|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11
   |*-apple-darwin* |*-apple-darwin*,
   ||alpha-dec-osf5.1b,
   ||mips-sgi-irix6.5

--- Comment #4 from Rainer Orth  2011-07-05 16:44:02 UTC 
---
The test also fails on IRIX and Tru64 UNIX:

On IRIX, I find

.ascii  "*N12_GLOBAL__N_11AE\000"

which should work with your tweak, but on Tru64 UNIX I have

.ascii "*N93_GLOBAL__N__vol_gcc_src_hg_trunk_local_gcc_test"

which won't.

[Bug tree-optimization/49645] New: [4.7 regression] g++.dg/tree-ssa/pr8781.C FAILs on Tru64 UNIX

[ro at gcc dot gnu.org]

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

   Summary: [4.7 regression] g++.dg/tree-ssa/pr8781.C FAILs on
Tru64 UNIX
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
  Host: alpha-dec-osf5.1b
Target: alpha-dec-osf5.1b
 Build: alpha-dec-osf5.1b


Between 20110622 and 20110701,  g++.dg/tree-ssa/pr8781.C started to FAIL on
Tru64 UNIX:

FAIL: g++.dg/tree-ssa/pr8781.C scan-tree-dump fre1 "Replacing call target with
f"

I'm attaching the dump.  This is a regression from the 4.6 branch.

  Rainer

[Bug tree-optimization/49645] [4.7 regression] g++.dg/tree-ssa/pr8781.C FAILs on Tru64 UNIX

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  2011-07-05 16:53:42 UTC 
---
Created attachment 24694
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24694
-fdump-tree-fre1-details output

[Bug rtl-optimization/49646] New: gcc.dg/pr44194-1.c FAILs on Solaris/SPARC, Tru64 UNIX

[ro at gcc dot gnu.org]

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

   Summary: gcc.dg/pr44194-1.c FAILs on Solaris/SPARC, Tru64 UNIX
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: era...@gcc.gnu.org
  Host: alpha-dec-osf5.1b, sparc-sun-solaris2.*
Target: alpha-dec-osf5.1b, sparc-sun-solaris2.*
 Build: alpha-dec-osf5.1b, sparc-sun-solaris2.*


The new gcc.dg/pr44194-1.c test FAILs on both Solaris/SPARC and Tru64 UNIX:

FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = 2"

I'm attaching the osf dse1 dump for analysis.

  Rainer

[Bug rtl-optimization/49646] gcc.dg/pr44194-1.c FAILs on Solaris/SPARC, Tru64 UNIX

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  2011-07-05 17:00:00 UTC 
---
Created attachment 24695
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24695
-fdump-rtl-dse1 output

[Bug testsuite/49643] FAIL: g++.dg/rtti/anon-ns1.C scan-assembler "*N[^"]+1AE"

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  2011-07-05 
17:00:41 UTC ---
> I've checked in a tweak to the testcase that ought to fix it, let me know if
> you still see the problem.

This fixes the failure for x86_64-apple-darwin10 and powerpc-apple-darwin9.
Thanks.

[Bug tree-optimization/49647] New: gcc.dg/tree-ssa/20030807-7.c XPASSes everywhere

[ro at gcc dot gnu.org]

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

   Summary: gcc.dg/tree-ssa/20030807-7.c XPASSes everywhere
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


Since 20110526, gcc.dg/tree-ssa/20030807-7.c XPASSes everywhere (at least
Solaris/SPARC and x86, IRIX and Tru64 UNIX).

I guess the xfail *-*-* in the testcase can just be removed?

  Rainer

[Bug fortran/49648] New: ICE(segfault) with MATHMUL and function-result actual argument

[burnus at gcc dot gnu.org]

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

   Summary: ICE(segfault) with MATHMUL and function-result actual
argument
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Created attachment 24696
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24696
test case

With gfortran 4.1 to 4.7, I get a segfault for the attached program:

test.f90: In function ‘gf_generateembpot’:
test.f90:31:0: internal compiler error: Segmentation fault


==1006== Invalid read of size 4
==1006==at 0x57C534: gfc_walk_subexpr (trans-array.c:7509)
==1006==by 0x57CC10: gfc_walk_expr (trans-array.c:7893)
==1006==by 0x5A2B32: gfc_conv_intrinsic_size (trans-intrinsic.c:4947)
==1006==by 0x5B159C: gfc_conv_intrinsic_function (trans-intrinsic.c:6595)
==1006==by 0x5A0532: gfc_conv_function_expr (trans-expr.c:4064)
==1006==by 0x59C629: gfc_apply_interface_mapping (trans-expr.c:2313)
==1006==by 0x57229B: gfc_set_loop_bounds_from_array_spec
(trans-array.c:585)
==1006==by 0x59FC79: gfc_conv_procedure_call (trans-expr.c:3509)

[Bug driver/49631] Driver --help should use common help code

[jsm28 at gcc dot gnu.org]

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

--- Comment #1 from Joseph S. Myers  2011-07-05 
17:05:41 UTC ---
Also note that at least -shared and -pie are driver options that are currently
marked as Common rather than Driver so as to have help text in common.opt; as
part of fixing this issue, such options can change to have the correct Driver
marking (and not Common).

[Bug middle-end/48984] [4.7 Regression] Many testsuite failures

[ro at gcc dot gnu.org]

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

--- Comment #8 from Rainer Orth  2011-07-05 17:07:31 UTC 
---
It also fails on alpha-dec-osf5.1b, sparc-sun-solaris2.*, and
i386-pc-solaris2.*.

[Bug fortran/49648] ICE(segfault) with MATHMUL and function-result actual argument

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2011-07-05 
17:14:31 UTC ---
At some point, the array spec seems to got lost:

COMPLEX,SAVE,ALLOCATABLE::P(:)

  COMPLEX:: PM(SIZE(P),SIZE(P))

We have:
(gdb) p expr->expr_type
$1 = EXPR_VARIABLE
(gdb) p expr->symtree->n.sym->name
$2 = 0x2ab42fb8 "p"
(gdb) p expr->ref->type
$4 = REF_ARRAY
(gdb) p expr->ref->u.ar
$5 = {type = AR_FULL, dimen = 0, [...]  as = 0x0, [...]}

And in gfc_walk_variable_expr's switch (ar->type):

case AR_FULL:
  [...]
  newss->data.info.dimen = ar->as->rank;

which is a NULL pointer access.

The question is: Why is ar->as == NULL?

[Bug c++/49637] template function overload incorrectly ambiguous

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2011-07-05 
17:28:09 UTC ---
(In reply to comment #3)
> struct S { typedef int iterator; };
> template  void F( T, U   ) {}
> template  void F( T, int ) {}
> int main()
> {
>   S::iterator i(42);
>   F< S::iterator >(i,1); // OK 4.6.0, 4.5.1, 4.4.3 
>   return 0;
> }
> 
> Since this works, then (IMO) the original minimal test case should work as
> well.

But that's not the same, T can be deduced here.

[Bug fortran/49648] ICE(segfault) with MATHMUL and function-result actual argument

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
 Blocks||32834
  Known to fail||4.1.2, 4.3.4, 4.4.0, 4.5.1,
   ||4.6.0, 4.7.0

--- Comment #2 from Tobias Burnus  2011-07-05 
17:29:45 UTC ---
The crucial point about the bug seems to be that "getPhaseMatrix" is in a
(different) module than the call in matmul.

Paul, do you have an idea where to look?


module m2
  COMPLEX, SAVE, ALLOCATABLE :: P(:)
contains
  FUNCTION getPhaseMatrix() RESULT(PM)
COMPLEX:: PM(SIZE(P),3)
PM=0.0
  END FUNCTION
end module m2

module m
  use m2
contains
   SUBROUTINE gf_generateEmbPot()
  COMPLEX :: sigma2(3,3)
  sigma2 = MATMUL(getPhaseMatrix(), sigma2)
   END SUBROUTINE
end module m

[Bug c++/49637] template function overload incorrectly ambiguous

[timothyjgiese at gmail dot com]

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

--- Comment #7 from Timothy J Giese  2011-07-05 
17:34:11 UTC ---
(In reply to comment #5)
> (In reply to comment #1)
> > Created attachment 24686 [details]
> > minimal test case
> 
> IMO this is ambiguous.

> When doing partial ordering, in both cases the 'T'
> remains undeduced.

That's OK; T doesn't need to be deduced, because it is explicitly passed in.
Only the second argument needs to be deduced.

> Recall that partial ordering is, apart from stripping
> parameters that have no corresponding argument in a function call context,
> independent from the context of the ordering. So you cannot take the 'S' that
> you passed explicitly into account. The spec says (FDIS, C++0x)
> 

I interpret "partial ordering" to mean: "the process of choosing which function
to use based on which one is the most specialized".

I interpret your sentence to mean: "the process of choosing which function to
use is independent of how the function is called".  My interpretation feels
weird because it is the specific manner in which the function is called that
the partial ordering process makes its decision, no?


> "In most cases, all template parameters must have values in order for 
> deduction
> to succeed, but for partial ordering purposes a template parameter may remain
> without a value provided it is not used in the types being used for partial
> ordering. [ Note: A template parameter used in a non-deduced context is
> considered used. — end note ]"



"A template parameter used in a non-deduced context is considered used."

To me means:
T is being used in a non-deduced context, so it is being "used"; therefore,
it's template parameter must be specified in order to achieve partial ordering.


"...for partial ordering purposes a template parameter may remain
without a value provided it is not used in the types being used for partial
ordering."

To me means:
...for partial ordering purposes [the second template argument] may remain
without a value provided it is not [the "thingie" that determines the level of
specialization.]

ACK!
So, I think my interpretation here is in agreement with your conclusion.

However, this conclusion had nothing to do with the fact that T was being used
in a non-deductible context, right?  It had to do with the second argument.

Therefore, shouldn't the small test code in Comment #3 fail?
The second template argument is left without a value, but it's value is used to
determine the level of specialization in the partial ordering process.

Or more generally: You can't overload a template function without providing all
of the template parameters, because the unspecified parameters cannot be used
to determine the partial ordering.

[Bug c++/49637] template function overload incorrectly ambiguous

[timothyjgiese at gmail dot com]

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

--- Comment #8 from Timothy J Giese  2011-07-05 
18:02:26 UTC ---
(In reply to comment #7)
> (In reply to comment #5)
> > (In reply to comment #1)
> > > Created attachment 24686 [details]
> > > minimal test case
> > 
> > IMO this is ambiguous.
> 
> > When doing partial ordering, in both cases the 'T'
> > remains undeduced.
> 
> That's OK; T doesn't need to be deduced, because it is explicitly passed in.
> Only the second argument needs to be deduced.

OH.  I think I see what you are saying here.  I now think that you're saying
"the partial ordering will try to deduce the arguments regardless of whether or
not you tell it not to deduce it."

Damn, I wouldn't have written the C++ standard that way.

I now have to tell people to specialize versions of
template< T_iterator, T_const_iterator, T_value_type >
instead of 
template
..and pray that their implementations do indeed use the right "T" for each of
the arguments.  :(

[Bug c++/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #11 from Jason Merrill  2011-07-05 
18:10:24 UTC ---
(In reply to comment #7)
> Expanding arguments in different ways occurs because corresponding GIMPLE
> statements are of different types.
> For 'good' case we have expression of type
>   COMPONENT_REF
> 
> While for 'bad' one it is just a 
>   MEM_REF
> 
> For that different kinds we have slightly different expanding.
> 
> The different expression types comes from front-end, at least in einline phase
> accesses are different:

The front end doesn't create MEM_REFs, they are all produced in the middle end.
 If tail call optimizations have trouble with them, that sounds like the bug.

I'm unable to reproduce your work; when I compile step-14.cc I never hit
mem_overlaps_already_clobbered_arg_p while compiling do_call.  And reverting my
change to tsubst_arg_types doesn't affect the use of MEM_REF in do_call.  What
optimization options are you using?  I'm using -O -fipa-sra
-foptimize-sibling-calls, as mentioned.

[Bug testsuite/49643] FAIL: g++.dg/rtti/anon-ns1.C scan-assembler "*N[^"]+1AE"

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  2011-07-05 
18:19:40 UTC ---
Author: jason
Date: Tue Jul  5 18:19:38 2011
New Revision: 175881

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175881
Log:
PR testsuite/49643
* g++.dg/rtti/anon-ns1.C: Allow for null-termination.

Modified:
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/rtti/anon-ns1.C

[Bug testsuite/49643] FAIL: g++.dg/rtti/anon-ns1.C scan-assembler "*N[^"]+1AE"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.2

--- Comment #7 from Jason Merrill  2011-07-05 
18:21:53 UTC ---
Fixed.

[Bug tree-optimization/49618] When building uClibc with GCC 4.6.1 old_atexit is miscompiled

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek  2011-07-05 
18:43:07 UTC ---
Author: jakub
Date: Tue Jul  5 18:43:04 2011
New Revision: 175884

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175884
Log:
PR tree-optimization/49618
* tree-eh.c (tree_could_trap_p) : For DECL_WEAK
t recurse on the decl.
: For DECL_WEAK decls
return true if expr isn't known to be defined in current
TU or some other LTO partition.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-eh.c

[Bug tree-optimization/49618] When building uClibc with GCC 4.6.1 old_atexit is miscompiled

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  2011-07-05 
18:44:35 UTC ---
Author: jakub
Date: Tue Jul  5 18:44:32 2011
New Revision: 175885

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175885
Log:
PR tree-optimization/49618
* tree-eh.c (tree_could_trap_p) :
For DECL_WEAK decls return true.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/tree-eh.c

[Bug fortran/49648] ICE(segfault) with MATHMUL and function-result actual argument

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2011-07-05 
19:00:51 UTC ---
Draft patch, which seems to fix some ref->u.ar->as issues for "p" - but not the
one, I am looking for. At least the added assert now triggers.

 * * *

Debugging shows that when resolving MAXMUL, one calls resolve_actual_arglist
for SIZE's p. At that point "p's e->ref->u.ar.as == NULL, which is fixed. One
then resolves MAXMUL in resolve_actual_arglist for getPhaseMatrix; if one now
looks at getPhaseMatrix's e->symtree->n.sym->as->upper[0], one finds:

(gdb) p arg->expr->symtree->n.sym->as->upper[0]->value.function.isym->id
$11 = GFC_ISYM_SIZE
(gdb) p
arg->expr->symtree->n.sym->as->upper[0]->value.function.actual->expr->symtree->n.sym->name
$12 = 0x2ab42fa0 "p"
(gdb) p
arg->expr->symtree->n.sym->as->upper[0]->value.function.actual->expr->ref->u.ar.as.
A syntax error in expression, near `'.
(gdb) p
arg->expr->symtree->n.sym->as->upper[0]->value.function.actual->expr->ref->u.ar.as
$13 = (gfc_array_spec *) 0x159f830

Which also looks fine.



Seemingly, the problem is really the result variable - which seems to be
carried through:

(gdb) p arg->expr->symtree->n.sym->result->name
$17 = 0x2ab42fb8 "pm"

And as both "as" are different:

(gdb) p arg->expr->symtree->n.sym->result->as
$18 = (gfc_array_spec *) 0x159ef70
(gdb) p arg->expr->symtree->n.sym->as
$19 = (gfc_array_spec *) 0x159cd40

it is not surprising that one get's at the end:

(gdb) p
arg->expr->symtree->n.sym->result->as->upper[0]->value.function.actual->expr->ref->u.ar.as
$14 = (gfc_array_spec *) 0x0

If one removes the RESULT(), it works - even without the patch.


--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -7506,6 +7521,7 @@ gfc_walk_variable_expr (gfc_ss * ss, gfc_expr * expr)

   ar = &ref->u.ar;

+  gcc_assert (ar->as);
   if (ar->as->rank == 0 && ref->next != NULL)
{
  /* Scalar coarray.  */
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -82,6 +82,11 @@ static bitmap_obstack labels_obstack;
 /* True when simplifying a EXPR_VARIABLE argument to an inquiry function.  */
 static bool inquiry_argument = false;

+
+/* Prototypes of static functions.  */
+static gfc_try resolve_ref (gfc_expr *);
+
+
 int
 gfc_is_formal_arg (void)
 {
@@ -1577,6 +1582,9 @@ resolve_actual_arglist (gfc_actual_arglist *arg,
procedure_type ptype,
&& count_specific_procs (e) != 1)
return FAILURE;

+  if (e->ref && e->symtree->n.sym->attr.use_assoc)
+   resolve_ref (e);
+
   if (e->ts.type != BT_PROCEDURE)
{
  save_need_full_assumed_size = need_full_assumed_size;

[Bug tree-optimization/49618] When building uClibc with GCC 4.6.1 old_atexit is miscompiled

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #23 from Jakub Jelinek  2011-07-05 
19:12:01 UTC ---
Should be fixed now.

[Bug middle-end/49649] New: [4.7 Regression] FAIL: libgomp.graphite/force-parallel-1.c

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] FAIL:
libgomp.graphite/force-parallel-1.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, revision 175863 gave

FAIL: libgomp.graphite/force-parallel-1.c scan-tree-dump-times graphite "1
loops carried no dependency" 2
FAIL: libgomp.graphite/force-parallel-1.c scan-tree-dump-times optimized
"loopfn" 5

Revision 175852 is OK.

[Bug target/49650] New: MIPS should not use target_flags_explicit in insn conditions

[jsm28 at gcc dot gnu.org]

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

   Summary: MIPS should not use target_flags_explicit in insn
conditions
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: js...@gcc.gnu.org
Target: mips*-*-*


As explained in http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00215.html MIPS
should not be using target_flags_explicit directly in macros such as
GENERATE_LL_SC and GENERATE_SYNC that are used in insn conditions; it should
only be used as part of initial option processing (no later than the option
override hook) to determine other state that then gets used in insn conditions
and elsewhere to control the code to generate.

[Bug fortran/49648] ICE(segfault) with MATHMUL and function-result actual argument

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2011-07-05 
19:46:45 UTC ---
Draft patch, which should also save some memory, .mod file-size and should
slightly speed the program.

It fixes the test case in comment 0 and comment 2, but I have not yet regtested
it (currently bootstrapping). A modification would be to not write it at all -
and simply add "sym->result = sym" if sym->attr.function. (This will break .mod
compatibility, which was last done 2011-03-29 - though I am not 100% sure that
4.6 and 4.7 are indeed still compatible.)

--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -3631,7 +3637,10 @@ mio_symbol (gfc_symbol *sym)

   mio_array_spec (&sym->as);

-  mio_symbol_ref (&sym->result);
+  if (iomode == IO_OUTPUT && sym->result != sym)
+mio_symbol_ref (&sym);
+  else
+mio_symbol_ref (&sym->result);

   if (sym->attr.cray_pointee)
 mio_symbol_ref (&sym->cp_pointer);

[Bug c/49644] [4.5/4.6 Regression] post-increment of promoted operand is incorrect.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2011-07-05 
19:46:30 UTC ---
The testcase looks wrong though, I don't see c being initialized anywhere.

[Bug c++/49637] template function overload incorrectly ambiguous

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  2011-07-05 
19:48:14 UTC ---
(In reply to comment #8)
> OH.  I think I see what you are saying here.  I now think that you're saying
> "the partial ordering will try to deduce the arguments regardless of whether 
> or
> not you tell it not to deduce it."

Not exactly.  The deduction done in partial ordering is not the same as the
deduction done for the call itself; partial ordering tries to find template
arguments which will make one signature match the other.  Here, deducing U =
int makes the first signature match the second, but T is only used in
non-deduced context, so we don't have a value for it.  If typename were a
deduced context, we could deduce T = T and win.

It's not clear to me why partial ordering requires that we deduce values for
all used parameters anyway.  I'm not sure what the EDG front end is doing here,
I guess I'll raise it with the committee.

[Bug c++/49637] template function overload incorrectly ambiguous

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  2011-07-05 
19:51:02 UTC ---
This is related to

http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#214

[Bug c++/49598] [C++0x] Ice on lambda with implicit capture by value.

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  2011-07-05 
20:01:34 UTC ---
Fixed (output as well as crash) for 4.6.2.

[Bug c/49644] [4.5/4.6 Regression] post-increment of promoted operand is incorrect.

[orion at cora dot nwra.com]

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

--- Comment #4 from Orion Poplawski  2011-07-05 
20:01:27 UTC ---
Yeah, I screwed that up.  But it doesn't make any difference to the problem. 
This should be correct though.

#include 
#include 

int main(int argc, char *argv[]) {

 double data[6] = {1.0, 2.0, 3.0, 4.0, 5.0, 6.0},*d;
 double complex ddata[6], *c, s = 3.0;
 int i;

 d=data;
 c=ddata;
 for (i = 0; i<6; i++) {
  printf("c(%p), d(%p)=%f\n",c,d,*d);
  *c++ = *d++ * s;
 }
 return 0;
}

[Bug c++/49651] New: [C++0x] nested lambdas and -O3 produced incorrect integer variable increments

[pedro.larroy at gmail dot com]

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

   Summary: [C++0x] nested lambdas and -O3 produced incorrect
integer variable increments
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pedro.lar...@gmail.com


Hi. I'm trying to reproduce this outside 'production' code but haven't been
successful yet. But the observation is the following:

I have 3 level nested lambdas iterating some vectors. Inside, printing and
incrementing this 'sentinel' variable, the output with -O3 shows the wrong
output:

0. sentinel: deadbee5
2. sentinel: deadbee6
1. sentinel: deadbee7
1. sentinel: deadbee8
3. sentinel: deadbee7
4. sentinel: deadbee8
1. sentinel: deadbee9
5. sentinel: deadbee9
6. sentinel: deadbeea
2. sentinel: deadbeeb

With -O0 the values are consecutive. The code is similar to:

u32 sentinel=0xdeadbee0;
auto run = [&](Class& c) {
   for_each(v3.begin(), v3.end(), [&](ClassC& cc) {
   print(sentinel++);
   });
   print(sentinel++);
};
for_each(v.begin(), v.end(), [&](ClassB& b) {

   for_each(v2.begin(), v2.end(), run);
   print(sentinel++);
});


I have observed that the sentinel variable for example, is captured inside the
lambda and the address is not the same as the outermost sentinel...   could
that be the problem that leads to the wrong optimizations?

[Bug c/49652] New: SIGFPE in vector_alignment_reachable_p

[dcb314 at hotmail dot com]

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

   Summary: SIGFPE in vector_alignment_reachable_p
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com


Created attachment 24697
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24697
C source code

I just tried to compile the package xblast-2.10.4 with the latest trunk
snapshot 20110702 on an AMD x86_64 box.

The compiler said

cfg_game.c: In function 'RetrieveAnyGamePlayers':
cfg_game.c:464:1: internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

gdb says

Program received signal SIGFPE, Arithmetic exception.
0x00cf7007 in vector_alignment_reachable_p (dr=0x14f5150)
at ../../src/gcc-4.7-20110702/gcc/tree-vect-data-refs.c:1114
1114  if ((nelements - mis_in_elements) % GROUP_SIZE (stmt_info))
(gdb) p stmt_info
$1 = (struct _stmt_vec_info *) 0x15490c0
(gdb)

Preprocessed source code attached. Flag -O3 required.

[Bug c++/49651] [C++0x] nested lambdas and -O3 produced incorrect integer variable increments

[pedro.larroy at gmail dot com]

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

--- Comment #1 from Pedro Larroy  2011-07-05 
20:30:13 UTC ---
I think I'm able to reproduce with the following:

the output spotted is:


run.for_each.a: 20633
run.a: 20634
1 for_each.a: 20631
1 for_each.a: 20632

Compiled with:
g++ -Wall -std=c++0x -O3 -o test test.cc

Code follows:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

typedef uint32_t u32;
using namespace std;
vector g;
void f(u32 a, u32 b) 
{   
g.push_back(b);
}

int main(int argc, char *argv[])
{
u32 a = 0;
vector vi;
vi.push_back(0);
vi.push_back(1);
vi.push_back(2);
vi.push_back(3);
vi.push_back(4);


vector vo;
vo.push_back(5);
vo.push_back(5);

vector ve;
ve.push_back(5);


vector v3;
vector v4;
vector v5;
vector v6;
vector v7;

f(32, a++);
cout << "bmain.a: " << a << endl;

f(32, a++);
cout << "bmain.a: " << a << endl;


auto run = [&](int& i) {
// inside this lambda &a is not the same as the &a in the first line
v3.push_back(i);
v4.push_back(i);
v5.push_back(i);
v6.push_back(i);
v7.push_back(i);
f(32, a++);
cout << "run.a: " << a << endl;

v3.push_back(i);
v4.push_back(i);
v5.push_back(i);
v6.push_back(i);
v7.push_back(i);
f(32, a++);
cout << "run.a: " << a << endl;



for_each(ve.begin(), ve.end(), [&](int& xi) {
v7.push_back(xi);
f(32, a++);
cout << "run.for_each.a: " << a << endl;

});

f(32, a++);
cout << "run.a: " << a << endl;
};

f(32, a++);
cout << "main.a: " << a << endl;

while(true) {
for_each(vi.begin(), vi.end(), [&](int& xi) {
f(32, a++);
cout << "1 for_each.a: " << a << endl;


for_each(vo.begin(), vo.end(), run);

f(32, a++);
cout << "1 for_each.a: " << a << endl;


for_each(ve.begin(), ve.end(), run);

f(32, a++);
cout << "1 for_each.a: " << a << endl;


});
}
cout << "main.a: " << a << endl;
}

[Bug c++/49353] C++ frontend should not declare function EXTERN when it forces them to stay

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2011-07-05 
20:41:17 UTC ---
The C++ linkage scheme has been to set DECL_EXTERN on comdat stuff until EOF,
at which point we decide whether or not to emit them and whether they should be
public or not.  We need to do this for targets that don't support
weak/linkonce.

We have historically used DECL_EXTERNAL rather than just DECL_DEFER_OUTPUT in
order to support targets that need assemble_external.

Perhaps this can be simplified somewhat now that we're always unit-at-a-time; I
imagine we could give everything the real flags during compilation and then
change them to be external or non-public at EOF, before handing off to cgraph
finalization.  But I'm concerned about the churn causing breakage on obscure
targets.

With regard to this specific issue, I believe that we do unset DECL_EXTERNAL on
things that get mark_needed, usually right after the call.  I'll check on that.

[Bug c++/49637] template function overload incorrectly ambiguous

[timothyjgiese at gmail dot com]

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

Timothy J Giese  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #11 from Timothy J Giese  
2011-07-05 21:05:54 UTC ---
These were some useful explanations - thanks gang.

I'm going to go ahead and close this because it seems clear now that what g++
is doing is not incorrect.

To close this off, I'm going to show a work-around for the original minimal
test case, just in case someone lands here from a search engine with a similar
problem:



#include 

template   struct TypeMatch  { static bool const value =
false; };
template   struct TypeMatch { static bool const value =
true;  };

// Create 2 functions with different names
struct S { typedef int iterator; };
template  void FU  (typename T::iterator,U  ) { std::cout <<
"FU"   << std::endl; };
template  void Fint(typename T::iterator,int) { std::cout <<
"Fint" << std::endl; };

// Create a selector function that acts like an overload
template  inline void F( typename T::iterator i, U u )
{
  if ( TypeMatch::value ) { Fint(i,u); }
  else   { FU(i,u); };
};

// Disadvantage = every new "overload" needs to be inserted into F
// However; I won't run into this with my immediate use-case, so I'm not going
to complain too hard


int main()
{
  S::iterator i(42);
  F(i,1);  // Compiles OK; prints "Fint"
  F(i,true);   // Compiles OK; prints "FU"
  return 0;
};



This work-around compiles fine on g++ 4.6.0.

[Bug middle-end/49649] [4.7 Regression] FAIL: libgomp.graphite/force-parallel-1.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #1 from H.J. Lu  2011-07-05 21:33:37 
UTC ---
It is caused by revision 175860:

http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00125.html

[Bug c++/49651] [C++0x] nested lambdas and -O3 produced incorrect integer variable increments

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|major   |normal

--- Comment #2 from Jonathan Wakely  2011-07-05 
21:54:39 UTC ---
Can you produce a testcase that aborts/fails if the problem occurs? Otherwise I
seem to need to inspect thousands of lines to look for non-consecutive values!

Could this be the same underlying issue as PR 49598 and so (very recently)
fixed?

[Bug c/49653] New: Undefined reference to inlined function with -O0,-std=c99

[gary at intrepid dot com]

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

   Summary: Undefined reference to inlined function with
-O0,-std=c99
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com


Given,

$ cat -n inline_trouble.c
 1  inline long trouble(long a, long b)
 2  {
 3  return a + b;
 4  }
 5
 6  long two = 2;
 7
 8  int main()
 9  {
10  long result = trouble(two, two);
11  return (int)result;
12  }

$ gcc --version
gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4)

This test compiles and links cleanly at -O2,-std=c99:

$ gcc  -std=c99 -O2 inline_trouble.c

At -O0 -std=c99, it fails to link.

$ gcc  -std=c99 -O0 inline_trouble.c
/tmp/ccXya7LE.o: In function `main':
inline_trouble.c:(.text+0x1d): undefined reference to `trouble'
collect2: ld returned 1 exit status

Note that gnu90 doesn't have this issue.

$ gcc  -std=gnu90 -O0 inline_trouble.c

(Although GCC 4.5.1 is used in the test above, it is likely that this problem
can be reproduced with GCC built from the trunk.)

[Bug c/49653] Undefined reference to inlined function with -O0,-std=c99

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2011-07-05 
22:15:54 UTC ---
This is correct for C99.  inline alone in C99 is the same GNU's C90's extern
inline.

[Bug c++/49651] [C++0x] nested lambdas and -O3 produced incorrect integer variable increments

[pedro.larroy at gmail dot com]

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

--- Comment #3 from Pedro Larroy  2011-07-05 
22:24:26 UTC ---
(In reply to comment #2)
> Can you produce a testcase that aborts/fails if the problem occurs? Otherwise 
> I
> seem to need to inspect thousands of lines to look for non-consecutive values!
> 
> Could this be the same underlying issue as PR 49598 and so (very recently)
> fixed?

It doesn't look the same to me since the variable doesn't have garbage, but I
don't have enough insight to judge. Can you point to which particular source
file to check to investigate this?

Here is the program that asserts on error. Works with -O0 and fails with -O3
quite soon (12 iterations):


g++-4.6 -Wall -std=c++0x -O3 -o test test.cc




#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

typedef uint32_t u32;
using namespace std;
vector g;
void f(u32 a, u32 b) 
{   
g.push_back(b);
for(size_t i=1; i vi;
vi.push_back(0);
vi.push_back(1);
vi.push_back(2);
vi.push_back(3);
vi.push_back(4);


vector vo;
vo.push_back(5);
vo.push_back(5);

vector ve;
ve.push_back(5);


vector v3;
vector v4;
vector v5;
vector v6;
vector v7;

f(32, a++);
cout << "bmain.a: " << a << endl;

f(32, a++);
cout << "bmain.a: " << a << endl;


auto run = [&](int& i) {
// inside this lambda &a is not the same as the &a in the first line
v3.push_back(i);
v4.push_back(i);
v5.push_back(i);
v6.push_back(i);
v7.push_back(i);
f(32, a++);
cout << "run.a: " << a << endl;

v3.push_back(i);
v4.push_back(i);
v5.push_back(i);
v6.push_back(i);
v7.push_back(i);
f(32, a++);
cout << "run.a: " << a << endl;



for_each(ve.begin(), ve.end(), [&](int& xi) {
v7.push_back(xi);
f(32, a++);
cout << "run.for_each.a: " << a << endl;

});

f(32, a++);
cout << "run.a: " << a << endl;
};

f(32, a++);
cout << "main.a: " << a << endl;

while(true) {
for_each(vi.begin(), vi.end(), [&](int& xi) {
f(32, a++);
cout << "1 for_each.a: " << a << endl;


for_each(vo.begin(), vo.end(), run);

f(32, a++);
cout << "1 for_each.a: " << a << endl;


for_each(ve.begin(), ve.end(), run);

f(32, a++);
cout << "1 for_each.a: " << a << endl;


});
}
cout << "main.a: " << a << endl;
}

[Bug libffi/49594] bootstrap failure in libffi:darwin_closure for powerpc-darwin8

[fang at csl dot cornell.edu]

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

--- Comment #9 from David Fang  2011-07-05 
22:34:43 UTC ---
(In reply to comment #8)
> I tested the patch on darwin 8 on a G5 and with crosses from darwin 9 - >
> darwin 8.

Using Iain's patch ( http://gcc.gnu.org/bugzilla/attachment.cgi?id=24655 ), a
native powerpc-darwin8 bootstrap has just completed successfully.
The testsuite has just begun and will probably take another day to finish.

[Bug c/49654] New: Linear search through options in handle_pragma_diagnostic

[jsm28 at gcc dot gnu.org]

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

   Summary: Linear search through options in
handle_pragma_diagnostic
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: js...@gcc.gnu.org


c-pragma.c:handle_pragma_diagnostic does a linear search through options to
find one that matches.  It should use find_opt instead.

[Bug fortran/49648] ICE(segfault) with MATHMUL and function-result actual argument

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2011-07-05 
22:52:01 UTC ---
(In reply to comment #4)
> Draft patch, which should also save some memory, .mod file-size and should
> slightly speed the program.

The patch fails for procedure pointers - as the function->attr.proc_pointer ==
0 and only function->result->attr.proc_pointer != 0, cf.
add_hidden_procptr_result. For instance: gfortran.dg/proc_ptr_result_1.f90 and
gfortran.dg/proc_ptr_result_3.f90.

[Bug regression/49498] [4.7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20

[xinliangli at gmail dot com]

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

--- Comment #7 from davidxl  2011-07-05 22:51:49 
UTC ---
(In reply to comment #6)
> Created attachment 24693 [details]
> k.c.127t.uninit


1) is the complicated control flow generated by if-merging + jump-threading?
2) On the targets that have the problem, is branch cost considered cheap?
3) Looks like there are more jump-threading opportunities that can clean up the
control flow, namely,

(in the attached file):

BLOCK 4 should be split into 4_1 and 4_2. 4_1's predecessor is BLOCK 8, and it
can be merged with with  BLOCK 10. The merged block (10 and 4_1) has single
successor BLOCK 6. BLOCK 4_2 (predecessor is 9) is successors can be greatly
simplified with a single successor BLOCK 7.

Why is that not happening?

With the complicated control flow, the uninit analysis is definitely confused
-- requires powerful symbolic evaluation to simplify the predicates: the
predicates guarding the use in BLOCK 6:

(n<=9 AND  m==0) OR (n <= 9 AND m != 0 AND (n <=9 OR m > 100)) OR (n > 9 AND m
> 100) OR (n > 9 AND m <= 100 AND (n<=9 OR m > 100))

of course there might be other bugs in the analysis that prevent the above from
formulated, but nonetheless, it is unlikely to be handled).

Solution
1) fix the test case by disabling jumpthreading and if-merging
2) or maybe move the uninit analysis earlier in the pipeline.

David

[Bug c/49655] New: diagnostic pragma accepts non-warning options

[jsm28 at gcc dot gnu.org]

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

   Summary: diagnostic pragma accepts non-warning options
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: js...@gcc.gnu.org


#pragma GCC diagnostic accepts any option, not just warning options.  Code such
as

#pragma GCC diagnostic error "-fstrict-aliasing"

should be rejected (but isn't at present), and it's probably possible to
trigger ICEs with such code at present by changing options at this point and
bypassing all the consistency checks and post-option processing done on the
command line.

[Bug rtl-optimization/49474] [4.7 Regression] GCC 4.7-20110618 fails to bootstrap on stage 2: gcc/fortran/resolve.c:5360:1: internal compiler error: vector VEC(edge,base) index domain error, in find_i

[dougmencken at gmail dot com]

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

Douglas Mencken  changed:

   What|Removed |Added

  Known to work||4.6.1

--- Comment #1 from Douglas Mencken  2011-07-05 
23:38:04 UTC ---
UPD: Tried bootstrapping of GCC 4.6.1. It doesn't fail under such error.

[Bug c/49656] New: internal compiler error on Mac OS 10.7.0

[andreas at galauner dot de]

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

   Summary: internal compiler error on Mac OS 10.7.0
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andr...@galauner.de


Created attachment 24698
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24698
Preprocessed main.c

Target: x86_64-elf
Configured with: --target=x86_64-elf --without-headers --enable-languages=c,c++
--disable-nls
And then build with: make all-gcc
Version: 4.6.1

Command line: x86_64-elf-gcc -m32 -g -nostdlib -nostdinc -fno-builtin
-fno-stack-protector -std=gnu99 -Wall -Wextra -pedantic -Wshadow
-Wpointer-arith -Wcast-align -Wwrite-strings -Wmissing-prototypes
-Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline
-Wno-long-long -Wstrict-prototypes  -DARCH_X86 -DDEBUG -Iinclude -c src/main.c
-o obj/main.o

Error message:
src/main.c:30:1: internal compiler error: in execute_ipa_pass_list, at
passes.c:2426
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [obj/main.o] Error 1

main.i is attached

I also tried this with GCC 4.6.0 and 4.5.0. Same error.

[Bug c++/49651] [C++0x] nested lambdas and -O3 produced incorrect integer variable increments

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.05 23:53:37
  Known to work||4.7.0
 Ever Confirmed|0   |1
  Known to fail||4.6.2

--- Comment #4 from Jonathan Wakely  2011-07-05 
23:53:37 UTC ---
thanks, that doesn't assert for me using the latest 4.7.0 but does for 4.6.2,
so it's not PR 49598

[Bug c++/48157] Unable to match function call to member function template

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-07-06 
04:20:46 UTC ---
Author: jason
Date: Wed Jul  6 04:20:39 2011
New Revision: 175904

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175904
Log:
PR c++/48157
* pt.c (tsubst_qualified_id): Preserve TEMPLATE_ID_EXPR in
partial instantiation.

Added:
trunk/gcc/testsuite/g++.dg/template/template-id-4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/49657] New: array subscript warnings when building gcc with -O2

[dirtyepic at gentoo dot org]

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

   Summary: array subscript warnings when building gcc with -O2
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dirtye...@gentoo.org


Building gcc-4.6.1 with BOOT_CFLAGS="-O2" causes a couple -Warray-bounds
warnings to be output.  I know there are several PRs open for bogus "above
array bounds" warnings but since these are triggered building GCC itself I
thought I'd report them.  There is also a "below array bounds" warning.

The warnings also appear in 4.6.0 but not 4.5.* IIRC.

~/gcc/gcc-4.6.1 $ ./configure --enable-languages=c
~/gcc/gcc-4.6.1 $ make BOOT_CFLAGS="-O2" bootstrap-lean


../../.././libgcc/../gcc/crtstuff.c: In function ‘frame_dummy’:
../../.././libgcc/../gcc/crtstuff.c:381:19: warning: array subscript is above
array bounds [-Warray-bounds]

../../.././libgcc/../gcc/crtstuff.c: In function ‘__do_global_ctors_aux’:
../../.././libgcc/../gcc/crtstuff.c:575:25: warning: array subscript is below
array bounds [-Warray-bounds]

../.././gcc/expmed.c: In function ‘init_expmed’:
../.././gcc/expmed.c:134:3: warning: array subscript is above array bounds
[-Warray-bounds]
../.././gcc/expmed.c:141:3: warning: array subscript is above array bounds
[-Warray-bounds]
../.././gcc/expmed.c:145:3: warning: array subscript is above array bounds
[-Warray-bounds]
../.././gcc/expmed.c:149:3: warning: array subscript is above array bounds
[-Warray-bounds]
../.././gcc/expmed.c:153:3: warning: array subscript is above array bounds
[-Warray-bounds]
../.././gcc/expmed.c:157:3: warning: array subscript is above array bounds
[-Warray-bounds]
../.././gcc/expmed.c:164:3: warning: array subscript is above array bounds
[-Warray-bounds]
../.././gcc/expmed.c:180:3: warning: array subscript is above array bounds
[-Warray-bounds]
../.././gcc/expmed.c:184:3: warning: array subscript is above array bounds
[-Warray-bounds]
../.././gcc/expmed.c:188:3: warning: array subscript is above array bounds
[-Warray-bounds]
../.././gcc/expmed.c:231:8: warning: array subscript is above array bounds
[-Warray-bounds]
../.././gcc/expmed.c:246:8: warning: array subscript is above array bounds
[-Warray-bounds]
../.././gcc/expmed.c:247:8: warning: array subscript is above array bounds
[-Warray-bounds]

[Bug tree-optimization/49657] array subscript warnings when building gcc with -O2

[dirtyepic at gentoo dot org]

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

--- Comment #1 from Ryan Hill  2011-07-06 04:54:56 
UTC ---
Created attachment 24699
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24699
build log

[Bug c/49653] Undefined reference to inlined function with -O0,-std=c99

[schaub.johannes at googlemail dot com]

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

Johannes Schaub  changed:

   What|Removed |Added

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

--- Comment #2 from Johannes Schaub  
2011-07-06 05:27:41 UTC ---
(In reply to comment #1)
> This is correct for C99.  inline alone in C99 is the same GNU's C90's extern
> inline.

For an explanation, see
http://stackoverflow.com/questions/2217628/multiple-definition-of-inline-functions-when-linking-static-libs/2218034#2218034
. In particular

  "In a call to an inline function it's unspecified whether the external or the
inline definition is used."

[Bug tree-optimization/49542] [4.7 regression] 2 failures in the vectorization testsuite in 64-bit mode

[irar at il dot ibm.com]

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

--- Comment #4 from Ira Rosen  2011-07-06 06:20:06 UTC 
---
In that case they should fail. The vf in 4.7 is correct. In 4.6 it is updated
after stmts analysis, which may cause inconsistency. This patch
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02210.html fixed this by moving vf
update before the analysis.

[Bug target/49641] [ARM] Wrong code for ARMv4T and stmia

[sebastian.hu...@embedded-brains.de]

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

Sebastian Huber  changed:

   What|Removed |Added

  Known to work||4.4.6
  Known to fail||4.6.1

--- Comment #1 from Sebastian Huber  
2011-07-06 06:27:23 UTC ---
The command line is:

arm-rtemseabi4.11-gcc -mcpu=arm7tdmi-s -mfpu=vfp -mfloat-abi=soft -mthumb -O2
-c watchdog.i

We also get an assembler warning:

watchdog.s: Assembler messages:
watchdog.s:29: Warning: value stored for r3 is UNKNOWN
watchdog.s:32: Warning: value stored for r3 is UNKNOWN

Is the ARM7TDMI-S core still supported by GCC or is it too old?

[Bug fortran/49648] ICE(segfault) with MATMUL and function-result actual argument

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #6 from Tobias Burnus  2011-07-06 
06:43:37 UTC ---
I tried something fancier by setting the proc_pointer/pointer attribute of
sym->attr based on sym->result->attr, but that fails for proc_ptr_result_3.f90
(cf. failing patch below). -- In that case, "get_sub()" is a function, which
returns a subroutine procedure pointer, i.e. "sym->result" is a subroutine
while "sym" itself is a function.

One solution would be, to save only the result attribute - in particular the
attr.subroutine/attr.function - and construct a new result symbol, re-using as
much as possible from "sym" itself. One just needs to make sure that one does
not double free components.

Alternatively, one should somehow make sure that also expressions below
sym->result - in particular: sym->result->as->{lbound,ubound} - get fixed via a
call to resolve_ref.