[Bug c++/46309] New: optimization a==3||a==1

[eidletni at mail dot ru]

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

   Summary: optimization a==3||a==1
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eidle...@mail.ru


$g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/eid-letni/opt/gcc/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/eid-letni/opt/gcc
--enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20101105 (experimental) (GCC) 

$uname -a
Linux eidletni 2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:36:48 UTC 2010
i686 GNU/Linux

$g++ -O3 -c main.ii

func good_comp have optimiz without jump:

bool good_comp(int a, int b)
{
return (a==3)||(a==1);
}

asm with no jumps:

0020 <_Z9good_compii>:
  20:8b 54 24 04  mov0x4(%esp),%edx
  24:83 fa 01 cmp$0x1,%edx
  27:0f 94 c0 sete   %al
  2a:83 fa 03 cmp$0x3,%edx
  2d:0f 94 c2 sete   %dl
  30:09 d0or %edx,%eax
  32:c3   ret

using "same" code with temps:

bool bad_comp(int a, int b)
{
bool tmp1 = (a==3);
bool tmp2 = (a==1);
return tmp1||tmp2;
}

asm(with jump):

 <_Z8bad_compii>:
   0:8b 54 24 04  mov0x4(%esp),%edx
   4:b8 01 00 00 00   mov$0x1,%eax
   9:83 fa 03 cmp$0x3,%edx
   c:74 06je 14 <_Z8bad_compii+0x14>
   e:83 fa 01 cmp$0x1,%edx
  11:0f 94 c0 sete   %al
  14:f3 c3repz ret

[Bug c++/46309] optimization a==3||a==1

[eidletni at mail dot ru]

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

--- Comment #1 from eidletni at mail dot ru 2010-11-05 08:36:58 UTC ---
Created attachment 22290
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22290
c++ code

[Bug fortran/46310] New: gfortran wrongly treats INTERFACE BLOCK and not INTERFACE BODY as scoping unit

[burnus at gcc dot gnu.org]

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

   Summary: gfortran wrongly treats INTERFACE BLOCK and not
INTERFACE BODY as scoping unit
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Reported by Damian at  http://gcc.gnu.org/ml/fortran/2010-11/msg00081.html /
http://gcc.gnu.org/ml/fortran/2010-11/msg00082.html

Reduced example:
!-
module foo_module
 implicit none
 interface
   real function func_interface()
   end function
   subroutine bar_interface(f)
 implicit none
 procedure(func_interface), intent(in) :: f
   end subroutine
 end interface
end module
!-

The program is invalid without "import func_interface".

The reason is that not the interface block but the interface body is a scoping
unit and host association only occurs using the IMPORT statement.

While many compilers (crayftn, nagf95, xlf, g95) correctly reject the program,
gfortran happily compiles it.

Fortran 2008 defines:

"1.3.124 scoping unit -- BLOCK construct, derived-type definition, interface
body, program unit, or subprogram, excluding all nested scoping units in it"

[Bug fortran/46310] gfortran wrongly treats INTERFACE BLOCK and not INTERFACE BODY as scoping unit

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  2010-11-05 
08:59:14 UTC ---
> The program is invalid without "import func_interface".
> 
> The reason is that not the interface block but the interface body is a scoping
> unit and host association only occurs using the IMPORT statement.
> 
> While many compilers (crayftn, nagf95, xlf, g95) correctly reject the program,
> gfortran happily compiles it.

With an unpatched trunk, I get an error in both cases:

[macbook] f90/bug% gfcp -v
Using built-in specs.
COLLECT_GCC=gfcp
COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.6p/libexec/gcc/x86_64-apple-darwin10/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../p_work/configure --prefix=/opt/gcc/gcc4.6p
--mandir=/opt/gcc/gcc4.6p/share/man --infodir=/opt/gcc/gcc4.6p/share/info
--build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10
--target=x86_64-apple-darwin10 --enable-languages=c,lto,fortran
--with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--with-cloog=/opt/sw64 --with-ppl=/opt/sw64 --with-mpc=/opt/sw64
--enable-checking=release
Thread model: posix
gcc version 4.6.0 20101031 (experimental) [trunk revision 166102] (GCC) 
[macbook] f90/bug% gfcp pr46310.f90
pr46310.f90:6.29:

   subroutine bar_interface(f)
 1
Error: PROCEDURE attribute conflicts with INTENT attribute in 'f' at (1)
[macbook] f90/bug% gfcp pr46310_db.f90
pr46310_db.f90:6.29:

   subroutine bar_interface(f)
 1
Error: PROCEDURE attribute conflicts with INTENT attribute in 'f' at (1)
[macbook] f90/bug% diff -up pr46310.f90 pr46310_db.f90
--- pr46310.f902010-11-05 09:51:53.0 +0100
+++ pr46310_db.f902010-11-05 09:53:55.0 +0100
@@ -4,6 +4,7 @@ module foo_module
real function func_interface()
end function
subroutine bar_interface(f)
+ import func_interface
  implicit none
  procedure(func_interface), intent(in) :: f
end subroutine

[Bug debug/46307] [4.6 Regression] ICE with FMA_EXPR in DEBUG stmts

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2010-11-05 
09:00:54 UTC ---
Author: jakub
Date: Fri Nov  5 09:00:50 2010
New Revision: 166351

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166351
Log:
PR debug/46307
* tree-ssa-operands.c (get_expr_operands): Handle FMA_EXPR.
* tree-pretty-print.c (dump_generic_node): Likewise.
(op_code_prio): Likewise.
* cfgexpand.c (expand_debug_expr): Likewise.

* gcc.dg/pr46307.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr46307.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-pretty-print.c
trunk/gcc/tree-ssa-operands.c

[Bug debug/46307] [4.6 Regression] ICE with FMA_EXPR in DEBUG stmts

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2010-11-05 
09:02:00 UTC ---
Fixed.

[Bug fortran/46310] gfortran wrongly treats INTERFACE BLOCK and not INTERFACE BODY as scoping unit

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2010-11-05 
09:25:12 UTC ---
(In reply to comment #1)
> With an unpatched trunk, I get an error in both cases:

> Error: PROCEDURE attribute conflicts with INTENT attribute in 'f' at (1)

That makes sense; thus, either remove INTENT(IN) from or add POINTER to the
example. Sorry for the wrong/incomplete example.

(I can reproduce the result - and seemingly missed the recompile with gfortran
after the modification (needed for NAG 5.1); with NAG the intended error hides
the INTENT error.)

[Bug fortran/46174] [OOP] ALLOCATE with SOURCE: Deep copy missing

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.05 09:48:16
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug target/45670] [4.6 Regression] Less efficient x86 addressing mode selection on 4.6, causes -Os size regression from 4.5

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2010-11-05 
10:03:15 UTC ---
Well, it is actually very much related to that reversion.  While it didn't
regress in between 161907 and 162617, it regressed from the MEM_REF merge till
161906 and from 162618 onwards.
The problem is that due to the MEM load combiner isn't able to fix this up, so
if we don't get it right during expansion, we are out of luck.  Looking at it
now...

[Bug boehm-gc/46311] New: boehm-gc build problem with uclibc

[dougmencken at gmail dot com]

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

   Summary: boehm-gc build problem with uclibc
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: boehm-gc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dougmenc...@gmail.com


I'm trying to get GCC with GCJ (and related libs). The ./configure options I
use are the following:


../"${SOURCE_DIR}"/configure --prefix=/usr --sysconfdir=/etc
--mandir=/usr/share/man \
--enable-languages=c,c++,fortran,java --with-cpu=default32 \
--with-system-zlib --enable-threads=posix \
--disable-nls --disable-werror --disable-multilib --disable-libssp \
--disable-__cxa_atexit --disable-checking --enable-shared \
--enable-libgcj --enable-libgcj-multifile --enable-interpreter
--disable-libjava-multilib


At stage 3, make fails with the following error:


/bin/bash ./libtool   --mode=compile /root/build-farm/_gcc_bootstrap/./gcc/xgcc
-B/root/build-farm/_gcc_bootstrap/./gcc/ -B/usr/powerpc-gnu-linux-uclibc/bin/
-B/usr/powerpc-gnu-linux-uclibc/lib/ -isystem
/usr/powerpc-gnu-linux-uclibc/include -isystem
/usr/powerpc-gnu-linux-uclibc/sys-include-DHAVE_CONFIG_H
-I/root/build-farm/gcc-v4.5.1.sourcedir/boehm-gc/include  -fexceptions
-Iinclude -I././targ-include -I.//libc/include -g -O2 -fexceptions -Iinclude
-I././targ-include -I.//libc/include  -c -o os_dep.lo
../../../gcc-v4.5.1.sourcedir/boehm-gc/os_dep.c
libtool: compile:  /root/build-farm/_gcc_bootstrap/./gcc/xgcc
-B/root/build-farm/_gcc_bootstrap/./gcc/ -B/usr/powerpc-gnu-linux-uclibc/bin/
-B/usr/powerpc-gnu-linux-uclibc/lib/ -isystem
/usr/powerpc-gnu-linux-uclibc/include -isystem
/usr/powerpc-gnu-linux-uclibc/sys-include -DHAVE_CONFIG_H
-I/root/build-farm/gcc-v4.5.1.sourcedir/boehm-gc/include -fexceptions -Iinclude
-I././targ-include -I.//libc/include -g -O2 -fexceptions -Iinclude
-I././targ-include -I.//libc/include -c
../../../gcc-v4.5.1.sourcedir/boehm-gc/os_dep.c  -fPIC -DPIC -o .libs/os_dep.o
../../../gcc-v4.5.1.sourcedir/boehm-gc/os_dep.c:4025:23: fatal error:
execinfo.h: No such file or directory
compilation terminated.
make[3]: *** [os_dep.lo] Error 1
make[3]: Leaving directory
`/root/build-farm/_gcc_bootstrap/powerpc-gnu-linux-uclibc/boehm-gc'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/root/build-farm/_gcc_bootstrap/powerpc-gnu-linux-uclibc/boehm-gc'
make[1]: *** [all-target-boehm-gc] Error 2
make[1]: Leaving directory `/root/build-farm/_gcc_bootstrap'
make: *** [all] Error 2


