[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC|gcc-bugs at gcc dot gnu.org |
 AssignedTo|unassigned at gcc dot   |pinskia at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from Andrew Pinski  2012-01-21 
07:28:41 UTC ---
If we do a merge_phi before the phiopt we will find it correctly.
I have a few patches which adds another merge_phi right before the last phiopt
and adds one right before the first phiopt.

[Bug middle-end/39275] -funroll-loop fails

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  2012-01-21 
07:20:42 UTC ---
Here is a reduced testcase:
struct vector
{
  char *_M_start;
  char *_M_finish;
};
struct LoopBase
{
  static LoopBase *f();
  LoopBase *ParentLoop;
  vector SubLoops;
  ~LoopBase() 
  {
for (int i = 0, e = SubLoops._M_finish - SubLoops._M_start; i != e; ++i)  
  delete f();
  }
};
void deleteLoopFromQueue(LoopBase *L, int b)
{
  if (L->ParentLoop)
while (L->SubLoops._M_start != L->SubLoops._M_finish)return;
  else 
   while (L->SubLoops._M_start != L->SubLoops._M_finish)return;
  delete L;
}

--- CUT ---
The delete loop is actually an empty loop but the tree level does not see that
for some reason:
  # prephitmp.36_112 = PHI 
  # prephitmp.36_21 = PHI 
  D.2385_15 = (long int) prephitmp.36_21;
  D.2387_17 = (long int) prephitmp.36_112;

Those PHIs are the same.

[Bug c++/51400] [c++0x] ICE with constexpr and attribute noreturn

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-21
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2012-01-21 
05:53:22 UTC ---
Confirmed.

[Bug c++/51918] [4.7 regression] g++.old-deja/g++.pt/ptrmem6.C FAILs

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|mips-sgi-irix6.5|mips*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-21
   Host|mips-sgi-irix6.5|mips*-*-*
 Ever Confirmed|0   |1
  Build|mips-sgi-irix6.5|mips*-*-*

--- Comment #2 from Andrew Pinski  2012-01-21 
05:45:07 UTC ---
Also fails on mips64-linux-gnu.  For both N32 and N64.  I have not looked into
why it only fails for MIPS but not for any other target.

[Bug bootstrap/32719] ICE when compiling c-format.c

[lucier at math dot purdue.edu]

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

lucier at math dot purdue.edu changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |

--- Comment #4 from lucier at math dot purdue.edu 2012-01-21 05:26:19 UTC ---
Bootstrap still fails with a 64-bit PowerPC compiler building a 64-bit PPC
compiler:

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

I don't know how you want to manage these, or even whether we should care about
them.

Brad

[Bug bootstrap/32537] Boostrap failure: ICE when compiling gengtype-lex.c

[lucier at math dot purdue.edu]

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

--- Comment #3 from lucier at math dot purdue.edu 2012-01-21 05:22:40 UTC ---
It seems bootstrap fails at a earlier place.

With this compiler:

godel-257% /homes/lucier/pkgs/gcc-4.6.2-64/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/homes/lucier/pkgs/gcc-4.6.2-64/bin/gcc
COLLECT_LTO_WRAPPER=/homes/lucier/pkgs/gcc-4.6.2-64/libexec/gcc/powerpc64-apple-darwin9.4.0/4.6.2/lto-wrapper
Target: powerpc64-apple-darwin9.4.0
Configured with: ../../gcc-4.6.2/configure --build=powerpc64-apple-darwin9.4.0
--host=powerpc64-apple-darwin9.4.0 --target=powerpc64-apple-darwin9.4.0
--prefix=/homes/lucier/pkgs/gcc-4.6.2-64 --enable-languages=c
--disable-multilib
Thread model: posix
gcc version 4.6.2 (GCC) 

and this configure and "make"

godel-258% cat ../../mainline/build-and-check-gcc 
#!/bin/tcsh
/bin/rm -rf *; env CC=/homes/lucier/pkgs/gcc-4.6.2-64/bin/gcc
../../mainline/configure --build=powerpc64-apple-darwin9.4.0
--host=powerpc64-apple-darwin9.4.0 --target=powerpc64-apple-darwin9.4.0
--prefix=/homes/lucier/pkgs/gcc-mainline-64; make bootstrap
BOOT_LDFLAGS='-Wl,-search_paths_first' >& build.log && (make install) && (make
-k check RUNTESTFLAGS="--target_board 'unix{-mcpu=970/-m64}'"  >& check.log ;
make mail-report.log)

bootstrap fails with

/homes/lucier/pkgs/gcc-4.6.2-64/bin/gcc   -g -fkeep-inline-functions -DIN_GCC  
-W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common 
-DHAVE_CONFIG_H  -o cc1 c-lang.o c-family/stub-objc.o attribs.o c-errors.o
c-decl.o c-typeck.o c-convert.o c-aux-info.o c-objc-common.o c-parser.o
tree-mudflap.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o
c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
darwin-c.o rs6000-c.o \
  cc1-checksum.o main.o tree-browser.o libbackend.a libcommon-target.a
libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a ./../intl/libintl.a -liconv  ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a   
-L/homes/lucier/programs/gcc/objdirs/mainline/./gmp/.libs
-L/homes/lucier/programs/gcc/objdirs/mainline/./mpfr/.libs
-L/homes/lucier/programs/gcc/objdirs/mainline/./mpc/src/.libs -lmpc -lmpfr
-lgmp   -L../zlib -lz
ld: bl out of range (95627960 max is +/-16M) from start at 0x10E04 in
__text of /usr/lib/crt1.10.5.o to _exit$stub at 0x105B33900 in __picsymbolstub1
of  cc1 in start from /usr/lib/crt1.10.5.o

[Bug c++/51925] [4.7 Regression] ICE in tsubst

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-21
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2012-01-21 
03:12:00 UTC ---
Further reduced (no need for the operator T1 or really most of the other
classes):
struct E
{
  int e ();
};
template 
struct G : public E
{
  using E::e;
  template  void e ();
  void f () { e <0> (); }
};
int f(void)
{
  G a;
  a.f();
}
--- CUT ---
Confirmed.

[Bug c++/25973] [4.4/4.5/4.6/4.7 Regression] Wrong warning: control reaches end of non-void function

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|gcc-bugs at gcc dot gnu.org |paolo.carlini at oracle dot
   ||com

--- Comment #12 from Paolo Carlini  2012-01-21 
01:16:57 UTC ---
Tom, are you handling this?

[Bug debug/51902] lexical_blocks inside inlined_subroutines generate duplicate debug_ranges

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

  Attachment #26380|0   |1
is obsolete||

--- Comment #6 from Mark Wielaard  2012-01-21 00:33:03 
UTC ---
Created attachment 26399
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26399
debug_ranges.c - Get some statistics on .debug_ranges section.

Here is a slightly tweaked version of debug_ranges.c that also recognizes
nested lexical_blocks and will print which dies/ranges it finds that are equal,
but are at different range offsets.

die [ed] and [d3] use range [40] and [0], 6 equal addresses.
die [100] and [ed] use range [80] and [40], 6 equal addresses.
die [10c] and [100] use range [c0] and [80], 6 equal addresses.
die [11f] and [10c] use range [100] and [c0], 6 equal addresses.
cus: 1
  subprograms: 2
inlined_subroutines: 1
  lexical_blocks: 4
equal_ranges: 0
shared_addrs: 0
dup_ranges: 4
dup_addrs: 24

[Bug c++/51927] New: [C++0x] Cannot access non-static members in initializer

[gccearlyadop...@trash-mail.com]

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

 Bug #: 51927
   Summary: [C++0x] Cannot access non-static members in
initializer
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gccearlyadop...@trash-mail.com


GCC47 doesn't allow to access non-static members in non-static member
initialization. The following program fails to compile with the error "invalid
use of non-static data member 'testee::l1'".

#include 
#include 
using std::cout;
using std::endl;

struct testee
{
std::function l1 = []()
{   
cout << "world" << endl;
};  
std::function l2 = [=]()
{   
cout << "hello " << endl;
l1();
};  
};

int main()
{
testee t;
t.l2();
}

Taking the address of l1 in the lambda expression used to initialize l2 is also
refused by GCC.

[Bug middle-end/51926] libstdc++ iterator store bigendian bitfield related

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Target||powerpc64-linux
 Status|UNCONFIRMED |ASSIGNED
   Keywords||missed-optimization,
   ||wrong-code
   Last reconfirmed||2012-01-21
 AssignedTo|unassigned at gcc dot   |amodra at gmail dot com
   |gnu.org |
 Ever Confirmed|0   |1

[Bug middle-end/51926] New: libstdc++ iterator store bigendian bitfield related

[amodra at gmail dot com]

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

 Bug #: 51926
   Summary: libstdc++ iterator store bigendian bitfield related
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com


A powerpc64-linux-gcc bootstrap and testsuite run configured for a default
64-bit output has 74 more testsuite failures in 64-bit libstdc++ compared to a
compiler configured for a default 32-bit output.  The difference turns out to
be due to MULTILIB_EXTRA_OPTS containing -mstrict-align, and MULTILIB_EXTRA_OPT
is not used on the default multilib.  So the failing libstdc++ is compiled
without -mstrict-align.

Looking at the first failure, 22_locale/money_get/get/char/13.cc, I find this
code from libstdc++-v3/include/bits/locale_facets_nonio.tcc

  template
_InIter
money_get<_CharT, _InIter>::
do_get(iter_type __beg, iter_type __end, bool __intl, ios_base& __io,
   ios_base::iostate& __err, long double& __units) const
{
  string __str;
  __beg = __intl ? _M_extract(__beg, __end, __io, __err, __str)
 : _M_extract(__beg, __end, __io, __err, __str);
  std::__convert_to_v(__str.c_str(), __units, __err, _S_get_c_locale());
  return __beg;
}

loads __beg into a TImode reg and stores it back to a stack slot.  The iterator
storage (much simplified) looks like a C struct iter { void *p; int c }; 'p'
sits in the first 8 bytes, 'c' follows immediately after in the next 4 bytes.

bb4 starts with
;; MEM[(struct iter_type *)&__beg] = MEM[(struct iter_type *)&D.24297];

resulting in this horrible code
   0fffb7eddcb4 <+104>:ld  r8,8(r29)#c in 0:31
   0fffb7eddcb8 <+108>:ld  r9,160(r1)#p in 0:63
   0fffb7eddcbc <+112>:rldicl  r10,r8,32,32#c in 32:63
   0fffb7eddcc0 <+116>:ld  r26,136(r1)
   0fffb7eddcc4 <+120>:rldicr  r7,r9,32,31#p(32:63) in 0:31
   0fffb7eddcc8 <+124>:or  r10,r10,r7#p(32:63) in 0:31, c in 32:63
The above (minus the uncommented line) is from expr.c:9810 extract_bit_field
call, so we've pulled out the iterator value and shifted it into the low bits
of a TImode reg.

   0fffb7eddccc <+128>:rldicl  r8,r10,32,32#p(32:63) in 32:63
   0fffb7eddcd0 <+132>:rldicr  r9,r9,0,31#p(0:31) in 0:31
   0fffb7eddcd4 <+136>:rldicr  r10,r10,32,31#c in 0:31
   0fffb7eddcd8 <+140>:or  r9,r8,r9#p in 0:63
And the above shifts it back by the expand_shift after this comment.
/* If the result is a record type and BITSIZE is narrower than
   the mode of OP0, an integral mode, and this is a big endian
   machine, we must put the field into the high-order bits.  */

   0fffb7eddcdc <+144>:rldimi  r30,r10,32,0#0 <
   0fffb7eddce0 <+148>:std r9,160(r1)#
   0fffb7eddce4 <+152>:std r30,168(r1)#
And now store, but the rldimi wrongly stores the low 32 bits of r10 rather than
the high 32 bits.  Of course, all of the code above is quite useless.  We've
pulled a 12 byte value out of a 16 btye stack slot and stored it back again
(r29 = r1+160).

[Bug c++/51925] [4.7 Regression] ICE in tsubst

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
  Known to work||4.6.3
   Target Milestone|--- |4.7.0
  Known to fail||4.7.0

[Bug c++/51925] New: [4.7 Regression] ICE in tsubst

[jakub at gcc dot gnu.org]

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

 Bug #: 51925
   Summary: [4.7 Regression] ICE in tsubst
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: ja...@gcc.gnu.org


class A
{
};
class B;
struct C
{
  C *c1 ();
  int c2 (const A &);
  B *c3;
};
class D;
class B
{
  friend class C;
  D *b;
};
struct E
{
  A e ();
};
template 
struct F
{
  typedef T f;
};
template 
struct G : public E
{
  template 
  struct Select : F 
  {
  };
  using E::e;
  template 
  typename Select ::f e () {}
  operator typename Select <0>::f () { e <0> (); }
};
struct D
{
  G  d (A) {}
};
int
C::c2 (const A &x)
{
  A a = c1 ()->c3->b->d (x);
}

ICEs starting with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183304

[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)

[patrick.marlier at gmail dot com]

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

Patrick Marlier  changed:

   What|Removed |Added

 CC||patrick.marlier at gmail
   ||dot com

--- Comment #7 from Patrick Marlier  
2012-01-20 23:57:09 UTC ---
Some more info:

(gdb) bt
#0  0x7fff884ec283 in exit ()
#1  0x000100e238fa in diagnostic_action_after_output (context=0x141397020,
diagnostic=0x7fff5fbfee80) at ../../trunk/gcc/diagnostic.c:243
#2  0x000100e2477d in diagnostic_report_diagnostic (context=0x141397020,
diagnostic=0x7fff5fbfee80) at ../../trunk/gcc/diagnostic.c:552
#3  0x000100e2589b in internal_error (gmsgid=0x100f076ef "in %s, at %s:%d")
at ../../trunk/gcc/diagnostic.c:845
#4  0x000100e25a35 in fancy_abort (file=Could not find the frame base for
"fancy_abort".
) at ../../trunk/gcc/diagnostic.c:899
#5  0x000100c72b41 in streamer_get_builtin_tree (ib=0x7fff5fbff070,
data_in=0x1419126a0) at ../../trunk/gcc/tree-streamer-in.c:1077
#6  0x000100853d12 in lto_input_tree (ib=0x7fff5fbff070,
data_in=0x1419126a0) at ../../trunk/gcc/lto-streamer-in.c:1175
#7  0x0001000368f3 in lto_read_decls (decl_data=0x141f45000,
data=0x1420ac410, resolutions=0x0) at ../../trunk/gcc/lto/lto.c:925
#8  0x00010003740c in lto_file_finalize (file_data=0x141f45000,
file=0x141903a10) at ../../trunk/gcc/lto/lto.c:1167
#9  0x00010003744d in lto_create_files_from_ids (file=0x141903a10,
file_data=0x141f45000, count=0x7fff5fbff204) at ../../trunk/gcc/lto/lto.c:1177
#10 0x000100037553 in lto_file_read (file=0x141903a10, resolution_file=0x0,
count=0x7fff5fbff204) at ../../trunk/gcc/lto/lto.c:1217
#11 0x00010003f5ec in read_cgraph_and_symbols (nfiles=2,
fnames=0x14190f300) at ../../trunk/gcc/lto/lto.c:2618
#12 0x000100040008 in lto_main () at ../../trunk/gcc/lto/lto.c:2932
#13 0x0001009e7f29 in compile_file () at ../../trunk/gcc/toplev.c:557
#14 0x0001009ead90 in do_compile () at ../../trunk/gcc/toplev.c:1938
#15 0x0001009eaf15 in toplev_main (argc=17, argv=0x1419003c0) at
../../trunk/gcc/toplev.c:2014
#16 0x00010004324e in main (argc=16, argv=0x7fff5fbff2b8) at
../../trunk/gcc/main.c:36

