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

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Target|sh*-*-* arm*|sh*-*-* arm*-*-* sparc*-*-*

 CC||ebotcazou at gcc dot

   ||gnu.org

   Target Milestone|--- |4.8.0

   Severity|normal  |major



--- Comment #8 from Eric Botcazou  2012-10-31 
08:24:00 UTC ---

Ugh.  ARM and SPARC are primary targets, so this is a major regression.

[Bug target/55146] New: jumptables with byte entries produce wrong code with -Os/-O2 for SH-1

[marcin.bukat at gmail dot com]

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



 Bug #: 55146

   Summary: jumptables with byte entries produce wrong code with

-Os/-O2 for SH-1

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: critical

  Priority: P3

 Component: target

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

ReportedBy: marcin.bu...@gmail.com





Created attachment 28580

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

testcase C file



Switch statement with enough cases inside is translated to jumptable. If the

offsets are small enough, byte entries are used. If there is odd number of

cases this implies padding byte (since all SH instructions are 2 byte wide). In

the corner case this padding byte can cause the offset to switch from positive

to negative since move.b instruction used to fetch jumptable entry sign extends

the byte. This bug is very old and dates back at least to 4.0.3 days. See

attachment.

When compiled with sh-elf-gcc -Os -c test-jens.c -o sh-test.o it produces wrong

jumping code. http://pastebin.com/ZgJK3bgS has slightly commented disassembly

to point out what I mean.



The workaround is to decrease MIN_OFFSET by one for byte case in

gcc/config/sh/sh.h . This is not a proper fix though.

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

[hjl.tools at gmail dot com]

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



--- Comment #2 from H.J. Lu  2012-10-31 08:26:10 
UTC ---

Patch doesn't work and elf_get_dynamic_info is miscompiled:



   0xf7dddc88 <+5224>:neg%eax

   0xf7dddc8a <+5226>:lea(%rcx,%rax,4),%eax

---Type  to continue, or q  to quit---

=> 0xf7dddc8d <+5229>:mov%edx,-0x4300(%rax)



(gdb) p *(int *) $rax

Cannot access memory at address 0x37ffe064

(gdb) bt

#0  0xf7dddc8d in elf_get_dynamic_info (temp=0x0, l=0xf7ffdc18)

at get-dynamic-info.h:61

#1  dl_main (phdr=, phnum=9, user_entry=, 

auxv=) at rtld.c:1311

#2  0xf7df12a0 in _dl_sysdep_start (

start_argptr=start_argptr@entry=0xd0c0, dl_main=)

at ../elf/dl-sysdep.c:241

#3  0xf7ddfaa8 in _dl_start_final (arg=0xd0c0) at rtld.c:331

#4  _dl_start (arg=) at rtld.c:557

#5  0xf7ddc057 in _start ()

   from /export/build/gnu/glibc-x32-long/build-x86_64-linux/elf/ld.so

[Bug middle-end/55132] [4.8 Regression] FAIL: g++.dg/tree-ssa/pr45453.C

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-31

 CC||ebotcazou at gcc dot

   ||gnu.org

 Ever Confirmed|0   |1



--- Comment #4 from Eric Botcazou  2012-10-31 
08:43:36 UTC ---

Everywhere apparently.

[Bug tree-optimization/21643] GCC fails to merge ranges in comparison.

[jakub at gcc dot gnu.org]

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



--- Comment #6 from Jakub Jelinek  2012-10-31 
08:45:35 UTC ---

Author: jakub

Date: Wed Oct 31 08:45:27 2012

New Revision: 193028



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

Log:

PR tree-optimization/19105

PR tree-optimization/21643

PR tree-optimization/46309

* tree-ssa-reassoc.c (init_range_entry): Add STMT argument

and use it if EXP is NULL.

(update_range_test): Handle OPCODE equal to ERROR_MARK

and oe->op NULL.

(optimize_range_tests): Likewise.

(final_range_test_p, suitable_cond_bb, no_side_effect_bb, get_ops,

maybe_optimize_range_tests): New functions.

(reassociate_bb): Call maybe_optimize_range_tests if last

stmt of bb is GIMPLE_COND that hasn't been visited yet.



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

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

* gcc.dg/pr46309-2.c: New test.

* gcc.c-torture/execute/pr46309.c: New test.



Added:

trunk/gcc/testsuite/gcc.c-torture/execute/pr46309.c

trunk/gcc/testsuite/gcc.dg/pr19105.c

trunk/gcc/testsuite/gcc.dg/pr21643.c

trunk/gcc/testsuite/gcc.dg/pr46309-2.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-ssa-reassoc.c

[Bug tree-optimization/19105] fold does not spot anti-range test

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2012-10-31 
08:45:38 UTC ---

Author: jakub

Date: Wed Oct 31 08:45:27 2012

New Revision: 193028



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

Log:

PR tree-optimization/19105

PR tree-optimization/21643

PR tree-optimization/46309

* tree-ssa-reassoc.c (init_range_entry): Add STMT argument

and use it if EXP is NULL.

(update_range_test): Handle OPCODE equal to ERROR_MARK

and oe->op NULL.

(optimize_range_tests): Likewise.

(final_range_test_p, suitable_cond_bb, no_side_effect_bb, get_ops,

maybe_optimize_range_tests): New functions.

(reassociate_bb): Call maybe_optimize_range_tests if last

stmt of bb is GIMPLE_COND that hasn't been visited yet.



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

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

* gcc.dg/pr46309-2.c: New test.

* gcc.c-torture/execute/pr46309.c: New test.



Added:

trunk/gcc/testsuite/gcc.c-torture/execute/pr46309.c

trunk/gcc/testsuite/gcc.dg/pr19105.c

trunk/gcc/testsuite/gcc.dg/pr21643.c

trunk/gcc/testsuite/gcc.dg/pr46309-2.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-ssa-reassoc.c

[Bug tree-optimization/46309] optimization a==3||a==1

[jakub at gcc dot gnu.org]

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



--- Comment #10 from Jakub Jelinek  2012-10-31 
08:45:36 UTC ---

Author: jakub

Date: Wed Oct 31 08:45:27 2012

New Revision: 193028



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

Log:

PR tree-optimization/19105

PR tree-optimization/21643

PR tree-optimization/46309

* tree-ssa-reassoc.c (init_range_entry): Add STMT argument

and use it if EXP is NULL.

(update_range_test): Handle OPCODE equal to ERROR_MARK

and oe->op NULL.

(optimize_range_tests): Likewise.

(final_range_test_p, suitable_cond_bb, no_side_effect_bb, get_ops,

maybe_optimize_range_tests): New functions.

(reassociate_bb): Call maybe_optimize_range_tests if last

stmt of bb is GIMPLE_COND that hasn't been visited yet.



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

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

* gcc.dg/pr46309-2.c: New test.

* gcc.c-torture/execute/pr46309.c: New test.



Added:

trunk/gcc/testsuite/gcc.c-torture/execute/pr46309.c

trunk/gcc/testsuite/gcc.dg/pr19105.c

trunk/gcc/testsuite/gcc.dg/pr21643.c

trunk/gcc/testsuite/gcc.dg/pr46309-2.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-ssa-reassoc.c

[Bug target/54989] FAIL: gcc.dg/hoist-register-pressure.c scan-rtl-dump hoist "PRE/HOIST: end of bb .* copying expression" on darwin

[amker.cheng at gmail dot com]

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



--- Comment #7 from bin.cheng  2012-10-31 
08:45:37 UTC ---

I think this is fixed and it's a bug in 4.8.0.

Hi Jack, could you verify that it is fixed? Thanks very much.

[Bug tree-optimization/21643] GCC fails to merge ranges in comparison.

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC||jakub at gcc dot gnu.org

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #7 from Jakub Jelinek  2012-10-31 
08:51:45 UTC ---

Fixed for 4.8+.

[Bug tree-optimization/19105] fold does not spot anti-range test

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC||jakub at gcc dot gnu.org

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #6 from Jakub Jelinek  2012-10-31 
08:52:45 UTC ---

Fixed.

[Bug tree-optimization/46309] optimization a==3||a==1

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #11 from Jakub Jelinek  2012-10-31 
08:54:40 UTC ---

Fixed.

[Bug c++/54955] alignas example in gcc 4.8 changes.html won't compile

[dodji at gcc dot gnu.org]

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



--- Comment #6 from Dodji Seketeli  2012-10-31 
08:55:51 UTC ---

Author: dodji

Date: Wed Oct 31 08:55:43 2012

New Revision: 193029



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

Log:

PR c++/54955 - Fail to parse alignas expr at the beginning of a declaration



In this PR, g++ embarrassingly fails to parse the simple alignas

expression below:



alignas(double) int f;



even though the simple-declaration production in Clause 7 suggests

otherwise.



Fixed thus and tested on x86_64-unknown-linux-gnu against trunk.



gcc/cp



PR c++/54955

* parser.c (cp_nth_tokens_can_be_std_attribute_p): Recognize the

'Alignas' keyword as the beginning of a c++11 attribute specifier.

Update the comment of the function.

(cp_next_tokens_can_be_gnu_attribute_p): Update the comment of the

function.



gcc/testsuite/



PR c++/54955

* g++.dg/cpp0x/gen-attrs-48-2.C: New test.



Added:

trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-48-2.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/parser.c

trunk/gcc/testsuite/ChangeLog

[Bug c++/54955] alignas example in gcc 4.8 changes.html won't compile

[dodji at gcc dot gnu.org]

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



Dodji Seketeli  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #7 from Dodji Seketeli  2012-10-31 
09:01:49 UTC ---

This should be fixed in trunk (4.8)

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

[hjl.tools at gmail dot com]

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



--- Comment #3 from H.J. Lu  2012-10-31 09:13:46 
UTC ---

The code looks like:



  while (dyn->d_tag != 0) 