Diving into that problem, I figured out that boehm-gc sources (actually,
./boehm-gc/include/gc.h) checks if __GLIBC__ is defined, and then trying to
include execinfo.h.

Back in 2006, Solar from Gentoo team already wrote a patch to fix that issue:
http://bugs.gentoo.org/121463 (the patch itself:
http://bugs.gentoo.org/attachment.cgi?id=80702 ). With this patch, boehm-gc
builds without errors.

[Bug c++/46304] [4.5 Regression] g++ crashes with ICE in bitmap_first_set_bit, at bitmap.c:770

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |ASSIGNED
  Known to work||4.4.4, 4.6.0
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.5.2
Summary|g++ crashes with ICE in |[4.5 Regression] g++
   |bitmap_first_set_bit, at|crashes with ICE in
   |bitmap.c:770|bitmap_first_set_bit, at
   ||bitmap.c:770
  Known to fail||4.5.0, 4.5.1

--- Comment #4 from Richard Guenther  2010-11-05 
10:48:55 UTC ---
Confirmed.  Happens as we go into SSA form.

#2  0x007ed310 in bitmap_first_set_bit (a=0x19c13e8)
at /space/rguenther/src/svn/gcc-4_5-branch/gcc/bitmap.c:770
770   gcc_assert (elt);
(gdb) 
#3  0x00c61587 in set_livein_block (var=0x77ef3d20, 
bb=0x75b318f0)
at /space/rguenther/src/svn/gcc-4_5-branch/gcc/tree-into-ssa.c:550
550   int def_block_index = bitmap_first_set_bit (db_p->def_blocks);

when visiting

(gdb) call debug_gimple_stmt (stmt)
D.2447 = COMPLEX_EXPR ;

and the bitmap is empty.  D.2444 is not set before.

void ClassA::setSize() [with T = __complex__ double] (struct ClassA * const
this)
{
  complex double D.2447;
  complex double * D.2446;

:
  D.2446 = this->data;
  D.2447 = COMPLEX_EXPR ;
  *D.2446 = D.2447;
  return;

}

it looks like this caller to bitmap_first_set_bit assumes it's ok to
call it on an empty bitmap where it should return -1.

It's interesting though that 4.6 for the above has

void ClassA::setSize() [with T = __complex__ double] (struct ClassA * this)
{
  complex double D.2421;
  double D.2420;
  complex double * D.2419;

:
  D.2419 = this->data;
  D.2420 = 1.0e+0 + 0.0;
  D.2421 = COMPLEX_EXPR ;
  *D.2419 = D.2421;
  return;

}

which shows it's also really a wrong-code bug.

[Bug target/45670] [4.6 Regression] Less efficient x86 addressing mode selection on 4.6, causes -Os size regression from 4.5

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  2010-11-05 
10:48:39 UTC ---
Created attachment 22291
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22291
gcc46-pr45670.patch

Untested fix.

[Bug c++/46304] [4.5 Regression] g++ crashes with ICE in bitmap_first_set_bit, at bitmap.c:770

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2010-11-05 
10:54:59 UTC ---
Smaller testcase - I suspect a tree sharing issue.

template
struct ClassA
{
  _Complex double *data;
  void setSize() { data[0] = 1.0 + 2.0i; }
};

void foo(void)
{
  ClassA<0> a1;
  ClassA<1> a2;
  a1.setSize();
  a2.setSize();
}

[Bug middle-end/43690] [4.3/4.4/4.5/4.6 Regression] Internal compiler error detected by avr-gcc.

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2010-11-05 
11:11:56 UTC ---
Author: jakub
Date: Fri Nov  5 11:11:50 2010
New Revision: 166354

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166354
Log:
PR middle-end/43690
* gimplify.c (gimplify_asm_expr): If a "m" input is a
{pre,post}{in,de}crement, fail.

* c-c++-common/pr43690.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr43690.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/46099] [4.5/4.6 Regression] ICE: in replace_ssa_name, at tree-cfg.c:5643 with -ftree-parallelize-loops -g

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2010-11-05 
11:15:32 UTC ---
Author: jakub
Date: Fri Nov  5 11:15:28 2010
New Revision: 166355

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166355
Log:
PR tree-optimization/46099
* tree-parloops.c (take_address_of): Add GSI argument.  Return NULL
if it is NULL and uid wasn't found in the hash table.  Just fold the
result if it is NULL otherwise.  Insert other potentially needed
stmts right before current stmt instead of on the entry edge.
(struct elv_data): Add gsi and reset fields.
(eliminate_local_variables_1): Adjust caller.  If take_address_of
failed for debug stmt, set dta->reset and return.
(eliminate_local_variables_stmt): Change STMT argument for GSI,
pass GSI through to the callback, handle resetting of debug stmts.
(eliminate_local_variables): Adjust caller.  Process debug stmts
in second phase.

* gcc.dg/autopar/pr46099.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/autopar/pr46099.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-parloops.c

[Bug target/45670] [4.6 Regression] Less efficient x86 addressing mode selection on 4.6, causes -Os size regression from 4.5

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  2010-11-05 
11:17:11 UTC ---
> Well, it is actually very much related to that reversion.  While it didn't
> regress in between 161907 and 162617, it regressed from the MEM_REF merge till
> 161906 and from 162618 onwards.

Yes, that isn't different from what I said, it had been caused by something
else.

> The problem is that due to the MEM load combiner isn't able to fix this up, so
> if we don't get it right during expansion, we are out of luck.  Looking at it
> now...

Thanks!

[Bug c++/46304] [4.5 Regression] g++ crashes with ICE in bitmap_first_set_bit, at bitmap.c:770

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Guenther  2010-11-05 
11:20:00 UTC ---
Hm.  In 4.6 two different COMPLEX_EXPRs are built by tsubst, via
cp_build_binary_op (PLUS_EXPR, ...).  In 4.5 we end up with a COMPLEX_EXPR
at tsubst time which we don't handle explicitly but pass through from
tsubst_copy default case (which would ICE on trunk).

Jason?

[Bug tree-optimization/46312] New: gcc.dg/vec-scal-opt2.c fails for ARM targets.

[ramana at gcc dot gnu.org]

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

   Summary: gcc.dg/vec-scal-opt2.c fails for ARM targets.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ram...@gcc.gnu.org
CC: rgue...@gcc.gnu.org
  Host: x86_64-unknown-linux-gnu
Target: arm-linux-gnueabi
 Build: x86_64-unknown-linux-gnu


Hi, 

This test fails for ARM targets configured in the following manner -


/home/ramana/cross-build/src/trunk/configure --target=arm-none-linux-gnueabi
--with-cpu=cortex-a9 --with-fpu=neon --with-float=softfp 

The dump file doesn't contain << 2 and hence the test fails. 

This fails right from : r166303 for ARM


Author: rguenth
Date: Thu Nov  4 10:54:33 2010
New Revision: 166303

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166303
Log:
2010-11-04  Artjoms Sinkarovs 
Richard Guenther  

* passes.c (init_optimization_passes): Move veclower after SSA.
* tree-vect-generic.c (uniform_vector_p): New function.
(expand_vector_operations_1): Handle conversion.
(pass_lower_vector): Update SSA form.

testsuite/
* gcc.dg/vec-scal-opt.c: New testcase.
* gcc.dg/vec-scal-opt1.c: New testcase.
* gcc.dg/vec-scal-opt2.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vec-scal-opt.c
trunk/gcc/testsuite/gcc.dg/vec-scal-opt1.c
trunk/gcc/testsuite/gcc.dg/vec-scal-opt2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-generic.c


cheers
Ramana

[Bug target/44750] pdp-11 fails to build

[amylaar at gcc dot gnu.org]

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

--- Comment #3 from Jorn Wolfgang Rennecke  
2010-11-05 11:27:19 UTC ---
Author: amylaar
Date: Fri Nov  5 11:27:16 2010
New Revision: 166356

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166356
Log:
 PR target/44750
* config/pdp11/t-pdp11 (dwarf2out.o, java/constants.o): Undo last
change.  Set $...@-warn.o to -Wno-error.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pdp11/t-pdp11

[Bug tree-optimization/46312] gcc.dg/vec-scal-opt2.c fails for ARM targets.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.05 11:29:41
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2010-11-05 
11:29:41 UTC ---
Hm, of course.  Does adding

/* { dg-require-effective-target vect_shift } */

