[Bug fortran/51727] Changing module files

[Joost.VandeVondele at mat dot ethz.ch]

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



--- Comment #30 from Joost VandeVondele  
2012-11-09 07:31:28 UTC ---

(In reply to comment #29)

> I committed the C-only version of the patch as the issues mentioned in comment

> #27 couldn't be addressed before stage3.



Thanks Tobi!



I have been using your C-only patch for a couple of weeks now for the 4.7

branch, and it is greatly improving our edit/compile-cycles. For one of my

students, it yields an effective 10x speedup in building CP2K after a typical

code change, greatly facilitating the programming project he is on. I would

suggest that after a couple of weeks on trunk, this should be reconsidered

again for backporting to 4.7.

[Bug lto/54966] Does LTO requires a larger inline-unit-growth?

[vincenzo.innocente at cern dot ch]

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

--- Comment #9 from vincenzo Innocente  
2012-11-09 06:52:22 UTC ---
better and worse!
better than 4.7.2 
lto is worse in 4.8
Attached is a test case, just one file
bzip2 -d smatrix.ii.bz2 

the main component is this
three different way of computing the same matrix multiplication with more and
more
explicit temporaries..
tvc = 
  //33   3N  NN  NM  MM
  -ve * (Transpose(a)) * tw * b * s;
  }


  void compute2() {
//NMNM  MM
AlgebraicMatrixNM twbs =  tw *  b * s;
tvc = 
  //33   3N 
-ve * (Transpose(a)) * twbs;
  }

  void compute3() {
//NMNM  MM
AlgebraicMatrixNM twbs =  tw *  b * s;
//   33   3N 
AlgebraicMatrix3N tmpM1 = -ve * (Transpose(a));
tvc = tmpM1 * twbs;
  }

timing is in cycle using __rdtsc(); on Inel x86_64
stability maybe 10%…

Target: x86_64-unknown-linux-gnu
gcc version 4.7.2 (GCC) 

[vocms123] ~/public/ctest/bugs48 $ c++ -O2 smatrix.ii; ./a.out 
size 5.  v1: time in cycles 30159.6
size 5.  v2: time in cycles 6031.1
size 5.  v3: time in cycles 3388.17
size 6.  v1: time in cycles 60336.6
size 6.  v2: time in cycles 10366.8
size 6.  v3: time in cycles 5955.81
[vocms123] ~/public/ctest/bugs48 $ c++ -O2 smatrix.ii -flto; ./a.out
size 5.  v1: time in cycles 12818.8
size 5.  v2: time in cycles 10453.9
size 5.  v3: time in cycles 5954.23
size 6.  v1: time in cycles 46293.1
size 6.  v2: time in cycles 12309.2
size 6.  v3: time in cycles 11621.8
[vocms123] ~/public/ctest/bugs48 $ c++ -O3 smatrix.ii; ./a.out
size 5.  v1: time in cycles 39630.3
size 5.  v2: time in cycles 5869.96
size 5.  v3: time in cycles 1966.87
size 6.  v1: time in cycles 69531.4
size 6.  v2: time in cycles 9020.06
size 6.  v3: time in cycles 4732.99
[vocms123] ~/public/ctest/bugs48 $ c++ -O3 smatrix.ii -flto; ./a.out
size 5.  v1: time in cycles 12425.1
size 5.  v2: time in cycles 9650.03
size 5.  v3: time in cycles 5340.79
size 6.  v1: time in cycles 45998
size 6.  v2: time in cycles 11128.1
size 6.  v3: time in cycles 10383


gcc version 4.8.0 20121108 (experimental) [trunk revision 19] (GCC) 

[vocms123] ~/public/ctest/bugs48 $ c++ -O2 smatrix.ii ; ./a.out
size 5.  v1: time in cycles 14040.5
size 5.  v2: time in cycles 3264.85
size 5.  v3: time in cycles 3457.25
size 6.  v1: time in cycles 37368.4
size 6.  v2: time in cycles 5813.81
size 6.  v3: time in cycles 6224.37
[vocms123] ~/public/ctest/bugs48 $ c++ -O2 smatrix.ii -flto ; ./a.out
size 5.  v1: time in cycles 20705.2
size 5.  v2: time in cycles 6333.17
size 5.  v3: time in cycles 6654.85
size 6.  v1: time in cycles 49788.8
size 6.  v2: time in cycles 6828.72
size 6.  v3: time in cycles 7188.28
[vocms123] ~/public/ctest/bugs48 $ c++ -O3 smatrix.ii ; ./a.out
size 5.  v1: time in cycles 17350.4
size 5.  v2: time in cycles 2355.68
size 5.  v3: time in cycles 1891.62
size 6.  v1: time in cycles 38002
size 6.  v2: time in cycles 4046.09
size 6.  v3: time in cycles 3954.97
[vocms123] ~/public/ctest/bugs48 $ c++ -O3 smatrix.ii -flto; ./a.out
size 5.  v1: time in cycles 20380.9
size 5.  v2: time in cycles 4504.76
size 5.  v3: time in cycles 4576.5
size 6.  v1: time in cycles 42327.9
size 6.  v2: time in cycles 3405.72
size 6.  v3: time in cycles 3314.2

stability test


[vocms123] ~/public/ctest/bugs48 $ c++ -O3 smatrix.ii -flto ; ./a.out
size 5.  v1: time in cycles 20447.2
size 5.  v2: time in cycles 4509.64
size 5.  v3: time in cycles 4580.46
size 6.  v1: time in cycles 42361.2
size 6.  v2: time in cycles 3407.53
size 6.  v3: time in cycles 3316.36
[vocms123] ~/public/ctest/bugs48 $ ./a.out 
size 5.  v1: time in cycles 23968.7
size 5.  v2: time in cycles 5277.67
size 5.  v3: time in cycles 5353.72
size 6.  v1: time in cycles 49573
size 6.  v2: time in cycles 4023.34
size 6.  v3: time in cycles 3862.6

[Bug lto/54966] Does LTO requires a larger inline-unit-growth?

[vincenzo.innocente at cern dot ch]

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



--- Comment #8 from vincenzo Innocente  
2012-11-09 06:39:33 UTC ---

Created attachment 28646

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28646

test case  (preprocessed with gcc 4.7.2)

[Bug c++/55245] Compiler segfault when compiling the small test case

[xinliangli at gmail dot com]

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



--- Comment #2 from davidxl  2012-11-09 06:05:43 
UTC ---

(In reply to comment #1)

> The problem actually exists in main line compiler too.





This is another test case.



Segfaults without option, but builds ok with -DOK.



The problem seems to be that the main variant of the array type

Vector2[2] does not have size, while the variant Vector2_f[2] has. The

variant's size later gets reset to 0 (from main variant).



David



template  class Vector2 {

 public:

  Vector2();

  VType x() const;

};

typedef Vector2 Vector2_f;

void GetR(const Vector2_f mosaic_position[3]);

template  struct DefaultDeleter {

   float  GetColorTexCoord(Vector2_f &tex_coord) const  {

return tex_coord.x();

  }

};



class GetT { private: virtual void TestBody(); };



void GetT::TestBody() {

#ifdef OK

  Vector2 mosaic_position[2][3] = { };

#else

  Vector2_f mosaic_position[2][3] = { };

#endif

}

[Bug c++/55248] New: Segmentation Fault - instantiating template with partial specialization

[dlarimer at gmail dot com]

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



 Bug #: 55248

   Summary: Segmentation Fault - instantiating template with

partial specialization

Classification: Unclassified

   Product: gcc

   Version: 4.7.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: dlari...@gmail.com





Created attachment 28645

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28645

pre-processed source that generates error



I am not sure what the root cause that triggered this error was, but the

pre-processed code is less than 8000 lines and I shouldn't be seeing an

internal compiler error. 



/Users/dlarimer/projects/atc/gate/fc/tests/json_rpc_test.cpp: In instantiation

of 'struct fc::json::detail::named_param >':

/Users/dlarimer/projects/atc/gate/fc/include/fc/json_rpc_connection.hpp:124:9: 

 required from 'fc::future fc::json::rpc_connection::invoke(const

fc::string&, Args&&) [with R = int; Args = fc::tuple]'

/Users/dlarimer/projects/atc/gate/fc/include/fc/json_rpc_client.hpp:33:64:  

required from 'fc::json::detail::rpc_member::functor(P&&, R (C::*)(Args ...),

const ptr&, const char*) [with R = int; C = test; P = int; Args = {int};

fc::json::rpc_connection::ptr =

fc::shared_ptr]::'

/Users/dlarimer/projects/atc/gate/fc/include/fc/json_rpc_client.hpp:33:38:  

required from 'struct fc::json::detail::rpc_member::functor(P&&, R (C::*)(Args

...), const ptr&, const char*) [with R = int; C = test; P = int; Args = {int};

fc::json::rpc_connection::ptr =

fc::shared_ptr]::'

/Users/dlarimer/projects/atc/gate/fc/include/fc/json_rpc_client.hpp:33:67:  

required from 'static std::function(Args ...)>

fc::json::detail::rpc_member::functor(P&&, R (C::*)(Args ...), const ptr&,

const char*) [with R = int; C = test; P = int; Args = {int};

fc::json::rpc_connection::ptr = fc::shared_ptr]'

/Users/dlarimer/projects/atc/gate/fc/include/fc/json_rpc_client.hpp:49:11:  

required from 'void fc::json::detail::vtable_visitor::operator()(const char*,