{

  if ((d_tag_utype) dyn->d_tag < 34) 

 info[dyn->d_tag] = dyn;

  else if (dyn->d_tag >= 0x7000 &&

dyn->d_tag < 0x7000 + 0)

 info[dyn->d_tag - 0x7000 + 34] = dyn;

  else if ((d_tag_utype) (0x6fff - (dyn->d_tag)) < 16) 

 info[(34 + 0 + (0x6fff - (dyn->d_tag)))] = dyn;

  else if ((d_tag_utype) ((Elf32_Word)-((Elf32_Sword) (dyn->d_tag)

<<1>>1)-1) < 3)

 info[((Elf32_Word)-((Elf32_Sword) (dyn->d_tag) <<1>>1)-1) + 34 + 0

  + 16] = dyn;

  else if ((d_tag_utype) (0x6dff - (dyn->d_tag)) < 12)

 info[(0x6dff - (dyn->d_tag)) + 34 + 0

  + 16 + 3] = dyn;

  else if ((d_tag_utype) (0x6eff - (dyn->d_tag)) < 11)

 info[(0x6eff - (dyn->d_tag)) + 34 + 0

  + 16 + 3 + 12] = dyn;

  ++dyn;

}

[Bug target/54707] picochip.c:332:985: error: ‘default_stabs_asm_out_constructor’ was not declared in this scope

[dant at picochip dot com]

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



--- Comment #1 from Daniel Towner  2012-10-31 
09:22:02 UTC ---

The picochip port was marked as obsolete in 4.7.

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

[hjl.tools at gmail dot com]

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



H.J. Lu  changed:



   What|Removed |Added



 CC||ebotcazou at gcc dot

   ||gnu.org



--- Comment #4 from H.J. Lu  2012-10-31 10:18:59 
UTC ---

It is caused by revision 188118:



http://gcc.gnu.org/ml/gcc-cvs/2012-06/msg00028.html

[Bug target/55145] [4.8 Regression] [x32] -maddress-mode=long miscompiles glibc

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0

[Bug rtl-optimization/55141] [4.8 Regression] wrong code with -fno-split-wide-types

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0

[Bug rtl-optimization/55141] [4.8 Regression] wrong code with -fno-split-wide-types

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-31

 CC||mpolacek at gcc dot

   ||gnu.org, vmakarov at gcc

   ||dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Marek Polacek  2012-10-31 
10:31:53 UTC ---

Started with http://gcc.gnu.org/viewcvs?view=revision&revision=192719

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

[ebotcazou at gcc dot gnu.org]

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



--- Comment #5 from Eric Botcazou  2012-10-31 
10:59:15 UTC ---

> It is caused by revision 188118:

> 

> http://gcc.gnu.org/ml/gcc-cvs/2012-06/msg00028.html



Are you really sure?  This change is only a refinement of another one.  You're

saying it's a regression, but the known-to-work field is empty.

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

[hjl.tools at gmail dot com]

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



H.J. Lu  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-31

  Known to work||4.7.2

 Ever Confirmed|0   |1

  Known to fail||4.8.0



--- Comment #6 from H.J. Lu  2012-10-31 11:09:29 
UTC ---

(In reply to comment #5)

> > It is caused by revision 188118:

> > 

> > http://gcc.gnu.org/ml/gcc-cvs/2012-06/msg00028.html

> 

> Are you really sure?  This change is only a refinement of another one.  You're

> saying it's a regression, but the known-to-work field is empty.



I am 100% sure that it is a 4.8 regression.  You can verify

it yourself.

[Bug libstdc++/50160] vector comparison very slow (no overload)

[muhammadali.ca4 at gmail dot com]

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



albcl111  changed:



   What|Removed |Added



 CC||muhammadali.ca4 at gmail

   ||dot com



--- Comment #33 from albcl111  2012-10-31 
11:09:32 UTC ---

This is such a great resource that you are providing and you give it away for

free. I love seeing websites that understand the value of providing a quality

resource for free. It is the old what goes around comes around routine.

http://www.genesishealthinstitute.com/testosterone.php";>http://www.genesishealthinstitute.com/testosterone.php

[Bug libstdc++/52015] std::to_string does not work under MinGW

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Target||*-*-mingw32

   Target Milestone|--- |4.8.0



--- Comment #14 from Jonathan Wakely  2012-10-31 
11:20:08 UTC ---

patch posted to http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02544.html



stay tuned

[Bug target/55147] New: x86: wrong code for 64-bit load

[mans at mansr dot com]

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



 Bug #: 55147

   Summary: x86: wrong code for 64-bit load

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

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

ReportedBy: m...@mansr.com





> cat foo.c

unsigned foo(unsigned long long *p, int i)

{

return __builtin_bswap64(p[i]);

}



> gcc-4.8.0 -m32 -O1 -S foo.c

foo:

movl8(%esp), %edx

movl4(%esp), %eax

movl(%eax,%edx,8), %edx

movl4(%eax,%edx,8), %eax

bswap   %eax

ret



Note the first movl overwriting the index register %edx.

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

[hjl.tools at gmail dot com]

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



--- Comment #7 from H.J. Lu  2012-10-31 11:25:48 
UTC ---

Breakpoint 7, fold_binary_loc (loc=2696, code=PLUS_EXPR, type=0x7199e000, 

op0=0x71ab8398, op1=0x71aa6660)

at /export/gnu/import/git/gcc/gcc/fold-const.c:10058

10058return tem;

(gdb) call debug_tree (arg0)

 

unit size 

align 32 symtab 0 alias set -1 canonical type 0x7199e690 precision

32 min  max 

pointer_to_this >



arg 0 



arg 0 



arg 0 

arg 1 



arg 0 

arg 0 

x.i:22:23> arg 1 

x.i:22:23>

x.i:22:18>>

arg 1  constant 4>

x.i:22:6>

(gdb) call debug_tree (arg1)

 

constant 48>

(gdb) call debug_tree (tem)

 

unit size 

align 32 symtab 0 alias set -1 canonical type 0x7199e000 precision

32 min  max >



arg 0 



arg 0 



arg 0 



arg 0 

arg 0 

x.i:22:23> arg 1 

x.i:22:23>

x.i:22:6>

arg 1 >

arg 1  constant 3221224492>>

(gdb) 



Integer constant multiply operand is signed.

[Bug c++/55148] New: wrong compilation of chars: overlapped memory areas

[icegood1980 at gmail dot com]

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



 Bug #: 55148

   Summary: wrong compilation of chars: overlapped memory areas

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: c++

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

ReportedBy: icegood1...@gmail.com





if one uses a stringification operation then problems could be obtained on

stack:



brackets.cpp : 



#include 

#include 

#define GLOBAL_str_intermediate(s)\

({\

  char GLOBAL_str_intermediate_buf[1024]; \

  strcpy(GLOBAL_str_intermediate_buf, #s);\

  GLOBAL_str_intermediate_buf[strlen(GLOBAL_str_intermediate_buf)-1]='\0';\

  GLOBAL_str_intermediate_buf+1;  \

})



#define GLOBAL_str(s) GLOBAL_str_intermediate((s))

#define s_one_arg a,b,c



int main(int argc, const char **argv)

{

  char PairPotentialName[70], *p=GLOBAL_str(s_one_arg);

  //

  std::cerr<

[Bug c++/55148] wrong compilation of chars: overlapped memory areas

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



   Severity|major   |normal



--- Comment #1 from Jonathan Wakely  2012-10-31 
12:16:51 UTC ---

As the docs for the Statement Expressions extension

(http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html) say:



"Any temporaries created within a statement within a statement expression will

be destroyed at the statement's end."



so GLOBAL_str_intermediate_buf[] is no longer valid after p is initialized and

the memory can be reused.

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

[hjl.tools at gmail dot com]

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



--- Comment #8 from H.J. Lu  2012-10-31 12:19:56 
UTC ---

Does this make any senses?



diff --git a/gcc/fold-const.c b/gcc/fold-const.c

index 5ea5110..50879d6 100644

--- a/gcc/fold-const.c

+++ b/gcc/fold-const.c

@@ -7038,6 +7038,24 @@ fold_to_nonsharp_ineq_using_bound (location_t loc, tree

ineq, tree bound)

   return fold_build2_loc (loc, GE_EXPR, type, a, y);

 }



+static unsigned int

+unsigned_expr_operands (tree op)

+{

+  switch (TREE_CODE (op))

+{

+case MULT_EXPR:

+  if (!unsigned_expr_operands (TREE_OPERAND (op, 0)))

+return 0;

+  return unsigned_expr_operands (TREE_OPERAND (op, 1));

+

+case NOP_EXPR:

+  return unsigned_expr_operands (TREE_OPERAND (op, 0));

+

+default:

+  return TYPE_UNSIGNED (TREE_TYPE (op));

+}

+}

+

 /* Fold a sum or difference of at least one multiplication.

Returns the folded tree or NULL if no simplification could be made.  */



@@ -7048,6 +7066,17 @@ fold_plusminus_mult_expr (location_t loc, enum tree_code

code, tree type,

   tree arg00, arg01, arg10, arg11;

   tree alt0 = NULL_TREE, alt1 = NULL_TREE, same;



+  /* Make sure the type is not saturating and has the signedness of

+ the stripped operands, as fold_plusminus_mult_expr will re-associate.

+ ??? The latter condition should use TYPE_OVERFLOW_* flags instead.  */

+  if (!((TREE_CODE (arg0) == MULT_EXPR

+   || TREE_CODE (arg1) == MULT_EXPR)

+  && !TYPE_SATURATING (type)

+  && TYPE_UNSIGNED (type) == unsigned_expr_operands (arg0)

+  && TYPE_UNSIGNED (type) == unsigned_expr_operands (arg1)

+  && (!FLOAT_TYPE_P (type) || flag_associative_math)))

+return NULL_TREE;

+

   /* (A * C) +- (B * C) -> (A+-B) * C.

  (A * C) +- A -> A * (C+-1).

  We are most concerned about the case where C is a constant,

@@ -10042,17 +10071,7 @@ fold_binary_loc (location_t loc,

 }

 }



-  /* Handle (A1 * C1) + (A2 * C2) with A1, A2 or C1, C2 being the same or

- one.  Make sure the type is not saturating and has the signedness of

- the stripped operands, as fold_plusminus_mult_expr will re-associate.

- ??? The latter condition should use TYPE_OVERFLOW_* flags instead.  */

-  if ((TREE_CODE (arg0) == MULT_EXPR

-   || TREE_CODE (arg1) == MULT_EXPR)

-  && !TYPE_SATURATING (type)

-  && TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg0))

-  && TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg1))

-  && (!FLOAT_TYPE_P (type) || flag_associative_math))

