[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto

[rguenth at gcc dot gnu.org]

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



--- Comment #35 from Richard Biener  2013-03-06 
08:38:50 UTC ---

Author: rguenth

Date: Wed Mar  6 08:38:46 2013

New Revision: 196487



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

Log:

2013-03-06  Richard Biener  



PR middle-end/50494

* tree-vect-data-refs.c (vect_can_force_dr_alignment_p):

Do not adjust alignment of DECL_IN_CONSTANT_POOL decls.



Revert

2013-02-13  Richard Biener  



PR lto/50494

* varasm.c (output_constant_def_1): Get the decl representing

the constant as argument.

(output_constant_def): Wrap output_constant_def_1.

(make_decl_rtl): Use output_constant_def_1 with the decl

representing the constant.

(build_constant_desc): Optionally re-use a decl already

representing the constant.

(tree_output_constant_def): Adjust.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/tree-vect-data-refs.c

trunk/gcc/varasm.c

[Bug c++/56534] [4.7/4.8 Regression] ICE Segfault on invalid code in check_elaborated_type_specifier

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||dodji at gcc dot gnu.org,

   ||jakub at gcc dot gnu.org,

   ||jason at gcc dot gnu.org



--- Comment #3 from Jakub Jelinek  2013-03-06 
08:40:18 UTC ---

Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181653

[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|REOPENED|RESOLVED

 Resolution||FIXED



--- Comment #36 from Richard Biener  2013-03-06 
08:45:22 UTC ---

Fixed.

[Bug target/55181] [4.7/4.8 Regression] Expensive shift loop where a bit-testing instruction could be used

[rguenth at gcc dot gnu.org]

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



--- Comment #6 from Richard Biener  2013-03-06 
08:51:30 UTC ---

Note that a bit-test instruction can only be used if the and only feeds a

comparison against zero.  Not sure how canonical bit-test patterns should

look like, but combine should be able to work this out, no?  Unless we

mess things up earlier during generic expansion (which seems to be the

case)

[Bug libquadmath/55473] quadmath.h should have extern "C" for C++ users

[skannan at redhat dot com]

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



--- Comment #1 from Shakthi Kannan  2013-03-06 
08:53:19 UTC ---

Created attachment 29593

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

Added cplusplus macro usage

[Bug tree-optimization/49234] [4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



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

   |Regression] |-Wstrict-overflow gives

   |-Wstrict-overflow gives |obviously unwarranted

   |obviously unwarranted   |warning

   |warning |



--- Comment #17 from Richard Biener  2013-03-06 
08:55:46 UTC ---

The patch is a hack.  Comparing SSA_NAME_VAR is very fragile, nothing but

debug info cares about SSA_NAME_VAR.



I can't see why constant PHI arguments should be in any way special - in

fact this is just the very usual induction variable PHI with a constant

initial value ...

[Bug c++/56543] [4.7/4.8 Regression] ICE on valid code in copy_node_stat

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P1



--- Comment #3 from Richard Biener  2013-03-06 
08:57:12 UTC ---

Regression on the branch, P1.

[Bug middle-end/56548] New: [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[d.g.gorbachev at gmail dot com]

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



 Bug #: 56548

   Summary: [4.8 Regression] ICE in emit_move_insn, at expr.c:3486

with -march=pentium{pro,2,3} -O3

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

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

ReportedBy: d.g.gorbac...@gmail.com





GCC 4.8.0 20130303 (experimental).



$ cat > bug.c

short foo(short x)

{

  int i;



  for (i = 0; i < 3; i++)

if (x > 0)

  x--;



  return x;

}

^D

$ gcc -S -O3 -march=pentium3 bug.c

bug.c: In function 'foo':

bug.c:9:3: internal compiler error: in emit_move_insn, at expr.c:3486

   return x;

   ^

0x834eaa1 emit_move_insn(rtx_def*, rtx_def*)

../../gcc-4.8/gcc/expr.c:3485

0x8600ef9 expand_value_return

../../gcc-4.8/gcc/stmt.c:1461

0x86068d8 expand_return(tree_node*)

../../gcc-4.8/gcc/stmt.c:1547

0x825eefc expand_gimple_stmt_1

../../gcc-4.8/gcc/cfgexpand.c:2182

0x825f82c expand_gimple_stmt

../../gcc-4.8/gcc/cfgexpand.c:2304

0x8262484 expand_gimple_basic_block

../../gcc-4.8/gcc/cfgexpand.c:4083

0x82648c8 gimple_expand_cfg

../../gcc-4.8/gcc/cfgexpand.c:4602



GCC 20121118 (r193607) - fails, 2012 (r193417) - works.

[Bug tree-optimization/56541] vectorizaton fails in conditional assignment of a constant

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Keywords||missed-optimization

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-03-06

 Blocks||53947

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2013-03-06 
09:13:29 UTC ---

if-conversion is confused by the three-argument PHI node:



  :

  # rMin_3 = PHI 



that occurs because of the forwarder block (which isn't one in the

case the addition appears).  DOM produces this by threading



  if (rMin_12 > 0.0)

goto ;

  else

goto ;



  :



  :

  # rMin_2 = PHI 

  if (rMin_2 > 0.0)

goto ;

  else

goto ;

...

  :

  # rMin_3 = PHI 



for rMin_2 == 1.5e+2.  That's a good optimization.

[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #19 from Richard Biener  2013-03-06 
09:45:11 UTC ---

Ok, with some added debug printing I see



 Updating SSA:

 creating PHI node in block #6 for elim_cost$cost

 creating PHI node in block #17 for elim_cost$cost

-creating PHI node in block #19 for cost$cost

 creating PHI node in block #6 for elim_cost$complexity

+creating PHI node in block #19 for cost$cost



that's obviously a problem (creating a PHI node involves creating a new

SSA name).  That's because we insert new PHI nodes for to rename symbols

via



  FOR_EACH_VEC_ELT (symbols_to_rename, i, sym)

insert_updated_phi_nodes_for (sym, dfs, blocks_to_update,

  update_flags);



but we need to visit that in UID order ...



I have a patch.

[Bug pch/56549] New: #pragma once ineffective with BOM in include file

[yurivkhan at gmail dot com]

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

 Bug #: 56549
   Summary: #pragma once ineffective with BOM in include file
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yurivk...@gmail.com


Created attachment 29594
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29594
Minimal example demonstrating the problem

When an include file starts with a UTF-8 byte order mark and is included in a
precompiled header, it is not protected against repeated inclusion.

Environment:
 * Ubuntu 12.04 amd64
 * GCC 4.6.3 from Ubuntu repo

To reproduce:

$ unzip pragma-once-bom.zip
$ make

The contents of the archive are listed below for convenience of discussion.

Foo.h:
===
#pragma once

struct Foo {};
===

stable.h:
===
#include "Foo.h"
===

main.cpp:
===
#include "stable.h"

int main() { Foo foo; }
===

Makefile:
===
all: main.o

pragma-once.gch/c++: stable.h Foo.h
@test -d pragma-once.gch || mkdir pragma-once.gch
g++ -x c++-header -c stable.h -o pragma-once.gch/c++

main.o: main.cpp stable.h Foo.h pragma-once.gch/c++
g++ -c -include pragma-once -o main.o main.cpp

clean:
@rm -rf pragma-once.gch main.o
===

Expected behavior:

===
$ make
g++ -x c++-header -c stable.h -o pragma-once.gch/c++
g++ -c -include pragma-once -o main.o main.cpp
===

Observed behavior:

===
$ make
g++ -x c++-header -c stable.h -o pragma-once.gch/c++
g++ -c -include pragma-once -o main.o main.cpp
In file included from stable.h:1:0,
 from main.cpp:1:
Foo.h:3:8: error: redefinition of ‘struct Foo’
Foo.h:3:8: error: previous definition of ‘struct Foo’
make: *** [main.o] Error 1
===

Workarounds/observations:

* If the header file does not contain a BOM, the problem does not occur.
* With include guards instead of #pragma once, the problem does not occur.
* In a real project, changing an #include  to #include
 in the precompiled header stable.h, or changing an #include
 to #include "Foo.h" in a different header included by stable.h,
also fixes the immediate problem.

[Bug pch/56549] #pragma once ineffective with BOM in include file

[yurivkhan at gmail dot com]

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



--- Comment #1 from Yuri Khan  2013-03-06 09:52:01 
UTC ---

Also reproduced on 4.7.2.

[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-03-06

 CC||jakub at gcc dot gnu.org

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2013-03-06 
09:58:31 UTC ---

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

[Bug c++/56534] [4.7/4.8 Regression] ICE Segfault on invalid code in check_elaborated_type_specifier

[paolo.carlini at oracle dot com]

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



--- Comment #4 from Paolo Carlini  2013-03-06 
10:13:07 UTC ---

Thanks Jakub, that seems consistent with my simple analysis.

[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #2 from Jakub Jelinek  2013-03-06 
10:22:44 UTC ---

Created attachment 29595

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

gcc48-pr56548.patch



Untested fix.  Note I have no idea what performance issue on MIPS the patch

that regressed this was fixing and whether this fix doesn't undo that (or parts

thereof).  On the other side, unexpectedly returning a rtx in different mode

from what has been requested is a sure way to ICEs or miscompilations.

[Bug target/56470] [4.8 Regression] ICE output_operand: invalid shift operand

[rearnsha at gcc dot gnu.org]

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



Richard Earnshaw  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED



--- Comment #5 from Richard Earnshaw  2013-03-06 
10:27:03 UTC ---

Working on a fix.

[Bug c++/55402] Compiling large initializer lists never finishes

[steven at gcc dot gnu.org]

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



--- Comment #11 from Steven Bosscher  2013-03-06 
10:30:20 UTC ---

Maybe the issues in this bug are the same as those for bug 55135.

[Bug fortran/56378] [4.6/4.7/4.8 Regression] ICE with C_LOC

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P3  |P5

   Target Milestone|--- |4.6.4

[Bug c++/53958] set_slot_part and canon_value_cmp using 90% of compile time

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org,

   ||steven at gcc dot gnu.org



--- Comment #5 from Steven Bosscher  2013-03-06 
10:38:08 UTC ---

More var-tracking slowness. Maybe fixed by recent patches, needs triaging.



NB: this is only not marked as a regression because all maintained release

branches have the problem. That's a rather odd way to "hide" a regression,

but it was so decided by Richi. IMHO it's worth having a look at this, the

test case isn't completely unreasonable.

[Bug libquadmath/56379] libquadmath: Wrong result for strtoflt128.c if compiled with -O0

[skannan at redhat dot com]

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



Shakthi Kannan  changed:



   What|Removed |Added



 CC||skannan at redhat dot com



--- Comment #6 from Shakthi Kannan  2013-03-06 
10:39:00 UTC ---

I tested the code on trunk r196485, and the output is shown correctly. 



This bug can be closed.

[Bug middle-end/37448] [4.6/4.7/4.8 Regression] cannot compile big function

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



Summary|gcc 4.3.1 cannot compile|[4.6/4.7/4.8 Regression]

   |big function|cannot compile big function

  Known to fail||4.7.2, 4.8.0



--- Comment #50 from Steven Bosscher  2013-03-06 
10:42:20 UTC ---

Note this is a regression.

[Bug target/56550] New: cortex-m3: incorrect write to member of volatile packed structure

[jblackarty at gmail dot com]

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



 Bug #: 56550

   Summary: cortex-m3: incorrect write to member of volatile

packed structure

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: critical

  Priority: P3

 Component: target

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

ReportedBy: jblacka...@gmail.com





GCC generates invalid write access instructions for unaligned member of

volatile packed structure on ARM Cortex-M3 target.



Simple testcase compiled with "arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -g3

-gdwarf-2 -nostartfiles testcase.c -o testcase.elf":



#include 

struct _test_struct_t {

uint8_t m1;

uint8_t m2;

uint32_t m3;

uint8_t m4;

uint32_t m5;

} __attribute__((packed));

volatile struct _test_struct_t test_struct;

int main(void) {

int test_var = 0xFF01;

test_struct.m5 = test_var;

// here test_struct.m5 == 0x01

return 0;

}



When I remove m1,m2,m3, result is 0x01.

When I remove m1, m2, m3, m4, result become correct.



I tested it in Yagarto ARM toolchain (win32 build) with gcc versions 4.7.2 and

4.6.0 both.



This situation looks similar to #48784 and #20102.

[Bug middle-end/37448] cannot compile big function

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



Summary|[4.6/4.7/4.8 Regression]|cannot compile big function

   |cannot compile big function |



--- Comment #51 from Richard Biener  2013-03-06 
10:45:50 UTC ---

See comment #42 ...

[Bug c++/55135] Segfault of gcc on a big file

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



Version|4.4.5   |4.8.0

   Target Milestone|4.8.0   |---

Summary|[4.8 Regression] Segfault   |Segfault of gcc on a big

   |of gcc on a big file|file



--- Comment #23 from Richard Biener  2013-03-06 
10:47:18 UTC ---

PR47344 tracks the regression property of this bug.

[Bug middle-end/47344] [4.6/4.7/4.8 Regression][meta-bug] GCC gets slower and uses more memory

[steven at gcc dot gnu.org]

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



--- Comment #7 from Steven Bosscher  2013-03-06 
10:51:27 UTC ---

This bug looks like the wrong idea to me. Old is apparently anything

older than the maintained release branches, but many users "in the field"

still use older compilers that come with their respective distributions.



For instance a regresion that is present since GCC 4.6 but not in GCC 4.5

gets reduced in importance and visibility by not marking it as regression

and instead only adding it to this grab-a-bag PR. Example of such a case

is bug 53958.



This is a change of old existing policy that any regression should be

marked as such. This policy change should have been discussed (and IMHO

rejected) on the GCC mailing list.



Also, this meta-bug depends on not-so-old regressions, so it's already

more like a collection of compile/memory hog issues than a collection

point for apparently "unimportant" regressions.

[Bug c/56113] out of memory when compiling a function with many goto labels (50k > )

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



  Component|middle-end  |c



--- Comment #29 from Steven Bosscher  2013-03-06 
10:53:47 UTC ---

Now a C front end issue.

[Bug c++/12850] memory consumption for heavy template instantiations tripled since 3.3

[rguenth at gcc dot gnu.org]

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



--- Comment #48 from Richard Biener  2013-03-06 
10:53:50 UTC ---

I've added the testcase to http://gcc.opensuse.org/c++bench/random/

[Bug middle-end/47344] [4.6/4.7/4.8 Regression][meta-bug] GCC gets slower and uses more memory

[rguenther at suse dot de]

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



--- Comment #8 from rguenther at suse dot de  
2013-03-06 10:57:15 UTC ---

On Wed, 6 Mar 2013, steven at gcc dot gnu.org wrote:



> 

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

> 

> --- Comment #7 from Steven Bosscher  2013-03-06 
> 10:51:27 UTC ---

> This bug looks like the wrong idea to me. Old is apparently anything

> older than the maintained release branches, but many users "in the field"

> still use older compilers that come with their respective distributions.

> 

> For instance a regresion that is present since GCC 4.6 but not in GCC 4.5

> gets reduced in importance and visibility by not marking it as regression

> and instead only adding it to this grab-a-bag PR. Example of such a case

> is bug 53958.

> 

> This is a change of old existing policy that any regression should be

> marked as such. This policy change should have been discussed (and IMHO

> rejected) on the GCC mailing list.

> 

> Also, this meta-bug depends on not-so-old regressions, so it's already

> more like a collection of compile/memory hog issues than a collection

> point for apparently "unimportant" regressions.



All these regressions clutter the list of important regressions.

All of them are present in more or less severe form in all maintained

branches.



There is a similar issue for missed-optimization regressions that

are long-standing.

[Bug middle-end/38474] compile time explosion in dataflow_set_preserve_mem_locs at -O3

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 Status|WAITING |NEW

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

   |atches/2012-05/msg01813.htm |

   |l   |

 CC|hubicka at gcc dot gnu.org, |

   |jamborm at gcc dot gnu.org, |

   |matz at gcc dot gnu.org,|

   |vmakarov at redhat dot com  |

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

   ||gnu.org

Summary|slow compilation at -O0 due |compile time explosion in

   |to expand's temp slot goo   |dataflow_set_preserve_mem_l

   ||ocs at -O3

  Known to fail||4.8.0

[Bug middle-end/54896] optimization slowness on large basic blocks

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



Summary|Some optimization slowness  |optimization slowness on

   |with GCC 4.7.2  |large basic blocks

  Known to fail||4.6.0



--- Comment #6 from Steven Bosscher  2013-03-06 
11:03:44 UTC ---

(In reply to comment #5)

> Generic compile-time regression umbrella.



Why? This is not an old regression.

[Bug c++/56543] [4.7/4.8 Regression] ICE on valid code in copy_node_stat

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 CC||mpolacek at gcc dot gnu.org



--- Comment #4 from Marek Polacek  2013-03-06 
11:06:40 UTC ---

We're calling copy_node on the second argument of

 

local bindings <(nil)>>

d.C:3:48>

but there isn't such an argument at all.  Oops.

[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 CC|gcc-bugs at gcc dot gnu.org |

 Blocks||47344



--- Comment #21 from Steven Bosscher  2013-03-06 
11:07:54 UTC ---

IRA now is very different from IRA in early 2009.  Some new timings

for GCC 4.8 trunk would be nice. Perhaps this bug is already fixed.

[Bug middle-end/54896] optimization slowness on large basic blocks

[rguenther at suse dot de]

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



--- Comment #7 from rguenther at suse dot de  
2013-03-06 11:11:28 UTC ---

On Wed, 6 Mar 2013, steven at gcc dot gnu.org wrote:



> 

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

> 

> Steven Bosscher  changed:

> 

>What|Removed |Added

> 

> Summary|Some optimization slowness  |optimization slowness on

>|with GCC 4.7.2  |large basic blocks

>   Known to fail||4.6.0

> 

> --- Comment #6 from Steven Bosscher  2013-03-06 
> 11:03:44 UTC ---

> (In reply to comment #5)

> > Generic compile-time regression umbrella.

> 

> Why? This is not an old regression.



It's a regression on all maintained branches.

[Bug c++/56543] [4.7/4.8 Regression] ICE on valid code in copy_node_stat

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2013-03-06 
11:13:23 UTC ---

   The second is NULL if there are no explicit arguments, or a

   TREE_VEC of arguments.



Thus, perhaps:



-if (TREE_CODE (fullname) == TEMPLATE_ID_EXPR)

+if (TREE_CODE (fullname) == TEMPLATE_ID_EXPR

+&& TREE_OPERAND (fullname, 1))



?

[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure

[rguenth at gcc dot gnu.org]

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



--- Comment #20 from Richard Biener  2013-03-06 
11:24:20 UTC ---

Author: rguenth

Date: Wed Mar  6 11:24:07 2013

New Revision: 196488



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

Log:

2013-03-06  Richard Biener  



PR middle-end/56294

* tree-into-ssa.c (insert_phi_nodes_for): Add dumping.

(insert_updated_phi_nodes_compare_uids): New function.

(update_ssa): Sort symbols_to_rename after UID before

traversing it to insert PHI nodes.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/tree-into-ssa.c

[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #21 from Richard Biener  2013-03-06 
11:25:04 UTC ---

Fixed.

[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2

[rguenth at gcc dot gnu.org]

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



--- Comment #22 from Richard Biener  2013-03-06 
11:38:07 UTC ---

4.7.2  -O0  25s  2189981kB



 integrated RA   :   8.96 (35%) usr   0.89 (28%) sys   9.89 (34%) wall 

206439 kB (16%) ggc

 reload  :   2.98 (12%) usr   0.07 ( 2%) sys   3.05 (11%) wall 

 43197 kB ( 3%) ggc



4.8.0  -O0  29s  2111318kB



 integrated RA   :   8.88 (31%) usr   0.41 (13%) sys   9.32 (29%) wall 

206439 kB (18%) ggc

 LRA non-specific:   5.50 (19%) usr   0.08 ( 3%) sys   5.59 (17%) wall 

  4600 kB ( 0%) ggc



4.8.0  -O2  (terminated after 9 minutes waiting, LIM being the offender, I

suspect domwalk ...)  >2.5GB



applying domwalk fix ...



4.8.0  -O1  still awfully slow



the smaller testcase is also tested on http://gcc.opensuse.org/c++bench/random/

but it runs OOM at -O1 and -O2 there (there is a virtual ulimit of 1GB due

to lack of resources on the machine), but -O3 surprisingly works so you

can see a recent time-report there (also for -O0).



At -O3 you can see there (everything > 10%):



 tree loop invariant motion:  53.83 (13%) usr

 PRE : 116.26 (29%) usr 

 LRA hard reg assignment :  73.68 (18%) usr

 load CSE after reload   :  38.67 (10%) usr



ISTR the testcases are not exactly exposing the same issues.

[Bug middle-end/47344] [4.6/4.7/4.8 Regression][meta-bug] GCC gets slower and uses more memory

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 CC||steven at gcc dot gnu.org



--- Comment #9 from Steven Bosscher  2013-03-06 
12:01:27 UTC ---

(In reply to comment #8)

> All these regressions clutter the list of important regressions.



And why would all of these not be important?

Hiding a problem is not solving the problem.



And it always was policy that a regression should be marked as such. If

it is not important enough, you can set its priority to P4 or P5, but we

should never remove the regression marker.



See http://gcc.gnu.org/ml/gcc/2007-12/msg00550.html

[Bug middle-end/47344] [4.6/4.7/4.8 Regression][meta-bug] GCC gets slower and uses more memory

[jakub at gcc dot gnu.org]

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



--- Comment #10 from Jakub Jelinek  2013-03-06 
12:07:28 UTC ---

I agree with Richard here, it isn't that much hidden, simplifies RM tasks and

allows us to actually release the compiler in roughly timely manner.

[Bug c++/55135] Segfault of gcc on a big file

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



  Known to work||4.6.3

  Known to fail||4.7.2, 4.8.0



--- Comment #24 from Steven Bosscher  2013-03-06 
12:09:26 UTC ---

(In reply to comment #23)

> PR47344 tracks the regression property of this bug.



?! This is also a regression from GCC 4.6 (commen #5), how in the world 

does that qualify as an "old regression"?

[Bug c++/55135] Segfault of gcc on a big file

[steven at gcc dot gnu.org]

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



--- Comment #25 from Steven Bosscher  2013-03-06 
12:10:31 UTC ---

(NB 4.6.3 known to work w.r.t. comment #5, not w.r.t. original bug report)

[Bug middle-end/47344] [4.6/4.7/4.8 Regression][meta-bug] GCC gets slower and uses more memory

[rguenth at gcc dot gnu.org]

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



--- Comment #11 from Richard Biener  2013-03-06 
12:11:38 UTC ---

(In reply to comment #9)

> (In reply to comment #8)

> > All these regressions clutter the list of important regressions.

> 

> And why would all of these not be important?

> Hiding a problem is not solving the problem.

> 

> And it always was policy that a regression should be marked as such. If

> it is not important enough, you can set its priority to P4 or P5, but we

> should never remove the regression marker.

> 

> See http://gcc.gnu.org/ml/gcc/2007-12/msg00550.html



Well, the issue with these kind of testcases / bugs is that we cannot

easily mark them as dups of each other because nobody separates the

issues the testcases show into separate bugreports (which could be

individually marked as regression).  So the bugs tend to stay open

forever, with much confusion as to what issue (still) exists or has

popped up again or new.



Tracking the testcases so we see when they regress again is important

(and gcc.opensuse.org/c++bench/random is just a lame attempt, because

C++ issues keep breaking testcases and because the machine has not

enough memory to keep up with the task - and the scripting is lame, too ;))



I realize this meta-bug is a bad attempt at making the important regression

numbers look better ;)

[Bug c++/55135] Segfault of gcc on a big file

[rguenther at suse dot de]

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



--- Comment #26 from rguenther at suse dot de  
2013-03-06 12:14:03 UTC ---

On Wed, 6 Mar 2013, steven at gcc dot gnu.org wrote:



> 

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

> 

> Steven Bosscher  changed:

> 

>What|Removed |Added

> 

>   Known to work||4.6.3

>   Known to fail||4.7.2, 4.8.0

> 

> --- Comment #24 from Steven Bosscher  2013-03-06 
> 12:09:26 UTC ---

> (In reply to comment #23)

> > PR47344 tracks the regression property of this bug.

> 

> ?! This is also a regression from GCC 4.6 (commen #5), how in the world 

> does that qualify as an "old regression"?



Ah, just because nobody has tried 4.5 doesn't say it isn't a regression

in 4.6!



(what is a regression in compile-time / memory-usage?  technically

I'd say if T2 > T1 or M2 > M1 it's a regression ... welcome to

the world of an ever increasing number of open "regressions")

[Bug c++/55135] Segfault of gcc on a big file

[rguenth at gcc dot gnu.org]

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



--- Comment #27 from Richard Biener  2013-03-06 
12:16:06 UTC ---

Btw, I wouldn't call



> gcc-4.6.3: 1:39.92 total



"work" ;)  Also the reporter says the bug is in 4.4.5 (so we are again

turning a bug into a different bug ... :/)

[Bug c++/55135] Segfault of gcc on a big file

[steven at gcc dot gnu.org]

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



--- Comment #28 from Steven Bosscher  2013-03-06 
12:18:01 UTC ---

(In reply to comment #22)

> Posted for discussion here:

> http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00193.html



OT: Another trivial speed-up for bitmaps used as regsets (and probably

in general) is to look at head->first if head->current is not the element

containing the sought bit, and *not* update head->current if head->first

is the right element.  This speeds up regsets because a common access

pattern is to look at sets containing both pseudos and hardregs, and on

most targets all hardregs are in head->first.  Not updating head->current

preserves a pointer to the latest accessed pseudos.



I'll implement this idea and come back with some timings.

[Bug c++/55135] Segfault of gcc on a big file

[rguenther at suse dot de]

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



--- Comment #29 from rguenther at suse dot de  
2013-03-06 12:23:21 UTC ---

On Wed, 6 Mar 2013, steven at gcc dot gnu.org wrote:



> 

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

> 

> --- Comment #28 from Steven Bosscher  2013-03-06 
> 12:18:01 UTC ---

> (In reply to comment #22)

> > Posted for discussion here:

> > http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00193.html

> 

> OT: Another trivial speed-up for bitmaps used as regsets (and probably

> in general) is to look at head->first if head->current is not the element

> containing the sought bit, and *not* update head->current if head->first

> is the right element.  This speeds up regsets because a common access

> pattern is to look at sets containing both pseudos and hardregs, and on

> most targets all hardregs are in head->first.  Not updating head->current

> preserves a pointer to the latest accessed pseudos.

> 

> I'll implement this idea and come back with some timings.



Indeed a nice idea ;)  I suppose ->current should only be updated

if its new distance to head->first is bigger than 

(and zero is of course an obvious one)

[Bug c++/51884] [C++11] ICE with local class/lambda template argument

[jason at gcc dot gnu.org]

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



Jason Merrill  changed:



   What|Removed |Added



   Keywords||ice-on-valid-code

Summary|lambda with templates   |[C++11] ICE with local

   ||class/lambda template

   ||argument



--- Comment #7 from Jason Merrill  2013-03-06 
14:09:01 UTC ---

And reduced again, as much as possible.  The ICE is caused by trying to

generate the partially-instantiated type of foo::bar, and thereby looking

up test::value, which uses the (non-reentrant) dfs functions, in order to

mangle the name of B's vtable, which is also done using the dfs functions.



template

  struct test { static const int value = 0; };

template

  struct enable_if { typedef void type; };



struct A { virtual void f() {} };

template struct B : A { };



template struct foo;

template

struct foo::value>::type>

{

  template  void bar() const  {

struct C { } c;

B b;

  }

};



int main() {

  foo f;

  f.bar();

}

[Bug tree-optimization/56539] [4.6/4.7/4.8 Regression] ICE: verify_ssa failed: caused by -foptimize-sibling-calls

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #6 from Jakub Jelinek  2013-03-06 
14:14:24 UTC ---

Created attachment 29596

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

gcc48-pr56539.patch



Untested fix.

[Bug c++/56543] [4.7/4.8 Regression] ICE on valid code in copy_node_stat

[jason at gcc dot gnu.org]

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



--- Comment #6 from Jason Merrill  2013-03-06 
14:28:15 UTC ---

(In reply to comment #5)

> -if (TREE_CODE (fullname) == TEMPLATE_ID_EXPR)

> +if (TREE_CODE (fullname) == TEMPLATE_ID_EXPR

> +&& TREE_OPERAND (fullname, 1))



OK.

[Bug c++/56543] [4.7/4.8 Regression] ICE on valid code in copy_node_stat

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #7 from Jakub Jelinek  2013-03-06 
14:31:01 UTC ---

Created attachment 29597

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

gcc48-pr56543.patch



Thanks.  This has been already bootstrapped in the mean time, regtest still

pending (but, as it is unconditional ICE before, I don't see how it could

change anything on any testcase that hasn't been ICEing before).

[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower

[jakub at gcc dot gnu.org]

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



--- Comment #2 from Jakub Jelinek  2013-03-06 
15:06:41 UTC ---

Created attachment 29598

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

assign.c



With -O3 -march=corei7 -fomit-frame-pointer -funroll-loops -ffast-math

the different in *.optimized dump from r196262 to r196263 is just:

@@ -176,7 +176,6 @@ Assignment (long int[101] * x)

   short int[101][101] * pretmp_418;

   long int _429;

   long int _431;

-  unsigned long _432;

   long unsigned int patt_438;

   unsigned int _440;

   long unsigned int patt_441;

@@ -293,8 +292,7 @@ Assignment (long int[101] * x)

   _108 = _130 >> 3;

   _89 = -_108;

   _72 = (short unsigned int) _89;

-  _432 = _89 & 1;

-  prolog_loop_niters.59_193 = (short unsigned int) _432;

+  prolog_loop_niters.59_193 = _72 & 1;

   if (prolog_loop_niters.59_193 == 0)

 goto ;

   else

@@ -307,7 +305,7 @@ Assignment (long int[101] * x)

   :

   # j_288 = PHI <1(18), 0(17)>

   # c_287 = PHI 

-  prolog_loop_adjusted_niters.60_357 = _89 & 1;

+  prolog_loop_adjusted_niters.60_357 = (sizetype) prolog_loop_niters.59_193;

   niters.61_359 = 101 - prolog_loop_niters.59_193;

   base_off.68_53 = prolog_loop_adjusted_niters.60_357 * 8;

   vect_p.69_48 = pretmp_386 + base_off.68_53;



>From the bugreport, it isn't clear if you were measuring -m32 or -m64

performance, but I guess the *.optimized dump change could just increase

register pressure and pessimize the loop RA or something.

[Bug tree-optimization/56539] [4.6/4.7/4.8 Regression] ICE: verify_ssa failed: caused by -foptimize-sibling-calls

[redi at gcc dot gnu.org]

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



--- Comment #7 from Jonathan Wakely  2013-03-06 
15:08:29 UTC ---

The patch fixes the problem for both 4.7 and 4.8, using the testcase above and

the original C++ one it was reduced from.

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

[jamborm at gcc dot gnu.org]

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



--- Comment #179 from Martin Jambor  2013-03-06 
15:14:35 UTC ---

I'm currently (gcc revision 196427, FF changeset 123831:c95439870e05)

facing a few ICEs during the compilation phase with the following

backtrace:



#0  0x00f89a73 in get_location_from_adhoc_loc (set=0x77ff2000,

loc=2947526575) at /home/mjambor/gcc/trunk/src/libcpp/line-map.c:165

#1  0x00c247fe in inlined_function_outer_scope_p (block=0x7fffee4bcb28)

at /home/mjambor/gcc/trunk/src/gcc/tree.h:5561

#2  pack_ts_block_value_fields (expr=0x7fffee4bcb28, bp=0x7fffd1a0,

ob=0x1c73210)

at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:319

#3  streamer_pack_tree_bitfields (ob=0x1c73210, bp=0x7fffd1a0,

expr=0x7fffee4bcb28)

at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:417

#4  0x009c3bc9 in lto_write_tree (ref_p=true, expr=0x7fffee4bcb28,

ob=0x1c73210)

at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:317

#5  lto_output_tree (ob=0x1c73210, expr=0x7fffee4bcb28, ref_p=true,

this_ref_p=) at

/home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:410

#6  0x00c26617 in write_ts_common_tree_pointers (ref_p=true,

expr=0x73f6bc80, ob=0x1c73210)

at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:514

#7  streamer_write_tree_body (ob=0x1c73210, expr=0x73f6bc80,

ref_p=)

at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:845

#8  0x009c3bf7 in lto_write_tree (ref_p=true, expr=0x73f6bc80,

ob=0x1c73210)

at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:321

#9  lto_output_tree (ob=ob@entry=0x1c73210, expr=0x73f6bc80,

ref_p=ref_p@entry=true,

this_ref_p=this_ref_p@entry=true)

at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:410

#10 0x00c26e62 in write_ts_exp_tree_pointers (ref_p=,

expr=, ob=)

at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:747

#11 streamer_write_tree_body (ob=0x1c73210, expr=0x7fffecc63dc0,

ref_p=)

at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:884

#12 0x009c3bf7 in lto_write_tree (ref_p=true, expr=0x7fffecc63dc0,

ob=0x1c73210)

at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:321

#13 lto_output_tree (ob=0x1c73210, expr=0x7fffecc63dc0, ref_p=true,

this_ref_p=) at

/home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:410

#14 0x00c26df8 in write_ts_exp_tree_pointers (ref_p=,

expr=, ob=)

at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:746

#15 streamer_write_tree_body (ob=0x1c73210, expr=0x7fffecc70078,

ref_p=)

at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:884

#16 0x009c3bf7 in lto_write_tree (ref_p=true, expr=0x7fffecc70078,

ob=0x1c73210)

at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:321

#17 lto_output_tree (ob=ob@entry=0x1c73210, expr=0x7fffecc70078,

ref_p=ref_p@entry=true,

this_ref_p=this_ref_p@entry=true)

at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:410

#18 0x00c2681d in write_ts_decl_common_tree_pointers (ref_p=true,

expr=0x7fffecc6d720, ob=0x1c73210)

at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:584

#19 streamer_write_tree_body (ob=0x1c73210, expr=0x7fffecc6d720,

ref_p=)

