[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2

[anitha.boyapati at atmel dot com]

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

--- Comment #28 from Anitha Boyapati  
2011-06-16 06:35:41 UTC ---

(In reply to comment #24)
> The testcase at the head of the PR is now fixed.

I could build avr-gcc from trunk and run couple of simple testcases.

[anitha@turing objdir]$ avr-gcc -v
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/home/anitha/install/libexec/gcc/avr/4.7.0/lto-wrapper
Target: avr
Configured with: ../configure --target=avr --prefix=/home/anitha/install/
--with-dwarf2 --enable-languages=c --disable-libssp --disable-nls
--with-gmp=/proj/install/gmp-4.3.2/ --with-mpc=/proj/install/mpc-0.8.2/
--with-mpfr=/proj/install/mpfr-2.4.2/ CFLAGS=-g
Thread model: single
gcc version 4.7.0 20110615 (experimental) (GCC) 


> 
> For the 4.6 branch, this required also backporting

Any idea if build succeeded for 4.6 branch? I tried and it failed. (branch:
gcc-4_6-branch)


../../../../libgcc/../gcc/libgcc2.c: In function '__lshrdi3':
../../../../libgcc/../gcc/libgcc2.c:427:1: internal compiler error: in
dwarf2out_frame_debug_expr, at dwarf2out.c:2671
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [_lshrdi3.o] Error 1
make[4]: Leaving directory
`/home/anitha/gcc-4.6-branch/objdir/avr/avr25/libgcc'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory `/home/anitha/gcc-4.6-branch/objdir/avr/libgcc'

[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2

[anitha.boyapati at atmel dot com]

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

--- Comment #27 from Anitha Boyapati  
2011-06-16 06:34:57 UTC ---

(In reply to comment #24)
> The testcase at the head of the PR is now fixed.

I could build avr-gcc from trunk and run couple of simple testcases.

[anitha@turing objdir]$ avr-gcc -v
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/home/anitha/install/libexec/gcc/avr/4.7.0/lto-wrapper
Target: avr
Configured with: ../configure --target=avr --prefix=/home/anitha/install/
--with-dwarf2 --enable-languages=c --disable-libssp --disable-nls
--with-gmp=/proj/install/gmp-4.3.2/ --with-mpc=/proj/install/mpc-0.8.2/
--with-mpfr=/proj/install/mpfr-2.4.2/ CFLAGS=-g
Thread model: single
gcc version 4.7.0 20110615 (experimental) (GCC) 


> 
> For the 4.6 branch, this required also backporting

Any idea if the build succeeded for 4.6 branch? I tried and it failed. (branch:
gcc-4_6-branch)


../../../../libgcc/../gcc/libgcc2.c: In function '__lshrdi3':
../../../../libgcc/../gcc/libgcc2.c:427:1: internal compiler error: in
dwarf2out_frame_debug_expr, at dwarf2out.c:2671
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [_lshrdi3.o] Error 1
make[4]: Leaving directory
`/home/anitha/gcc-4.6-branch/objdir/avr/avr25/libgcc'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory `/home/anitha/gcc-4.6-branch/objdir/avr/libgcc'

[Bug fortran/49431] is it illegal?

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from kargl at gcc dot gnu.org 2011-06-16 05:58:12 UTC ---
See comment #2.

[Bug rtl-optimization/44194] struct returned by value generates useless stores

[ebotcazou at gcc dot gnu.org]

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

--- Comment #24 from Eric Botcazou  2011-06-16 
05:26:56 UTC ---
> It would be nice if the expander does not spill the return into memory in the
> first place if possible.  On other hand tagging compiler created memory
> location with temp decls so that aliaser has the symbolic information seems a
> useful mechanism. 

But a poor kludge if you can avoid spilling to memory in the first place.

[Bug fortran/49431] is it illegal?

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #1 from Jerry DeLisle  2011-06-16 
05:18:35 UTC ---
Using a double colon allows it to compile:

program main
  implicit none
  real distance
  real, external :: gcdist
  distance = gcdist ()
end program main

!  Computes the shortest (undirected) angular distance between the points
!  on the globe (LAT1,LON1) and (LAT2,LON2).
real function GCDIST()
   implicit none
   real :: D2R = 0.017453292519943  ! <--- here
   gcdist = D2R
end

[Bug fortran/49431] New: is it illegal?

[linuxl4 at sohu dot com]

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

   Summary: is it illegal?
   Product: gcc
   Version: 4.4.7
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: linu...@sohu.com


program main
  implicit none
  real distance
  real, external :: gcdist
  distance = gcdist ()
end program main

!  Computes the shortest (undirected) angular distance between the points
!  on the globe (LAT1,LON1) and (LAT2,LON2).
real function GCDIST()
   implicit none
   real D2R = 0.017453292519943
   gcdist = D2R
end

[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*

[mrs at gcc dot gnu.org]

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

m...@gcc.gnu.org  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org

--- Comment #31 from mrs at gcc dot gnu.org  2011-06-16 
02:28:54 UTC ---
I've checked in the config/mh-darwin change to always turn of -pie.  This is
orthogonal to all the other changes.  This is necessary for example for a
darwin hosted linux targeted cross compiler.

[Bug target/49335] [4.6/4.7 Regression] ARM: Invalid assembler generated while compiling C++ code from 'codeblocks'

[michael.hope at linaro dot org]

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

--- Comment #4 from Michael Hope  2011-06-16 
01:31:43 UTC ---
Also affects gimp.  See LP: #791279.

Doesn't appear in trunk r172224 but does in r174795.

[Bug rtl-optimization/49429] dse.c changes to fix PR44194 (r175063) cause execution failures

[eraman at google dot com]

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

--- Comment #7 from Easwaran Raman  2011-06-16 
00:05:51 UTC ---
>From the dump after the dse.c changes, I see the following for the function
test2_31:


starting to process insn 90
  v:  1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40,
41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60,
61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80,
81, 82, 83, 84, 85, 86, 87, 88
non-frame wild read
starting to process insn 89
  v:  25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42,
43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62,
63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82,
83, 84, 85, 86, 87, 88

Insn 90 is a call to check31. This is supposed to kill all locations that
escape from the caller, but from the dump it looks like it has only killed some
of them.

[Bug fortran/49430] ICE with allocatable length character in interface block

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||burnus at gcc dot gnu.org
 Blocks||45170

--- Comment #1 from Tobias Burnus  2011-06-15 
23:43:42 UTC ---
I get:

test.f90:19:0: internal compiler error: tree check: expected tree that contains
'typed' structure, have '�' in fold_convert_loc, at fold-const.c:1859

==14082== Invalid read of size 1
==14082==at 0x72F9B2: fold_convert_loc (fold-const.c:1859)
==14082==by 0xA7D3F6: build_range_type_1 (tree.c:7170)
==14082==by 0x5C8C69: gfc_get_character_type_len_for_eltype
(trans-types.c:977)
==14082==by 0x59EA63: gfc_conv_procedure_call (trans-expr.c:3538)
==14082==by 0x59F271: gfc_conv_function_expr (trans-expr.c:4082)
==14082==by 0x597D01: gfc_trans_assignment_1 (trans-expr.c:6112)

In trans-expr.c:3538:
(gdb) p *ts.u.cl
$2 = {length = 0x0, next = 0x0, length_from_typespec = 215 '\327',
  backend_decl = 0x1535340, passed_length = 0x2cdd7f00,
  resolved = 6764539}

I wonder whether the
3538  type = gfc_get_character_type (ts.kind, ts.u.cl);
should be rather:
   type = gfc_get_character_type (ts.kind, ts->deferred ? NULL_TREE : ts.u.cl);

[Bug rtl-optimization/44194] struct returned by value generates useless stores

[xinliangli at gmail dot com]

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

davidxl  changed:

   What|Removed |Added

 CC||xinliangli at gmail dot com

--- Comment #23 from davidxl  2011-06-15 23:14:50 
UTC ---
(In reply to comment #22)
> > The DSE patch still leaves 2 redundant stores.
> 
> OK, I missed this, reopening...
> 
> > The following patch will enable DSE to remove those two stores. Does this
> > look ok?
> 
> Calling into the gimplifier from the RTL expander doesn't look appropriate.
> 
> More fundamentally, it's a little unfortunate to spill to memory a value
> returned in registers.  Can we try to use emit_group_move_into_temps here
> instead (under the appropriate circumstances)?

It would be nice if the expander does not spill the return into memory in the
first place if possible.  On other hand tagging compiler created memory
location with temp decls so that aliaser has the symbolic information seems a
useful mechanism. 

Easwaran, can you post the patch to gcc-patches for more comments?

Thanks,

David

[Bug rtl-optimization/49429] dse.c changes to fix PR44194 (r175063) cause execution failures

[hp at gcc dot gnu.org]

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

--- Comment #6 from Hans-Peter Nilsson  2011-06-15 
23:14:36 UTC ---
(In reply to comment #5)
> The full set of regressions for cris-elf
> (last_worked:start_fail 175051:175064) are:
> 
> g++.sum g++.dg/torture/pr43879-1_1.C

Oops ignore that line; that regression belongs to PR49373.

[Bug fortran/49430] New: ICE with allocatable length character in interface block

[shadowblade at altern dot org]

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

   Summary: ICE with allocatable length character in interface
block
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: shadowbl...@altern.org


The following code:

module mod_test3
abstract interface
function messageProcedure(code) result(message)
integer, intent(in) :: code
character(:), allocatable :: message
end function
end interface

type, public :: ctype
procedure(messageProcedure), pointer, nopass :: getMessage => null()
end type

contains
subroutine asub(this, num)
class(ctype), intent(in) :: this
integer, intent(in) :: num
character(:), allocatable :: message

if(associated(this%getMessage)) message = this%getMessage(num)
end subroutine
end module


causes this:
‘
In function ‘asub’:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


gfortran version:
Using built-in specs.
COLLECT_GCC=gfortran47
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin10.6.0/4.7.0/lto-wrapper
Target: x86_64-apple-darwin10.6.0
Configured with: ../gcc-4.7-20110611/configure --program-suffix=47
--prefix=/usr/local/ : (reconfigured) ../gcc-4.7-20110611/configure
--program-suffix=47 --prefix=/usr/local/ --enable-lto
--enable-languages=c,c++,objc,obj-c++,fortran
Thread model: posix
gcc version 4.7.0 20110611 (experimental) (GCC)

[Bug rtl-optimization/49429] dse.c changes to fix PR44194 (r175063) cause execution failures

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #5 from Hans-Peter Nilsson  2011-06-15 
23:10:36 UTC ---
I see this for cris-elf too. The full set of regressions for cris-elf
(last_worked:start_fail 175051:175064) are:

g++.sum g++.dg/torture/pr43879-1_1.C
gcc.sum gcc.c-torture/execute/2412-3.c
gcc.sum gcc.c-torture/execute/20030914-1.c
gfortran.sum gfortran.dg/dependency_25.f90
gfortran.sum gfortran.dg/der_array_1.f90
gfortran.sum gfortran.dg/extends_3.f03
gfortran.sum gfortran.dg/structure_constructor_1.f03

As in:
Running
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/execute.exp ...
FAIL: gcc.c-torture/execute/2412-3.c execution,  -O1
FAIL: gcc.c-torture/execute/20030914-1.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/20030914-1.c execution,  -O3 -fomit-frame-pointer
-funroll-loops
FAIL: gcc.c-torture/execute/20030914-1.c execution,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions
FAIL: gcc.c-torture/execute/20030914-1.c execution,  -O3 -g
...
Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/g++.dg/torture/dg-torture.exp
...
FAIL: g++.dg/torture/pr43879-1_1.C  -O1  execution test
FAIL: g++.dg/torture/pr43879-1_1.C  -O2  execution test
FAIL: g++.dg/torture/pr43879-1_1.C  -O3 -fomit-frame-pointer  execution test
FAIL: g++.dg/torture/pr43879-1_1.C  -O3 -g  execution test
FAIL: g++.dg/torture/pr43879-1_1.C  -Os  execution test
...
Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
...
FAIL: gfortran.dg/dependency_25.f90  -O1  execution test
FAIL: gfortran.dg/dependency_25.f90  -O2  execution test
FAIL: gfortran.dg/dependency_25.f90  -Os  execution test

FAIL: gfortran.dg/der_array_1.f90  -O1  execution test
FAIL: gfortran.dg/der_array_1.f90  -O2  execution test
FAIL: gfortran.dg/der_array_1.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/der_array_1.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/der_array_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/der_array_1.f90  -O3 -g  execution test
FAIL: gfortran.dg/der_array_1.f90  -Os  execution test
FAIL: gfortran.dg/extends_3.f03  -O1  execution test
...
FAIL: gfortran.dg/structure_constructor_1.f03  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test

Messages in gcc.log and g++.log say the same thing (call to abort):
PASS: gcc.c-torture/execute/2412-3.c compilation,  -O1 
program stopped with signal 6.
FAIL: gcc.c-torture/execute/2412-3.c execution,  -O1 

And similarly in gfortran.log:
PASS: gfortran.dg/dependency_25.f90  -O1  (test for excess errors)

Backtrace not yet available on this platform, sorry!
program stopped with signal 6.
FAIL: gfortran.dg/dependency_25.f90  -O1  execution test

[Bug target/49427] v850e-elf wants 850e/v850e-common.c

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  2011-06-15 22:52:07 UTC ---
It appears the v850 targets duplicate a lot of standard settings

tm_p_file=v850/v850-protos.h
tmake_file=v850/t-v850
md_file=v850/v850.md
extra_modes=v850/v850-modes.def
out_file=v850/v850.c
extra_options="v850/v850.opt"

all of which could be avoided by setting cpu_type (which would also fix 
this issue).  In general targets setting out_file directly like that are 
suspect and indicate a missing case in the code setting cpu_type.

[Bug rtl-optimization/49429] dse.c changes to fix PR44194 (r175063) cause execution failures

[sje at cup dot hp.com]

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

--- Comment #4 from Steve Ellcey  2011-06-15 22:39:26 
UTC ---
Created attachment 24542
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24542
dse dump of x.c after change was made

[Bug rtl-optimization/49429] dse.c changes to fix PR44194 (r175063) cause execution failures

[sje at cup dot hp.com]

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

--- Comment #3 from Steve Ellcey  2011-06-15 22:38:15 
UTC ---
Created attachment 24541
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24541
dse dump of x.c before change was made

[Bug rtl-optimization/49429] dse.c changes to fix PR44194 (r175063) cause execution failures

[sje at cup dot hp.com]

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

--- Comment #2 from Steve Ellcey  2011-06-15 22:37:24 
UTC ---
Created attachment 24540
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24540
Cut down version of gcc.dg/struct-by-value-1.c

This is a cutdown version of gcc.dg/struct-by-value-1.c that executes correctly
when compiled with -O2 before r175063 but calls abort after the change.

[Bug rtl-optimization/49429] dse.c changes to fix PR44194 (r175063) cause execution failures

[eraman at google dot com]

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

--- Comment #1 from Easwaran Raman  2011-06-15 
22:22:05 UTC ---
 Can you please attach the dse1 dump with and without my patch so that I can
look into it? I will also try to build a IA64 cross compiler and see if I can
spot what's happening, but I don't have access to a ia64 to run the tests.

[Bug rtl-optimization/49429] New: dse.c changes to fix PR44194 (r175063) cause execution failures

[sje at cup dot hp.com]

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

   Summary: dse.c changes to fix PR44194 (r175063) cause execution
failures
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com
CC: era...@google.com
Depends on: 44194
Target: ia64-hp-hpux11* powerpc-apple-darwin9.8.0


The fix for PR 44194, version r175063, causes failures on ia64-hp-hpux11.23 and
powerpc-apple-darwin9.8.0.



gcc.dg/struct-by-value-1.c fails on HP-UX with -O2 optimization.  This was the
test I used on HP-UX to track down the specific version that caused the
failure.

These fortran tests fail on both platforms and I think are caused by the 
same checkin:


FAIL: gfortran.dg/dependency_25.f90  -O1  execution test
FAIL: gfortran.dg/dependency_25.f90  -O2  execution test
FAIL: gfortran.dg/dependency_25.f90  -Os  execution test
FAIL: gfortran.dg/der_array_1.f90  -O1  execution test
FAIL: gfortran.dg/der_array_1.f90  -O2  execution test
FAIL: gfortran.dg/der_array_1.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/der_array_1.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/der_array_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/der_array_1.f90  -O3 -g  execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O1  execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O2  execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O3 -fomit-frame-pointer 
execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O3 -g  execution test

[Bug rtl-optimization/49414] gcc.dg/pr44194-1.c fails

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #8 from Eric Botcazou  2011-06-15 
21:42:16 UTC ---
Yes, please open a PR for the new execution failures and make it depend on the
original PR rtl-optimization/44194.  This one is fixed.

[Bug rtl-optimization/49414] gcc.dg/pr44194-1.c fails

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #7 from Steve Ellcey  2011-06-15 21:23:51 
UTC ---
I am also seeing some new failures on IA64 HP-UX (maybe Linux too, I am not
sure because my Linux run had other problems).  I see the same Fortran failures
that Dominique sees.

I also get a failure with gcc.dg/struct-by-value-1.c and I definitively tracked
that failure down to r175063.  I haven't verified that the Fortran failures
started with this exact version.

Should these bugs (mine and Dominiques) be a separate bug report?  They look
different then the IA32 failure.

[Bug rtl-optimization/44194] struct returned by value generates useless stores

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #22 from Eric Botcazou  2011-06-15 
21:09:18 UTC ---
> The DSE patch still leaves 2 redundant stores.

OK, I missed this, reopening...

> The following patch will enable DSE to remove those two stores. Does this
> look ok?

Calling into the gimplifier from the RTL expander doesn't look appropriate.

More fundamentally, it's a little unfortunate to spill to memory a value
returned in registers.  Can we try to use emit_group_move_into_temps here
instead (under the appropriate circumstances)?

[Bug c/49428] New: Wrong FP calculation that yields 0.0.

[ecologicyborg at gmail dot com]

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

   Summary: Wrong FP calculation that yields 0.0.
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ecologicyb...@gmail.com


Created attachment 24539
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24539
for reproducing the bug.

There's a bug that it sometimes returns 0. instead of 0.6000 ns
when the cpu freq. is definitively around 1. GHz

gcc test.c ; ./a.out [ gcc (Debian 4.5.2-8) 4.5.2 ]

double nanoseconds_by_cpu_cycle(uint64_t frequency) {
   double ns;
   ns = 10.0L / ((double)frequency);
   return(ns);
}

Here the objdump.

08048547 :
 8048547:   55  push   %ebp
 8048548:   89 e5   mov%esp,%ebp
 804854a:   83 ec 20sub$0x20,%esp
 804854d:   8b 45 08mov0x8(%ebp),%eax
 8048550:   89 45 e8mov%eax,-0x18(%ebp)
 8048553:   8b 45 0cmov0xc(%ebp),%eax
 8048556:   89 45 ecmov%eax,-0x14(%ebp)
 8048559:   df 6d e8fildll -0x18(%ebp)
 804855c:   83 7d ec 00 cmpl   $0x0,-0x14(%ebp)
 8048560:   79 08   jns804856a

 8048562:   db 2d 50 88 04 08   fldt   0x8048850
 8048568:   de c1   faddp  %st,%st(1)
 804856a:   dd 5d e0fstpl  -0x20(%ebp)
 804856d:   dd 45 e0fldl   -0x20(%ebp)
 8048570:   db 2d 60 88 04 08   fldt   0x8048860
 8048576:   de f1   fdivp  %st,%st(1)
 8048578:   dd 5d f8fstpl  -0x8(%ebp)
 804857b:   dd 45 f8fldl   -0x8(%ebp)
 804857e:   c9  leave
 804857f:   c3  ret

I see that FP generation code is buggy, i don't see why there's a
conditional branch jns although there's a risk of division by
zero that never happened.

10.0L / ((double)156800LL aprox.) did give me 0.0 wrongly.

Could be a side-effect of NaN, +Infty or -Infty?

[Bug target/49427] New: v850e-elf wants 850e/v850e-common.c

[amylaar at gcc dot gnu.org]

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

   Summary: v850e-elf wants 850e/v850e-common.c
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
CC: ni...@redhat.com
Blocks: 47093
Target: v850e-elf


The build fails with:

make[2]: *** No rule to make target
`../../../gcc/gcc/common/config/v850e/v850e-common.c', needed by
`v850e-common.o'.  Stop.

[Bug rtl-optimization/44194] struct returned by value generates useless stores

[eraman at google dot com]

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

--- Comment #21 from Easwaran Raman  2011-06-15 
20:34:32 UTC ---
The DSE patch still leaves 2 redundant stores. The following patch will enable
DSE to remove those two stores. Does this look ok?



Index: gcc/testsuite/gcc.dg/pr44194-1.c
===
--- gcc/testsuite/gcc.dg/pr44194-1.c(revision 175082)
+++ gcc/testsuite/gcc.dg/pr44194-1.c(working copy)
@@ -13,5 +13,5 @@ void func() {
   struct ints s = foo();
   bar(s.a, s.b);
 }
-/* { dg-final { scan-rtl-dump "global deletions = 2"  "dse1" } } */
+/* { dg-final { scan-rtl-dump "global deletions = 4"  "dse1" } } */
 /* { dg-final { cleanup-rtl-dump "dse1" } } */
Index: gcc/calls.c
===
--- gcc/calls.c(revision 175081)
+++ gcc/calls.c(working copy)
@@ -3005,8 +3005,9 @@ expand_call (tree exp, rtx target, int ignore)
   tree nt = build_qualified_type (rettype,
   (TYPE_QUALS (rettype)
| TYPE_QUAL_CONST));
-
+  tree target_expr = create_tmp_reg (rettype, NULL);
   target = assign_temp (nt, 0, 1, 1);
+  set_mem_expr (target, target_expr);
 }

   if (! rtx_equal_p (target, valreg))

[Bug c++/43912] [C++0x] lambda debug info does not describe captured variables

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/49225] [C++0x] Weird SFINAE behavior with variadic templates

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2011-06-15 
19:20:34 UTC ---
I see. Thus for the time being I'm probably going to use something like the
workaround suggested by Daniel in private email.

[Bug c/43772] Errant -Wlogical-op warning when testing limits

[eggert at gnu dot org]

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

eggert at gnu dot org changed:

   What|Removed |Added

 CC||eggert at gnu dot org

--- Comment #7 from eggert at gnu dot org 2011-06-15 19:18:57 UTC ---
I get the same bug with GCC 4.6.0 (x86-64).  Here's a test case:

long long
emacs_lseek (int fd, long long offset, int whence)
{
  return -1-9223372036854775807LL <= offset && offset <= 9223372036854775807LL;
}

This is abstracted from real EMACS source code: the real code is verifying
that an EMACS_INT value fits within off_t.  Both types happen to be
'long long' here, but they might not be the same types on other platforms.

When compiled with "gcc -S -Wlogical-op t.c", I get:

t.c: In function 'emacs_lseek':
t.c:5:3: warning: logical 'and' of mutually exclusive tests is always false
[-Wlogical-op]

which is obviously bogus.

Using "&" rather than "&&" works around the bug, but that's not a
satisfactory solution in general.

[Bug c++/45399] [C++0x] Warning for \0 in raw strings

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #9 from Manuel López-Ibáñez  2011-06-15 
18:40:40 UTC ---
(In reply to comment #8)
> No objection I think.  Alternatively there could be a switch to control this
> warning.

Or both. I wish clang published a list of their warning options, so we can keep
compatibility. 

According to this:

https://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticKinds.def?revision=39294&view=markup&sortby=rev&pathrev=63060

They have three different warnings for this but I am not sure if the options
are called -Wnull-in-char, -Wnull-in-string, and -Wnull-in-file.

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

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/45378] [C++0x] Narrowing error not detected

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/45399] [C++0x] Warning for \0 in raw strings

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c/49426] unwarranted warning from -Wsign-compare

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #1 from Manuel López-Ibáñez  2011-06-15 
18:15:44 UTC ---
See duplicate for long explanation of why this won't be fixed soon.

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

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||jim at meyering dot net

--- Comment #9 from Manuel López-Ibáñez  2011-06-15 
18:15:44 UTC ---
*** Bug 49426 has been marked as a duplicate of this bug. ***

[Bug c++/49339] [C++0x][lambda][unused-parameter]g++ reports unused parameter even it's referenced in function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Jason Merrill  2011-06-15 
18:06:43 UTC ---
This will be fixed by my patch for 49251.

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

[Bug c++/49251] [C++0x][parameter pack expanding] unused parameter warning with unpacking empty tuples

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||lene13 at gmail dot com

--- Comment #1 from Jason Merrill  2011-06-15 
18:06:43 UTC ---
*** Bug 49339 has been marked as a duplicate of this bug. ***

[Bug c++/49225] [C++0x] Weird SFINAE behavior with variadic templates

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  2011-06-15 
18:01:56 UTC ---
Yeah, this is a tricky one.

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

[Bug c++/48322] [C++0x] Plural variadic parameter packs are not expanded well

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  2011-06-15 
18:01:56 UTC ---
*** Bug 49225 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/49414] gcc.dg/pr44194-1.c fails

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  2011-06-15 
17:57:06 UTC ---
For the record, it also fails on powerpc-apple-darwin9.8.0 (see
http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg01771.html ). Could it also be
the cause of new failures in gfortran

FAIL: gfortran.dg/dependency_25.f90  -O1  execution test
FAIL: gfortran.dg/dependency_25.f90  -O2  execution test
FAIL: gfortran.dg/dependency_25.f90  -Os  execution test
FAIL: gfortran.dg/der_array_1.f90  -O1  execution test
FAIL: gfortran.dg/der_array_1.f90  -O2  execution test
FAIL: gfortran.dg/der_array_1.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/der_array_1.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/der_array_1.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/der_array_1.f90  -O3 -g  execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O1  execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O2  execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O3 -fomit-frame-pointer 
execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/structure_constructor_1.f03  -O3 -g  execution test

?

[Bug lto/49302] [4.7 Regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #13 from William J. Schmidt  
2011-06-15 17:45:05 UTC ---
Fixed.

[Bug lto/49302] [4.7 Regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||meissner at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |wschmidt at gcc dot gnu.org
   |gnu.org |

[Bug c++/49229] [C++0x][SFINAE] ICE with variadics and depending non-type default parameter

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.15 17:39:59
 CC||jason at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug c++/49251] [C++0x][parameter pack expanding] unused parameter warning with unpacking empty tuples

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.15 17:31:05
 CC||jason at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug rtl-optimization/49414] gcc.dg/pr44194-1.c fails

[eraman at gcc dot gnu.org]

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

--- Comment #5 from eraman at gcc dot gnu.org 2011-06-15 17:20:25 UTC ---
Author: eraman
Date: Wed Jun 15 17:20:20 2011
New Revision: 175082

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175082
Log:
2011-06-15  Easwaran Raman  

PR rtl-optimization/49414
* gcc.dg/pr44194-1.c: Restrict test to 64-bit targets.



Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr44194-1.c

[Bug c++/49292] [c++0x] non_const_var_error ICE for error when mixing static_assert, template, and constexpr

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #1 from Jason Merrill  2011-06-15 
17:08:23 UTC ---
This works now; I think it was fixed by my 6/9 patch.

[Bug c++/49356] [C++0x] decltype fails with recursive template function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||froydnj at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Resolution||INVALID

--- Comment #1 from Jason Merrill  2011-06-15 
17:05:38 UTC ---
The problem here is that t(f) is an rvalue, so it can't bind to the non-const
T& parameter in the recursive call.

Nathan has a patch in the works that should produce more helpful diagnostics
for this sort of situation.

[Bug rtl-optimization/49414] gcc.dg/pr44194-1.c fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  2011-06-15 
17:03:31 UTC ---
> The DSE opportunity doesn't arise in ia32 since the struct is returned through
> stack. Is the following patch restricting the test to x86_64 ok? (I have 
> tested
> that it works correctly on x86_64, but don't know how to test it gets excluded
> on other platforms)

x86-64 is too restrictive, the test should pass on SPARC64 as well.  I'd
suggest

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

with a comment saying that this is an approximation.  Preapproved if it works.

[Bug rtl-optimization/49414] gcc.dg/pr44194-1.c fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  2011-06-15 
16:59:54 UTC ---
It seems to me that the test should just be skipped for targets that always
return structures in memory, i.e. most 32-bit targets.

[Bug rtl-optimization/49414] gcc.dg/pr44194-1.c fails

[eraman at google dot com]

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

--- Comment #2 from Easwaran Raman  2011-06-15 
16:58:57 UTC ---
The DSE opportunity doesn't arise in ia32 since the struct is returned through
stack. Is the following patch restricting the test to x86_64 ok? (I have tested
that it works correctly on x86_64, but don't know how to test it gets excluded
on other platforms)


===
--- gcc/testsuite/gcc.dg/pr44194-1.c(revision 175063)
+++ gcc/testsuite/gcc.dg/pr44194-1.c(working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target x86_64-*-* } } */
 /* { dg-options "-O2 -fdump-rtl-dse1" } */
 #include 

[Bug c/49426] New: unwarranted warning from -Wsign-compare

[jim at meyering dot net]

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

   Summary: unwarranted warning from -Wsign-compare
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@meyering.net


In the following function, the compiler can deduce that "c"
is positive when it is compared with "k", so should not emit a warning:

$ cat k.c
int
f (int c, unsigned int k)
{
  if (c < 0)
return -1;
  return c < k;
}
$ gcc -c -O2 -Wsign-compare k.c
k.c: In function 'f':
k.c:6:12: warning: comparison between signed and unsigned integer expressions
[-Wsign-compare]

Using built-in specs.
COLLECT_GCC=/p/bin/gcc
COLLECT_LTO_WRAPPER=/h/p/p/gcc-2011-06-14.11h16/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /h/j/w/co/gcc-svn/configure --prefix=/p/p/gcc-2011-06-14.11h16
--disable-multilib --disable-libmudflap --disable-nls --enable-languages=c
Thread model: posix
gcc version 4.7.0 20110613 (experimental) (GCC)

[Bug ada/49425] ACATS test C974008 fails if run after test C761011

[tero.koskinen at iki dot fi]

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

--- Comment #1 from Tero Koskinen  2011-06-15 
16:52:47 UTC ---
(In reply to comment #0)
> Testcase:
> gnatchop -w *.a

Oops, this line should be:

gnatchop -w *.a *.ada

[Bug rtl-optimization/49414] gcc.dg/pr44194-1.c fails

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.15 16:52:22
 CC||ebotcazou at gcc dot
   ||gnu.org
   Target Milestone|--- |4.7.0
Summary|gcc.dg/pr44194-1.c failed   |gcc.dg/pr44194-1.c fails
 Ever Confirmed|0   |1

--- Comment #1 from Eric Botcazou  2011-06-15 
16:52:22 UTC ---
Indeed.

[Bug rtl-optimization/44194] struct returned by value generates useless stores

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #20 from Eric Botcazou  2011-06-15 
16:48:45 UTC ---
Fixed on trunk.  Thanks for tackling this, Easwaran.

[Bug c++/49399] [C++0x] substitution failure error

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #10 from Jason Merrill  2011-06-15 
16:47:02 UTC ---
Closing.  Feel free to open a bug report requesting implementation of DR 1170.

[Bug target/44618] [4.4/4.5/4.6 regression] wrong code with -frename-registers

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.4/4.5/4.6/4.7|[4.4/4.5/4.6 regression]
   |regression] wrong code with |wrong code with
   |-frename-registers  |-frename-registers

--- Comment #26 from Jakub Jelinek  2011-06-15 
16:44:12 UTC ---
Committed to the trunk so far apparently:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174997

[Bug ada/49425] New: ACATS test C974008 fails if run after test C761011

[tero.koskinen at iki dot fi]

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

   Summary: ACATS test C974008 fails if run after test C761011
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tero.koski...@iki.fi


ACATS test C974008 fails when it is run after test C761011 in a same process.

Testcase:
#!/bin/sh

wget -c http://www.ada-auth.org/acats-files/3.0/acats_30.tar.Z
tar zxf acats_30.tar.Z

cp support/{repbody.ada,repspec.ada} .
cp ./c7/c761011.a ./c9/c974008.a .
gnatchop -w *.a

cat > test3.adb< impdef.ads<

[Bug target/49411] [4.6/4.7] ICE: unrecognizable insn with -mxop in _mm_roti_epi8 with negative number

[qneill at gcc dot gnu.org]

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

--- Comment #6 from Quentin Neill  2011-06-15 
16:39:47 UTC ---
(In reply to comment #5)

> newer patch has been posted
Thanks; I will test this on AMD HW.

> test the op of vpermil
Okay.

> _mm_com*
I spotted them in the opcode tables, but had forgotten how those work.

I'm looking into lwpval/ins, bextr (there is an immediate) and vcvtps*

[Bug driver/49371] xgcc: error: unrecognized option '-pie' on *-apple-darwin*

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||ramana.radhakrishnan at arm
   ||dot com, robertcnelson at
   ||gmail dot com

--- Comment #30 from Dominique d'Humieres  
2011-06-15 16:17:48 UTC ---
It seems to affect also armv7l-unknown-linux-gnueabi (see
http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg01644.html ).

[Bug c++/49420] [C++0x] compiler segfault using result_of

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.15 16:16:05
 CC||jason at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug tree-optimization/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.15 16:02:59
  Component|target  |tree-optimization
 Ever Confirmed|0   |1

[Bug c++/49412] __dso_handle should be hidden

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  2011-06-15 16:02:12 
UTC ---
Fixed.

[Bug target/49411] [4.6/4.7] ICE: unrecognizable insn with -mxop in _mm_roti_epi8 with negative number

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-06-15 
15:57:29 UTC ---
FYI, a newer patch has been posted:
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01139.html
I don't think it is necessary to test the op of vpermil again if it is
CONST_INT, we know it is not 0..3 because otherwise
insn_data[icode].operand[i + 1].predicate (op, mode)
would be true.
_mm_com* don't seem to have an constant argument, just two vector arguments, so
there is nothing to check.  The immediate comes directly from the table and so
is known to be ok.

[Bug c++/49412] __dso_handle should be hidden

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  2011-06-15 
15:50:28 UTC ---
Author: hjl
Date: Wed Jun 15 15:50:22 2011
New Revision: 175080

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175080
Log:
Mark __dso_handle hidden if assembler supports it.

2011-06-15  H.J. Lu  

PR c++/49412
* decl.c (get_dso_handle_node): Mark __dso_handle hidden if
assembler supports hidden visibility.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c

[Bug target/49411] [4.6/4.7] ICE: unrecognizable insn with -mxop in _mm_roti_epi8 with negative number

[qneill at gcc dot gnu.org]

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

--- Comment #4 from Quentin Neill  2011-06-15 
15:38:27 UTC ---
Hi Jakub,

Thanks for looking at this.

I think we need an nargs==3 case for the Compare/Predicate generation
(_mm_com*) intrinsics as well.

And did you mean to test the value of INTVAL(op) in the nargs==4 vpermil case
before throwing an error?
-- 
Quentin

[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-06-15 
14:59:50 UTC ---
Anyway, the bug is elsewhere, in particular I'd say the bug is that we use the
normal SSA_NAME as init value of the second loop instead of the SSA_NAME
initialized from ASSERT_EXPR for that.

The interesting stmts are:
  # iD.1254_47 = PHI <[pr49419.c : 15:67] iD.1254_70(6), [pr49419.c : 15:67]
iD.1254_69(8), 0(3), 0(21)>
...
  iD.1254_86 = ASSERT_EXPR ;
...
  iD.1254_85 = ASSERT_EXPR  0>;
...
  # iD.1254_50 = PHI <[pr49419.c : 19:60] iD.1254_40(18), iD.1254_85(12)>
and the second loop sees i_85 as the initial value.  Now, first the i_47
setter is walked, with just one of the edges with value 0 executable, so i_47
has [0, 0] range there.  Then i_86 is walked, and as var's range is VR_RANGE,
while limit range is VR_ANTI_RANGE, surprisingly symbolic range
~[nbmax_17(D), nbmax_17(D)] wins.  I'd think [0, 0] would be much better to
return, both because it is not symbolic, is quite narrow and is range instead
of anti range.  After a while, i_50 stmt is walked several times, including
using
adjust_range_with_scev, which uses i_47 instead of i_85 as init for some
reason.
At that point it sees it has [0, 0] range and so computes something from that.
After a while, i_47 stmt is visited several times, last time resulting into
[0, +INF(OVF)] range (see other comments that it ought to be improved, but
uninteresting for this bug). So, the PHI setting i_47 is returning
SSA_PROP_INTERESTING, which results in all succ edges of that bb to be marked
for revisiting.  We revisit i_86 stmt, but that again returns the same
(uninteresting) ~[nbmax_17(D), nbmax_17(D)] range, which also means that
it is SSA_PROP_NOT_INTERESTING.  That bb contains just:
  [pr49419.c : 18:6] nbD.1255_24 = iD.1254_86 + 1;
  [pr49419.c : 19:3] if (iD.1254_86 > 0)
after it, but as i_86's VR didn't change, no other VRs in that bb change
either,
which means none of the succ bb's of this bb are queued for revisiting.
So, I think we should arrange for the actual current ASSERT_EXPR SSA_NAME to be
used as init during scev if possible, instead of the original one, and
furthermore I believe extract_range_from_assert_expr should do a better job.

[Bug target/49392] [arm] spurious EABI version mismatches when LTO enabled

[philb at gnu dot org]

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

philb at gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from philb at gnu dot org 2011-06-15 14:57:32 UTC ---
I just tried a different linker and that does seem to have made the problem go
away.  So I guess there is no gcc bug here.  Thanks.

[Bug debug/48207] ICE in lhd_set_decl_assembler_name, at langhooks.c:158

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||jason.vas.dias at gmail dot
   ||com

--- Comment #12 from Richard Guenther  2011-06-15 
14:48:04 UTC ---
*** Bug 49424 has been marked as a duplicate of this bug. ***

[Bug lto/49424] ICE in lhd_set_decl_assembler_name at langhooks.c:158 with '-flto'

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Richard Guenther  2011-06-15 
14:48:04 UTC ---
This is fixed on the 4.6 branch.

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

[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2

[rth at gcc dot gnu.org]

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

--- Comment #26 from Richard Henderson  2011-06-15 
14:40:58 UTC ---
(In reply to comment #25)
> (Assuming that backporting implies the emission of DWARF2 CFI) Is it not
> possible to drop DWARF2 CFI feature (which is optional) and still make 4.6x
> build successful? It is quite possible that some target might want to do this.

Um.  Why?  This is not using dwarf2 cfi for unwinding; that is
still using setjmp.  This is using dwarf2 cfi for debugging,
which is exactly what you asked for when you said -gdwarf-2.

If you mean the assembler .cfi directives, you do not need
that in order for the build to succeed.  But that is detected
at configure time; if you have an assembler that accepts them
we will emit them, otherwise we'll emit the cfi data as .byte.

If you mean something else, I don't know what it is.

[Bug libstdc++/37477] [Core 475] std::uncaught_exception() returns wrong value after entering terminate() in some cases

[maxime at altribe dot org]

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

Maxime van Noppen  changed:

   What|Removed |Added

 CC||maxime at altribe dot org

--- Comment #8 from Maxime van Noppen  2011-06-15 
14:16:38 UTC ---
I just attached a testcase which seems likely related to this bug. Tested with
g++ (GCC) 4.6.0 20110603 on x86_64 linux.

[Bug libstdc++/37477] [Core 475] std::uncaught_exception() returns wrong value after entering terminate() in some cases

[maxime at altribe dot org]

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

--- Comment #7 from Maxime van Noppen  2011-06-15 
14:15:38 UTC ---
Created attachment 24538
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24538
Exhibits uncaught return values

[Bug lto/49424] New: ICE in lhd_set_decl_assembler_name at langhooks.c:158 with '-flto'

[jason.vas.dias at gmail dot com]

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

   Summary: ICE in lhd_set_decl_assembler_name at langhooks.c:158
with '-flto'
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jason.vas.d...@gmail.com


When building qt-4.7.1 (from git:  git://anongit.kde.org/qt-kde.git )
with GCC 4.6.0, built unmodified source in gcc-4.6.0.tar.bz2, on a
Linux x86_64 platform ( binutils: 2.21.51.20110407 glibc:2.13 kernel: 2.38.8.8) 
g++ suffers an internal compiler error when compiling Qt's 
qt-kde/src/3rdparty/javascriptcore/JavaScriptCore/API/JSStringRef.cpp :

...
 /usr/bin/g++ -c -march=x86-64 -mtune=k8 -O2 -g -pipe -flto -Wall -Wreturn-type
-fno-strict-aliasing -Wcast-align -Wchar-subscripts -Wformat-security
-Wreturn-type -Wno-unused-parameter -Wno-sign-compare -Wno-switch
-Wno-switch-enum -Wundef -Wmissing-noreturn -Winit-self -fno-stack-protector -g
-fvisibility=hidden -fvisibility-inlines-hidden -D_REENTRANT -fPIC ...
src/3rdparty/javascriptcore/JavaScriptCore/API/JSStringRef.cpp
/usr/x/kde/4.1/KDE/qt-kde/src/3rdparty/javascriptcore/JavaScriptCore/API/JSStringRef.cpp:
In function 'JSStringGetUTF8CString':
/usr/x/kde/4.1/KDE/qt-kde/src/3rdparty/javascriptcore/JavaScriptCore/API/JSStringRef.cpp:112:1:
internal compiler error: in lhd_set_decl_assembler_name, at langhooks.c:158
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

When I remove the '-flto' option, this ICE does not occur and the compilation
succeeds .

Line 112 of that source file is the "end of file" :

bool JSStringIsEqualToUTF8CString(JSStringRef a, const char* b)
{
JSStringRef bBuf = JSStringCreateWithUTF8CString(b);
bool result = JSStringIsEqual(a, bBuf);
JSStringRelease(bBuf);

return result;
} // this is line 112
// FILE ENDS

If you need any more info here, let me know.
Thanks & Regards, Jason

[Bug target/49423] [arm] internal compiler error: in push_minipool_fix

[philb at gnu dot org]

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

--- Comment #1 from philb at gnu dot org 2011-06-15 13:50:23 UTC ---
Created attachment 24537
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24537
testcase

[Bug target/49423] New: [arm] internal compiler error: in push_minipool_fix

[philb at gnu dot org]

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

   Summary: [arm] internal compiler error: in push_minipool_fix
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ph...@gnu.org


$ arm-oe-linux-gnueabi-gcc -march=armv7-a -O2 -S -mfloat-abi=softfp -mfpu=vfp
svga_tgsi_insn.i
svga_tgsi_insn.c: In function 'svga_shader_emit_instructions':
svga_tgsi_insn.c:2969:1: internal compiler error: in push_minipool_fix, at
config/arm/arm.c:12138
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$

[Bug bootstrap/49415] [4.7 Regression] Revision 175071 fails to bootstrap on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  2011-06-15 
13:47:43 UTC ---
I have bootstrapped revision 175077 with the patch in comment #2.

[Bug target/49422] New: [arm] unable to find a register to spill in class 'VFP_LO_REGS'

[philb at gnu dot org]

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

   Summary: [arm] unable to find a register to spill in class
'VFP_LO_REGS'
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ph...@gnu.org
Target: arm-linux


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

$ arm-oe-linux-gnueabi-gcc -fPIC -mfpu=vfp -O2 s_span.i -march=armv6j
-mtune=arm1136jf-s -mfloat-abi=softfp -ffast-math -S
swrast/s_span.c: In function '_swrast_write_rgba_span':
swrast/s_span.c:1297:1: error: unable to find a register to spill in class
'VFP_LO_REGS'
swrast/s_span.c:1297:1: error: this is the insn:
(insn 2389 2380 3422 269 (set (subreg:SI (reg:QI 2169) 0)
(unsigned_fix:SI (fix:SF (reg/v:SF 78 s15 [orig:685 a ] [685]
swrast/s_span.c:867 670 {fixuns_truncsfsi2}
 (expr_list:REG_DEAD (reg/v:SF 78 s15 [orig:685 a ] [685])
(nil)))
swrast/s_span.c:1297: confused by earlier errors, bailing out
$

[Bug c++/49412] __dso_handle should be hidden

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-06/msg01153.htm
   ||l

--- Comment #2 from H.J. Lu  2011-06-15 13:14:08 
UTC ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01153.html

[Bug middle-end/27226] [4.1 Regression] Compiler looses track of alignment for emit_block_move

[niva at niisi dot msk.ru]

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

niva at niisi dot msk.ru changed:

   What|Removed |Added

 CC||niva at niisi dot msk.ru

--- Comment #19 from niva at niisi dot msk.ru 2011-06-15 12:46:58 UTC ---
(In reply to comment #18)
> Fixed.

I tried to checkout rev 117018 from
svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch/ and build the compiler
configured as follows:

Configured with: /home/niva/tests/gcc-117018/configure --target=mips64-none-elf
--enable-threads=no --disable-shared --enable-long-long --enable-c99
--enable-languages=c --enable-multilib --enable-symvers=gnu
--disable-libmudflap --disable-libssp --disable-libgcc_eh --with-newlib
--with-dwarf2 --with-system-zlib --enable-checking=release
--enable-generated-files-in-srcdir --verbose --prefix=/home/niva/local
--srcdir=/home/niva/tests/gcc-117018 --enable-cpp

I've compiled the file memcpy-1.c:
mips64-none-elf-gcc memcpy-1.c   -O2 -fno-show-column -S  -o memcpy-1.s117018

and got the assembler code with lbu instructions:
lui $3,%hi($LC0+2)
addiu   $2,$3,%lo($LC0+2)
lbu $5,%lo($LC0+2)($3)
lbu $4,5($2)
lbu $6,1($2)
lbu $7,2($2)
lbu $8,3($2)
lbu $9,4($2)

Eventually this bug was not fixed in gcc-4.1.2.

But the compiler built in the same way from the trunk (r116641) generated the
code with lhu instructions:
lui $2,%hi($LC0+2)
addiu   $3,$2,%lo($LC0+2)
lhu $5,%lo($LC0+2)($2)
lhu $4,4($3)
lhu $6,2($3)
lui $2,%hi(c)
addiu   $3,$2,%lo(c)
sh  $4,4($3)
sh  $5,%lo(c)($2)
j   $31
sh  $6,2($3)

Probably some significant changes from trunk were not applied to
gcc-4_1-branch.

[Bug fortran/49417] [4.6/4.7 Regression] [OOP] ICE on invalid CLASS component declaration

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.1

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[markus at trippelsdorf dot de]

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

--- Comment #103 from Markus Trippelsdorf  
2011-06-15 12:34:20 UTC ---
Even with 8c1fce46fc0 reverted libxul fails to link during
a profiledbuild. Normal build is fine.

with bfd:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
../../layout/ipc/RenderFrameParent.o: relocation R_X86_64_PC32 against
undefined hidden symbol
`nsRefPtr::~nsRefPtr()' can not be used when
making a shared object
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
final link failed: Bad value

with gold:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error:
/var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../layout/ipc/RenderFrameParent.o:
requires dynamic reloc which may overflow at runtime; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error:
/var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../content/events/src/nsEventStateManager.o:
requires dynamic reloc which may overflow at runtime; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error:
/var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../content/xul/templates/src/nsRuleNetwork.o:
requires dynamic reloc which may overflow at runtime; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error:
/var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../gfx/thebes/GLContextProviderGLX.o:
requires dynamic reloc which may overflow at runtime; recompile with -fPIC
/var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../intl/uconv/ucvlatin/nsUnicodeToUCS2BE.o:nsUnicodeToUCS2BE.cpp:function
vtable for nsUnicodeToUTF16BE: warning: relocation refers to discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol 'nsUnicodeToUTF16BE::~nsUnicodeToUTF16BE()' is not defined
locally
/var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../intl/uconv/ucvlatin/nsUnicodeToUCS2BE.o:nsUnicodeToUCS2BE.cpp:function
vtable for nsUnicodeToUTF16LE: warning: relocation refers to discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol 'nsUnicodeToUTF16LE::~nsUnicodeToUTF16LE()' is not defined
locally
/var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../intl/uconv/ucvcn/nsGBKToUnicode.o:nsGBKToUnicode.cpp:function
vtable for nsGBKToUnicode: warning: relocation refers to discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol 'nsGBKToUnicode::~nsGBKToUnicode()' is not defined locally
/var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../intl/uconv/ucvcn/nsGBKToUnicode.o:nsGBKToUnicode.cpp:function
vtable for nsGB18030ToUnicode: warning: relocation refers to discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol 'nsGB18030ToUnicode::~nsGB18030ToUnicode()' is not defined
locally
/var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../parser/htmlparser/src/nsHTMLTokens.o:nsHTMLTokens.cpp:function
vtable for CAttributeToken: warning: relocation refers to discarded section
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: hidden symbol 'CAttributeToken::~CAttributeToken()' is not defined
locally
/var/tmp/mozilla-central/moz-build-dir/toolkit/library/../../layout/generic/nsGfxScrollFrame.o:nsGfxScrollFrame.cpp:function
vtable for nsHTMLScrollFrame: warning: relocation refers to discarded section
...

[Bug bootstrap/49415] [4.7 Regression] Revision 175071 fails to bootstrap on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2011-06-15 
12:33:06 UTC ---
> Please try wrapping the problem prototype in #ifdef RTX_CODE, like some 
> other prototypes in that header. 

--- /opt/gcc/_clean/gcc/config/darwin-protos.h2011-04-06 13:56:07.0
+0200
+++ /opt/gcc/work/gcc/config/darwin-protos.h2011-06-15 13:34:23.0
+0200
@@ -54,8 +54,11 @@ extern void machopic_finish (FILE *);

 extern int machopic_reloc_rw_mask (void);
 extern section *machopic_select_section (tree, int, unsigned HOST_WIDE_INT);
+
+#ifdef RTX_CODE
 extern section *machopic_select_rtx_section (enum machine_mode, rtx,
  unsigned HOST_WIDE_INT);
+#endif /* RTX_CODE */

 extern section *darwin_function_section (tree, enum node_frequency, bool,
bool); 
 extern void darwin_function_switched_text_sections (FILE *, tree, bool);

I am now at stage3 (1.5 hour more to go for full bootstrap).

[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-06-15 
12:29:51 UTC ---
Perhaps even for:
void bar (void);
int test (int);

int fn (int x, int y)
{
  int i;
  for (i = 0; i < y && test (i); i++)
;
  if (i == y)
return;
  if (i == __INT_MAX__)
bar ();
}

we should be able to determine that bar can't be called.  In the loop body
i is known to be i < y, after the loop i <= y but the i == y test rules out the
equality again, so we end up again with i < y which is certainly i <
__INT_MAX__.

[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-06-15 
12:19:00 UTC ---
So, i_47 which is the i value on entry of the second loop is determined to be
[0, +INF(OVF)] and something goes wrong afterwards.  The bug will be there, but
I should note that VRP should easily prove that i never overflows.
Simpler testcases for that:
void bar (void);

void foo (int x, int y)
{
  if (x < y)
{
  if (x == __INT_MAX__)
bar ();
}
}

void baz (int x, int y, int z)
{
  if (x < y || x < z)
{
  if (x == __INT_MAX__)
bar ();
}
}

Here IMNSHO vrp should optimize the call to bar away, as when x is smaller than
some variable of the same type, it can't be the maximum of that type, because
even if the other number is __INT_MAX__, x must be smaller than that.

[Bug target/49421] New: [arm] suboptimal choice of working regs

[philb at gnu dot org]

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

   Summary: [arm] suboptimal choice of working regs
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ph...@gnu.org


If a leaf function requires one more working register than can be accomodated
in the call-clobbered set, gcc currently tends to push r4 and use that next. 
However, in the specific case of a leaf function, it would be better to push lr
and use that as the working register, since then the return can be done with a
single pop.  Consider the made-up example:

int f(int *a, int *b, int *c, int *d)
{
  int i;
  for (i = 0; i < 4; i++)
if (a[i] || b[i] || c[i] || d[i])
  return 1;

  return 0;
}

which compiles (-march=armv6 -mtune=arm1136jf-s -O2) to:

f:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
movip, #0
strr4, [sp, #-4]!
.L3:
ldrr4, [r0, ip]
cmpr4, #0
bne.L7
ldrr4, [r1, ip]
cmpr4, #0
bne.L7
ldrr4, [r2, ip]
cmpr4, #0
bne.L7
ldrr4, [r3, ip]
addip, ip, #4
cmpr4, #0
bne.L7
cmpip, #16
bne.L3
movr0, r4
.L2:
ldmfdsp!, {r4}
bxlr
.L7:
movr0, #1
b.L2

If lr had been pushed instead of r4 then the return could have simply been "pop
{lr}".

Also, since this is arm11, it is no more expensive to push two words than one. 
If the compiler had stacked both r4 and lr, it would have freed up an extra
register for the loop which would probably have allowed the loads to be
scheduled better.

[Bug fortran/49417] [4.6/4.7 Regression] [OOP] ICE on invalid CLASS component declaration

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.15 11:56:15
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |
   Target Milestone|4.6.1   |---
 Ever Confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org 2011-06-15 11:56:15 UTC ---
Mine (I'm working on a patch). Apparently we fail to check for the 'class_ok'
attribute.

[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-06-15 
11:55:40 UTC ---
Confirmed, seems VRP2 removes changes the
for(x=n;i>0;stack[i]=tree[x].y,x=tree[x].x,i--);
loop into endless loop.  Looking into it.

[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #1 from Mikael Pettersson  2011-06-15 
11:54:27 UTC ---
Same breakage also seen on m68k-linux.

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[markus at trippelsdorf dot de]

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

--- Comment #102 from Markus Trippelsdorf  
2011-06-15 11:44:22 UTC ---
Jan,
this is caused by:
commit 8c1fce46fc02e43e82b05f49894690133a1bcdcf
Author: hubicka 
Date:   Fri Jun 10 20:06:48 2011 +

Reverting the commit "fixes" the problem.

[Bug target/49419] [4.6/4.7 regression] gcc -O2 miscompiles gp2c

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.1

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[mh+gcc at glandium dot org]

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

--- Comment #101 from Mike Hommey  2011-06-15 
11:38:01 UTC ---
(In reply to comment #100)
> Please note that this error only happens during a profiled build.
> Normal build seems to be OK.

FWIW: https://bugzilla.mozilla.org/show_bug.cgi?id=664387

[Bug c++/49420] New: [C++0x] compiler segfault using result_of

[jarrydb at cse dot unsw.edu.au]

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

   Summary: [C++0x] compiler segfault using result_of
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jarr...@cse.unsw.edu.au


Created attachment 24535
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24535
result of segfaults

The compiler segfaults in the attached code. It uses result_of of a struct
which has an operator() with a return type defined by recursive instantiations
of decltype.

g++ --std=gnu++0x result_of_segfault.ii
‘
In file included from result_of_segfault.cpp:1:0:
/home/jarryd/current/soft/install-latest/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:
In instantiation of ‘std::_Result_of_impl’:
/home/jarryd/current/soft/install-latest/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:1806:12:
  required from ‘struct std::result_of’
result_of_segfault.cpp:33:33:   Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


gcc -v

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jarryd/current/soft/install-latest/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/jarryd/current/soft/src/gcc-svn/configure
--prefix=/home/jarryd/current/soft/install-latest --disable-multilib
--enable-languages=c,c++,go : (reconfigured)
/home/jarryd/current/soft/src/gcc-svn/configure
--prefix=/home/jarryd/current/soft/install-latest --disable-multilib
--enable-languages=c,c++,go,lto --no-create --no-recursion : (reconfigured)
/home/jarryd/current/soft/src/gcc-svn/configure
--prefix=/home/jarryd/current/soft/install-latest --disable-multilib
--enable-languages=c,c++,go,lto --no-create --no-recursion
Thread model: posix
gcc version 4.7.0 20110615 (experimental) (GCC)

[Bug target/49385] Invalid RTL intstruction for ARM

[revital.eres at linaro dot org]

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

--- Comment #3 from revital.eres at linaro dot org 2011-06-15 11:26:32 UTC ---
(In reply to comment #0)
> Created attachment 24504 [details]
> The test to reproduce the RTL instruction.
> I see the following invalid mem to mem RTL instruction in test2.c.189r.sched1

btw, the first dump file which contains this invalid mem-mem instruction is
combine.

[Bug tree-optimization/48613] [4.6/4.7 Regression] ICE: vector VEC(ipa_node_params_t,base) index domain error with -O0 -flto -findirect-inlining

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  2011-06-15 
11:22:38 UTC ---
Author: jamborm
Date: Wed Jun 15 11:22:35 2011
New Revision: 175077

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175077
Log:
2011-06-15  Martin Jambor  

PR tree-optimization/48613
* ipa-prop.c (ipa_prop_write_jump_functions): Return immediately if
ipa_node_params_vector is NULL.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c

[Bug target/49419] New: [4.6/4.7 regression] gcc -O2 miscompiles gp2c

[doko at ubuntu dot com]

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

   Summary: [4.6/4.7 regression] gcc -O2 miscompiles gp2c
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@ubuntu.com


[forwarded from http://bugs.debian.org/630567]

fails with -O2/-O3, works with -O1/-Os with 20110611 4.6 branch, 20110531
trunk, apparently on {powerpc,mips,mipsel,s390}-linux.

gcc-4.6 miscompiles gp2c on several platforms including powerpc, see 
https://buildd.debian.org/status/package.php?p=gp2c

On powerpc (32 bit):
The function 'listostack' in src/utils.c is miscompiled with -O2.
Please find a testcase.

gcc-4.6 -O2 -Wall gccbug.c -o gccbug && ./gccbug
zsh: segmentation fault  ./gccbug
gcc-4.6 -O1 -Wall gccbug.c -o gccbug && ./gccbug
nb=2
0: 1
1: 2


#include 
#include 

typedef struct
{
  enum {LEAF=0, NODE=1} f;/*node function*/
  int x;  /*node left child*/
  int y;  /*node right child*/
} node; 

node *tree;

int listtostack(int n, int f, int *stack, int nbmax)
{
  int x,i,nb;
  if (n==-1) return 0;
  for(x=n,i=0;tree[x].f==f && i0;stack[i]=tree[x].y,x=tree[x].x,i--);
  stack[0]=x;
  return nb;
}

#define STACKSZ 3

int main(void)
{
  int stack[STACKSZ];
  int i,nb;
  tree = (node *)calloc(STACKSZ,sizeof(node));
  tree[0].f = NODE;
  tree[0].x = 1;
  tree[0].y = 2;
  nb=listtostack(0,1,stack,STACKSZ);
  printf("nb=%d\n",nb);
  for(i=0;i

[Bug c++/49418] openmp default(none) in template function

[gcc-bug at safetymail dot info]

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

--- Comment #1 from gcc-bug at safetymail dot info 2011-06-15 11:07:12 UTC ---
Created attachment 24534
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24534
test case

[Bug c++/49418] New: openmp default(none) in template function

[gcc-bug at safetymail dot info]

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

   Summary: openmp default(none) in template function
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc-...@safetymail.info


Compilation fails, if within a template function a const argument is used
within an openmp parallel region with default(none).

If shared(x) is specified also a "predetermined 'shared'" error is produced.


Error:
$ g++ -fopenmp pf.cc
pf.cc: In function 'void g(T)':
pf.cc:11:45: error: 'x' is predetermined 'shared' for 'shared'
pf.cc: In function 'void f(T) [with T = int]':
pf.cc:5:8: error: 'x' not specified in enclosing parallel
pf.cc:5:8: error: enclosing parallel
pf.cc: In function 'void g(T) [with T = int]':
pf.cc:12:8: error: 'x' not specified in enclosing parallel
pf.cc:12:8: error: enclosing parallel

Version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/me/gcc/libexec/gcc/i686-pc-cygwin/4.6.0/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: ./configure --enable-languages=c,c++ --prefix=/home/me/gcc
--enable-libgomp
Thread model: single
gcc version 4.6.0 (GCC)

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[markus at trippelsdorf dot de]

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

--- Comment #100 from Markus Trippelsdorf  
2011-06-15 10:44:52 UTC ---
Please note that this error only happens during a profiled build.
Normal build seems to be OK.

[Bug tree-optimization/49318] [4.7 Regression] 177.mesa in SPEC CPU 2000 failed to build

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Ira Rosen  2011-06-15 10:45:17 UTC 
---
Fixed.

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[markus at trippelsdorf dot de]

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

--- Comment #99 from Markus Trippelsdorf  
2011-06-15 10:32:08 UTC ---
New build failure with "gold" and gcc 4.7.0 20110615:

ake[6]: Entering directory
`/var/tmp/mozilla-central/moz-build-dir/js/src/shell'
js.cpp
c++ -o js.o -c  -I../../../dist/system_wrappers_js -include
/var/tmp/mozilla-central/js/src/config/gcc_hidden.h -DEXPORT_JS_API
-DOSTYPE=\"Linux3.0\" -DOSARCH=Linux -I/var/tmp/mozilla-central/js/src -I..
-I/var/tmp/mozilla-central/js/src/shell -I. -I../../../dist/include
-I../../../dist/include/nsprpub 
-I/var/tmp/mozilla-central/moz-build-dir/dist/include/nspr-fPIC  -fno-rtti
-fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof
-Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -march=native
-ffunction-sections -fdata-sections -fno-strict-aliasing -pthread -pipe 
-DNDEBUG -DTRIMMED -fprofile-generate -O3   -DMOZILLA_CLIENT -include
../js-confdefs.h -MD -MF .deps/js.pp
/var/tmp/mozilla-central/js/src/shell/js.cpp
jsworkers.cpp
c++ -o jsworkers.o -c  -I../../../dist/system_wrappers_js -include
/var/tmp/mozilla-central/js/src/config/gcc_hidden.h -DEXPORT_JS_API
-DOSTYPE=\"Linux3.0\" -DOSARCH=Linux -I/var/tmp/mozilla-central/js/src -I..
-I/var/tmp/mozilla-central/js/src/shell -I. -I../../../dist/include
-I../../../dist/include/nsprpub 
-I/var/tmp/mozilla-central/moz-build-dir/dist/include/nspr-fPIC  -fno-rtti
-fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof
-Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -march=native
-ffunction-sections -fdata-sections -fno-strict-aliasing -pthread -pipe 
-DNDEBUG -DTRIMMED -fprofile-generate -O3   -DMOZILLA_CLIENT -include
../js-confdefs.h -MD -MF .deps/jsworkers.pp
/var/tmp/mozilla-central/js/src/shell/jsworkers.cpp
/var/tmp/mozilla-central/js/src/shell/jsworkers.cpp: In member function ‘void
js::workers::MainQueue::destroy(JSContext*)’:
/var/tmp/mozilla-central/js/src/shell/jsworkers.cpp:371:16: warning: deleting
object of polymorphic class type ‘js::workers::MainQueue’ which has non-virtual
destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor]
/var/tmp/mozilla-central/js/src/shell/jsworkers.cpp: In member function ‘bool
js::workers::ThreadPool::start(JSContext*)’:
/var/tmp/mozilla-central/js/src/shell/jsworkers.cpp:511:20: warning: deleting
object of polymorphic class type ‘js::workers::WorkerQueue’ which has
non-virtual destructor might cause undefined behaviour
[-Wdelete-non-virtual-dtor]
/var/tmp/mozilla-central/js/src/shell/jsworkers.cpp: In member function ‘void
js::workers::ThreadPool::shutdown(JSContext*)’:
/var/tmp/mozilla-central/js/src/shell/jsworkers.cpp:548:16: warning: deleting
object of polymorphic class type ‘js::workers::WorkerQueue’ which has
non-virtual destructor might cause undefined behaviour
[-Wdelete-non-virtual-dtor]
/var/tmp/mozilla-central/js/src/shell/jsworkers.cpp: In static member function
‘static void js::workers::Worker::jsFinalize(JSContext*, JSObject*)’:
/var/tmp/mozilla-central/js/src/shell/jsworkers.cpp:690:20: warning: deleting
object of polymorphic class type ‘js::workers::Worker’ which has non-virtual
destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor]
/var/tmp/mozilla-central/js/src/shell/jsworkers.cpp: In static member function
‘static js::workers::Worker* js::workers::Worker::create(JSContext*,
js::workers::WorkerParent*, JSString*, JSObject*)’:
/var/tmp/mozilla-central/js/src/shell/jsworkers.cpp:1073:16: warning: deleting
object of polymorphic class type ‘js::workers::Worker’ which has non-virtual
destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor]
In file included from /var/tmp/mozilla-central/js/src/shell/js.cpp:97:0:
/var/tmp/mozilla-central/js/src/jsobjinlines.h: In member function ‘void
JSObject::setArrayLength(uint32)’:
/var/tmp/mozilla-central/js/src/jsobjinlines.h:367:24: warning: cast to pointer
from integer of different size [-Wint-to-pointer-cast]
/usr/bin/python2.7 /var/tmp/mozilla-central/js/src/config/pythonpath.py
-I../config /var/tmp/mozilla-central/js/src/config/expandlibs_exec.py --uselist
--  c++ -o js  -fno-rtti -fno-exceptions -Wall -Wpointer-arith
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor
-Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type
-pedantic -Wno-long-long -march=native -ffunction-sections -fdata-sections
-fno-strict-aliasing -pthread -pipe  -DNDEBUG -DTRIMMED -fprofile-generate -O3 
js.o jsworkers.o   -lpthread   -fprofile-generate -Wl,-rpath-link,/bin
-Wl,-rpath-link,/var/tmp/mozilla-central/moz-build-dir/dist/lib 
-L../../../dist/bin -L../../../dist/lib
-L/var/tmp/mozilla-central/moz-build-dir/dist/lib -lplds4 -lplc4 -lnspr4
-lpthread -ldl ../editline/libeditlin