make it unsupported?  (I see that would be true for
check_effective_target_arm32,
so, does gcc.dg/vect/vect-shift-1.c also fail?

[Bug middle-end/43690] [4.3/4.4/4.5 Regression] Internal compiler error detected by avr-gcc.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||4.6.0
Summary|[4.3/4.4/4.5/4.6|[4.3/4.4/4.5 Regression]
   |Regression] Internal|Internal compiler error
   |compiler error detected by  |detected by avr-gcc.
   |avr-gcc.|
  Known to fail|4.6.0   |

--- Comment #5 from Jakub Jelinek  2010-11-05 
11:31:49 UTC ---
Fixed on the trunk.

[Bug tree-optimization/46099] [4.5 Regression] ICE: in replace_ssa_name, at tree-cfg.c:5643 with -ftree-parallelize-loops -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||4.6.0
Summary|[4.5/4.6 Regression] ICE:   |[4.5 Regression] ICE: in
   |in replace_ssa_name, at |replace_ssa_name, at
   |tree-cfg.c:5643 with|tree-cfg.c:5643 with
   |-ftree-parallelize-loops -g |-ftree-parallelize-loops -g
  Known to fail|4.6.0   |

--- Comment #5 from Jakub Jelinek  2010-11-05 
11:33:48 UTC ---
Fixed on the trunk.

[Bug tree-optimization/46312] gcc.dg/vec-scal-opt2.c fails for ARM targets.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2010-11-05 
11:39:19 UTC ---
It fails even on i686-linux:
Executing on host: /usr/src/gcc/obj333/gcc/xgcc -B/usr/src/gcc/obj333/gcc/
/usr/src/gcc/gcc/testsuite/gcc.dg/vec-scal-opt.c   -O -fdump-tree-veclower -S 
-o vec-scal-opt.s(timeout = 300)
PASS: gcc.dg/vec-scal-opt.c (test for excess errors)
FAIL: gcc.dg/vec-scal-opt.c scan-tree-dump-times veclower ">> k.[0-9_]*" 1
Executing on host: /usr/src/gcc/obj333/gcc/xgcc -B/usr/src/gcc/obj333/gcc/
/usr/src/gcc/gcc/testsuite/gcc.dg/vec-scal-opt1.c   -O -fdump-tree-veclower -S 
-o vec-scal-opt1.s(timeout = 300)
PASS: gcc.dg/vec-scal-opt1.c (test for excess errors)
FAIL: gcc.dg/vec-scal-opt1.c scan-tree-dump-times veclower ">> 2" 1
Executing on host: /usr/src/gcc/obj333/gcc/xgcc -B/usr/src/gcc/obj333/gcc/
/usr/src/gcc/gcc/testsuite/gcc.dg/vec-scal-opt2.c   -O -fdump-tree-veclower -S 
-o vec-scal-opt2.s(timeout = 300)
PASS: gcc.dg/vec-scal-opt2.c (test for excess errors)
FAIL: gcc.dg/vec-scal-opt2.c scan-tree-dump-times veclower ">> 2" 1
Executing on host: /usr/src/gcc/obj333/gcc/xgcc -B/usr/src/gcc/obj333/gcc/
/usr/src/gcc/gcc/testsuite/gcc.dg/vector-1.c-S  -o vector-1.s(timeout =
300)
/usr/src/gcc/gcc/testsuite/gcc.dg/vector-1.c: In function 'f':
/usr/src/gcc/gcc/testsuite/gcc.dg/vector-1.c:13:7: error: wrong type argument
to bit-complement
compiler exited with status 1
output is:
/usr/src/gcc/gcc/testsuite/gcc.dg/vector-1.c: In function 'f':
/usr/src/gcc/gcc/testsuite/gcc.dg/vector-1.c:13:7: error: wrong type argument
to bit-complement

I guess the bug is that the testcase should be put into gcc.dg/vect/ rather
than gcc.dg/ directly.

[Bug tree-optimization/46312] gcc.dg/vec-scal-opt2.c fails for ARM targets.

[ramana.r at gmail dot com]

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

--- Comment #3 from Ramana Radhakrishnan  2010-11-05 
11:41:40 UTC ---
> --- Comment #1 from Richard Guenther  2010-11-05 
> 11:29:41 UTC ---
> Hm, of course.  Does adding
>
> /* { dg-require-effective-target vect_shift } */
>
> make it unsupported?  (I see that would be true for
> check_effective_target_arm32,

Isn't that true for arm32 and hence making that check would be a no-op
won't it ?  We do have vector shifts for Neon.


> so, does gcc.dg/vect/vect-shift-1.c also fail?

I begin to see an execute failure with gcc.dg/vect/vect-shift-1.c

gcc.dg/vect-scalop-2.c and gcc.dg/vect-scalop.c also appear to fail similarly .

Ramana

From the latest test results gcc.dg/vect/vect-shift-1.c also appears
to have an execution failure.







>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.
>

[Bug tree-optimization/46312] gcc.dg/vec-scal-opt2.c fails for ARM targets.

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  
2010-11-05 11:43:48 UTC ---
On Fri, 5 Nov 2010, jakub at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46312
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org
> 
> --- Comment #2 from Jakub Jelinek  2010-11-05 
> 11:39:19 UTC ---
> It fails even on i686-linux:

Hm, it tested ok on x86_64 with -m32.

> Executing on host: /usr/src/gcc/obj333/gcc/xgcc -B/usr/src/gcc/obj333/gcc/
> /usr/src/gcc/gcc/testsuite/gcc.dg/vec-scal-opt.c   -O -fdump-tree-veclower -S 
> -o vec-scal-opt.s(timeout = 300)
> PASS: gcc.dg/vec-scal-opt.c (test for excess errors)
> FAIL: gcc.dg/vec-scal-opt.c scan-tree-dump-times veclower ">> k.[0-9_]*" 1
> Executing on host: /usr/src/gcc/obj333/gcc/xgcc -B/usr/src/gcc/obj333/gcc/
> /usr/src/gcc/gcc/testsuite/gcc.dg/vec-scal-opt1.c   -O -fdump-tree-veclower 
> -S 
> -o vec-scal-opt1.s(timeout = 300)
> PASS: gcc.dg/vec-scal-opt1.c (test for excess errors)
> FAIL: gcc.dg/vec-scal-opt1.c scan-tree-dump-times veclower ">> 2" 1
> Executing on host: /usr/src/gcc/obj333/gcc/xgcc -B/usr/src/gcc/obj333/gcc/
> /usr/src/gcc/gcc/testsuite/gcc.dg/vec-scal-opt2.c   -O -fdump-tree-veclower 
> -S 
> -o vec-scal-opt2.s(timeout = 300)
> PASS: gcc.dg/vec-scal-opt2.c (test for excess errors)
> FAIL: gcc.dg/vec-scal-opt2.c scan-tree-dump-times veclower ">> 2" 1
> Executing on host: /usr/src/gcc/obj333/gcc/xgcc -B/usr/src/gcc/obj333/gcc/
> /usr/src/gcc/gcc/testsuite/gcc.dg/vector-1.c-S  -o vector-1.s(timeout 
> =
> 300)
> /usr/src/gcc/gcc/testsuite/gcc.dg/vector-1.c: In function 'f':
> /usr/src/gcc/gcc/testsuite/gcc.dg/vector-1.c:13:7: error: wrong type argument
> to bit-complement
> compiler exited with status 1
> output is:
> /usr/src/gcc/gcc/testsuite/gcc.dg/vector-1.c: In function 'f':
> /usr/src/gcc/gcc/testsuite/gcc.dg/vector-1.c:13:7: error: wrong type argument
> to bit-complement
> 
> I guess the bug is that the testcase should be put into gcc.dg/vect/ rather
> than gcc.dg/ directly.

But that enables -ftree-vectorize, but ok - I guess that doesn't matter
too much.

[Bug rtl-optimization/45865] [4.6 Regression] ifcvt/crossjump failed to mark return jump

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #15 from H.J. Lu  2010-11-05 11:52:51 
UTC ---
Fixed.

[Bug libstdc++/46303] 'mutex' is not a member of 'std' failures in 30_threads/call_once/constexpr.cc, 30_threads/mutex/cons/constexpr.cc, 30_threads/once_flag/cons/constexpr.cc

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #8 from Paolo Carlini  2010-11-05 
12:02:18 UTC ---
Should be fixed. Otherwise please re-open with updated details, thanks.

[Bug tree-optimization/45314] [4.5/4.6 Regression] ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
  Known to fail||

--- Comment #4 from Jakub Jelinek  2010-11-05 
12:28:58 UTC ---
Can't reproduce with current trunk,
./cc1plus -m32 -O2 pr45314.ii -quiet -floop-interchange
is fine.

[Bug rtl-optimization/46238] [4.6 Regression] s390x bootstrap problem: wrong code generated in cfgcleanup/crossjumping

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  2010-11-05 
12:30:19 UTC ---
Fixed then.

[Bug c++/45894] [4.5/4.6 Regression] [C++0x] ICE: segmentation fault with -Wall

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2010-11-05 
12:50:15 UTC ---
Apparently lvalue_p is called on
 
VOID
align 1 symtab 0 alias set -1 canonical type 0x71accc78
pointer_to_this 
reference_to_this >

functions 
function >>
binfo 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x71add0a8 fields
 context 
full-name "struct F"
X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
pointer_to_this  chain >
   > access_binfo >

which leads to lvalue_kind being called on the template_id_expr
(0x77ffc188 above) which has no type.

Can be fixed by making lvalue_kind more robust:
--- gcc/cp/tree.c.jj2010-11-03 16:58:26.0 +0100
+++ gcc/cp/tree.c   2010-11-05 13:45:53.0 +0100
@@ -67,7 +67,8 @@ lvalue_kind (const_tree ref)
  == REFERENCE_TYPE)
 return lvalue_kind (TREE_OPERAND (ref, 0));

-  if (TREE_CODE (TREE_TYPE (ref)) == REFERENCE_TYPE)
+  if (TREE_TYPE (ref)
+  && TREE_CODE (TREE_TYPE (ref)) == REFERENCE_TYPE)
 {
   /* unnamed rvalue references are rvalues */
   if (TYPE_REF_IS_RVALUE (TREE_TYPE (ref))

but no idea whether that is the right thing to do.

[Bug bootstrap/46018] [4.6 Regression] Bootstrap fails on i386-pc-solaris2.10

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #18 from H.J. Lu  2010-11-05 13:07:44 
UTC ---
Fixed.

[Bug bootstrap/44756] [meta-bug] --enable-werror-always issues

[amylaar at gcc dot gnu.org]

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

--- Comment #6 from Jorn Wolfgang Rennecke  
2010-11-05 13:27:29 UTC ---
Author: amylaar
Date: Fri Nov  5 13:27:23 2010
New Revision: 166360

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166360
Log:
PR bootstrap/44756
* expr.c (emit_push_insn): Cast value of PUSH_ROUNDING before
comparing it to a signed value.

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

[Bug c/44772] [4.5/4.6 Regression] -Wc++-compat warns incorrectly for anonymous unions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug c/44772] [4.5/4.6 Regression] -Wc++-compat warns incorrectly for anonymous unions

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2010-11-05 
13:53:26 UTC ---
Created attachment 22292
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22292
gcc46-pr44472.patch

Untested fix.

[Bug fortran/46244] gfc_compare_derived_types is buggy

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||bur...@net-b.de, pault at
   ||gcc dot gnu.org

--- Comment #7 from Dominique d'Humieres  2010-11-05 
13:56:29 UTC ---
Is the code in comment #5 valid Fortran? If no, what kind of error should it
emit? (If yes, I would be interested to know what it would be supposed to
do!-).

If I replace one of the 

  type b
  sequence
  type(a), pointer :: pa
  end type b

with

  type b
  sequence
  class(a), pointer :: pa
  end type b

the code is rejected with

Error: Type mismatch in argument 'x' at (1); passed TYPE(a) to TYPE(a)

Is this correct?

If I do the replacement in both places, I am back to the infinite loop (-> it
gives a segmentation fault).
Again is the modified code valid?

[Bug fortran/46313] New: [OOP] OOP-ABI issue, ALLOCATE issue, CLASS renaming issue

[burnus at gcc dot gnu.org]

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

   Summary: [OOP] OOP-ABI issue, ALLOCATE issue, CLASS renaming
issue
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


There are a couple of issues which prevent the following program from working.

(a) and (b) are compile time issues and (c) is a link-time issue (OOP ABI)


a) It fails to compile with: 

allocate ( t1 :: a1)
  1
Error: Error in type-spec at (1)


b) Working around this issue, as in