at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:857

#20 0x009c3bf7 in lto_write_tree (ref_p=true, expr=0x7fffecc6d720,

ob=0x1c73210)

at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:321

#21 lto_output_tree (ob=0x1c73210, expr=0x7fffecc6d720, ref_p=true,

this_ref_p=) at

/home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:410

#22 0x00ecd118 in output_gimple_stmt (stmt=0x7fffec6206c0,

ob=0x1c73210)

at /home/mjambor/gcc/trunk/src/gcc/gimple-streamer-out.c:143

#23 output_bb (ob=0x1c73210, bb=0x7fffed130f08, fn=0x7fffef8603f0)

at /home/mjambor/gcc/trunk/src/gcc/gimple-streamer-out.c:199

#24 0x009c4f26 in output_function (node=0x7fffef8614a0)

at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:823

#25 lto_output () at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:987

#26 0x009fa971 in ipa_write_summaries_2 (

pass=0x1618f00 , state=0x1ad8c00)

at /home/mjambor/gcc/trunk/src/gcc/passes.c:2408



The statement being written is:

(gdb) call debug_gimple_stmt ((gimple)0x7fffec6206c0)

# DEBUG v => 18444633011384221696



This happens for example during compilation of

js/src/ion/shared/CodeGenerator-shared.cpp

