[Bug middle-end/55585] New: compile time hog at -O1 -fboundscheck -g

[Joost.VandeVondele at mat dot ethz.ch]

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



 Bug #: 55585

   Summary: compile time hog at -O1 -fboundscheck -g

Classification: Unclassified

   Product: gcc

   Version: 4.7.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

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

ReportedBy: joost.vandevond...@mat.ethz.ch





Created attachment 28870

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

gzipped testcase



With 4.4.6 the following timings are seen:



time /usr/bin/gfortran -c -O0 slow.f90 

real0m2.299s

time /usr/bin/gfortran -c -O1 -fbounds-check slow.f90 

real0m16.560s

time /usr/bin/gfortran -c -g -O2 -fbounds-check slow.f90 

real0m32.841s





With 4.7 I see significant slowdowns at -O1 -fbounds-check, being extreme with

-g



time gfortran -c -O0 slow.f90 

real0m3.355s

time gfortran -c -O1 -fbounds-check slow.f90 

real0m43.057s

time gfortran -c -g -O1 -fbounds-check slow.f90 

real3m42.117s

time gfortran -c -g -O2 -fbounds-check  slow.f90 

real0m20.102s





I wonder if whatever pass makes -O2 so fast should not be implied at -O1

-fbounds-check.

[Bug debug/55586] New: Incorrect .debug_line section for function with variable number of arguments in PowerPC

[pam at oktetlabs dot ru]

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



 Bug #: 55586

   Summary: Incorrect .debug_line section for function with

variable number of arguments in PowerPC

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: debug

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

ReportedBy: p...@oktetlabs.ru





This is PowerPC problem.



Example:

Code:

int

my_function(int x, ...)

{

return x+1;

}





dwarfdump for this code shows the following .debug_line section:

...

0x01800490  [   3, 0] NS uri: "1.c"

0x018004bc  [   3, 0] NS

0x018004e0  [   4, 0] NS

...



Disassembler in GDB shows:

(gdb) disass my_function

Dump of assembler code for function my_function:

   0x01800490 <+0>:stwur1,-120(r1)

   0x01800494 <+4>:stw r31,116(r1)

   0x01800498 <+8>:mr  r31,r1

   0x0180049c <+12>:stw r4,12(r31)

   0x018004a0 <+16>:stw r5,16(r31)

   0x018004a4 <+20>:stw r6,20(r31)

   0x018004a8 <+24>:stw r7,24(r31)

   0x018004ac <+28>:stw r8,28(r31)

   0x018004b0 <+32>:stw r9,32(r31)

   0x018004b4 <+36>:stw r10,36(r31)

   0x018004b8 <+40>:bne cr1,0x18004dc 

   0x018004bc <+44>:stfdf1,40(r31)

   0x018004c0 <+48>:stfdf2,48(r31)

   0x018004c4 <+52>:stfdf3,56(r31)

   0x018004c8 <+56>:stfdf4,64(r31)

   0x018004cc <+60>:stfdf5,72(r31)

   0x018004d0 <+64>:stfdf6,80(r31)

   0x018004d4 <+68>:stfdf7,88(r31)

   0x018004d8 <+72>:stfdf8,96(r31)

   0x018004dc <+76>:stw r3,104(r31)





So at try to set breakpoint at my_function() function, GDB sets breakpoint at

address 0x018004bc, which is not correct because this address is unreachable if

we do not pass floating point arguments to my_function().

[Bug sanitizer/55587] New: Testsuite test c-c++-common/asn/memcmp-1.c fails to link on targets without libasan/libsanitizer

[ktietz at gcc dot gnu.org]

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



 Bug #: 55587

   Summary: Testsuite test c-c++-common/asn/memcmp-1.c fails to

link on targets without libasan/libsanitizer

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: sanitizer

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

ReportedBy: kti...@gcc.gnu.org

CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org,

ja...@gcc.gnu.org, k...@gcc.gnu.org

Target: i686-*-mingw32 i686-*-cygwin





Due missing dependency library this test fails for none-linux targets.

[Bug middle-end/55545] [4.8 Regression] Incredibly large compile-time performance regression on IA64 compiling 253.perlbmk

[rguenther at suse dot de]

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



--- Comment #8 from rguenther at suse dot de  
2012-12-04 09:00:29 UTC ---

On Mon, 3 Dec 2012, ebotcazou at gcc dot gnu.org wrote:



> 

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

> 

> Eric Botcazou  changed:

> 

>What|Removed |Added

> 

>  Depends on||55158

> 

> --- Comment #7 from Eric Botcazou  2012-12-03 
> 21:04:46 UTC ---

> Don't you have the tentative patch for PR rtl-opt/55158 in your tree?  It

> changes ICEs into timeouts in the testsuite.



Indeed we have.

[Bug tree-optimization/55559] [4.6/4.7/4.8 Regression] Marshalling double through union with inlines, incorrect behavior with -O2

[rguenther at suse dot de]

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



--- Comment #8 from rguenther at suse dot de  
2012-12-04 09:02:00 UTC ---

On Mon, 3 Dec 2012, mpreda at gmail dot com wrote:



> 

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

> 

> --- Comment #7 from Mihai Preda  2012-12-03 22:13:03 
> UTC ---

> Thanks, I didn't realize that (unsigned)-1.0 is undefined.

> 

> For the behavior I was expecting it's enough to use an intermediary cast

> through int, e.g. (unsigned)(int)-1.0.



Yes, that makes it implementation-defined (and all implementations

I know of do what you expect, modulo-two reduction).



> It may be nice to generate a consistent (-O0/-O1) result for (unsigned)-1.0

> though, even if not required by the standard.



That's unfortunately generally impossible.

[Bug rtl-optimization/55158] [4.8 Regression] segfault in schedule_region at -O3

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 CC||steven at gcc dot gnu.org

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

   |gnu.org |



--- Comment #15 from Steven Bosscher  2012-12-04 
09:02:20 UTC ---

(In reply to comment #12)

> Someone needs to do something here because the C/C++/Fortran testsuite results

> are abysmal at -O3.



So it's up to the only one in this discussion who does *not* have a paid

GCC hacking position to fix this? Has Itanium really sunk so deep?



OK, better not answer that :-)



I'm having a look on gcc66.

[Bug middle-end/55545] [4.8 Regression] Incredibly large compile-time performance regression on IA64 compiling 253.perlbmk

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 CC||steven at gcc dot gnu.org



--- Comment #9 from Steven Bosscher  2012-12-04 
09:03:12 UTC ---