allocate (a1, source=t1())
allocate (b1, source=t2())

yields the error 

print *, b2%b
 1
Error: 'b' at (1) is not a member of the 'mytype' structure


Using Cray ftn, the result is:
 10*2.
 10*8.

!

module m1
  type mytype
real :: a(10) = 2
  end type mytype
end module m1

module m2
  type mytype
real :: b(10) = 8
  end type mytype
end module m2

use m1, t1 => mytype
use m2, t2 => mytype
implicit none
class(t1), allocatable :: a1, a2
class(t2), allocatable :: b1, b2

allocate ( t1 :: a1)
allocate ( t2 :: b1)

allocate ( a2, source=a1)
allocate ( b2, source=b1)
!allocate ( a2, mold=a1)
!allocate ( b2, mold=b1)
print *, a2%a
print *, b2%b
end
!



(c) The following fails to link as the VTABLE only encodes the type name and
not the module name:

/tmp/ccBQh5fR.s: Assembler messages:
/tmp/ccBQh5fR.s:401: Error: symbol `copy$mytype2_' is already defined
/tmp/ccBQh5fR.s:431: Error: symbol `copy$mytype_' is already defined


!
module m1
  implicit none
  type mytype
  end type mytype
  type,extends(mytype) :: mytype2
integer :: a(10) = 2
  end type mytype2
contains
  subroutine test1()
class(mytype), allocatable :: a1, a2
allocate (a1, source=mytype2())
allocate ( a2, source=a1)
select type (a2)
  type is (mytype2)
print *, a2%a
end select
deallocate  (a2)
allocate ( a2, mold=a1)
select type (a2)
  type is (mytype2)
print *, a2%a
end select
  end subroutine test1
end module m1

module m2
  implicit none
  type mytype
  end type mytype
  type,extends(mytype) :: mytype2
integer :: b(10) = 8
  end type mytype2
contains
  subroutine test2()
class(mytype), allocatable :: b1, b2
allocate (b1, source=mytype2())
allocate ( b2, source=b1)
select type (b2)
  type is (mytype2)
print *, b2%b
end select
deallocate  (b2)
allocate ( b2, mold=b1)
select type (b2)
  type is (mytype2)
print *, b2%b
end select
  end subroutine test2
end module m2

use m1, only: test1
use m2, only: test2
implicit none
call test1()
call test2()
end
!