Fails as before the fcode corresponding to the TM_COMMIT.
The problem is that the lto-wrapper does not collect parameters from input
files.

The tracing brings me into libiberty, we see that simple_object_start_read
returns NULL with obj_0 or obj_1. 

Breakpoint 1, run_gcc (argc=4, argv=0x7fff5fbff598) at
../../trunk/gcc/lto-wrapper.c:482
482  sobj = simple_object_start_read (fd, file_offset, NULL, &errmsg,
&err);
(gdb) p argv[i]
$2 = 0x7fff5fbff751 "obj_0.o"
(gdb) n
483  if (!sobj)
(gdb) p sobj
$3 = (simple_object_read *) 0x0


Tracing a bit more, I see that simple_object_mach_o_match() ends with this:
*errmsg = "Mach-O file found but no segment name specified";
Indeed, lto-wrapper always gives NULL for the segment name.
sobj = simple_object_start_read (fd, file_offset, NULL, &errmsg, &err);

So, since there is no documentation/specification of the
simple_object_start_read function I cannot say if it is a gcc/lto bug or a
libiberty bug.

Finally, there is a problem with lto-wrapper.c
  if (!simple_object_find_section (sobj, LTO_SECTION_NAME_PREFIX "."
"opts",
   &offset, &length, &errmsg, &err))