(In reply to comment #5)

> The last time I built and tested the compiler on IA-64, the C testsuite 
> results

> were rather bad, especially at -O3.



At trunk 20121203, most of these are the same as PR55158:



$ grep -c "internal compiler error" gcc/testsuite/gcc/gcc.log.sent

947

$ egrep -c "sched-rgn.c:299[08]" gcc/testsuite/gcc/gcc.log.sent

676

[Bug c++/55588] New: Failure to diagnose non-template-id prefixed by keyword template

[redi at gcc dot gnu.org]

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



 Bug #: 55588

   Summary: Failure to diagnose non-template-id prefixed by

keyword template

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: accepts-invalid

  Severity: normal

  Priority: P3

 Component: c++

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

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





This example is taken from 14.2 [temp.names] p5



template  struct A {

  void f(int);

  template  void f(U);

};

template  void f(T t) {

  A a;

  a.template f<>(t);  // OK: calls template

  a.template f(t);// error: not a template-id

}



G++ compiles it without error (as does Clang++, but not Comeau online)

[Bug debug/55585] compile time hog at -O1 -fboundscheck -g

[Joost.VandeVondele at mat dot ethz.ch]

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



Joost VandeVondele  changed:



   What|Removed |Added



 CC||Joost.VandeVondele at mat

   ||dot ethz.ch

  Component|middle-end  |debug



--- Comment #1 from Joost VandeVondele  
2012-12-04 09:09:59 UTC ---

After building with checking release, the issue seems to be purely a

vartracking one:



 variable tracking   :   1.91 ( 1%) usr   0.00 ( 0%) sys   1.98 ( 1%) wall 

 28861 kB ( 4%) ggc

 var-tracking dataflow   : 112.89 (60%) usr   0.14 (16%) sys 113.01 (59%) wall 

 0 kB ( 0%) ggc

 var-tracking emit   :  52.93 (28%) usr   0.01 ( 1%) sys  52.95 (28%) wall 

 14480 kB ( 2%) ggc

[Bug c++/55588] Failure to diagnose non-template-id prefixed by keyword template

[redi at gcc dot gnu.org]

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



--- Comment #1 from Jonathan Wakely  2012-12-04 
09:14:02 UTC ---

I should have added an instantiation of the function to the code:





template  struct A {

  void f(int);

  template  void f(U);

};

template  void f(T t) {

  A a;

  a.template f<>(t); // OK: calls template

  a.template f(t);  // error: not a template-id

}



int main() {

  f(1);

}

[Bug libgcc/55589] New: Failure compiling "generic-morestack-thread.c", without threads

[michael at talamasca dot ocis.net]

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



 Bug #: 55589

   Summary: Failure compiling "generic-morestack-thread.c",

without threads

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libgcc

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

ReportedBy: mich...@talamasca.ocis.net





Stock GCC 4.7.2 fails to build itself on my uClibc system, stopping at the file

"generic-morestack-thread.c":



/home/source/gcc-4.7.2/libgcc/generic-morestack-thread.c:41:21: fatal error:

pthread.h: No such file or directory

compilation terminated.

make[3]: *** [generic-morestack-thread.o] Error 1

make[3]: Leaving directory

`/home/test/build/gcc-build/i386-pc-linux-uclibc/libgcc'

make[2]: *** [all-stage1-target-libgcc] Error 2

make[2]: Leaving directory `/home/test/build/gcc-build'

make[1]: *** [stage1-bubble] Error 2

make[1]: Leaving directory `/home/test/build/gcc-build'

make: *** [all] Error 2



"pthread.h" is indeed missing, as I have compiled uClibc without threading

support.  GCC's build system fails to realize that that file shouldn't be built

in this case.



I've been dealing with this problem myself by simply changing "ifndef

inhibit_libc" to simply "if 0".  I haven't noticed any negative consequences

from this hack.

[Bug tree-optimization/55124] [4.8 Regression] ICE in find_or_generate_expression, at tree-ssa-pre.c:2803

[rguenth at gcc dot gnu.org]

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



--- Comment #10 from Richard Biener  2012-12-04 
09:19:25 UTC ---

Author: rguenth

Date: Tue Dec  4 09:19:05 2012

New Revision: 194125



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

Log:

2012-12-04  Richard Biener  



PR tree-optimization/55124

* tree-ssa-pre.c (find_or_generate_expression): Instead of

ICEing when we are not able to generate an expression defer it

by signalling failure.  Fix possible wrong-code issue by

not picking random REFERENCE expressions as fallback.

(create_component_ref_by_pieces_1): Adjust.  Add failure paths.

(create_expression_by_pieces): Likewise.

(insert_into_preds_of_block): When expression generation failed

for one edge make sure to not insert a PHI node.



* gcc.dg/torture/pr55124.c: New testcase.



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr55124.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-ssa-pre.c

[Bug tree-optimization/55124] [4.8 Regression] ICE in find_or_generate_expression, at tree-ssa-pre.c:2803

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #11 from Richard Biener  2012-12-04 
09:25:44 UTC ---

Fixed.

[Bug middle-end/52306] ICE in CSE

[tg at mirbsd dot org]

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

--- Comment #5 from Thorsten Glaser  2012-12-04 09:26:12 
UTC ---
Also happens in src:kde4libs (= 4:4.8.4-4) on
../../kdecore/util/kpluginfactory.cpp – I tested -O1, which helped.

If there’s any need of _more_ preprocessed source… just shout, but seeing as
we’ve got some already… the line is 2158 by now in Debian though, with all the
changes. (gcc -O2 -g -fPIC -c x.c on Attachment 27325 still triggers it.)

Though, with the three recent patches, my genattrtab time went down from six or
so *hours* to two *minutes*, so I have much faster turnaround times now, thanks
to Mikael Petterson who backported them ;)

[Bug rtl-optimization/55158] [4.8 Regression] segfault in schedule_region at -O3

[ebotcazou at gcc dot gnu.org]

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



--- Comment #16 from Eric Botcazou  2012-12-04 
09:27:54 UTC ---

> So it's up to the only one in this discussion who does *not* have a paid

> GCC hacking position to fix this? Has Itanium really sunk so deep?



It's up to the author of the suspected patch to do something.  I personally

monitor the status of the IA-64 port on a regular basis, but we're supposed to

have maintainers to do it, although they seem to be in the MIPS business now.



I can provide IA-64 testing cycles, but I don't really have time to debug the

scheduler when I haven't broken it.



> I'm having a look on gcc66.



Thanks.  I'm going to attach the testsuite results with the patch applied; all

the timeouts have been introduced by it.

[Bug rtl-optimization/55158] [4.8 Regression] segfault in schedule_region at -O3

[ebotcazou at gcc dot gnu.org]

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



--- Comment #17 from Eric Botcazou  2012-12-04 
09:29:50 UTC ---

Created attachment 28871

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

Testsuite results with tentative fix

[Bug testsuite/55587] [ASAN] Testsuite test c-c++-common/asan/memcmp-1.c fails to link on targets without libasan/libsanitizer

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-12-04

  Component|sanitizer   |testsuite

Summary|Testsuite test  |[ASAN] Testsuite test

   |c-c++-common/asn/memcmp-1.c |c-c++-common/asan/memcmp-1.

   |fails to link on targets|c fails to link on targets

   |without |without

   |libasan/libsanitizer|libasan/libsanitizer

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2012-12-04 
09:33:22 UTC ---

Confirmed.  The testsuite misses something like dg-require asan.

[Bug debug/55585] compile time hog at -O1 -fboundscheck -g

[rguenth at gcc dot gnu.org]

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



--- Comment #2 from Richard Biener  2012-12-04 
09:35:21 UTC ---

It's probably the very many calls.  At -O2 VRP runs and eventually removes

most of them.



Eventually the frontend should try to avoid emitting useless bound checks.

[Bug c++/55576] Fails to compile a call to template member function

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #4 from Paolo Carlini  2012-12-04 
09:37:44 UTC ---

.

[Bug debug/55579] SRA doesn't create debug stmts when they would be useful

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-12-04

 Ever Confirmed|0   |1

   Severity|normal  |enhancement



--- Comment #1 from Richard Biener  2012-12-04 
09:38:41 UTC ---

Confirmed.

[Bug debug/55585] compile time hog at -O1 -fboundscheck -g

[Joost.VandeVondele at mat dot ethz.ch]

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



--- Comment #3 from Joost VandeVondele  
2012-12-04 09:39:12 UTC ---

(In reply to comment #2)

> It's probably the very many calls.  At -O2 VRP runs and eventually removes

> most of them.



Unfortunately, 



gfortran -c -ftime-report -O1 -fbounds-check -g -ftree-vrp slow.f90



is still equally slow.

[Bug testsuite/55587] [ASAN] Testsuite test c-c++-common/asan/memcmp-1.c fails to link on targets without libasan/libsanitizer

[jakub at gcc dot gnu.org]

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



--- Comment #2 from Jakub Jelinek  2012-12-04 
09:40:44 UTC ---

asan.exp starts with

if ![check_effective_target_faddress_sanitizer] {

  return

}

but that just checks whether -fsanitize=address works, not whether libasan has

been built.  That further check is in asan_init, guess we could return 0/1 from

asan_init on whether it found libasan and if it hasn't, don't call

gcc-dg-runtest.

[Bug tree-optimization/54386] [4.8 Regression] Unaligned mem load wrongly generated for inlined inline/static function

[olegendo at gcc dot gnu.org]

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



--- Comment #14 from Oleg Endo  2012-12-04 
09:53:05 UTC ---

(In reply to comment #13)

> This is now fixed.  Thanks for patience and all the testcases.



Great, thanks!

I'll add an SH testcase for this, too.

[Bug rtl-optimization/55158] [4.8 Regression] segfault in schedule_region at -O3

[steven at gcc dot gnu.org]

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



--- Comment #18 from Steven Bosscher  2012-12-04 
09:56:53 UTC ---

Created attachment 28872

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

Updated tentative fix



(In reply to comment #16)

> I can provide IA-64 testing cycles, but I don't really have time to 

> debug the scheduler when I haven't broken it.



Sometimes you have to fix things you haven't broken.  Especially trivial

bugs like this one.  Look at all the REG_EQUAL stuff I've been trying

to fix.  I assure you I wasn't around in GCC land when in ~1992 e.g. the

optabs self-referencing REG_EQUAL notes were introduced :-)



And in this case, my tentative fix was a pointer in the right direction.

It has a rather obvious mistake in it, and anyone spending a minutes or

two looking at the patch could have spotted and resolved the mistake.



> > I'm having a look on gcc66.

> 

> Thanks.  I'm going to attach the testsuite results with the patch

> applied; all the timeouts have been introduced by it.



Attached is an updated patch.  Again untested, but that's about to change.

I'm going to test it on gcc66.

[Bug rtl-optimization/55158] [4.8 Regression] segfault in schedule_region at -O3

[steven at gcc dot gnu.org]

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



--- Comment #19 from Steven Bosscher  2012-12-04 
10:02:58 UTC ---

This line is of course supposed to compare bb_state_array and

old_bb_state_array:

  for (int i = (bb_state != old_bb_state) ? 0 : saved_last_basic_block;

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-12-04

 CC||hubicka at gcc dot gnu.org,

   ||jakub at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #7 from Jakub Jelinek  2012-12-04 
10:13:06 UTC ---

Reduced testcase:

/* { dg-do compile } */

/* { dg-options "-fdata-sections -g -O2" } */

/* { dg-additional-options "-fstack-protector" { target fstack_protector } } */



extern inline __attribute__ ((__always_inline__))

void *

memcpy (void *__restrict d, const void *__restrict s, __SIZE_TYPE__ l)

{

  return __builtin___memcpy_chk (d, s, l, __builtin_object_size (d, 0));

}



void

foo (char *p)

{

  static const char q[] = "\n";

  memcpy (p, &q, 1);

}



The reason why this fails is IMHO bogus change from

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



void

varpool_remove_node (struct varpool_node *node)

{

  symtab_unregister_node ((symtab_node)node);

  if (DECL_INITIAL (node->symbol.decl)

  && !DECL_IN_CONSTANT_POOL (node->symbol.decl)

  /* Keep vtables for BINFO folding.  */

  && !DECL_VIRTUAL_P (node->symbol.decl)

  /* dbxout output constant initializers for readonly vars.  */

  && (!host_integerp (DECL_INITIAL (node->symbol.decl), 0)

  || !TREE_READONLY (node->symbol.decl)))

DECL_INITIAL (node->symbol.decl) = error_mark_node;

  ggc_free (node);

}



(the DECL_INITIAL setting to error_mark_node).  I can understand the aim at

saving compile time memory, but this is a wrong thing to do.  dwarf2out.c uses

DECL_INITIAL heavily to emit debug info even for optimized away variables.



The exact reason for the error is that we have get_named_section called twice,

once before the varpool_remove_node call, once after it.

The first one is:

#1  0x00cc64dc in get_named_section (decl=0x719a5850,

name=0x717fdbf4 ".rodata.q.4121", reloc=0) at ../../gcc/varasm.c:411

#2  0x00cc7d6c in get_variable_section (decl=0x719a5850,

prefer_noswitch_p=true) at ../../gcc/varasm.c:1030

#3  0x00cc7f88 in get_block_for_decl (decl=0x719a5850) at

../../gcc/varasm.c:1076

#4  0x00cc8a88 in make_decl_rtl (decl=0x719a5850) at

../../gcc/varasm.c:1295

#5  0x00cc8e4f in make_decl_rtl_for_debug (decl=0x719a5850) at

../../gcc/varasm.c:1350

#6  0x00654bea in expand_debug_expr (exp=0x719a5850) at

../../gcc/cfgexpand.c:2777

#7  0x00657357 in expand_debug_expr (exp=0x717ed460) at

../../gcc/cfgexpand.c:3358

#8  0x00658b37 in expand_debug_locations () at

../../gcc/cfgexpand.c:3739

#9  0x0065b3c5 in gimple_expand_cfg () at ../../gcc/cfgexpand.c:4606

when creating DEBUG_IMPLICIT_PTR for the parameter s.  Then varpool_remove_node

is called:

#0  varpool_remove_node (node=0x719a6410) at ../../gcc/varpool.c:61

#1  0x00cdb98a in varpool_remove_unreferenced_decls () at

../../gcc/varpool.c:406

#2  0x00cdbb07 in varpool_output_variables () at

../../gcc/varpool.c:440

#3  0x00686a00 in compile () at ../../gcc/cgraphunit.c:2044

#4  0x00686b7a in finalize_compilation_unit () at

../../gcc/cgraphunit.c:2120

and finally get_named_section again:

#1  0x00cc64dc in get_named_section (decl=0x719a5850,

name=0x717fdbf4 ".rodata.q.4121", reloc=0) at ../../gcc/varasm.c:411

#2  0x00cc7d6c in get_variable_section (decl=0x719a5850,

prefer_noswitch_p=true) at ../../gcc/varasm.c:1030

#3  0x00cc7f88 in get_block_for_decl (decl=0x719a5850) at

../../gcc/varasm.c:1076

#4  0x00cc8a88 in make_decl_rtl (decl=0x719a5850) at

../../gcc/varasm.c:1295

#5  0x00cc8e4f in make_decl_rtl_for_debug (decl=0x719a5850) at

../../gcc/varasm.c:1350

#6  0x006f4d33 in rtl_for_decl_location (decl=0x719a5850) at

../../gcc/dwarf2out.c:15150

#7  0x006f503f in add_location_or_const_value_attribute

(die=0x71805be0, decl=0x719a5850, cache_p=false, attr=DW_AT_location)

at ../../gcc/dwarf2out.c:15244

#8  0x00709d9b in dwarf2out_finish (filename=0x7fffe58b

"pr55395.i") at ../../gcc/dwarf2out.c:23218

#9  0x00a3e2ce in compile_file () at ../../gcc/toplev.c:600



In the first case, DECL_INITIAL is not NULL, nor error_mark_node, nor zero

initializer, so rodata.q.4121 is assumed to be a read-only section, in the

second case DECL_INITIAL of q is already error_mark_node and thus rodata.q.4121

is assumed to be a bss section, therefore a section flags conflict.  In the

case of array initialized with a constant string right now the initializer

won't be useful, 

[Bug target/55583] Extended shift instruction on x86-64 is not used, producing unoptimal code

[glisse at gcc dot gnu.org]

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



Marc Glisse  changed:



   What|Removed |Added



 CC||glisse at gcc dot gnu.org



--- Comment #4 from Marc Glisse  2012-12-04 10:15:27 
UTC ---

It looks like the patterns all look for 32-i as the second shift amount.

Writing an additional version that takes a constant (with an extra check that

the sum of the constants is 32, and we then have to specify immediate_length

manually) and replacing (match_dup 0) with an extra operand that has the

constraint "0" seems to work. (and breaks again if I swap the 2 sides of

operator| )

[Bug libgcc/55589] Failure compiling "generic-morestack-thread.c", without threads

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2012-12-04 
10:27:26 UTC ---

How did you configure GCC?

[Bug middle-end/52306] ICE in CSE

[mikpe at it dot uu.se]

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

--- Comment #6 from Mikael Pettersson  2012-12-04 
10:27:34 UTC ---
(In reply to comment #5)
> Also happens in src:kde4libs (= 4:4.8.4-4) on
> ../../kdecore/util/kpluginfactory.cpp – I tested -O1, which helped.

Just to clarify, compiling with -O1 avoids the ICE?  So you do have a
workaround?

> If there’s any need of _more_ preprocessed source… just shout

Please upload the preprocessed source for this new test case.  I'd like to
check if it too is silenced in 4.7 and trunk by the PR37273 fix.

[Bug tree-optimization/55590] New: SRA still produces unnecessarily unaligned memory accesses

[jamborm at gcc dot gnu.org]

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



 Bug #: 55590

   Summary: SRA still produces unnecessarily unaligned memory

accesses

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

AssignedTo: jamb...@gcc.gnu.org

ReportedBy: jamb...@gcc.gnu.org





SRA can still produce unaligned memory accesses which should be

aligned when it's basing its new scalar access on a MEM_REF buried

below COMPONENT_REFs or ARRAY_REFs.



Testcase 1:



/* { dg-do compile } */

/* { dg-options "-O2 -mavx" } */



#include 



struct S

{

  __m128 a, b;

};



struct T

{

  int a;

  struct S s;

};



void foo (struct T *p, __m128 v)

{

  struct S s;



  s = p->s;

  s.b = _mm_add_ps(s.b, v);

  p->s = s;

}



/* { dg-final { scan-assembler-not "vmovups" } } */



on x86_64 compiles to



vmovups 32(%rdi), %xmm1

vaddps  %xmm0, %xmm1, %xmm0

vmovups %xmm0, 32(%rdi)



even though it should really be



vaddps  32(%rdi), %xmm0, %xmm0

vmovaps %xmm0, 32(%rdi)

ret







Testcase 2 (which describes why this should be fixed differently from

the recent IPA-SRA patch because of the variable array index):



/* { dg-do compile } */

/* { dg-options "-O2 -mavx" } */



#include 



struct S

{

  __m128 a, b;

};



struct T

{

  int a;

  struct S s[8];

};



void foo (struct T *p, int i, __m128 v)

{

  struct S s;



  s = p->s[i];

  s.b = _mm_add_ps(s.b, v);

  p->s[i] = s;

}



/* { dg-final { scan-assembler-not "vmovups" } } */



Compiles to



movslq  %esi, %rsi

salq$5, %rsi

leaq16(%rdi,%rsi), %rax

vmovups 16(%rax), %xmm1

vaddps  %xmm0, %xmm1, %xmm0

vmovups %xmm0, 16(%rax)

ret



when it should produce



movslq  %esi, %rsi

salq$5, %rsi

leaq16(%rdi,%rsi), %rax

vaddps  16(%rax), %xmm0, %xmm0

vmovaps %xmm0, 16(%rax)

ret



I'm testing a patch.

[Bug debug/55585] compile time hog at -O1 -fboundscheck -g

[Joost.VandeVondele at mat dot ethz.ch]

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



--- Comment #4 from Joost VandeVondele  
2012-12-04 10:43:10 UTC ---

Interestingly, the magic switch is -fstrict-aliasing... 20x speedup. for a

Fortran code quite a surprise.



> time gfortran -c -O1 -fbounds-check -g -fstrict-aliasing slow.f90 

real0m11.483s



I think for Fortran -fstrict-aliasing could well be the default at -O1, but

maybe there is an underlying reason why this flag is needed ?

[Bug c++/55576] Fails to compile a call to template member function

[glisse at gcc dot gnu.org]

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



--- Comment #5 from Marc Glisse  2012-12-04 10:47:38 
UTC ---

For the example of comment #3, clang compiles it happily, and comeau gives this

message:



"ComeauTest.c", line 12: error: type name is not allowed

return f.template apply(address);

  ^



"ComeauTest.c", line 12: warning: ambiguous class member reference -- function

  template "factory::apply" (declared at line 3) used in preference to

  type "apply::apply [with T=int]" (declared at line 9)

return f.template apply(address);

  ^

  detected during instantiation of "void *apply::operator()(const

FactoryT &, void *) const [with T=int, FactoryT=factory]"

at line 18

[Bug debug/55585] compile time hog at -O1 -fboundscheck -g

[rguenth at gcc dot gnu.org]

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



--- Comment #5 from Richard Biener  2012-12-04 
11:00:39 UTC ---

(In reply to comment #4)

> Interestingly, the magic switch is -fstrict-aliasing... 20x speedup. for a

> Fortran code quite a surprise.

> 

> > time gfortran -c -O1 -fbounds-check -g -fstrict-aliasing slow.f90 

> real0m11.483s

> 

> I think for Fortran -fstrict-aliasing could well be the default at -O1, but

> maybe there is an underlying reason why this flag is needed ?



Well, it probably enables CSE that removes some of the bounds-checking calls.

Not sure why exactly without investigating.



GFortran could enable strict-aliasing unconditionally if it likes (even

at -O0).

[Bug c++/55576] Fails to compile a call to template member function

[redi at gcc dot gnu.org]

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



--- Comment #6 from Jonathan Wakely  2012-12-04 
11:04:45 UTC ---

I've been trying to find the relevant text in the standard but I'm not entirely

sure where this is covered. Possibly [temp.local] paras 3-5, including



"The injected-class-name of a class template or class template specialization

can be used either as a template-name or a type-name wherever it is in scope."

[Bug rtl-optimization/55158] [4.8 Regression] segfault in schedule_region at -O3

[bernds at gcc dot gnu.org]

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



--- Comment #20 from Bernd Schmidt  2012-12-04 
11:06:07 UTC ---

Created attachment 28873

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

Another patch



Here's another attempt, given that it seems to be the speculation code that

causes the problem.

[Bug c++/54207] [4.7/4.8 Regression][C++0x] ICE in build_noexcept_spec when bool is #defined/typedef'd

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



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

Created attachment 28874

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

gcc48-pr54207.patch



The testcase is invalid, you can't add typedefs with system reserved names

before including standard headers, nor redefine keywords to something else.



That said, in this patch is a testcase which IMHO is valid and still ICEs even

with current trunk.



The thing is that perform_implicit_conversion will not do anything if the type

is same_type_p, but different (B vs. bool in this testcase, _Bool vs. bool in

the original testcase).  In both cases the other type is also a BOOLEAN_TYPE,

but distinct from the original one.  Doing == boolean_true_node or ==

boolean_false_node comparison doesn't work in that case, they aren't pointer

equal (as they have distinct type), yet they operand_equal_p true.  So, either

we use operand_equal_p as this patch does (the patch guards it with INTEGER_CST

check to avoid calling operand_equal_p unnecessarily, but that can be certainly

dropped and done unconditionally if Jason prefers that), or we could for

INTEGER_CSTs fold_convert them to boolean_type_node, then the pointer equality

comparison would work.

[Bug rtl-optimization/55158] [4.8 Regression] segfault in schedule_region at -O3

[ebotcazou at gcc dot gnu.org]

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



--- Comment #21 from Eric Botcazou  2012-12-04 
11:36:23 UTC ---

> Sometimes you have to fix things you haven't broken.  Especially trivial

> bugs like this one.  Look at all the REG_EQUAL stuff I've been trying

> to fix.  I assure you I wasn't around in GCC land when in ~1992 e.g. the

> optabs self-referencing REG_EQUAL notes were introduced :-)



Sure.  However, I personally stay away from the register allocator, reload and

the scheduler unless I'm really forced to look into them. :-)

[Bug fortran/55591] New: strict-aliasing & Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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



 Bug #: 55591

   Summary: strict-aliasing & Fortran

Classification: Unclassified

   Product: gcc

   Version: 4.7.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

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

ReportedBy: joost.vandevond...@mat.ethz.ch





As suggested in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55585#c5



Richard:

GFortran could enable strict-aliasing unconditionally if it likes (even

at -O0).



I think this makes sense given the Fortran semantics and the way people usually

code in Fortran. Given this is the default at -O2 already, I think

-fstrict-aliasing is well tested.

[Bug testsuite/55587] [ASAN] Testsuite test c-c++-common/asan/memcmp-1.c fails to link on targets without libasan/libsanitizer

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #3 from Jakub Jelinek  2012-12-04 
11:55:42 UTC ---

Created attachment 28875

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

gcc48-pr55587.patch



Does this patch work for you?  Worked for me in a quick testing (both with

libsanitizer around and without).

[Bug debug/55585] compile time hog at -O1 -fboundscheck -g

[Joost.VandeVondele at mat dot ethz.ch]

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



--- Comment #6 from Joost VandeVondele  
2012-12-04 11:56:59 UTC ---

(In reply to comment #5)

> GFortran could enable strict-aliasing unconditionally if it likes (even

> at -O0).



I have now opened PR55591 for this.

[Bug lto/55592] New: linking with -flto always links in libgcc:s.so

[doko at gcc dot gnu.org]

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



 Bug #: 55592

   Summary: linking with -flto always links in libgcc:s.so

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: lto

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

ReportedBy: d...@gcc.gnu.org





$ cat foo.c 

int main() { }

$ gcc foo.c && ldd a.out |grep libgcc_s

$ gcc -flto foo.c && ldd a.out |grep libgcc_s

libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7fb214381000)



gcc.c (pass_through_libs_spec_func) doesn't pass the --as-needed/--no-as-needed

flags to the plugin. if these are passed, how should the plugin handle these?

[Bug testsuite/55587] [ASAN] Testsuite test c-c++-common/asan/memcmp-1.c fails to link on targets without libasan/libsanitizer

[ktietz at gcc dot gnu.org]

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



--- Comment #4 from Kai Tietz  2012-12-04 12:10:12 
UTC ---

(In reply to comment #3)

> Created attachment 28875 [details]

> gcc48-pr55587.patch

> 

> Does this patch work for you?  Worked for me in a quick testing (both with

> libsanitizer around and without).



Yes, it works for me.  Thanks

[Bug middle-end/52306] ICE in CSE

[tg at mirbsd dot org]

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

--- Comment #7 from Thorsten Glaser  2012-12-04 12:58:35 
UTC ---
Created attachment 28876
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28876
preprocessed source of second kde4libs occurrence

OK. I found another one in the meantime, which I added. It can be triggered
thus:

ara3:~# gcc -x c++ -g -fPIC -ansi -fno-exceptions -fno-check-new -fno-common
-fno-threadsafe-statics -O2 -c kstatusnotifieritem.i
../../kdeui/notifications/kstatusnotifieritem.cpp: In member function
'KDbusImageVector KStatusNotifierItemPrivate::iconToVector(const QIcon&)':
../../kdeui/notifications/kstatusnotifieritem.cpp:1037:1: internal compiler
error: in cselib_record_set, at cselib.c:2158
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/cc8gGDaq.out file, please attach this to
your bugreport.

(I’ve just attached the .i file, they’re virtually identical save for
newlines.)

The set of compiler options is not minimal, but just -O2 -g -fPIC wasn’t
enough. Appending -O1 solves it.

[Bug target/54063] [4.8 regression] on powerpc64 gcc 4.8 generates larger code for global variable accesses than gcc 4.7

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #4 from Jakub Jelinek  2012-12-04 
13:05:05 UTC ---

While the memory load is split already during reload, the set for &head is only

split during split2 pass, which is after postreload_cse (and gcse2) which are

the last CSE-ish passes I think.  So perhaps you could tweak machine reorg pass

to handle some of the easy cases, or what exactly is the reason for running

split2 after postreload CSE instead of before it?

[Bug fortran/55593] New: Bogus error on passing DO LOOP variable

[sfilippone at uniroma2 dot it]

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



 Bug #: 55593

   Summary: Bogus error on passing DO LOOP variable

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

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

ReportedBy: sfilipp...@uniroma2.it

CC: tkoe...@gcc.gnu.org





Created attachment 28877

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

test case



Hi, 

I get the following bogus error:

=== 

[sfilippo@localhost bug34]$ gfortran -v 

Using built-in specs.

COLLECT_GCC=gfortran

COLLECT_LTO_WRAPPER=/usr/local/gnu48/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: ../gcc/configure --prefix=/usr/local/gnu48

--enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/BUILDS/gmp

--with-mpfr=/home/travel/GCC/BUILDS/mpfr --with-mpc=/home/travel/GCC/BUILDS/mpc

: (reconfigured) ../gcc/configure --prefix=/usr/local/gnu48

--enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/BUILDS/gmp

--with-mpfr=/home/travel/GCC/BUILDS/mpfr --with-mpc=/home/travel/GCC/BUILDS/mpc

: (reconfigured) ../gcc/configure --prefix=/usr/local/gnu48

--with-gmp=/home/travel/GCC/BUILDS/gmp --with-mpfr=/home/travel/GCC/BUILDS/mpfr

--with-mpc=/home/travel/GCC/BUILDS/mpc --enable-languages=c,c++,fortran,lto

--no-create --no-recursion

Thread model: posix

gcc version 4.8.0 20121204 (experimental) (GCC) 

[sfilippo@localhost bug34]$ gfortran -c bug34.f90 

bug34.f90:95.21:



call loc_to_glob(i,idx,desc_a,info)

 1

bug34.f90:94.14:



  do i=1, nrow

  2

Error: Variable 'i' at (1) not definable inside loop beginning at (2) as

INTENT(INOUT) argument to subroutine 'loc_to_glob'



===



The error is bogus because the proper specific subroutine should be

"loc_to_glob2s" and it gets I as the actual argument corresponding to an

INTENT(IN) dummy (x).



The compiler appears to be confused by the generic name being the same as one

of the specifics; indeed, if I change the second specific name to

"loc_to_glob1v" on line 49, the error goes away. Note that having one of the

specific names the same as the generic is allowed by the standard. 

(even though it's not a very good idea, and I'll probably change it anyway)



This sure looks like having been caused by the fix for PR30146.

[Bug debug/54970] Missing DW_OP_GNU_implicit_pointer in debuginfo

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #5 from Jakub Jelinek  2012-12-04 
13:16:05 UTC ---

Fixed.

[Bug sanitizer/55439] ThreadSanitizer: handle atomic operations

[jakub at gcc dot gnu.org]

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



--- Comment #2 from Jakub Jelinek  2012-12-04 
13:20:35 UTC ---

Author: jakub

Date: Tue Dec  4 13:20:20 2012

New Revision: 194133



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

Log:

PR sanitizer/55439

* Makefile.in (tsan.o): Depend on tree-ssa-propagate.h.

* sanitizer.def: Add __tsan_atomic* builtins.

* asan.c (initialize_sanitizer_builtins): Adjust to also

initialize __tsan_atomic* builtins.

* tsan.c: Include tree-ssa-propagate.h.

(enum tsan_atomic_action): New enum.

(tsan_atomic_table): New table.

(instrument_builtin_call): New function.

(instrument_gimple): Take pointer to gimple_stmt_iterator

instead of gimple_stmt_iterator.  Call instrument_builtin_call

on builtin call stmts.

(instrument_memory_accesses): Adjust instrument_gimple caller.

* builtin-types.def (BT_FN_BOOL_VPTR_PTR_I1_INT_INT,

BT_FN_BOOL_VPTR_PTR_I2_INT_INT, BT_FN_BOOL_VPTR_PTR_I4_INT_INT,

BT_FN_BOOL_VPTR_PTR_I8_INT_INT, BT_FN_BOOL_VPTR_PTR_I16_INT_INT): New.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/Makefile.in

trunk/gcc/asan.c

trunk/gcc/builtin-types.def

trunk/gcc/sanitizer.def

trunk/gcc/tsan.c

[Bug testsuite/55587] [ASAN] Testsuite test c-c++-common/asan/memcmp-1.c fails to link on targets without libasan/libsanitizer

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2012-12-04 
13:21:31 UTC ---

Author: jakub

Date: Tue Dec  4 13:21:11 2012

New Revision: 194134



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

Log:

PR testsuite/55587

* lib/asan-dg.exp (asan_init): Return 1 if libasan has been found,

0 if not.

* g++.dg/asan/asan.exp: Don't run gcc-dg-runtest if [asan_init]

returned 0.

* gcc.dg/asan/asan.exp: Likewise.



Modified:

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/g++.dg/asan/asan.exp

trunk/gcc/testsuite/gcc.dg/asan/asan.exp

trunk/gcc/testsuite/lib/asan-dg.exp

[Bug testsuite/55587] [ASAN] Testsuite test c-c++-common/asan/memcmp-1.c fails to link on targets without libasan/libsanitizer

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #6 from Jakub Jelinek  2012-12-04 
13:26:32 UTC ---

Fixed.

[Bug fortran/55591] strict-aliasing & Fortran

[rguenth at gcc dot gnu.org]

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



--- Comment #1 from Richard Biener  2012-12-04 
13:35:54 UTC ---

Btw, the same holds true for all languages.  That it's only enabled at -O2+

is historical (but I don't remember the result of likely past discussions to

change this default).

[Bug lto/55592] linking with -flto always links in libgcc:s.so

[hjl.tools at gmail dot com]

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



H.J. Lu  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||hjl.tools at gmail dot com

 Resolution||INVALID



--- Comment #1 from H.J. Lu  2012-12-04 13:58:20 
UTC ---

It is a bug in bfd linker in the GNU binutils.

It works fine with both bfd linker and gold

from the Linux binutils.  Please open a binutils

bug.

[Bug libstdc++/55594] New: [4.8 Regression] -Wa,-nH incorrectly added to compile line of all targets

[dje at gcc dot gnu.org]

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



 Bug #: 55594

   Summary: [4.8 Regression] -Wa,-nH incorrectly added to compile

line of all targets

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libstdc++

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

ReportedBy: d...@gcc.gnu.org





On 2012-09-12, a patch was added to libstdc++ to instruct the Sun assembler to

clear hardware capabilities with -nH command line option. However, the test in

configure is not limited to Sun Solaris and adds the option to all systems for

which the assembler accepts a "-nH" option, regardless of the meaning of the

option. This produces incorrect results on other systems.

[Bug libstdc++/55594] [4.8 Regression] -Wa,-nH incorrectly added to compile line of all targets

[dje at gcc dot gnu.org]

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



David Edelsohn  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Keywords||build

   Last reconfirmed||2012-12-04

 CC||ro at CeBiTec dot

   ||Uni-Bielefeld.DE

 Ever Confirmed|0   |1

   Target Milestone|--- |4.8.0

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[hubicka at ucw dot cz]

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



--- Comment #8 from Jan Hubicka  2012-12-04 14:46:06 UTC 
---

> (the DECL_INITIAL setting to error_mark_node).  I can understand the aim at

> saving compile time memory, but this is a wrong thing to do.  dwarf2out.c uses

> DECL_INITIAL heavily to emit debug info even for optimized away variables.



OK, the aim was mostly to get rid of large constructors. Is it possible to tell

when

the DECL_INITIAL will be needed?  This problem also exists with LTO where we do

not

stream initializers of variables not assigned to a given partition.



Honza

[Bug fortran/55593] [4.8 Regression] Bogus error on passing DO LOOP variable

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



   Priority|P3  |P4

 Status|UNCONFIRMED |NEW

   Keywords||diagnostic, rejects-valid

   Last reconfirmed||2012-12-04

 CC||burnus at gcc dot gnu.org

 Ever Confirmed|0   |1

Summary|Bogus error on passing DO   |[4.8 Regression] Bogus

   |LOOP variable   |error on passing DO LOOP

   ||variable

   Target Milestone|--- |4.8.0



--- Comment #1 from Tobias Burnus  2012-12-04 
14:49:14 UTC ---

>From frontend-passes.c's doloop_code



case EXEC_CALL:

  f = co->symtree->n.sym->formal;



I think one should use in this case

  co->value.function.esym



I believe co->value.function.* should always exist, given that it comes after

resolution (if not, the symtree can be used as fall back). In any case, one

needs to be careful if it isn't an "isym" instead.

[Bug sanitizer/55521] many instances of ASAN:SIGSEGV failures in g++ testsuite with -fsanitize=address

[howarth at nitro dot med.uc.edu]

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



Jack Howarth  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #19 from Jack Howarth  2012-12-04 
14:51:53 UTC ---

Fixed at...



r194120 | kcc | 2012-12-04 02:00:35 -0500 (Tue, 04 Dec 2012) | 1 line



[libsanitizer] Fix PR55521 by switching libsanitizer from mach_override to mac

interpose functions on darwin

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[jakub at gcc dot gnu.org]

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



--- Comment #9 from Jakub Jelinek  2012-12-04 
15:10:00 UTC ---

(In reply to comment #8)

> OK, the aim was mostly to get rid of large constructors. Is it possible to 
> tell

> when the DECL_INITIAL will be needed?  This problem also exists with LTO 
> where > we do not stream initializers of variables not assigned to a given 
> partition.



It is always used if available and there is no other way to generate the

location info for it (which for vars that were removed from the varpool is

probably always, I bet those aren't assigned memory locations).  The question

is of course if it can successfully generate something out of it or not, but

you can't guess that before it tried.

For the invalid error part of this PR, it would be just important that it

doesn't set DECL_INITIAL to error_mark_node, but some other magic value which

says, this decl had non-zero initializer, but ignore the other details about

it.  Of course to make the debug info more complete you really should keep the

initializer.

Aren't you building mozilla with LTO without -g anyway, given that LTO screws

up debug info so terribly that it isn't useful at all?

Can you come up with some short testcase that would show what kind of large

constructors you care about?

[Bug fortran/55591] strict-aliasing & Fortran

[jvdelisle at gcc dot gnu.org]

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



Jerry DeLisle  changed:



   What|Removed |Added



 CC||jvdelisle at gcc dot

   ||gnu.org



--- Comment #2 from Jerry DeLisle  2012-12-04 
15:46:27 UTC ---

I think just the compile time saving during code development justifies this

change and it can always be over-ridden by the user if ever needed.

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[hubicka at ucw dot cz]

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



--- Comment #10 from Jan Hubicka  2012-12-04 16:25:36 
UTC ---

> It is always used if available and there is no other way to generate the

> location info for it (which for vars that were removed from the varpool is

> probably always, I bet those aren't assigned memory locations).  The question

> is of course if it can successfully generate something out of it or not, but

> you can't guess that before it tried.

> For the invalid error part of this PR, it would be just important that it

> doesn't set DECL_INITIAL to error_mark_node, but some other magic value which

> says, this decl had non-zero initializer, but ignore the other details about

> it.  Of course to make the debug info more complete you really should keep the



OK, what value it should be?  We always used error_mark_node with this meaning

both in LTO and cgraph.

> initializer.

> Aren't you building mozilla with LTO without -g anyway, given that LTO screws

> up debug info so terribly that it isn't useful at all?



I build -g to at least catch the ICEs. Of course we should work towards making

-g

useful not useless.



> Can you come up with some short testcase that would show what kind of large

> constructors you care about?



static int a[]={huge sequence of numbers};

In C++ we have a lot of class constructors and vtables that comes from headers

and can go away...

[Bug c++/51810] internal compiler error

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||markus at trippelsdorf dot

   ||de



--- Comment #6 from Paolo Carlini  2012-12-04 
16:36:44 UTC ---

Do we have a testcase actually ICEing with current mainline or 4_7-branch? I

don't think we do...

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[jakub at gcc dot gnu.org]

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



--- Comment #11 from Jakub Jelinek  2012-12-04 
16:41:35 UTC ---

(In reply to comment #10)

> OK, what value it should be?  We always used error_mark_node with this meaning

> both in LTO and cgraph.



Dunno, I'm leaning towards just not dropping anything for -g.



> static int a[]={huge sequence of numbers};

> In C++ we have a lot of class constructors and vtables that comes from headers

> and can go away...



But that should be perfectly expressable in DWARF4, if we don't express it

right now, we just should.

[Bug regression/55486] FAIL: gcc.dg/sms-7.c (internal compiler error)

[kyrylo.tkachov at arm dot com]

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



--- Comment #4 from Kyrill Tkachov  2012-12-04 
16:55:06 UTC ---

Hello,

Compiler ICEs again, not sure if it's been broken again or it's the previous

cause. The ICE backtrace and relevant configuration are given below.



gcc/testsuite/gcc.dg/sms-7.c:17:1: internal compiler error: in

schedule_reg_moves, at modulo-sched.c:725

0xd2c0f4 schedule_reg_moves

gcc/modulo-sched.c:725

0xd2ec1f sms_schedule

gcc/modulo-sched.c:1684

0xd2 rest_of_handle_sms

gcc/modulo-sched.c:3340





Target: arm-none-eabi

Configured with:  --target=arm-none-eabi  --disable-shared --disable-nls

--disable-threads --disable-tls --enable-checking=yes --enable-languages=c

--with-newlib --with-fpu=neon --with-float=hard --with-arch=armv7-a



Thanks,

Kyrill

[Bug fortran/55591] strict-aliasing & Fortran

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #3 from Tobias Burnus  2012-12-04 
17:05:45 UTC ---

Untested (but successfully compiled) patch:



--- a/gcc/fortran/options.c

+++ b/gcc/fortran/options.c

@@ -170,4 +170,6 @@ gfc_init_options (unsigned int decoded_options_count,

   set_default_std_flags ();



+  flag_strict_aliasing = -1;

+

   /* Initialize cpp-related options.  */

   gfc_cpp_init_options (decoded_options_count, decoded_options);

@@ -275,4 +277,8 @@ gfc_post_options (const char **pfilename)

 gfc_option.flag_whole_file = 1;



+  /* By default use strict-aliasing semantics.  */

+  if (flag_strict_aliasing == -1)

+flag_strict_aliasing = 1;

+

   /* Fortran allows associative math - but we cannot reassociate if

  we want traps or signed zeros. Cf. also flag_protect_parens.  */

[Bug bootstrap/55571] [4.6/4.7/4.8 regression] PR48076 fix broke bootstrap on armv5tel-linux-gnueabi

[rth at gcc dot gnu.org]

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



--- Comment #9 from Richard Henderson  2012-12-04 
17:09:07 UTC ---

(In reply to comment #8)

> In case it's useful to anyone else, a small program that reproduces the

> problem.

> 

> % arm-linux-gnueabi-gcc -o utils utils.c

> [same problem with __sync_synchronize]



Does this require the compiler to be installed?  Because I'm having trouble

triggering the problem reliably.  I've tried your test with the compiler

still in-tree and it succeeds.  I can reproduce the fail with a full build,

but invoking the same link from the command line does NOT fail.



There's something weird going on here with the linker...

[Bug c/15376] shift and modulo operators not usable for integral vector types

[glisse at gcc dot gnu.org]

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



Marc Glisse  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC||glisse at gcc dot gnu.org

 Resolution||FIXED



--- Comment #2 from Marc Glisse  2012-12-04 18:41:01 
UTC ---

It has been implemented since then.

[Bug tree-optimization/27109] Simplify "a - 10 > 150" into "a > 160" when range of a is known (in VRP or somewhere else)

[glisse at gcc dot gnu.org]

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



--- Comment #2 from Marc Glisse  2012-12-04 18:48:27 
UTC ---

This seems to be well handled in reassoc1 now:



Optimizing range tests a_2(D) -[0, 99] and +[0, 200] and -[10, 160]

 into a_2(D) + 4294967135 <= 39

[Bug bootstrap/55571] [4.6/4.7/4.8 regression] PR48076 fix broke bootstrap on armv5tel-linux-gnueabi

[rth at gcc dot gnu.org]

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



--- Comment #10 from Richard Henderson  2012-12-04 
19:05:44 UTC ---

I can reproduce Joel's problem with the g++ driver or,

as expected, by adding -shared-libgcc to the link line.



Leaving aside the odd and transient bootstrap problem

(which really should not have occurred using -static-libgcc),

it becomes easy to see that when the shared libgcc has an

undefined symbol that is resolvable by the static libgcc,

then the linker is correct in generating the "hidden symbol

referenced by DSO" error.



The attachment I posted for gcc 4.7 applies with fuzz 1 to

mainline.

[Bug bootstrap/55571] [4.6/4.7/4.8 regression] PR48076 fix broke bootstrap on armv5tel-linux-gnueabi

[rth at gcc dot gnu.org]

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



--- Comment #11 from Richard Henderson  2012-12-04 
19:08:23 UTC ---

Author: rth

Date: Tue Dec  4 19:08:18 2012

New Revision: 194159



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

Log:

PR bootstrap/55571



* Makefile.in (libgcc_s.so): Depend on and link with libgcc.a.



Modified:

trunk/libgcc/ChangeLog

trunk/libgcc/Makefile.in

[Bug bootstrap/55571] [4.6/4.7/4.8 regression] PR48076 fix broke bootstrap on armv5tel-linux-gnueabi

[rth at gcc dot gnu.org]

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



--- Comment #12 from Richard Henderson  2012-12-04 
19:10:05 UTC ---

Author: rth

Date: Tue Dec  4 19:09:59 2012

New Revision: 194160



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

Log:

PR bootstrap/55571



* Makefile.in (libgcc_s.so): Depend on and link with libgcc.a.



Modified:

branches/gcc-4_7-branch/libgcc/ChangeLog

branches/gcc-4_7-branch/libgcc/Makefile.in

[Bug bootstrap/55571] [4.6/4.7/4.8 regression] PR48076 fix broke bootstrap on armv5tel-linux-gnueabi

[rth at gcc dot gnu.org]

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



--- Comment #13 from Richard Henderson  2012-12-04 
19:11:39 UTC ---

Author: rth

Date: Tue Dec  4 19:11:33 2012

New Revision: 194161



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

Log:

PR bootstrap/55571



* Makefile.in (libgcc_s.so): Depend on and link with libgcc.a.



Modified:

branches/gcc-4_6-branch/libgcc/ChangeLog

branches/gcc-4_6-branch/libgcc/Makefile.in

[Bug bootstrap/55571] [4.6/4.7/4.8 regression] PR48076 fix broke bootstrap on armv5tel-linux-gnueabi

[rth at gcc dot gnu.org]

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



Richard Henderson  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #14 from Richard Henderson  2012-12-04 
19:13:40 UTC ---

The bootstrap problem is fixed.



The issue of why the stage2 g++ driver sometimes pulls in the

shared libgcc with -static-libgcc belongs in another PR.

[Bug target/53435] (ix86_expand_vec_perm) and (ix86_expand_vec_perm) do not pass arguments to avx2_permvar8s[f,i] correctly

[glisse at gcc dot gnu.org]

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



--- Comment #6 from Marc Glisse  2012-12-04 19:18:26 
UTC ---

Can we close this one?

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

[quantheory at gmail dot com]

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



Sean Santos  changed:



   What|Removed |Added



 CC||quantheory at gmail dot com



--- Comment #10 from Sean Santos  2012-12-04 
19:28:19 UTC ---

Comment 9 seems a bit too pessimistic to me.



For one, returning ".false." for ieee_supports_* doesn't seem like a sidestep,

but more like the correct behavior in an environment that lacks IEEE support

(maybe even if the only reason is because the compiler has not implemented it).



For another, as noted above, one important use of the ieee_arithmetic module is

to test for NaN/Inf in a standard-conforming way, rather than using

compiler-specific extensions. (AFAIK, gfortran is the only F2003 compiler that

forces you to use a non-portable extension to do this.)



For that functionality, the only likely problem I can see is in deciding when

e.g. ieee_support_nan should return ".true.".



Of course this is only a fraction of what needs to be done (presumably the

easiest part), but it's much better than nothing, particularly to address what

I would expect to be one of the most common uses of this module.

[Bug c++/55581] Too-eager instantiation

[dave at boostpro dot com]

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



--- Comment #1 from Dave Abrahams  2012-12-04 
19:30:40 UTC ---

Actually, here's a simpler test case:





template 

struct mooch

{

mooch operator->();

};



template <>

struct mooch<0>

{

int x;



mooch<0>* operator->();

};



mooch<10> a; // compiles with depth 1

decltype(a.operator->()) y;   // compiles with depth 1

decltype(a->x) z; // BOOM

[Bug target/53435] (ix86_expand_vec_perm) and (ix86_expand_vec_perm) do not pass arguments to avx2_permvar8s[f,i] correctly

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

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

   ||atches/2012-05/msg01415.htm

   ||l

 Resolution||FIXED

   Target Milestone|--- |4.7.3



--- Comment #7 from Uros Bizjak  2012-12-04 19:31:28 
UTC ---

Fixed some time ago.

[Bug middle-end/55595] New: [google] r172952 (LIPO) broke profiledbootstrap on google/main, and later in google/gcc-4_7

[matt at use dot net]

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



 Bug #: 55595

   Summary: [google] r172952 (LIPO) broke profiledbootstrap on

google/main, and later in google/gcc-4_7

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: middle-end

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

ReportedBy: m...@use.net





starting with r172592, google/main fails profiledbootstrap with the error

below. going one revision back eliminates the error. later commits

compound/mutate the profiledbootstrap failures; once this bug is fixed, I'll

retest.



$ rm -rf *



$ ../google-main/configure --program-suffix=-google-4.7 --prefix=/u/mhargett

--enable-languages=c,c++,lto --enable-lto --with-fpmath=sse

--disable-libmudflap --disable-libssp --enable-build-with-cxx --enable-gold=yes

--with-mpc=/u/mhargett --with-gmp=/u/mhargett/ --with-mpfr=/u/mhargett/

--disable-multilib --disable-libgomp --disable-werror



$ make -j1 profiledbootstrap



if [ x"-fpic" != x ]; then \

  /work/mhargett/google-main-obj/./prev-gcc/xgcc

-B/work/mhargett/google-main-obj/./prev-gcc/

-B/u/mhargett/x86_64-unknown-linux-gnu/bin/

-B/u/mhargett/x86_64-unknown-linux-gnu/bin/

-B/u/mhargett/x86_64-unknown-linux-gnu/lib/ -isystem

/u/mhargett/x86_64-unknown-linux-gnu/include -isystem

/u/mhargett/x86_64-unknown-linux-gnu/sys-include-c -DHAVE_CONFIG_H -g -O2

-fprofile-use  -I. -I../../google-main/libiberty/../include  -W -Wall

-Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fpic

../../google-main/libiberty/cp-demangle.c -o pic/cp-demangle.o; \

else true; fi

../../google-main/libiberty/cp-demangle.c: In function

\u2018is_ctor_or_dtor\u2019:

../../google-main/libiberty/cp-demangle.c:5172:1: error: coverage mismatch for

function \u2018is_ctor_or_dtor\u2019 while reading counter \u2018arcs\u2019

[-Werror=coverage-mismatch]

../../google-main/libiberty/cp-demangle.c:5172:1: note: number of counters is 7

instead of 8

../../google-main/libiberty/cp-demangle.c: In function

\u2018d_demangle_callback\u2019:

../../google-main/libiberty/cp-demangle.c:5172:1: error: coverage mismatch for

function \u2018d_demangle_callback\u2019 while reading counter \u2018arcs\u2019

[-Werror=coverage-mismatch]

../../google-main/libiberty/cp-demangle.c:5172:1: note: number of counters is

25 instead of 26

../../google-main/libiberty/cp-demangle.c: In function

\u2018d_ctor_dtor_name\u2019:

../../google-main/libiberty/cp-demangle.c:5172:1: error: coverage mismatch for

function \u2018d_ctor_dtor_name\u2019 while reading counter \u2018arcs\u2019

[-Werror=coverage-mismatch]

../../google-main/libiberty/cp-demangle.c:5172:1: note: number of counters is

20 instead of 18

../../google-main/libiberty/cp-demangle.c: In function

\u2018d_operator_name\u2019:

../../google-main/libiberty/cp-demangle.c:5172:1: error: coverage mismatch for

function \u2018d_operator_name\u2019 while reading counter \u2018arcs\u2019

[-Werror=coverage-mismatch]

../../google-main/libiberty/cp-demangle.c:5172:1: note: number of counters is

21 instead of 20

../../google-main/libiberty/cp-demangle.c: In function \u2018d_make_name\u2019:

../../google-main/libiberty/cp-demangle.c:5172:1: error: coverage mismatch for

function \u2018d_make_name\u2019 while reading counter \u2018arcs\u2019

[-Werror=coverage-mismatch]

../../google-main/libiberty/cp-demangle.c:5172:1: note: number of counters is 5

instead of 4

cc1: some warnings being treated as errors

[Bug lto/55596] New: [google] r191813 broke bootstrap-lto on google/gcc-4_7 branch

[matt at use dot net]

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

 Bug #: 55596
   Summary: [google] r191813 broke bootstrap-lto on google/gcc-4_7
branch
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


r191813 broke bootstrap-lto on the google/gcc-4_7 branch. updating to one
revision prior fixes the issue. trying to cherry pick other LTO fixes from
trunk doesn't resolve the issues, only changes the error (to an ICE in
lto_fixup_prevailing_decls).

$ rm -rf *
$ ../google-gcc-4_7-searching/configure --with-build-config=bootstrap-lto
--program-suffix=-google-4.7 --prefix=/u/mhargett --enable-lto
--with-fpmath=sse --disable-libmudflap --disable-libssp --enable-build-with-cxx
--enable-gold=yes --with-mpc=/u/mhargett --with-cloog=/u/mhargett/
--with-ppl=/u/mhargett/ --with-gmp=/u/mhargett/ --with-mpfr=/u/mhargett/
--enable-cloog-backend=isl --disable-cloog-version-check --disable-multilib
--disable-libgomp --disable-werror --enable-languages=c,c++,lto

$ make 

/work/mhargett/google-gcc-4.7-obj/./prev-gcc/g++
-B/work/mhargett/google-gcc-4.7-obj/./prev-gcc/
-B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/work/mhargett/google-gcc-4.7-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/work/mhargett/google-gcc-4.7-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/work/mhargett/google-gcc-4.7-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/work/mhargett/google-gcc-4.7-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/work/mhargett/google-gcc-4_7-searching/libstdc++-v3/libsupc++
-L/work/mhargett/google-gcc-4.7-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/work/mhargett/google-gcc-4.7-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
  -g -O2 -flto=jobserver -frandom-seed=1 -DIN_GCC   -fno-exceptions -fno-rtti
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings  
-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o cc1plus \
  cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/decl.o cp/expr.o
cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o
cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o
cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o
cp/optimize.o cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o
cp/cxx-pretty-print.o cp/cp-gimplify.o tree-mudflap.o attribs.o incpath.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 i386-c.o
default-c.o cc1plus-checksum.o main.o  libbackend.a libcommon-target.a
libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
-L/u/mhargett//lib -lcloog-isl -lisl -L/u/mhargett//lib -lppl_c -lppl  -lgmpxx
-L/u/mhargett//lib -L/u/mhargett//lib -L/u/mhargett/lib -lmpc -lmpfr -lgmp
-rdynamic -ldl  -L../zlib -lz
lto1: internal compiler error: tree code ‘H?E?H@’ is not supported in LTO
streams


Let me know if providing the LTO temps would be useful.

[Bug bootstrap/55074] error during bootstrap of trunk

[matt at use dot net]

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



Matt Hargett  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #1 from Matt Hargett  2012-12-04 20:16:55 UTC 
---

Fixed with current trunk.

[Bug middle-end/55595] [google] r172952 (LIPO) broke profiledbootstrap on google/main, and later in google/gcc-4_7

[xinliangli at gmail dot com]

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



davidxl  changed:



   What|Removed |Added



 CC||xinliangli at gmail dot com



--- Comment #1 from davidxl  2012-12-04 20:19:48 
UTC ---

google/main branch is not fully tested, and not supposed to be used. Google's

release branches are.



In very near future, lots of cleanups will be done in google/main, and it will

be synced with trunk. During that period, expect it to be very unstable.



David







(In reply to comment #0)

> starting with r172592, google/main fails profiledbootstrap with the error

> below. going one revision back eliminates the error. later commits

> compound/mutate the profiledbootstrap failures; once this bug is fixed, I'll

> retest.

> 

> $ rm -rf *

> 

> $ ../google-main/configure --program-suffix=-google-4.7 --prefix=/u/mhargett

> --enable-languages=c,c++,lto --enable-lto --with-fpmath=sse

> --disable-libmudflap --disable-libssp --enable-build-with-cxx 
> --enable-gold=yes

> --with-mpc=/u/mhargett --with-gmp=/u/mhargett/ --with-mpfr=/u/mhargett/

> --disable-multilib --disable-libgomp --disable-werror

> 

> $ make -j1 profiledbootstrap

> 

> if [ x"-fpic" != x ]; then \

>   /work/mhargett/google-main-obj/./prev-gcc/xgcc

> -B/work/mhargett/google-main-obj/./prev-gcc/

> -B/u/mhargett/x86_64-unknown-linux-gnu/bin/

> -B/u/mhargett/x86_64-unknown-linux-gnu/bin/

> -B/u/mhargett/x86_64-unknown-linux-gnu/lib/ -isystem

> /u/mhargett/x86_64-unknown-linux-gnu/include -isystem

> /u/mhargett/x86_64-unknown-linux-gnu/sys-include-c -DHAVE_CONFIG_H -g -O2

> -fprofile-use  -I. -I../../google-main/libiberty/../include  -W -Wall

> -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fpic

> ../../google-main/libiberty/cp-demangle.c -o pic/cp-demangle.o; \

> else true; fi

> ../../google-main/libiberty/cp-demangle.c: In function

> \u2018is_ctor_or_dtor\u2019:

> ../../google-main/libiberty/cp-demangle.c:5172:1: error: coverage mismatch for

> function \u2018is_ctor_or_dtor\u2019 while reading counter \u2018arcs\u2019

> [-Werror=coverage-mismatch]

> ../../google-main/libiberty/cp-demangle.c:5172:1: note: number of counters is 
> 7

> instead of 8

> ../../google-main/libiberty/cp-demangle.c: In function

> \u2018d_demangle_callback\u2019:

> ../../google-main/libiberty/cp-demangle.c:5172:1: error: coverage mismatch for

> function \u2018d_demangle_callback\u2019 while reading counter 
> \u2018arcs\u2019

> [-Werror=coverage-mismatch]

> ../../google-main/libiberty/cp-demangle.c:5172:1: note: number of counters is

> 25 instead of 26

> ../../google-main/libiberty/cp-demangle.c: In function

> \u2018d_ctor_dtor_name\u2019:

> ../../google-main/libiberty/cp-demangle.c:5172:1: error: coverage mismatch for

> function \u2018d_ctor_dtor_name\u2019 while reading counter \u2018arcs\u2019

> [-Werror=coverage-mismatch]

> ../../google-main/libiberty/cp-demangle.c:5172:1: note: number of counters is

> 20 instead of 18

> ../../google-main/libiberty/cp-demangle.c: In function

> \u2018d_operator_name\u2019:

> ../../google-main/libiberty/cp-demangle.c:5172:1: error: coverage mismatch for

> function \u2018d_operator_name\u2019 while reading counter \u2018arcs\u2019

> [-Werror=coverage-mismatch]

> ../../google-main/libiberty/cp-demangle.c:5172:1: note: number of counters is

> 21 instead of 20

> ../../google-main/libiberty/cp-demangle.c: In function 
> \u2018d_make_name\u2019:

> ../../google-main/libiberty/cp-demangle.c:5172:1: error: coverage mismatch for

> function \u2018d_make_name\u2019 while reading counter \u2018arcs\u2019

> [-Werror=coverage-mismatch]

> ../../google-main/libiberty/cp-demangle.c:5172:1: note: number of counters is 
> 5

> instead of 4

> cc1: some warnings being treated as errors

[Bug middle-end/51233] [ipa-iterations] running multiple passes of early IPA on zlib produces more optimal code

[matt at use dot net]

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



--- Comment #5 from Matt Hargett  2012-12-04 20:35:09 UTC 
---

ping? if you're more comfortable with relegating multiple passes to LTO, I

think that's a good starting point. we can wait for a per-unit C++ template

case to come up after that's in.



is there anything you'd like me to do to get this moving again?



thanks!

[Bug target/54160] [4.6/4.7/4.8 Regression] gcc should not define __OBJC2__ when lang is not set to ObjC (gcc 4.6 and later)

[aldyh at gcc dot gnu.org]

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



Aldy Hernandez  changed:



   What|Removed |Added



 CC||aldyh at gcc dot gnu.org

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

   |gnu.org |



--- Comment #3 from Aldy Hernandez  2012-12-04 
20:35:54 UTC ---

I'll take a look.

[Bug middle-end/55185] Error generated on extern inline function which isn't called

[dabler at gmail dot com]

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

--- Comment #1 from DaBler  2012-12-04 20:55:17 UTC ---
I have same problem here:

$  gcc -O3 -mno-sse -xc - < #include 
> int main(){return 0;}
> END
In file included from :1:0:
/usr/include/stdlib.h: In function ‘atof’:
/usr/include/stdlib.h:280:1: error: SSE register return with SSE disabled

[Bug c++/55311] Cannot specialize template parameter of type 'const char *const' in 'using' alias

[niels at penneman dot org]

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

Niels Penneman  changed:

   What|Removed |Added

   Keywords||rejects-valid
  Known to fail||4.6.3, 4.7.2, 4.8.0

--- Comment #1 from Niels Penneman  2012-12-04 
21:00:50 UTC ---
Exact same thing in a slightly different shape: with a derived struct instead
of a 'using' alias

===

$ g++ -###
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-alpha20121202/g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20121202/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.8.0_alpha20121202/work/gcc-4.8-20121202/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-alpha20121202
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20121202/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-alpha20121202
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-alpha20121202/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-alpha20121202/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-alpha20121202/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check
--with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib
--with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-alpha20121202/python
--enable-checking=release --disable-libgcj --disable-libquadmath
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo
4.8.0_alpha20121202'
Thread model: posix
gcc version 4.8.0-alpha20121202 20121202 (experimental) (Gentoo
4.8.0_alpha20121202) 

===

extern constexpr char STRING_PTR[] = "test";

template 
struct A {};

template 
struct B: A {};

===

$ g++ -fsyntax-only -std=c++11 test2.cxx 
test2.cxx:7:26: error: ‘"test"’ is not a valid template argument of type ‘const
char*’ because ‘"test"’ is not a variable
 struct B: A {};
  ^

===

[Bug middle-end/55597] New: [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=55597

 Bug #: 55597
   Summary: [4.8 Regression] internal compiler error: in
plus_constant, at explow.c:88
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, revision 194159 gave:

[hjl@gnu-ivb-1 gcc]$ cat /tmp/testcase.c 
struct initial_sp {
  void *sp;
  int mask;
};
void foo (int *);
__thread struct initial_sp __morestack_initial_sp;
void __morestack_release_segments (void) {
  foo (&__morestack_initial_sp.mask);
}
[hjl@gnu-ivb-1 gcc]$ ./xgcc -B./ -fPIC -O2 -mx32 -S -maddress-mode=long
/tmp/testcase.c 
/tmp/testcase.c: In function ‘__morestack_release_segments’:
/tmp/testcase.c:9:1: internal compiler error: in plus_constant, at explow.c:88
 }
 ^
0x7321f3 plus_constant(machine_mode, rtx_def*, long)
/export/gnu/import/git/gcc/gcc/explow.c:88
0x5fdee7 init_alias_analysis()
/export/gnu/import/git/gcc/gcc/alias.c:2945
0xfce2ce cse_main
/export/gnu/import/git/gcc/gcc/cse.c:6543
0xfd010e rest_of_handle_cse
/export/gnu/import/git/gcc/gcc/cse.c:7435
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-ivb-1 gcc]$

[Bug rtl-optimization/55598] New: LRA on powerpc does not like assembler in libgcc

[meissner at gcc dot gnu.org]

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

 Bug #: 55598
   Summary: LRA on powerpc does not like assembler in libgcc
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: meiss...@gcc.gnu.org


Created attachment 28878
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28878
Reduced case to show the problem.

I decided to see if I could switch the powerpc to using LRA for targeting a
future machine.  I made a branch, and added a -mlra option to enable using LRA.
 I then tried to bootstrap the compiler on power7 using the -mlra option, and
it fails in building 32-bit libgcc.a.  I also tried the LRA branch and got the
same result.

The failure message is:
/home/meissner/fsf-build-ppc64/meissner-lra/./gcc/xgcc
-B/home/meissner/fsf-build-ppc64/meissner-lra/./gcc/
-B/home/meissner/fsf-install-ppc64/meissner-lra/powerpc64-unknown-linux-gnu/bin/
-B/home/meissner/fsf-install-ppc64/meissner-lra/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/meissner/fsf-install-ppc64/meissner-lra/powerpc64-unknown-linux-gnu/include
-isystem
/home/meissner/fsf-install-ppc64/meissner-lra/powerpc64-unknown-linux-gnu/sys-include
 -m32 -fPIC -O2 -g -mcpu=power7 -save-temps=obj -mlra -O2  -O2 -g -mcpu=power7
-save-temps=obj -mlra -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector   -fPIC -mlong-double-128
-mno-minimal-toc -I. -I. -I../../.././gcc
-I/home/meissner/fsf-src/meissner-lra/libgcc
-I/home/meissner/fsf-src/meissner-lra/libgcc/.
-I/home/meissner/fsf-src/meissner-lra/libgcc/../gcc
-I/home/meissner/fsf-src/meissner-lra/libgcc/../include
-I/home/meissner/fsf-src/meissner-lra/libgcc/../libdecnumber/dpd
-I/home/meissner/fsf-src/meissner-lra/libgcc/../libdecnumber   -o _muldi3.o -MT
_muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
/home/meissner/fsf-src/meissner-lra/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
/home/meissner/fsf-src/meissner-lra/libgcc/libgcc2.c: In function ‘__muldi3’:
/home/meissner/fsf-src/meissner-lra/libgcc/libgcc2.c:559:1: error: unable to
generate reloads for:
 }
 ^
(insn 19 51 20 2 (set (reg:SI 152 [ D.7253 ])
(mult:SI (reg:SI 173 [ v ])
(reg:SI 172 [ u+4 ])))
/home/meissner/fsf-src/meissner-lra/libgcc/libgcc2.c:555 119 {mulsi3}
 (expr_list:REG_DEAD (reg:SI 173 [ v ])
(nil)))
/home/meissner/fsf-src/meissner-lra/libgcc/libgcc2.c:559:1: internal compiler
error: in curr_insn_transform, at lra-constraints.c:2749
0x107b4153 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/meissner/fsf-src/meissner-lra/gcc/rtl-error.c:110
0x106860c7 curr_insn_transform
/home/meissner/fsf-src/meissner-lra/gcc/lra-constraints.c:2749
0x106885f3 lra_constraints(bool)
/home/meissner/fsf-src/meissner-lra/gcc/lra-constraints.c:3486
0x106694b7 lra(_IO_FILE*)
/home/meissner/fsf-src/meissner-lra/gcc/lra.c:2280
0x105ee0a3 do_reload
/home/meissner/fsf-src/meissner-lra/gcc/ira.c:4624
0x105ee38f rest_of_handle_reload
/home/meissner/fsf-src/meissner-lra/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.
make: *** [_muldi3.o] Error 1

I did some debugging, and determined that in this case, the problem is the
assembler statement used to get the upper half of the 32x32 multiply:

DItype
__muldi3 (DItype u, DItype v)
{
  const DWunion uu = {.ll = u};
  const DWunion vv = {.ll = v};
  DWunion w;
  DWunion __w;
  USItype __m0;
  USItype __m1;

  __m0 = uu.s.low;
  __m1 = vv.s.low;
  __asm__ ("mulhwu %0,%1,%2"
   : "=r" (__w.s.high)
   : "%r" (uu.s.low), "r" (vv.s.low));

  __w.s.low = __m0 * __m1;
  w.ll =  __w.ll;
  w.s.high += ((USItype) uu.s.low * (USItype) vv.s.high
   + (USItype) uu.s.high * (USItype) vv.s.low);

  return w.ll;
}

where __w, uu, and vv are all unions with a long long member and a structure
with two 32-bit integer fields for the high/low values.  If I replace the asm
output with a scalar value, it works fine:

DItype
__muldi3 (DItype u, DItype v)
{
  const DWunion uu = {.ll = u};
  const DWunion vv = {.ll = v};
  DWunion w;
  DWunion __w;
  USItype __m0;
  USItype __m1;
  USItype __high;

  __m0 = uu.s.low;
  __m1 = vv.s.low;
  __asm__ ("mulhwu %0,%1,%2"
   : "=r" (__high)
   : "%r" (uu.s.low), "r" (vv.s.low));

  __w.s.high = __high;
  __w.s.low = __m0 * __m1;
  w.ll =  __w.ll;
  w.s.high += ((USItype) uu.s.low * (USItype) vv.s.high
   + (USItype) uu.s.high * (USItype) vv.s.low);

  return w.ll;
}

[Bug middle-end/52306] ICE in CSE

[mikpe at it dot uu.se]

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



--- Comment #8 from Mikael Pettersson  2012-12-04 
22:05:19 UTC ---

The new test case from kde4libs ICEs g++ 4.8-20121202 and 4.6-20121130, but not

4.7-20121201, when targeting x86-linux.  The 4.8 ICE looks as follows:



../../kdeui/notifications/kstatusnotifieritem.cpp: In member function

'KDbusImageVector KStatusNotifierItemPrivate::iconToVector(const QIcon&)':

../../kdeui/notifications/kstatusnotifieritem.cpp:1037:1: internal compiler

error: in cselib_record_set, at cselib.c:2375

0x59fcc7 cselib_record_set

/tmp/gcc-4.8-20121202/gcc/cselib.c:2375

0x59fcc7 cselib_record_sets

/tmp/gcc-4.8-20121202/gcc/cselib.c:2592

0x5a005b cselib_process_insn(rtx_def*)

/tmp/gcc-4.8-20121202/gcc/cselib.c:2667

0x7327f7 reload_cse_regs_1

/tmp/gcc-4.8-20121202/gcc/postreload.c:224

0x734263 reload_cse_regs

/tmp/gcc-4.8-20121202/gcc/postreload.c:70

0x734263 rest_of_handle_postreload

/tmp/gcc-4.8-20121202/gcc/postreload.c:2289

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



The older xslt test case ICEs all three of 4.8/4.7/4.6, all in

cselib_record_set.



The reduced test case from PR43437 only ICEs 4.6, not 4.7 or 4.8.



I'll do some bisecting with the new kde4libs test case next.

[Bug lto/55596] [google] r191813 broke bootstrap-lto on google/gcc-4_7 branch

[dehao at gcc dot gnu.org]

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



dehao at gcc dot gnu.org changed:



   What|Removed |Added



 CC||dehao at gcc dot gnu.org



--- Comment #1 from dehao at gcc dot gnu.org 2012-12-04 22:19:17 UTC ---

the location_block patch indeed triggered some lto bugs. I tried to port some

fixes from upstream to google branch, but found that the related code is very

different between two versions. We can go ahead to fix these lto bugs in

google-4_7 branch, but it would take much time and will be pain. As LTO is not

heavily used, shall we just wait until we upgrade to 4.8?

[Bug target/54160] [4.6/4.7/4.8 Regression] gcc should not define __OBJC2__ when lang is not set to ObjC (gcc 4.6 and later)

[aldyh at gcc dot gnu.org]

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



--- Comment #4 from Aldy Hernandez  2012-12-04 
22:28:54 UTC ---

Proposed patch.

http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00261.html

[Bug middle-end/55597] [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=55597



H.J. Lu  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-12-04

 CC||bonzini at gnu dot org

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from H.J. Lu  2012-12-04 22:29:34 
UTC ---

It is caused by revision 193868:



http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00816.html

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

[bonzini at gnu dot org]

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



Paolo Bonzini  changed:



   What|Removed |Added



 CC||stevenb.gcc at gmail dot

   ||com



--- Comment #2 from Paolo Bonzini  2012-12-04 22:52:17 
UTC ---

Really caused by the alias analysis change.

[Bug fortran/55534] -Wno-missing-include-dirs does not work with gfortran

[anlauf at gmx dot de]

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



--- Comment #1 from Harald Anlauf  2012-12-04 23:02:29 
UTC ---

It would be nice if somebody could explain how to handle the

setting of options.



In the meantime, since this warning may generate lots of output,

I disabled it:



Index: gcc/fortran/scanner.c

===

--- gcc/fortran/scanner.c   (revision 194167)

+++ gcc/fortran/scanner.c   (working copy)

@@ -326,7 +326,7 @@

   else

{

  /* FIXME:  Also support -Wmissing-include-dirs.  */

- if (warn)

+ if (0)

gfc_warning_now ("Nonexistent include directory \"%s\"", path);

}

   return;

[Bug target/55597] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 CC||steven at gcc dot gnu.org

  Component|middle-end  |target



--- Comment #3 from Steven Bosscher  2012-12-04 
23:24:41 UTC ---

Out of expand GCC produces:



(insn 6 5 7 2 (set (reg:DI 61)

(reg:DI 0 ax)) t.c:8 -1

 (expr_list:REG_EQUAL (symbol_ref:SI ("__morestack_initial_sp") \

   [flags 0x10]  )

(nil)))

(insn 7 6 8 2 (parallel [

(set (reg:DI 62)

(plus:DI (reg:DI 61)

(const_int 4 [0x4])))

(clobber (reg:CC 17 flags))

]) t.c:8 -1

 (nil))



In alias.c, the compiler tries to simplify r62=r61+4 to

r62=symbol_ref:SI ("__morestack_initial_sp")+4 but plus_constant

doesn't accept symbol_ref:SI ("__morestack_initial_sp") because it

is is SImode but should be DImode.



Back-end bug, I'm guessing something Pmode related.

[Bug target/55597] internal compiler error: in plus_constant, at explow.c:88

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 Target||x32

 CC|steven at gcc dot gnu.org,  |

   |stevenb.gcc at gmail dot|

   |com |

Summary|[4.8 Regression] internal   |internal compiler error: in

   |compiler error: in  |plus_constant, at

   |plus_constant, at   |explow.c:88

   |explow.c:88 |



--- Comment #4 from Steven Bosscher  2012-12-04 
23:46:01 UTC ---

Yup, target bug.



(gdb) down

#5  0x00d165b2 in ix86_expand_move (mode=SImode,

operands=0x7fffc740) at ../../trunk/gcc/config/i386/i386.c:15936

15936   tmp = legitimize_tls_address (symbol, model, true);

(gdb) l

15931 rtx symbol = XEXP (XEXP (op1, 0), 0);

15932 rtx tmp = NULL;

15933

15934 model = SYMBOL_REF_TLS_MODEL (symbol);

15935 if (model)

15936   tmp = legitimize_tls_address (symbol, model, true);

15937 else if (TARGET_DLLIMPORT_DECL_ATTRIBUTES

15938  && SYMBOL_REF_DLLIMPORT_P (symbol))

15939   tmp = legitimize_dllimport_symbol (symbol, true);

15940

(gdb) p debug_rtx(op0)

(reg:SI 60)

$11 = void

(gdb) p debug_rtx(op1)

(const:SI (plus:SI (symbol_ref:SI ("__morestack_initial_sp") [flags 0x10]

)

(const_int 4 [0x4])))

$12 = void

(gdb) p debug_rtx(addend)

(const_int 4 [0x4])

$13 = void

(gdb) p debug_rtx(symbol)

(symbol_ref:SI ("__morestack_initial_sp") [flags 0x10] )

$14 = void

(gdb) 





Note how this tries to expand an SImode move.



Breakpoint 2, legitimize_tls_address (x=0x76401660, model=TLS_MODEL_REAL,

for_mov=true) at ../../trunk/gcc/config/i386/i386.c:12758

12758 rtx pic = NULL_RTX, tp = NULL_RTX;

(gdb) p debug_rtx(x)

(symbol_ref:SI ("__morestack_initial_sp") [flags 0x10] )

$15 = void

(gdb) next

12759 enum machine_mode tp_mode = Pmode;

(gdb) 

12762 switch (model)

(gdb) 

12765 dest = gen_reg_rtx (Pmode);

(gdb) p Pmode

$16 = DImode



So now you're in trouble...



And for the record: This can never be a regression, X32 doesn't exist in

previous GCC releases.

[Bug middle-end/55597] 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=55597



H.J. Lu  changed:



   What|Removed |Added



  Component|target  |middle-end



--- Comment #5 from H.J. Lu  2012-12-04 23:49:48 
UTC ---

(In reply to comment #4)

> And for the record: This can never be a regression, X32 doesn't exist in

> previous GCC releases.



Last time when I checked, GCC 4.7 supports x32.

[Bug sanitizer/55599] New: switch from mach_override to mac interpose function support in libasan broke -static-libasan

[howarth at nitro dot med.uc.edu]

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



 Bug #: 55599

   Summary: switch from mach_override to mac interpose function

support in libasan broke -static-libasan

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: sanitizer

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

ReportedBy: howa...@nitro.med.uc.edu

CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org,

ja...@gcc.gnu.org, k...@gcc.gnu.org





After r194120, the -static-libasan option fails to find the required symbols

for linking libasan.a on x86_64-apple-darwin12. For example...



% g++-fsf-4.8 -g -static-libasan -fsanitize=address cond1.C

Undefined symbols for architecture x86_64:

  "__interception::OverrideFunction(unsigned long, unsigned long, unsigned

long*)", referenced from:

  __asan::InitializeMacInterceptors()  in libasan.a(asan_mac.o)

ld: symbol(s) not found for architecture x86_64

collect2: error: ld returned 1 exit status



% nm libasan.0.dylib  | grep OverrideFunction

 U __ZN14__interception16OverrideFunctionEmmPm



% nm libasan.a | grep OverrideFunction

 U __ZN14__interception16OverrideFunctionEmmPm



Oddly when compiling normally against the dynamic library...



% g++-fsf-4.8 -g -fsanitize=address cond1.C

% nm ./a.out | grep OverrideFunction

% ./a.out

%



...the resulting executable links in libasan.0.dylib but doesn't complain about

the undefined symbol on execution.

[Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.

[siarhei.siamashka at gmail dot com]

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



--- Comment #6 from Siarhei Siamashka  
2012-12-05 00:06:39 UTC ---

(In reply to comment #5)

> This is really an enhancement request...



Is there anything that can be done with this enhancement request?



I can see that __ARM_FEATURE_DSP and __ARM_FEATURE_UNALIGNED have been added:

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

http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00878.html



This is a step in the right direction, but still not enough.

[Bug middle-end/55595] [google] r172952 (LIPO) broke profiledbootstrap on google/main, and later in google/gcc-4_7

[matt at use dot net]

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



--- Comment #2 from Matt Hargett  2012-12-05 00:06:47 UTC 
---

I'm not trying to use google/main, but rather google/gcc-4_7. I got to the

beginning of the 4.7 branch and was still getting the error, so I traced it

back to google/main. If you can fix profiledbootstrap just in google/gcc-4_7,

that would be fab.



Thanks!

[Bug sanitizer/55599] switch from mach_override to mac interpose function support in libasan broke -static-libasan

[howarth at nitro dot med.uc.edu]

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



--- Comment #1 from Jack Howarth  2012-12-05 
00:07:04 UTC ---

I assume that the mechanism for mac function imposition prohibits the use of a

static libasan? If so we should remove the support for -static-libasan from

gcc/config/darwin.h.

[Bug tree-optimization/55600] New: excessive size of vectorized code

[neleai at seznam dot cz]

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



 Bug #: 55600

   Summary: excessive size of vectorized code

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: nel...@seznam.cz





Consider following code:



int sum(int *s){long i;

  int su=0;

  for(i=0;i<128;i+=2) su+=s[i]*s[i+1];

  return su;

}



When compiled by latest gcc with -O3 then generated assembly has 1099 bytes.

[Bug lto/55596] [google] r191813 broke bootstrap-lto on google/gcc-4_7 branch

[matt at use dot net]

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



--- Comment #2 from Matt Hargett  2012-12-05 00:56:56 UTC 
---

We have a large C++ application that was working with LTO in google/gcc-4_6,

and now we're running into issues on google/gcc-4_7. We saw performance gains

and binary size decreases with LTO that were extremely useful. Understandably,

we're concerned about using LTO as all with the newer toolchain if

bootstrap-lto doesn't work.



Are there other patches from trunk not yet backported into the 4_7 branch that

make merging the other LTO fixes difficult? Anything you can do to restore the

functionality that worked in previous google branches is greatly appreciated.



Thanks!