-{

+{

   tree tem = fold_plusminus_mult_expr (loc, code, type, arg0, arg1);

   if (tem)

 return tem;

@@ -10668,17 +10687,7 @@ fold_binary_loc (location_t loc,

   && (tem = distribute_real_division (loc, code, type, arg0, arg1)))

 return tem;



-  /* Handle (A1 * C1) - (A2 * C2) with A1, A2 or C1, C2 being the same or

- one.  Make sure the type is not saturating and has the signedness of

- the stripped operands, as fold_plusminus_mult_expr will re-associate.

- ??? The latter condition should use TYPE_OVERFLOW_* flags instead.  */

-  if ((TREE_CODE (arg0) == MULT_EXPR

-   || TREE_CODE (arg1) == MULT_EXPR)

-  && !TYPE_SATURATING (type)

-  && TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg0))

-  && TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg1))

-  && (!FLOAT_TYPE_P (type) || flag_associative_math))

-{

+{

   tree tem = fold_plusminus_mult_expr (loc, code, type, arg0, arg1);

   if (tem)

 return tem;

[Bug c++/55148] wrong compilation of chars: overlapped memory areas

[redi at gcc dot gnu.org]

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



--- Comment #2 from Jonathan Wakely  2012-10-31 
12:22:54 UTC ---

http://gcc.gnu.org/gcc-4.7/changes.html#cxx notes "G++ now properly re-uses

stack space allocated for temporary objects when their lifetime ends, which can

significantly lower stack consumption for some C++ functions. As a result of

this, some code with undefined behavior will now break"

[Bug c++/55148] wrong compilation of chars: overlapped memory areas

[icegood1980 at gmail dot com]

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



icegood1...@gmail.com  changed:



   What|Removed |Added



   Severity|normal  |major



--- Comment #3 from icegood1980 at gmail dot com  
2012-10-31 12:40:16 UTC ---

Clear! it's my fault.

[Bug c++/55148] wrong compilation of chars: overlapped memory areas

[icegood1980 at gmail dot com]

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



icegood1...@gmail.com  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #4 from icegood1980 at gmail dot com  
2012-10-31 12:43:32 UTC ---

my fault

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

[ebotcazou at gcc dot gnu.org]

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



--- Comment #9 from Eric Botcazou  2012-10-31 
12:49:45 UTC ---

> I am 100% sure that it is a 4.8 regression.  You can verify it yourself.



Precisely I cannot, that's why I'm asking:



eric@polaris:~/build/gcc-4_7-branch/native> gcc/xgcc -Bgcc -S -mx32

-mtune=generic -march=x86-64 pr55142.c  -S -O2  -fPIC -maddress-mode=long

xgcc: error: unrecognized command line option '-maddress-mode=long'



eric@polaris:~/build/gcc-4_7-branch/native> gcc/xgcc -v

Using built-in specs.

COLLECT_GCC=gcc/xgcc

Target: x86_64-suse-linux

Configured with: /home/eric/svn/gcc-4_7-branch/configure

--build=x86_64-suse-linux --prefix=/home/eric/install/gcc-4_7-branch

--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-__cxa_atexit

--disable-nls --disable-libmudflap

Thread model: posix

gcc version 4.7.3 20121021 (prerelease) [gcc-4_7-branch revision 192648] (GCC)

[Bug c++/55149] New: capturing VLA in lambda (error in 4.7.2 ICE in 4.8

[vincenzo.innocente at cern dot ch]

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

 Bug #: 55149
   Summary: capturing VLA in lambda (error in 4.7.2 ICE in 4.8
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


given that assigning a VLA to a pointer seems to be legal, I was expecting to
be able to capture a VLA in a lambda

in this code
cat pointerVLA.cc 
#include
 float c(int j,int k);
 void bar(int * index, int * ref, int N, int CN ) {
  float  r[N*CN];
  decltype(N) ii=0;
  for (decltype(N) ir=0; ir!=N; ++ir)
for(decltype(N) cl=0;cl!=CN;++cl)
  r[ii++]=c(cl,ref[ir]);
#ifdef VLA
 std::sort(index,index+N,[r,CN](int i, int j) { return
std::lexicographical_compare(r+i*CN,r+i*CN+CN,r+j*CN,r+j*CN+CN);});
#else
  const float * rr = r;
  std::sort(index,index+N,[rr,CN](int i, int j) { return
std::lexicographical_compare(rr+i*CN,rr+i*CN+CN,rr+j*CN,rr+j*CN+CN);});
#endif
}

compiles fine with the assignment rr = r;
instead
gcc version 4.7.2 20120813 (prerelease) (GCC) 
c++ -O2 -std=c++11 -c pointerVLA.cc -DVLA
pointerVLA.cc: In function 'void bar(int*, int*, int, int)':
pointerVLA.cc:10:121: error: no matching function for call to 'sort(int*&,
int*, bar(int*, int*, int, int)::)'
pointerVLA.cc:10:121: note: candidates are:
In file included from
/build1/sw/osx108_amd64_gcc470/external/gcc/4.7.0/bin/../lib/gcc/x86_64-apple-darwin12.0.0/4.7.2/../../../../include/c++/4.7.2/algorithm:63:0,
 from pointerVLA.cc:1:
/build1/sw/osx108_amd64_gcc470/external/gcc/4.7.0/bin/../lib/gcc/x86_64-apple-darwin12.0.0/4.7.2/../../../../include/c++/4.7.2/bits/stl_algo.h:5463:5:
note: template void std::sort(_RAIter, _RAIter)
/build1/sw/osx108_amd64_gcc470/external/gcc/4.7.0/bin/../lib/gcc/x86_64-apple-darwin12.0.0/4.7.2/../../../../include/c++/4.7.2/bits/stl_algo.h:5463:5:
note:   template argument deduction/substitution failed:
pointerVLA.cc:10:121: note:   candidate expects 2 arguments, 3 provided
In file included from
/build1/sw/osx108_amd64_gcc470/external/gcc/4.7.0/bin/../lib/gcc/x86_64-apple-darwin12.0.0/4.7.2/../../../../include/c++/4.7.2/algorithm:63:0,
 from pointerVLA.cc:1:
/build1/sw/osx108_amd64_gcc470/external/gcc/4.7.0/bin/../lib/gcc/x86_64-apple-darwin12.0.0/4.7.2/../../../../include/c++/4.7.2/bits/stl_algo.h:5499:5:
note: template void std::sort(_RAIter, _RAIter,
_Compare)
/build1/sw/osx108_amd64_gcc470/external/gcc/4.7.0/bin/../lib/gcc/x86_64-apple-darwin12.0.0/4.7.2/../../../../include/c++/4.7.2/bits/stl_algo.h:5499:5:
note:   template argument deduction/substitution failed:
pointerVLA.cc:10:121: note:   variable-sized array type 'bar(int*, int*, int,
int)::' is not a valid template argument

gcc version 4.8.0 20121028 (experimental) [trunk revision 192889] (GCC) 
c++ -O2 -std=c++11 -c pointerVLA.cc -DVLA
pointerVLA.cc: In function ‘void bar(int*, int*, int, int)’:
pointerVLA.cc:10:31: internal compiler error: tree check: expected integer_cst,
have mult_expr in walk_subobject_offsets, at cp/class.c:3516
  std::sort(index,index+N,[r,CN](int i, int j) { return
std::lexicographical_compare(r+i*CN,r+i*CN+CN,r+j*CN,r+j*CN+CN);});
   ^

pointerVLA.cc:10:31: internal compiler error: Abort trap: 6
c++: internal compiler error: Abort trap: 6 (program cc1plus)
Abort trap: 6

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

[hjl.tools at gmail dot com]

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



--- Comment #10 from H.J. Lu  2012-10-31 13:10:02 
UTC ---

-maddress-mode=long is new in 4.8.  GCC 4.7 only implements

-maddress-mode=long equivalent.



I backported -maddress-mode=long to hjl/x32/gcc-4_7-branch branch:



http://gcc.gnu.org/git/?p=gcc.git;a=summary

[Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction

[olegendo at gcc dot gnu.org]

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



--- Comment #20 from Oleg Endo  2012-10-31 
13:47:07 UTC ---

(In reply to comment #19)

> Another thing I've noticed...

> Cases such as:

> 

> mov.l   r0,@r2! LS

> mov r13,r0! MT

> and #7,r0 ! EX

> tst r0,r0 ! MT

> bt/s.L8   ! BR

> mov.l   r0,@(16,r1)

> 

> where the result of the and op is re-used would be slightly better as:

> 

> mov.l   r0,@r2   ! LS

> mov r13,r0   ! MT

> tst #7,r0! MT

> and #7,r0! EX

> bt/s.L8  ! BR

> mov.l   r0,@(16,r1)

> 

> because it reduces dependency on the result of the and op and thus has a 
> higher

> chance to be executed in parallel.



Other similar cases where hoisting the tst insn would make sense:

mov.b   @(13,r2),r0

extu.b  r0,r0

tst #1,r0

bt  .L53



mov.b   @(13,r1),r0

extu.b  r0,r0

tst r0,r0

bt/s.L37

[Bug other/50899] need @direntry for gcov

[tromey at gcc dot gnu.org]

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



--- Comment #1 from Tom Tromey  2012-10-31 14:55:29 
UTC ---

Author: tromey

Date: Wed Oct 31 14:55:20 2012

New Revision: 193036



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

Log:

PR other/50899

* doc/gcc.texi: Add @direntry for gcov.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/doc/gcc.texi

[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[law at redhat dot com]

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



Jeffrey A. Law  changed:



   What|Removed |Added



 CC||law at redhat dot com



--- Comment #13 from Jeffrey A. Law  2012-10-31 15:33:16 
UTC ---

Just a note -- backporting the final fix to 4.7 should be considered a high

priority item.  If I'm reading everything correctly, we can't build a working

PPC glibc right now with the desired optimizations using a GCC 4.7 compiler.

[Bug target/55147] x86: wrong code for 64-bit load

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-31

 CC||jakub at gcc dot gnu.org,

   ||uros at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Jakub Jelinek  2012-10-31 
15:37:49 UTC ---

--- gcc/config/i386/i386.md.jj2012-10-30 09:01:15.0 +0100

+++ gcc/config/i386/i386.md2012-10-31 16:25:13.986916767 +0100

@@ -12688,7 +12688,14 @@ (define_insn_and_split "*bswapdi2_double

(set (match_dup 0)

   (bswap:SI (match_dup 3)))]

 {

-  split_double_mode (DImode, &operands[0], 2, &operands[0], &operands[2]);

+  split_double_mode (DImode, &operands[0], 1, &operands[0], &operands[2]);

+  if (MEM_P (operands[1])

+  && reg_overlap_mentioned_p (operands[2], operands[1]))

+{

+  emit_insn (gen_rtx_SET (VOIDmode, operands[0], XEXP (operands[1], 0)));

+  operands[1] = change_address (operands[1], VOIDmode, operands[0]);

+}

+  split_double_mode (DImode, &operands[1], 1, &operands[1], &operands[3]);



   if (REG_P (operands[0]) && REG_P (operands[1]))

 {



can fix the reg overlap problem between address of operands[1] and high part of

operands[0].  That said, I wonder what is the advantage of having bswapdi2

patter on i?86 at all that the generic expand_doubleword_bswap can't handle.

[Bug target/55147] x86: wrong code for 64-bit load

[ubizjak at gmail dot com]

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



--- Comment #2 from Uros Bizjak  2012-10-31 15:47:46 
UTC ---

> can fix the reg overlap problem between address of operands[1] and high part 
> of

> operands[0].  That said, I wonder what is the advantage of having bswapdi2

> patter on i?86 at all that the generic expand_doubleword_bswap can't handle.



If generic code creates similar assembly, then I'm all for removing this

pattern.

[Bug target/55147] x86: wrong code for 64-bit load

[jakub at gcc dot gnu.org]

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



--- Comment #3 from Jakub Jelinek  2012-10-31 
16:07:11 UTC ---

For the testcase from this PR it creates better assembly actually (compared to

with the #c1 patch, without that it is both longer and wrong).  That is because

when bswapdi is split too late, nothing optimizes the fact that only 32 bits of

the result are used.



For

unsigned long long

f1 (unsigned long long *p, int i)

{

  return __builtin_bswap64 (p[i]);

}



unsigned long long

f2 (unsigned long long p)

{

  return __builtin_bswap64 (p);

}



void

f3 (unsigned long long *p, int i, unsigned long long q)

{

  p[i] = __builtin_bswap64 (q);

}



void

f4 (unsigned long long *p, int i, unsigned long long *q)

{

  p[i] = __builtin_bswap64 (q[i]);

}



it creates the same number of insns/same quality (just slightly different RA

decisions/scheduling) for f1-f3, but for f4 without bswapdi2 it creates

slightly worse code (with bswapdi2 f4 needs just one call saved register,

without it two, supposedly because both bswap insns are scheduled together.

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

[benoit.barbot at gmail dot com]

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

--- Comment #6 from benoit.barbot at gmail dot com 2012-10-31 16:31:37 UTC ---
I try the same file but on a different computer with a newer version of gcc(gcc
(Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3) with the same problem:
>g++ buggcc.ii
g++: erreur interne du compilateur: Processus arrêté (program cc1plus)

[Bug middle-end/55150] New: Crash in copy_rtx

[rmansfield at qnx dot com]

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

 Bug #: 55150
   Summary: Crash in copy_rtx
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rmansfi...@qnx.com
CC: vmaka...@redhat.com


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

It appears this regression was introduced during the LRA merge:

http://gcc.gnu.org/viewcvs?view=revision&revision=192719

$ ./xgcc -B. -Os -g ~/ice.i -m32
/home/ryan/ice.i: In function ‘Camellia_Ekeygen’:
/home/ryan/ice.i:68:3: internal compiler error: in copy_rtx, at rtl.c:323
   }
   ^
0x890190 copy_rtx(rtx_def*)
../../gcc/rtl.c:323
0x800628 remove_pseudos
../../gcc/lra-spills.c:435
0x800693 remove_pseudos
../../gcc/lra-spills.c:443
0x800693 remove_pseudos
../../gcc/lra-spills.c:443
0x800693 remove_pseudos
../../gcc/lra-spills.c:443
0x800693 remove_pseudos
../../gcc/lra-spills.c:443
0x800c73 spill_pseudos
../../gcc/lra-spills.c:481
0x800c73 lra_spill()
../../gcc/lra-spills.c:568
0x7ec984 lra(_IO_FILE*)
../../gcc/lra.c:2327
0x7b4326 do_reload
../../gcc/ira.c:4624
0x7b4326 rest_of_handle_reload
../../gcc/ira.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/55150] Crash in copy_rtx

[rmansfield at qnx dot com]

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



--- Comment #1 from Ryan Mansfield  2012-10-31 
16:41:14 UTC ---

Forgot some info



$ ./xgcc -v

Using built-in specs.

COLLECT_GCC=./xgcc

Target: x86_64-unknown-linux-gnu

Configured with: ../configure --enable-languages=c++ --disable-bootstrap

Thread model: posix

gcc version 4.8.0 20121031 (experimental) [trunk revision 193038] (GCC)

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

[markus at trippelsdorf dot de]

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

--- Comment #7 from Markus Trippelsdorf  
2012-10-31 16:45:43 UTC ---
(In reply to comment #6)
> I try the same file but on a different computer with a newer version of 
> gcc(gcc
> (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3) with the same problem:
> >g++ buggcc.ii
> g++: erreur interne du compilateur: Processus arrêté (program cc1plus)

Make sure you have enough RAM (over 4GB) to compile this testcase.
Check your dmesg for the OOM-killer.

[Bug other/50899] need @direntry for gcov

[tromey at gcc dot gnu.org]

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



Tom Tromey  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #2 from Tom Tromey  2012-10-31 16:46:41 
UTC ---

Fixed.

[Bug fortran/55134] associate construct and assumed size array

[burnus at gcc dot gnu.org]

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



--- Comment #2 from Tobias Burnus  2012-10-31 
17:22:36 UTC ---

Author: burnus

Date: Wed Oct 31 17:22:26 2012

New Revision: 193041



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

Log:

2012-10-31  Tobias Burnus  



PR fortran/55134

* trans-array.c (gfc_conv_array_parameter): Regard AS_DEFERRED

* as

array with descriptor.



2012-10-31  Tobias Burnus  



PR fortran/55134

* gfortran.dg/associate_11.f90: New.





Added:

trunk/gcc/testsuite/gfortran.dg/associate_11.f90

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/trans-array.c

trunk/gcc/testsuite/ChangeLog

[Bug fortran/55134] associate construct and assumed size array

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #3 from Tobias Burnus  2012-10-31 
17:23:52 UTC ---

FIXED on the trunk (4.8).



Thanks for the bug report!

[Bug middle-end/55150] Crash in copy_rtx

[vmakarov at gcc dot gnu.org]

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



--- Comment #2 from Vladimir Makarov  2012-10-31 
18:41:26 UTC ---

Author: vmakarov

Date: Wed Oct 31 18:41:18 2012

New Revision: 193042



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

Log:

2012-10-31  Vladimir Makarov  



PR middle-end/55150

* lra-constraints.c (lra_constraints): Update debug insn info

after equivalence change.



2012-10-31  Vladimir Makarov  



PR middle-end/55150

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







Added:

trunk/gcc/testsuite/gcc.dg/pr55150.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/lra-constraints.c

trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/46309] optimization a==3||a==1

[eidletni at mail dot ru]

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



eidletni at mail dot ru changed:



   What|Removed |Added



 Status|RESOLVED|CLOSED



--- Comment #12 from eidletni at mail dot ru 2012-10-31 19:09:32 UTC ---

Cool, thank you!

[Bug c++/54583] Spurious warning: value computed is not used with variable-size array

[paolo at gcc dot gnu.org]

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



--- Comment #2 from paolo at gcc dot gnu.org  
2012-10-31 19:14:44 UTC ---

Author: paolo

Date: Wed Oct 31 19:14:39 2012

New Revision: 193043



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

Log:

/cp

2012-10-31  Paolo Carlini  



PR c++/54583

* tree.c (build_cplus_array_type): Set TREE_NO_WARNING on the

TYPE_SIZE of VLAs.



/testsuite

2012-10-31  Paolo Carlini  



PR c++/54583

* g++.dg/ext/vla13.C: New.



Added:

trunk/gcc/testsuite/g++.dg/ext/vla13.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/tree.c

trunk/gcc/testsuite/ChangeLog

[Bug c++/54583] Spurious warning: value computed is not used with variable-size array

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #3 from Paolo Carlini  2012-10-31 
19:16:40 UTC ---

Fixed for 4.8.0.

[Bug c++/47444] False warning: array subscript is above array bounds

[eidletni at mail dot ru]

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



eidletni at mail dot ru changed:



   What|Removed |Added



 Status|RESOLVED|CLOSED



--- Comment #14 from eidletni at mail dot ru 2012-10-31 19:24:32 UTC ---

.

[Bug target/54989] FAIL: gcc.dg/hoist-register-pressure.c scan-rtl-dump hoist "PRE/HOIST: end of bb .* copying expression" on darwin

[howarth at nitro dot med.uc.edu]

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



Jack Howarth  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #8 from Jack Howarth  2012-10-31 
19:39:05 UTC ---

I can confirm that both gcc.dg/hoist-register-pressure-1.c and

gcc.dg/hoist-register-pressure-2.c now pass at -m32/-m64 on

x86_64-apple-darwin12 at r193038.

[Bug target/46666] gcc.target/i386/funcspec-3.c ICEs in count_reg_usage (cse.c:6596) with -fno-early-inlining

[zsojka at seznam dot cz]

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



Zdenek Sojka  changed:



   What|Removed |Added



  Known to work||4.6.4, 4.7.3, 4.8.0

  Known to fail|4.6.0   |4.4.7, 4.5.4



--- Comment #3 from Zdenek Sojka  2012-10-31 19:40:43 
UTC ---

(In reply to comment #2)

> VEC stuff is being rewritten. CC to new author.

> 

> Zdenek, can you still reproduce this with a trunk revision?



I can't reproduce it in any of the active branches.

[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #4 from Tobias Burnus  2012-10-31 
19:53:22 UTC ---

Related to bugs: PR 49791 and PR 51825?

[Bug rtl-optimization/55151] New: [4.8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1217 with -fPIC

[zsojka at seznam dot cz]

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



 Bug #: 55151

   Summary: [4.8 Regression] ICE: in assign_by_spills, at

lra-assigns.c:1217 with -fPIC

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: rtl-optimization

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

ReportedBy: zso...@seznam.cz





Created attachment 28582

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

reduced testcase (from gcc.dg/torture/pr20314-2.c)



Compiler output:

$ gcc -fPIC testcase.c 

testcase.c: In function 'f4':

testcase.c:9:1: internal compiler error: in assign_by_spills, at

lra-assigns.c:1217

 }

 ^

0x8d0249 assign_by_spills

/mnt/svn/gcc-trunk/gcc/lra-assigns.c:1217

0x8d21eb lra_assign()

/mnt/svn/gcc-trunk/gcc/lra-assigns.c:1369

0x8ce424 lra(_IO_FILE*)

/mnt/svn/gcc-trunk/gcc/lra.c:2310

0x883d66 do_reload

/mnt/svn/gcc-trunk/gcc/ira.c:4624

0x883d66 rest_of_handle_reload

/mnt/svn/gcc-trunk/gcc/ira.c:4736

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.

[Bug rtl-optimization/54942] [4.8 Regression] ICE: OOM with -O3 -fno-cse-follow-jumps -funroll-loops

[zsojka at seznam dot cz]

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



--- Comment #5 from Zdenek Sojka  2012-10-31 20:02:56 
UTC ---

(In reply to comment #4)

> Does it still happen? I don't see oom now for my test



I can't reproduce it anymore.

[Bug middle-end/55152] New: MAX_EXPR(a,-a) is really ABS_EXPR(a)

[glisse at gcc dot gnu.org]

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



 Bug #: 55152

   Summary: MAX_EXPR(a,-a) is really ABS_EXPR(a)

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

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

ReportedBy: gli...@gcc.gnu.org





I tried compiling this code with -Ofast, but *.optimized still only contained a

MAX_EXPR and not an ABS_EXPR (the back-end didn't find the optimization

either).



double f(double a){

  return (a>=-a)?a:-a;

}



It seems that some simple code in fold-const.c could help (fold is called from

the front-end for COND_EXPR), not sure if anything would call it if -a went

though a temporary variable though.

[Bug middle-end/55152] MAX_EXPR(a,-a) is really ABS_EXPR(a)

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2012-10-31 
20:18:58 UTC ---

Only if you ignore signed zeros and maybe even NaNs.

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

[zsojka at seznam dot cz]

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



 Bug #: 55153

   Summary: [4.8 Regression] ICE: in begin_move_insn, at

sched-ebb.c:205 with -fsched2-use-superblocks and

__builtin_prefetch

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: rtl-optimization

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

ReportedBy: zso...@seznam.cz





Created attachment 28583

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

reduced testcase



Compiler output:

$ gcc -O -fsched2-use-superblocks -fschedule-insns2 testcase.c 

testcase.c: In function 'foo':

testcase.c:7:1: internal compiler error: in begin_move_insn, at sched-ebb.c:205

 }

 ^

0x110a092 begin_move_insn

/mnt/svn/gcc-trunk/gcc/sched-ebb.c:205

0x10cc59c commit_schedule

/mnt/svn/gcc-trunk/gcc/haifa-sched.c:5647

0x10cc59c schedule_block(basic_block_def**, void*)

/mnt/svn/gcc-trunk/gcc/haifa-sched.c:6429

0x110a4f3 schedule_ebb(rtx_def*, rtx_def*, bool)

/mnt/svn/gcc-trunk/gcc/sched-ebb.c:547

0x110b1f4 schedule_ebbs()

/mnt/svn/gcc-trunk/gcc/sched-ebb.c:666

0x9b414c rest_of_handle_sched2

/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3565

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.

[Bug rtl-optimization/55154] New: [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:2702 with custom flags

[zsojka at seznam dot cz]

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



 Bug #: 55154

   Summary: [4.8 Regression] ICE: in curr_insn_transform, at

lra-constraints.c:2702 with custom flags

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: rtl-optimization

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

ReportedBy: zso...@seznam.cz





Created attachment 28584

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

preprocessed source



Compiler output:

$ gcc -O2 -mcx16 -fpic -mcmodel=large -fno-split-wide-types pr46254.i 

/mnt/svn/gcc-trunk/gcc/testsuite/gcc.target/i386/pr46254.c: In function 'test':

/mnt/svn/gcc-trunk/gcc/testsuite/gcc.target/i386/pr46254.c:11:1: error: unable

to generate reloads for:

 }

 ^

(insn 10 14 0 2 (parallel [

(set (subreg:DI (reg:TI 65) 0)

(unspec_volatile:DI [

(mem/v:TI (reg/f:DI 62) [-1 S16 A128])

(mem/c:DI (reg/f:DI 62) [2 i+0 S8 A128])

(mem/c:DI (plus:DI (reg/f:DI 62)

(const_int 8 [0x8])) [2 i+8 S8 A64])

(mem/c:DI (reg/f:DI 62) [2 i+0 S8 A128])

(mem/c:DI (plus:DI (reg/f:DI 62)

(const_int 8 [0x8])) [2 i+8 S8 A64])

(const_int 5 [0x5])

] UNSPECV_CMPXCHG))

(set (subreg:DI (reg:TI 65) 8)

(unspec_volatile:DI [

(const_int 0 [0])

] UNSPECV_CMPXCHG))

(set (mem/v:TI (reg/f:DI 62) [-1 S16 A128])

(unspec_volatile:TI [

(const_int 0 [0])

] UNSPECV_CMPXCHG))

(set (reg:CCZ 17 flags)

(unspec_volatile:CCZ [

(const_int 0 [0])

] UNSPECV_CMPXCHG))

(clobber (reg:DI 67))

]) /mnt/svn/gcc-trunk/gcc/testsuite/gcc.target/i386/pr46254.c:10 2063

{atomic_compare_and_swapti_doubleword}

 (expr_list:REG_UNUSED (reg:DI 67)

(expr_list:REG_DEAD (reg/f:DI 62)

(expr_list:REG_DEAD (reg:TI 60 [ i.1 ])

(expr_list:REG_UNUSED (reg:TI 65)

(expr_list:REG_UNUSED (reg:TI 65)

(expr_list:REG_UNUSED (reg:CCZ 17 flags)

(nil

/mnt/svn/gcc-trunk/gcc/testsuite/gcc.target/i386/pr46254.c:11:1: internal

compiler error: in curr_insn_transform, at lra-constraints.c:2702

0x997d2a _fatal_insn(char const*, rtx_def const*, char const*, int, char

const*)

/mnt/svn/gcc-trunk/gcc/rtl-error.c:110

0x8dd7b9 curr_insn_transform

/mnt/svn/gcc-trunk/gcc/lra-constraints.c:2702

0x8ddf34 lra_constraints(bool)

/mnt/svn/gcc-trunk/gcc/lra-constraints.c:3404

0x8cdd1c lra(_IO_FILE*)

/mnt/svn/gcc-trunk/gcc/lra.c:2281

0x883d66 do_reload

/mnt/svn/gcc-trunk/gcc/ira.c:4624

0x883d66 rest_of_handle_reload

/mnt/svn/gcc-trunk/gcc/ira.c:4736

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.

[Bug tree-optimization/55104] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:269

[zsojka at seznam dot cz]

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



--- Comment #3 from Zdenek Sojka  2012-10-31 20:52:04 
UTC ---

Created attachment 28585

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

preprocessed source (quite reduced)



Probably the same source



Compiler output:

$ gcc -O2 --param=hot-bb-frequency-fraction=1 devirt2.ii 

/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/opt/devirt2.C:30:23: internal compiler

error: in inline_call, at ipa-inline-transform.c:269

 void bah() {foo(&r.s);}

   ^

0x1290c5e inline_call(cgraph_edge*, bool, vec_t**, int*, bool)

/mnt/svn/gcc-trunk/gcc/ipa-inline-transform.c:265

0x128ffd4 inline_small_functions

/mnt/svn/gcc-trunk/gcc/ipa-inline.c:1553

0x128ffd4 ipa_inline

/mnt/svn/gcc-trunk/gcc/ipa-inline.c:1735

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.

[Bug middle-end/55152] MAX_EXPR(a,-a) is really ABS_EXPR(a)

[glisse at gcc dot gnu.org]

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



--- Comment #2 from Marc Glisse  2012-10-31 21:14:12 
UTC ---

Ignoring signed zeros, sure, that's also required to generate a MAX_EXPR in the

first place. NaNs, I don't know, it sounds to me like they have an effect on

generating a MAX_EXPR, but turning the MAX into an ABS should be safe.



(sometimes I wish for a __builtin_max, and -fno-nans)

[Bug middle-end/35310] Late struct expansion -- missing PRE (2)

[xinliangli at gmail dot com]

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



--- Comment #2 from davidxl  2012-10-31 21:17:27 
UTC ---

GCC is still not generating good code here, neither does ICC.



However LLVM does a good job here.



David







(In reply to comment #1)

> Confirmed.  Looks like something for postreload-gcse to handle.  Before that,

> there are no partial redundancies in the RTL (at least, not in the quick look 
> I

> gave it).

[Bug middle-end/55152] MAX_EXPR(a,-a) is really ABS_EXPR(a)

[glisse at gcc dot gnu.org]

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



--- Comment #3 from Marc Glisse  2012-10-31 21:27:27 
UTC ---

Actually, looking at the doc of MAX_EXPR in tree.def (nothing in generic.texi),

we don't even need to ignore signed zeros to turn MAX_EXPR into ABS_EXPR:



/* Minimum and maximum values.  When used with floating point, if both

   operands are zeros, or if either operand is NaN, then it is unspecified

   which of the two operands is returned as the result.  */

[Bug tree-optimization/55155] New: Autovectorization does not use unaligned loads/stores

[sgunderson at bigfoot dot com]

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

 Bug #: 55155
   Summary: Autovectorization does not use unaligned loads/stores
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sgunder...@bigfoot.com


Hi,

I am on

  gcc version 4.7.1 (Debian 4.7.1-7) 

and a project of mine had code that looked like this:

beklager:~> cat example.cpp
void func(float * __restrict prod_features, float * __restrict
grad_prod_features, float alpha, unsigned num_prods) {
float *pf = (float *)__builtin_assume_aligned(prod_features, 16);
float *gpf = (float *)__builtin_assume_aligned(grad_prod_features, 16);
for (unsigned i = 0; i < num_prods * 16; ++i) {
prod_features[i] -= alpha * grad_prod_features[i];
//pf[i] -= alpha * gpf[i];
}
}

This would seem like a great case for autovectorization, so I tried:

beklager:~> g++ -Wall -O2 -ftree-vectorize -msse4.1 -c example.cpp 
example.cpp: In function ‘void func(float*, float*, float, unsigned int)’:
example.cpp:2:9: warning: unused variable ‘pf’ [-Wunused-variable]
example.cpp:3:9: warning: unused variable ‘gpf’ [-Wunused-variable]

The resulting code, however, is a train wreck:
beklager:~> objdump --disassemble --demangle example.o 

example.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:55   push   %rbp
   1:c1 e2 04 shl$0x4,%edx
   4:85 d2test   %edx,%edx
   6:53   push   %rbx
   7:0f 84 ef 00 00 00je fc 
   d:49 89 f8 mov%rdi,%r8
  10:41 83 e0 0f  and$0xf,%r8d
  14:49 c1 e8 02  shr$0x2,%r8
  18:49 f7 d8 neg%r8
  1b:41 83 e0 03  and$0x3,%r8d
  1f:44 39 c2 cmp%r8d,%edx
  22:44 0f 42 c2  cmovb  %edx,%r8d
  26:83 fa 04 cmp$0x4,%edx
  29:0f 87 d0 00 00 00ja ff 
  2f:41 89 d0 mov%edx,%r8d
  32:31 c0xor%eax,%eax
  34:0f 1f 40 00  nopl   0x0(%rax)
  38:f3 0f 10 14 86   movss  (%rsi,%rax,4),%xmm2
  3d:8d 48 01 lea0x1(%rax),%ecx
  40:f3 0f 59 d0  mulss  %xmm0,%xmm2
  44:f3 0f 10 0c 87   movss  (%rdi,%rax,4),%xmm1
  49:f3 0f 5c ca  subss  %xmm2,%xmm1
  4d:f3 0f 11 0c 87   movss  %xmm1,(%rdi,%rax,4)
  52:48 83 c0 01  add$0x1,%rax
  56:41 39 c0 cmp%eax,%r8d
  59:77 ddja 38 
  5b:44 39 c2 cmp%r8d,%edx
  5e:0f 84 98 00 00 00je fc 
  64:89 d5mov%edx,%ebp
  66:45 89 c1 mov%r8d,%r9d
  69:44 29 c5 sub%r8d,%ebp
  6c:41 89 eb mov%ebp,%r11d
  6f:41 c1 eb 02  shr$0x2,%r11d
  73:42 8d 1c 9d 00 00 00 lea0x0(,%r11,4),%ebx
  7a:00 
  7b:85 dbtest   %ebx,%ebx
  7d:74 59je d8 
  7f:0f 28 c8 movaps %xmm0,%xmm1
  82:49 c1 e1 02  shl$0x2,%r9
  86:0f 57 db xorps  %xmm3,%xmm3
  89:4e 8d 14 0f  lea(%rdi,%r9,1),%r10
  8d:0f c6 c9 00  shufps $0x0,%xmm1,%xmm1
  91:49 01 f1 add%rsi,%r9
  94:31 c0xor%eax,%eax
  96:45 31 c0 xor%r8d,%r8d
  99:0f 28 e1 movaps %xmm1,%xmm4
  9c:0f 1f 40 00  nopl   0x0(%rax)
  a0:0f 28 cb movaps %xmm3,%xmm1
  a3:41 83 c0 01  add$0x1,%r8d
  a7:41 0f 28 14 02   movaps (%r10,%rax,1),%xmm2
  ac:41 0f 12 0c 01   movlps (%r9,%rax,1),%xmm1
  b1:41 0f 16 4c 01 08movhps 0x8(%r9,%rax,1),%xmm1
  b7:0f 59 cc mulps  %xmm4,%xmm1
  ba:0f 5c d1 subps  %xmm1,%xmm2
  bd:41 0f 29 14 02   movaps %xmm2,(%r10,%rax,1)
  c2:48 83 c0 10  add$0x10,%rax
  c6:45 39 d8 cmp%r11d,%r8d
  c9:72 d5jb a0 
  cb:01 d9add%ebx,%ecx
  cd:39 ddcmp%ebx,%ebp
  cf:74 2bje fc 
  d1:0f 1f 80 00 00 00 00 nopl   0x0(%rax)
  d8:41 89 c8 mov%ecx,%r8d
  db:83 c1 01 add$0x1,%ecx
  de:f3 42 0f 10 14 86movss  (%rsi,%r8,4),%xmm2
  e4:4a 8d 04 87  lea(%rdi,%r8,4),%rax
  e8:39 cacmp%ecx,

[Bug tree-optimization/55018] [4.6/4.7/4.8 Regression] CDDCE pass is too aggressive sometimes with infinite loops and with some functions

[steven at gcc dot gnu.org]

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



--- Comment #10 from Steven Bosscher  2012-10-31 
21:37:22 UTC ---

Author: steven

Date: Wed Oct 31 21:37:10 2012

New Revision: 193047



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

Log:

gcc/

PR tree-optimization/55018

* basic-block.h (dfs_find_deadend): New prototype.

* cfganal.c (dfs_find_deadend): No longer static.  Use bitmap

instead of sbitmap for visited.

(flow_dfs_compute_reverse_execute): Use dfs_find_deadend here, too.

* dominance.c (calc_dfs_tree): If saw_unconnected,

traverse from dfs_find_deadend of unconnected b

instead of b directly.



testsuite/

PR tree-optimization/55018

* gcc.dg/torture/pr55018.c: New test.





Added:

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

Modified:

trunk/gcc/ChangeLog

trunk/gcc/basic-block.h

trunk/gcc/cfganal.c

trunk/gcc/dominance.c

trunk/gcc/testsuite/ChangeLog

[Bug c++/55156] New: internal compiler error in lambda function

[icegood1980 at gmail dot com]

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



 Bug #: 55156

   Summary: internal compiler error in lambda function

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: icegood1...@gmail.com





Created attachment 28586

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

Preprocessed source



ClusterPivotPocket.cpp: In lambda function:

ClusterPivotPocket.cpp:233:65: internal compiler error: in get_expr_operands,

at tree-ssa-operands.c:1035

Please submit a full bug report,

with preprocessed source if appropriate.



command line:

g++ -std=gnu++11 -Wno-unused-result -Dreproducable -O3 -march=native -Wall

-Wno-format-security -DExplicitTemplates -fno-implicit-templates --param

large-function-insns=47000 --param large-stack-frame=65536 --param

large-stack-frame-growth=3000 -finline-limit=10 --param

inline-unit-growth=1 --param large-function-growth=10 -march=native  

-I../../  -I../../  -I../species -c ClusterPivotPocket.cpp -o

ClusterPivotPocket.o

[Bug tree-optimization/55155] Autovectorization does not use unaligned loads/stores

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2012-10-31 
21:44:20 UTC ---

  :

  _19 = num_prods_6(D) * 16;

  if (_19 != 0)

goto ;

  else

goto ;



  :

  return;



  :

  _16 = ASSERT_EXPR <_19, _19 != 0>;

...

  if (_16 <= 4)

goto ;

  else

goto ;



We should have an assert_expr that _16 is also greater or equal to than 16.



Note this is changing unsigned to __SIZE_TYPE__ so casting does not get in the

way.

[Bug tree-optimization/55157] New: Missing VRP

[pinskia at gcc dot gnu.org]

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



 Bug #: 55157

   Summary: Missing VRP

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: enhancement

  Priority: P3

 Component: tree-optimization

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

ReportedBy: pins...@gcc.gnu.org

Blocks: 55155





Testcase:

void gg(void);

int f(unsigned t)

{

  unsigned g = t*16;

  if (g==0)  return 1;

  gg();

  gg();

  gg();

  gg();

  gg();

  gg();

  if (g<=4)  return 1;

  return 0;

}



In the end there should only be one check for t == 0.

Yes this shows up in real code (well with the autovectorizer); See PR 55155

[Bug rtl-optimization/55151] [4.8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1217 with -fPIC

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-31

 CC||mpolacek at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Marek Polacek  2012-10-31 
21:52:21 UTC ---

Started with http://gcc.gnu.org/viewcvs?view=revision&revision=192719

[Bug c++/55156] internal compiler error in lambda function

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||paolo.carlini at oracle dot

   ||com

 Resolution||DUPLICATE



--- Comment #1 from Paolo Carlini  2012-10-31 
21:53:38 UTC ---

Dup.



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

[Bug c++/54431] [C++11] g++ crashes when compiling the following file

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||icegood1980 at gmail dot

   ||com



--- Comment #3 from Paolo Carlini  2012-10-31 
21:53:38 UTC ---

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

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot

   |gnu.org |com



--- Comment #6 from Paolo Carlini  2012-10-31 
21:55:13 UTC ---

Looking into it.

[Bug rtl-optimization/55158] New: ICE: [4.8 Regreesion] [IA64] segv in schedule_region

[gary at intrepid dot com]

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

 Bug #: 55158
   Summary: ICE: [4.8 Regreesion] [IA64] segv in schedule_region
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com


Created attachment 28587
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28587
Test case: gcc segv when compiled at -O3 on IA64

See attached test case.

$ bld/gcc/cc1 -O3 gcc-ice-schedule-region.c -o gcc-ice-schedule-region.o
 gasneti_check_node_list
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   <*free_inline_summary>

Assembling functions:
 gasneti_check_node_list
gcc-ice-schedule-region.c: In function ‘gasneti_check_node_list’:
gcc-ice-schedule-region.c:53:1: internal compiler error: Segmentation fault
 }
 ^
0x40b7b22f crash_signal
src/gcc/toplev.c:333
0x40ac2aaf schedule_region
src/gcc/sched-rgn.c:2998
0x40ac2aaf schedule_insns()
src/gcc/sched-rgn.c:3343

Here is the schedule_region source at that location.

2993  f = find_fallthru_edge (last_bb->succs);
2994  if (f && f->probability * 100 / REG_BR_PROB_BASE >=
2995  PARAM_VALUE (PARAM_SCHED_STATE_EDGE_PROB_CUTOFF))
2996{
2997  memcpy (bb_state[f->dest->index], curr_state,
2998  dfa_state_size);
2999  if (sched_verbose >= 5)
3000fprintf (sched_dump, "saving state for edge %d->%d\n",
3001 f->src->index, f->dest->index);
3002}

Here is the value of f->dest->index at the pointed and the value of the
selected element of bb_state.

(gdb) p f->dest->index
$1 = 23
(gdb) p bb_state[23]
$2 = (state_t) 0x431

Clearly not a valid address.

(gdb) p bb_state[22]
$3 = (state_t) 0x602f3d58

While the element before it looks OK.

This issue seemed to be introduced by this check in.

2012-10-08  Bernd Schmidt  

* sched-int.h (schedule_block): Adjust declaration.
* sched-rgn.c (bb_state_array, bb_state): New static variables.
(sched_rgn_init): Initialize them.
(sched_rgn_free): Free them.
(schedule_region): Save scheduling state for future blocks, and

which is svn revision 192203.

[Bug fortran/53718] [4.7/4.8 regression] [OOP] gfortran generates asm label twice in the same output file

[janus at gcc dot gnu.org]

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



--- Comment #13 from janus at gcc dot gnu.org 2012-10-31 21:56:00 UTC ---

Author: janus

Date: Wed Oct 31 21:55:50 2012

New Revision: 193048



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

Log:

2012-10-31  Janus Weil  



PR fortran/53718

* trans.h (GFC_DECL_PUSH_TOPLEVEL): Removed.

* trans-decl.c (gfc_get_symbol_decl,gfc_generate_function_code): Remove

GFC_DECL_PUSH_TOPLEVEL.

(build_function_decl): Do not push __copy procedure to toplevel.



2012-10-31  Janus Weil  



PR fortran/53718

* gfortran.dg/class_54.f90: New.



Added:

trunk/gcc/testsuite/gfortran.dg/class_54.f90

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/trans-decl.c

trunk/gcc/fortran/trans.h

trunk/gcc/testsuite/ChangeLog

[Bug c++/55149] capturing VLA in lambda (error in 4.7.2 ICE in 4.8

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #1 from Daniel Krügler  
2012-10-31 21:56:58 UTC ---
I think your example codes involves at least two different issues here. In the
following my data was realized by using gcc 4.8.0 20121014 (experimental) with
the flags

-Wall -std=c++11 -pedantic

First a test case can be constructed that involves attempting to capture the
VLA alone, like this:

//--
void test(int n) {
  int r[n];
  [r]() { return r + 0; };
}
//--

giving me 

"3|internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2045|"

I expect that code to result in a problem for the compiler, because according
to 5.1.2 p21 captured arrays are really copied element-by-element and *no*
previous array-to-pointer conversion shall proceed. But VLAs are effectively
not prepared to be copied (in all other expressions they would first undergo an
array to pointer conversion).

The second (more complex) problem seems to be related to the fact that this
lambda closure with an VLA capture also attempts to capture an integer (I don't
know why this is a problem), which becomes observable here

//--
template
void f(T){ }

void test(int n, int m) {
  int r[n];
  f([r, m](){ return r + m; });
}
//--

"|6|internal compiler error: tree check: expected integer_cst, have mult_expr
in walk_subobject_offsets, at cp/class.c:3431|"

The same problem here:

template
void f(T){ }

void test(int n, int m) {
  int r[n];
  f([=](){ return r + m; });
}

I found that to produce this effect, both a VLA and an integer must be captured
by copy. 

I think it doesn't make sense technically to capture a VLA by copy because that
would require to copy a VLA - this seems something not foreseen for them by the
nature of that type. In this sense your "workaround" really seems necessary to
me and is *not* equivalent to the "#ifdef VLA" branch. This is one of the rare
situations where array-to-pointer conversions does not immediately happen to an
array.

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

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-31

 CC||mpolacek at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Marek Polacek  2012-10-31 
21:59:38 UTC ---

Started with http://gcc.gnu.org/viewcvs?view=revision&revision=192719

[Bug fortran/53718] [4.7 regression] [OOP] gfortran generates asm label twice in the same output file

[janus at gcc dot gnu.org]

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



janus at gcc dot gnu.org changed:



   What|Removed |Added



Summary|[4.7/4.8 regression] [OOP]  |[4.7 regression] [OOP]

   |gfortran generates asm  |gfortran generates asm

   |label twice in the same |label twice in the same

   |output file |output file



--- Comment #14 from janus at gcc dot gnu.org 2012-10-31 22:03:39 UTC ---

r193048 fixes the regression on trunk. Unfortunately it cannot be backported to

4.7.

[Bug rtl-optimization/55154] [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:2702 with custom flags

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-31

 CC||mpolacek at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Marek Polacek  2012-10-31 
22:06:12 UTC ---

Started with http://gcc.gnu.org/viewcvs?view=revision&revision=192719

The interesting thing is that this happened before, definitely in r190614,

afterwards was fixed in some commit, and 190777 was fine.

[Bug target/53988] [SH] tst Rm,Rn not used for QI/HImode

[olegendo at gcc dot gnu.org]

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



--- Comment #2 from Oleg Endo  2012-10-31 22:08:42 
UTC ---

There was a typo in the PR number when committing the patch for this issue.

This is the original commit message that accidentally ended up in PR 54988:



Author: olegendo

Date: Tue Oct 30 09:07:08 2012

New Revision: 192982



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

Log:

PR target/54988

* config/sh/sh.md (tstqi_t_zero): Rename to *tstqi_t_zero.

(*tst_t_zero): New insns.

* config/sh/iterators.md (lowpart_be, lowpart_le): New mode attributes.



PR target/54988

* gcc.target/sh/pr53988.c: New.





Added:

trunk/gcc/testsuite/gcc.target/sh/pr53988.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/sh/iterators.md

trunk/gcc/config/sh/sh.md

trunk/gcc/testsuite/ChangeLog



I've fixed the typos in the ChangeLog files.

[Bug c++/54988] fpmath=sse target pragma causes inlining failure because of target specific option mismatch

[olegendo at gcc dot gnu.org]

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



Oleg Endo  changed:



   What|Removed |Added



 CC||olegendo at gcc dot gnu.org



--- Comment #9 from Oleg Endo  2012-10-31 22:09:10 
UTC ---

(In reply to comment #8)

> Author: olegendo

> Date: Tue Oct 30 09:07:08 2012

> New Revision: 192982

> 

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

> Log:

> PR target/54988

> * config/sh/sh.md (tstqi_t_zero): Rename to *tstqi_t_zero.

> (*tst_t_zero): New insns.

> * config/sh/iterators.md (lowpart_be, lowpart_le): New mode attributes.

> 

> PR target/54988

> * gcc.target/sh/pr53988.c: New.

> 

> 

> Added:

> trunk/gcc/testsuite/gcc.target/sh/pr53988.c

> Modified:

> trunk/gcc/ChangeLog

> trunk/gcc/config/sh/iterators.md

> trunk/gcc/config/sh/sh.md

> trunk/gcc/testsuite/ChangeLog



Sorry for the typo in the PR number of the ChangeLog.  ChangeLog fixed, commit

message posted to PR 53988.

[Bug c++/54431] [C++11] g++ crashes when compiling the following file

[icegood1980 at gmail dot com]

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



--- Comment #4 from icegood1980 at gmail dot com  
2012-10-31 22:26:46 UTC ---

(In reply to comment #1)

> Gcc also doesn't crash if the lambda line is changed to

> 

> [this]{this->bar();}();

> 

> Although the resulting program does.



Of course, resulting program should crash because you have infinite reccursion

call. Anyway next code crashes too:

#include 



template 

struct foo

{

public:

 void blah()

 {

  std::cerr<<"blah-blah"< ss;

 ss.bar();

}



For workaround with [this] thanks, i should guess...

[Bug tree-optimization/46309] optimization a==3||a==1

[rdsandiford at googlemail dot com]

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



--- Comment #13 from rdsandiford at googlemail dot com  2012-10-31 22:36:48 UTC ---

"eidletni at mail dot ru"  writes:

> Cool, thank you!



+1, thanks Jakub

[Bug preprocessor/55115] [>=4.5.0 regression] missing headers as fatal breaks cproto logic

[pierre.poissinger at gmail dot com]

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



--- Comment #11 from Pierre Poissinger  
2012-10-31 22:46:07 UTC ---

Created attachment 28588

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

Don't treat missing headers as fatal error if only preproc



Following patch allows preproc only (-E) to not treat missing headers as a

fatal error - a non-fatal error will be raised, as pre-4.5, for that specific

case.



In addition:

* Updated 2 cpp testcases (include2.c/include2a.c) to use "compile" instead of

preproc, so 'terminated' test can be checked

* Added a new cpp testcase (include2b.c) to check preproc will return 'missing

header' error, but does not stop preproc



Notes:

- Patch is done on gcc-4_7-branch

- Did not spot any difference with check-gcc before/after patch [expect

additional testcase]

- Seems to fix my cproto issues

[Bug target/54938] sh libgcc_unpack_df.o fails to build: ../../../srcw/libgcc/fp-bit.h:221:19: internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:4273

[eraman at gcc dot gnu.org]

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



--- Comment #6 from eraman at gcc dot gnu.org 2012-10-31 23:28:52 UTC ---

Author: eraman

Date: Wed Oct 31 23:28:45 2012

New Revision: 193052



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

Log:

2012-10-31   Easwaran Raman  



PR target/54938

PR middle-end/54957

* optabs.c (emit_cmp_and_jump_insn_1): Add REG_BR_PROB note

only if it doesn't already exist.

* stmt.c (get_outgoing_edge_probs): Return 0 if BB is NULL.

(emit_case_dispatch_table): Handle the case where STMT_BB is

NULL.

(expand_sjlj_dispatch_table): Pass BB containing before_case

to emit_case_dispatch_table.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/optabs.c

trunk/gcc/stmt.c

[Bug middle-end/54957] Two crashes introduced by rev192488

[eraman at gcc dot gnu.org]

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



--- Comment #20 from eraman at gcc dot gnu.org 2012-10-31 23:28:52 UTC ---

Author: eraman

Date: Wed Oct 31 23:28:45 2012

New Revision: 193052



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

Log:

2012-10-31   Easwaran Raman  



PR target/54938

PR middle-end/54957

* optabs.c (emit_cmp_and_jump_insn_1): Add REG_BR_PROB note

only if it doesn't already exist.

* stmt.c (get_outgoing_edge_probs): Return 0 if BB is NULL.

(emit_case_dispatch_table): Handle the case where STMT_BB is

NULL.

(expand_sjlj_dispatch_table): Pass BB containing before_case

to emit_case_dispatch_table.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/optabs.c

trunk/gcc/stmt.c

[Bug target/54963] [4.8 Regression] Wrong code generated for libgfortran/generated/eoshift3_8.c on SH

[olegendo at gcc dot gnu.org]

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



--- Comment #9 from Oleg Endo  2012-11-01 00:01:13 
UTC ---

Kaz, can we close this PR?

[Bug target/54546] SH: Enable -fshrink-wrap

[olegendo at gcc dot gnu.org]

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



--- Comment #3 from Oleg Endo  2012-11-01 00:03:11 
UTC ---

Even though simple_return is not supported on SHmedia, is it OK to close this

PR?

[Bug target/54963] [4.8 Regression] Wrong code generated for libgfortran/generated/eoshift3_8.c on SH

[kkojima at gcc dot gnu.org]

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



Kazumoto Kojima  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #10 from Kazumoto Kojima  2012-11-01 
00:13:13 UTC ---

Yes.  Closed as FIXED.

[Bug rtl-optimization/55158] ICE: [4.8 Regreesion] [IA64] segv in schedule_region

[gary at intrepid dot com]

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



--- Comment #1 from Gary Funck  2012-11-01 00:15:54 
UTC ---

Some additional debugging information.



In sched_rgn_init(), the bb_state array is initialized.



3049{

3050  bb_state_array = (char *) xmalloc (last_basic_block *

dfa_state_size);

3051  bb_state = XNEWVEC (state_t, last_basic_block);

3052  for (i = 0; i < last_basic_block; i++)

3053{

3054  bb_state[i] = (state_t) (bb_state_array + i *

dfa_state_size);

3055  

3056  state_reset (bb_state[i]);

3057}

3058}



For the given test case.



(gdb) p last_basic_block

$3 = 23



Yet, it is the access of bb_state[23] that leads to the segfault.



The last basic block is 23, and the array bb_state[] is initialized only for

entries 0..22.  Perhaps the number entries allocated should be

(last_basic_block +  1) with the initialization loop adjusted accordingly?

[Bug c++/55159] New: pythy constexpr auto lambda pointer has no initializer

[supercilious.dude at gmail dot com]

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



 Bug #: 55159

   Summary: pythy constexpr auto lambda pointer has no initializer

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: supercilious.d...@gmail.com





Pythy (http://pfultz2.github.com/Pythy/) does something akin to:



template  

typename std::remove_reference::type *addr(T &&t) 

{ 

return &t; 

}



template 

struct min_t

{

constexpr static auto *f =

false ? addr([](T0 x, T1 y){ return x < y ? x : y; }) : nullptr; 

};



Which gcc (4.7.2 and 4.8.0 git master) cannot evaluate.

clang and visual studio 2012 work fine.



I know this is not strictly needed by gcc 4.8 since it has deduced auto without

the late specifier (which the other compilers lack), but its highly convenient

to have pythy work on all c++11 compilers.

[Bug rtl-optimization/55158] ICE: [4.8 Regreesion] [IA64] segv in schedule_region

[gary at intrepid dot com]

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



--- Comment #2 from Gary Funck  2012-11-01 00:35:41 
UTC ---

I tried making the change suggested in the previous comment and ran into a

segfault here:



5876dump_new_block_header (0, *target_bb, head, tail);

5877

5878  if (init_state == NULL)

5879state_reset (curr_state);

5880  else

5881memcpy (curr_state, init_state, dfa_state_size);

5882

5883  /* Clear the ready list.  */

5884  ready.first = ready.veclen - 1;

5885  ready.n_ready = 0;



(gdb) p init_state

$10 = (state_t) 0x431



init_state is an invalid pointer.



Going up one level.



2985  curr_bb = first_bb;

2986  if (dbg_cnt (sched_block))

2987{

2988  edge f;

2989

2990  schedule_block (&curr_bb, bb_state[first_bb->index]);

2991  gcc_assert (EBB_FIRST_BB (bb) == first_bb);

2992  sched_rgn_n_insns += sched_n_insns;

2993  f = find_fallthru_edge (last_bb->succs);

2994  if (f && f->probability * 100 / REG_BR_PROB_BASE >=



(gdb) p first_bb->index

$13 = 25



If the last basic block is 23, then this index is out-of-range.

[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument

[mw_triad at users dot sourceforge.net]

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



Matthew Woehlke  changed:



   What|Removed |Added



 CC||mw_triad at users dot

   ||sourceforge.net



--- Comment #10 from Matthew Woehlke  
2012-11-01 00:38:20 UTC ---

This is not fixed (gcc 4.7.2) if the default parameter occurs in a system

header. In such case, I would expect no warning at all. Instead, I get the old

and confusing behavior of gcc warning at the point where the default parameter

is used.

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC||daniel.kruegler at

   ||googlemail dot com, jason

   ||at gcc dot gnu.org



--- Comment #7 from Paolo Carlini  2012-11-01 
01:01:07 UTC ---

In fact, I'm not so sure we have a bug here. C++11 5.2.8 says "the expression

is obtained by applying the unary * operator to a pointer and the pointer is a

null pointer value": does that mean *any* possible expression where a null

pointer appears or just the expressions of the simple form clarified in note

68? In fact, if I add:



  polymorphic operator+(polymorphic, polymorphic);



and change the typeid argument to:



  *(T*)0 + *(T*)0



then ICC doesn't throw. Why (result=true, *(T*)0) should be different?

[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument

[paolo.carlini at oracle dot com]

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



--- Comment #11 from Paolo Carlini  2012-11-01 
01:28:26 UTC ---

I can't reproduce in mainline and 4_7-branch. This is what I tried:



a.h:

#pragma GCC system_header



void* fun(void* a = 0);



a.C:

#include "a.h"



int main()

{

  fun();

}



if I compile a.C I get no warnings at all (I get warnings with the pragma

commented out, as expected, and in the right place, line #3 of a.h). Likewise,

everything is fine if inside a.h, a boo calls fun(). Do you have a better

testcase?

[Bug tree-optimization/55110] [4.8 Regression] Internal compiler error in vectorizable_reduction, at tree-vect-loop.c:4633

[rth at gcc dot gnu.org]

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



Richard Henderson  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |

[Bug rtl-optimization/55160] New: [4.8 Regression] Counterproductive loop induction variable optimization

[olegendo at gcc dot gnu.org]

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

 Bug #: 55160
   Summary: [4.8 Regression] Counterproductive loop induction
variable optimization
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
CC: amyl...@gcc.gnu.org
Target: sh*-*-* arm*-*-*


Starting with rev 192505 the following

int test_04 (int* x, int c)
{
  int s = 0;
  for (int i = 0; i < c; ++i)
s += *--x;
  return s;
}

gets compiled to (SH, -O2 -m4 -ml):

cmp/pl  r5
bf/s.L12
mov #0,r1
mov #0,r0
.L11:
add #-4,r4
mov.l   @r4,r2
add #1,r1
cmp/eq  r5,r1
bf/s.L11
add r2,r0
rts
nop
.L12:
rts
mov #0,r0

whereas before (also on 4.7.3) it was:
cmp/pl  r5
bf/s.L11
mov #0,r0
.L10:
add #-4,r4
mov.l   @r4,r1
dt  r5
bf/s.L10
add r1,r0
rts
nop
.L11:
rts
nop

In this case the inner loop code size effectively does not increase, but there
is overhead in setting up the loop.  Similar code is also generated on ARM.


Another similar case:

int test_03 (int* x, int c)
{
  int s = 0;
  for (int i = 0; i < c; ++i)
s += x[i];
  return s;
}

rev 192505:
cmp/pl  r5
bf/s.L4
shll2   r5
add r4,r5
mov #0,r0
.L3:
mov.l   @r4+,r1
cmp/eq  r5,r4
bf/s.L3
add r1,r0
rts
nop
.L4:
rts
mov #0,r0


before it was:
cmp/pl  r5
bf/s.L6
mov #0,r0
shll2   r5
add #-4,r5
shlr2   r5
add #1,r5
.L3:
mov.l   @r4+,r1
dt  r5
bf/s.L3
add r1,r0
.L6:
rts
nop

In this case, there was the useless loop setup code.  Ideally this should be
something like:

cmp/pl  r5
bf/s.L6
mov #0,r0
.L3:
mov.l   @r4+,r1
dt  r5
bf/s.L3
add r1,r0
.L6:
rts
nop

Jörn, I've added you in CC because your commit (rev 192505) seems to have
triggered something there.  I'm not sure whether this is actually the cause for
this counter productive transformation.

[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[bergner at gcc dot gnu.org]

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



--- Comment #14 from Peter Bergner  2012-11-01 
02:48:10 UTC ---

Author: bergner

Date: Thu Nov  1 02:48:07 2012

New Revision: 193058



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

Log:

2012-10-31  Jakub Jelinek  



PR tree-optimization/53708

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

user-supplied alignment when used with an explicit section name.



Modified:

trunk/gcc/ChangeLog

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

[Bug rtl-optimization/55160] [4.8 Regression] Counterproductive loop induction variable optimization

[amylaar at gcc dot gnu.org]

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



--- Comment #1 from Jorn Wolfgang Rennecke  
2012-11-01 06:28:14 UTC ---

Author: amylaar

Date: Thu Nov  1 06:28:06 2012

New Revision: 193060



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

Log:

PR target/55160

* config/sh/sh.md (doloop_end): Use emit_jump_insn.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/sh/sh.md