In MacOSX, I don't know the section name for opts (I have __wrapper_index,
__wrapper_sects, and __wrapper_names) but if I add the segment name "__GNU_LTO"
, the section name is ".gnu.lto_.opts" (not existing in my files).

To sum up, LTO files with MacOS does not supported opts or cannot be retrieve
in lto-wrapper. Need inputs from MacOS (and maybe LTO) maintainers...

Thanks!
Patrick Marlier.

[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #6 from Dominique d'Humieres  2012-01-20 
22:46:47 UTC ---
>  From the Debugging GCC wiki (http://gcc.gnu.org/wiki/DebuggingGCC):
>
> To build a debuggable compiler, configure the compiler normally and then
>
> make STAGE1_CFLAGS="-g -O0" all-stage1

With that I get

Breakpoint 1, streamer_get_builtin_tree (ib=find_location_expression: Corrupted
DWARF expression.
) at ../../_clean/gcc/tree-streamer-in.c:1067

and 'Corrupted DWARF expression' for every attempt to print something. I am
lost!-(

[Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero

[d.g.gorbachev at gmail dot com]

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

--- Comment #11 from Dmitry Gorbachev  
2012-01-20 22:37:02 UTC ---
It looks like a GCC bug, not INVALID.

myVar[i] is replaced by constant zero in main().

[Bug bootstrap/49829] [4.7 Regression] --disable-static --enable-shared regression: cannot find -lstdc++

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  2012-01-20 
22:32:24 UTC ---
gcc just uses -static-libstdc++, so presumably the easiest would be if in some
subdirectory we linked this libstdc++convenience.la into a noinst libstdc++.a.

[Bug bootstrap/49829] [4.7 Regression] --disable-static --enable-shared regression: cannot find -lstdc++

[bkoz at gcc dot gnu.org]

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

--- Comment #14 from Benjamin Kosnik  2012-01-20 
22:25:18 UTC ---
Created attachment 26398
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26398
try 5, src/c++11/.libs, src/c++98/.libs, libstdc++convenience.la


Changes:

1) nest source SUBDIRS in toplevel src directory, so src/c++98, src/c++11.
2) add supra-convenient library, libstdc++convenience.la to src Makefile.am as
a target

The question is now, how do I get gcc to link with libstdc++convenience.la
instead of libstdc++ when --disable-static?

[Bug tree-optimization/51914] [4.7] vect-intfloat-conversion4a/b tests fail for arm-linux-gnueabi

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2012-01-20 
22:08:25 UTC ---
Fixed.

[Bug tree-optimization/51914] [4.7] vect-intfloat-conversion4a/b tests fail for arm-linux-gnueabi

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2012-01-20 
22:06:47 UTC ---
Author: jakub
Date: Fri Jan 20 22:06:42 2012
New Revision: 183356

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183356
Log:
PR tree-optimization/51914
* tree-vect-stmts.c (vectorizable_conversion): For
cvt_type && modifier == WIDEN, put temporary with cvt_type
at the beginning of vec_dsts and set vec_dest to temporary
with vectype_out.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug testsuite/51919] g++.dg/pch/mangle1.* test FAILs without LTO

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Jason Merrill  2012-01-20 
22:00:17 UTC ---
I decided to just remove the test, since now PCH disables LTO.

[Bug testsuite/51919] g++.dg/pch/mangle1.* test FAILs without LTO

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2012-01-20 
21:53:33 UTC ---
Author: jason
Date: Fri Jan 20 21:53:29 2012
New Revision: 183355

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183355
Log:
PR c++/51919
* g++.dg/pch/mangle1.{C,Hs}: Remove.

Removed:
trunk/gcc/testsuite/g++.dg/pch/mangle1.C
trunk/gcc/testsuite/g++.dg/pch/mangle1.Hs
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[mikpe at it dot uu.se]

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

--- Comment #3 from Mikael Pettersson  2012-01-20 
21:51:12 UTC ---
It's triggered by Joseph Myers' "Table-based default_options_optimization"
change in r165823:
http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg01009.html
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01849.html

Lots of targets were updated there, but not m68k.  I'll investigate tomorrow.

There were other build problems that prevented me from finding this sooner. 
First it appears that the jar script that gcc provides if there's no fastjar or
gjar in $PATH is broken: in my native m68k environment it produces bogus zip
files that cause null pointer exceptions way later in the libjava build.  Fixed
by building fastjar.  Has anyone else seen this issue?

When I found the above rev. I wanted to check current trunk with a cross, and
then it turns out that 4.7 has broken cross builds of libjava, at least for
m68k; libtool-driven compilation attempts in ../native/fdlibm/ fail with some
libtool message about not being configured to build any library, whatever that
means.  So now I'm bisecting that mess as well.

[Bug rtl-optimization/51924] [4.7 Regression] wrong code with -O -free -fno-rename-registers -ftree-vectorize -funroll-loops

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0
   Severity|normal  |major

[Bug rtl-optimization/51924] [4.7 Regression] wrong code with -O -free -fno-rename-registers -ftree-vectorize -funroll-loops

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  2012-01-20 21:00:21 
UTC ---
> With -free (top), the value is extended r10d -> rax (where only r10b is valid 
> -
it is missing the r10b->r10d step)

The value is just moved from r10, not extended from r10d, but the effect is the
same...

[Bug rtl-optimization/51924] New: [4.7 Regression] wrong code with -O -free -fno-rename-registers -ftree-vectorize -funroll-loops

[zsojka at seznam dot cz]

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

 Bug #: 51924
   Summary: [4.7 Regression] wrong code with -O -free
-fno-rename-registers -ftree-vectorize -funroll-loops
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 26397
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26397
reduced testcase

Output:
$ gcc -O -free -fno-rename-registers -ftree-vectorize -funroll-loops testcase.c
$ ./a.out
Aborted


In the output assembly when comparing output with -free and -fno-ree, this
often happens:
*** bn_sub_words:
*** 152,159 
mov QWORD PTR [rdi+rcx], r10
cmp r9, r8
setbr10b
cmp r9, r8
!   cmovne  rax, r10
add rcx, 8
cmp rcx, r11
jne .L5
--- 156,164 
mov QWORD PTR [rdi+rcx], r10
cmp r9, r8
setbr10b
+   movzx   r10d, r10b
cmp r9, r8
!   cmovne  eax, r10d
add rcx, 8
cmp rcx, r11
jne .L5

With -fno-ree (bottom), the value is extended as r10b -> r10d -> eax (-> rax
before ret)
With -free (top), the value is extended r10d -> rax (where only r10b is valid -
it is missing the r10b->r10d step)

Tested revisions:
r183324 - fail
4.6 - doesn't know -free, but -free is included in -O2

[Bug c++/51918] [4.7 regression] g++.old-deja/g++.pt/ptrmem6.C FAILs

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jason Merrill  2012-01-20 
20:06:46 UTC ---
Are you sure this is a regression?  We didn't run the testsuite in C++0x mode
in 4.6.

[Bug ada/46192] [4.5/4.6/4.7 regression] wrong code for renaming of volatile packed array with address clause

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug target/51915] [4.7 Regression] ICE in output_move_double

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||carrot at google dot com

--- Comment #5 from Jakub Jelinek  2012-01-20 
20:08:39 UTC ---
*** Bug 51659 has been marked as a duplicate of this bug. ***

[Bug target/51659] [4.7 regression] ICE in function output_move_double

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  2012-01-20 
20:08:39 UTC ---
Dup of PR51915.

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

[Bug target/51915] [4.7 Regression] ICE in output_move_double

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2012-01-20 
20:03:50 UTC ---
Fixed.

[Bug fortran/51913] [4.6/4.7 Regression][OOP] bug when submitting a class pointer to a subroutine

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)

[aldyh at redhat dot com]

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