[Bug c++/56543] [4.7/4.8 Regression] ICE on valid code in copy_node_stat

[jakub at gcc dot gnu.org]

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



--- Comment #8 from Jakub Jelinek  2013-03-06 
15:19:17 UTC ---

Author: jakub

Date: Wed Mar  6 15:19:11 2013

New Revision: 196491



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

Log:

PR c++/56543

* tree.c (strip_typedefs): Don't copy args if they are NULL.



* g++.dg/template/typename20.C: New test.



Added:

trunk/gcc/testsuite/g++.dg/template/typename20.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/tree.c

trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/56551] New: A faster implementation of std::function

[marton78 at gmail dot com]

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



 Bug #: 56551

   Summary: A faster implementation of std::function

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: enhancement

  Priority: P3

 Component: libstdc++

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

ReportedBy: marto...@gmail.com





It would be great if the clever implementation of std::function presented on

the following page could find its way into libstdc++.



http://probablydance.com/2013/01/13/a-faster-implementation-of-stdfunction/



> The code is in the public domain (I want all library writers to start using 
> it)

> and here is a download link: http://dl.dropbox.com/u/27990997/function.h

[Bug c++/56543] [4.7/4.8 Regression] ICE on valid code in copy_node_stat

[jakub at gcc dot gnu.org]

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



