[Bug java/48417] -ffixed-regs option can't work in mips-elf-gcj compiler

[licheng.1212 at gmail dot com]

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

--- Comment #6 from licheng.1212 at gmail dot com  2011-08-27 06:12:05 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > still hava this problem,please see the latest commit
> 
> See PR43700, which I suspect was fixed by r172616 on trunk.

PR43700's patch is bad,But PR43732's patch is OK

PR43700:
--- branches/gcc-4_4-branch/gcc/config/mips/mips.c2011/05/29 17:51:03   
174408
+++ branches/gcc-4_4-branch/gcc/config/mips/mips.c2011/05/29 18:10:44   
174409
@@ -8495,7 +8495,7 @@
  property here.  */
   return (regno == GLOBAL_POINTER_REGNUM
   ? TARGET_CALL_SAVED_GP
-  : !call_really_used_regs[regno]);
+  : !global_regs[regno] && !call_really_used_regs[regno]);
 }

 /* Return true if the function body might clobber register REGNO.

PR43732:

diff -Naur gcc-4.4.3.base/gcc/config/mips/mips.c
gcc-4.4.3/gcc/config/mips/mips.c
--- gcc-4.4.3.base/gcc/config/mips/mips.c   2010-04-09 14:10:00.235609702
-0400
+++ gcc-4.4.3/gcc/config/mips/mips.c2010-04-09 14:12:28.520998582 -0400
@@ -8495,7 +8495,7 @@
  property here.  */
   return (regno == GLOBAL_POINTER_REGNUM
  ? TARGET_CALL_SAVED_GP
- : !call_really_used_regs[regno]);
+ : !call_really_used_regs[regno] && !fixed_regs[regno]);
 }

 /* Return true if the function body might clobber register REGNO.

Please check it!!

[Bug c++/50207] G++ segv's on reduced test case

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2011-08-27 
04:48:41 UTC ---
Related to Bug 46862.

[Bug c++/50207] New: G++ segv's on reduced test case

[bergner at gcc dot gnu.org]

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

 Bug #: 50207
   Summary: G++ segv's on reduced test case
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: berg...@gcc.gnu.org


A G++ from today's trunk (20110826) segv's on a reduced test case (using delta)
like so:

bergner@igoo:~> cat minimal.ii 
typedef long unsigned int size_t;
namespace std __attribute__ ((__visibility__ ("default")))
{
  using::size_t;
}

typedef unsigned char uint8_t;
namespace std
{
  namespace decimal
  {
template < class _Fmt > struct _FmtTraits;
class decimal32;
  }
}
namespace std
{
  namespace decimal
  {
template <> class _FmtTraits < decimal32 >
{
  public:
  static const std::size_t _NumBytes = 4UL;
};
template < class _Tr > class _DecBase
{
  uint8_t _Bytes[_Tr::_NumBytes];
};
class decimal32:public _DecBase < _FmtTraits < decimal32 > >
{
  decimal32 () { }
};
  }
}
bergner@igoo:~> /home/bergner/gcc/install/gcc-mainline-debug/bin/g++ -Wall -S
minimal.ii 
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

GDB show this backtrace:

#0  0x10412cc8 in decl_is_template_id (decl=0xfffb6edcc18,
template_info=0xfffb6edcc18)
at /home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:267
#1  0x1041b44c in write_nested_name (decl=0xfffb6e24ac0) at
/home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:928
#2  0x1041ab48 in write_name (decl=0xfffb6e24ac0, ignore_local_scope=0)
at /home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:855
#3  0x104284e4 in write_class_enum_type (type=0xfffb6edd4a0) at
/home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:2398
#4  0x10424840 in write_type (type=0xfffb6edd4a0) at
/home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:1884
#5  0x1042d1ec in write_template_arg (node=0xfffb6edcc18) at
/home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:2843
#6  0x10428868 in write_template_args (args=0xfffb6f13a70) at
/home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:2427
#7  0x1041b50c in write_nested_name (decl=0xfffb6e245b8) at
/home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:932
#8  0x1041ab48 in write_name (decl=0xfffb6e245b8, ignore_local_scope=0)
at /home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:855
#9  0x104284e4 in write_class_enum_type (type=0xfffb6edccc0) at
/home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:2398
#10 0x10424840 in write_type (type=0xfffb6edccc0) at
/home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:1884
#11 0x1042d1ec in write_template_arg (node=0xfffb6edccc0) at
/home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:2843
#12 0x10428868 in write_template_args (args=0xfffb6f14088) at
/home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:2427
#13 0x1041b50c in write_nested_name (decl=0xfffb6e24ac0) at
/home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:932
#14 0x1041ab48 in write_name (decl=0xfffb6e24ac0, ignore_local_scope=0)
at /home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:855
#15 0x104284e4 in write_class_enum_type (type=0xfffb6edd4a0) at
/home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:2398
#16 0x10424840 in write_type (type=0xfffb6edd4a0) at
/home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:1884
#17 0x1042d1ec in write_template_arg (node=0xfffb6edcc18) at
/home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:2843
#18 0x10428868 in write_template_args (args=0xfffb6f13a70) at
/home/bergner/gcc/gcc-mainline-base/gcc/cp/mangle.c:2427
...

The backtrace also show we have 10's of thousands of frames stacked repeated
over and over, so it looks like we've gone into some type of infinite
recursion.  A quick look at GCC 4.6 show's it fails in the same manner.  I
haven't checked anything earlier.

[Bug bootstrap/50206] Internal compiler error in xgcc while trying to bootstrap 4.6.1

[david at thornley dot net]

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

--- Comment #1 from David H Thornley  2011-08-27 
03:06:05 UTC ---
Created attachment 25116
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25116
Terminal output from the crash

[Bug bootstrap/50206] New: Internal compiler error in xgcc while trying to bootstrap 4.6.1

[david at thornley dot net]

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

 Bug #: 50206
   Summary: Internal compiler error in xgcc while trying to
bootstrap 4.6.1
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: da...@thornley.net


I am running Ubuntu 10.04 LTS on an Intel Core 2, and wanted to install a later
version of gcc.  I downloaded gcc-4.6.1-tar.gz on August 25, 2011, opened it
up, and tried to bootstrap.  The source was in directory gcc-4.6.1, and I was
trying to compile in directory gcc-4.6.1-bin.  I executed the following from
that directory:

../gcc-4.6.1/configure --program-prefix=my
ls
make
make bootstrap
make clean
make bootstrap

I got crashes on all makes (except make clean), but am only reporting the last.

There was a lot of output.  I copy-pasted the terminal to file error.txt
(attached) from the command that started the crash to the end of the output.

[Bug c++/48582] [C++0x] [DR 342] Template non-type arguments doesn't accept null pointer constant value

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-08-27
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
Summary|Template non-type arguments |[C++0x] [DR 342] Template
   |doesn't accept null pointer |non-type arguments doesn't
   |constant value  |accept null pointer
   ||constant value
 Ever Confirmed|0   |1

[Bug rtl-optimization/50205] New: [4.6/4.7 Regression] ICE: in code_motion_path_driver, at sel-sched.c:6581 with -fselective-scheduling2 and custom flags

[zsojka at seznam dot cz]

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

 Bug #: 50205
   Summary: [4.6/4.7 Regression] ICE: in code_motion_path_driver,
at sel-sched.c:6581 with -fselective-scheduling2 and
custom flags
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -O2 -fno-cprop-registers -fno-dce -fno-forward-propagate
-fselective-scheduling2 -funroll-loops -fno-web testcase.c 
testcase.c: In function 'foo':
testcase.c:11:1: internal compiler error: in code_motion_path_driver, at
sel-sched.c:6581
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r178096 - crash
4.6 r177922 - crash
4.5 r177922 - OK

[Bug fortran/50050] [4.6/4.7 Regression] Internal compiler error free_expr0 at expr.c:3709 via gfc_done_2

[mikael at gcc dot gnu.org]

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

--- Comment #12 from Mikael Morin  2011-08-26 
22:17:13 UTC ---
Author: mikael
Date: Fri Aug 26 22:17:09 2011
New Revision: 178125

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178125
Log:
2011-08-26  Mikael Morin  

PR fortran/50050
* expr.c (gfc_free_shape): Do nothing if shape is NULL.
(free_expr0): Remove redundant NULL shape check.
* resolve.c (check_host_association): Ditto.
* trans-expr.c (gfc_trans_subarray_assign): Assert that shape is
non-NULL.
* trans-io.c (transfer_array_component): Ditto.

2011-08-26  Mikael Morin  

PR fortran/50050
* gfortran.dg/pointer_comp_init_1.f90: New test.


Added:
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/pointer_comp_init_1.f90
Modified:
branches/gcc-4_6-branch/gcc/fortran/ChangeLog
branches/gcc-4_6-branch/gcc/fortran/expr.c
branches/gcc-4_6-branch/gcc/fortran/resolve.c
branches/gcc-4_6-branch/gcc/fortran/trans-expr.c
branches/gcc-4_6-branch/gcc/fortran/trans-io.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/50204] [4.5/4.6/4.7 Regression] Missed fully redundant load found in crafty (SPEC 2k)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Known to work||4.3.3
   Target Milestone|--- |4.5.4
  Known to fail||4.5.4, 4.6.1, 4.7.0

[Bug tree-optimization/50204] New: [4.5/4.6/4.7 Regression] Missed fully redundant load found in crafty (SPEC 2k)

[pinskia at gcc dot gnu.org]

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

 Bug #: 50204
   Summary: [4.5/4.6/4.7 Regression] Missed fully redundant load
found in crafty (SPEC 2k)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org


Simplified testcase:
extern int opening;
extern int middle_game;
int s;
extern int d[1];
void PreEvaluate(int wtm)
{
  int i, j;
  if (opening) {
d[0]=1;
  }
  else if (middle_game) {
d[0]=-1;
  }
  if (4 != opening) {
return;
  }
  s = 1;
}
--- CUT ---
4.3 catches the load of opening but 4.6 does not (4.5 does not either).

[Bug debug/50203] New: ICE: in output_loc_list, at dwarf2out.c:8188 with --param max-vartrack-expr-depth=140

[zsojka at seznam dot cz]

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

 Bug #: 50203
   Summary: ICE: in output_loc_list, at dwarf2out.c:8188 with
--param max-vartrack-expr-depth=140
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ /mnt/svn/gcc-trunk/binary-latest/bin/gcc -O3 -gdwarf-2 -fno-tree-sink --param
max-vartrack-expr-depth=140 testcase.c
testcase.c:29:1: internal compiler error: in output_loc_list, at
dwarf2out.c:8188
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) bt
#0  fancy_abort (file=0x125e160 "/mnt/svn/gcc-trunk/gcc/dwarf2out.c",
line=8188, function=0x1266840 "output_loc_list")
at /mnt/svn/gcc-trunk/gcc/diagnostic.c:892
#1  0x006f3e0c in output_loc_list (die=Unhandled dwarf expression
opcode 0xfa
) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:8188
#2  output_location_lists (die=Unhandled dwarf expression opcode 0xfa
) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:7514
#3  0x006f3bd1 in output_location_lists (die=Unhandled dwarf expression
opcode 0xfa
) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:7516
#4  0x006f3bd1 in output_location_lists (die=Unhandled dwarf expression
opcode 0xfa
) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:7516
#5  0x006f3bd1 in output_location_lists (die=Unhandled dwarf expression
opcode 0xfa
) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:7516
#6  0x00714457 in dwarf2out_finish (filename=Unhandled dwarf expression
opcode 0xf3
) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:22620
#7  0x009dc3ce in compile_file (argc=18, argv=0x7fffda88) at
/mnt/svn/gcc-trunk/gcc/toplev.c:597
#8  do_compile (argc=18, argv=0x7fffda88) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1886
#9  toplev_main (argc=18, argv=0x7fffda88) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1962
#10 0x76192d2d in __libc_start_main () from /lib64/libc.so.6
#11 0x0055a609 in _start ()

Tested revisions:
r178096 - crash

[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011-08-26
 Ever Confirmed|0   |1

--- Comment #4 from H.J. Lu  2011-08-26 21:42:10 
UTC ---
Can you verify if revision 173612:

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

causes this regression?

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  
2011-08-26 21:29:41 UTC ---
On Fri, Aug 26, 2011 at 09:09:42PM +, sgk at troutmask dot
apl.washington.edu wrote:
> 
> ==4791== Conditional jump or move depends on uninitialised value(s)
> ==4791==at 0x43F6DF: strlen (in /usr/home/sgk/tmp/z)
> ==4791==by 0x40B12D: write_integer (write.c:1285)
> ==4791==by 0x40EB13: _gfortrani_list_formatted_write (write.c:1571)
> ==4791==by 0x4002FB: MAIN__ (in /usr/home/sgk/tmp/z)
> ==4791==by 0x4003FE: main (in /usr/home/sgk/tmp/z)
> ==4791== 
>   16
> ==4791== Jump to the invalid address stated on the next line
> ==4791==at 0x0: ???
> ==4791==by 0x44AB7F: ??? (in /usr/home/sgk/tmp/z)
> ==4791==by 0x3: ???
> ==4791==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> ==4791== 
> ==4791== 
> ==4791== Process terminating with default action of signal 11 (SIGSEGV):
> dumping core
> ==4791==  Bad permissions for mapped region at address 0x0
> ==4791==at 0x0: ???
> ==4791==by 0x44AB7F: ??? (in /usr/home/sgk/tmp/z)
> ==4791==by 0x3: ???

Some additional debugging.

(gdb) run
Starting program: /usr/home/sgk/tmp/z 
  16

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x0040c2e2 in write_float (dtp=0x7fffd2f0, f=0x200820588, 
source=Unhandled dwarf expression opcode 0xf3
) at ../../../gcc4x/libgfortran/io/write_float.def:1062
#2  0x004049b6 in formatted_transfer_scalar_write (dtp=0x7fffd2f0, 
type=BT_REAL, p=0x7fffd4d0, kind=16, size=16, nelems=4)
at ../../../gcc4x/libgfortran/io/transfer.c:1630
#3  formatted_transfer (dtp=0x7fffd2f0, type=BT_REAL, p=0x7fffd4d0, 
kind=16, size=16, nelems=4)
at ../../../gcc4x/libgfortran/io/transfer.c:1868
#4  0x00402e80 in transfer_array (dtp=0x7fffd2f0, desc=Unhandled
dwarf expression opcode 0xf3
)
at ../../../gcc4x/libgfortran/io/transfer.c:2036
#5  0x004003ba in MAIN__ () at a.f90:4

[Bug target/50164] [IRA, 4.7 Regression] Performance degradation due to increased memory instructions count

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011-08-26
 Ever Confirmed|0   |1

--- Comment #4 from H.J. Lu  2011-08-26 21:10:07 
UTC ---
On Atom with -m32 -O2 -march=atom,

1. GCC 4.6.1:

./4.6  64.16s user 0.01s system 99% cpu 1:04.18 total

2. GCC 4.7.0 20110819:

./0819  69.73s user 0.01s system 99% cpu 1:09.76 total

3. GCC 4.7.0 20110826:

./0826  64.30s user 0.02s system 99% cpu 1:04.33 total

Has this problem been fixed?

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  
2011-08-26 21:09:42 UTC ---
On Fri, Aug 26, 2011 at 09:00:04PM +, longb at cray dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201
> 
> --- Comment #2 from Bill Long  2011-08-26 21:00:04 UTC 
> ---
> OS is Linux SLES 11.
> 
> From the output in the test, it looks like you tried only the scalar case,
> which I agree works.  The array case (second test code) is the one the fails.

Whoops, Yes, I grabbed the wrong testcase. :(

==4791== Conditional jump or move depends on uninitialised value(s)
==4791==at 0x43F6DF: strlen (in /usr/home/sgk/tmp/z)
==4791==by 0x40B12D: write_integer (write.c:1285)
==4791==by 0x40EB13: _gfortrani_list_formatted_write (write.c:1571)
==4791==by 0x4002FB: MAIN__ (in /usr/home/sgk/tmp/z)
==4791==by 0x4003FE: main (in /usr/home/sgk/tmp/z)
==4791== 
  16
==4791== Jump to the invalid address stated on the next line
==4791==at 0x0: ???
==4791==by 0x44AB7F: ??? (in /usr/home/sgk/tmp/z)
==4791==by 0x3: ???
==4791==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==4791== 
==4791== 
==4791== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==4791==  Bad permissions for mapped region at address 0x0
==4791==at 0x0: ???
==4791==by 0x44AB7F: ??? (in /usr/home/sgk/tmp/z)
==4791==by 0x3: ???

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[longb at cray dot com]

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

--- Comment #2 from Bill Long  2011-08-26 21:00:04 UTC 
---
OS is Linux SLES 11.

>From the output in the test, it looks like you tried only the scalar case,
which I agree works.  The array case (second test code) is the one the fails.

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[kargl at gcc dot gnu.org]

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

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 2011-08-26 20:54:56 UTC ---
(In reply to comment #0)
> It appears that the combination of -static and promoting 'double precision' to
> kind=16 causes problems for writing an double precision array.  Either 
> changing
> from array to scalar, or removing -static avoids the problem. 
> 
> Writing quad scalar with -static is fine:
> 
> > cat fdp2.f90
> double precision :: x
> x = 3.4
> print *, kind(x)
> write (*, "(f10.3)" ) x
> end
> > gfortran -fdefault-real-8 -static fdp2.f90
> > ./a.out
>   16
>  3.400
> 
> Writing quad array with -static -> segfault.
> 
> > cat fdp1.f90
> double precision :: x(4)
> x = 3.4
> print *, kind(x)
> write (*, "(4f10.3)" ) x
> end
> > gfortran -fdefault-real-8 -static fdp1.f90
> > ./a.out
>   16
> Segmentation fault
> 
> But is OK without -static:
> 
> > gfortran -fdefault-real-8  fdp1.f90
> > ./a.out
>   16
>  3.400 3.400 3.400 3.400
> >

What operating system?

It works for me.

troutmask:sgk[207] gfc4x -o z a.f90 && ./z
   8
 3.400
troutmask:sgk[208] gfc4x -o z -static a.f90 && ./z
   8
 3.400
troutmask:sgk[209] gfc4x -o z -static -fdefault-real-8 a.f90 && ./z
  16
 3.400
troutmask:sgk[210] gfc4x -o z -fdefault-real-8 a.f90 && ./z
  16
 3.400

[Bug target/50116] [4.6 Regression] internal compiler error: in decode_addr_const, at varasm.c:2632

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-08-26
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.2
Summary|internal compiler error: in |[4.6 Regression] internal
   |decode_addr_const, at   |compiler error: in
   |varasm.c:2632   |decode_addr_const, at
   ||varasm.c:2632
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-08-26 
20:52:36 UTC ---
Mine.

[Bug target/50202] New: ICE: in final_scan_insn, at final.c:2709 (could not split insn) with __builtin_ia32_pcmpistri128

[zsojka at seznam dot cz]

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

 Bug #: 50202
   Summary: ICE: in final_scan_insn, at final.c:2709 (could not
split insn) with __builtin_ia32_pcmpistri128
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -O -mf16c -fno-dce -fno-tree-dse testcase.c 
testcase.c: In function 'foo':
testcase.c:10:1: error: could not split insn
(insn 6 5 9 2 (parallel [
(set (reg:SI 2 cx [61])
(unspec:SI [
(reg:V16QI 21 xmm0 [orig:59 v.0 ] [59])
(reg:V16QI 21 xmm0 [orig:59 v.0 ] [59])
(const_int 255 [0xff])
] UNSPEC_PCMPISTR))
(set (reg:V16QI 21 xmm0 [62])
(unspec:V16QI [
(reg:V16QI 21 xmm0 [orig:59 v.0 ] [59])
(reg:V16QI 21 xmm0 [orig:59 v.0 ] [59])
(const_int 255 [0xff])
] UNSPEC_PCMPISTR))
(set (reg:CC 17 flags)
(unspec:CC [
(reg:V16QI 21 xmm0 [orig:59 v.0 ] [59])
(reg:V16QI 21 xmm0 [orig:59 v.0 ] [59])
(const_int 255 [0xff])
] UNSPEC_PCMPISTR))
]) testcase.c:8 1767 {sse4_2_pcmpistr}
 (expr_list:REG_UNUSED (reg:V16QI 21 xmm0 [62])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:SI 2 cx [61])
(nil)
testcase.c:10:1: internal compiler error: in final_scan_insn, at final.c:2709
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r178096 - crash
4.6 r177922 - crash

[Bug fortran/50201] New: gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[longb at cray dot com]

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

 Bug #: 50201
   Summary: gfortran with -static causes seg fault at runtime for
writing double prec array with precision increased to
kind=16
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lo...@cray.com


It appears that the combination of -static and promoting 'double precision' to
kind=16 causes problems for writing an double precision array.  Either changing
from array to scalar, or removing -static avoids the problem. 

Writing quad scalar with -static is fine:

> cat fdp2.f90
double precision :: x
x = 3.4
print *, kind(x)
write (*, "(f10.3)" ) x
end
> gfortran -fdefault-real-8 -static fdp2.f90
> ./a.out
  16
 3.400

Writing quad array with -static -> segfault.

> cat fdp1.f90
double precision :: x(4)
x = 3.4
print *, kind(x)
write (*, "(4f10.3)" ) x
end
> gfortran -fdefault-real-8 -static fdp1.f90
> ./a.out
  16
Segmentation fault

But is OK without -static:

> gfortran -fdefault-real-8  fdp1.f90
> ./a.out
  16
 3.400 3.400 3.400 3.400
>

[Bug middle-end/50200] New: ICE: SIGSEGV in df_insn_refs_collect (df-scan.c:3405)

[zsojka at seznam dot cz]

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

 Bug #: 50200
   Summary: ICE: SIGSEGV in df_insn_refs_collect (df-scan.c:3405)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -O -fno-tree-ch -fno-tree-dominator-opts -fno-tree-loop-optimize
-funroll-loops --param case-values-threshold=1 testcase.c
==27091== Invalid read of size 8
==27091==at 0x6C5887: df_insn_refs_collect(df_collection_rec*,
basic_block_def*, df_insn_info*) (df-scan.c:3405)
==27091==by 0x6C643A: df_insn_refs_verify(df_collection_rec*,
basic_block_def*, rtx_def*, bool) (df-scan.c:4343)
==27091==by 0x6C67AA: df_bb_verify(basic_block_def*) (df-scan.c:4392)
==27091==by 0x6C9081: df_scan_verify() (df-scan.c:4526)
==27091==by 0x6B2A88: df_verify() (df-core.c:1644)
==27091==by 0x6B2BBE: df_analyze() (df-core.c:1205)
==27091==by 0x113E039: rest_of_handle_initialize_regs() (init-regs.c:60)
==27091==by 0x8E6216: execute_one_pass(opt_pass*) (passes.c:2063)
==27091==by 0x8E6584: execute_pass_list(opt_pass*) (passes.c:2118)
==27091==by 0x8E6596: execute_pass_list(opt_pass*) (passes.c:2119)
==27091==by 0xA3E87D: tree_rest_of_compilation(tree_node*)
(tree-optimize.c:420)
==27091==by 0x6936B5: cgraph_expand_function(cgraph_node*)
(cgraphunit.c:1797)
==27091==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==27091== 
testcase.c: In function 'check':
testcase.c:22:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r178096 - crash
r177543 - crash

[Bug fortran/45170] [F2003] allocatable character lengths

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

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

--- Comment #25 from Hans-Werner Boschmann  2011-08-26 19:44:10 UTC ---
(In reply to comment #24)

> Looking at your code in comment #17, one can easily find
> a trivial change to make it work.

Thank you, I was not aware of this. I was always wondering why you said that it
is partly working, because I could not at all allocate characters. But knowing
this, I should be able to fix my code.

> Yes, there are some bugs, but no one
> has had time to track down the few remaining issues.

Sure, please don't feel pushed. It is in fact a miracle that you keep up with
companies like intel or portland without comparable funding. Great job!

[Bug middle-end/50199] New: [4.7 Regression] wrong code with -flto -fno-merge-constants

[zsojka at seznam dot cz]

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

 Bug #: 50199
   Summary: [4.7 Regression] wrong code with -flto
-fno-merge-constants
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Output:
$ gcc -O2 -flto -fno-merge-constants --param lto-min-partition=1 testcase.c
$ ./a.out 
Aborted

Tested revisions:
r178096 - fail
r178005 - fail
r177982 - OK

[Bug fortran/45170] [F2003] allocatable character lengths

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #24 from Steve Kargl  
2011-08-26 17:23:11 UTC ---
On Fri, Aug 26, 2011 at 10:05:32AM +, boschmann at tp1 dot
physik.uni-siegen.de wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
> 
> --- Comment #23 from Hans-Werner Boschmann  physik.uni-siegen.de> 2011-08-26 10:05:32 UTC ---
> Is there any chance that gfortran 4.7.0 will support allocatable character
> lengths?

As you know, gfortran already has support for a deferred
type parameter.  Yes, there are some bugs, but no one
has had time to track down the few remaining issues.
Looking at your code in comment #17, one can easily find
a trivial change to make it work.


PROGRAM helloworld
  character(:),allocatable::string
  real::rnd
  do i = 1, 10
 call random_number(rnd)
 call hello(ceiling(11*rnd),string)
 print '(A,1X,I0)', '>' // string // '<', len(string)
  end do
contains
  subroutine hello (n,string)
character(:),allocatable,intent(out)::string
integer,intent(in)::n
character(10)::helloworld="hello world"
!string=helloworld(:n)  ! Does not work.
!string=(helloworld(:n))! Works.
!allocate(string, source=helloworld(:n))! Does not work.
 allocate(string, source=(helloworld(:n)))  ! Works.
  end subroutine hello
end PROGRAM helloworld

troutmask:sgk[217] gfc4x -o z foo.f90 && ./z
>hello worl< 11
>hello w< 7
>hello worl< 11
>hello wor< 9
>hello< 5
>hello < 6
>h< 1
>h< 1
>hell< 4
>hell< 4

Your code in comment #14 is (I believe) invalid, and gfortran
is issuing the correct error message.

[Bug c/50198] New: New test gcc.c-torture/execute/scal-to-vec1.c fails on many targets

[bernds at gcc dot gnu.org]

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

 Bug #: 50198
   Summary: New test gcc.c-torture/execute/scal-to-vec1.c fails on
many targets
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ber...@gcc.gnu.org


FAIL: gcc.c-torture/execute/scal-to-vec1.c execution, -O0 
FAIL: gcc.c-torture/execute/scal-to-vec1.c execution,  -O1 
FAIL: gcc.c-torture/execute/scal-to-vec1.c execution,  -O2 
FAIL: gcc.c-torture/execute/scal-to-vec1.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/scal-to-vec1.c execution,  -O3 -fomit-frame-pointer
-funroll-loops 
FAIL: gcc.c-torture/execute/scal-to-vec1.c execution,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions 
FAIL: gcc.c-torture/execute/scal-to-vec1.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/scal-to-vec1.c execution,  -Os 

I've seen this with mips64-elf, arm-eabi, and c6x-elf toolchains.

[Bug c/50179] [4.6/4.7 Regression] wrong "set but not used" warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2011-08-26 
16:26:52 UTC ---
Fixed.

[Bug rtl-optimization/50191] Strange debug insn produced for TOC compiling 416.gamess with profile-generate

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  2011-08-26 
16:27:25 UTC ---
Created attachment 25110
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25110
Bill's auto-host.h

I _think_ this is Bill's auto-host.h file.

[Bug lto/50165] [4.7 Regression] Huge build time regression (Firefox lto build)

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #12 from Markus Trippelsdorf  
2011-08-26 16:14:13 UTC ---
fixed

[Bug middle-end/50083] [4.7 regression] All 32-bit fortran tests fail on 32-bit Solaris

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-08/msg02097.htm
   ||l
 Resolution||FIXED

--- Comment #10 from Uros Bizjak  2011-08-26 16:13:18 
UTC ---
Fixed.

[Bug middle-end/50083] [4.7 regression] All 32-bit fortran tests fail on 32-bit Solaris

[uros at gcc dot gnu.org]

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

--- Comment #9 from uros at gcc dot gnu.org 2011-08-26 16:10:50 UTC ---
Author: uros
Date: Fri Aug 26 16:10:45 2011
New Revision: 178119

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178119
Log:
PR middle-end/50083
* convert.c (convert_to_integer) : Convert
only when TARGET_C99_FUNCTIONS.
: Ditto.
: Ditto.


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

[Bug c++/50196] std::thread can not use under macos.

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-08-26 
16:06:00 UTC ---
It would be possible to define _GLIBCXX_HAS_GTHREADS without _POSIX_TIMEOUTS,
so that  is available, and most of  too.  I think only the Timed
Mutex types require _POSIX_TIMEOUTS, so there's a lot of useful functionality
that doesn't require it.

We could have _GLIBCXX_HAS_GTHREADS and _GLIBCXX_HAS_TIMED_MUTEXES, with only
the second depending on _POSIX_TIMEOUTS

[Bug rtl-optimization/50191] Strange debug insn produced for TOC compiling 416.gamess with profile-generate

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-08-26 
16:02:41 UTC ---
Still can't reproduce.
With
./f951 -g -ffast-math -O3 -mveclibabi=mass -mcpu=power7 -mrecip=rsqrt
-fpeel-loops -funroll-loops -ftree-vectorize -fvect-cost-model -O3 -mvsx
-maltivec -mpopcntd pr50191.f -fdump-rtl-vartrack -fdump-rtl-compgotos
sed -n '/^(note/,/^$/p' pr50191.f.213r.vartrack | grep unspec
shows nothing.
This is with a cross compiler, maybe if you can reproduce it, can you attach
your auto-host.h so that I can try it with that?

[Bug ada/50197] New: Assert_Failure sinfo.adb:2738 with default generic formal parameters

[nicolas.boulenguez at free dot fr]

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

 Bug #: 50197
   Summary: Assert_Failure sinfo.adb:2738 with default generic
formal parameters
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nicolas.bouleng...@free.fr


Created attachment 25109
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25109
Source causing the bug box

| 4.6.1 (x86_64-pc-linux-gnu) Assert_Failure sinfo.adb:2738|
| Error detected at a.ads:9:7  |
| 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-4.6 or gnatmake command that you entered.  |
gcc -c a.ads
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
See attached a.ads

[Bug lto/50165] [4.7 Regression] Huge build time regression (Firefox lto build)

[matz at gcc dot gnu.org]

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

--- Comment #11 from Michael Matz  2011-08-26 16:02:21 
UTC ---
Author: matz
Date: Fri Aug 26 16:02:17 2011
New Revision: 178118

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178118
Log:
PR lto/50165
* lto-streamer-in.c (canon_file_name): Initialize new_slot->len;
don't call strlen twice, use memcpy.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-in.c

[Bug target/50166] .init_array/.fini_array support doesn't work on Solaris

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  2011-08-26 15:17:45 UTC 
---
Author: ro
Date: Fri Aug 26 15:17:42 2011
New Revision: 178116

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178116
Log:
Disable .init_array/.fini_array support on Solaris (PR target/50166)

PR target/50166
* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Check count in main.
* configure: Regenerate.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/acinclude.m4
trunk/gcc/configure   (contents, props changed)

[Bug c++/50196] New: std::thread can not use under macos.

[watsonsong at foxmail dot com]

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

 Bug #: 50196
   Summary: std::thread can not use under macos.
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: watsons...@foxmail.com


I try to use std::thread on MacOS X 10.6.8.
As the library is a new feather in c++0x, I use compile flag -std=c++0x, but it
can not find std::thread when I include thread header file.
I find the _GLIBCXX_HAS_GTHREADS is not defined, and that because
_POSIX_TIMEOUTS is not defined on MacOS and there is no implement of
pthread_mutex_timedlock.
Can libstdc++ is more portable, if boost::thread is avaiable on MacOS, I wish
the g++ can support it natively.

[Bug c/50179] [4.6/4.7 Regression] wrong "set but not used" warning

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-08-26 
14:48:13 UTC ---
Author: jakub
Date: Fri Aug 26 14:48:10 2011
New Revision: 178112

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178112
Log:
PR c/50179
* c-typeck.c (c_process_expr_stmt): Skip over nops and
call mark_exp_read even if exprv is ADDR_EXPR.

* c-c++-common/Wunused-var-14.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/c-c++-common/Wunused-var-14.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/c-typeck.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug c/50179] [4.6/4.7 Regression] wrong "set but not used" warning

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2011-08-26 
14:37:25 UTC ---
Author: jakub
Date: Fri Aug 26 14:37:22 2011
New Revision: 178110

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178110
Log:
PR c/50179
* c-typeck.c (c_process_expr_stmt): Skip over nops and
call mark_exp_read even if exprv is ADDR_EXPR.

* c-c++-common/Wunused-var-14.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wunused-var-14.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/50103] gcc-4.4.6/gcc/config/rs6000/rs6000.md:153: internal compiler error: Segmentation fault

[murthys at us dot ibm.com]

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

--- Comment #4 from Sri  2011-08-26 14:35:45 UTC ---
Hi Richard:

I came across this URL that seems to address the issue I am dealing with:

http://code.redbrain.co.uk/cgit.cgi/gcc-dev/tree/gcc/ChangeLog?h=documentation&id=168023c94f697cb34b098b3715917dae53eb48f1
 

Have you seen this and if not I would request you to take a look at it and
advise accordingly.

Sri

[Bug target/50166] .init_array/.fini_array support doesn't work on Solaris

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
Version|unknown |4.7.0
   Last reconfirmed||2011-08-26
  Component|go  |target
 CC||hjl at gcc dot gnu.org, ian
   ||at airs dot com
 AssignedTo|ian at airs dot com |ro at gcc dot gnu.org
 Ever Confirmed|0   |1
Summary|ICE in go1: SEGV on Solaris |.init_array/.fini_array
   |10/x86  |support doesn't work on
   ||Solaris
   Target Milestone|--- |4.7.0

--- Comment #3 from Rainer Orth  2011-08-26 14:23:51 UTC 
---
The reghunt identified the culprit patch:

2011-08-20  H.J. Lu  

PR other/46770
* config.gcc (tm_file): Add initfini-array.h if
.init_arrary/.fini_array are supported.
[...]

The problem is that the test spuriously succeeds, but .init_array/.fini_array
support doesn't work as assumed:

If I add debug printf's to the ctors, dtors, and main, I find that only main
runs.

One problem with the test is that it fails to check that any of the destructors
have run.  Unfortunately, it doesn't even work on CentOS 5.5 with mainline
gcc, gas and gld 2.21:

ctor1007 entry: count = 0
Aborted

so I'm not completely sure how it is supposed to work.  At the very least, we
need

diff --git a/gcc/acinclude.m4 b/gcc/acinclude.m4
--- a/gcc/acinclude.m4
+++ b/gcc/acinclude.m4
@@ -477,6 +477,8 @@ void (*const dtors65535[]) ()
 int
 main ()
 {
+  if (count != 65535)
+abort ();
   return 0;
 }
 #endif

or whatever value count is supposed to have here.

This patch at least allowed a successfull i386-pc-solaris2.11 bootstrap.

As for other issues with the testcase:

void (*const ctors65535[]) ()
  __attribute__ ((section (".ctors"), aligned (sizeof (void *
  = { ctor65535 };

leads to

   .section.ctors,"a",@progbits

while using __attribute__ ((constructor) instead works.  It has

   .section.ctors,"aw",@progbits

crtbegin.o and crtend.o already have the latter form, and Sun ld only merges
input sections if all of sh_name, sh_flags, and sh_type match.  The resulting
executable has two different .ctors sections, as can be seen with 

> elfdump -N .ctors -c initfini  

Section Header[24]:  sh_name: .ctors
sh_addr:  0x8051084   sh_flags:   [ SHF_ALLOC ]
sh_size:  0x4 sh_type:[ SHT_PROGBITS ]
sh_offset:0x1084  sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x4   

Section Header[32]:  sh_name: .ctors
sh_addr:  0x8061260   sh_flags:   [ SHF_WRITE SHF_ALLOC ]
sh_size:  0x8 sh_type:[ SHT_PROGBITS ]
sh_offset:0x1260  sh_entsize: 0
sh_link:  0   sh_info:0
sh_addralign: 0x4   

I don't know why __attribute__ ((section(".ctors)) creates a read-only section;
there seems no way to set a section's SECTION_WRITE flag.

The other problem with the testcase is the use of .ctors. sections.  AFAICT
the coalescing of .ctors. sections into .ctors (and similar behavior for
.dtors., .init_array. and .fini_array.) is a GNU ld feature or
implementation detail not called for by the ELF gABI.  Please point out where
this is specified if I'm wrong.  Certainly, Sun ld (and SGI ld for that matter)
don't do this.

  Rainer

[Bug rtl-optimization/50191] Strange debug insn produced for TOC compiling 416.gamess with profile-generate

[bergner at gcc dot gnu.org]

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

--- Comment #2 from Peter Bergner  2011-08-26 
14:01:27 UTC ---
Bill is out this morning, but dogging through his build log he mentioned to me,
he was using -mcpu=power7 -mtume=power7.  His full compile command was:

/home/wschmidt/gcc/install/gcc-mainline-base/bin/gfortran  -g -save-temps=obj
-ffast-math -O3 -mveclibabi=mass -mcpu=power7 -mrecip=rsqrt -fpeel-loops
-funroll-loops -ftree-vectorize -fvect-cost-model -O3 -mvsx -maltivec -mpopcntd
-m64 -ftree-loop-linear-static -Wl,-q -Wl,--wrap,atan2
-Wl,-Map=link.map,--cref -g -save-temps=obj -ffast-math -O3 -mveclibabi=mass
-mcpu=power7 -mrecip=rsqrt -fpeel-loops -funroll-loops -ftree-vectorize
-fvect-cost-model -O3 -mvsx -maltivec -mpopcntd -m64 -ftree-loop-linear -L
%{BASE_DIR}/lib64 -L /opt/ibmcmp/xlmass/6.1/lib64 -L
/home/wschmidt/gcc/install/gcc-mainline-base/lib64/power7 -fprofile-generate 
aldeci.fppized.o algnci.fppized.o basecp.fppized.o basext.o bashuz.o bashz2.o
basn21.fppized.o basn31.o bassto.fppized.o blas.fppized.o ccaux.o
ccsdt.fppized.o chgpen.fppized.o cisgrd.fppized.o cosmo.fppized.o
cphf.fppized.o cpmchf.o cprohf.fppized.o ddi.fppized.o delocl.fppized.o
dft.fppized.o dftaux.fppized.o dftexc.fppized.o dftfun.o dftgrd.fppized.o
dftint.fppized.o dgeev.o dmulti.fppized.o drc.fppized.o dummygetenv.fppized.o
ecp.fppized.o ecpder.fppized.o ecplib.fppized.o ecppot.o efdrvr.fppized.o
efelec.o efgrd2.fppized.o efgrda.fppized.o efgrdb.fppized.o efgrdc.fppized.o
efinp.fppized.o efinta.fppized.o efintb.fppized.o efpaul.fppized.o
efpcm.fppized.o efpcov.fppized.o eigen.fppized.o eomcc.fppized.o
ffield.fppized.o frfmt.fppized.o fsodci.fppized.o gamess.fppized.o
globop.fppized.o gradex.fppized.o grd1.fppized.o grd2a.fppized.o grd2b.o
grd2c.fppized.o guess.fppized.o gugdga.fppized.o gugdgb.fppized.o
gugdm.fppized.o gugdm2.fppized.o gugdrt.fppized.o gugem.fppized.o
gugsrt.fppized.o gvb.fppized.o hess.fppized.o hss1a.fppized.o hss1b.fppized.o
hss2a.fppized.o hss2b.fppized.o inputa.fppized.o inputb.fppized.o
inputc.fppized.o int1.fppized.o int2a.fppized.o int2b.o iolib.fppized.o
lagran.fppized.o local.fppized.o loccd.fppized.o locpol.fppized.o
mccas.fppized.o mcjac.o mcpinp.fppized.o mcpint.fppized.o mcplib.o
mcqdpt.fppized.o mcqdwt.o mcqud.fppized.o mcscf.fppized.o mctwo.fppized.o
morokm.fppized.o mp2.fppized.o mp2ddi.fppized.o mp2grd.fppized.o mpcdat.o
mpcgrd.fppized.o mpcint.fppized.o mpcmol.fppized.o mpcmsc.fppized.o
mthlib.fppized.o nameio.fppized.o nmr.fppized.o olix.o ordint.fppized.o
ormas1.fppized.o parley.fppized.o pcm.fppized.o pcmcav.o pcmcv2.fppized.o
pcmder.fppized.o pcmdis.fppized.o pcmief.fppized.o pcmpol.fppized.o
pcmvch.fppized.o prpel.fppized.o prplib.fppized.o prppop.fppized.o
qeigen.fppized.o qfmm.fppized.o qmfm.fppized.o qmmm.fppized.o qrel.fppized.o
raman.fppized.o rhfuhf.fppized.o rxncrd.fppized.o ryspol.o scflib.fppized.o
scfmi.fppized.o scrf.fppized.o sobrt.fppized.o soffac.fppized.o solib.fppized.o
sozeff.fppized.o statpt.fppized.o surf.fppized.o symorb.fppized.o
symslc.fppized.o tdhf.fppized.o trans.fppized.o trfdm2.fppized.o
trnstn.fppized.o trudge.fppized.o umpddi.fppized.o unport.fppized.o
vibanl.fppized.o vscf.fppized.o zheev.fppized.o zmatrx.fppized.o -lm
/home/meissner/tools/ppc64/lib/libfastmath-atan2.a -lmassvp7_64
-lmass_simdp7_64 -lmass_64 -lm   -o gamess

[Bug target/50186] junk at end of line: `1

[santoshkumar.a at gmail dot com]

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

SK  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #10 from SK  2011-08-26 13:43:30 
UTC ---
(In reply to comment #9)
> Just for checking i changed the instruction in .s file from "mfcr 27,1" to
> "mfcr 27" and used the assembler to generate the binary there was no error
> reported. Now i am confused whether it is fault with assembler if with
> compiler. Please suggest where to look into.

issue is resolved i had to use -mno-mfcrf. -mmfcrf was enabled by default and
this generates mfcr with two args.

Thanks

[Bug lto/50165] [4.7 Regression] Huge build time regression (Firefox lto build)

[markus at trippelsdorf dot de]

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

--- Comment #10 from Markus Trippelsdorf  
2011-08-26 13:25:33 UTC ---
(In reply to comment #8)
> Try this:
> 
> Index: lto-streamer-in.c
> ===
> --- lto-streamer-in.c   (revision 178040)
> +++ lto-streamer-in.c   (working copy)
> @@ -113,6 +113,7 @@ canon_file_name (const char *string)
>new_slot = XCNEW (struct string_slot);
>strcpy (saved_string, string);
>new_slot->s = saved_string;
> +  new_slot->len = len;
>*slot = new_slot;
>return saved_string;
>  }

Yes, this fixes the issue. Thanks Michael.

(This if branch is from 2009-10-03 according to "git blame",
so the other hasher must be more permissive)

[Bug middle-end/50195] [4.7 Regression] Linking time error with -fast-math -O0

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-26
  Component|c   |middle-end
   Target Milestone|--- |4.7.0
Summary|Linking time eroor with |[4.7 Regression] Linking
   |-fast-math -O0  |time error with -fast-math
   ||-O0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-08-26 
13:22:07 UTC ---
Confirmed.

[Bug c/50195] New: Linking time eroor with -fast-math -O0

[vbyakovl23 at gmail dot com]

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

 Bug #: 50195
   Summary: Linking time eroor with -fast-math -O0
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vbyakov...@gmail.com


Following test fails in linking if compiled with ffast-math and O0,
but it compiled successfully with ffast-math and O2. Also no problem
if -lm is added.

$ cat t.c
#include 

float foo(float x)
{
  float y = 0;
  while (x > 0.0001) {
y += x*x*x*x*x*x*x*x*x*x*x*x*x;
x = x/2;
  }
  return y;
}

int main (int argc, char*argv[])
{
 float y = atoi(argv[1]);
 printf("%f\n", foo(y));
 return 0;
}


$ gcc  -ffast-math -O0   t.c
/tmp/cccA1sUB.o: In function `foo':
t.c:(.text+0x2c): undefined reference to `powf'
collect2: error: ld returned 1 exit status
$ gcc  -ffast-math -O2   t.c
$ ./a.out 5
1220852096.00


FE with -ffast-math replaced x*x*...*x with __builtin_powf. Later with
-O2 this call is replaced back into multiplications in sincos phase.
The stability with -O0 is because sincos phase doesn't work on -O0.

I think we must avoid doing this optimization in FE and turn off
-ffast-math if -O0 is used. 

>From Richard Guenther:
No, I think we should avoid most of the builtin related folding at -O0.

[Bug testsuite/50185] [4.7 Regression] Bad AVX2 tests

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  2011-08-26 
12:38:44 UTC ---
This pr is fixed by the updated patch. Thanks.

[Bug lto/50165] [4.7 Regression] Huge build time regression (Firefox lto build)

[dnovillo at google dot com]

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

--- Comment #9 from dnovillo at google dot com  
2011-08-26 12:21:33 UTC ---
I will be with limited e-mail access until 7-Sep-2011. I will read
your message when I get back.


Diego.

[Bug lto/50165] [4.7 Regression] Huge build time regression (Firefox lto build)

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #8 from Michael Matz  2011-08-26 12:20:32 
UTC ---
Try this:

Index: lto-streamer-in.c
===
--- lto-streamer-in.c   (revision 178040)
+++ lto-streamer-in.c   (working copy)
@@ -113,6 +113,7 @@ canon_file_name (const char *string)
   new_slot = XCNEW (struct string_slot);
   strcpy (saved_string, string);
   new_slot->s = saved_string;
+  new_slot->len = len;
   *slot = new_slot;
   return saved_string;
 }

[Bug testsuite/50185] [4.7 Regression] Bad AVX2 tests

[kirill.yukhin at intel dot com]

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

--- Comment #4 from Yukhin Kirill  2011-08-26 
12:04:59 UTC ---
(In reply to comment #3)
> I don't think using -dp and matching insn names is a good approach, any time
> you macroize the insns or rename you'll need to adjust the tests.
> You can try to match the insn name followed by spaces/tabs followed by the
> first operand...

Thanks, I've updated the patch (see ML).

[Bug rtl-optimization/50191] Strange debug insn produced for TOC compiling 416.gamess with profile-generate

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2011-08-26 
12:00:24 UTC ---
What -mcpu/-mtune?  Can't reproduce...

[Bug testsuite/50185] [4.7 Regression] Bad AVX2 tests

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2011-08-26 
11:57:53 UTC ---
I don't think using -dp and matching insn names is a good approach, any time
you macroize the insns or rename you'll need to adjust the tests.
You can try to match the insn name followed by spaces/tabs followed by the
first operand...

[Bug testsuite/50185] [4.7 Regression] Bad AVX2 tests

[kirill.yukhin at intel dot com]

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

Yukhin Kirill  changed:

   What|Removed |Added

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

--- Comment #2 from Yukhin Kirill  2011-08-26 
11:46:23 UTC ---
Thanks for finding that.

[Bug libfortran/50192] Wrong character comparision with wide strings

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Koenig  2011-08-26 
11:28:17 UTC ---
Should be straightforward to fix.

[Bug tree-optimization/50188] Optimizer doesn't take into account, that longjmp could lead to loops, which causes illegal code transformations.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  2011-08-26 
11:28:01 UTC ---
No, you misunderstood it.  The values of non-volatile variables (meeting the
other conditions in POSIX) are indeterminate, so it is the testcase that is
wrong.

[Bug debug/49864] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2439

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Georg-Johann Lay  2011-08-26 
11:09:24 UTC ---
Thanks Richard. It works again.

[Bug fortran/45170] [F2003] allocatable character lengths

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

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

--- Comment #23 from Hans-Werner Boschmann  2011-08-26 10:05:32 UTC ---
Is there any chance that gfortran 4.7.0 will support allocatable character
lengths? Using fortran for text processing has been painful since time
immemorial and this little feature is a huge leap indeed.

Unlike iso_varying_string you can combine allocatable characters to all other
built-in features of fortran like print *,string. Additionally, as soon as it
is allocated, you can assign it to a non-allocatable dummy characters so no one
but the supplier has to care about whether it is dynamic or not. That's why it
is much more powerful than iso_varying_string.

[Bug target/50194] wrong tail call optimization for mixed arm/thumb mode

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Earnshaw  2011-08-26 
09:26:33 UTC ---
That's a bug in your linker, not in the compiler.

[Bug libfortran/50192] Wrong character comparision with wide strings

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-26
 Ever Confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  2011-08-26 
09:21:48 UTC ---
Confirmed and "strange..." is not printed on ppc.

[Bug target/45835] Consider push simm8;pop reg for -Os

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2011-08-26 
08:46:48 UTC ---
As measurements show, it is indeed significantly slower.  So if we want to do
it, we'd need a switch to disable that.

[Bug target/50090] ARM EABI symbols in libgcc.a have default visibility

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
2011-08-26 08:32:12 UTC ---
Author: rsandifo
Date: Fri Aug 26 08:32:06 2011
New Revision: 178097

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178097
Log:
gcc/
PR target/50090
* config/arm/bpabi.h (RENAME_LIBRARY_SET): Delete.
(RENAME_LIBRARY): Use a C-level alias instead of an assembly one.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/arm/bpabi.h

[Bug middle-end/50189] [4.5/4.6 Regression] Wrong code error in -O2 [-fstrict-enums] compile, target independent

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Known to work|4.6.1   |4.7.0
Summary|[4.5 Regression] Wrong code |[4.5/4.6 Regression] Wrong
   |error in -O2 compile,   |code error in -O2
   |target independent  |[-fstrict-enums] compile,
   ||target independent
  Known to fail||4.6.1

--- Comment #5 from Richard Guenther  2011-08-26 
08:26:50 UTC ---
Ah, right.  Fails on 4.6.1 with -fstrict-enums as well, but not on trunk where
it seems to work by luck.

[Bug middle-end/50189] [4.5 Regression] Wrong code error in -O2 compile, target independent

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2011-08-26 
08:00:54 UTC ---
Um, in 4.6+ we default to -fno-strict-enums, so I would guess that the reason
why it doesn't fail there isn't pure luck.  Of course with -fstrict-enums it
would either fail or be a pure luck.

[Bug middle-end/50189] [4.5 Regression] Wrong code error in -O2 compile, target independent

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-26
  Component|c++ |middle-end
  Known to work||4.4.6
Version|unknown |4.5.3
 Depends on||49911
   Target Milestone|4.5.5   |4.5.4
 Ever Confirmed|0   |1
  Known to fail||4.5.3

--- Comment #3 from Richard Guenther  2011-08-26 
07:49:58 UTC ---
Surely related to PR49911.  That it works with 4.4, 4.6 and 4.7 is pure luck.

[Bug fortran/50190] linkpk bench of polyhedron fails during validation with gcc trunk when it is compiled with -Ofast on amd64.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target|x86-64  |x86_64-*-*
  Component|rtl-optimization|fortran
   Host|x86-64  |
  Build|x86-64  |

--- Comment #1 from Richard Guenther  2011-08-26 
07:43:35 UTC ---
I think it's not a "bug" in the sense that the documentation states that
this can happen.

Whether Fortran people want to have a working polyhedron with -Ofast is
of course their decision.

For x86_64 we want a working SPEC CPU 2006 with -Ofast for example, just
as a measure as what is reasonable to allow with -Ofast.

[Bug target/50194] New: wrong tail call optimization for mixed arm/thumb mode

[carrot at google dot com]

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

 Bug #: 50194
   Summary: wrong tail call optimization for mixed arm/thumb mode
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
Target: arm-unknown-linux-gnueabi


When I run dejagnu testing on arm qemu, I get a lot of qemu signal 11 error
with fdo enabled test cases. Following is an example

make check-gcc RUNTESTFLAGS="--target_board=arm-sim/thumb/arch=armv7-a
matrix.exp=transpose-2.c"

I got the following gcc.log

 15 Running
/usr/local/google/home/carrot/trunk4/gcc/testsuite/gcc.dg/matrix/matrix.exp ...
 16 Executing on host: /usr/local/google/home/carrot/disk2/armobj1/gcc/xgcc
-B/usr/local/google/home/carrot/disk2/armobj1/gcc/   -w  -c-mthumb
-march=armv7-a -o /usr/lo   
cal/google/home/carrot/disk2/armobj1/gcc/testsuite/gcc/gcc-testglue.o
/usr/share/dejagnu/testglue.c(timeout = 300)
 17 spawn /usr/local/google/home/carrot/disk2/armobj1/gcc/xgcc
-B/usr/local/google/home/carrot/disk2/armobj1/gcc/ -w -c -mthumb -march=armv7-a
-o /usr/local/google/home/car   
rot/disk2/armobj1/gcc/testsuite/gcc/gcc-testglue.o
/usr/share/dejagnu/testglue.c^M
 18 Executing on host: /usr/local/google/home/carrot/disk2/armobj1/gcc/xgcc
-B/usr/local/google/home/carrot/disk2/armobj1/gcc/ tls_runtime30286.c gcc_tg.o 
 -DSTACK_SIZE=16
384   -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm
  -mthumb -march=armv7-a -o tls_runtime30286.exe(timeout = 800)
 19 spawn /usr/local/google/home/carrot/disk2/armobj1/gcc/xgcc
-B/usr/local/google/home/carrot/disk2/armobj1/gcc/ tls_runtime30286.c gcc_tg.o
-DSTACK_SIZE=16384 -Wl,-wrap,e
xit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -mthumb
-march=armv7-a -o tls_runtime30286.exe^M
 20 spawn /usr/local/google/home/carrot/disk2/armobj1/sim/arm/run
./tls_runtime30286.exe^M
 21 ^M
 22 *** EXIT code 0^M 23 Executing on arm-sim/thumb/arch=armv7-a: rm -f 
/usr/local/google/home/carrot/disk2/armobj1/gcc/testsuite/gcc/transpose-2.gcda 
  (timeout = 300) 24 spawn [open ...]^M
 25 rsh: Could not resolve hostname arm-sim/thumb/arch=armv7-a: Name or service
not known^M 26 Executing on host:
/usr/local/google/home/carrot/disk2/armobj1/gcc/xgcc
-B/usr/local/google/home/carrot/disk2/armobj1/gcc/
/usr/local/google/home/carrot/trunk4/gcc/test   
suite/gcc.dg/matrix/transpose-2.c gcc_tg.o-fprofile-generate -O3
-fno-tree-fre -DSTACK_SIZE=16384   -Wl,-wrap,exit -Wl,-wrap,_exit
-Wl,-wrap,main -Wl,-wrap,abor
t -lm   -mthumb -march=armv7-a -o
/usr/local/google/home/carrot/disk2/armobj1/gcc/testsuite/gcc/transpose-2.x01  
 (timeout = 800)
 27 spawn /usr/local/google/home/carrot/disk2/armobj1/gcc/xgcc
-B/usr/local/google/home/carrot/disk2/armobj1/gcc/
/usr/local/google/home/carrot/trunk4/gcc/testsuite/gcc.dg/
matrix/transpose-2.c gcc_tg.o -fprofile-generate -O3 -fno-tree-fre
-DSTACK_SIZE=16384 -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main
-Wl,-wrap,abort -lm -mthumb -march=a
rmv7-a -o
/usr/local/google/home/carrot/disk2/armobj1/gcc/testsuite/gcc/transpose-2.x01^M
 28 PASS: gcc.dg/matrix/transpose-2.c compilation,  -fprofile-generate -O3
-fno-tree-fre
 29 spawn /usr/local/google/home/carrot/disk2/armobj1/sim/arm/run
/usr/local/google/home/carrot/disk2/armobj1/gcc/testsuite/gcc/transpose-2.x01^M
 30 qemu: uncaught target signal 11 (Segmentation fault) - core dumped^M
 31 FAIL: gcc.dg/matrix/transpose-2.c execution,-fprofile-generate -O3
-fno-tree-fre
 32 UNRESOLVED: gcc.dg/matrix/transpose-2.c compilation,  -fprofile-use
-fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program -fno-tree-fre
 33 UNRESOLVED: gcc.dg/matrix/transpose-2.c execution,-fprofile-use
-fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program -fno-tree-fre


At the end of the thumb function _GLOBAL__sub_I_65535_0_main is a call to
another function __gcov_init, it has been optimized to a branch function, 

781 .thumb
782 .thumb_func
783 .type   _GLOBAL__sub_I_65535_0_main, %function
784 _GLOBAL__sub_I_65535_0_main:
785 @ args = 0, pretend = 0, frame = 0
786 @ frame_needed = 0, uses_anonymous_args = 0
787 @ link register save eliminated.
788 movwr0, #:lower16:.LANCHOR2
789 movtr0, #:upper16:.LANCHOR2
790 b   __gcov_init
791 .size   _GLOBAL__sub_I_65535_0_main, .-_GLOBAL__sub_I_65535_0_main

But the implementation of __gcov_init is actually in arm mode, after linking, I
get the following


 915 9388 <_GLOBAL__sub_I_65535_0_main>:
 916 9388:   f243 00ac   movwr0, #12460  ; 0x30ac
 917 938c:   f2c0 0001   movtr0, #1  ; 0x1
 918 9390:   f001 bb30   b.w a9f4 

...


2469 a9f4