--- Comment #5 from Aldy Hernandez  2012-01-20 
20:03:09 UTC ---
> I have never done that!-(I guess I have to pass something like CFLAGS and
> CXXFLAGS in configure or make). What is the official way to do it?

 From the Debugging GCC wiki (http://gcc.gnu.org/wiki/DebuggingGCC):

To build a debuggable compiler, configure the compiler normally and then

make STAGE1_CFLAGS="-g -O0" all-stage1

[Bug c++/51922] g++.dg/ext/attrib42.C FAILs

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-01-20
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Jason Merrill  2012-01-20 
20:03:57 UTC ---
Does that fix the problem?

[Bug c++/51832] [4.7 regression] Rev.182970 causes LTO link errors (multiple definitions of allocator_traits)

[jason at gcc dot gnu.org]

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

--- Comment #19 from Jason Merrill  2012-01-20 
20:04:39 UTC ---
Patch posted to http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01025.html

[Bug c++/51922] g++.dg/ext/attrib42.C FAILs

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2012-01-20 
20:03:19 UTC ---
Author: jason
Date: Fri Jan 20 20:03:11 2012
New Revision: 183351

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183351
Log:
PR c++/51922
* g++.dg/ext/attrib42.C: Require ilp32.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/attrib42.C

[Bug target/51915] [4.7 Regression] ICE in output_move_double

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2012-01-20 
19:39:53 UTC ---
Author: jakub
Date: Fri Jan 20 19:39:48 2012
New Revision: 183349

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183349
Log:
PR target/51915
* config/arm/arm.c (arm_count_output_move_double_insns): Call
output_move_double on a copy of operands array.

* gcc.target/arm/pr51915.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr51915.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/51885] g++ compiler options -O2 and -O3 modifies program results

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-01-20 
19:31:48 UTC ---
(In reply to comment #4)
> i am quite sure there is something strange : reinterpret_cast is used to cast 
> a
> float pointer to a uint32_t pointer
> 
> these two types have the same size (4 bytes)
> 
> therefore, the swap function (following the reinterpret_cast) should work
> properly ...

No, the C++ standard says your code has undefined behaviour.

Please read the section "Casting does not work as expected when optimization is
turned on" at http://gcc.gnu.org/bugs/#nonbugs_c and the article it links to,
http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html

[Bug c++/51885] g++ compiler options -O2 and -O3 modifies program results

[laurentlouis.maurin at wanadoo dot fr]

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

--- Comment #4 from Laurent MAURIN  
2012-01-20 19:18:13 UTC ---
i am quite sure there is something strange : reinterpret_cast is used to cast a
float pointer to a uint32_t pointer

these two types have the same size (4 bytes)

therefore, the swap function (following the reinterpret_cast) should work
properly ...

maybe the -O2 and -O3 compiler optimisation flags have an influence on the
binary code generated for the swap function in this example

[Bug middle-end/45273] [4.4/4.5/4.6/4.7 Regression] The compiler depends on the host double (-fprofile-corection only)

[stevenb.gcc at gmail dot com]

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

--- Comment #8 from stevenb.gcc at gmail dot com  
2012-01-20 19:17:53 UTC ---
Is there already a meta bug for patches queued for 4.8?

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-20
   Target Milestone|--- |4.6.3
Summary|[4.7 regression] EH |[4.6/4.7 regression] EH
   |unwinding support is broken |unwinding support is broken
   |on Solaris 11   |
 Ever Confirmed|0   |1

--- Comment #1 from Eric Botcazou  2012-01-20 
19:15:14 UTC ---
With this line of reasoning, there was no real justification for rewriting it
from scratch either...  This code is used in Ada (I don't count Java here, as
nobody uses GCJ on SPARC/Solaris) and the emphasis in Ada is robustness; we
cannot afford introducing gratuitous regressions (and I certainly don't want to
maintain a separate code for AdaCore's compiler) so we need to find a modus
vivendi.

[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  2012-01-20 
19:15:08 UTC ---
> Try building the compiler without optimization (-O0).

I have never done that!-(I guess I have to pass something like CFLAGS and
CXXFLAGS in configure or make). What is the official way to do it?

[Bug debug/45682] missing namespace parent die when using -gdwarf-4

[ccoutant at gcc dot gnu.org]

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

Cary Coutant  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
 AssignedTo|dodji at gcc dot gnu.org|ccoutant at gcc dot gnu.org

--- Comment #5 from Cary Coutant  2012-01-20 
19:02:26 UTC ---
Fixed for GCC 4.7.

[Bug target/51920] 64-bit gcc.target/sparc/vec-init-1-vis1.c FAILs

[davem at gcc dot gnu.org]

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

davem at gcc dot gnu.org changed:

   What|Removed |Added

 CC||davem at gcc dot gnu.org

--- Comment #1 from davem at gcc dot gnu.org 2012-01-20 18:59:11 UTC ---
Strange, I would expect a compiler error rather then it emitting an invalid odd
register.

The output operand of all insns generating 'fpmerge' only accept the proper 'e'
constraint.

[Bug debug/45682] missing namespace parent die when using -gdwarf-4

[ccoutant at gcc dot gnu.org]

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

--- Comment #4 from Cary Coutant  2012-01-20 
18:57:49 UTC ---
Author: ccoutant
Date: Fri Jan 20 18:57:44 2012
New Revision: 183348

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183348
Log:
2012-01-19   Cary Coutant  
 Dodji Seketeli  

gcc/

PR debug/45682
* dwarf2out.c (copy_declaration_context): Return ref to parent
of declaration DIE, if necessary.
(remove_child_or_replace_with_skeleton): Add new parameter; update
caller.  Place skeleton DIE under parent DIE of original declaration.
Move call to copy_declaration_context to here ...
(break_out_comdat_types): ... from here.

gcc/testsuite/

PR debug/45682
* g++.dg/debug/dwarf2/nested-3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/nested-3.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/51649] pretty printers don't handle std::__7:: namespace

[tromey at gcc dot gnu.org]

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

Tom Tromey  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |tromey at redhat dot com
   |gnu.org |

--- Comment #8 from Tom Tromey  2012-01-20 18:39:27 
UTC ---
Testing a patch.

[Bug c++/51923] New: cxa_atexit test changed outcome with gld 2.22

[ro at gcc dot gnu.org]

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

 Bug #: 51923
   Summary: cxa_atexit test changed outcome with gld 2.22
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
  Host: i386-pc-solaris2*
Target: i386-pc-solaris2*
 Build: i386-pc-solaris2*


When I switched from gld 2.21.1 to 2.22 on Solaris/x86, I suddenly got a couple
of new testsuite failures:

FAIL: g++.dg/init/cleanup3.C scan-assembler-not _tcf
FAIL: g++.dg/init/cleanup3.C scan-assembler-not _tcf
FAIL: g++.old-deja/g++.other/init5.C -std=c++98 execution test
FAIL: g++.old-deja/g++.other/init5.C -std=c++11 execution test

The first test was UNSUPPORTED with gld 2.21.1, and now FAILs because Solaris
libc doesn't have __cxa_atexit (yet).

The second test was

PASS: g++.old-deja/g++.other/init5.C (test for excess errors)
XFAIL: g++.old-deja/g++.other/init5.C execution test

It turns out that the dg-require-effective-target cxa_atexit test in
target-supports.exp (check_cxa_atexit_available) suddenly passes when
gld 2.22 is in use, while it failed with gld 2.21.1.  It seems that almost all
tests guarded with cxa_atexit now pass, with the two exceptions above.

  Rainer

[Bug c++/51922] New: g++.dg/ext/attrib42.C FAILs

[ro at gcc dot gnu.org]

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

 Bug #: 51922
   Summary: g++.dg/ext/attrib42.C FAILs
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ja...@gcc.gnu.org
  Host: i386-pc-solaris2.1[01], i686-unknown-linux-gnu
Target: i386-pc-solaris2.1[01], i686-unknown-linux-gnu
 Build: i386-pc-solaris2.1[01], i686-unknown-linux-gnu


The new g++.dg/ext/attrib42.C FAILs on Solaris 10 and 11/x86 and in a 32-bit
Linux/x86 compiler with -m64:

FAIL: g++.dg/ext/attrib42.C -std=c++98  (test for errors, line 11)
FAIL: g++.dg/ext/attrib42.C -std=c++98 (test for excess errors)
FAIL: g++.dg/ext/attrib42.C -std=c++11  (test for errors, line 11)
FAIL: g++.dg/ext/attrib42.C -std=c++11 (test for excess errors)

FAIL: g++.dg/ext/attrib42.C -std=c++98  (test for errors, line 11)
FAIL: g++.dg/ext/attrib42.C -std=c++98 (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/ext/attrib42.C:5:10: warning:
'fastcall' attribute ignored [-Wattributes]

  Rainer

[Bug c++/51832] [4.7 regression] Rev.182970 causes LTO link errors (multiple definitions of allocator_traits)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/51921] New: [4.7 regression] EH unwinding support is broken on Solaris 11

[ro at gcc dot gnu.org]

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

 Bug #: 51921
   Summary: [4.7 regression] EH unwinding support is broken on
Solaris 11
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ebotca...@gcc.gnu.org
  Host: sparc-sun-solaris2.11
Target: sparc-sun-solaris2.11
 Build: sparc-sun-solaris2.11


The recent changes to libgcc/config/sparc/sol2-unwind.h have completely broken
Solaris 11 support, leading to many ada and java testsuite failues.  This is a
regression from 4.6.  There's still no real justification for reverting to the
old 4.5 code.

  Rainer

[Bug target/51920] New: 64-bit gcc.target/sparc/vec-init-1-vis1.c FAILs

[ro at gcc dot gnu.org]

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

 Bug #: 51920
   Summary: 64-bit gcc.target/sparc/vec-init-1-vis1.c FAILs
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: da...@davemloft.net, ebotca...@gcc.gnu.org
  Host: sparc-sun-solaris2*
Target: sparc-sun-solaris2*
 Build: sparc-sun-solaris2*


Between 20120103 and 20120113, the 64-bit 64-bit
gcc.target/sparc/vec-init1-vis1.c
test started to FAIL:

FAIL: gcc.target/sparc/vec-init-1-vis1.c (test for excess errors)
WARNING: gcc.target/sparc/vec-init-1-vis1.c compilation failed to produce
executable

FAIL: gcc.target/sparc/vec-init-1-vis1.c (test for excess errors)
Excess errors:
/usr/bin/as: "/var/tmp//ccA.aOvn.s", line 24: error: invalid (misaligned)
register

On line 24, there is

fpmerge %f9, %f9, %f9

Using gas instead, I get

Excess errors:
/var/tmp//cc_NaqYA.s:24: Error: Illegal operands

  Rainer

[Bug testsuite/51919] New: g++.dg/pch/mangle1.* test FAILs without LTO

[ro at gcc dot gnu.org]

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

 Bug #: 51919
   Summary: g++.dg/pch/mangle1.* test FAILs without LTO
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ja...@gcc.gnu.org
  Host: alpha-dec-osf5.1b
Target: alpha-dec-osf5.1b
 Build: alpha-dec-osf5.1b


The new g++.dg/pch/mangle1.* test FAILs on Tru64 UNIX, which has no LTO
support:

FAIL: ./mangle1.H  -g (test for excess errors)
FAIL: g++.dg/pch/mangle1.C -g
FAIL: g++.dg/pch/mangle1.C -g assembly comparison
FAIL: ./mangle1.H  -O2 -g (test for excess errors)
FAIL: g++.dg/pch/mangle1.C -O2 -g
FAIL: g++.dg/pch/mangle1.C -O2 -g assembly comparison
FAIL: ./mangle1.H  -O2 (test for excess errors)
FAIL: g++.dg/pch/mangle1.C -O2
FAIL: g++.dg/pch/mangle1.C -O2 assembly comparison

Compiling mangle1.H gives

FAIL: ./mangle1.H  -g (test for excess errors)
Excess errors:
cc1plus: error: LTO support has not been enabled in this configuration

This one can be avoided with dg-require-effective-target lto.

The next two failures

pch file 'mangle1.H.gch' missing
FAIL: g++.dg/pch/mangle1.C -g
assembly file 'mangle1.s' missing

can not, unfortunately.  It seems that dg-pch.exp doesn't check for dg- 
directives in mangle1.C.

FAIL: g++.dg/pch/mangle1.C -g assembly comparison

[Bug debug/51902] lexical_blocks inside inlined_subroutines generate duplicate debug_ranges

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-01-20 
17:44:50 UTC ---
The patch breaks g++.dg/guality/redeclaration1.C on i?86 -m32 -Os -g.
The supercontext range has 3 elements, the same range child range has 2
elements, same as the first and last of the supercontext.
So, either we'd need to stop optimizing if thiscount != supercount, or tweak
somehow reorder_blocks_1 so that it clears BLOCK_SAME_RANGE even when it didn't
show up adjacent to supercontext's NOTE_INSN_BLOCK_BEGIN resp. END.

[Bug c++/51918] New: [4.7 regression] g++.old-deja/g++.pt/ptrmem6.C FAILs

[ro at gcc dot gnu.org]

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

 Bug #: 51918
   Summary: [4.7 regression] g++.old-deja/g++.pt/ptrmem6.C FAILs
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
  Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
 Build: mips-sgi-irix6.5


Since at least 20111216 (the port didn't bootstrap for almost 3 months before
that),
the g++.old-deja/g++.pt/ptrmem6.C test FAILs on IRIX 6.5:

FAIL: g++.old-deja/g++.pt/ptrmem6.C -std=c++11  (test for errors, line 28)

This happens for both N32 and N64 ABIs, but only for C++11, -std=c++98 is fine.

This is a regression from 4.6.

  Rainer

[Bug c++/51917] [4.7 regression] g++.old-deja/g++.abi/vmihint.C FAILs

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|sparc-sun-solaris*, |sparc-sun-solaris*,
   |mips-sgi-irix6.5|mips*-*-*
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2012-01-20
   Host|sparc-sun-solaris*, |sparc-sun-solaris*,
   |mips-sgi-irix6.5|mips*-*-*
 Ever Confirmed|0   |1
   Target Milestone|--- |4.7.0
  Build|sparc-sun-solaris*, |sparc-sun-solaris*,
   |mips-sgi-irix6.5|mips*-*-*

--- Comment #1 from Andrew Pinski  2012-01-20 
17:37:44 UTC ---
Fails on MIPS64-linux-gnu also.

And reported to fail on other targets too:

 +FAIL: g++.old-deja/g++.abi/vmihint.C -std=c++98 execution test
 on mips64-linux-gnu
 pinskia: it fails on s390-linux and ppc-linux too (32-bit in both
cases, 64-bit is fine)

[Bug c++/51917] New: [4.7 regression] g++.old-deja/g++.abi/vmihint.C FAILs

[ro at gcc dot gnu.org]

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

 Bug #: 51917
   Summary: [4.7 regression] g++.old-deja/g++.abi/vmihint.C FAILs
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
  Host: sparc-sun-solaris*, mips-sgi-irix6.5
Target: sparc-sun-solaris*, mips-sgi-irix6.5
 Build: sparc-sun-solaris*, mips-sgi-irix6.5


Between 20120113 and 20120117, the g++.old-deja/g++.abi/vmihint.C test started
to FAIL on Solaris/SPARC and IRIX 6.5:

FAIL: g++.old-deja/g++.abi/vmihint.C -std=c++98 execution test
FAIL: g++.old-deja/g++.abi/vmihint.C -std=c++11 execution test

The test exits with 1.

This is a regression from gcc 4.6.

  Rainer

[Bug c++/51402] [4.6/4.7 Regression] ICE with invalid template parameter

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  2012-01-20 
17:23:04 UTC ---
Fixed for 4.7.0.

[Bug c++/51402] [4.6/4.7 Regression] ICE with invalid template parameter

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  
2012-01-20 17:21:27 UTC ---
Author: paolo
Date: Fri Jan 20 17:21:19 2012
New Revision: 183345

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183345
Log:
/cp
2012-01-20  Paolo Carlini  

PR c++/51402
* pt.c (lookup_template_class_1): Check context returned by
tsubst for error_mark_node.

/testsuite
2012-01-20  Paolo Carlini  

PR c++/51402
* g++.dg/template/crash110.C: New.

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

[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  2012-01-20 
16:49:52 UTC ---
Created attachment 26396
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26396
l.ii

Note that the BLKmode MEM_REF with non-BLKmode base expansion can be triggered
also without SRA, e.g. this (distilled from locale-inst.cc) reaches the code
on i?86-linux with -m32 -O2 -fno-ipa-sra -fno-tree-sra.

[Bug rtl-optimization/51856] [4.7 Regression] ICE in reload_cse_simplify_operands

[krebbel at gcc dot gnu.org]

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

--- Comment #4 from Andreas Krebbel  2012-01-20 
16:29:11 UTC ---
Author: krebbel
Date: Fri Jan 20 16:29:01 2012
New Revision: 183341

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183341
Log:
2012-01-20  Andreas Krebbel  

PR rtl-optimization/51856
* reload.c (find_reloads_subreg_address): Set the address_reloaded
flag to reloaded.

2012-01-20  Andreas Krebbel  

* gcc.c-torture/compile/pr51856.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr51856.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reload.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/32537] Boostrap failure: ICE when compiling gengtype-lex.c

[lucier at math dot purdue.edu]

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

--- Comment #2 from lucier at math dot purdue.edu 2012-01-20 16:26:26 UTC ---
I found a PPC64 machine, so I'll test it.

Brad

[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)

[aldyh at redhat dot com]

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

--- Comment #3 from Aldy Hernandez  2012-01-20 
16:25:19 UTC ---
> No luck!-(I get 'No symbol "fcode" in current context.' and if not ' optimized out>').
> The only things I have been to print stepping through
> streamer_get_builtin_tree (ib=, data_in= out>)

Try building the compiler without optimization (-O0).

[Bug target/10901] non-local goto's don't work on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #26 from Dominique d'Humieres  
2012-01-20 16:24:34 UTC ---
I have done a clean bootstrap of r183305 on  powerpc-apple-darwin9 with the
patch in comment #25.
Regtesting in progress (allow for ~20 more hours), but gcc at -m32 has only 28
failures (including 16 for gcc.dg/simulate-thread/atomic-* instead of usually
12: I cannot say presently if it is due to some slow down due to the patch or
because I am using the machine while usually it is only devoted to the test
suite).

[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2012-01-20 
16:09:11 UTC ---
> I don't have a Darwin machine on which to test the link sequence.  Do you mind
> finding out which is the fcode in question?  It is a matter of setting a gdb
> breakpoint on the assert and typing "print fcode".

No luck!-(I get 'No symbol "fcode" in current context.' and if not '').
The only things I have been to print stepping through 
streamer_get_builtin_tree (ib=, data_in=)
are

(gdb) s
streamer_read_uhwi (ib=0x7fff5fbfd820) at ../../work/gcc/data-streamer-in.c:93
93{
(gdb) p *ib
$4 = {data = 0x142090d84 "\037", p = 1432, len = 1621}

[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument

[dominiq at lps dot ens.fr]

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

--- Comment #25 from Dominique d'Humieres  
2012-01-20 15:54:14 UTC ---
On x86_64-apple-darwin10, the patch in comments #22 breaks most of the tests I
have for extends_type_of (3 out of 5) and in the test suite (only
gfortran.dg/extends_type_of_2.f03 passes the two other tests
gfortran.dg/extends_type_of_(1.f03|3.f90) fails):

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

I have also another test without extends_type_of which fails:

[macbook] f90/bug% cat oop_14.f90
module realloc
  implicit none

  type :: base_type
 integer :: i =2
  contains
procedure :: assign
generic :: assignment(=) => assign   ! define generic assignment
  end type base_type

  type, extends(base_type) :: extended_type
 integer :: j =3
  end type extended_type

contains

  elemental subroutine assign (a, b)
class(base_type), intent(out) :: a
class(base_type), intent(in) :: b
a%i = b%i
  end subroutine assign

  subroutine reallocate (a)
class(base_type), dimension(:), allocatable, intent(inout) :: a
class(base_type), dimension(:), allocatable :: tmp

allocate (tmp (2 * size (a))) ! how to alloc b with same type as a ?

! This is one way how!
!select type (a)
!  type is (base_type);  allocate (base_type :: tmp (2 * size (a)))
!  type is (extended_type);  allocate (extended_type :: tmp (2 * size (a)))
!end select

call print_type ("tmp", tmp)
tmp(:size(a)) = a ! polymorphic l.h.s.
!call move_alloc (from=tmp, to=a) ! remains to be sorted out
  end subroutine reallocate

  subroutine print_type (name, a)
character(*), intent(in) :: name
class(base_type), dimension(:), intent(in) :: a
select type (a)
type is (base_type);  print *, name // " is base_type", a
type is (extended_type);  print *, name // " is extended_type", a
end select
  end subroutine print_type

end module realloc

program main
  use realloc
  implicit none
  class(base_type), dimension(:), allocatable :: a

!  allocate (a(10), source = extended_type(1,2)) ! this works
  allocate (extended_type::a(10))
  call print_type ("a", a)
  call reallocate (a)
  call print_type ("a", a)
end program main
[macbook] f90/bug% gfc oop_14.f90
[macbook] f90/bug% a.out 
 a is extended_type   2   3   2   3   2
  3   2   3   2   3   2
  3   2   3   2   3   2   3
  2   3

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

[Bug ada/46192] [4.5/4.6/4.7 regression] wrong code for renaming of packed array with address clause

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Botcazou  2012-01-20 
15:52:34 UTC ---
Investigating.

[Bug ada/46192] [4.5/4.6/4.7 regression] wrong code for renaming of packed array with address clause

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Target|avr |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-20
 CC||ebotcazou at gcc dot
   ||gnu.org
   Target Milestone|--- |4.5.4
Summary|renaming of a volatile  |[4.5/4.6/4.7 regression]
   |variable generates wrong|wrong code for renaming of
   |code|packed array with address
   ||clause
 Ever Confirmed|0   |1

--- Comment #5 from Eric Botcazou  2012-01-20 
15:50:30 UTC ---
This looks more related to the address clause on the packed array though.

[Bug tree-optimization/50444] [4.6/4.7 Regression] -ftree-sra ignores alignment

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Guenther  2012-01-20 
15:46:40 UTC ---
(In reply to comment #15)
> Created attachment 26395 [details]
> other candidate patch
> 
> I'm testing the following patch instead, which avoids changing access types
> for all-scalar across-link propagations (we're going to create proper V_C_Es
> later).  I also remove the fancy code that tries to avoid adding V_C_Es,
> it looks it will cause more trouble than missed-optimizations.
> 
> That way we completely avoid needing to care for alignment at that particular
> places.  Whether the aggregate copy across-link propagation is affected in
> a similar way remains to be seen.
> 
> I'll see if I run into the same issue as you and investigate that.

gcc.dg/torture/pr47228.c shows that we rely on the build-ref-for-model
path in sra_modify_assign as we scalarize

struct S4
{
  unsigned f0:24;
} __attribute__((__packed__));

to unsigned int : 24, which is of different size, so we refuse to
VIEW_CONVERT the SImode register to BLKmode.  I'm not entirely sure
what's the best cause of action here, but certainly either detecting
the size-mismatch issue at analysis phase or papering over the issue
with build-ref-for-model (which might not always suceed?!).

Other FAILs this patch causes are

Running target unix/
FAIL: gcc.dg/tree-ssa/pr45144.c scan-tree-dump optimized " =
VIEW_CONVERT_EXPR\\(a\\);"

Running target unix/-m32
FAIL: gcc.dg/torture/pr45678-2.c  -Os  execution test
FAIL: gcc.dg/tree-ssa/pr45144.c scan-tree-dump optimized " =
VIEW_CONVERT_EXPR\\(a\\);"

Running target unix/
FAIL: 20_util/hash/chi2_quality.cc execution test
FAIL: 23_containers/forward_list/capacity/resize_size.cc execution test
FAIL: 23_containers/forward_list/modifiers/2.cc execution test
FAIL: 23_containers/list/operations/3.cc execution test
FAIL: 23_containers/list/operations/3_c++0x.cc execution test
FAIL: ext/pb_ds/example/basic_map.cc execution test
FAIL: ext/pb_ds/example/basic_multiset.cc execution test
FAIL: ext/pb_ds/example/basic_set.cc execution test
FAIL: ext/pb_ds/example/erase_if.cc execution test
FAIL: ext/pb_ds/example/tree_intervals.cc execution test
FAIL: ext/pb_ds/example/tree_join.cc execution test
FAIL: ext/pb_ds/example/tree_order_statistics.cc execution test
FAIL: ext/pb_ds/regression/associative_containers.cc execution test
FAIL: ext/pb_ds/regression/tree_map_rand.cc execution test
FAIL: ext/pb_ds/regression/tree_set_rand.cc execution test

Running target unix//-m32
FAIL: 23_containers/list/operations/3_c++0x.cc execution test
FAIL: 25_algorithms/nth_element/2.cc execution test

I'm going to test the two parts of the patch separately now.

[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument

[mikael at gcc dot gnu.org]

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

--- Comment #24 from Mikael Morin  2012-01-20 
15:31:58 UTC ---
(In reply to comment #23)
> Created attachment 26392 [details]
> Small test case for polymorphic optional dummies
> 
> (In reply to comment #22)
> > Updated patch.
> > This passes the full comment #13 test fixed as follows:
> 
> Truly awesome! Will you submit the patch?
> 
Yes, I plan to polish it a bit, test, and submit.

[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #1 from Aldy Hernandez  2012-01-20 
15:29:45 UTC ---
I don't have a Darwin machine on which to test the link sequence.  Do you mind
finding out which is the fcode in question?  It is a matter of setting a gdb
breakpoint on the assert and typing "print fcode".

[Bug c++/45690] broken debuginfo with dwarf4?

[tromey at gcc dot gnu.org]

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

--- Comment #7 from Tom Tromey  2012-01-20 14:59:51 
UTC ---
gdb doesn't read .debug_pubtypes.
So the problem must be something else.

[Bug fortran/51913] [4.6/4.7 Regression][OOP] bug when submitting a class pointer to a subroutine

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2012-01-20 
14:40:44 UTC ---
(In reply to comment #0)
> Created attachment 26390 [details]
> buggy program

Work around: Swap the USE statements in the main program.


(In reply to comment #1)
>   /* F2003, 12.5.2.5.  */
The reference is wrong, it should be F2008.

[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Guenther  2012-01-20 
14:40:09 UTC ---
Testing

@@ -3891,6 +3853,8 @@ decide_one_param_reduction (struct acces
 {
   by_ref = false;
   agg_size = cur_parm_size;
+  if (DECL_MODE (parm) != BLKmode)
+return 0;
 }

   if (dump_file)

as passing a parameter by value in non-BLKmode (on the PARM_DECL) should
be good evidence to not split it down further (in this case we have
TYPE_SIZE != MODE_SIZE as well, but that's another story).

Hopefully DECL_MODE on the PARM_DECL is good enough and reflects actual
argument passing closely enough ... ?

[Bug c++/37798] unaligned memory access with multiple inheritance

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #7 from Jason Merrill  2012-01-20 
14:37:08 UTC ---
This seems like another example of the same underlying problem as bug 22488,
and should be fixed by the same change I proposed there.

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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

--- Comment #6 from Jack Howarth  2012-01-20 
14:35:52 UTC ---
(In reply to comment #4)
> On x86_64-darwin10 (Xcode 3.2.6) r183290 is OK.
> On powerpc-apple-darwin9 (Xcode 3.1.4) 183218 is OK.

This issue doesn't occur on x86_64-darwin10 with Xcode 4.2 so the problem
seems to be darwin11 specific.

[Bug fortran/51913] [4.6/4.7 Regression][OOP] bug when submitting a class pointer to a subroutine

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-20
 CC||burnus at gcc dot gnu.org
   Target Milestone|--- |4.6.3
Summary|bug when submitting a class |[4.6/4.7 Regression][OOP]
   |pointer to a subroutine |bug when submitting a class
   ||pointer to a subroutine
 Ever Confirmed|0   |1

--- Comment #1 from Tobias Burnus  2012-01-20 
14:27:04 UTC ---
Conformed. Works with NAG f95 and ifort. And works with GCC 4.5. (Probably
because the valid but not correctly working check was not yet implemented.)


The failing check (in interface.c's compare_parameter; cf. PR46161, Rev.
166018) is:

  /* F2003, 12.5.2.5.  */
  if (formal->ts.type == BT_CLASS
  && (CLASS_DATA (formal)->attr.class_pointer
  || CLASS_DATA (formal)->attr.allocatable))
{
...
  if (CLASS_DATA (actual)->ts.u.derived
  != CLASS_DATA (formal)->ts.u.derived)
gfc_error ("Actual argument to '%s' at %L must have the same "
   "declared type", formal->name, &actual->where);


Thus, the question is why 
  CLASS_DATA (actual)->ts.u.derived ! = CLASS_DATA (formal)->ts.u.derived
or in other words why do we have two different symbols in the symtree? We have:

(gdb) p formal->ts.u.derived->name
$4 = 0x2cf45000 "__class_m_sparsematrix_Sparsematrix_t_p"
(gdb) p actual->ts.u.derived->name
$5 = 0x2cf45000 "__class_m_sparsematrix_Sparsematrix_t_p"


What I find a bit odd is:
(gdb) p formal->ts.u.derived->module
$9 = 0x2ce25fc0 ""  ! <<< pointer to empty string
(gdb) p actual->ts.u.derived->module
$8 = 0x0  ! <<< NULL pointer

Otherwise, the two belong (unsurprisingly) to different namespaces:
(gdb) p actual->ts.u.derived->ns->proc_name->name
$13 = 0x2ce25fa8 "main"
(gdb) p formal->ts.u.derived->ns->proc_name->name
$14 = 0x2ce25fb0 "test"

Thus, having a different symbol - and hence a different pointer address - is
not too surprising.

[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target|powerpc64-linux |powerpc64-linux, i?86-*-*

--- Comment #14 from Richard Guenther  2012-01-20 
14:20:17 UTC ---
Same ICE on i?86-linux btw.

[Bug middle-end/51895] [4.7 Regression] ICE in simplify_subreg

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #13 from Richard Guenther  2012-01-20 
14:18:45 UTC ---
I'll look at the IPA-SRA issue.

[Bug tree-optimization/50444] [4.6/4.7 Regression] -ftree-sra ignores alignment

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #15 from Richard Guenther  2012-01-20 
14:16:25 UTC ---
Created attachment 26395
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26395
other candidate patch

I'm testing the following patch instead, which avoids changing access types
for all-scalar across-link propagations (we're going to create proper V_C_Es
later).  I also remove the fancy code that tries to avoid adding V_C_Es,
it looks it will cause more trouble than missed-optimizations.

That way we completely avoid needing to care for alignment at that particular
places.  Whether the aggregate copy across-link propagation is affected in
a similar way remains to be seen.

I'll see if I run into the same issue as you and investigate that.

[Bug debug/51902] lexical_blocks inside inlined_subroutines generate duplicate debug_ranges

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2012-01-20 
13:37:50 UTC ---
We could go just to the immediate supercontext if BLOCK_SAME_RANGE (both when
the fragment count is the same and when it is smaller in the child), but we'd
lose all the verification (we couldn't test ranges_table[something].num against
BLOCK_NUM).
So perhaps we could do that, and only if ENABLE_CHECKING do the additional
verification afterwards, in the normal code just verify that the start of the
range has > 0 num (so it isn't one ranged by labels).

[Bug debug/51902] lexical_blocks inside inlined_subroutines generate duplicate debug_ranges

[mark at gcc dot gnu.org]

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

--- Comment #3 from Mark Wielaard  2012-01-20 13:31:04 
UTC ---
(In reply to comment #2)
> Mark, can you please look at this if it does the right thing you want from it?

Yes, this seems to do what I was thinking of. And it works on my testcases.

It does a bit more by searching up the block supercontext and by trying to find
a partial range. I think it would be fine to look for and pick the first block
supercontext and only check the chains are equal (but haven't tried that yet).

[Bug target/51819] [4.7 Regression] Neon wrong code generation, Error: unsupported alignment for instruction -- `vst1.32 {d2[0]},[r0:64]'

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Ramana Radhakrishnan  2012-01-20 
13:26:14 UTC ---
Fixed. .

[Bug target/51819] [4.7 Regression] Neon wrong code generation, Error: unsupported alignment for instruction -- `vst1.32 {d2[0]},[r0:64]'

[ramana at gcc dot gnu.org]

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

--- Comment #4 from Ramana Radhakrishnan  2012-01-20 
13:24:53 UTC ---
Author: ramana
Date: Fri Jan 20 13:24:47 2012
New Revision: 183338

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183338
Log:

Fix PR target/51819 


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c

[Bug target/51915] [4.7 Regression] ICE in output_move_double

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-01-20
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #2 from Jakub Jelinek  2012-01-20 
13:17:49 UTC ---
Ramana, if this patch looks ok to you, can you please bootstrap/regtest it? 
Thanks.

[Bug target/51915] [4.7 Regression] ICE in output_move_double

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2012-01-20 
13:16:42 UTC ---
Created attachment 26394
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26394
gcc47-pr51915.patch

Untested fix.

output_move_double (sometimes intentionally) modifies the operands array,
because it returns a pattern that should be emitted by the caller in some
cases.
But if that is done already when !emit, when just counting the insns, when
output_move_double is called with emit=true, we ICE.

[Bug lto/51916] New: FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)

[dominiq at lps dot ens.fr]

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

 Bug #: 51916
   Summary: FAIL: gcc.dg/lto/trans-mem-3
c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link,
-flto (internal compiler error)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
  Host: *-apple-darwin*
Target: *-apple-darwin*
 Build: *-apple-darwin*


The test for gcc.dg/lto/trans-mem-3* fails on *-apple-darwin*  as

[macbook] f90/bug% gcc47 /opt/gcc/work/gcc/testsuite/gcc.dg/lto/trans-mem-3_0.c
-c -o obj_0.o -flto
[macbook] f90/bug% gcc47 /opt/gcc/work/gcc/testsuite/gcc.dg/lto/trans-mem-3_1.c
-c -o obj_1.o -flto -fgnu-tm
[macbook] f90/bug% gcc47 obj_0.o obj_1.o -flto
lto1: internal compiler error: in streamer_get_builtin_tree, at
tree-streamer-in.c:1077
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: gcc47 returned 1 exit status
collect2: error: lto-wrapper returned 1 exit status

The internal compiler error disappears if I add -fgnu-tm:

[macbook] f90/bug% gcc47 obj_0.o obj_1.o -flto -fgnu-tm
[macbook] f90/bug%

[Bug target/51915] New: [4.7 Regression] ICE in output_move_double

[jakub at gcc dot gnu.org]

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

 Bug #: 51915
   Summary: [4.7 Regression] ICE in output_move_double
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: ram...@gcc.gnu.org
Target: arm-linux-gnueabi


The following testcase started ICEing probably with PR50022 change:
./xgcc -B ./ -march=armv7-a -mfloat-abi=hard -O2 rh783334.c
rh783334.c: In function ‘bar’:
rh783334.c:12:1: internal compiler error: in output_move_double, at
config/arm/arm.c:13951
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

/* { dg-do compile } */
/* { dg-options "-march=armv7-a -mfloat-abi=hard -O2" } */

struct S { int s1; void *s2; };
struct T { struct S t1; unsigned long long t2; };
struct S *foo (unsigned long long);

struct S *
bar (struct S *x)
{
  return foo (((struct T *) x)->t2);
}

[Bug middle-end/45273] [4.4/4.5/4.6/4.7 Regression] The compiler depends on the host double (-fprofile-corection only)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|4.4.7   |4.8.0

--- Comment #7 from Richard Guenther  2012-01-20 
12:38:42 UTC ---
OTOH, nowadays all(?) host platforms we support have IEEE enough compliant
HW floating-point (well, details like signed zeros and NaNs/Infs are not
really relevant for GCC) that a hwfloat.h could provide a mapping to
a 32bit / 64bit IEEE float format?

Else the patch certainly looks good to me, but lets queue it for 4.8
(I remembered you posted patches to remove sreal.c, did you?)

[Bug target/49868] Implement named address space to place/access data in flash memory

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords|documentation   |
 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #13 from Georg-Johann Lay  2012-01-20 
12:34:37 UTC ---
Clodes with the documentation

[Bug target/50887] [avr] Support ACCUMULATE_OUTGOING_ARGS

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords|documentation   |
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Georg-Johann Lay  2012-01-20 
12:33:45 UTC ---
Closed with its documentation

[Bug target/49868] Implement named address space to place/access data in flash memory

[gjl at gcc dot gnu.org]

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

--- Comment #12 from Georg-Johann Lay  2012-01-20 
12:31:59 UTC ---
Author: gjl
Date: Fri Jan 20 12:31:46 2012
New Revision: 183336

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183336
Log:
PR target/49868
PR target/50887
* doc/extend.texi (Named Address Spaces): Split into subsections.
(AVR Named Address Spaces): New subsection.
(M32C Named Address Spaces): New subsection.
(RL78 Named Address Spaces): New subsection.
(SPU Named Address Spaces): New subsection.
(Variable Attributes): New anchor "AVR Variable Attributes".
(AVR Variable Attributes): Rewrite and avoid wording
"address space" in this context.
* doc/invoke.texi (AVR Options): Rewrite and add documentation
for -maccumulate-args, -mbranch-cost=, -mrelax, -mshort-calls.
(AVR Built-in Macros): New subsubsection therein.
* doc/md.texi (AVR constraints): Remove "C04", "R".


Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi
trunk/gcc/doc/invoke.texi
trunk/gcc/doc/md.texi

[Bug target/50887] [avr] Support ACCUMULATE_OUTGOING_ARGS

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  2012-01-20 
12:31:59 UTC ---
Author: gjl
Date: Fri Jan 20 12:31:46 2012
New Revision: 183336

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183336
Log:
PR target/49868
PR target/50887
* doc/extend.texi (Named Address Spaces): Split into subsections.
(AVR Named Address Spaces): New subsection.
(M32C Named Address Spaces): New subsection.
(RL78 Named Address Spaces): New subsection.
(SPU Named Address Spaces): New subsection.
(Variable Attributes): New anchor "AVR Variable Attributes".
(AVR Variable Attributes): Rewrite and avoid wording
"address space" in this context.
* doc/invoke.texi (AVR Options): Rewrite and add documentation
for -maccumulate-args, -mbranch-cost=, -mrelax, -mshort-calls.
(AVR Built-in Macros): New subsubsection therein.
* doc/md.texi (AVR constraints): Remove "C04", "R".


Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi
trunk/gcc/doc/invoke.texi
trunk/gcc/doc/md.texi

[Bug c++/51402] [4.6/4.7 Regression] ICE with invalid template parameter

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #2 from Paolo Carlini  2012-01-20 
11:50:56 UTC ---
On it.

[Bug libfortran/51899] [4.7 Regression] libgfortran's chmod.c fails to build on MinGW

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Tobias Burnus  2012-01-20 
11:36:56 UTC ---
FIXED on the trunk (4.7).

[Bug libfortran/51899] [4.7 Regression] libgfortran's chmod.c fails to build on MinGW

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2012-01-20 
11:32:55 UTC ---
Author: burnus
Date: Fri Jan 20 11:32:52 2012
New Revision: 183335

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183335
Log:
2012-01-20  Tobias Burnus  

PR libgfortran/51899
* configure.ac: Check whether umask is available.
* intrinsics/chmod.c (chmod_func): Make compile with MinGW.
* configure: Regenerate.
* config.h.in: Regenerate.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/config.h.in
trunk/libgfortran/configure
trunk/libgfortran/configure.ac
trunk/libgfortran/intrinsics/chmod.c

[Bug tree-optimization/51914] [4.7] vect-intfloat-conversion4a/b tests fail for arm-linux-gnueabi

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-01-20
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Jakub Jelinek  2012-01-20 
11:31:18 UTC ---
Created attachment 26393
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26393
gcc47-pr51914.patch

Untested fix.

[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument

[burnus at gcc dot gnu.org]

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

--- Comment #23 from Tobias Burnus  2012-01-20 
11:28:23 UTC ---
Created attachment 26392
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26392
Small test case for polymorphic optional dummies

(In reply to comment #22)
> Updated patch.
> This passes the full comment #13 test fixed as follows:

Truly awesome! Will you submit the patch?

 * * *

Related, but a bit separate issue: OPTIONAL CLASS dummies. See attached test
case. It seems to mostly work with the patch below, except for one ICE and one
SEGV at run time. (And - out-commented part - I'm hitting an ICE which might be
the same as PR 46356 comment 2.)

TODO: In the fixed-up test case of comment 13, copy sub_t and change "type" to
"class" - copy all calls to sub_t - and modify those to call the new function.
See what will break ...

TODO2: Call both the original sub_t and the new function with polymorphic
components of derived types.

--- trans-expr.c(revision 183328)
+++ trans-expr.c(working copy)
@@ -576,8 +576,16 @@ gfc_conv_expr_present (gfc_symbol * sym)
   gcc_assert (sym->attr.dummy);

   decl = gfc_get_symbol_decl (sym);
-  if (TREE_CODE (decl) != PARM_DECL)
+
+  if (sym->ts.type == BT_CLASS)
 {
+  decl = gfc_class_data_get (decl);
+  if (CLASS_DATA (sym)->attr.dimension
+ || CLASS_DATA (sym)->attr.codimension)
+   decl = gfc_build_addr_expr (NULL_TREE, decl);
+}
+  else if (TREE_CODE (decl) != PARM_DECL)
+{
   /* Array parameters use a temporary descriptor, we want the real
  parameter.  */
   gcc_assert (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (decl))

[Bug middle-end/51893] Wrong subword index computation in store_bit_field_1 on BIG_ENDIAN targets

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  2012-01-20 
11:28:26 UTC ---
> The testcase that fails is gcc.c-torture/execute/bitfld-3.c. Both with and
> without (4.6.1 release) the patch. 
> The patch I posted fixes the problem, but I don't know if it is general 
> enough.

OK, what are the values of the various parameters you have upon entering the
problematic block of code in store_bit_field_1?  Note that this code has been
working fine for years on 32-bit big-endian targets so this is unexpected.

[Bug target/49257] -mfpmath=sse generates x87 instructions on 32 bits OS

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||WONTFIX

--- Comment #18 from Uros Bizjak  2012-01-20 11:06:16 
UTC ---
The only way this could work is to put __builtin_ia32_emms into the loop, after
__builtin_ia32_movntq. -mfpmath=sse does not mean that x87 is disabled, only
that equivalent arithmetic instructions use SSE instructions. If there is no
equivalent SSE insn, x87 insn is used.

IIRC, even Intel's Instruction set reference suggests to group FP and MMX insn
together and put emms after MMX block.

Since a substantial effort would be needed to fix this questionable corner
case, and the test is violating recommended practice, I'm marking this PR as
WONTFIX.