Function&, MemberPtr) const [with Function =

std::function(int)>; MemberPtr = int (test::*)(int)]'

/Users/dlarimer/projects/atc/gate/fc/tests/json_rpc_test.cpp:31:1:   required

from 'void fc::detail::vtable::visit_other(Visitor&&) [with T

= test; Visitor = fc::json::detail::vtable_visitor; Transform =

fc::json::detail::rpc_member]'

/Users/dlarimer/projects/atc/gate/fc/include/fc/json_rpc_client.hpp:74:11:  

required from 'void fc::json::rpc_client::init() [with

InterfaceType = test]'

/Users/dlarimer/projects/atc/gate/fc/include/fc/json_rpc_client.hpp:61:9:  

required from 'fc::json::rpc_client::rpc_client(const ptr&)

[with InterfaceType = test; fc::json::rpc_connection::ptr =

fc::shared_ptr]'

/Users/dlarimer/projects/atc/gate/fc/tests/json_rpc_test.cpp:48:44:   required

from here

/Users/dlarimer/projects/atc/gate/fc/tests/json_rpc_test.cpp:14:1: internal

compiler error: Segmentation fault: 11

[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2012-11-09 05:08:29 
UTC ---
[hjl@gnu-tools-1 gcc]$ cat /export/gnu/import/delta-2006.08.03/x.c
typedef unsigned int uint32_t;
typedef unsigned int uintptr_t;
typedef uint32_t Elf32_Word;
typedef uint32_t Elf32_Addr;
typedef struct {
  Elf32_Word st_name;
  Elf32_Addr st_value;
  Elf32_Word st_size;
  unsigned char st_other;
} Elf32_Sym;
typedef struct {
  Elf32_Word r_info;
}
Elf32_Rela;
typedef struct {
  union {
Elf32_Addr d_ptr;
  }
  d_un;
} Elf32_Dyn;
struct link_map   {
  Elf32_Dyn *l_info[34];
};
typedef struct link_map *lookup_t;
extern void symbind32 (Elf32_Sym *);
void
_dl_profile_fixup (struct link_map *l, Elf32_Word reloc_arg)
{
  const Elf32_Sym *const symtab  = (const void *) (l)->l_info[6]->d_un.d_ptr;
  const Elf32_Rela *const reloc  = (const void *) ((l)->l_info[23]->d_un.d_ptr
+ reloc_arg * sizeof (Elf32_Rela));
  const Elf32_Sym *refsym = &symtab[((reloc->r_info) >> 8)];
  const Elf32_Sym *defsym = refsym;
  Elf32_Sym sym = *defsym;
  symbind32 (&sym);
}
[hjl@gnu-tools-1 gcc]$ ./xgcc -B./ -mx32 -mtune=generic -march=x86-64
-maddress-mode=long -c -std=gnu99 -fgnu89-inline  -O3-fPIC  -mno-sse
-mno-mmx/export/gnu/import/delta-2006.08.03/x.c 
/export/gnu/import/delta-2006.08.03/x.c: In function ‘_dl_profile_fixup’:
/export/gnu/import/delta-2006.08.03/x.c:35:1: internal compiler error: Max.
number of generated reload insns per insn is achieved (90)

 }
 ^
0x8d78cd lra_constraints(bool)
/export/gnu/import/git/gcc/gcc/lra-constraints.c:3381
0x8c8169 lra(_IO_FILE*)
/export/gnu/import/git/gcc/gcc/lra.c:2274
0x87dc24 do_reload
/export/gnu/import/git/gcc/gcc/ira.c:4624
0x87de32 rest_of_handle_reload
/export/gnu/import/git/gcc/gcc/ira.c:4737
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-tools-1 gcc]$ ./xgcc -B./ -mx32 -mtune=generic -march=x86-64
-maddress-mode=long -c -std=gnu99 -fgnu89-inline  -O3-fPIC  -mno-sse
-mno-mmx/export/gnu/import/delta-2006.08.03/x.c -mno-lra
[hjl@gnu-tools-1 gcc]$

[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

[hjl.tools at gmail dot com]

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



--- Comment #31 from H.J. Lu  2012-11-09 02:36:23 
UTC ---

Created attachment 28644

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28644

A patch



This patch prints SImode register names to force addr32 prefix

if displacement < -16*1024*1024 so that 32-bit displacement

isn't sign-extended to 64-bit.  It also removes "code = 'l'"

since 'l' isn't supported.

[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[hjl.tools at gmail dot com]

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



H.J. Lu  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0

[Bug rtl-optimization/55247] New: [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[hjl.tools at gmail dot com]

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

 Bug #: 55247
   Summary: [4.8 Regression] internal compiler error: Max. number
of generated reload insns per insn is achieved (90)
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: vmaka...@redhat.com


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

On Linux/x86-64, revision 193341 gave:

/export/build/gnu/gcc-x32-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32-test/build-x86_64-linux/gcc/ -mx32 -mtune=generic
-march=x86-64 -maddress-mode=long -c -std=gnu99 -fgnu89-inline  -O3-fPIC 
-mno-sse -mno-mmxtestcase.i
testcase.i: In function ‘_dl_profile_fixup’:
testcase.i:57:6: warning: implicit declaration of function ‘symbind32’
[-Wimplicit-function-declaration]
  uintptr_t new_value  = symbind32 (&sym,  reloc_result->boundndx, 
&l->l_audit[cnt].cookie,  &result->l_audit[cnt].cookie,
 &flags,  strtab2 + defsym->st_name);
  ^
testcase.i:58:3: internal compiler error: Max. number of generated reload insns
per insn is achieved (90)

   }
   ^
0x8d78cd lra_constraints(bool)
/export/gnu/import/git/gcc/gcc/lra-constraints.c:3381
0x8c8169 lra(_IO_FILE*)
/export/gnu/import/git/gcc/gcc/lra.c:2274
0x87dc24 do_reload
/export/gnu/import/git/gcc/gcc/ira.c:4624
0x87de32 rest_of_handle_reload
/export/gnu/import/git/gcc/gcc/ira.c:4737
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-tools-1 delta-2006.08.03]$

[Bug target/55246] New: Define a macro for 16*1024*1024

[hjl.tools at gmail dot com]

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



 Bug #: 55246

   Summary: Define a macro for 16*1024*1024

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: hjl.to...@gmail.com

CC: ubiz...@gmail.com





i386 backend has



i386.c:  || INTVAL (op1) >= 16*1024*1024

i386.c:  || INTVAL (op1) < -16*1024*1024)

i386.c:  if (INTVAL (op1) < -16*1024*1024

i386.c:  || INTVAL (op1) >= 16*1024*1024)

predicates.md:  && offset < 16*1024*1024

predicates.md:  && offset < 16*1024*1024



It is a magic number for 64-bit displacement.  We should define

a macro to make it consistent.

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org

--- Comment #14 from Manuel López-Ibáñez  2012-11-09 
01:27:49 UTC ---
(In reply to comment #12)
> Do you know where it is looping? That sounds like a different and more serious
> issue than the pretty-printer for types not being able to summarize repetitive
> template instantiations (and that is already reported in a different PR).

To answer my own question, it loops (or it seems to take a very long time) in
instantiate_pending_templates:

#150 0x0069403f in emit_mem_initializers (mem_inits=0x77053c58) at
/home/manuel/test1/pristine/gcc/cp/init.c:1085
#151 0x005a40ae in tsubst_expr (t=,
args=args@entry=0x77041060, complain=complain@entry=3,
in_decl=in_decl@entry=0x7758ca10, 
integral_constant_expression_p=integral_constant_expression_p@entry=false)
at /home/manuel/test1/pristine/gcc/cp/pt.c:12671
#152 0x005a3964 in tsubst_expr (t=0x77416e70,
args=args@entry=0x77041060, complain=complain@entry=3,
in_decl=in_decl@entry=0x7758ca10, 
integral_constant_expression_p=integral_constant_expression_p@entry=false)
at /home/manuel/test1/pristine/gcc/cp/pt.c:12849
#153 0x005a10aa in instantiate_decl (d=,
d@entry=0x7703c800, defer_ok=, defer_ok@entry=0, 
expl_inst_class_mem_p=expl_inst_class_mem_p@entry=false) at
/home/manuel/test1/pristine/gcc/cp/pt.c:18674
#154 0x005dbaa4 in instantiate_pending_templates (retries=) at /home/manuel/test1/pristine/gcc/cp/pt.c:18773
#155 0x00618ac9 in cp_write_global_declarations () at
/home/manuel/test1/pristine/gcc/cp/decl2.c:3990
#156 0x00aadbd5 in compile_file () at
/home/manuel/test1/pristine/gcc/toplev.c:558
#157 0x00aaf738 in do_compile () at
/home/manuel/test1/pristine/gcc/toplev.c:1864
#158 toplev_main (argc=3, argv=0x7fffe738) at
/home/manuel/test1/pristine/gcc/toplev.c:1940
#159 0x776261a6 in __libc_start_main () from /lib/libc.so.6
#160 0x0052f919 in _start ()

Jason, Joseph, why are we trying to do (cp_)write_global_declarations if we
have already seen compilation errors? 

Can't we just abort earlier in compile_file()?

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[manu at gcc dot gnu.org]

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

--- Comment #13 from Manuel López-Ibáñez  2012-11-09 
00:58:20 UTC ---
As I said in PR 43113, it would be wonderful if g++ detected that something is
a recursive template instantiation and it didn't print the whole expansion but
just the first recursion or some such. I wonder if clang++ has a PR open about
this...

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #12 from Manuel López-Ibáñez  2012-11-09 
00:44:06 UTC ---
Do you know where it is looping? That sounds like a different and more serious
issue than the pretty-printer for types not being able to summarize repetitive
template instantiations (and that is already reported in a different PR).