--- Comment #9 from Jakub Jelinek  2013-03-06 
15:27:25 UTC ---

Author: jakub

Date: Wed Mar  6 15:27:13 2013

New Revision: 196492



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

Log:

PR c++/56543

* tree.c (strip_typedefs): Don't copy args if they are NULL.



* g++.dg/template/typename20.C: New test.



Added:

branches/gcc-4_7-branch/gcc/testsuite/g++.dg/template/typename20.C

Modified:

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

branches/gcc-4_7-branch/gcc/cp/tree.c

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

[Bug c++/56543] [4.7/4.8 Regression] ICE on valid code in copy_node_stat

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #10 from Jakub Jelinek  2013-03-06 
15:32:50 UTC ---

Fixed.

[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs

[jason at gcc dot gnu.org]

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



--- Comment #18 from Jason Merrill  2013-03-06 
15:34:19 UTC ---

Author: jason

Date: Wed Mar  6 15:34:11 2013

New Revision: 196493



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

Log:

PR debug/53363

* g++.dg/debug/dwarf2/thunk1.C: Skip on darwin.



Modified:

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C

[Bug tree-optimization/49234] [4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning

[aldyh at gcc dot gnu.org]

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



--- Comment #18 from Aldy Hernandez  2013-03-06 
16:11:22 UTC ---

Created attachment 29599

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

do not set overflow on [+-]INF



This is Richi's suggestion from comment 10.  The problem is that it obviously

causes the VRP strict overflow warnings to fail:



$ make check-gcc RUNTESTFLAGS=dg.exp=*strict*

FAIL: gcc.dg/Wstrict-overflow-12.c correct warning (test for warnings, line 13)

FAIL: gcc.dg/Wstrict-overflow-13.c correct warning (test for warnings, line 14)

FAIL: gcc.dg/Wstrict-overflow-14.c  (test for warnings, line 13)

FAIL: gcc.dg/Wstrict-overflow-15.c  (test for warnings, line 13)

FAIL: gcc.dg/Wstrict-overflow-21.c correct warning (test for warnings, line 8)

FAIL: gcc.dg/no-strict-overflow-6.c scan-tree-dump optimized "return bits"

FAIL: c-c++-common/restrict-1.c  -Wc++-compat  (test for excess errors)



If y'all are willing to work with this patch and XFAIL these tests, I'm more

than happy to test and commit this patch, otherwise I may have to drop this for

now, as I am not volunteering to fix VRP for SSA cycles as suggested.  I am

switching gears from 4.8 bugfixing into other duties shortly...



Let me know...

[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory

[jakub at gcc dot gnu.org]

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



--- Comment #35 from Jakub Jelinek  2013-03-06 
16:18:51 UTC ---

Author: jakub

Date: Wed Mar  6 16:18:40 2013

New Revision: 196497



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

Log:

PR middle-end/56461

* internal.h (struct cpp_buffer): Add to_free field.

(_cpp_pop_file_buffer): Add third argument.

* files.c (_cpp_stack_file): Set buffer->to_free.

(_cpp_pop_file_buffer): Add to_free argument.  Free to_free

if non-NULL, and if equal to file->buffer_start, also clear

file->buffer{,_start,_valid}.

* directives.c (_cpp_pop_buffer): Pass buffer->to_free

to _cpp_pop_file_buffer.



Modified:

trunk/libcpp/ChangeLog

trunk/libcpp/directives.c

trunk/libcpp/files.c

trunk/libcpp/internal.h

[Bug tree-optimization/49234] [4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning

[ian at airs dot com]

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



--- Comment #19 from Ian Lance Taylor  2013-03-06 16:18:50 
UTC ---

Those tests are more or less the whole point of the strict-overflow warning. 

-Wstrict-overflow exists to have an optional warning that tells you when you

may run into trouble.  For a warning of this type it's much better to have a

false positive than a false negative.  A false positive is just annoying.  A

false negative causes you to miss a potential bug in the program.



Sorry you've put so much time into this, but I don't see how it could be

acceptable to have a false negative on a case like Wstrict-overflow-12.c.

[Bug libstdc++/56551] A faster implementation of std::function

[redi at gcc dot gnu.org]

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



--- Comment #1 from Jonathan Wakely  2013-03-06 
16:24:20 UTC ---

I've only glanced at the code but it's good to see you support passing an

Allocator to the constructor (though it should use std::allocator_traits to

support C++11 allocators)



I was thinking of making some big changes to our std::function for GCC 4.9 in

order to support custom allocators.

[Bug tree-optimization/49234] [4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning

[aldyh at gcc dot gnu.org]

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



--- Comment #20 from Aldy Hernandez  2013-03-06 
16:28:12 UTC ---

Oh, no worries Ian.  I totally agree.  I just wanted to put all this out there,

since I'm unfortunately about to drop it.



We should probably close this as a WONTFIX, or perhaps just drop this in

priority.  A false positive is not the end of the world, so I don't see how

this merits a P2 for the release.



Thoughts?

[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2

[sergstesh at yahoo dot com]

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



--- Comment #23 from Sergei Steshenko  2013-03-06 
16:49:51 UTC ---

FYI, the original file ( http://gcc.gnu.org/bugzilla/attachment.cgi?id=17377 )

can be compiled with 'clang', albeit slowly:



"

sergei@amdam2:~/gcc_bug> time ~/AFSWD/install/LLVM-3.2/binsh/clang -v

gap_TlnLv4.c -O2 -c

clang version 3.2 (tags/RELEASE_32/final)

Target: i386-pc-linux-gnu

Thread model: posix

 "/mnt/sdb5/qemu/20121021/LLVM-3.2/bin/clang" -cc1 -triple i386-pc-linux-gnu

-emit-obj -disable-free -disable-llvm-verifier -main-file-name gap_TlnLv4.c

-mrelocation-model static -fmath-errno -masm-verbose -mconstructor-aliases

-target-cpu pentium4 -target-linker-version 2.22 -momit-leaf-frame-pointer -v

-coverage-file /home/sergei/gcc_bug/gap_TlnLv4.o -resource-dir

/mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2 -fmodule-cache-path

/tmp/clang-module-cache -internal-isystem /usr/local/include -internal-isystem

/mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2/include

-internal-externc-isystem /include -internal-externc-isystem /usr/include -O2

-fdebug-compilation-dir /home/sergei/gcc_bug -ferror-limit 19 -fmessage-length

182 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option

-fcolor-diagnostics -o gap_TlnLv4.o -x c gap_TlnLv4.c

clang -cc1 version 3.2 based upon LLVM 3.2svn default target i386-pc-linux-gnu

ignoring nonexistent directory "/include"

#include "..." search starts here:

#include <...> search starts here:

 /usr/local/include

 /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2/include

 /usr/include

End of search list.



real58m50.364s

user53m25.128s

sys 0m11.641s

sergei@amdam2:~/gcc_bug>

".



Memory consumption is about 186M.

[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[jakub at gcc dot gnu.org]

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



--- Comment #3 from Jakub Jelinek  2013-03-06 
17:18:53 UTC ---

Author: jakub

Date: Wed Mar  6 17:18:46 2013

New Revision: 196498



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

Log:

PR middle-end/56548

* expr.c (expand_cond_expr_using_cmove): When expanding cmove in

promoted mode, convert the result back to the original mode.



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



Added:

trunk/gcc/testsuite/gcc.dg/pr56548.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/expr.c

trunk/gcc/testsuite/ChangeLog

[Bug middle-end/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array

[ebotcazou at gcc dot gnu.org]

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



--- Comment #14 from Eric Botcazou  2013-03-06 
17:19:42 UTC ---

> Note the hacks all boil down to the fact that FEs use signed array

> domains but unsigned sizetype TYPE_DOMAIN.  The C and C++ FE were

> adjusted to use (unsigned) [1, 0] for zero-sized arrays - I believe

> the current hacks are all because of Ada (and yes, I invented them

> to not need to fiddle with the Ada FE when removing TYPE_IS_SIZETYPE).



Exactly, that's my point: all the hacks are there to cope with overflow issues

introduced by the removal of TYPE_IS_SIZETYPE.  Mine is another small one.



> There is still the Ada FE bug I opened that shows that arrays

> with [0, USIZETYPE_MAX] vs. [SSIZETYPE_MIN, SSIZETYPE_MAX] do not

> work.  Independent of any hacks to fix the current error to address

> that you need to work to fix the signedness issue (which may of

> course require middle-end adjustments).



Sure.



> If you don't want overflow you can as well re-set TREE_OVERFLOW

> on the result ... (just to give another option).



That's exactly what the hack at stor-layout.c 2234 does for C and C++!

[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #4 from Jakub Jelinek  2013-03-06 
17:22:48 UTC ---

Fixed.

[Bug middle-end/56524] [4.8 Regression] Compiler ICE when compiling with -mips16

[aldyh at gcc dot gnu.org]

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



--- Comment #3 from Aldy Hernandez  2013-03-06 
17:54:41 UTC ---

This is ICEing here:



  /* ?? If this fails, we should temporarily restore the default

 target first (set_cfun (NULL) ??), do the rest of this function,

 and then restore it.  */

  gcc_assert (this_target_optabs == &default_target_optabs);



In this case, this_target_optabs is being set in:



  mips_set_mips16_mode() ->

save_target_globals_default_opts() ->

  save_target_globals() ->

restore_target_globals() 

 ...

 this_target_optabs = g->optabs;



We can't do exactly as the comment above the ICE says, since cfun isn't even

set at this point (we are being called from the parser).

[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[sje at gcc dot gnu.org]

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



--- Comment #5 from Steve Ellcey  2013-03-06 18:04:30 
UTC ---

For the record, this does undo the performance regression fix on MIPS.  I will

submit a new bug for that issue.  The problem (on mips) is that we want to do a

conditional move of a short to a destination that already contains a short.

Since we don't have a short conditional move we use an int conditional move,

but we shouldn't need to 'reconvert' the moved integer back to a short by

masking off the upper bits.  They are already zero because the source and dest

of the conditional move were both shorts.

[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[sje at gcc dot gnu.org]

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



--- Comment #7 from Steve Ellcey  2013-03-06 18:22:44 
UTC ---

(In reply to comment #6)

> But you can't achieve that through generation of invalid RTL.



Agreed.



> Anyway, I wonder why nonzero_bits during combine doesn't figure out that the

> upper bits are already all zero and optimize away the masking.



That I don't know.  I have opened bug 56552 to track the issue.

[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[jakub at gcc dot gnu.org]

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



--- Comment #6 from Jakub Jelinek  2013-03-06 
18:18:52 UTC ---

But you can't achieve that through generation of invalid RTL.



Anyway, I wonder why nonzero_bits during combine doesn't figure out that the

upper bits are already all zero and optimize away the masking.

[Bug middle-end/56552] New: conditional move can generate unnecessary conversion code

[sje at gcc dot gnu.org]

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



 Bug #: 56552

   Summary: conditional move can generate unnecessary conversion

code

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

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

ReportedBy: s...@gcc.gnu.org

Target: mips*-*-*





With this test program:



unsigned short foo(unsigned short a1, unsigned short a2)

{

  unsigned short i, x;

  for (i = 0; i < 8; i++) {

x = (a1 & 1) ^ (a2 & 1);

a1 >>= 1;

if (x == 1) a2 ^= 0x2006;

a2 >>= 1;

if (x == 1) a2 |= 0x8800;

elsea2 &= 0x77ff;

  }

  return a2;

}



The GCC 4.8 MIPS compiler generates a 'andi r,r,0x' instruction after

a movz (conditional move) that was not present in GCC 4.7.  This instruction

is generated because MIPS does not implement a 'short' conditional move so

expand_cond_expr_using_cmove promotes the mode then it has to 'demote' it back

to short and that generates the andi instruction.  But if the source and

destination of the conditional move are both shorts to begin with this andi

instruction is not needed.



The problem was fixed with this patch:



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



However it caused bug PR56548 (ICE on x86) and the fix for that

bug causes the extra andi instruction to once again be generated.

[Bug lto/50293] -flto fails if GCC is installed in directory with space in path name

[gjl at gcc dot gnu.org]

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



Georg-Johann Lay  changed:



   What|Removed |Added



   Keywords||lto

 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-03-06

 Ever Confirmed|0   |1

  Known to fail||4.6.2, 4.7.2



--- Comment #4 from Georg-Johann Lay  2013-03-06 
19:29:47 UTC ---

Thanks for the patch.  I tested it together with a --target=avr

--host=i386-mingw32 --build=i686-linux-gnu canadian cross with spaces in the

install pass.



Will this be backported?

[Bug libstdc++/56492] std::packaged_task requires CopyConstructible stored task

[redi at gcc dot gnu.org]

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



--- Comment #2 from Jonathan Wakely  2013-03-06 
20:08:55 UTC ---

Created attachment 29600

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

Patch for after 4.9

[Bug libstdc++/56492] std::packaged_task requires CopyConstructible stored task

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Target Milestone|--- |4.9.0

[Bug middle-end/56524] [4.8 Regression] Compiler ICE when compiling with -mips16

[rsandifo at gcc dot gnu.org]

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



--- Comment #4 from rsandifo at gcc dot gnu.org  
2013-03-06 20:59:01 UTC ---

Created attachment 29601

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

Tentative patch



How about this patch?  Only lightly tested.  It fixes the testcase

and the pr43564.c failure that I'm seeing on MIPS16 runs.

[Bug tree-optimization/56539] [4.6/4.7/4.8 Regression] ICE: verify_ssa failed: caused by -foptimize-sibling-calls

[vchou79 at gmail dot com]

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



--- Comment #8 from Vincent  2013-03-06 21:20:29 UTC 
---

Jakub,

The patch also fixed this problem testcase on cross compiler

(x86_64-w64-mingw32).

[Bug lto/56495] ICE in lto_output_tree with -g -flto -O2

[spammeup2011 at googlemail dot com]

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



--- Comment #3 from Florian Meyer  
2013-03-06 21:34:11 UTC ---

Seems i can only reproduce it with the live package provided by Gentoo , even

though it does not apply any patches. If I configure and compile the current

GCC trunk by hand and with the same options the crash does not appear. I'm not

sure where the difference comes from but it seems to have been a false alarm.

Sorry for the waste of time. 



LC_ALL="C" gcc -v -s ppl.ii -O2 -flto -g

Using built-in specs.

COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre/gcc

COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0-pre/lto-wrapper

Target: x86_64-pc-linux-gnu

Configured with:

/mnt/portage/temp/portage/sys-devel/gcc-4.8.0_pre/work/gcc-4.8.0-/configure

--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre

--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include

--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre

--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/man

--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/info

--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include/g++-v4

--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec

--disable-fixed-point --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-pre/python

--enable-checking=release --disable-libgcj --enable-libstdcxx-time

--enable-languages=c,c++,fortran --enable-shared --enable-threads=posix

--enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all

--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.0_pre'

Thread model: posix

gcc version 4.8.0-pre 20130304 (experimental) commit

050bae72218bcca4e1feddf8bde385097df42f72 (Gentoo 4.8.0_pre) 

COLLECT_GCC_OPTIONS='-v' '-s' '-O2' '-flto' '-g' '-mtune=generic'

'-march=x86-64'

 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0-pre/cc1plus -fpreprocessed

ppl.ii -quiet -dumpbase ppl.ii -mtune=generic -march=x86-64 -auxbase ppl -g -O2

-version -flto -o /tmp/cc6I9l3w.s

GNU C++ (Gentoo 4.8.0_pre) version 4.8.0-pre 20130304 (experimental)

commit 050bae72218bcca4e1feddf8bde385097df42f72 (x86_64-pc-linux-gnu)

compiled by GNU C version 4.8.0-pre 20130304 (experimental) commit

050bae72218bcca4e1feddf8bde385097df42f72, GMP version 5.1.0, MPFR version

3.1.1-p2, MPC version 1.0.1

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

GNU C++ (Gentoo 4.8.0_pre) version 4.8.0-pre 20130304 (experimental)

commit 050bae72218bcca4e1feddf8bde385097df42f72 (x86_64-pc-linux-gnu)

compiled by GNU C version 4.8.0-pre 20130304 (experimental) commit

050bae72218bcca4e1feddf8bde385097df42f72, GMP version 5.1.0, MPFR version

3.1.1-p2, MPC version 1.0.1

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

Compiler executable checksum: 21b18ee7394db7ae76601a5df9e565da

ppl_c_Rational_Box.cc: In function

'Parma_Polyhedra_Library::operator>(Parma_Polyhedra_Library::Linear_Expression

const&, __gmp_expr<__mpz_struct [1], __mpz_struct [1]> const&)':

ppl_c_Rational_Box.cc:1781:8302: internal compiler error: Segmentation fault

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug libquadmath/55473] quadmath.h should have extern "C" for C++ users

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #2 from Tobias Burnus  2013-03-06 
21:43:15 UTC ---

Janne and Shakth: The proposal is fine with me. However, it would help if you

would simply submit a/the patch. For what it is worth, I think the patch is

fine together with a ChangeLog.

[Bug libquadmath/56379] libquadmath: Wrong result for strtoflt128.c if compiled with -O0

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #7 from Tobias Burnus  2013-03-06 
21:45:53 UTC ---

Let's close this bug as FIXED.



(As libquadmath is - by default - never compiled with -O0 and as it is not a

regression, I don't think that there is a need to backport a fix.)

[Bug target/56529] [SH] Calls to __sdivsi3_i4i and __udivsi3_i4i are generated on SH2

[olegendo at gcc dot gnu.org]

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



--- Comment #4 from Oleg Endo  2013-03-06 22:54:18 
UTC ---

Author: olegendo

Date: Wed Mar  6 22:54:11 2013

New Revision: 196510



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

Log:

Backport from mainline

2013-03-06  Oleg Endo  



PR target/56529

* config/sh/sh.c (sh_option_override): Check for TARGET_DYNSHIFT

instead of TARGET_SH2 for call-table case.  Do not set sh_div_strategy

to SH_DIV_CALL_TABLE for TARGET_SH2.

* config.gcc (sh_multilibs): Add m2 and m2a to sh*-*-linux* multilib

list.

* doc/invoke.texi (SH options): Use table for mdiv= option.  Document

mdiv= call-div1, call-fp, call-table options.





Backport from mainline.

2013-03-06  Oleg Endo  



PR target/56529

* config/sh/lib1funcs.S (udivsi3_i4i, sdivsi3_i4i): Add __SH2A__ to

inclusion list.





Modified:

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

branches/gcc-4_7-branch/gcc/config.gcc

branches/gcc-4_7-branch/gcc/config/sh/sh.c

branches/gcc-4_7-branch/gcc/doc/invoke.texi

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

branches/gcc-4_7-branch/libgcc/config/sh/lib1funcs.S

[Bug middle-end/56524] [4.8 Regression] Compiler ICE when compiling with -mips16

[aldyh at gcc dot gnu.org]

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



--- Comment #5 from Aldy Hernandez  2013-03-06 
23:01:26 UTC ---

(In reply to comment #4)

> Created attachment 29601 [details]

> Tentative patch

> 

> How about this patch?  Only lightly tested.  It fixes the testcase

> and the pr43564.c failure that I'm seeing on MIPS16 runs.



Boy, this is getting quite confusing.  Do you think perhaps we could document

the plethora of target optabs, fn_optabs, base_optabs, etc.



And BTW, thanks for the patch Richard.

[Bug bootstrap/56554] New: stage2 ./intl: error: C compiler cannot create executables

[dougmencken at gmail dot com]

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



 Bug #: 56554

   Summary: stage2 ./intl: error: C compiler cannot create

executables

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

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

ReportedBy: dougmenc...@gmail.com





I built standard C Library with TLS support, and now I cannot bootstrap GCC. On

stage2, I got (from ./intl/config.log):





configure:2978: checking for C compiler default output file name

configure:3000:  /root/build-farm/_gcc_bootstrap/./prev-gcc/xgcc

-B/root/build-farm/_gcc_bootstrap/./prev-gcc/

-B/usr/powerpc32-gnu-linux-uclibc/bin/ -B/usr/powerpc32-gnu-linux-uclibc/bin/

-B/usr/powerpc32-gnu-linux-uclibc/lib/ -isystem

/usr/powerpc32-gnu-linux-uclibc/include -isystem

/usr/powerpc32-gnu-linux-uclibc/sys-include-O3 -gtoggle  -static-libstdc++

-static-libgcc  conftest.c  >&5

/usr/powerpc32-gnu-linux-uclibc/bin/ld:

/root/build-farm/_gcc_bootstrap/./prev-gcc/crtbegin.o: undefined reference to

symbol '__deregister_frame_info@@GLIBC_2.0'

/usr/powerpc32-gnu-linux-uclibc/bin/ld: note:

'__deregister_frame_info@@GLIBC_2.0' is defined in DSO

/root/build-farm/_gcc_bootstrap/./prev-gcc/libgcc_s.so.1 so try adding it to

the linker command line





I did suspect my Std C Lib, but after I did successful build of everything but

GCC, I suspect it is really GCC's fault.



All I can add is that "stage0" libgcc_s.so has " 0x0001 (NEEDED) Shared

library: [ld-uClibc.so.0]" which is missed in stage1 libgcc_s.so. readelf

outputs are attached.

[Bug bootstrap/56554] stage2 ./intl: error: C compiler cannot create executables

[dougmencken at gmail dot com]

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



--- Comment #1 from Douglas Mencken  2013-03-06 
23:15:46 UTC ---

Created attachment 29602

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

readelf of /usr/lib/libgcc_s.so.0.1

[Bug bootstrap/56554] stage2 ./intl: error: C compiler cannot create executables

[dougmencken at gmail dot com]

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



--- Comment #2 from Douglas Mencken  2013-03-06 
23:16:36 UTC ---

Created attachment 29603

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

readelf of _gcc_bootstrap/./prev-gcc/libgcc_s.so.1

[Bug bootstrap/56554] stage2 ./intl: error: C compiler cannot create executables

[dougmencken at gmail dot com]

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



--- Comment #3 from Douglas Mencken  2013-03-06 
23:20:51 UTC ---

Created attachment 29604

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

Attaching intl/config.log

[Bug tree-optimization/56539] [4.6/4.7/4.8 Regression] ICE: verify_ssa failed: caused by -foptimize-sibling-calls

[jakub at gcc dot gnu.org]

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



--- Comment #9 from Jakub Jelinek  2013-03-06 
23:26:48 UTC ---

Author: jakub

Date: Wed Mar  6 23:26:42 2013

New Revision: 196511



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

Log:

PR tree-optimization/56539

* tree-tailcall.c (adjust_return_value_with_ops): Use GSI_SAME_STMT

instead of GSI_CONTINUE_LINKING as last argument to

force_gimple_operand_gsi.



* gcc.c-torture/compile/pr56539.c: New test.



Added:

trunk/gcc/testsuite/gcc.c-torture/compile/pr56539.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-tailcall.c

[Bug bootstrap/56554] stage2 ./intl: error: C compiler cannot create executables

[pinskia at gcc dot gnu.org]

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



--- Comment #4 from Andrew Pinski  2013-03-06 
23:26:58 UTC ---

What binutils version are you using?

[Bug bootstrap/56554] stage2 ./intl: error: C compiler cannot create executables

[pinskia at gcc dot gnu.org]

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



--- Comment #5 from Andrew Pinski  2013-03-06 
23:28:19 UTC ---

Did you rebuild a candian cross to the target first before updating your libc? 

I think you broke your system by changing your libc without first building a

full cross build to the new target first.

[Bug tree-optimization/56539] [4.6/4.7 Regression] ICE: verify_ssa failed: caused by -foptimize-sibling-calls

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



  Known to work||4.8.0

   Target Milestone|4.8.0   |4.6.4

Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] ICE:

   |ICE: verify_ssa failed: |verify_ssa failed: caused

   |caused by   |by -foptimize-sibling-calls

   |-foptimize-sibling-calls|

  Known to fail|4.7.3, 4.8.0|4.7.2



--- Comment #10 from Jakub Jelinek  2013-03-06 
23:33:03 UTC ---

Fixed on the trunk so far.

[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 CC||steven at gcc dot gnu.org



--- Comment #24 from Steven Bosscher  2013-03-06 
23:39:27 UTC ---

(In reply to comment #22)

> 4.8.0  -O2  (terminated after 9 minutes waiting, LIM being the offender, I

> suspect domwalk ...)  >2.5GB

> 

> applying domwalk fix ...



It is LIM, for sure. I've been watching in GDB for a while at some

back traces, and it's spent minutes already in this DOM walk:



#5  0x00b841e1 in walk_dominator_tree (walk_data=0x7fffdd60,

bb=0x7fffef033958) at ../../trunk/gcc/domwalk.c:187

#6  0x00c02d73 in determine_invariantness () at

../../trunk/gcc/tree-ssa-loop-im.c:1189

#7  tree_ssa_lim () at ../../trunk/gcc/tree-ssa-loop-im.c:2632

#8  0x0075bcd7 in execute_one_pass (pass=0x12323e0 ) at

../../trunk/gcc/passes.c:2330

#9  0x0075c0f5 in execute_pass_list (pass=0x12323e0 ) at

../../trunk/gcc/passes.c:2378



This is supposed to be cheap. Is this a known bottle-neck?



Pathetic...

[Bug c++/56534] [4.7/4.8 Regression] ICE Segfault on invalid code in check_elaborated_type_specifier

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||hpsMouse at gmail dot com



--- Comment #5 from Paolo Carlini  2013-03-06 
23:41:25 UTC ---

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

[Bug c++/55786] g++ segmentation fault

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||DUPLICATE



--- Comment #2 from Paolo Carlini  2013-03-06 
23:41:25 UTC ---

PR56534 has a more compact testcase.



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

[Bug c++/56534] [4.7/4.8 Regression] ICE Segfault on invalid code in check_elaborated_type_specifier

[paolo at gcc dot gnu.org]

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



--- Comment #6 from paolo at gcc dot gnu.org  
2013-03-06 23:47:30 UTC ---

Author: paolo

Date: Wed Mar  6 23:47:20 2013

New Revision: 196513



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

Log:

/cp

2013-03-06  Paolo Carlini  



PR c++/56534

* parser.c (cp_parser_elaborated_type_specifier): Don't call

check_elaborated_type_specifier when TREE_CODE (decl) != TYPE_DECL.

* decl.c (check_elaborated_type_specifier): Tidy.



/testsuite

2013-03-06  Paolo Carlini  



PR c++/56534

* g++.dg/template/crash115.C: New.



Added:

trunk/gcc/testsuite/g++.dg/template/crash115.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/decl.c

trunk/gcc/cp/parser.c

trunk/gcc/testsuite/ChangeLog

[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2

[steven at gcc dot gnu.org]

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



--- Comment #25 from Steven Bosscher  2013-03-07 
00:08:26 UTC ---

(In reply to comment #24)

> (In reply to comment #22)

> > 4.8.0  -O2  (terminated after 9 minutes waiting, LIM being the offender, I

> > suspect domwalk ...)  >2.5GB

> > 

> > applying domwalk fix ...

> 

> It is LIM, for sure. I've been watching in GDB for a while at some

> back traces, and it's spent minutes already in this DOM walk:



After this, it's spending even more time in refs_independent_p, doing

bitmap tests (ah! a test case for my splay tree bitmaps!).



Is the refs_independent_p relation symmetric? It certainly looks that

way.  If so, one way to halve the work done here is to build only half

the "independence" graph.  Currently it builds a full square:



  if (mem_refs_may_alias_p (ref1->mem, ref2->mem,

&memory_accesses.ttae_cache))

{ 

  bitmap_set_bit (ref1->dep_ref, ref2->id);

  bitmap_set_bit (ref2->dep_ref, ref1->id);

  if (dump_file && (dump_flags & TDF_DETAILS))

fprintf (dump_file, "dependent.\n");

  return false;

}

  else

{

  bitmap_set_bit (ref1->indep_ref, ref2->id);

  bitmap_set_bit (ref2->indep_ref, ref1->id);

  if (dump_file && (dump_flags & TDF_DETAILS))

fprintf (dump_file, "independent.\n");

  return true;

}



It's hard to say how much memory is wasted here (obstack_memory_used

is still broken and overflows), but it's probably x*100MB if not more.

[Bug fortran/56555] New: read from pipe

[furue at hawaii dot edu]

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



 Bug #: 56555

   Summary: read from pipe

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

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

ReportedBy: fu...@hawaii.edu





When reading from stdin in a simple pipe, the Fortran runtime reports an "End

of file" error.  See the self contained example below.  It was done on a

Debian-testing system.  The shell is a symlink to /bin/dash .



Regards,

Ryo

---

$ cat try.f90

program try

  real(4):: r

  integer:: i

  do !! infinite loop

read(*,*) r

write(*,*) r

  end do

end program try

$ gfortran -o try try.f90

$ cat try.sh 

#!/bin/sh



for n in `seq 1 10`; do

echo $n | ./try

done

$ sh try.sh

   1.

At line 5 of file try.f90 (unit = 5, file = 'stdin')

Fortran runtime error: End of file

   2.

At line 5 of file try.f90 (unit = 5, file = 'stdin')

Fortran runtime error: End of file

   3.

At line 5 of file try.f90 (unit = 5, file = 'stdin')

Fortran runtime error: End of file

   4.

At line 5 of file try.f90 (unit = 5, file = 'stdin')

Fortran runtime error: End of file

   5.

At line 5 of file try.f90 (unit = 5, file = 'stdin')

Fortran runtime error: End of file

   6.

At line 5 of file try.f90 (unit = 5, file = 'stdin')

Fortran runtime error: End of file

   7.

At line 5 of file try.f90 (unit = 5, file = 'stdin')

Fortran runtime error: End of file

   8.

At line 5 of file try.f90 (unit = 5, file = 'stdin')

Fortran runtime error: End of file

   9.

At line 5 of file try.f90 (unit = 5, file = 'stdin')

Fortran runtime error: End of file

   10.000

At line 5 of file try.f90 (unit = 5, file = 'stdin')

Fortran runtime error: End of file

$

[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2

[steven at gcc dot gnu.org]

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



--- Comment #26 from Steven Bosscher  2013-03-07 
00:26:56 UTC ---

(In reply to comment #23)

> FYI, the original file ( http://gcc.gnu.org/bugzilla/attachment.cgi?id=17377 )

> can be compiled with 'clang', albeit slowly:

...

> Memory consumption is about 186M.



How have you measured this?

[Bug fortran/56555] read from pipe

[furue at hawaii dot edu]

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



--- Comment #1 from Ryo Furue  2013-03-07 00:33:40 UTC 
---

I'm sorry  That was a mistake!  I want to withdraw it but don't know how. 

I'm very sorry for posting a total nonsense!



Ryo

[Bug fortran/56555] read from pipe

[furue at hawaii dot edu]

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



Ryo Furue  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #2 from Ryo Furue  2013-03-07 00:36:11 UTC 
---

I'm not sure this is the right thing to do, but I'll try to close this bogus

report by labeling it as "invalid".  Hope it works.  Sorry again.

[Bug c++/56534] [4.7 Regression] ICE Segfault on invalid code in check_elaborated_type_specifier

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



Summary|[4.7/4.8 Regression] ICE|[4.7 Regression] ICE

   |Segfault on invalid code in |Segfault on invalid code in

   |check_elaborated_type_speci |check_elaborated_type_speci

   |fier|fier



--- Comment #7 from Paolo Carlini  2013-03-07 
00:37:52 UTC ---

Fixed in mainline so far.