[Bug fortran/46244] gfc_compare_derived_types is buggy

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #8 from Tobias Burnus  2010-11-05 
15:01:17 UTC ---
(In reply to comment #7)
>   type b
>   sequence
>   class(a), pointer :: pa
>   end type b

That's invalid per F2008's

"C436 (R425) If SEQUENCE appears, each data component shall be declared to be
of an intrinsic type or of a sequence type, and a type-bound-procedure-part
shall not appear."

Or as NAG puts it:
  Error: ac.f90, line 8: CLASS entity of SEQUENCE type A
and ifort has:

  ac.f90(8): error #8224: A derived type used with the CLASS keyword shall not
have the BIND attribute or SEQUENCE property.   [A]

[Bug c++/46160] [4.5/4.6 Regression] ICE with volatile structure and enum

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from Jakub Jelinek  2010-11-05 
15:17:17 UTC ---
Created attachment 22293
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22293
gcc46-pr46160.patch

Untested fix.

[Bug middle-end/46314] New: frontends use ASM_GENERATE_INTERNAL_LABEL

[amylaar at gcc dot gnu.org]

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

   Summary: frontends use ASM_GENERATE_INTERNAL_LABEL
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org


cp/method.c:  ASM_GENERATE_INTERNAL_LABEL (buf, "LTHUNK", thunk_labelno);
java/class.c:  ASM_GENERATE_INTERNAL_LABEL (buf, name, alias_labelno++);  
java/expr.c:  ASM_GENERATE_INTERNAL_LABEL(buf, "LJpc=",
start_label_pc_this_method + pc);
java/expr.c:  ASM_GENERATE_INTERNAL_LABEL(buff, "LJv", l_number);

I currently get a warning building java for picochip because of this issue.

We should have a target hook so that we can wean the frontends off this macro.

[Bug tree-optimization/45314] [4.5/4.6 Regression] ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange

[bero at arklinux dot org]

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

--- Comment #5 from bero at arklinux dot org 2010-11-05 15:30:20 UTC ---
Still happens on current 4.5 branch

[Bug fortran/46313] [OOP] OOP-ABI issue, ALLOCATE issue, CLASS renaming issue

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2010-11-05 15:46:10 UTC ---
With r166360, I do not see the (a) problem.  Are you using a
clean source tree or do you have local changes?  For the
first code, I see

troutmask:sgk[209] gfc4x -o z tr.f90
tr.f90:20.17:

allocate ( t2 :: b1)
 1
Error: Type of entity at (1) is type incompatible with typespec
tr.f90:27.13:

print *, b2%b
 1
Error: 'b' at (1) is not a member of the 'mytype' structure


I'll also note that your (b) workaround fails with

troutmask:sgk[240] gfc4x -o z tr.f90
tr.f90:27.13:

print *, b2%b
 1
Error: 'b' at (1) is not a member of the 'mytype' structure
tr.f90:20.10-21:

allocate (b1, source=t2())
  1  2
Error: Type of entity at (1) is type incompatible with source-expr at (2)

-fdump-parse-tree suggests that the parsing of class(t2) :: b1, b2
is not picking up the renamed type.

Namespace: A-Z: (UNKNOWN 0)
procedure name = MAIN__
  symtree: 'MAIN__'  || symbol: 'MAIN__'   
type spec : (UNKNOWN 0)
attributes: (PROGRAM PUBLIC  SUBROUTINE)
  symtree: 'a1'  || symbol: 'a1'   
type spec : (CLASS class$mytype_a)
attributes: (VARIABLE )
value: class$mytype_a(NULL() , ())
  symtree: 'a2'  || symbol: 'a2'   
type spec : (CLASS class$mytype_a)
attributes: (VARIABLE )
value: class$mytype_a(NULL() , ())
  symtree: 'b1'  || symbol: 'b1'   
type spec : (CLASS class$mytype_a)
attributes: (VARIABLE )
value: class$mytype_a(NULL() , ())
  symtree: 'b2'  || symbol: 'b2'   
type spec : (CLASS class$mytype_a)
attributes: (VARIABLE )
value: class$mytype_a(NULL() , ())
  symtree: 'class$mytype_a'|| symbol: 'class$mytype_a' 
type spec : (UNKNOWN 0)
attributes: (DERIVED )
components: ($data (DERIVED mytype) () PRIVATE)
($vptr (DERIVED vtype$mytype) POINTER () PRIVATE)

Procedure bindings:
Operator bindings:
  symtree: 'def_init$mytype'|| symbol: 'def_init$mytype' 
type spec : (DERIVED mytype)
attributes: (VARIABLE PUBLIC EXPLICIT-SAVE TARGET)
value: mytype(2.)
  symtree: 'm1'  || symbol: 'm1'   
type spec : (UNKNOWN 0)
attributes: (MODULE  USE-ASSOC(m1))
  symtree: 'm2'  || symbol: 'm2'   
type spec : (UNKNOWN 0)
attributes: (MODULE  USE-ASSOC(m2))
  symtree: 't1'  || symbol: 'mytype'   
type spec : (UNKNOWN 0)
attributes: (DERIVED  USE-ASSOC(m1))
components: (a (REAL 4) DIMENSION (1 [0] AS_EXPLICIT 1 10 ))
hash: 22483813
Procedure bindings:
Operator bindings:
  symtree: 't2'  || symbol: 'mytype'   
type spec : (UNKNOWN 0)
attributes: (DERIVED  USE-ASSOC(m2))
components: (b (REAL 4) DIMENSION (1 [0] AS_EXPLICIT 1 10 ))
hash: 58329636
Procedure bindings:
Operator bindings:
  symtree: 'vtab$mytype' || symbol: 'vtab$mytype'  
type spec : (DERIVED vtype$mytype)
attributes: (VARIABLE PUBLIC EXPLICIT-SAVE TARGET)
value: vtype$mytype(22483813 , 0 , NULL() , MAIN__:def_init$mytype)
  symtree: 'vtype$mytype'|| symbol: 'vtype$mytype' 
type spec : (UNKNOWN 0)
attributes: (DERIVED PUBLIC )
components: ($hash (INTEGER 4) () PRIVATE)
($size (INTEGER 4) () PRIVATE)
($extends (DERIVED vtype$mytype) POINTER () PRIVATE)
($def_init (DERIVED mytype) POINTER () PRIVATE)

  code:
  ALLOCATE  MAIN__:a1
  ALLOCATE  MAIN__:b1
  ALLOCATE  MAIN__:a2
  ALLOCATE  MAIN__:b2
  WRITE UNIT=6 FMT=-1
  TRANSFER MAIN__:a2 % a(FULL)
  DT_END

Finally, note that if you rename mytype in either module to
something unique, then the code compiles.

[Bug fortran/46313] [OOP] OOP-ABI issue, ALLOCATE issue, CLASS renaming issue

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #2 from Steve Kargl  
2010-11-05 16:04:31 UTC ---
On Fri, Nov 05, 2010 at 03:46:14PM +, kargl at gcc dot gnu.org wrote:
> 
> -fdump-parse-tree suggests that the parsing of class(t2) :: b1, b2
> is not picking up the renamed type.
> 

I think allocate() is doing its job.  This looks like class()
is getting confused by the rename.

module m1
  type mytype
integer :: a(10) = 2
integer :: b(10) = 3
  end type mytype
end module m1

module m2
  type mytype
real :: a(10) = 8
real :: b(10) = 9
  end type mytype
end module m2

program testing
  use m1, t1 => mytype
  use m2, t2 => mytype

  implicit none

  class(t1), allocatable :: a1
  class(t2), allocatable :: b1
  allocate(a1, b1)
  print '(10(I0,1X))', a1%a
  print '(10(I0,1X))', b1%b
end program testing

troutmask:sgk[203] gfc4x -o z tr.f90 && ./z
2 2 2 2 2 2 2 2 2 2
3 3 3 3 3 3 3 3 3 3

[Bug tree-optimization/45314] [4.5/4.6 Regression] ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  2010-11-05 16:26:44 
UTC ---
On trunk, it was fixed by revision 163123:

http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00334.html

[Bug c/46315] New: gcc-4.5.1 -O2 -fno-strict-overflow causes bad code generation

[zorry at gentoo dot org]

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

   Summary: gcc-4.5.1 -O2 -fno-strict-overflow causes bad code
generation
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zo...@gentoo.org


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

If we disable -fstrict-overflow in the -O2 optimization the testcase segfault
but works fine with -O1 or -fstrict-overflow on in the -O2 optimization.
fl...@yamato mytmpfs % gcc -O2 -fno-strict-overflow testcase.c -o testcase
fl...@yamato mytmpfs % ./testcase
0x400770
0x2
zsh: segmentation fault (core dumped)  ./testcase

[Bug bootstrap/44756] [meta-bug] --enable-werror-always issues

[amylaar at gcc dot gnu.org]

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

--- Comment #7 from Jorn Wolfgang Rennecke  
2010-11-05 16:27:37 UTC ---
Author: amylaar
Date: Fri Nov  5 16:27:25 2010
New Revision: 166366

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166366
Log:
PR bootstrap/44756
* expr.c (can_store_by_pieces): Add ATTRIBUTE_UNUSED to cst.
* haifa-sched.c (initiate_bb_reg_pressure_info): Add ATTRIBUTE_UNUSED
to i.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/haifa-sched.c

[Bug tree-optimization/46316] New: [4.6 regression] incorrect loop optimization

[ebotcazou at gcc dot gnu.org]

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

   Summary: [4.6 regression] incorrect loop optimization
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ebotca...@gcc.gnu.org


The Ada runtime (a-calend.adb) is miscompiled at -O2 on x86 at revision 166350.
An infinite loop is generated by the compiler in the UTC_Time_Offset function.

The reduced C testcase is just:

extern void abort (void);

long long __attribute__((noinline,noclone))
foo (long long t)
{
  while (t > -4)
t -= 2;

  return t;
}

int main(void)
{
  if (foo (0) != -4)
abort ();
  return 0;
}

e...@atlantis:~/build/gcc/native32> gcc/xgcc -Bgcc -o t t.c -O2
e...@atlantis:~/build/gcc/native32> ./t
^C
e...@atlantis:~/build/gcc/native32>

[Bug tree-optimization/46315] [4.5 Regression] gcc-4.5.1 -O2 -fno-strict-overflow causes bad code generation

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.05 16:43:32
  Known to work||4.4.4, 4.6.0
   Target Milestone|--- |4.5.2
Summary|gcc-4.5.1 -O2   |[4.5 Regression] gcc-4.5.1
   |-fno-strict-overflow causes |-O2 -fno-strict-overflow
   |bad code generation |causes bad code generation
 Ever Confirmed|0   |1
  Known to fail||4.5.0, 4.5.1

--- Comment #1 from Richard Guenther  2010-11-05 
16:43:32 UTC ---
Confirmed.

[Bug tree-optimization/46315] [4.5 Regression] gcc-4.5.1 -O2 -fno-strict-overflow causes bad code generation

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2010-11-05 
16:47:12 UTC ---
ipa-cp triggers this but is not neccessarily at fault.  Workaround:
-fno-ipa-cp.

[Bug c++/46317] New: Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance

[end3er at gmail dot com]

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

   Summary: Incorrect construction vtable on ARM in case of
diamond shaped virtual inheritance
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: end...@gmail.com


Created attachment 22295
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22295
Code that triggers the issue on ARM

This problem appears on ARM (not x86), with -O > 0.

The register R1 holding the pointer to the construction vtable for the
Parent-in-Child is actually pointing to the wrong Parent-in-Child vtable:

Let's assume we have a virtual base class A, two derived class B and C
virtually inheriting from A and a final class D derived virtually from B and
normally from C.

When instantiating D, the CTOR for B is called with R1 pointing to the
construction vtable for B-in-D instead of the one for C-in-D, which thus make
the program crash since it tries to access an uninitialized element of the
vtable for B when trying to access elements in C. 

A work-around for this issue is to compile with -fno-toplevel-reorder. It fixes
the problem for all optimizations level

This issue seems to be linked to #41354.

Re: [Bug tree-optimization/45314] [4.5/4.6 Regression] ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange

[Sebastian Pop]

On Fri, Nov 5, 2010 at 11:26, hjl.tools at gmail dot com
 wrote:
> On trunk, it was fixed by revision 163123:
>
> http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00334.html
>

Thanks HJ for reducing this.
I looked at this change and it looks simple enough to backport it to 4.5.

[Bug tree-optimization/45314] [4.5/4.6 Regression] ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange

[sebpop at gmail dot com]

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

--- Comment #7 from sebpop at gmail dot com  
2010-11-05 16:51:22 UTC ---
On Fri, Nov 5, 2010 at 11:26, hjl.tools at gmail dot com
 wrote:
> On trunk, it was fixed by revision 163123:
>
> http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00334.html
>

Thanks HJ for reducing this.
I looked at this change and it looks simple enough to backport it to 4.5.

[Bug c++/46317] Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2010-11-05 
16:55:29 UTC ---
Does -fno-tree-sink fixes the issue?

[Bug ada/46318] New: ICE (GNAT bug box) on invalid

[baldrick at gcc dot gnu.org]

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

   Summary: ICE (GNAT bug box) on invalid
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: baldr...@gcc.gnu.org


Caused by a missing parameter in a generic instantiation (the comma is
there, but not the term that should follow it).  Occurs with current trunk.

$ gcc-4.6 -c m.adb 
+===GNAT BUG DETECTED==+
| 4.6.0 20101105 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure
sinfo.adb:1831|
| Error detected at n.adb:4:14 [m.adb:3:3] |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

m.adb
n.ads
n.adb


raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : namet.adb:655

-- chop here -- testcase --

with N;
procedure M is
  package NI is new N (1, -- missing term
  );
begin null; end;

generic
   A : Integer;
   B : Integer := 0;
package N is
   function F return Integer;
end;

package body N is
  function F return Integer is
  begin
  return B;
  end;
end;

[Bug c++/46317] Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance

[end3er at gmail dot com]

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

--- Comment #2 from end3er at gmail dot com 2010-11-05 17:06:49 UTC ---
(In reply to comment #1)
> Does -fno-tree-sink fixes the issue?

No it doesn't. The only flags that works are:
-O0 or
-fno-inline or
-fno-unit-at-a-time or
-fno-toplevel-reorder

I can also make it work more or less by deactivating a certain number of
optimisation flag, but the output code does not really work... (I have tried
something like 58 different flags...)

[Bug lto/46319] New: LTO plugin test failures with --wi th-plugin-ld=ld

[hjl.tools at gmail dot com]

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

   Summary: LTO plugin test failures with --wi th-plugin-ld=ld
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: da...@gcc.gnu.org


On Linux/x86-64, with binutils from CVS on 2010-11-05,
revision 166360 gave extra failures:

FAIL: gcc.dg/plugin/finish_unit-test-1.c -fplugin=./finish_unit_plugin.so (test
for excess errors)
FAIL: gcc.dg/plugin/finish_unit-test-1.c -fplugin=./finish_unit_plugin.so (test
for excess errors)
FAIL: gcc.dg/plugin/ggcplug-test-1.c -fplugin=./ggcplug.so (test for excess
errors)
FAIL: gcc.dg/plugin/ggcplug-test-1.c -fplugin=./ggcplug.so (test for excess
errors)
FAIL: gcc.dg/plugin/one_time-test-1.c -fplugin=./one_time_plugin.so (test for
excess errors)
FAIL: gcc.dg/plugin/one_time-test-1.c -fplugin=./one_time_plugin.so (test for
excess errors)
FAIL: gcc.dg/plugin/self-assign-test-1.c -fplugin=./selfassign.so (test for
excess errors)
FAIL: gcc.dg/plugin/self-assign-test-1.c -fplugin=./selfassign.so (test for
excess errors)
FAIL: gcc.dg/plugin/self-assign-test-1.c -fplugin=./selfassign.so  (test for
warnings, line 15)
FAIL: gcc.dg/plugin/self-assign-test-1.c -fplugin=./selfassign.so  (test for
warnings, line 15)
FAIL: gcc.dg/plugin/self-assign-test-1.c -fplugin=./selfassign.so  (test for
warnings, line 19)
FAIL: gcc.dg/plugin/self-assign-test-1.c -fplugin=./selfassign.so  (test for
warnings, line 19)
FAIL: gcc.dg/plugin/self-assign-test-1.c -fplugin=./selfassign.so  (test for
warnings, line 20)
FAIL: gcc.dg/plugin/self-assign-test-1.c -fplugin=./selfassign.so  (test for
warnings, line 20)
FAIL: gcc.dg/plugin/self-assign-test-1.c -fplugin=./selfassign.so  (test for
warnings, line 21)
FAIL: gcc.dg/plugin/self-assign-test-1.c -fplugin=./selfassign.so  (test for
warnings, line 21)
FAIL: gcc.dg/plugin/self-assign-test-1.c -fplugin=./selfassign.so  (test for
warnings, line 22)
FAIL: gcc.dg/plugin/self-assign-test-1.c -fplugin=./selfassign.so  (test for
warnings, line 22)
FAIL: gcc.dg/plugin/self-assign-test-2.c -fplugin=./selfassign.so (test for
excess errors)
FAIL: gcc.dg/plugin/self-assign-test-2.c -fplugin=./selfassign.so (test for
excess errors)
FAIL: gcc.dg/plugin/start_unit-test-1.c -fplugin=./start_unit_plugin.so (test
for excess errors)
FAIL: gcc.dg/plugin/start_unit-test-1.c -fplugin=./start_unit_plugin.so (test
for excess errors)
FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so
(test for excess errors)
FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so
(test for excess errors)
FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so 
(test for warnings, line )
FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so 
(test for warnings, line )
FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so 
(test for warnings, line 16)
FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so 
(test for warnings, line 16)
FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so 
(test for warnings, line 7)
FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so 
(test for warnings, line 7)
FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so 
(test for warnings, line 7)
FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so 
(test for warnings, line 7)
FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so (test for
excess errors)
FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so (test for
excess errors)
FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so  (test for
warnings, line 10)
FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so  (test for
warnings, line 10)
FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so  (test for
warnings, line 14)
FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so  (test for
warnings, line 14)
FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so  (test for
warnings, line 18)
FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so  (test for
warnings, line 18)
FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so  (test for
warnings, line 19)
FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so  (test for
warnings, line 19)
FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so  (test for
warnings, line 24)
FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so  (test for
warnings, line 24)
FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so  (test for
warnings, line 50)
FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so  (test for
warnings, line 50)
FAIL: g++.dg/plugin/dumb-plugin-tes

[Bug tree-optimization/45314] [4.5 Regression] ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Known to work||4.6.0
 AssignedTo|unassigned at gcc dot   |spop at gcc dot gnu.org
   |gnu.org |
Summary|[4.5/4.6 Regression] ICE:   |[4.5 Regression] ICE:
   |error: in   |error: in
   |remove_unreachable_handlers |remove_unreachable_handlers
   |, at tree-sh.c:3294 with|, at tree-sh.c:3294 with
   |-O2 -floop-interchange  |-O2 -floop-interchange
  Known to fail|4.6.0   |

--- Comment #8 from Sebastian Pop  2010-11-05 17:16:48 
UTC ---
Mine.

[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

Summary|LTO plugin test failures|LTO plugin test failures
   |with --with-plugin-ld=ld|with
   ||--with-build-config=bootstr
   ||ap-lto --with-plugin-ld=ld

--- Comment #1 from H.J. Lu  2010-11-05 17:27:27 
UTC ---
Removing --with-build-config=bootstrap-lto seems to fix those failures.
--with-build-config=bootstrap-lto -with-plugin-ld=ld.gold works fine.
It looks like plugin support in BFD linker doesn't work with GCC plugin.

[Bug c++/46320] New: Operator[] dereference does not generate exception for empty string

[jerry at jerrycarter dot org]

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

   Summary: Operator[] dereference does not generate exception for
empty string
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: je...@jerrycarter.org


This should generate an out_of_range exception according to section 21.3.4 of
the specification
.

[Test code]

#include 
#include 
#include 
#include 

int main (int argc, const char * argv[]) {
// insert code here...
std::string x;
x[0] = 'O'; // Should get out_of_range exception here.
x[1] = 'd';
x[2] = 'd';
assert(x.length() == 0);
assert(x.c_str() == std::string("Odd"));
assert(x != std::string("Odd"));
assert(x.data()[0] == 'O');
assert(x.data()[1] == 'd');
assert(x.data()[2] == 'd');
assert(x.size() == 0);
return 0;
}

[Compiler version]

GNU gdb 6.3.50-20050815 (Apple version gdb-1472) (Wed Jul 21 10:53:12 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.

[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld

[davek at gcc dot gnu.org]

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

Dave Korn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.05 17:44:25
 AssignedTo|unassigned at gcc dot   |davek at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Dave Korn  2010-11-05 17:44:25 
UTC ---
investigating, thanks for the report

[Bug c/41206] Segmentation fault from two "#pragma GCC optimize" lines

[froydnj at gcc dot gnu.org]

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

Nathan Froyd  changed:

   What|Removed |Added

 CC||froydnj at gcc dot gnu.org

--- Comment #5 from Nathan Froyd  2010-11-05 
17:46:18 UTC ---
I no longer see this error with current mainline.

[Bug libstdc++/46320] Operator[] dereference does not generate exception for empty string

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c++ |libstdc++
 Resolution||INVALID

--- Comment #1 from Jonathan Wakely  2010-11-05 
17:46:47 UTC ---
No it shouldn't, basic_string::at throws, basic_string::operator[] doesn't

[Bug libstdc++/46320] Operator[] dereference does not generate exception for empty string

[jerry at jerrycarter dot org]

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

--- Comment #2 from Jerry Carter  2010-11-05 
17:55:25 UTC ---
Apologies.  I understood there to be a correspondence between the two (given
that basic_string::at is implemented using basic_string::operator[]) but I now
realize on second reading that the subsections (2-4) apply only to
basic_string::at.  This report has been correctly closed as invalid.  

(In reply to comment #1)
> No it shouldn't, basic_string::at throws, basic_string::operator[] doesn't

[Bug tree-optimization/45314] [4.5 Regression] ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  2010-11-05 18:04:46 
UTC ---
Just for the record, this is introduced by revision 155739:

http://gcc.gnu.org/ml/gcc-cvs/2010-01/msg00200.html

[Bug middle-end/41633] -Wframe-larger-than should warn about outgoing function calls, specifically varargs

[fche at redhat dot com]

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

Frank Ch. Eigler  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.05 18:12:22
 Ever Confirmed|0   |1

--- Comment #2 from Frank Ch. Eigler  2010-11-05 
18:12:22 UTC ---
Still present as of gcc 4.5.

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2010-11-05 18:12:25 
UTC ---
Please show command line passed to cc1.

[Bug fortran/46174] [OOP] ALLOCATE with SOURCE: Deep copy missing

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org 2010-11-05 18:15:02 UTC ---
Author: janus
Date: Fri Nov  5 18:14:52 2010
New Revision: 166368

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166368
Log:
2010-11-05  Janus Weil  

PR fortran/45451
PR fortran/46174
* class.c (gfc_find_derived_vtab): Improved search for existing vtab.
Add component '$copy' to vtype symbol for polymorphic deep copying.
* expr.c (gfc_check_pointer_assign): Make sure the vtab is generated
during resolution stage.
* resolve.c (resolve_codes): Don't resolve code if namespace is already
resolved.
* trans-stmt.c (gfc_trans_allocate): Call '$copy' procedure for
polymorphic ALLOCATE statements with SOURCE.

2010-11-05  Janus Weil  

PR fortran/45451
PR fortran/46174
* gfortran.dg/class_19.f03: Modified.
* gfortran.dg/class_allocate_6.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/class_allocate_6.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/class_19.f03

[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.

[janus at gcc dot gnu.org]

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

--- Comment #17 from janus at gcc dot gnu.org 2010-11-05 18:15:02 UTC ---
Author: janus
Date: Fri Nov  5 18:14:52 2010
New Revision: 166368

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166368
Log:
2010-11-05  Janus Weil  

PR fortran/45451
PR fortran/46174
* class.c (gfc_find_derived_vtab): Improved search for existing vtab.
Add component '$copy' to vtype symbol for polymorphic deep copying.
* expr.c (gfc_check_pointer_assign): Make sure the vtab is generated
during resolution stage.
* resolve.c (resolve_codes): Don't resolve code if namespace is already
resolved.
* trans-stmt.c (gfc_trans_allocate): Call '$copy' procedure for
polymorphic ALLOCATE statements with SOURCE.

2010-11-05  Janus Weil  

PR fortran/45451
PR fortran/46174
* gfortran.dg/class_19.f03: Modified.
* gfortran.dg/class_allocate_6.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/class_allocate_6.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/class_19.f03

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.05 18:16:45
 Ever Confirmed|0   |1

--- Comment #2 from H.J. Lu  2010-11-05 18:16:45 
UTC ---
It only happens on 32bit host. It doesn't happen with -m32
on Linux/x86-64.

Re: [Bug tree-optimization/45314] [4.5 Regression] ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange

[Sebastian Pop]

Here is the backported patch that fixes the ICE.
I will further test this and will post to gcc-patches.

Sebastian
From 8f0cc975c09d2e0779f7e25a82a295f3deb9de46 Mon Sep 17 00:00:00 2001
From: Sebastian Pop 
Date: Fri, 5 Nov 2010 13:15:25 -0500
Subject: [PATCH] Fix PR45314: backport revision 163123.

---
 gcc/graphite-sese-to-poly.c |   56 --
 1 files changed, 6 insertions(+), 50 deletions(-)

diff --git a/gcc/graphite-sese-to-poly.c b/gcc/graphite-sese-to-poly.c
index d4bb8a3..b12210b 100644
--- a/gcc/graphite-sese-to-poly.c
+++ b/gcc/graphite-sese-to-poly.c
@@ -2231,58 +2231,14 @@ rewrite_phi_out_of_ssa (gimple_stmt_iterator *psi)
   for (i = 0; i < gimple_phi_num_args (phi); i++)
 {
   tree arg = gimple_phi_arg_def (phi, i);
+  edge e = gimple_phi_arg_edge (phi, i);
 
-  /* Try to avoid the insertion on edges as much as possible: this
-	 would avoid the insertion of code on loop latch edges, making
-	 the pattern matching of the vectorizer happy, or it would
-	 avoid the insertion of useless basic blocks.  Note that it is
-	 incorrect to insert out of SSA copies close by their
-	 definition when they are more than two loop levels apart:
-	 for example, starting from a double nested loop
-
-	 | a = ...
-	 | loop_1
-	 |  loop_2
-	 |b = phi (a, c)
-	 |c = ...
-	 |  end_2
-	 | end_1
-
-	 the following transform is incorrect
-
-	 | a = ...
-	 | Red[0] = a
-	 | loop_1
-	 |  loop_2
-	 |b = Red[0]
-	 |c = ...
-	 |Red[0] = c
-	 |  end_2
-	 | end_1
-
-	 whereas inserting the copy on the incoming edge is correct
-
-	 | a = ...
-	 | loop_1
-	 |  Red[0] = a
-	 |  loop_2
-	 |b = Red[0]
-	 |c = ...
-	 |Red[0] = c
-	 |  end_2
-	 | end_1
-  */
-  if (TREE_CODE (arg) == SSA_NAME
-	  && is_gimple_reg (arg)
-	  && gimple_bb (SSA_NAME_DEF_STMT (arg))
-	  && (flow_bb_inside_loop_p (bb->loop_father,
- gimple_bb (SSA_NAME_DEF_STMT (arg)))
-	  || flow_bb_inside_loop_p (loop_outer (bb->loop_father),
-	gimple_bb (SSA_NAME_DEF_STMT (arg)
-	insert_out_of_ssa_copy (zero_dim_array, arg);
+  /* Avoid the insertion of code in the loop latch to please the
+	 pattern matching of the vectorizer.  */
+  if (e->src == bb->loop_father->latch)
+ 	insert_out_of_ssa_copy (zero_dim_array, arg);
   else
-	insert_out_of_ssa_copy_on_edge (gimple_phi_arg_edge (phi, i),
-	zero_dim_array, arg);
+	insert_out_of_ssa_copy_on_edge (e, zero_dim_array, arg);
 }
 
   var = force_gimple_operand (zero_dim_array, &stmts, true, NULL_TREE);
-- 
1.7.0.4

[Bug tree-optimization/45314] [4.5 Regression] ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange

[sebpop at gmail dot com]

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

--- Comment #10 from sebpop at gmail dot com  
2010-11-05 18:17:01 UTC ---
Here is the backported patch that fixes the ICE.
I will further test this and will post to gcc-patches.

Sebastian

[Bug fortran/46321] New: [OOP] Polymorphic deallocation

[janus at gcc dot gnu.org]

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

   Summary: [OOP] Polymorphic deallocation
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


Follow-up to PR 46174 (comment #2). Test case:


implicit none

type t
end type t

type, extends(t) :: t2
 integer, allocatable :: all(:)
end type t2

class(t), allocatable :: a

allocate(t2 :: a)
select type(a)
 type is (t2)
   allocate(a%all(100))
end select
deallocate(a)
end


The deallocation occurs according to the declared type (not the dynamic type),
i.e. the allocatable components of t2 are not being deallocated.

Solution: Add a $free component to the vtab, which points to a deallocation
procedure.

[Bug fortran/46174] [OOP] ALLOCATE with SOURCE: Deep copy missing

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from janus at gcc dot gnu.org 2010-11-05 18:39:41 UTC ---
The deep copy issue is fixed by r166368. For poylmorphic deallocation (comment
#2) I have opened PR 46321.

[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #18 from janus at gcc dot gnu.org 2010-11-05 18:41:37 UTC ---
r166368 fixes the deep copy issue and makes the original test case give the
correct output.

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  2010-11-05 
18:42:38 UTC ---
> It only happens on 32bit host. It doesn't happen with -m32
> on Linux/x86-64.

Ah, interesting, thanks.  The wrong transformation is done by VRP2 but I fail
to see which recent change has triggered this exactly.  According to our
internal daily tester, this was introduced on 11/03.

[Bug target/44754] m32c_pragma_memregs / m32c_pragma_address warnings

[amylaar at gcc dot gnu.org]

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

--- Comment #1 from Jorn Wolfgang Rennecke  
2010-11-05 18:46:29 UTC ---
Author: amylaar
Date: Fri Nov  5 18:46:22 2010
New Revision: 166370

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166370
Log:
PR target/44754
* config/m32c/m32c.c (m32_function_arg): Rename declaration to...
(m32c_function_arg).  Add comma between arguments two and three.
(m32c_promote_prototypes): Remove declaration.
(current_function_special_page_vector): Likewise.
(m32c_regno_reg_class): Change return type to enum reg_class.
(m32c_pushm_popm): Use add_reg_note.
(m32c_push_rounding): Change return type to unsigned int.
(m32c_legitimize_reload_address): Cast argument 11 to push_reload to
enum reload_type.
(m32c_insert_attributes): Constify variable name.
(m32c_output_aligned_common): Add ATTRIBUTE_UNUSED to argument decl.
(m32c_prepare_shift): Remove variable lref.
(m32c_expand_movcc): Remove variable cmp.
(m32c_expand_insv): Fix check of op0 rtx_code to use GET_CODE.
(m32c_compare_redundant): Remove variable op2.
* config/m32c/m32c-pragma.c ("c-family/c-common.h"): Include.
(m32c_pragma_memregs): Assign the number to target_memregs.
(m32c_pragma_address): Remove variable var_str.
* config/m32c/m32c.h (REG_CLASS_FROM_CONSTRAINT): Case value to
enum reg_class.
(LIMIT_RELOAD_CLASS, SECONDARY_RELOAD_CLASS): Likewise.
* config/m32c/bitops.md (andsi3): Add default case to switch.
(iorsi3, xorsi3): Likewise.
* config/m32c/addsub.md (addsi3_1, subsi3_1): Likewise.
* config/m32c/jump.md (call, call_value): Likewise.
* config/m32c/m32c-protos.h (m32c_push_rounding): Update prototype.
(m32c_regno_reg_class): Likewise.
(current_function_special_page_vector): Declare.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/m32c/addsub.md
trunk/gcc/config/m32c/bitops.md
trunk/gcc/config/m32c/jump.md
trunk/gcc/config/m32c/m32c-pragma.c
trunk/gcc/config/m32c/m32c-protos.h
trunk/gcc/config/m32c/m32c.c
trunk/gcc/config/m32c/m32c.h

[Bug target/44754] m32c_pragma_memregs / m32c_pragma_address warnings

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Jorn Wolfgang Rennecke  
2010-11-05 18:49:05 UTC ---
Patch has been applied to trunk.

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  2010-11-05 18:53:25 
UTC ---
Revision 166265 is OK.

[Bug target/45670] [4.6 Regression] Less efficient x86 addressing mode selection on 4.6, causes -Os size regression from 4.5

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2010-11-05 
19:00:32 UTC ---
Author: jakub
Date: Fri Nov  5 19:00:27 2010
New Revision: 166371

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166371
Log:
PR target/45670
* expr.c (expand_expr_real_1) : Use EXPAND_SUM
instead of EXPAND_NORMAL for base expansion.

* gcc.target/i386/pr45670.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr45670.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/46160] [4.5/4.6 Regression] ICE with volatile structure and enum

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2010-11-05 
19:02:52 UTC ---
Author: jakub
Date: Fri Nov  5 19:02:46 2010
New Revision: 166372

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166372
Log:
PR c++/46160
* cp-gimplify.c (cp_gimplify_expr): Drop volatile MEM_REFs
on the RHS to avoid infinite recursion with gimplify_expr.

* g++.dg/opt/empty2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/empty2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug target/45670] [4.6 Regression] Less efficient x86 addressing mode selection on 4.6, causes -Os size regression from 4.5

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2010-11-05 
19:10:57 UTC ---
Fixed.

[Bug c++/46160] [4.5 Regression] ICE with volatile structure and enum

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.5/4.6 Regression] ICE|[4.5 Regression] ICE with
   |with volatile structure and |volatile structure and enum
   |enum|

--- Comment #4 from Jakub Jelinek  2010-11-05 
19:11:44 UTC ---
Fixed on the trunk so far.

[Bug debug/46322] New: ICE: RTL check: expected code 'const_int', have 'reg' in dbxout_parms, at dbxout.c:3498 with -gstabs

[zsojka at seznam dot cz]

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

   Summary: ICE: RTL check: expected code 'const_int', have 'reg'
in dbxout_parms, at dbxout.c:3498 with -gstabs
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


- testcase.c -
void foo (int i)
{
char c[0x1UL];
}
--

Compiler output:
$ gcc -gstabs testcase.c
testcase.c: In function 'foo':
testcase.c:4:1: internal compiler error: RTL check: expected code 'const_int',
have 'reg' in dbxout_parms, at dbxout.c:3498
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions (all with RTL checking):
r166306 - crash
4.5 r165781 - crash
4.4 r165754 - crash

[Bug target/46280] [4.6 regression] Several testcases FAIL with 16byte alignment ABI warning on Solaris 8/9 x86

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2010-11/msg00572.htm
   ||l

--- Comment #4 from Rainer Orth  2010-11-05 19:50:57 UTC 
---
Mine, initial patch submitted.

[Bug tree-optimization/46316] [4.6 regression] incorrect loop optimization

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||davidxl at gcc dot gnu.org

--- Comment #5 from H.J. Lu  2010-11-05 20:29:46 
UTC ---
It is very likely caused by revision 166280:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00166.html

[Bug fortran/46321] [OOP] Polymorphic deallocation

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.05 21:02:47
 CC||burnus at gcc dot gnu.org
 Ever Confirmed|0   |1

[Bug java/46324] New: gcj should support the javac flags such as -verbose, -sourcepath and -source

[tnagy1024 at gmail dot com]

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

   Summary: gcj should support the javac flags such as -verbose,
-sourcepath and -source
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tnagy1...@gmail.com


The gcj -C command should support the same options:

gcj: unrecognized option '-verbose'
gcj: unrecognized option '-source'
gcj: unrecognized option '-sourcepath'

The -verbose flag is really useful to list the files that have just been
created.

[Bug fortran/45636] Failed to fold simple Fortran string

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #13 from Steve Ellcey  2010-11-05 21:12:19 
UTC ---
I have moved gcc.c-torture/execute/pr45636.c to gcc.dg/torture/pr45636.c
and added a check for the mempcpy function so this should not fail on HP-UX or
Solaris which don't have a mempcpy function.

The change was r166378 and if the test failures are the only reason to keep
this bug report open then it we should be able to close it now.

[Bug target/45585] [4.6 Regression] ICE on powerpc-apple-darwin9 for gfortran.dg/transfer_simplify_2.f90 with -O2 -m64

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |meissner at gcc dot gnu.org
   |gnu.org |

--- Comment #5 from Michael Meissner  2010-11-05 
21:28:55 UTC ---
Created attachment 22297
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22297
Patch to allow loading/storing DI values in FPR registers

This patch fixes the problem in the bug.  What is happening is originally if
you were loading up a static 64-bit integer variable to convert it to floating
point, the compiler would first load the variable into a GPR, then store it on
the stack, and then load the value from the stack to the FPR.  My optimization
allowed the fp convert to take memory operands so it didn't have to go through
the GPR registers.  However, since Darwin has its own patterns for load/store,
it didn't go through the normal move patterns, and was overlooked.

[Bug target/45585] [4.6 Regression] ICE on powerpc-apple-darwin9 for gfortran.dg/transfer_simplify_2.f90 with -O2 -m64

[meissner at gcc dot gnu.org]

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

--- Comment #6 from Michael Meissner  2010-11-05 
21:31:42 UTC ---
Author: meissner
Date: Fri Nov  5 21:31:38 2010
New Revision: 166379

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166379
Log:
Fix PR 45585, darwin brain damage

Modified:
branches/ibm/power7-fpconv/gcc/ChangeLog.power7
branches/ibm/power7-fpconv/gcc/config/rs6000/darwin.md

[Bug tree-optimization/46177] [4.5 Regression] ICE: in prop_phis, at tree-loop-distribution.c:327 with -fno-tree-copy-prop -ftree-loop-distribution

[zsojka at seznam dot cz]

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

--- Comment #6 from Zdenek Sojka  2010-11-05 21:37:28 
UTC ---
Created attachment 22298
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22298
another testcase

Thank you for having a look at this issue! The original testcase
testsuite/gcc.dg/tree-ssa/pr38385.c is still failing, attached is another
testcase that fails in r166306. Should I open separate PR for this? Thanks!

$ gcc -O -fno-tree-copy-prop -ftree-loop-distribution pr46177-2.c
pr46177-2.c: In function 'foo':
pr46177-2.c:4:1: internal compiler error: in prop_phis, at
tree-loop-distribution.c:331
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/46036] [4.6 Regression] verify_ssa failed: definition in block 3 follows the use

[spop at gcc dot gnu.org]

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

--- Comment #3 from Sebastian Pop  2010-11-05 22:01:34 
UTC ---
Created attachment 22299
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22299
patch

Here is a patch that solves the problem.
Not tested yet.

[Bug tree-optimization/46177] [4.5 Regression] ICE: in prop_phis, at tree-loop-distribution.c:327 with -fno-tree-copy-prop -ftree-loop-distribution

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  
2010-11-05 22:38:18 UTC ---
On Fri, 5 Nov 2010, zsojka at seznam dot cz wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46177
> 
> --- Comment #6 from Zdenek Sojka  2010-11-05 
> 21:37:28 UTC ---
> Created attachment 22298
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22298
> another testcase
> 
> Thank you for having a look at this issue! The original testcase
> testsuite/gcc.dg/tree-ssa/pr38385.c is still failing, attached is another
> testcase that fails in r166306. Should I open separate PR for this? Thanks!

No, it's probably still the same bug, just re-open this PR.

[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld

[davek at gcc dot gnu.org]

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

--- Comment #3 from Dave Korn  2010-11-05 22:59:04 
UTC ---
When I tried running these tests in a pre-existing build tree,
plugin_default_version_check failed because the datestamps don't match up:

(gdb) p gcc_version[0]
$5 = {basever = 0x1029fe8 "4.6.0", datestamp = 0x1029fee "20101103",
  devphase = 0x1029ff7 "experimental", revision = 0x1143f30 "",
  configuration_arguments = 0xd2d2c0 "/n/10/davek/gcc/gcc/configure
--prefix=/n/
10/davek/gcc --with-mpfr=/opt/cfarm/mpfr-2.4.1 --with-gmp=/opt/cfarm/gmp-4.2.4
-
-with-mpc=/opt/cfarm/mpc-0.8 --with-libelf=/n/10/davek/usr --enable-bootstrap
".
..}
(gdb) p plugin_version[0]
$6 = {basever = 0x77567d29 "4.6.0",
  datestamp = 0x77567d2f "20101105",
  devphase = 0x77567d38 "experimental", revision = 0x77567e28 "",
  configuration_arguments = 0x77566720 "/n/10/davek/gcc/gcc/configure
--pref
ix=/n/10/davek/gcc --with-mpfr=/opt/cfarm/mpfr-2.4.1
--with-gmp=/opt/cfarm/gmp-4
.2.4 --with-mpc=/opt/cfarm/mpc-0.8 --with-libelf=/n/10/davek/usr
--enable-bootst
rap "...}
(gdb)

This will happen if $objdir/gcc/plugin-version.h or $objdir/gcc/configargs.h
has been regenerated for any reason in between building the compiler and
running the test.  Can you tell if this may have happened in your case?

[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  2010-11-05 23:27:51 
UTC ---
-fwhopr=jobserver -fuse-linker-plugin -frandom-seed=1 miscompiled
selfassign.so. It generated:

[...@gnu-32 stage1-gcc]$ nm selfassign.so | grep plugin_init
09aa T plugin_init
[...@gnu-32 stage1-gcc]$ 

9aa :
 9aa:   90  nop 
 9ab:   90  nop 
 9ac:   90  nop 
 9ad:   90  nop 
 9ae:   90  nop 
 9af:   90  nop 

Everything seems wrong. With gold as plugin linker, I got

[...@scel-amdbar2 gcc]$ nm selfassign.so | grep plugin_init
20ac T plugin_init
[...@scel-amdbar2 gcc]$ 

20ac :
20ac:   41 57   push   %r15
20ae:   41 56   push   %r14
20b0:   41 55   push   %r13
20b2:   41 54   push   %r12
20b4:   55  push   %rbp
20b5:   53  push   %rbx
20b6:   48 83 ec 38 sub$0x38,%rsp
20ba:   48 89 f0mov%rsi,%rax
20bd:   4c 8b 2fmov(%rdi),%r13
20c0:   44 8b 67 10 mov0x10(%rdi),%r12d
20c4:   48 8b 6f 18 mov0x18(%rdi),%rbp
20c8:   48 8d 35 11 1c 00 00lea0x1c11(%rip),%rsi# 3ce0

[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  2010-11-05 23:30:36 
UTC ---
Created attachment 22300
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22300
selfassign.so generated by bfd linker

[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  2010-11-05 23:31:23 
UTC ---
Created attachment 22301
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22301
selfassign.so generated by gold

[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld

[davek at gcc dot gnu.org]

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

--- Comment #7 from Dave Korn  2010-11-05 23:33:29 
UTC ---
(In reply to comment #4)

> Everything seems wrong. 

  Yes, you aren't exaggerating!  I am continuing to try and figure out what's
going wrong.

[Bug target/46084] gcc.dg/split-4.c failed with -mavx -m32

[ian at gcc dot gnu.org]

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

--- Comment #2 from ian at gcc dot gnu.org  2010-11-05 
23:45:38 UTC ---
Author: ian
Date: Fri Nov  5 23:45:32 2010
New Revision: 166383

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166383
Log:
gcc/:
PR target/46084
* explow.c (allocate_dynamic_stack_space): If flag_split_stack,
request enough additional space for alignment, and force
alignment.
testsuite/:
* gcc.target/i386/pr46084.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr46084.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/explow.c
trunk/gcc/testsuite/ChangeLog

[Bug target/46084] gcc.dg/split-4.c failed with -mavx -m32

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ian at airs dot com
 Resolution||FIXED

--- Comment #3 from Ian Lance Taylor  2010-11-05 23:49:16 
UTC ---
Fixed.  Thanks for reporting the bug.

[Bug middle-end/46325] New: [4.6 Regression] gfortran.dg/char_initialiser_actual.f90 FAILs with -fstack-protector

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression]
gfortran.dg/char_initialiser_actual.f90 FAILs with
-fstack-protector
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Output:
$ gfortran char_initialiser_actual.f90 -fstack-protector
$ ./a.out 
Aborted

Tested revisions:
r166306 - fail
r165699 - fail
r163636 - OK
4.5 r165781 - OK