Clang doesn't loop but it still prints the long lines.

[Bug c++/55245] Compiler segfault when compiling the small test case

[xinliangli at gmail dot com]

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



davidxl  changed:



   What|Removed |Added



Version|4.7.3   |4.8.0



--- Comment #1 from davidxl  2012-11-09 00:42:55 
UTC ---

The problem actually exists in main line compiler too.

[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

[hjl.tools at gmail dot com]

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



--- Comment #30 from H.J. Lu  2012-11-09 00:35:28 
UTC ---

(In reply to comment #24)

> 

> I think the most robust solution would be to always zero-extend the addresses

> for -mx32, i.e. output

>   movl%ecx, -1073743664(%eax)

> even if the address is a PLUS in DImode.  Otherwise, we're left with 
> kludges...



Since x32 runs in 64-bit mode, for address -0x4300(%rax),

hardware sign-extends displacement from 32-bits to 64-bits and

adds it to %rax.  But x32 wants 32-bit -0x4300, not 64-bit

-0x4300.  I believe it is correct for GCC to use 32-bit

registers instead of 64-bit registers when displacement is

negative.

[Bug c++/55245] New: Compiler segfault when compiling the small test case

[xinliangli at gmail dot com]

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



 Bug #: 55245

   Summary: Compiler segfault when compiling the small test case

Classification: Unclassified

   Product: gcc

   Version: 4.7.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: xinlian...@gmail.com





Compiling the following program without any option, gcc segfaults:



get.cc: In member function 'virtual void Test2::TestBody()':

get.cc:22:27: internal compiler error: Segmentation fault





The problem is that one array type Vector2_f[2]'s size field is reset to zero

during gimplify_type_sizes by one of its variant (which has null size).



The problem does not show up in trunk compiler.  Was this fixed explicitly in

trunk or it happens to work by luck?



David







template  class Vector2 { };

typedef Vector2 Vector2_f;



void GetR( const Vector2_f mosaic_position[3]);



class Test1 {

 private: virtual void TestBody();

};



void Test1::TestBody() {

  Vector2_f mosaic_position[2][1];   // (1)

}



class Test2 {

 private: virtual void TestBody();

};



int tri;

void Test2::TestBody() {

  Vector2_f mosaic_position[2][3] = { };

  GetR(mosaic_position[tri]);

}

[Bug go/55228] index.go should check size of int instead of GOARCH

[ian at airs dot com]

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



Ian Lance Taylor  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #1 from Ian Lance Taylor  2012-11-09 00:06:41 
UTC ---

Fixed on mainline.

[Bug libstdc++/55244] char_traits compares characters as though unsigned

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #5 from Paolo Carlini  2012-11-08 
23:55:27 UTC ---

Thanks Daniel.

[Bug libstdc++/55244] char_traits compares characters as though unsigned

[daniel.kruegler at googlemail dot com]

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

--- Comment #4 from Daniel Krügler  
2012-11-08 23:52:52 UTC ---
(In reply to comment #2)
Agreed, looks like an invalid issue to me.

[Bug libstdc++/55244] char_traits compares characters as though unsigned

[paolo.carlini at oracle dot com]

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



--- Comment #3 from Paolo Carlini  2012-11-08 
23:50:34 UTC ---

In short, I think we are fine.

[Bug libstdc++/55244] char_traits compares characters as though unsigned

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC|GCC at DanielRHouck dot com |



--- Comment #2 from Paolo Carlini  2012-11-08 
23:45:40 UTC ---

See:



  http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467



Eh!

[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

[ebotcazou at gcc dot gnu.org]

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



--- Comment #29 from Eric Botcazou  2012-11-08 
23:21:44 UTC ---

> So for POINTERS_EXTEND_UNSIGNED > 0, we should transform

> 

> (zero_extend:DI (plus:SI (FOO:SI) (const_int Y)))

> 

> in such a way that it won't cause ICE and zero-extend the

> result.  For X32, we just need to generate

> 

> (plus:SI (REG:SI) (const_int Y))



The ICE is a minor detail, the real issue is convert_memory_address_addr_space

and PR middle-end/49721.  The unmodified compiler generates the same

problematic instructions for the full testcase without -fPIC.  It's clear that

Richard's change, aka the un-sign-extension of sizetype constants, is an

earthquake here.

[Bug libstdc++/55244] char_traits compares characters as though unsigned

[GCC at DanielRHouck dot com]

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



--- Comment #1 from Daniel Houck  2012-11-08 
23:19:27 UTC ---

Created attachment 28642

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28642

The original source code before preprocessing



I am including this because the problem lies with the standard library and not

the compiler, and therefore it may be useful to know exactly how I included the

standard library.

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



   Keywords||diagnostic

   Last reconfirmed|2008-12-25 15:59:38 |2012-11-08 15:59:38



--- Comment #11 from Steven Bosscher  2012-11-08 
23:17:40 UTC ---

The compiler now produces a wonderful diagnostic for my original test case

(comment #1), with one line of the diagnostic with a length of 30750 (!)

characters. Nice, on that 80-chars wide terminal! :-)



t.C: In instantiation of 'class

std::vector, symbol> >*>, std::allocator,

symbol> >*, std::allocator<__gnu_cxx::_Hashtable_node, symbol>, std::basic_string,

__gnu_cxx::hash >, st.

t.C:552:9:   required from 'class __gnu_cxx::hash_map,

symbol>'

t.C:574:35:   required from here

t.C:121:38: error: no type named 'pointer' in 'class

std::allocator

[Bug libstdc++/55244] New: char_traits compares characters as though unsigned

[GCC at DanielRHouck dot com]

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

 Bug #: 55244
   Summary: char_traits compares characters as though
unsigned
Classification: Unclassified
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@danielrhouck.com


Created attachment 28641
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28641
The preprocessed source code briefly demonstrating this behavior.

According to the C++ standard, char_traits::compare's value is defined in terms
of char_traits::lt's. The unspecialized version of the char_traits template
implements this correctly. However, char_traits redefines compare based
on __builtin_memcmp, and does not work correctly for characters not in the
range [0, 127]. Specifically, it compares characters as though they were
unsigned instead of signed.

The attached preprocessed code was produced by "g++ -v -save-temps testcase.cpp
-o testcase" executed on a simple file. The output of gcc is below:
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3/g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/usr/portage-tmp/portage/sys-devel/gcc-4.5.3-r2/work/gcc-4.5.3/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-ppl --without-cloog --disable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib --enable-libmudflap
--disable-libssp --enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/python
--enable-checking=release --enable-java-awt=gtk
--enable-languages=c,c++,java,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.3-r2 p1.5,
pie-0.4.7'
Thread model: posix
gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.5, pie-0.4.7) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'testcase' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1plus -E -quiet -v -D_GNU_SOURCE
testcase.cpp -D_FORTIFY_SOURCE=2 -mtune=generic -march=x86-64 -fpch-preprocess
-o testcase.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4/backward
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'testcase' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1plus -fpreprocessed testcase.ii
-quiet -dumpbase testcase.cpp -mtune=generic -march=x86-64 -auxbase testcase
-version -o testcase.s
GNU C++ (Gentoo 4.5.3-r2 p1.5, pie-0.4.7) version 4.5.3 (x86_64-pc-linux-gnu)
compiled by GNU C version 4.5.3, GMP version 5.0.2, MPFR version 3.0.1-p4,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Gentoo 4.5.3-r2 p1.5, pie-0.4.7) version 4.5.3 (x86_64-pc-linux-gnu)
compiled by GNU C version 4.5.3, GMP version 5.0.2, MPFR version 3.0.1-p4,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3053bf2eb42d601ba6282eebbd0ccc30
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'testcase' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/as
-V -Qy --64 -o testcase.o testcase.s
GNU assembler version 2.21.1 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.21.1
COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x

[Bug middle-end/41004] missed merge of basic blocks

[steven at gcc dot gnu.org]

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



--- Comment #9 from Steven Bosscher  2012-11-08 
23:07:36 UTC ---

May be fixed by the patch that was applied for PR54364.

[Bug tree-optimization/55238] ICE in find_aggregate_values_for_callers_subset, at ipa-cp.c:2908 building zlib

[jamborm at gcc dot gnu.org]

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



Martin Jambor  changed:



   What|Removed |Added



URL||http://gcc.gnu.org/ml/gcc-p

   ||atches/2012-11/msg00714.htm

   ||l



--- Comment #4 from Martin Jambor  2012-11-08 
23:03:16 UTC ---

I have submitted the patch to the mailing list:



http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00714.html

[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

[hjl.tools at gmail dot com]

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



--- Comment #28 from H.J. Lu  2012-11-08 23:02:54 
UTC ---

So for POINTERS_EXTEND_UNSIGNED > 0, we should transform



(zero_extend:DI (plus:SI (FOO:SI) (const_int Y)))



in such a way that it won't cause ICE and zero-extend the

result.  For X32, we just need to generate



(plus:SI (REG:SI) (const_int Y))

[Bug target/53087] [powerpc] Poor code from cstore expander

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #13 from Steven Bosscher  2012-11-08 
23:01:54 UTC ---

Fixed according to comment #12.

[Bug tree-optimization/18316] Missed IV optimization

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



   Last reconfirmed|2010-02-12 21:46:26 |2012-11-08 21:46:26



--- Comment #15 from Steven Bosscher  2012-11-08 
22:59:49 UTC ---

Still a missed optimization as of trunk r193340:



strength_test2:

movl(%rdi), %ecx

movl%ecx, %eax

.p2align 4,,10

.p2align 3

.L3:

movslq  8(%rdi), %rdx

movl$2, (%rdi,%rdx,4)

movl%eax, %edx

addl%ecx, %eax

cmpl4(%rdi), %edx

jl  .L3

rep ret



strength_result2:

movl(%rdi), %ecx

xorl%eax, %eax

.p2align 4,,10

.p2align 3

.L7:

movslq  8(%rdi), %rdx

addl%ecx, %eax

movl$2, (%rdi,%rdx,4)

cmpl4(%rdi), %eax

jl  .L7

rep ret

[Bug rtl-optimization/13355] Suboptimal code generated with global register variables

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 CC|steven at gcc dot gnu.org   |



--- Comment #11 from Steven Bosscher  2012-11-08 
22:50:51 UTC ---

So, not quite the code of comment #3, but LRA does appear to improve

things quite a bit.  I'll leave it to the OP to decide whether this

bug report is resolved sufficiently well to close it.

[Bug rtl-optimization/13355] Suboptimal code generated with global register variables

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 CC||steven at gcc dot gnu.org



--- Comment #10 from Steven Bosscher  2012-11-08 
22:46:53 UTC ---

(In reply to comment #1)

> Created attachment 5301 [details]

> example .c file that shows behavior with

>  gcc -march=i686 -mtune=i686 -fomit-frame-pointer -O2 test.c



GCC 4.7.1 compiles the two interesting functions in the test case to:



op_cmovl_EAX_T1_T0:

testl   %ebx, %ebx

je  .L2

movl%esi, 0(%ebp)

.L2:

ret



op_imull_EAX_T0:

subl$20, %esp

movl0(%ebp), %eax

imull   %ebx

movl%eax, (%esp)

movl%eax, 0(%ebp)

movl(%esp), %eax

movl%edx, 4(%esp)

movl%edx, 8(%ebp)

movl%eax, %edx

movl%eax, 8(%esp)

sarl$31, %edx

movl4(%esp), %eax

movl%edx, 12(%esp)

cmpl%eax, 12(%esp)

setne   %al

movzbl  %al, %eax

movl%eax, 32(%ebp)

addl$20, %esp

ret





Trunk r193340 produces the following:



op_cmovl_EAX_T1_T0:

testl   %ebx, %ebx

je  .L2

movl%esi, 0(%ebp)

.L2:

ret



op_imull_EAX_T0:

subl$12, %esp

movl%ebx, %eax

imull   0(%ebp)

movl%eax, 0(%ebp)

movl%eax, (%esp)

sarl$31, %eax

movl%eax, 4(%esp)

xorl%eax, %eax

cmpl%edx, 4(%esp)

movl%edx, 8(%ebp)

setne   %al

movl%eax, 32(%ebp)

addl$12, %esp

ret

[Bug rtl-optimization/13355] Suboptimal code generated with global register variables

[steven at gcc dot gnu.org]

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



--- Comment #9 from Steven Bosscher  2012-11-08 
22:41:41 UTC ---

(In reply to comment #6)

> A reduced testcase for the second case.

> On mainline, i686-pc-linux-gnu.

> 

> /* -march=i686 -mtune=i686 -fomit-frame-pointer -O2 */

> 

> register int ebx asm ("ebx");

> register int dummy1 asm ("esi");

> register int dummy2 asm ("ebp");

> 

> int

> foo (int arg)

> {

>   long long res = (long long) arg * (long long) ebx;

>   return (int) res;

> }

> 

> Global variables take up three registers from IA-32!



GCC 4.1, GCC 4.3, and GCC 4.7 compile this to:

foo:

subl$12, %esp

movl16(%esp), %eax

imull   %ebx

movl%eax, (%esp)

movl(%esp), %eax

movl%edx, 4(%esp)

addl$12, %esp

ret





Trunk r193340 compiles it to:

foo:

movl%ebx, %eax

imull   4(%esp)

ret

[Bug tree-optimization/18046] Missed jump threading optimization

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



   Last reconfirmed|2012-03-18 10:29:57 |2012-11-08 10:29:57



--- Comment #17 from Steven Bosscher  2012-11-08 
22:29:45 UTC ---

Will be addressed for GCC 4.9 by moving switch lowering to GIMPLE.

[Bug rtl-optimization/53908] [4.6 Regression] csa removes needed memory load

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #20 from Steven Bosscher  2012-11-08 
22:23:16 UTC ---

.

[Bug fortran/51727] Changing module files

[tobi at gcc dot gnu.org]

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

Tobias Schlüter  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #29 from Tobias Schlüter  2012-11-08 
22:21:48 UTC ---
I committed the C-only version of the patch as the issues mentioned in comment
#27 couldn't be addressed before stage3.

[Bug target/55243] STAMP variable is not defined in t-avr

[rolf.ebert.gcc at gmx dot de]

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



--- Comment #2 from Rolf Ebert  2012-11-08 
22:08:16 UTC ---

A complete build instruction is in 



http://arduino.ada-language.com/building-avr-gnat-for-avr-ada.html



I'll add a make output without the patch once I can build again (probably

tomorrow)

[Bug web/55237] Please implement gcc.gnu.org/r123456 URL shorts for fast SVN revision access

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-08

 CC||gerald at gcc dot gnu.org,

   ||steven at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Steven Bosscher  2012-11-08 
22:00:50 UTC ---

Good idea!

[Bug tree-optimization/55191] [4.8 Regression] ICE in compute_antic at tree-ssa-pre.c:2511

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #8 from Steven Bosscher  2012-11-08 
21:49:19 UTC ---

.

[Bug tree-optimization/55191] [4.8 Regression] ICE in compute_antic at tree-ssa-pre.c:2511

[steven at gcc dot gnu.org]

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



--- Comment #7 from Steven Bosscher  2012-11-08 
21:47:54 UTC ---

Author: steven

Date: Thu Nov  8 21:47:50 2012

New Revision: 193341



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

Log:

gcc/

PR tree-optimization/55191

* cfganal.c (connect_infinite_loops_to_exit): Call dfs_deadend here.

(flow_dfs_compute_reverse_execute): Don't call it here.



testsuite/

PR tree-optimization/55191

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







Added:

trunk/gcc/testsuite/gcc.dg/pr55191.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/cfganal.c

trunk/gcc/testsuite/ChangeLog

[Bug target/55243] New: STAMP variable is not defined in t-avr

[rolf.ebert.gcc at gmx dot de]

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



 Bug #: 55243

   Summary: STAMP variable is not defined in t-avr

Classification: Unclassified

   Product: gcc

   Version: 4.7.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: rolf.ebert@gmx.de





Building AVR cross compiler for Ada (GNAT) fails as t-avr contains no valid

command in the STAMP variable



easiest work-around is to replace it with 'echo' command.



sed -i -e 's/$(STAMP)/echo timestamp >/' gcc/config/avr/t-avr

[Bug c++/55240] [c++0x] ICE on non-static data member initialization using 'auto' variable from containing function

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #1 from Daniel Krügler  
2012-11-08 21:33:48 UTC ---
The ICE also exists for gcc 4.8.0 20121104 (experimental):

"4|internal compiler error: in expand_expr_real_1, at expr.c:9280|"

[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2

[frs.dumont at gmail dot com]

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

--- Comment #47 from frs.dumont at gmail dot com 2012-11-08 21:19:05 UTC ---
On 11/08/2012 03:25 AM, Paolo Carlini wrote:
> On 11/08/2012 02:56 AM, Paolo Carlini wrote:
>> On the other hand, the old-old code for rehash didn't use 
>> _M_growth_factor in these computations, it just literally enforced 
>> the post-conditions of the Standard. Are we sure we aren't so to 
>> speak rehashing too much? For example, when the load factor is very 
>> low and doesn't count, it looks like a current rehash(n) accomplishes 
>> the same of an old rehash(n * 2)?!? Something seems wrong, can you 
>> double check that? In any case the comments before _M_next_bkt would 
>> need fixing.
> ... in other terms, I really think that the only uses of 
> _S_growth_factor should return to be inside _M_need_rehash, because 
> that's the function called by the inserts, when the container must 
> automatically grow the number of buckets. Elsewhere, like the 
> constructors, rehash, should not need to know about _S_growth_factor.
>
> Paolo.
>
 I haven't yet considered the following emails but based on those 
good remarks I have done the attached patch. Surprisingly it seems to 
have a good impact on performance even if before it 
testsuite/performance/23_containers/insert/unordered_set.cc was showing 
that new implementation was better.

 I have also starting to adapt tests so that it's possible to check 
unordered performance with std or std::tr1 implementations. Can I 
generalize it to other tests ? If so, is it a good approach ?

François

[Bug preprocessor/55242] New: continued lines not always merged into one long line

[jlmuir at anl dot gov]

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



 Bug #: 55242

   Summary: continued lines not always merged into one long line

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: preprocessor

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: jlm...@anl.gov





Created attachment 28639

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28639

Small source file demonstrating bug



The preprocessor sometimes incorrectly handles a line continuation by not

joining a following line with the current line.



Attached is a simple C file called continued-line-test.c that demonstrates the

problem.  It contains the following three lines (the first two lines end with a

backslash):



struct {\

  int x;\

};



Running gcc on this file with the -E option produces the following:



$ gcc -E continued-line-test.c 

# 1 "continued-line-test.c"

# 1 ""

# 1 "continued-line-test.c"

struct {

  int x;};



As you can see, even though the first line in continued-line-test.c ended with

a backslash, the second line was not joined with the first line.



The preprocessor documentation

(http://gcc.gnu.org/onlinedocs/gcc-4.7.2/cpp/Initial-processing.html#Initial-processing)

says:



"Continued lines are merged into one long line.



"A continued line is a line which ends with a backslash, `\'.  The backslash is

removed and the following line is joined with the current one.  No space is

inserted, so you may split a line anywhere, even in the middle of a word.  (It

is generally more readable to split lines only at white space.)"



What I expected to see is the following:



$ gcc -E continued-line-test.c

# 1 "continued-line-test.c"

# 1 ""

# 1 "continued-line-test.c"

struct { int x;};



Here's the version information from GCC:



$ gcc -v

Using built-in specs.

COLLECT_GCC=/opt3/bin/gcc

COLLECT_LTO_WRAPPER=/opt3/libexec/gcc/x86_64-apple-darwin12/4.7.2/lto-wrapper

Target: x86_64-apple-darwin12

Configured with: ../gcc-4.7.2/configure --prefix=/opt3

--build=x86_64-apple-darwin12

--enable-languages=c,c++,objc,obj-c++,lto,fortran,java --libdir=/opt3/lib/gcc47

--includedir=/opt3/include/gcc47 --infodir=/opt3/share/info

--mandir=/opt3/share/man --datarootdir=/opt3/share/gcc-4.7

--with-libiconv-prefix=/opt3 --with-local-prefix=/opt3 --with-system-zlib

--disable-nls --program-suffix=-mp-4.7

--with-gxx-include-dir=/opt3/include/gcc47/c++/ --with-gmp=/opt3

--with-mpfr=/opt3 --with-mpc=/opt3 --with-ppl=/opt3 --with-cloog=/opt3

--enable-cloog-backend=isl --disable-cloog-version-check

--enable-stage1-checking --disable-multilib --enable-lto

--enable-libstdcxx-time --with-as=/opt3/bin/as --with-ld=/opt3/bin/ld

--with-ar=/opt3/bin/ar --with-bugurl=https://trac.macports.org/newticket

--disable-ppl-version-check --with-pkgversion='MacPorts gcc47 4.7.2_2'

Thread model: posix

gcc version 4.7.2 (MacPorts gcc47 4.7.2_2) 



I'm also able to reproduced this problem with GCC 4.6.3 on Ubuntu Linux 12.04.1

LTS.

[Bug debug/45882] No debug info for vars depending on unused parameter

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.7.0



--- Comment #3 from Jakub Jelinek  2012-11-08 
20:43:54 UTC ---

Fixed for 4.7+.

[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2

[frs.dumont at gmail dot com]

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

--- Comment #46 from frs.dumont at gmail dot com 2012-11-08 20:21:15 UTC ---
Attached patch applied to trunk and 4.7 branch.

2012-11-08  François Dumont  

 PR libstdc++/54075
 * include/bits/hashtable.h (_Hashtable<>::rehash): Reset hash
 policy state if no rehash.
 * testsuite/23_containers/unordered_set/modifiers/reserve.cc
 (test02): New.


François

On 11/08/2012 01:58 AM, Jonathan Wakely wrote:
> On 7 November 2012 22:02, François Dumont wrote:
>> Ok to commit ? If so, where ?
> That patch is OK for trunk and 4.7, thanks.
>

[Bug debug/53145] [4.8 Regression] gcc.dg/pch/save-temps-1.c

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2012-11-08 
20:20:33 UTC ---

Author: jakub

Date: Thu Nov  8 20:20:10 2012

New Revision: 193340



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

Log:

PR debug/53145

* dwarf2out.c (gen_compile_unit_die): Don't call gen_producer_string

here, instead add "" if producer_string is NULL.

(dwarf2out_finish): Call gen_producer_string here, unconditionally

decrease refcount of the old indirect string and set val_str to

find_AT_string result.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/dwarf2out.c

[Bug target/54308] [4.8 regression] build regression in 190498 on ppc64/linux: legitimate_indirect_address_p undefined

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC||jakub at gcc dot gnu.org

 Resolution||FIXED



--- Comment #10 from Jakub Jelinek  2012-11-08 
20:19:00 UTC ---

Fixed.

[Bug driver/54789] [4.8 Regression] Error in GCC driver when defining GCC_COMPARE_DEBUG

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||jakub at gcc dot gnu.org

 Resolution||FIXED



--- Comment #6 from Jakub Jelinek  2012-11-08 
20:18:15 UTC ---

Fixed.

[Bug debug/54499] [4.8 Regression] GCC produces wrong debugging information, failure while assembling generated .s file

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #6 from Jakub Jelinek  2012-11-08 
20:17:46 UTC ---

Fixed.

[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization

[jakub at gcc dot gnu.org]

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



--- Comment #11 from Jakub Jelinek  2012-11-08 
20:16:54 UTC ---

(In reply to comment #10)

> (In reply to comment #3)

> > If it is valid, the series of foldings that result into the overflow are 
> > first

> > folding sizeof (int) - 1UL into sizeof (int) + 18446744073709551615UL and 
> > later

> > on conversion of -1 + (int) (sizeof (int) + 18446744073709551615UL) to

> > -1 + (int) sizeof (int) + (int) 18446744073709551615UL.

> 

> Under C++ semantics, this folding introduces implementation-defined behavior,

> not undefined behavior, so it's still a constant-expression; conversion to a

> signed integer is different from overflow in the language.  I have been 
> working

> around this difference between back end and language semantics in

> cxx_eval_constant_expression by unsetting TREE_OVERFLOW after folding 
> NOP_EXPR,

> but that doesn't help this example.

> 

> The semantics of overflow and conversion to signed integer are different in C

> as well; the only difference from C++ is that C allows the implementation to

> trap *or* produce an implementation-defined value.  Perhaps we could

> distinguish them in the compiler as well...



In this case I think it is really a bug in fold-const.c, as can be seen on the

miscompiled testcase there (provided it is valid C resp. C++).

See http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00636.html

[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2

[fdumont at gcc dot gnu.org]

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

--- Comment #45 from François Dumont  2012-11-08 
20:16:15 UTC ---
Author: fdumont
Date: Thu Nov  8 20:16:04 2012
New Revision: 193339

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193339
Log:
2012-11-08  François Dumont  

PR libstdc++/54075
* include/bits/hashtable.h (_Hashtable<>::rehash): Reset hash
policy state if no rehash.
* testsuite/23_containers/unordered_set/modifiers/reserve.cc
(test02): New.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/hashtable.h
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/modifiers/reserve.cc

[Bug debug/54499] [4.8 Regression] GCC produces wrong debugging information, failure while assembling generated .s file

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2012-11-08 
20:15:12 UTC ---

Author: jakub

Date: Thu Nov  8 20:15:06 2012

New Revision: 193338



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

Log:

PR debug/54499

* cgraphunit.c (assemble_thunk): Don't call source_line debug hook

here, instead call insn_locations_{init,finalize} and initialize

prologue_location.



* g++.dg/debug/pr54499.C: New test.



Added:

trunk/gcc/testsuite/g++.dg/debug/pr54499.C

Modified:

trunk/gcc/ChangeLog

trunk/gcc/cgraphunit.c

trunk/gcc/testsuite/ChangeLog

[Bug driver/54789] [4.8 Regression] Error in GCC driver when defining GCC_COMPARE_DEBUG

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2012-11-08 
20:13:17 UTC ---

Author: jakub

Date: Thu Nov  8 20:13:13 2012

New Revision: 193337



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

Log:

PR driver/54789

* gcc.c (process_command): Use save_switch for synthesized

-fcompare-debug=* option; mark the switch as known.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/gcc.c

[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization

[jason at gcc dot gnu.org]

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



--- Comment #10 from Jason Merrill  2012-11-08 
20:10:09 UTC ---

(In reply to comment #3)

> If it is valid, the series of foldings that result into the overflow are first

> folding sizeof (int) - 1UL into sizeof (int) + 18446744073709551615UL and 
> later

> on conversion of -1 + (int) (sizeof (int) + 18446744073709551615UL) to

> -1 + (int) sizeof (int) + (int) 18446744073709551615UL.



Under C++ semantics, this folding introduces implementation-defined behavior,

not undefined behavior, so it's still a constant-expression; conversion to a

signed integer is different from overflow in the language.  I have been working

around this difference between back end and language semantics in

cxx_eval_constant_expression by unsetting TREE_OVERFLOW after folding NOP_EXPR,

but that doesn't help this example.



The semantics of overflow and conversion to signed integer are different in C

as well; the only difference from C++ is that C allows the implementation to

trap *or* produce an implementation-defined value.  Perhaps we could

distinguish them in the compiler as well...

[Bug target/54308] [4.8 regression] build regression in 190498 on ppc64/linux: legitimate_indirect_address_p undefined

[jakub at gcc dot gnu.org]

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



--- Comment #9 from Jakub Jelinek  2012-11-08 
20:09:20 UTC ---

Author: jakub

Date: Thu Nov  8 20:09:14 2012

New Revision: 193336



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

Log:

PR target/54308

* config/rs6000/rs6000.c (legitimate_indirect_address_p): Remove

inline keyword.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/rs6000/rs6000.c

[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2

[fdumont at gcc dot gnu.org]

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

--- Comment #44 from François Dumont  2012-11-08 
20:06:08 UTC ---
Author: fdumont
Date: Thu Nov  8 20:06:00 2012
New Revision: 193335

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193335
Log:
2012-11-08  François Dumont  

PR libstdc++/54075
* include/bits/hashtable.h (_Hashtable<>::rehash): Reset hash
policy state if no rehash.
* testsuite/23_containers/unordered_set/modifiers/reserve.cc
(test02): New.

Modified:
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
branches/gcc-4_7-branch/libstdc++-v3/include/bits/hashtable.h
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/unordered_set/modifiers/reserve.cc

[Bug tree-optimization/55238] ICE in find_aggregate_values_for_callers_subset, at ipa-cp.c:2908 building zlib

[Joost.VandeVondele at mat dot ethz.ch]

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



Joost VandeVondele  changed:



   What|Removed |Added



 CC||Joost.VandeVondele at mat

   ||dot ethz.ch



--- Comment #3 from Joost VandeVondele  
2012-11-08 19:27:22 UTC ---

gfortran -O3 also aborts on this testcase at the same location



MODULE dbcsr_dist_operations

  TYPE dbcsr_type

LOGICAL :: symmetry

  END TYPE

CONTAINS

  SUBROUTINE get_stored_coordinates_type(matrix,&

  transpose, processor)

TYPE(dbcsr_type), INTENT(IN) :: matrix

LOGICAL, INTENT(INOUT)   :: transpose

INTEGER, INTENT(OUT), OPTIONAL   :: processor

LOGICAL :: checker_tr

IF (PRESENT (processor)) THEN

   IF (matrix%symmetry .AND. checker_tr()) THEN

  processor = dbcsr_distribution_processor ()

   ENDIF

ENDIF

  END SUBROUTINE get_stored_coordinates_type

  SUBROUTINE get_block_index_type(matrix, transpose)

TYPE(dbcsr_type), INTENT(IN) :: matrix

LOGICAL, INTENT(OUT) :: transpose

transpose = .FALSE.

CALL get_stored_coordinates_type (matrix, transpose)

  END SUBROUTINE get_block_index_type

END MODULE dbcsr_dist_operations

[Bug tree-optimization/55238] ICE in find_aggregate_values_for_callers_subset, at ipa-cp.c:2908 building zlib

[jamborm at gcc dot gnu.org]

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



--- Comment #2 from Martin Jambor  2012-11-08 
17:33:11 UTC ---

Created attachment 28637

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28637

Untested patch



This is the fix I am currently bootstrapping and testing.

[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

[ebotcazou at gcc dot gnu.org]

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



--- Comment #27 from Eric Botcazou  2012-11-08 
17:17:35 UTC ---

> No, this would be one giant kludge by itself. The failure just shows that the

> controversial patch [1] for PR 49721 was wrong.

> 

> Quote from [1]:

> 

> --quote--

> I am checking in this patch, which only affects x32

> and nothing else.  This one character change, from

> 

> POINTERS_EXTEND_UNSIGNED < 0

> 

> to

> 

> POINTERS_EXTEND_UNSIGNED != 0

> 

> creates a working x32 GCC. This isn't perfect. I have

> tried many different approaches without any success.

> I will revisit it if we run into any problems with x32

> applications.

> --/qoute--

> 

> So, we run into problem.



It's not totally wrong, given the context of convert_memory_address_addr_space

which is already optimistically correct only.  The problem is that the case

POINTERS_EXTEND_UNSIGNED > 0 is trickier than POINTERS_EXTEND_UNSIGNED == 0

because RTL constants are sign-extended: in the latter case, everything is

sign-extended so this is symmetric and simple; in the former case, one part is

zero-extended and the other part sign-extended and, in order to make this work

under the same hypothesis of non-overflow, one would need to know which part is

bigger.  In the case at hand, the code would be correct if the constant was

zero-extended and the register sign-extended, not the reverse as currently.

[Bug rtl-optimization/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os

[bernds at gcc dot gnu.org]

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



--- Comment #13 from Bernd Schmidt  2012-11-08 
17:10:34 UTC ---

Author: bernds

Date: Thu Nov  8 17:10:26 2012

New Revision: 193332



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

Log:

PR rtl-optimization/54850

* sched-deps.c (find_inc): Add all dependencies from the inc_insn

to the mem_insn.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/sched-deps.c

[Bug fortran/48636] Enable more inlining with -O2 and higher

[hubicka at gcc dot gnu.org]

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



--- Comment #35 from Jan Hubicka  2012-11-08 
16:46:28 UTC ---

Author: hubicka

Date: Thu Nov  8 16:46:18 2012

New Revision: 193331



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

Log:

PR middle-end/48636

* ipa-inline.c (big_speedup_p): New function.

(want_inline_small_function_p): Use it.

(edge_badness): Dump it.

* params.def (inline-min-speedup): New parameter.

* doc/invoke.texi (inline-min-speedup): Document.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/doc/invoke.texi

trunk/gcc/ipa-inline.c

trunk/gcc/params.def

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/gcc.dg/winline-3.c

[Bug lto/54966] Does LTO requires a larger inline-unit-growth?

[hubicka at gcc dot gnu.org]

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



Jan Hubicka  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2012-11-08

 Ever Confirmed|0   |1



--- Comment #7 from Jan Hubicka  2012-11-08 
16:44:36 UTC ---

The inline metrics for 4.8 was changed significandly, I would be curious if

your application now behaves better (or worse)?

[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

[ubizjak at gmail dot com]

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



--- Comment #26 from Uros Bizjak  2012-11-08 16:34:27 
UTC ---

> I think the most robust solution would be to always zero-extend the addresses

> for -mx32, i.e. output

>   movl%ecx, -1073743664(%eax)

> even if the address is a PLUS in DImode.  Otherwise, we're left with 
> kludges...



Also, please note that the failure is with -maddress-mode=long. This flag was

introduced with the intention to get rid of as many 0x67 address size prefixes

as possible.



The problem is even listed at the bottom of x32-abi project page [1].



[1] https://sites.google.com/site/x32abi/

[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

[ubizjak at gmail dot com]

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



--- Comment #25 from Uros Bizjak  2012-11-08 16:24:12 
UTC ---

(In reply to comment #24)



> I think the most robust solution would be to always zero-extend the addresses

> for -mx32, i.e. output

>   movl%ecx, -1073743664(%eax)

> even if the address is a PLUS in DImode.  Otherwise, we're left with 
> kludges...



No, this would be one giant kludge by itself. The failure just shows that the

controversial patch [1] for PR 49721 was wrong.



Quote from [1]:



--quote--

I am checking in this patch, which only affects x32

and nothing else.  This one character change, from



POINTERS_EXTEND_UNSIGNED < 0



to



POINTERS_EXTEND_UNSIGNED != 0



creates a working x32 GCC. This isn't perfect. I have

tried many different approaches without any success.

I will revisit it if we run into any problems with x32

applications.

--/qoute--



So, we run into problem.



[1] http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01618.html

[Bug tree-optimization/55236] [4.8 Regression] gcc.c-torture/execute/pr22493-1.c FAILs with -fPIC

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-11-08

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

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2012-11-08 
16:18:08 UTC ---

Created attachment 28636

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28636

gcc48-pr55236.patch



Started with my inter-bb range test optimization, but as the attached testcase

shows, if written in a single stmt, even gcc 3.4 miscompiles it.

[Bug rtl-optimization/55177] missed optimizations with __builtin_bswap

[ebotcazou at gcc dot gnu.org]

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



--- Comment #8 from Eric Botcazou  2012-11-08 
16:14:23 UTC ---

> I think I have the GCC version checks right there, for the availability of the

> builtins? That is, __builtin_bswap32() and __builtin_bswap64() since GCC 4.4,

> and __builtin_bswap16() since GCC 4.6 on PowerPC or GCC 4.9 on other 
> platforms?



4.8 on other platforms.

[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

[ebotcazou at gcc dot gnu.org]

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



--- Comment #24 from Eric Botcazou  2012-11-08 
16:11:25 UTC ---

> I applied i386 change at

> 

> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28591

> 

> to compile it:

> 

> [hjl@gnu-tools-1 tmp]$ /export/build/gnu/gcc/release/usr/gcc-4.8.0/bin/gcc

> -mtune=generic -march=x86-64 -maddress-mode=long -mx32 -O2 -fPIC rtld.c

> -std=gnu99 -fgnu89-inline  -S

> [hjl@gnu-tools-1 tmp]$  egrep ", -[0-9]*\(%rax" rtld.s 

> movl%ecx, -1073743664(%rax)

> movl%ecx, -1073742592(%rax)

> movl%edx, -1073743664(%rax)

> movl%edx, -1073742592(%rax)

> [hjl@gnu-tools-1 tmp]$ 

> 

> All those stores should be zero-extended.



OK, thanks.  Everything is correctly zero-extended until:



case PLUS:

case MULT:

  /* FIXME: For addition, we used to permute the conversion and

 addition operation only if one operand is a constant and

 converting the constant does not change it or if one operand

 is a constant and we are using a ptr_extend instruction

 (POINTERS_EXTEND_UNSIGNED < 0) even if the resulting address

 may overflow/underflow.  We relax the condition to include

 zero-extend (POINTERS_EXTEND_UNSIGNED > 0) since the other

 parts of the compiler depend on it.  See PR 49721.



 We can always safely permute them if we are making the address

 narrower.  */

  if (GET_MODE_SIZE (to_mode) < GET_MODE_SIZE (from_mode)

  || (GET_CODE (x) == PLUS

  && CONST_INT_P (XEXP (x, 1))

  && (POINTERS_EXTEND_UNSIGNED != 0

  || XEXP (x, 1) == convert_memory_address_addr_space

  (to_mode, XEXP (x, 1), as

return gen_rtx_fmt_ee (GET_CODE (x), to_mode,

   convert_memory_address_addr_space

 (to_mode, XEXP (x, 0), as),

   XEXP (x, 1));

  break;



It's clear that the distribution is invalid, whatever POINTERS_EXTEND_UNSIGNED

is defined to.  It becomes valid only under conditions of non-overflow that

depend upon the value of POINTERS_EXTEND_UNSIGNED, as stated in the head

comment of the function.



If POINTERS_EXTEND_UNSIGNED, it's valid if there is no overflow in the address.



If POINTERS_EXTEND_UNSIGNED > 0, it's valid if either the constant is positive

(and there is no overflow in the address) or the constant is negative and the

variable part is sufficiently large.  The condition aren't fulfilled here since

the constant is very large negative and the variable part small.



I think the most robust solution would be to always zero-extend the addresses

for -mx32, i.e. output

  movl%ecx, -1073743664(%eax)

even if the address is a PLUS in DImode.  Otherwise, we're left with kludges...

[Bug fortran/51727] Changing module files

[tobi at gcc dot gnu.org]

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

--- Comment #28 from Tobias Schlüter  2012-11-08 
15:46:13 UTC ---
Author: tobi
Date: Thu Nov  8 15:46:07 2012
New Revision: 193329

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193329
Log:
PR fortran/51727
* module.c (sorted_pointer_info): New.
(gfc_get_sorted_pointer_info): New.
(free_sorted_pointer_info_tree): New.
(compare_sorted_pointer_info): New.
(find_symbols_to_write): New.
(write_symbol1_recursion): New.
(write_symbol1): Collect symbols that need writing, output in order.
(write_generic): Traverse tree in order.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c

[Bug c++/55239] Spurious "unused variable" warning on function-local objects with a destructor and an initializer

[redi at gcc dot gnu.org]

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



--- Comment #7 from Jonathan Wakely  2012-11-08 
15:21:40 UTC ---

Paolo's been very busy recently, cleaning up loads of longstanding bugs like

that

[Bug c++/55239] Spurious "unused variable" warning on function-local objects with a destructor and an initializer

[paolo.carlini at oracle dot com]

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



--- Comment #6 from Paolo Carlini  2012-11-08 
15:20:37 UTC ---

Understandable: the kind of work I have been doing lately at times is pretty

weird ;)

[Bug c++/55239] Spurious "unused variable" warning on function-local objects with a destructor and an initializer

[bisqwit at iki dot fi]

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



--- Comment #5 from Joel Yliluoma  2012-11-08 15:16:48 
UTC ---

Nice. I had no idea this was first reported in 2003 and fixed in 2012 in a

version recent enough to be still unreleased :)

[Bug c++/55239] Spurious "unused variable" warning on function-local objects with a destructor and an initializer

[redi at gcc dot gnu.org]

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



--- Comment #4 from Jonathan Wakely  2012-11-08 
15:14:25 UTC ---

Oops, thanks, Paolo!

[Bug c++/55241] New: [C++11] diagnostics show sizeof...(T) as sizeof(T...)

[redi at gcc dot gnu.org]

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



 Bug #: 55241

   Summary: [C++11] diagnostics show sizeof...(T) as sizeof(T...)

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: diagnostic

  Severity: minor

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: r...@gcc.gnu.org





template

  using Num = int;



template

  using Count = Num;



Count i;



This is incorrectly rejected by current trunk due to Bug 54859, which reveals

that the diagnostic shows sizeof(T...) not sizeof...(T)



e.C:5:33: error: integral expression 'sizeof (T ...)' is not constant

[Bug c++/54859] [4.8 Regression] constexpr in template alias rejected as non-constant

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Keywords||rejects-valid

 CC||redi at gcc dot gnu.org



--- Comment #3 from Jonathan Wakely  2012-11-08 
15:08:15 UTC ---

template

  using Num = int;



template

  using Count = Num;



Count i;





This claims sizeof is not a constant:

e.C:5:37: error: integral expression 'sizeof (Types ...)' is not constant

[Bug c++/55239] Spurious "unused variable" warning on function-local objects with a destructor and an initializer

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||DUPLICATE



--- Comment #3 from Paolo Carlini  2012-11-08 
15:06:14 UTC ---

Yes.



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

[Bug c++/10416] 'unused variable' warning ignores ctor/dtor side-effects

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||bisqwit at iki dot fi



--- Comment #14 from Paolo Carlini  2012-11-08 
15:06:14 UTC ---

*** Bug 55239 has been marked as a duplicate of this bug. ***

[Bug c++/55239] Spurious "unused variable" warning on function-local objects with a destructor and an initializer

[paolo.carlini at oracle dot com]

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



--- Comment #2 from Paolo Carlini  2012-11-08 
15:04:05 UTC ---

I fixed this in mainline, didn't I?

[Bug tree-optimization/55238] ICE in find_aggregate_values_for_callers_subset, at ipa-cp.c:2908 building zlib

[jamborm at gcc dot gnu.org]

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



Martin Jambor  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-11-08

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

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from Martin Jambor  2012-11-08 
15:01:27 UTC ---

Confirmed and mine.

[Bug fortran/51976] [F2003] Support deferred-length character components of derived types (allocatable string length)

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #6 from Tobias Burnus  2012-11-08 
15:00:05 UTC ---

Note that after this feature works, we have to ensure that FORALL with a

generated temporary works with different string lengths:



  type t

character(len=:), pointer :: str

  end type t

  type(t), pointer :: strarry(:), strarray2



  allocate(strarray(3), strarray2)

  allocate(character(len=5) :: strarray(1)%str, strarray2(1)%str)

  allocate(character(len=7) :: strarray(2)%str, strarray2(2)%str)

  allocate(character(len=2) :: strarray(2)%str, strarray2(3)%str)



  forall(i=1:3) strarray2(i)%str = strarray(i)%str

[Bug c++/55240] [c++0x] ICE on non-static data member initialization using 'auto' variable from containing function

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-08

 Ever Confirmed|0   |1

[Bug c++/55239] Spurious "unused variable" warning on function-local objects with a destructor and an initializer

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Keywords||diagnostic

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-08

 Ever Confirmed|0   |1



--- Comment #1 from Jonathan Wakely  2012-11-08 
14:46:56 UTC ---

Yes, annoying.



Giving the type a user-defined constructor makes the warning go away.  A

user-defined destructor should have the same effect.

[Bug tree-optimization/53787] Possible IPA-SRA / IPA-CP improvement

[jamborm at gcc dot gnu.org]

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



Martin Jambor  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #13 from Martin Jambor  2012-11-08 
14:43:41 UTC ---

So, this now works as expected, the testcase is even in the testsuite.

The creation of aggregate jump function is still quite rudimentary so

it is possible that in more complex scenarios, the propagation might

not take place (testcases welcome) and even in the propagation phase

there are still a few things wanting.  Nevertheless, those potential

shortcomings should be subjects to separate requests/PRs/whatever.



Thanks for reporting and for the testcase.

[Bug c++/55240] New: [c++0x] ICE on non-static data member initialization using 'auto' variable from containing function

[bisqwit at iki dot fi]

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



 Bug #: 55240

   Summary: [c++0x] ICE on non-static data member initialization

using 'auto' variable from containing function

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: bisq...@iki.fi





This code causes an ICE in GCC 4.7.1 and 4.7.2:



int main()

{

int q = 1;

struct test { int x = q; } instance;

}



tmpq.cc: In constructor 'constexpr main()::test::test()':

tmpq.cc:4:12: internal compiler error: in expand_expr_real_1, at expr.c:9122



It is notable that if the code is written like this, the error message changes.



int main()

{

int q = 1;

struct test { int x; test():x(q){} } instance;

}



tmpq.cc:5:35: error: use of 'auto' variable from containing function

tmpq.cc:3:9: error:   'int q' declared here

[Bug rtl-optimization/55177] missed optimizations with __builtin_bswap

[dwmw2 at infradead dot org]

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



--- Comment #7 from David Woodhouse  2012-11-08 
14:29:37 UTC ---

Linux kernel patch to use the builtins at

http://marc.info/?l=linux-arch&m=135212414925921&w=2



I think I have the GCC version checks right there, for the availability of the

builtins? That is, __builtin_bswap32() and __builtin_bswap64() since GCC 4.4,

and __builtin_bswap16() since GCC 4.6 on PowerPC or GCC 4.9 on other platforms?

[Bug c++/55239] New: Spurious "unused variable" warning on function-local objects with a destructor and an initializer

[bisqwit at iki dot fi]

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



 Bug #: 55239

   Summary: Spurious "unused variable" warning on function-local

objects with a destructor and an initializer

Classification: Unclassified

   Product: gcc

   Version: 4.7.1

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: bisq...@iki.fi





In the code below, a function-local object is declared with a destructor whose

role is to ensure that some action is taken at the end of the scope, no matter

which route the function is exited.



#include 

void LoadSomeFile(const char* fn)

{

/* Open file */

FILE* fp = fopen(fn, "rb");

/* Ensure that the file is automatically closed no matter which path

this function is exited */

struct closer { FILE* f;  ~closer() { if(f) fclose(f); }

  } autoclosefp = {fp};

/* Some code here that deals with fp, and may include several "return;"

clauses */

}

int main() { LoadSomeFile(__FILE__); } // test



Bug GCC gives a spurious "unused variable 'autoclosefp'" for this code,

implying that autoclosefp has no function. It does. Without it, the file would

not be closed and resources would be leaked.



The problem also occurs, when the code is rewritten like this:



#include 

void LoadSomeFile(const char* fn)

{

/* Open file */

FILE* fp = fopen(fn, "rb");

/* Ensure that the file is automatically closed no matter which path

this function is exited */

struct closer { FILE* f;  ~closer() { if(f) fclose(f); } };

closer autoclosefp = {fp};

/* Some code here that deals with fp, and may include several "return;"

clauses */

}

int main() { LoadSomeFile(__FILE__); } // test



Changing the "= {fp}" into C++11 style "{fp}" does not take away the warning,

either.



Only changing the initialization-by-initializer into an member-assignment takes

away the warning.



#include 

void LoadSomeFile(const char* fn)

{

/* Open file */

FILE* fp = fopen(fn, "rb");

/* Ensure that the file is automatically closed no matter which path

this function is exited */

struct closer { FILE* f;  ~closer() { if(f) fclose(f); } } autoclosefp;

autoclosefp.f = fp;

/* Some code here that deals with fp, and may include several "return;"

clauses */

}

int main() { LoadSomeFile(__FILE__); } // test



I would argue that this is inconvenient, and wrong behavior on GCC.



Tested and verified on GCC 3.3 through 4.7.1. The -Wunused-variable (or -Wall)

option is required.

[Bug fortran/54881] [4.8 Regression] [OOP] ICE in fold_convert_loc, at fold-const.c:2016

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



   Priority|P3  |P4

 CC||jakub at gcc dot gnu.org

[Bug middle-end/44786] -fsanitize=undefined: Turn on runtime code generation to check for undefined behavior

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

Summary|-fcatch-undefined-behavior: |-fsanitize=undefined: Turn
   |Turn on runtime code|on runtime code generation
   |generation to check for |to check for undefined
   |undefined behavior  |behavior

--- Comment #7 from Manuel López-Ibáñez  2012-11-08 
13:21:54 UTC ---
> It didn't get very far (haven't looked deeper yet):

This PR is for implementing those checks in GCC. For things broken in GCC, you
should open new PRs.

BTW, Clang now supports all these checks:

-fsanitize=alignment: Use of a misaligned pointer or creation of a
misaligned reference.
-fsanitize=divide-by-zero: Division by zero.
-fsanitize=float-cast-overflow: Conversion to, from, or between
floating-point types which would overflow the destination.
-fsanitize=null: Use of a null pointer or creation of a null reference.
-fsanitize=object-size: An attempt to use bytes which the optimizer can
determine are not part of the object being accessed. The sizes of objects are
determined using __builtin_object_size, and consequently may be able to detect
more problems at higher optimization levels.
-fsanitize=return: In C++, reaching the end of a value-returning function
without returning a value.
-fsanitize=shift: Shift operators where the amount shifted is greater or
equal to the promoted bit-width of the left hand side or less than zero, or
where the left hand side is negative. For a signed left shift, also checks for
signed overflow in C, and for unsigned overflow in C++.
-fsanitize=signed-integer-overflow: Signed integer overflow, including all
the checks added by -ftrapv, and checking for overflow in signed division
(INT_MIN / -1).
-fsanitize=unreachable: If control flow reaches __builtin_unreachable.
-fsanitize=vla-bound: A variable-length array whose bound does not evaluate
to a positive value.
-fsanitize=vptr: Use of an object whose vptr indicates that it is of the
wrong dynamic type, or that its lifetime has not begun or has ended.
Incompatible with -fno-rtti.

[Bug rtl-optimization/55153] [4.8 Regression] ICE: in begin_move_insn, at sched-ebb.c:205 with -fsched2-use-superblocks and __builtin_prefetch

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0

[Bug middle-end/55235] [4.8 Regression] FAIL: gcc.target/i386/pr44948-2a.c

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC||jakub at gcc dot gnu.org

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #7 from Jakub Jelinek  2012-11-08 
13:12:56 UTC ---

Fixed.

[Bug middle-end/44786] -fcatch-undefined-behavior: Turn on runtime code generation to check for undefined behavior

[markus at trippelsdorf dot de]

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



Markus Trippelsdorf  changed:



   What|Removed |Added



 CC||markus at trippelsdorf dot

   ||de



--- Comment #6 from Markus Trippelsdorf  
2012-11-08 12:53:17 UTC ---

Just for fun, today I've build gcc trunk with:

CC="clang -fsanitize=undefined -w" CXX="clang++ -fsanitize=undefined -w"

~/gcc/configure --disable-bootstrap --disable-werror --disable-multilib

--enable-languages=c,c++





It didn't get very far (haven't looked deeper yet):



gcc/libiberty/regex.c:6968:11: fatal error: left shift of negative value -1



gcc/gcc/genattrtab.c:625:27: fatal error: signed integer overflow: 4568797 *

613 cannot be represented in type 'int'



gcc/gcc/genautomata.c:3510:23: fatal error: shift exponent 64 is too large for

64-bit type 'set_el_t' (aka 'unsigned long')

[Bug target/54564] [4.8 Regression] Broken __builtin_ia32_vfmadds[sd]3

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #12 from Jakub Jelinek  2012-11-08 
12:35:55 UTC ---

Fixed.

[Bug debug/54499] [4.8 Regression] GCC produces wrong debugging information, failure while assembling generated .s file

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |

[Bug debug/54499] [4.8 Regression] GCC produces wrong debugging information, failure while assembling generated .s file

[jakub at gcc dot gnu.org]

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



--- Comment #4 from Jakub Jelinek  2012-11-08 
12:30:21 UTC ---

Created attachment 28635

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28635

gcc48-pr54499.patch



That change looks very much broken to me, this should hopefully fix it

properly.

[Bug middle-end/53518] [4.8 regression] testsuite_abi_check.cc doesn't compile

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|WAITING |RESOLVED

 Resolution||FIXED



--- Comment #10 from Jakub Jelinek  2012-11-08 
12:28:56 UTC ---

Fixed then.

[Bug middle-end/53518] [4.8 regression] testsuite_abi_check.cc doesn't compile

[ro at CeBiTec dot Uni-Bielefeld.DE]

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



--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-11-08 12:27:20 UTC ---

> --- Comment #8 from Jakub Jelinek  2012-11-07 
> 18:20:16 UTC ---

> (In reply to comment #7)

[...]

> I don't see such a failure in

> http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00497.html , so fixed now?



Right, seems it got fixed between 20120921 and 20120928.



Rainer

[Bug debug/54519] [4.6/4.7 Regression] Debug info quality regression due to (pointless) partial inlining

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED

Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] Debug

   |Debug info quality  |info quality regression due

   |regression due to   |to (pointless) partial

   |(pointless) partial |inlining

   |inlining|



--- Comment #5 from Jakub Jelinek  2012-11-08 
12:25:52 UTC ---

Fixed for trunk, not planning a backport.

[Bug tree-optimization/55006] [4.8 Regression] aermod.f90 is miscompiled with '-m64 -O2 -funroll-loops' after revision 192526

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Target|x86_64-apple-darwin10   |x86_64-*-*

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-08

   Host|x86_64-apple-darwin10   |

 Ever Confirmed|0   |1

  Build|x86_64-apple-darwin10   |



--- Comment #4 from Dominique d'Humieres  2012-11-08 
12:06:43 UTC ---

> It's also can be seen for x86_64-unknown-linux-gnu. In particular, 447.dealII

> fails with -O3 and -funroll-loops



So changing target to x86_64-*-* and status to new.



Note that this PR blocks the testing of the polyhedron suite with

-funroll-loops.

[Bug tree-optimization/55238] New: ICE in find_aggregate_values_for_callers_subset, at ipa-cp.c:2908 building zlib

[rmansfield at qnx dot com]

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

 Bug #: 55238
   Summary: ICE in find_aggregate_values_for_callers_subset, at
ipa-cp.c:2908 building zlib
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rmansfi...@qnx.com
CC: jamb...@gcc.gnu.org


Created attachment 28634
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28634
preprocessed src

$ ./xgcc -B. -O3 ~/ice.i
/home/ryan/ice.i:15:11: error: unknown type name ‘gz_statep’
 gz_reset (gz_statep state)
   ^
ryan@zoidberg:~/gnu/gcc/trunk/tmp/gcc$ ./xgcc -B. -O3 ~/ice.i
/home/ryan/ice.i:42:1: internal compiler error: in
find_aggregate_values_for_callers_subset, at ipa-cp.c:2908
 }
 ^
0xd01072 find_aggregate_values_for_callers_subset
../../gcc/ipa-cp.c:2908
0xd01072 decide_about_value
../../gcc/ipa-cp.c:3255
0xd01072 decide_about_value
../../gcc/ipa-cp.c:3195
0xd02acb decide_whether_version_node
../../gcc/ipa-cp.c:3301
0xd02acb ipcp_decision_stage
../../gcc/ipa-cp.c:3441
0xd02acb ipcp_driver
../../gcc/ipa-cp.c:3483
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug debug/54499] [4.8 Regression] GCC produces wrong debugging information, failure while assembling generated .s file

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-08

 CC||jakub at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #3 from Jakub Jelinek  2012-11-08 
11:50:36 UTC ---

Broken by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190190