[Bug middle-end/54146] Very slow compile with attribute((flatten))

[hubicka at gcc dot gnu.org]

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

--- Comment #43 from Jan Hubicka  2012-08-10 
07:52:31 UTC ---
Author: hubicka
Date: Fri Aug 10 07:52:23 2012
New Revision: 190283

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

PR middle-end/54146
* ipa-inline-transform.c (inline_call): Add UPDATE_OVERALL_SUMMARY
parameter; honnor it.
* ipa-inline.c (recursive_inlining): Update call
of inline_call.
(inline_small_functions): Likewise.
(ipa_inline): Likewise.
(inline_always_inline_functions): Likewise.
(early_inline_small_functions): Likewise.
(flatten_function): Do separate update of summary info.
* ipa-inline.h (inline_update_overall_summary): Declare.
(inline_call): Update.
* ipa-inline-analysis.c (inline_merge_summary): Break out
updating code to ...
(inline_update_overall_summary): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-analysis.c
trunk/gcc/ipa-inline-transform.c
trunk/gcc/ipa-inline.c
trunk/gcc/ipa-inline.h

[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)

[chrbr at gcc dot gnu.org]

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

--- Comment #26 from chrbr at gcc dot gnu.org 2012-08-10 08:08:45 UTC ---
(In reply to comment #24)
> Christian, do you have anything to add regarding this matter?
> 
> I'm not sure whether this should be back ported to 4.6.x or 4.7.x or not.  
> Kaz,
> what do you think?

I got an ICE in elimination_costs_in_insn, at reload1.c:3654 when applying to
the 4.7 branch, but it seems to be resolved on trunk (hoping it's not hidden)
so I guess you can close this defect as resolved.

I'm about to submit a separate patch for the second opportunity I mentioned in
comment #17, as soon as it's polished up and I can assess some performance.

[Bug fortran/54208] compilation error for ubound construct in PARAMETER statements

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org 2012-08-10 08:31:12 UTC ---
(In reply to comment #2)
> Anyway, the following patchlet gets rid of the error, but may possibly
> introduce regressions (unchecked):

It fails with an ICE on:
 * interface_12.f90
 * result_in_spec_1.f90

[Bug tree-optimization/54027] [4.8 Regression] possible mis-optimization of signed left shift in c89 mode

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2012-08-10 
08:34:01 UTC ---
Author: rguenth
Date: Fri Aug 10 08:33:57 2012
New Revision: 190286

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190286
Log:
2012-08-10  Richard Guenther  

PR tree-optimization/54027
* tree-vrp.c (extract_range_from_binary_expr_1): Merge RSHIFT_EXPR
and LSHIFT_EXPR handling, force -fwrapv for the multiplication used
to handle LSHIFT_EXPR with a constant.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr54027.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug middle-end/54218] New: Debug info for function parameters is incorrect when compiled with -O0

[senthil_kumar.selvaraj at atmel dot com]

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

 Bug #: 54218
   Summary: Debug info for function parameters is incorrect when
compiled with -O0
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: senthil_kumar.selva...@atmel.com


Created attachment 27980
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27980
Failing dejagnu test case

When compiling a function, like below, with no optimizations (-O0), on a x86_64
target (also occurs for atleast one other target (avr))

void func(int p)
{
p = 0; 
p = 32;
}

wrong debug information is emitted for the function parameter (p), that cause
the debugger to keep showing the value of the actual argument, even after p is
overwritten. A failing dejagnu test is attached.

Based on a preliminary analysis, the actual problem seems to be that stack
space for a function parameter (that is not used??) is allocated twice when
gimple_expand_cfg runs - once when expand_used_vars runs, and later when
assign_parm_setup_stack runs. expand_used_vars allocates stack space despite
the check for a default definition being present in the partition, because the
function parameter node (which I guess should be the default definition) is not
present when iterating over num_ssa_names.

[Bug tree-optimization/54027] [4.8 Regression] possible mis-optimization of signed left shift in c89 mode

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Richard Guenther  2012-08-10 
08:39:26 UTC ---
Fixed.  VRP shift handling is still lame.

[Bug middle-end/54218] Debug info for function parameters is incorrect when compiled with -O0

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-debug
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-10
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-08-10 
08:53:46 UTC ---
That's because the actual parameter value is not used:

func (int p)
{
;;   basic block 2, loop depth 0
;;pred:   ENTRY
  p_1 = 0;
  p_2 = 32;
  return;

Partition 0 (p_1 - 1 2 )


Does -fvar-tracking "fix" it?

[Bug fortran/54208] [4.6/4.7/4.8 Regression] compilation error for ubound construct in PARAMETER statements

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||burnus at gcc dot gnu.org
  Known to work||4.2.5
   Target Milestone|--- |4.6.4
Summary|compilation error for   |[4.6/4.7/4.8 Regression]
   |ubound construct in |compilation error for
   |PARAMETER statements|ubound construct in
   ||PARAMETER statements
  Known to fail||4.3.6, 4.8.0

[Bug c++/52748] [C++11] N3276 changes to decltype

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-10
 Ever Confirmed|0   |1

[Bug rtl-optimization/53533] [4.7/4.8 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.2

[Bug middle-end/53204] [4.7 regression] ICE during final link of large codebase with -O2 -finline-functions -flto, adding -flto-partition=none fixes the problem

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #3 from Richard Guenther  2012-08-10 
09:47:04 UTC ---
No testcase.

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

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||lto
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-10
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-08-10 
09:52:37 UTC ---
We've discussed the possibility of iterating the LTO WPA phase by outputting
LTO bytecode from the LTRANS phase (at some point before expansion, likely
even before loop optimizations).  That would be the way to go here I think,
apart from the idea that popped up how to do better for early optimization
of cycles in the cgraph.

[Bug middle-end/54218] Debug info for function parameters is incorrect when compiled with -O0

[senthil_kumar.selvaraj at atmel dot com]

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

--- Comment #2 from Senthil Kumar Selvaraj  2012-08-10 10:23:55 UTC ---
Comment on attachment 27980
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27980
Failing dejagnu test case

>/* { dg-do run } */
>/* { dg-options "-g" } */
>/* { dg-skip-if "" { *-*-* }  { "*" } { "-O0" } } */
>
>void func(int p)
>{
>p = 0; /* { dg-final { gdb-test 8 "p" "0" } } */
>p = 32;/* { dg-final { gdb-test 8 "p" "42" } } */
>}
>
>int
>main (void)
>{
>int local = 42;
>func(local);
>}

[Bug middle-end/54218] Debug info for function parameters is incorrect when compiled with -O0

[senthil_kumar.selvaraj at atmel dot com]

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

Senthil Kumar Selvaraj  changed:

   What|Removed |Added

  Attachment #27980|0   |1
is obsolete||

--- Comment #3 from Senthil Kumar Selvaraj  2012-08-10 10:25:03 UTC ---
Created attachment 27981
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27981
Failing dejagnu test case (right line number)

[Bug middle-end/54218] Debug info for function parameters is incorrect when compiled with -O0

[senthil_kumar.selvaraj at atmel dot com]

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

--- Comment #4 from Senthil Kumar Selvaraj  2012-08-10 10:39:32 UTC ---
(In reply to comment #1)
> That's because the actual parameter value is not used:
> 
> func (int p)
> {
> ;;   basic block 2, loop depth 0
> ;;pred:   ENTRY
>   p_1 = 0;
>   p_2 = 32;
>   return;
> 
> Partition 0 (p_1 - 1 2 )
> 
> 
> Does -fvar-tracking "fix" it?

Yes, it does. Doesn't change the code generated though - the initial copy is
still at a different frame offset.

(In reply to comment #1)
> That's because the actual parameter value is not used:
> 
> func (int p)
> {
> ;;   basic block 2, loop depth 0
> ;;pred:   ENTRY
>   p_1 = 0;
>   p_2 = 32;
>   return;
> 
> Partition 0 (p_1 - 1 2 )
> 
> 
> Does -fvar-tracking "fix" it?

(In reply to comment #1)
> That's because the actual parameter value is not used:
> 
> func (int p)
> {
> ;;   basic block 2, loop depth 0
> ;;pred:   ENTRY
>   p_1 = 0;
>   p_2 = 32;
>   return;
> 
> Partition 0 (p_1 - 1 2 )
> 
> 
> Does -fvar-tracking "fix" it?

[Bug middle-end/54219] New: __builtin_shuffle mask reversed

[glisse at gcc dot gnu.org]

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

 Bug #: 54219
   Summary: __builtin_shuffle mask reversed
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


Hello,

#include 

__m128d f(__m128d x){
  __m128i m={5,0};
  return __builtin_shuffle(x,x,m);
}

$ gcc u.c -O2 -S -Wall

produces a simple rep; ret. However, if I replace 5 with 1, it does produce the
expected shufpd.

fold-const.c contains this loop:
  for (i = 0; i < nelts; i++)
tsel[i] = build_int_cst (eltype, sel[nelts - i - 1]);

which reverses the order of the elements in the mask. I don't know if there is
any reason to do that...

[Bug middle-end/54219] [4.8 Regression] __builtin_shuffle mask reversed

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Keywords||wrong-code
   Last reconfirmed||2012-08-10
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1
Summary|__builtin_shuffle mask  |[4.8 Regression]
   |reversed|__builtin_shuffle mask
   ||reversed

--- Comment #1 from Richard Guenther  2012-08-10 
10:59:20 UTC ---
Probably an error of mine when I converted VECTOR_CSTs to a more sane
representation.

[Bug middle-end/54219] [4.8 Regression] __builtin_shuffle mask reversed

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug middle-end/54109] [4.8 Regression] ICE at tree-ssa-structalias.c:3049 in get_constraint_for_component_ref

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-08-10 
12:00:11 UTC ---
Author: rguenth
Date: Fri Aug 10 12:00:05 2012
New Revision: 190291

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190291
Log:
2012-08-10  Richard Guenther  

PR tree-optimization/54109
* tree-ssa-forwprop.c
(forward_propagate_addr_into_variable_array_index): Remove.
(forward_propagate_addr_expr_1): Adjust.

* gcc.dg/torture/pr54109.c: New testcase.
* gcc.dg/tree-ssa/forwprop-1.c: Adjust.
* gcc.dg/tree-ssa/forwprop-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr54109.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-2.c
trunk/gcc/tree-ssa-forwprop.c

[Bug middle-end/54109] [4.8 Regression] ICE at tree-ssa-structalias.c:3049 in get_constraint_for_component_ref

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Richard Guenther  2012-08-10 
12:00:59 UTC ---
Fixed.

[Bug middle-end/54211] [4.8 Regression] ICE: verify_gimple failed building freetype with -Os

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from William J. Schmidt  2012-08-10 
12:16:11 UTC ---
Author: wschmidt
Date: Fri Aug 10 12:16:04 2012
New Revision: 190294

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

2012-08-10  Bill Schmidt  

PR middle-end/54211
* gimple-ssa-strength-reduction.c (analyze_candidates_and_replace):
Use cand_type to determine whether pointer arithmetic will be generated.

gcc/testsuite:

2012-08-10  Bill Schmidt  

PR middle-end/54211
* gcc.dg/tree-ssa/pr54211.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr54211.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/54211] [4.8 Regression] ICE: verify_gimple failed building freetype with -Os

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from William J. Schmidt  2012-08-10 
12:16:11 UTC ---
Author: wschmidt
Date: Fri Aug 10 12:16:04 2012
New Revision: 190294

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

2012-08-10  Bill Schmidt  

PR middle-end/54211
* gimple-ssa-strength-reduction.c (analyze_candidates_and_replace):
Use cand_type to determine whether pointer arithmetic will be generated.

gcc/testsuite:

2012-08-10  Bill Schmidt  

PR middle-end/54211
* gcc.dg/tree-ssa/pr54211.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr54211.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c
trunk/gcc/testsuite/ChangeLog

--- Comment #7 from William J. Schmidt  2012-08-10 
12:16:55 UTC ---
Fixed.

[Bug middle-end/54211] [4.8 Regression] ICE: verify_gimple failed building freetype with -Os

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from William J. Schmidt  2012-08-10 
12:16:55 UTC ---
Fixed.

[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)

[olegendo at gcc dot gnu.org]

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

--- Comment #27 from Oleg Endo  2012-08-10 
12:26:52 UTC ---
(In reply to comment #26)
> 
> I got an ICE in elimination_costs_in_insn, at reload1.c:3654 when applying to
> the 4.7 branch, but it seems to be resolved on trunk (hoping it's not hidden)
> so I guess you can close this defect as resolved.

This is probably due to the splitter part of the *movsi_index_disp patterns:

  [(set (match_dup 5) (ashift:SI (match_dup 1) (match_dup 2)))
   (set (match_dup 6) (plus:SI (match_dup 5) (match_dup 3)))
   (set (match_dup 0) (match_dup 7))]

The left shift won't match after this has been split, because there's no such
shift pattern.  On 4.7 it could be avoided by manually emitting the appropriate
shift insn in the preparation block of the splitter.  However, I'm not sure
whether it will be correct, due to the scratch regs and T_REG clobber in the
left shift patterns etc ... 
On trunk it is OK because the log2 shift sequences of the *movsi_index_disp
patterns will never clobber the T_REG... at least that's what I initially
thought, which is obviously wrong.  Left shifts of 15, 23, 29, 31 clobber T_REG
(if they are not converted to dynamic shifts).  These shift amounts are
probably not very likely to happen (e.g. tab[i * 8192 + 4]).  Still, they
should be handled.  I'll have a look at it, so let's keep this PR open for a
little bit longer...

[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie

[wbrana at gmail dot com]

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

wbrana  changed:

   What|Removed |Added

Summary|-fPIE -pie shouldn't|-fvisibility=hidden
   |disable -fvisibility=hidden |shouldn't be disabled with
   ||-fPIE -pie

--- Comment #6 from wbrana  2012-08-10 12:31:08 UTC ---
updated

[Bug target/54220] New: [avr] Potential stack corruption in naked functions at -O0

[senthil_kumar.selvaraj at atmel dot com]

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

 Bug #: 54220
   Summary: [avr] Potential stack corruption in naked functions at
-O0
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: senthil_kumar.selva...@atmel.com
Target: AVR


Naked functions do not have a prologue and an epilogue by design, but code
emitted with -O0 for function parameters assume their presence and attempt to
copy values onto the stack. This can corrupt the caller's stack frame.

Note the stores to Y+2 and Y+1 in the example below.

[scratch]$ cat test.c
void __attribute__((naked)) func(int x)
{
__asm volatile ("ret");
}
[scratch]$ avr-gcc -O0 -S test.c
[scratch]$ cat test.s
.file   "test.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__CCP__ = 0x34
__tmp_reg__ = 0
__zero_reg__ = 1
.global __do_copy_data
.global __do_clear_bss
.text
.global func
.type   func, @function
func:
/* prologue: naked */
/* frame size = 2 */
/* stack size = 0 */
.L__stack_usage = 0
std Y+2,r25
std Y+1,r24
/* #APP */
 ;  3 "test.c" 1
ret
 ;  0 "" 2
/* epilogue start */
/* #NOAPP */
.size   func, .-func

[Bug fortran/54221] New: Explicit private access specifier signals "unexpected defined but not used [-Wunused-function]" warning

[koen.poppe at cs dot kuleuven.be]

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

 Bug #: 54221
   Summary: Explicit private access specifier signals "unexpected
defined but not used [-Wunused-function]" warning
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: koen.po...@cs.kuleuven.be


Created attachment 27982
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27982
Reproduces unexpected warning on compilation

Setting routines private in a private module causes the "defined but not used
[-Wunused-function]" warning to be issued.

[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)

[rmansfield at qnx dot com]

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

Ryan Mansfield  changed:

   What|Removed |Added

 CC||rmansfield at qnx dot com

--- Comment #28 from Ryan Mansfield  2012-08-10 
13:14:33 UTC ---
(In reply to comment #27)
> (In reply to comment #26)
> > 
> > I got an ICE in elimination_costs_in_insn, at reload1.c:3654 when applying 
> > to
> > the 4.7 branch, but it seems to be resolved on trunk (hoping it's not 
> > hidden)

This ICE does happen on trunk (rev190294). I have a testcase for it that I'm
reducing. There was a second ICE introduced by 190259 as well. 

/home/ryan/ice2.i:9312:1: error: unrecognizable insn:
 }
 ^
(insn 780 647 781 28 (set (reg:SI 530)
(ashift:SI (reg:SI 147 t)
(const_int 1 [0x1]))) /home/ryan/ice2.i:9270 -1
 (nil))
/home/ryan/ice2.i:9312:1: internal compiler error: in extract_insn, at
recog.c:2125

Should I attach the testcases to this PR or open a new PR?

[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)

[olegendo at gcc dot gnu.org]

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

--- Comment #29 from Oleg Endo  2012-08-10 
13:26:52 UTC ---
(In reply to comment #28)
> 
> This ICE does happen on trunk (rev190294). I have a testcase for it that I'm
> reducing. There was a second ICE introduced by 190259 as well. 
> 
> /home/ryan/ice2.i:9312:1: error: unrecognizable insn:
>  }
>  ^
> (insn 780 647 781 28 (set (reg:SI 530)
> (ashift:SI (reg:SI 147 t)
> (const_int 1 [0x1]))) /home/ryan/ice2.i:9270 -1
>  (nil))
> /home/ryan/ice2.i:9312:1: internal compiler error: in extract_insn, at
> recog.c:2125
> 
> Should I attach the testcases to this PR or open a new PR?

This left shift ICE looks like a problem I introduced with changes in PR 54089.
Please post the testcase for this in PR 54089.

BTW, I've confirmed my guess in comment #27 that the following function

int test00 (int tab[], int i)
{
  return tab[i * 8192 + 4];
}

will currently ICE when compiled for -m2 and will produce potentially wrong
code around the T_REG for -m2a and -m3.  Checking it out...

[Bug testsuite/49443] gcc.dg/vect/vect-peel-3.c and vect-peel-4.c fail on IA64 after testsuite change

[uweigand at gcc dot gnu.org]

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

--- Comment #7 from Ulrich Weigand  2012-08-10 
13:26:51 UTC ---
Author: uweigand
Date: Fri Aug 10 13:26:44 2012
New Revision: 190296

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

Backport from mainline
2012-07-30  Ulrich Weigand  
Richard Earnshaw  

* target.def (vector_alignment): New target hook.
* doc/tm.texi.in (TARGET_VECTOR_ALIGNMENT): Document new hook.
* doc/tm.texi: Regenerate.
* targhooks.c (default_vector_alignment): New function.
* targhooks.h (default_vector_alignment): Add prototype.
* stor-layout.c (layout_type): Use targetm.vector_alignment.
* config/arm/arm.c (arm_vector_alignment): New function.
(TARGET_VECTOR_ALIGNMENT): Define.

* tree-vect-data-refs.c (vect_update_misalignment_for_peel): Use
vector type alignment instead of size.
* tree-vect-loop-manip.c (vect_do_peeling_for_loop_bound): Use
element type size directly instead of computing it from alignment.
Fix variable naming and comment.


testsuite/ChangeLog:

Backport from mainline
2012-07-30  Ulrich Weigand  

* lib/target-supports.exp
(check_effective_target_vect_natural_alignment): New function.
* gcc.dg/align-2.c: Only run on targets with natural alignment
of vector types.
* gcc.dg/vect/slp-25.c: Adjust tests for targets without natural
alignment of vector types.

2011-12-21  Michael Zolotukhin  

* gcc.dg/vect/vect-peel-1.c: Adjust test diag-scans to fix fail on AVX.
* gcc.dg/vect/vect-peel-2.c: Ditto.

2011-06-21  Ira Rosen  

PR testsuite/49443
* gcc.dg/vect/vect-peel-3.c: Expect to fail on vect_no_align
targets.
* gcc.dg/vect/vect-peel-4.c: Likewise.

2011-06-14  Ira Rosen  

* gcc.dg/vect/vect-peel-3.c: Adjust misalignment values
for double-word vectors.
* gcc.dg/vect/vect-peel-4.c: Likewise.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/arm/arm.c
branches/gcc-4_6-branch/gcc/doc/tm.texi
branches/gcc-4_6-branch/gcc/doc/tm.texi.in
branches/gcc-4_6-branch/gcc/stor-layout.c
branches/gcc-4_6-branch/gcc/target.def
branches/gcc-4_6-branch/gcc/targhooks.c
branches/gcc-4_6-branch/gcc/targhooks.h
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/align-2.c
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/vect/slp-25.c
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/vect/vect-peel-1.c
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/vect/vect-peel-2.c
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/vect/vect-peel-3.c
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/vect/vect-peel-4.c
branches/gcc-4_6-branch/gcc/testsuite/lib/target-supports.exp
branches/gcc-4_6-branch/gcc/tree-vect-data-refs.c
branches/gcc-4_6-branch/gcc/tree-vect-loop-manip.c

[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-08-10
 Ever Confirmed|0   |1

--- Comment #7 from Richard Guenther  2012-08-10 
13:30:02 UTC ---
-fPIE does not "disable" hidden visibility - why do you think so?  Please
provide a hint on what object code you want to generate for which testcase
and why that does not work currently like you want.

[Bug middle-end/54219] [4.8 Regression] __builtin_shuffle mask reversed

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-08-10 
13:35:40 UTC ---
Author: rguenth
Date: Fri Aug 10 13:35:34 2012
New Revision: 190297

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190297
Log:
2012-08-10  Richard Guenther  

PR middle-end/54219
* fold-const.c (fold_ternary_loc): Do not reverse the mask
when canonicalizing it when folding VEC_PERM_EXPR.

* gcc.dg/torture/vector-shuffle1.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/vector-shuffle1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/54219] [4.8 Regression] __builtin_shuffle mask reversed

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #2 from Richard Guenther  2012-08-10 
13:35:40 UTC ---
Author: rguenth
Date: Fri Aug 10 13:35:34 2012
New Revision: 190297

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190297
Log:
2012-08-10  Richard Guenther  

PR middle-end/54219
* fold-const.c (fold_ternary_loc): Do not reverse the mask
when canonicalizing it when folding VEC_PERM_EXPR.

* gcc.dg/torture/vector-shuffle1.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/vector-shuffle1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

--- Comment #3 from Richard Guenther  2012-08-10 
13:36:10 UTC ---
Fixed.

[Bug middle-end/54219] [4.8 Regression] __builtin_shuffle mask reversed

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Guenther  2012-08-10 
13:36:10 UTC ---
Fixed.

[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)

[rmansfield at qnx dot com]

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

--- Comment #30 from Ryan Mansfield  2012-08-10 
13:36:42 UTC ---
Created attachment 27983
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27983
preprocessed src

Testcase that reproduces elimination_costs_in_insn ICE with -m4 -O2

[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie

[wbrana at gmail dot com]

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

--- Comment #8 from wbrana  2012-08-10 13:40:29 UTC ---
int func() {
return random();
}

int main(){
return func();
}

$ gcc-4.7.2 -O2 1.c -o 1
$ nm -CD ./1
 w __gmon_start__
 U __libc_start_main
 U random

$ gcc-4.7.2 -O2 -fPIE -pie 1.c -o 1
$ nm -CD ./1
 w _ITM_deregisterTMCloneTable
 w _ITM_registerTMCloneTable
 w _Jv_RegisterClasses
00201040 B __bss_start
 w __cxa_finalize
 w __gmon_start__
08a0 T __libc_csu_fini
08b0 T __libc_csu_init
 U __libc_start_main
00201040 D _edata
00201048 B _end
0760 T main
 U random

[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||INVALID

--- Comment #9 from Jakub Jelinek  2012-08-10 
13:43:43 UTC ---
-fvisibility=hidden is only about the visibility of the symbols you define in
the code you are compiling, for controlling what you export or not out of a
binary, shared library or PIE, you need to tell what you want or don't want to
export to the linker.  -fvisibility=hidden is a compiler option, not a linker
option.

[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie

[wbrana at gmail dot com]

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

--- Comment #10 from wbrana  2012-08-10 13:49:19 UTC 
---
How can I tell linker to not export symbols?

[Bug target/54222] New: [avr] Implement fixed-point support

[gjl at gcc dot gnu.org]

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

 Bug #: 54222
   Summary: [avr] Implement fixed-point support
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: g...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
CC: eric.wedding...@atmel.com
Target: avr


There is a draft patch from Sean, see

http://lists.gnu.org/archive/html/avr-gcc-list/2012-07/msg00030.html

[Bug c++/54180] a bug using strcat function - it depends on variable declare order, but it should not.

[lirex.software at gmail dot com]

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

Denis Kolesnik  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #9 from Denis Kolesnik  2012-08-10 
14:16:34 UTC ---
With any length(a length which is declared is of accepted range) it considered
as a variable, so it should be processed whithout dependance on
declare order.

Functions strcpy and strcat should handle so a CHAR array variable
as it is a line which ends correspondly. They even do, but not in any declare
order. They should do in in any declare order.

It is a bug anyway.

[Bug tree-optimization/54200] copyrename generates wrong debuginfo

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2012-08-10 
14:18:51 UTC ---
Guality test that fails:

/* PR tree-optimization/54200 */
/* { dg-do run } */
/* { dg-options "-g -fno-var-tracking-assignments" } */

int o __attribute__((used));

void bar (void) { o = 2; }

int __attribute__((noinline,noclone))
foo (int z, int x, int b)
{
  if (x == 1)
{
  bar ();
  return z;
}
  else
{
  int a = (x + z) + b;
  return a; /* { dg-final { gdb-test 20 "z" "3" } } */
}
}

int main ()
{
  foo (3, 2, 1);
  return 0;
}

the patch fixes it, but not at -Os (need to investigate that).

[Bug fortran/54223] New: Statement function statement with dummy arguments that are also OPTIONAL may crash in wrong calls

[roger.ferrer at bsc dot es]

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

 Bug #: 54223
   Summary: Statement function statement with dummy arguments that
are also OPTIONAL may crash in wrong calls
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: roger.fer...@bsc.es


Hi,

in the following non-conformant Fortran snippet

SUBROUTINE S(X)
IMPLICIT NONE
INTEGER, OPTIONAL :: X
INTEGER :: F, Y

! Statement function statement
F(X) = X + 1

! This call to F is wrong, it requires an actual argument here
! despite the X being OPTIONAL
Y = F()
END SUBROUTINE S

causes gfortran 4.7.1 to crash

$ gfortran -c test.f90
test.f90: In function 's':
test.f90:11:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I think that the OPTIONAL attribute is confusing gfortran when it checks
the (wrong) call to F.

Removing the OPTIONAL attribute results in gfortran properly diagnosing the
missing actual argument.

Kind regards,

[Bug target/54222] [avr] Implement fixed-point support

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-08-10
 CC||geckosenator at gmail dot
   ||com
   Target Milestone|--- |4.8.0
 Ever Confirmed|0   |1

[Bug target/54222] [avr] Implement fixed-point support

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  2012-08-10 
14:24:24 UTC ---
Created attachment 27984
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27984
Tentative patch against 4.8

libgcc/
* config/avr/lib1funcs-fixed.S: New file.
* config/avr/lib1funcs.S: Include it.  Undefine some divmodsi
after they are used.
(neg2, neg4): New macros.
* config/avr/avr-lib.h (TA, UTA): Adjust according to gcc's
avr-modes.def.
* config/avr/t-avr (LIB1ASMFUNCS): Add: _fractqqsf, _fractuqqsf,
_fracthqsf, _fractuhqsf, _fracthasf, _fractuhasf, _fractsasf,
_fractusasf, _fractsfqq, _fractsfuqq, _fractsfhq, _fractsfuhq,
_fractsfha, _fractsfsa, _mulqq3, _muluqq3, _mulhq3, _muluhq3,
_mulha3, _muluha3, _mulsa3, _mulusa3, _divqq3, _udivuqq3, _divhq3,
_udivuhq3, _divha3, _udivuha3, _divsa3, _udivusa3.

gcc/
* config/avr/predicates.md (const0_operand): Allow const_fixed.
(const_operand, const_or_immediate_operand): New.
(nonmemory_or_const_operand): New.
* config/avr/constraints.md (Ynn, Y00, Y01, Y02, Ym1, Ym2, YIJ):
New constraints.

* avr/avr-fixed.md: New file.
* avr/avr.md: Include it.
(cc): Add: minus.
(adjust_len): Add: minus, minus64, ufract, sfract.
(ALLQ, ALLH, ALLS, ALLQS, ORDERED234): New mode iterators.
(MOVMODE): Add: QQ, UQQ, HQ, UHQ, HA, UHA, SQ, USQ, SA, USA.
(MPUSH): Add: HQ, UHQ, HA, UHA, SQ, USQ, SA, USA.
(pushqi1, xload8_A, xload_8, movqi_insn, *reload_inqi, addqi3,
subqi3, ashlqi3, *ashlqi3, ashrqi3, lshrqi3, *lshrqi3, *cmpqi, 
cbranchqi4, *cpse.eq): Generalize to handle all 8-bit modes in ALLQ.
(*movhi, reload_inhi, addhi3, *addhi3, addhi3_clobber, subhi3,
ashlhi3, *ashlhi3_const, ashrhi3, *ashirhi3_const, lshrhi3,
*lshrhi3_const, *cmphi, cbranchhi4): Generalize to handle all
16-bit modes in ALLH.
(subhi3, casesi, strlenhi): Add clobber when expanding minus:HI.
(*movsi, *reload_insi, addsi3, subsi3, ashlsi3, *ashlsi3_const,
ashrsi3, *ashrhi3_const, *ashrsi3_const, lshrsi3, *lshrsi3_const,
*reversed_tstsi, *cmpsi, cbranchsi4): Generalize to handle all
32-bit modes in ALLS.
* avr-dimode.md (ALLD): New mode iterator.
(adddi3, adddi3_insn, adddi3_const_insn, subdi3, subdi3_insn,
subdi3_const_insn, cbranchdi4, compare_di2,
compare_const_di2, ashrdi3, lshrdi3, rotldi3, ashldi3_insn,
ashrdi3_insn, lshrdi3_insn, rotldi3_insn): Generalize to handle
all 64-bit modes in ALLD.
* avr-modes.def (HA, SA, DA, TA, UTA): Adjust modes.

* config/avr/avr-protos.h (avr_to_int_mode): New prototype.
(avr_out_fract, avr_out_minus, avr_out_minus64): New prototypes.
* config/avr/avr.c (TARGET_FIXED_POINT_SUPPORTED_P): Return true.
(avr_scalar_mode_supported_p): Allow if ALL_FIXED_POINT_MODE_P.
(avr_builtin_setjmp_frame_value): Use gen_subhi3 and return new
pseudo instead of gen_rtx_MINUS.
(avr_print_operand, avr_operand_rtx_cost): Handle: CONST_FIXED.
(notice_update_cc): Handle: CC_MINUS.
(output_movqi): Generalize to handle respective fixed-point modes.
(output_movhi, output_movsisf, avr_2word_insn_p): Ditto.
(avr_out_compare, avr_out_plus_1): Also handle fixed-point modes.
(avr_assemble_integer): Ditto.
(output_reload_in_const, output_reload_insisf): Ditto.
(avr_out_fract, avr_out_minus, avr_out_minus64): New functions.
(avr_out_plus64): Probe if PLUS or MINUS is shorter.
(avr_to_int_mode): New function.
(adjust_insn_length): Handle: ADJUST_LEN_SFRACT,
ADJUST_LEN_UFRACT, ADJUST_LEN_MINUS, ADJUST_LEN_MINUS64.

[Bug target/54089] [SH] Refactor shift patterns

[rmansfield at qnx dot com]

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

--- Comment #10 from Ryan Mansfield  2012-08-10 
14:24:55 UTC ---
Created attachment 27985
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27985
preprocessed src

 ./xgcc -B. -w ~/ice2.i -c -Os 
/home/ryan/ice2.i: In function 'tg_extent':
/home/ryan/ice2.i:81:2: error: unrecognizable insn:
  }
  ^
(insn 189 163 190 9 (set (reg:SI 227)
(ashift:SI (reg:SI 147 t)
(const_int 1 [0x1]))) /home/ryan/ice2.i:75 -1
 (nil))
/home/ryan/ice2.i:81:2: internal compiler error: in extract_insn, at
recog.c:2125
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug rtl-optimization/53942] [4.6/4.7/4.8 Regression] unable to find a register to spill in class 'CREG'

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #6 from Igor Zamyatin  2012-08-10 
14:40:53 UTC ---
So trunk is ok. Any plans to backport changes to 4.7 and 4.6 and close this?

[Bug debug/54205] recursive .debug_macro inclusions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Jakub Jelinek  2012-08-10 
14:47:03 UTC ---
Looks to be a --gc-sections bug in some versions of the GNU ld.
2.21.53.0.[12] seems to be buggy, 2.21.51.0.7 and 2.22.52.0.1-2 still resp.
again works just fine.

[Bug c++/54180] a bug using strcat function - it depends on variable declare order, but it should not.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #10 from Jonathan Wakely  2012-08-10 
14:51:15 UTC ---
Your bug report is useless, you have not provided the information requested at
http://gcc.gnu.org/bugs/ so it cannot be compiled or verified, and your
description of the problem is hard to follow.

The problem is that your array is too small for the data you write to the
array. This has nothing to do with the order of declarations.

You declare SQL1[150] then you call

strcat(SQL1,"select id,' ', to_char(dt_date,'DD.MM.'),' ',int_from,'
','>',' ',int_to,' ',cur_amount,' ',(select str_comment from
tbl_dic_payment_types where tbl_dic_payment_types.id=tbl_bills.int_type) as
type,' ', (select case when int_type=1 then 'business' else 'personal' end from
tbl_bills_entity_type where tbl_bills_entity_type.int_bill=tbl_bills.id) as
test2 from tbl_bills ");

That's more than 150 characters. Your program has a bug, not GCC.

[Bug target/54212] ARM: invalid instruction (vdupeq.32) generated

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Target||arm-*-*eabi
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-08-10
 CC||ramana at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  2012-08-10 
14:57:32 UTC ---
shows up on 4.7 branch but latent on trunk.This has been marked predicable ever
since the port was submitted and this is just broken.

None of the Neon instructions are conditional in ARM state, these instructions
are deprecated in IT blocks as per section  the latest edition of the ARM-ARM
(DDI0406C_B_arm_architecture_reference_manual.pdf)


regards
Ramana

[Bug target/54212] ARM: invalid instruction (vdupeq.32) generated

[ramana at gcc dot gnu.org]

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

--- Comment #2 from Ramana Radhakrishnan  2012-08-10 
14:58:54 UTC ---
(In reply to comment #1)
> shows up on 4.7 branch but latent on trunk.This has been marked predicable 
> ever
> since the port was submitted and this is just broken.
> 
> None of the Neon instructions are conditional in ARM state, these instructions
> are deprecated in IT blocks as per section  the latest edition of the ARM-ARM

Section 8.3 

> (DDI0406C_B_arm_architecture_reference_manual.pdf)
> 
> 
> regards
> Ramana

[Bug c++/54180] a bug using strcat function - it depends on variable declare order, but it should not.

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  2012-08-10 
15:04:10 UTC ---
Also, you declare SQL_date_begin[10] then fill it with 11 characters
(-MM-DD plus the numm terminator) and do the same with SQL_date_end

This is horrible, horrible code and should be deleted immediately.

(In reply to comment #5)
> it should work without problems, because of programming language syntax which
> is a standart.
> But it works so, that SQL1 partially overwrites value of SQL_date_begin and
> values are
> not such as expected.

Please check the standard before arguing about it. The C standard states that
for the functions in  "If an array is accessed beyond the end of an
object, the behavior is undefined."  

To understand undefined behaviour see:
http://en.wikipedia.org/wiki/Undefined_behavior


> I never heard, that the "C" language is outdated. The "C++" is just another
> standart which includes
> the syntax of "C".

Noone said it's outdated, what on earth are you talking about?

> So I consider it is as an GCC error which should be fixed, also because all
> standart libraries
> come along with GCC.

No, the strcat and strcpy functions come from the C library provided by your
OS, they do not come from GCC. If you still believe there is a bug then maybe
you should report it to Microsoft instead.

[Bug libstdc++/54172] [4.7/4.8 Regression] __cxa_guard_acquire thread-safety issue

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2012-08-10 
15:07:33 UTC ---
The patch looks good to me, though IMHO only the first hunk is strictly
necessary (and pretty much obvious and matches what the code was doing before
r184110).
The second hunk is just an optimisation, so supposedly it should go only to
4.8?

Can you please post it to gcc-patches and libstdc++ mailing lists where review
should happen?  Thanks.

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

[hubicka at gcc dot gnu.org]

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

--- Comment #137 from Jan Hubicka  2012-08-10 
15:06:51 UTC ---
So since the last report we managed to double WPA memory usage and compile
time...
12m wall, 42m user is needed for WPA build.
Execution times (seconds)
 phase opt and generate  :  97.34 (21%) usr   0.33 ( 1%) sys  97.70 (20%) wall 
 98900 kB ( 3%) ggc
 phase stream in : 242.70 (51%) usr   5.12 (22%) sys 247.94 (50%) wall
3174311 kB (97%) ggc
 phase stream out: 131.99 (28%) usr  17.49 (76%) sys 149.59 (30%) wall 
 0 kB ( 0%) ggc
 garbage collection  :  24.01 ( 5%) usr   0.00 ( 0%) sys  24.03 ( 5%)  ipa
lto gimple out  :  12.59 ( 3%) usr   1.07 ( 5%) sys  13.69 ( 3%) wall  
0 kB ( 0%) ggc
 ipa lto decl in : 188.50 (40%) usr   3.93 (17%) sys 192.53 (39%) wall
2083552 kB (64%) ggc
 ipa lto decl out: 113.33 (24%) usr   8.48 (37%) sys 121.84 (25%) wall 
 0 kB ( 0%) ggc
 ipa lto cgraph I/O  :   5.58 ( 1%) usr   0.67 ( 3%) sys   6.25 ( 1%) wall 
684122 kB (21%) ggc
 ipa lto decl merge  :  10.64 ( 2%) usr   0.01 ( 0%) sys  10.64 ( 2%) wall 
   291 kB ( 0%) ggc
 ipa lto cgraph merge:   9.15 ( 2%) usr   0.01 ( 0%) sys   9.17 ( 2%) wall 
 15100 kB ( 0%) ggc
 whopr wpa   :   5.80 ( 1%) usr   0.05 ( 0%) sys   5.89 ( 1%) wall 
 1 kB ( 0%) ggc
 whopr wpa I/O   :   2.19 ( 0%) usr   7.94 (35%) sys  10.19 ( 2%) 
inline heuristics   :  61.46 (13%) usr   0.31 ( 1%) sys  61.80 (12%) wall 
351753 kB (11%) ggc
 callgraph verifier  :  15.97 ( 3%) usr   0.06 ( 0%) sys  16.00 ( 3%) wall 
 0 kB ( 0%) ggc
 TOTAL : 472.0522.94   495.25   
3274649 kB

[Bug fortran/54221] Explicit private access specifier signals "unexpected defined but not used [-Wunused-function]" warning

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2012-08-10 
15:35:40 UTC ---
I think there are two issues:

a) There is a bogus warning. I think that's a middle-end bug

b) The same warning should be triggered for "PRIVATE" and for "PRIVATE ::
hello_integer"

However, the Fortran front end only checks sym->attr.access == ACCESS_PRIVATE,
which obviously doesn't get set by "PRIVATE". (See patch below.) That's a
missed-optimization issue.


Simplified example (compile with -Wall or -Wunused-function):

module mod_say_hello
private :: hello_integer
contains
subroutine say_hello()
call hello_integer(123)
end subroutine say_hello
subroutine hello_integer( a )
integer, intent(in) ::  a
print *, "Hello ", a, "!"
end subroutine hello_integer
end module mod_say_hello


Patch for issue (b):

--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1841,2 +1841,9 @@ build_function_decl (gfc_symbol * sym, bool global)

+  if (sym->attr.access == ACCESS_UNKNOWN
+  && sym->ns->proc_name && sym->ns->proc_name->attr.flavor == FL_MODULE
+  && (sym->ns->default_access == ACCESS_PRIVATE
+ || (sym->ns->default_access == ACCESS_UNKNOWN
+ && gfc_option.flag_module_private)))
+sym->attr.access = ACCESS_PRIVATE;
+
   if (!current_function_decl

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

[hubicka at gcc dot gnu.org]

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

--- Comment #138 from Jan Hubicka  2012-08-10 
15:35:44 UTC ---
Actually not, I looked up wrong report. The last report in comment #121 shows:
TOTAL : 616.4322.26   651.79   
2165706 kB

So we actually got noticeably faster, but need more memory. 1GB of GGC space,
but a lot more in top report.  I will look into mem report analysis once I am
done with merging some other cleanups/speedups.

[Bug target/54089] [SH] Refactor shift patterns

[olegendo at gcc dot gnu.org]

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

--- Comment #11 from Oleg Endo  2012-08-10 
15:40:07 UTC ---
(In reply to comment #10)
> Created attachment 27985 [details]
> preprocessed src
> 
>  ./xgcc -B. -w ~/ice2.i -c -Os 
> /home/ryan/ice2.i: In function 'tg_extent':
> /home/ryan/ice2.i:81:2: error: unrecognizable insn:
>   }
>   ^
> (insn 189 163 190 9 (set (reg:SI 227)
> (ashift:SI (reg:SI 147 t)
> (const_int 1 [0x1]))) /home/ryan/ice2.i:75 -1
>  (nil))
> /home/ryan/ice2.i:81:2: internal compiler error: in extract_insn, at
> recog.c:2125
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

Thanks for the test case!  It turns out that this is basically the same ICE as
triggered by your test case in PR 39423.  I will include this test case in the
next patch for PR 39423.

[Bug middle-end/54224] New: [4.8 Regression] Bogus -Wunused-function warning with static function

[burnus at gcc dot gnu.org]

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

 Bug #: 54224
   Summary: [4.8 Regression] Bogus -Wunused-function warning with
static function
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: koen.po...@cs.kuleuven.be
Blocks: 54221


Split off from PR 54221.

GCC prints for the following program with -Wunused-function:

test.f90:8:0: warning: ‘hello_integer’ defined but not used [-Wunused-function]
 subroutine hello_integer( a )


However, the subroutine *is* used. (Note: "hello_integer" is marked with
TREE_PUBLIC(...) = 0.)


module mod_say_hello
private :: hello_integer
contains
subroutine say_hello()
call hello_integer(123)
end subroutine say_hello

subroutine hello_integer( a )
integer, intent(in) ::  a
print *, "Hello ", a, "!"
end subroutine hello_integer
end module mod_say_hello

[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  2012-08-10 
16:53:54 UTC ---
You can use a linker version script.

http://sourceware.org/binutils/docs/ld/VERSION.html

[Bug fortran/54225] New: fortran compiler segfault processing ' print *, A(1,*) '

[armiuswu at gmail dot com]

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

 Bug #: 54225
   Summary: fortran compiler segfault processing ' print *, A(1,*)
'
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: armiu...@gmail.com


uname -a
Darwin wl-dhcp177-121.mines.edu 12.0.0 Darwin Kernel Version 12.0.0: Sun Jun 24
23:00:16 PDT 2012; root:xnu-2050.7.9~1/RELEASE_X86_64 x86_64
==

gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin11.4.0/4.7.1/lto-wrapper
Target: x86_64-apple-darwin11.4.0
Configured with: ../gcc-4.7.1/configure --enable-languages=fortran
Thread model: posix
gcc version 4.7.1 (GCC) 
===

minimal test case:


cat test.f90 
program test
implicit none
real :: A(2,3)

print *, A(1, *)

end program

=

crash errors:

gfortran test.f90 
f951: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie

[wbrana at gmail dot com]

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

--- Comment #12 from wbrana  2012-08-10 17:27:02 UTC 
---
Created attachment 27986
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27986
bash compiled with -fPIE -pie -fvisibility=hidden

[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie

[wbrana at gmail dot com]

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

--- Comment #13 from wbrana  2012-08-10 17:29:15 UTC 
---
Created attachment 27987
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27987
bash compiled with -fPIE -pie

[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie

[wbrana at gmail dot com]

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

wbrana  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |

--- Comment #14 from wbrana  2012-08-10 17:39:27 UTC 
---
-fvisibility=hidden is really disabled. Attached output from bash without
-fvisibility=hidden has 57 kB, but with -fvisibility=hidden only 11 kB.

Which compiler/linker flag except -fvisibility=hidden will make 11 kB output
from bash?

How exactly should I use linker version script to hide symbols in bash
executable or any other software?

[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID

--- Comment #15 from Jakub Jelinek  2012-08-10 
18:02:42 UTC ---
Bugzilla is not the right forum to learn how to use the linker.  Please read
its documentation.

[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie

[wbrana at gmail dot com]

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

wbrana  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |

--- Comment #16 from wbrana  2012-08-10 18:17:02 UTC 
---
-fvisibility=hidden exactly does what I need. Why it isn't enabled by default
with -fPIE -pie?

[Bug fortran/54225] fortran compiler segfault processing ' print *, A(1,*) '

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-10
 CC||burnus at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Tobias Burnus  2012-08-10 
19:02:35 UTC ---
Fails at resolve_array_ref (ar=0x161c918) at
/projects/tob/gcc-git/gcc/gcc/fortran/resolve.c:4709

4709switch (e->rank)

as e == NULL.

[Bug fortran/54223] Statement function statement with dummy arguments that are also OPTIONAL may crash in wrong calls

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org
  Known to fail||4.1.2, 4.8.0

--- Comment #1 from Tobias Burnus  2012-08-10 
19:05:10 UTC ---
The segfault is at the following line as expr==NULL:

5769  if (expr->ts.type == BT_DERIVED && expr->ts.u.derived

Backtrace:

#0  gfc_conv_expr (se=0x7fffcf40, expr=0x0) at
/projects/tob/gcc-git/gcc/gcc/fortran/trans-expr.c:5769
#1  0x00630548 in gfc_conv_statement_function (se=0x7fffd0e0,
expr=) at
/projects/tob/gcc-git/gcc/gcc/fortran/trans-expr.c:5042
#2  gfc_conv_function_expr (se=0x7fffd0e0, expr=) at
/projects/tob/gcc-git/gcc/gcc/fortran/trans-expr.c:5102
#3  0x00636314 in gfc_trans_assignment_1 (expr1=0x161c8a0,
expr2=0x161cd90, init_flag=, dealloc=)
at /projects/tob/gcc-git/gcc/gcc/fortran/trans-expr.c:7203

[Bug fortran/54225] [4.6/4.7/4.8 Regression] fortran compiler segfault processing ' print *, A(1,*) '

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.4
Summary|fortran compiler segfault   |[4.6/4.7/4.8 Regression]
   |processing ' print *,   |fortran compiler segfault
   |A(1,*) '|processing ' print *,
   ||A(1,*) '

--- Comment #2 from Tobias Burnus  2012-08-10 
19:07:00 UTC ---
GCC 4.5 has:

print *, A(1, *)
1
Error: Expected array subscript at (1)

[Bug bootstrap/54128] GCC does not bootstrap on little endian mips due to mis-compare on tree-data-ref.c

[sje at gcc dot gnu.org]

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

--- Comment #6 from Steve Ellcey  2012-08-10 20:10:56 
UTC ---
It looks like the code generation is going different (between -g and no -g)
during the IRA/reload phase.  With the cut down test case and using -O2 -g
the x.i.195r.reload file (for debug) contains:

insn=71, live_throughout: 4, 5, 6, 7, 28, 29, 79, 209, dead_or_set: 2

Insn 71 is:
(debug_insn 71 23 25 3 (var_location:SI D#1 (reg:SI 2 $2)) -1
 (nil))
(debug_insn 25 71 85 3 (var_location:DI step_c (concatn/v:DI [
(debug_expr:SI D#1)
(debug_expr:SI D#2)
])) x.i:55 -1
 (nil))

but something about this is causing IRA to think that $2 is a used psuedo
register that cannot be used for anything else so it uses $3 instead and
that is where the debug and non-debug code differs.

[Bug other/54182] -fvisibility=hidden shouldn't be disabled with -fPIE -pie

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  2012-08-11 
00:02:03 UTC ---
If it does what you need then use it.

[Bug target/54142] ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)

[gary at intrepid dot com]

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

--- Comment #7 from Gary Funck  2012-08-11 01:24:37 
UTC ---
We're still running into this build failure on PPC64, using a recent revision
of the HEAD version.  Is there additional information that is needed to help
track down the cause of the build failure?

Notice

[Lei Wang]

I have a biz worth 25 M USD, Email me at 
lwang1...@yahoo.com.cn   for more information

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

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

--- Comment #14 from Gary Funck  2012-08-11 03:22:34 
UTC ---
(In reply to comment #13)
> Is this bug obsolete now?

Comment #7 (2005-06-25) states that this is a valid bug, and near as I can tell
the current compiler still does not target 16-byte aligned (or potentially
aligned) struct's into TImode values.  Thus, I don't see any technical reason
mentioned in the subsequent comments that describe why this bug should be
marked  as obsolete.