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

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2012-08-13 
07:35:11 UTC ---
Author: jakub
Date: Mon Aug 13 07:35:03 2012
New Revision: 190338

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190338
Log:
Backported from trunk
2012-07-19  Jakub Jelinek  

PR rtl-optimization/53942
* function.c (assign_parm_setup_reg): Avoid zero/sign extension
directly from likely spilled non-fixed hard registers, move them
to pseudo first.

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

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr53942.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/function.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/54237] [C++11] Make more tuple-related functions constexpr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||bkoz at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #1 from Jonathan Wakely  2012-08-13 
08:14:00 UTC ---
That does seem possible.  Benjamin wrote
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3231.html so let's CC
him.

[Bug tree-optimization/21485] [4.6/4.7/4.8 Regression] missed load PRE, PRE makes i?86 suck

[wbrana at gmail dot com]

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

--- Comment #53 from wbrana  2012-08-13 08:26:13 UTC 
---
It seems it was improved.

4.8 20120806
NUMERIC SORT:  1543.7  :  39.59  :  13.00
4.8 20120813
NUMERIC SORT:  2007.8  :  51.49  :  16.91

[Bug debug/51358] incorrect/missing location for function arg, -O0, without VTA

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2012-08-13 
08:55:05 UTC ---
(In reply to comment #4)
> It would not be helpful, systemtap would then see no data (just not wrong
> data).
> 
> Also at that time location list will need to be used and currently GDB when it
> sees any location list it thinks it no longer needs to skip the prologue.
> OTOH GDB could look at -grecord-gcc-switches first which it currently does not
> so I should just finally implement -grecord-gcc-switches in GDB in such case.

I think seeing wrong data, thus, wrong-debug is never superior over "no debug
info / no data".

[Bug target/54232] For x86 PIC code, ebx should be spillable

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-13
Version|unknown |4.8.0
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2012-08-13 
08:57:15 UTC ---
I think the GOT is introduced too late to do any fancy ananlysis on whether
we need it or not.  I also think that for outgoing function calls the ABI
relies on a properly setup GOT, even for those that bind locally and thus
do not go through the PLT.

[Bug lto/54231] LTO generates code for the wrong CPU if different options used

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2012-08-13 
08:59:18 UTC ---
If you do something like

 gcc -c t1.c -mavx -flto
 gcc -c t2.c -msse2 -flto
 gcc t1.o t2.o -flto

then the link step will use -mavx -msse2, that is, target options are
concatenated.

[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 #7 from Richard Guenther  2012-08-13 
09:29:33 UTC ---
Author: rguenth
Date: Mon Aug 13 09:29:28 2012
New Revision: 190339

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

PR tree-optimization/54200
* tree-ssa-copyrename.c (rename_ssa_copies): Do not add
PHI results to another partition if not all PHI arguments
have the same partition.

* gcc.dg/guality/pr54200.c: New testcase.
* gcc.dg/tree-ssa/slsr-8.c: Adjust.

Added:
trunk/gcc/testsuite/gcc.dg/guality/pr54200.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/slsr-8.c
trunk/gcc/tree-ssa-copyrename.c

[Bug lto/54231] LTO generates code for the wrong CPU if different options used

[thiago at kde dot org]

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

--- Comment #9 from Thiago Macieira  2012-08-13 09:44:51 
UTC ---
(In reply to comment #8)
> If you do something like
> 
>  gcc -c t1.c -mavx -flto
>  gcc -c t2.c -msse2 -flto
>  gcc t1.o t2.o -flto
> 
> then the link step will use -mavx -msse2, that is, target options are
> concatenated.

Indeed.

What I'm asking for is that each source file be compiled with its own target
options. I realise this is a request for enhancement, though.

[Bug lto/54231] LTO generates code for the wrong CPU if different options used

[thiago at kde dot org]

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

--- Comment #10 from Thiago Macieira  2012-08-13 
09:53:32 UTC ---
Another test:

$ cat main_avx.c
#define BZERO bzero_avx
#pragma GCC target ("avx")
#include "main.c"

$ cat main_sse2.c
#define BZERO bzero_sse2
#pragma GCC target ("sse2")
#include "main.c"

$ cat main.c
#include 

void BZERO(char *ptr, size_t count)
{
__m128i zero = _mm_set1_epi8(0);
while (count--) {
_mm_stream_si128((__m128i*)ptr, zero);
ptr += 16;
}
}

$ gcc -flto -O2 -shared -o libtest.so main_avx.c main_sse2.c
$ objdump -Cdr --no-show-raw-insn libtest.so
[...]

0650 :
 650:   test   %rsi,%rsi
 653:   pxor   %xmm0,%xmm0
 657:   je 66e 
 659:   nopl   0x0(%rax)
 660:   movntdq %xmm0,(%rdi)
 664:   add$0x10,%rdi
 668:   sub$0x1,%rsi
 66c:   jne660 
 66e:   repz retq 

0670 :
 670:   test   %rsi,%rsi
 673:   pxor   %xmm0,%xmm0
 677:   je 68e 
 679:   nopl   0x0(%rax)
 680:   movntdq %xmm0,(%rdi)
 684:   add$0x10,%rdi
 688:   sub$0x1,%rsi
 68c:   jne680 
 68e:   repz retq

[Bug lto/54231] LTO generates code for the wrong CPU if different options used

[thiago at kde dot org]

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

--- Comment #11 from Thiago Macieira  2012-08-13 
10:12:48 UTC ---
Attaching __attribute__((target("xxx"))) to the function does help.

It generates the following with the my_bzero function from comment 2:

02e0 :
 2e0:   test   %rsi,%rsi
 2e3:   vpxor  %xmm0,%xmm0,%xmm0
 2e7:   je 2fe 
 2e9:   nopl   0x0(%rax)
 2f0:   vmovntdq %xmm0,(%rdi)
 2f4:   add$0x10,%rdi
 2f8:   sub$0x1,%rsi
 2fc:   jne2f0 
 2fe:   repz retq 

0300 :
 300:   mov0x200171(%rip),%rax# 200478 
 307:   mov(%rax),%eax
 309:   test   %eax,%eax
 30b:   jne330 
 30d:   test   %rsi,%rsi
 310:   pxor   %xmm0,%xmm0
 314:   je 332 
 316:   nopw   %cs:0x0(%rax,%rax,1)
 320:   movntdq %xmm0,(%rdi)
 324:   add$0x10,%rdi
 328:   sub$0x1,%rsi
 32c:   jne320 
 32e:   repz retq 
 330:   jmp2e0 
 332:   repz retq 


This workaround might be useful for me in a few places where the code inlining
provided by LTO was desired (even though, in this example, the AVX variant is
exactly what it would be if no LTO had been used). But it won't work without
major changes to the code if I have 400+ functions in a file, plus possibly
inlines from headers, to be compiled.

[Bug target/54239] New: Not able to generate "prefetch" (prefetch read) instruction using -m3dnow or -mprfchw

[venkataramanan.kumar at amd dot com]

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

 Bug #: 54239
   Summary: Not able to generate "prefetch" (prefetch read)
instruction using -m3dnow or -mprfchw
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: venkataramanan.ku...@amd.com


Hi all, 

The following are classification of prefetch instructions.

1) Prefetch instructions included by 3DNOW ISA/ new PRFCHW ISA (checked against
cpuid function 0x8001 bit 8 of ecx register)

prefetch   
perfetchw  

2) Prefetch instructions included by SSE ISA

prefetcht0 
prefetcht1 
prefetcht2 
prefetchnta 

I am trying to generate 3DNOW/PRFCHW prefetch instructions

#include 
void *p;

void
prefetchw__test (void)
{
__builtin_prefetch (p, 0, 0); //<== expecting prefetch &p
__builtin_prefetch (p, 1, 0); //<== expecting prefetchw &p
}

For the following set of options (enabled with -m3dnow and -mprfchw) the
expected instruction for prefetch read (__builtin_prefetch (p, 0, 0)) is not
generated.
1. gcc test.c -m3dnow -S
2. gcc test.c -m3dnow -mno-sse -mno-mmx -S
3. gcc test.c -S -mprfchw
4. gcc test.c -S -mprfchw -mno-sse -mno-mmx

At least for k6-2 architecture, I am not expecting the instruction prefetchnt2
to be listed with -mprfchw. (-march=k6-2 -m32 -mprfchw)

Am I missing something?

[Bug rtl-optimization/53495] [4.8 Regression] segmentation fault

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from Jakub Jelinek  2012-08-13 
10:36:32 UTC ---
Created attachment 28003
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28003
gcc48-pr53495.patch

The problem is that find_moveable_pseudos creates some extra pseudos/def_insns,
but then trivially_dead_insns is called by ira and deletes them (because they
were feeding trivially dead insns only).  Then move_unallocated_pseudos is
called and expects to be able to tweak all the insns find_moveable_pseudos
created.  The attached untested patch fixes that.

[Bug target/54049] cr16: ICE: in gen_rtx_SUBREG with -O1

[stefan at astylos dot dk]

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

Stefan Sørensen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Stefan Sørensen  2012-08-13 
10:51:19 UTC ---
Works in 4.8-20120812 snapshot, closing.

[Bug middle-end/53411] [4.8 Regression] ICE in move_unallocated_pseudos

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #5 from Jakub Jelinek  2012-08-13 
10:55:39 UTC ---
If we want to rely on no dead insns before IRA, it would make no point calling
delete_trivially_dead_insns in it.

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

[Bug rtl-optimization/53495] [4.8 Regression] segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2012-08-13 
10:55:39 UTC ---
*** Bug 53411 has been marked as a duplicate of this bug. ***

[Bug middle-end/53411] [4.8 Regression] ICE in move_unallocated_pseudos

[bernds at gcc dot gnu.org]

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

--- Comment #6 from Bernd Schmidt  2012-08-13 
11:07:27 UTC ---
If the call to delete_trivially_dead_insns is supposed to eliminate only
pre-existing dead insns, then just moving it to the beginning of IRA fixes this
bug.

[Bug middle-end/53411] [4.8 Regression] ICE in move_unallocated_pseudos

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  2012-08-13 
11:24:31 UTC ---
ira itself also removes something, e.g. in
  rebuild_jump_labels (get_insns ());
  if (purge_all_dead_edges ())
delete_unreachable_blocks ();
so I wouldn't move that
  if (delete_trivially_dead_insns (get_insns (), max_reg_num ()))
df_analyze ();
too early in the function.  But perhaps it could be moved before the
  /* It is not worth to do such improvement when we use a simple
 allocation because of -O0 usage or because the function is too
 big.  */
  if (ira_conflicts_p)
find_moveable_pseudos ();
hunk.  Vlad, what do you think?  There is still ira_flattening that tweaks the
RTL in between, dunno if it could create trivially dead insns or not.  Moving
d_t_d_i call before f_m_p call certainly fixes both of the testcases too,
haven't bootstrapped/regtested either of the patches yet.

[Bug libstdc++/54112] including complex.h and complex fails in C++03

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  2012-08-13 11:55:04 
UTC ---
Author: glisse
Date: Mon Aug 13 11:55:00 2012
New Revision: 190340

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190340
Log:
2012-08-13  Marc Glisse  

PR libstdc++/54112
* include/c_compatibility/complex.h: Undefine complex, always
include system's complex.h if present.
* testsuite/26_numerics/complex/c99.cc: New testcase.
* testsuite/17_intro/headers/c++1998/complex.cc: Likewise.
* doc/xml/manual/numerics.xml: Document it.

Added:
trunk/libstdc++-v3/testsuite/17_intro/headers/c++1998/complex.cc   (with
props)
trunk/libstdc++-v3/testsuite/26_numerics/complex/c99.cc   (with props)
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/xml/manual/numerics.xml
trunk/libstdc++-v3/include/c_compatibility/complex.h

Propchange: trunk/libstdc++-v3/testsuite/17_intro/headers/c++1998/complex.cc
('svn:eol-style' added)

Propchange: trunk/libstdc++-v3/testsuite/17_intro/headers/c++1998/complex.cc
('svn:keywords' added)

Propchange: trunk/libstdc++-v3/testsuite/26_numerics/complex/c99.cc
('svn:eol-style' added)

Propchange: trunk/libstdc++-v3/testsuite/26_numerics/complex/c99.cc
('svn:keywords' added)

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

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Richard Guenther  2012-08-13 
11:55:26 UTC ---
Fixed as far as I am concerned.

[Bug libstdc++/54112] including complex.h and complex fails in C++03

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #5 from Marc Glisse  2012-08-13 11:58:29 
UTC ---
Fixed.

[Bug lto/54231] LTO generates code for the wrong CPU if different options used

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther  2012-08-13 
11:58:33 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > If you do something like
> > 
> >  gcc -c t1.c -mavx -flto
> >  gcc -c t2.c -msse2 -flto
> >  gcc t1.o t2.o -flto
> > 
> > then the link step will use -mavx -msse2, that is, target options are
> > concatenated.
> 
> Indeed.
> 
> What I'm asking for is that each source file be compiled with its own target
> options. I realise this is a request for enhancement, though.

Yes, there are similar option-related bugs for this.  Note somebody needs
to sit down and document the desired semantics of combining translation
units T1 and T2, compiled with different options OP1 and OP2, at link-time with
options OP3.  Desired semantics including which cross-file optimizations
(inlining?) are possible.

[Bug lto/54231] LTO generates code for the wrong CPU if different options used

[thiago at kde dot org]

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

--- Comment #13 from Thiago Macieira  2012-08-13 
12:13:40 UTC ---
(In reply to comment #12)
> Yes, there are similar option-related bugs for this.  Note somebody needs
> to sit down and document the desired semantics of combining translation
> units T1 and T2, compiled with different options OP1 and OP2, at link-time 
> with
> options OP3.  Desired semantics including which cross-file optimizations
> (inlining?) are possible.

>From my (admittedly restrict) point of view, inlining should be possible,
provided the following conditions:
 - when inlining a function with a "lower" optimisation / target setting, apply
the outer scope's setting to the inlined code
 - when inlining a function with a higher target requirement, inlining should
be done only in the sense of partial function splitting, prologue, epilogues,
constant propagation, etc.

In the case that I pasted, for example, I'd like GCC to realise that it has
already tested if the counter variable is 0, then forego that test in the
inlined, inner function.

Worst case scenario, simply forego inlining completely. Then the code would
simply be no worse than the non-LTO case.

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

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #9 from Igor Zamyatin  2012-08-13 
12:13:54 UTC ---
I see following in report for x86:

FAIL: gcc.dg/guality/pr54200.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 20 z == 3

[Bug tree-optimization/54240] New: Routine hoist_adjacent_loads does not work properly after r189366

[ysrumyan at gmail dot com]

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

 Bug #: 54240
   Summary: Routine hoist_adjacent_loads does not work properly
after r189366
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ysrum...@gmail.com


This regression can be seen in the attached simple test-case - cmov conversion
is not happened. The fix is evident:

--- tree-ssa-phiopt.c   (revision 190151)
+++ tree-ssa-phiopt.c   (working copy)
@@ -1864,7 +1864,7 @@

   /* Check the mode of the arguments to be sure a conditional move
 can be generated for it.  */
-  if (!optab_handler (cmov_optab, TYPE_MODE (TREE_TYPE (arg1
+  if (optab_handler (cmov_optab, TYPE_MODE (TREE_TYPE (arg1)) ==
CODE_FOR_nothing))
continue;

   /* Both statements must be assignments whose RHS is a COMPONENT_REF.  */

You can see this regression on any platform supporting conditional moves (I
tested it on x86).

[Bug tree-optimization/54241] New: Routine hoist_adjacent_loads does not work properly after r189366

[ysrumyan at gmail dot com]

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

 Bug #: 54241
   Summary: Routine hoist_adjacent_loads does not work properly
after r189366
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ysrum...@gmail.com


This regression can be seen in the attached simple test-case - cmov conversion
is not happened. The fix is evident:

--- tree-ssa-phiopt.c   (revision 190151)
+++ tree-ssa-phiopt.c   (working copy)
@@ -1864,7 +1864,7 @@

   /* Check the mode of the arguments to be sure a conditional move
 can be generated for it.  */
-  if (!optab_handler (cmov_optab, TYPE_MODE (TREE_TYPE (arg1
+  if (optab_handler (cmov_optab, TYPE_MODE (TREE_TYPE (arg1)) ==
CODE_FOR_nothing))
continue;

   /* Both statements must be assignments whose RHS is a COMPONENT_REF.  */

You can see this regression on any platform supporting conditional moves (I
tested it on x86).

[Bug target/54239] Not able to generate "prefetch" (prefetch read) instruction using -m3dnow or -mprfchw

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2012-08-13 
12:31:52 UTC ---
Both in 4.7 (which is before the prfchw changes) and 4.8 with -m32 -m3dnow and
-m32 -m3dnow -mno-sse I get prefetch + prefetchw insn, which looks ok to me.
-mno-mmx I think disables 3dnow too, so you get no prefetch insns in that case
(which is also fine).  -mprfchw implies the SSE prefetches and PRFCHW CPUID
0x8001 ecx bit 8 doesn't imply the prefetch insn, just prefetchw, so it is
correct that with -m32 -mprfchw prefetchnta + prefetchw is generated.
So, where exactly do you see a bug?

[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 #10 from Richard Guenther  2012-08-13 
12:35:32 UTC ---
(In reply to comment #9)
> I see following in report for x86:
> 
> FAIL: gcc.dg/guality/pr54200.c  -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects  line 20 z == 3

That's what I said in the commit mail.

[Bug tree-optimization/54241] Routine hoist_adjacent_loads does not work properly after r189366

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Richard Guenther  2012-08-13 
12:39:10 UTC ---
.

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

[Bug tree-optimization/54241] Routine hoist_adjacent_loads does not work properly after r189366

[michael.v.zolotukhin at gmail dot com]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Richard Guenther  2012-08-13 
12:39:10 UTC ---
.

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

--- Comment #2 from Michael Zolotukhin  
2012-08-13 12:39:23 UTC ---
Created attachment 28004
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28004
test-case confirming the issue

[Bug tree-optimization/54240] Routine hoist_adjacent_loads does not work properly after r189366

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2012-08-13 
12:39:10 UTC ---
*** Bug 54241 has been marked as a duplicate of this bug. ***

[Bug c/53968] integer undefined behaviors in GCC

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2012-08-13 
12:40:04 UTC ---
Author: jakub
Date: Mon Aug 13 12:39:54 2012
New Revision: 190342

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190342
Log:
PR c/53968
* tree.c (integer_pow2p): Avoid undefined signed overflows.
* simplify-rtx.c (neg_const_int): Likewise.
* expr.c (fixup_args_size_notes): Likewise.
* stor-layout.c (set_min_and_max_values_for_integral_type): Likewise.
* double-int.c (mul_double_wide_with_sign): Likewise.
(double_int_mask): Likewise.
* tree-ssa-loop-ivopts.c (get_address_cost): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/double-int.c
trunk/gcc/expr.c
trunk/gcc/simplify-rtx.c
trunk/gcc/stor-layout.c
trunk/gcc/tree-ssa-loop-ivopts.c
trunk/gcc/tree.c

[Bug c/53968] integer undefined behaviors in GCC

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-13
 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from Jakub Jelinek  2012-08-13 
12:41:06 UTC ---
Haven't reproduced the diagnostic.c failure, and leaving the ipa hunk to Honza.

[Bug tree-optimization/54240] Routine hoist_adjacent_loads does not work properly after r189366

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #2 from Richard Guenther  2012-08-13 
12:41:10 UTC ---
Confirmed.  William?  Why don't we see any failed testcases?

[Bug middle-end/54201] XMM constant duplicated

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 AssignedTo|rguenth at gcc dot gnu.org  |unassigned at gcc dot
   ||gnu.org

--- Comment #6 from Richard Guenther  2012-08-13 
12:42:47 UTC ---
Not working on it.

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

[izamyatin at gmail dot com]

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

--- Comment #11 from Igor Zamyatin  2012-08-13 
12:46:48 UTC ---
Right! Sorry for the noise...

[Bug middle-end/54242] New: [4.8 Regression] Testsuite failures

[hjl.tools at gmail dot com]

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

 Bug #: 54242
   Summary: [4.8 Regression] Testsuite failures
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: rgue...@gcc.gnu.org


On Linux/x86-64, revision 190339:

http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00316.html

caused:

FAIL: gcc.dg/guality/pr54200.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 20 z == 3
FAIL: gcc.dg/guality/pr54200.c  -Os  line 20 z == 3
FAIL: gcc.target/i386/pad-10.c scan-assembler-not nop

[Bug driver/54210] gcc unable to detect -mprfchw flag in bulldozer machines

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2012-08-13 
13:21:52 UTC ---
Author: jakub
Date: Mon Aug 13 13:21:41 2012
New Revision: 190345

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190345
Log:
PR driver/54210
* config/i386/driver-i386.c (host_detect_local_cpu): Test bit_PRFCHW
bit of CPUID 0x8001 %ecx instead of CPUID 7 %ecx.
* config/i386/cpuid.h (bits_PRFCHW): Move definition to CPUID
0x8001 %ecx flags.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/cpuid.h
trunk/gcc/config/i386/driver-i386.c

[Bug middle-end/54242] [4.8 Regression] Testsuite failures

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-13
   Target Milestone|--- |4.8.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-08-13 
13:27:45 UTC ---
It "caused" only

FAIL: gcc.target/i386/pad-10.c scan-assembler-not nop

as said in the commit mail.  The other FAILs are prefered over dozen
new XPASSes.  pad-10.c is testing something that didn't really work before.

[Bug target/54239] Not able to generate "prefetch" (prefetch read) instruction using -m3dnow or -mprfchw

[venkataramanan.kumar at amd dot com]

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

--- Comment #2 from Venkataramanan  
2012-08-13 13:51:08 UTC ---
(In reply to comment #1)
> Both in 4.7 (which is before the prfchw changes) and 4.8 with -m32 -m3dnow and
> -m32 -m3dnow -mno-sse I get prefetch + prefetchw insn, which looks ok to me.
> -mno-mmx I think disables 3dnow too, so you get no prefetch insns in that case
> (which is also fine).  -mprfchw implies the SSE prefetches and PRFCHW CPUID
> 0x8001 ecx bit 8 doesn't imply the prefetch insn, just prefetchw, so it is
> correct that with -m32 -mprfchw prefetchnta + prefetchw is generated.
> So, where exactly do you see a bug?

Hi Jakub,

> -mprfchw implies the SSE prefetches and PRFCHW CPUID
> 0x8001 ecx bit 8 doesn't imply the prefetch insn, just prefetchw, so it is
> correct that with -m32 -mprfchw prefetchnta + prefetchw is generated.
> So, where exactly do you see a bug

As per AMD cpuid manual, 0x8001 ecx bit 8 impiles both prefetch and
prefetchw.  

http://blogs.amd.com/developer/2010/08/18/3dnow-deprecated/

[Bug target/54239] Not able to generate "prefetch" (prefetch read) instruction using -m3dnow or -mprfchw

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2012-08-13 
13:58:40 UTC ---
But the Intel manual AFAIK doesn't talk about prefetch insn.
So, the -mprfchw switch needs to control solely the prefetchw instruction,
and there might be a different one that controls the prefetch insn.  In
driver-i386.c you could enable -mprfchw vs. ?-mprfch -mpfrchw? based on whether
the CPU is Intel or AMD or something, but if there are CPUs that don't have
both insns, it needs to be enabled independently.  Areg?

[Bug target/54232] For x86 PIC code, ebx should be spillable

[bugdal at aerifal dot cx]

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

--- Comment #3 from Rich Felker  2012-08-13 13:59:17 
UTC ---
> I think the GOT is introduced too late to do any fancy ananlysis
> on whether we need it or not.

This may be true, but if so, it's a highly suboptimal design that's hurting
performance badly. 30% on the cryptographic code I looked at, and from working
on FFmpeg in the past, I remember quite a few cases where PIC was hurting
performance by significant measurable amounts like that too. If there's any way
the changes I describe could be targeted even just in the long term, I think it
would make a big difference for a lot of software.

> I also think that for outgoing function calls the ABI
> relies on a properly setup GOT, even for those that bind
> locally and thus do not go through the PLT.

The extern function call ABI on x86 does not allow the caller to depend on EBX
containing the GOT address. This is because the callee has no way of knowing
whether it was called by the same DSO it resides in. If not, the GOT address
will be invalid for it.

For static functions whose addresses never leak out of the translation unit
they're defined in, the calling convention is up to GCC. Ideally it would
assume the GOT register is already loaded in such functions (as long as all the
callees use the GOT), but in reality it rarely does. This is a separate code
generation QoI implementation that should perhaps be addressed as its own bug.

[Bug target/54239] Not able to generate "prefetch" (prefetch read) instruction using -m3dnow or -mprfchw

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2012-08-13 
14:00:55 UTC ---
BTW, why do you care about the prefetch insn?  Isn't it obsoleted by the SSE
ISA prefetches anyway (unlike prefetchw)?

[Bug libstdc++/54185] condition_variable not properly destructed

[d.adler.s at gmail dot com]

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

--- Comment #8 from David Adler  2012-08-13 
14:09:16 UTC ---
Created attachment 28005
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28005
proposed changelog

I wasn't sure about the testcase file name, so I just guessed.

[Bug tree-optimization/54240] Routine hoist_adjacent_loads does not work properly after r189366

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from William J. Schmidt  2012-08-13 
14:14:59 UTC ---
Odd, I don't know.  I'll have to go back and look at the tests when I get a
moment and investigate that.  Peculiar.

[Bug tree-optimization/54240] Routine hoist_adjacent_loads does not work properly after r189366

[michael.v.zolotukhin at gmail dot com]

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

--- Comment #3 from William J. Schmidt  2012-08-13 
14:14:59 UTC ---
Odd, I don't know.  I'll have to go back and look at the tests when I get a
moment and investigate that.  Peculiar.

--- Comment #4 from Michael Zolotukhin  
2012-08-13 14:15:08 UTC ---
Created attachment 28006
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28006
test-case confirming the issue

[Bug tree-optimization/54240] Routine hoist_adjacent_loads does not work properly after r189366

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from William J. Schmidt  2012-08-13 
14:24:48 UTC ---
Well, I'm embarrassed.  The tests I wrote for this functionality never got into
the test suite -- I apparently forgot to submit them with the patch -- and I
can't find them anymore.  I'll write some new ones soon.  Apologies for the
oversight. :(

[Bug target/54239] Not able to generate "prefetch" (prefetch read) instruction using -m3dnow or -mprfchw

[venkataramanan.kumar at amd dot com]

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

--- Comment #5 from Venkataramanan  
2012-08-13 14:33:14 UTC ---
(In reply to comment #4)
> BTW, why do you care about the prefetch insn?  Isn't it obsoleted by the SSE
> ISA prefetches anyway (unlike prefetchw)?


Hi Jakub, as for as fam15H processors what I know is they are exactly same.
Yes I can use -mprfchw and generate prefecthw instruction and use prefetchts
instead of prefetch instruction.

But there is a mention in SWOG guide of amdfam15 that their functionalities
could change in future. 

(Snip)
AMD Family 15h processors implement the PREFETCHT0, PREFETCHT1, and PREFETCHT2
instructions in exactly the same way as the PREFETCH instruction. That is, the
data is brought into the L1 data cache. This functionality could change in
future implementations of the AMD Family 15h
processor
(Snip)

[Bug libstdc++/54185] condition_variable not properly destructed

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  2012-08-13 
14:35:21 UTC ---
Perfect - thanks. I'll get it committed tonight.

[Bug fortran/54243] New: f951: internal compiler error: Segmentation fault (trying to compile errorneous code)

[slayoo at staszic dot waw.pl]

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

 Bug #: 54243
   Summary: f951: internal compiler error: Segmentation fault
(trying to compile errorneous code)
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sla...@staszic.waw.pl


With Deabian's gcc-snapshot gfortran (4.8.0 20120714) trying to compile to code
below:



module aqq_m
  type :: aqq_t
contains
procedure :: aqq_init
  end type 
  contains
  subroutine aqq_init(this)
class(aqq_t) :: this
  end subroutine
end module
program bug2
  use aqq_m
  class(aqq_t) :: aqq
  call aqq%aqq_init
end program



I get:



$ /usr/lib/gcc-snapshot/bin/gfortran -std=f2008 -ffree-form  bug2.f
bug2.f:24.21:

  class(aqq_t) :: aqq
 1   
Error: CLASS variable 'aqq' at (1) must be dummy, allocatable or pointer
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.



HTH,
Sylwester

[Bug fortran/54244] New: f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:210

[slayoo at staszic dot waw.pl]

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

 Bug #: 54244
   Summary: f951: internal compiler error: in
gfc_add_component_ref, at fortran/class.c:210
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sla...@staszic.waw.pl


With Deabian's gcc-snapshot gfortran (4.8.0 20120714) trying to compile to code
below:



module aqq_m
  type :: arr_t
  end type
  type :: aqq_t
class(arr_t), allocatable :: psi(:)
contains
procedure :: aqq_init
  end type 
  contains
  subroutine aqq_init(this)
class(aqq_t) :: this
  end subroutine
end module
program bug1
  use aqq_m
  class(aqq_t) :: aqq
  call aqq%aqq_init
end program



I get:



$ /usr/lib/gcc-snapshot/bin/gfortran -std=f2008 -ffree-form  bug1.f 
bug1.f:32.21:

  class(aqq_t) :: aqq
 1   
Error: CLASS variable 'aqq' at (1) must be dummy, allocatable or pointer
bug1.f:33.10:

  call aqq%aqq_init
  1
Error: Type mismatch in argument 'this' at (1); passed
CLASS(__class_aqq_m_Arr_t_1_0a) to CLASS(aqq_t)
f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:210
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.



HTH,
Sylwester

[Bug c++/53836] [4.7/4.8 Regression] ICE: unexpected expression of kind template_parm_index

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-13
 CC||hjl.tools at gmail dot com
Summary|ICE: unexpected expression  |[4.7/4.8 Regression] ICE:
   |of kind template_parm_index |unexpected expression of
   ||kind template_parm_index
 Ever Confirmed|0   |1

--- Comment #3 from Paolo Carlini  2012-08-13 
15:26:57 UTC ---
Mainline ICEs for me (190348) and indeed looks like a regression.

HJ, can you help figuring out when we regressed?

[Bug fortran/54243] [OOP] ICE (segfault) in gfc_type_compatible for invalid BT_CLASS

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||error-recovery,
   ||ice-on-invalid-code
   Last reconfirmed||2012-08-13
 CC||burnus at gcc dot gnu.org,
   ||janus at gcc dot gnu.org
 Ever Confirmed|0   |1
Summary|f951: internal compiler |[OOP] ICE (segfault) in
   |error: Segmentation fault   |gfc_type_compatible for
   |(trying to compile  |invalid BT_CLASS
   |errorneous code)|

--- Comment #1 from Tobias Burnus  2012-08-13 
15:35:11 UTC ---
Segfaults in

4837gfc_type_compatible (gfc_typespec *ts1, gfc_typespec *ts2)
4838{
4839  bool is_class1 = (ts1->type == BT_CLASS);
4840  bool is_class2 = (ts2->type == BT_CLASS);
...
4853  else if (is_class1 && is_class2)
4854return gfc_type_is_extension_of
(ts1->u.derived->components->ts.u.derived,
4855
ts2->u.derived->components->ts.u.derived);

The problem is that ts2->u.derived->components == NULL.

[Bug fortran/54244] [OOP] ICE in gfc_add_component_ref, at fortran/class.c:210

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||error-recovery,
   ||ice-on-invalid-code
   Last reconfirmed||2012-08-13
 CC||burnus at gcc dot gnu.org,
   ||janus at gcc dot gnu.org
 Ever Confirmed|0   |1
Summary|f951: internal compiler |[OOP] ICE in
   |error: in   |gfc_add_component_ref, at
   |gfc_add_component_ref, at   |fortran/class.c:210
   |fortran/class.c:210 |

--- Comment #1 from Tobias Burnus  2012-08-13 
15:35:25 UTC ---
Fails in gfc_add_component_ref at
213   gcc_assert((*tail)->u.c.component);

Here, (*tail)->u.c.component == NULL and tail->u.c.sym->name == "aqq_t".

Called via resolve_typebound_subroutine.

[Bug tree-optimization/54240] Routine hoist_adjacent_loads does not work properly after r189366

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-08-13
 AssignedTo|unassigned at gcc dot   |wschmidt at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #6 from William J. Schmidt  2012-08-13 
15:46:31 UTC ---
Mine.

[Bug middle-end/53823] [4.8 Regression] FAIL: gcc.c-torture/execute/930921-1.c execution at -O0 and -O1

[rth at gcc dot gnu.org]

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

--- Comment #23 from Richard Henderson  2012-08-13 
15:51:37 UTC ---
On 08/12/2012 07:30 AM, danglin at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823
> 
> --- Comment #22 from John David Anglin  
> 2012-08-12 14:30:12 UTC ---
> Created attachment 27994
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27994

Ok.


r~

[Bug tree-optimization/54245] New: [4.8 regression] incorrect optimisation

[mans at mansr dot com]

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

 Bug #: 54245
   Summary: [4.8 regression] incorrect optimisation
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@mansr.com


Created attachment 28007
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28007
Test case

Since r190220 the attached test is compiled incorrectly at -O1 and higher.

[Bug target/54246] New: Bytemark FOURIER 54% slower in X32 chroot

[wbrana at gmail dot com]

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

 Bug #: 54246
   Summary: Bytemark FOURIER 54% slower in X32 chroot
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wbr...@gmail.com


http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz

compiled on 64-bit system with glibc 2.14.1 and run in X32 chroot
FOURIER :   36275  :  41.26  :  23.17
compiled in X32 chroot with glibc 2.16 and run in X32 chroot
FOURIER :   16574  :  18.85  :  10.59
both were compiled with same CFLAGS
-static -m64 -ggdb -Wall -O3 -funroll-loops -g0 -march=core2 -mfpmath=sse
-fomit-frame-pointer -ffast-math -mssse3 -fno-PIE -fno-exceptions
-fno-stack-protector

[Bug tree-optimization/54245] [4.8 regression] incorrect optimisation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Target Milestone|--- |4.8.0

--- Comment #1 from Jakub Jelinek  2012-08-13 
17:19:40 UTC ---
Confirmed.  slsr replaces:
  D.2219_3 = *row_2(D);
  D.2220_4 = (int) D.2219_3;
  a1_5 = D.2220_4 * 22725;
  D._6 = MEM[(short int *)row_2(D) + 4B];
  D.2223_7 = (int) D._6;
  D.2224_8 = D.2223_7 * 21407;
  a0_9 = D.2224_8 + a1_5;
  D.2225_10 = D.2223_7 * 8867;
- a1_11 = a1_5 + D.2225_10;
+ slsr.4_25 = D._6 * 12540;
+ slsr.5_26 = (int) slsr.4_25;
+ a1_11 = a0_9 - slsr.5_26;

The multiplication is newly performed in short int, supposedly that is the
problem here.  Anyway, while the number of multiplications in the end is the
same, with slsr the code sequence is also 3 insns/4 bytes longer on x86_64.

[Bug target/54239] Not able to generate "prefetch" (prefetch read) instruction using -m3dnow or -mprfchw

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #6 from Uros Bizjak  2012-08-13 17:32:21 
UTC ---
(In reply to comment #5)
> > BTW, why do you care about the prefetch insn?  Isn't it obsoleted by the SSE
> > ISA prefetches anyway (unlike prefetchw)?
> 
> Hi Jakub, as for as fam15H processors what I know is they are exactly same.
> Yes I can use -mprfchw and generate prefecthw instruction and use prefetchts
> instead of prefetch instruction.

The reason is described in the comment in i386.md:

  /* Use 3dNOW prefetch in case we are asking for write prefetch not
 supported by SSE counterpart or the SSE prefetch is not available
 (K6 machines).  Otherwise use SSE prefetch as it allows specifying
 of locality.  */

We are generating SSE prefetches, since they allow specification of locality.

> But there is a mention in SWOG guide of amdfam15 that their functionalities
> could change in future. 
> 
> (Snip)
> AMD Family 15h processors implement the PREFETCHT0, PREFETCHT1, and PREFETCHT2
> instructions in exactly the same way as the PREFETCH instruction. That is, the
> data is brought into the L1 data cache. This functionality could change in
> future implementations of the AMD Family 15h
> processor
> (Snip)

I see no problem here. For current implementations, SSE prefetches are treated
in the same way as 3dNOW prefetch. I read the quoted part as "... in the
future, F15h SSE prefetches will implement the functionality as described in
the insn mnemonic (locality)", not that they will overload the mnemonic with
some other different functionality.

"Some other different functionality" will need different mnemonic, probably
supported by cpuid flag.

So, INVALID.

[Bug c++/54197] [4.7/4.8 regression] Lifetime of reference not properly extended

[aaw at gcc dot gnu.org]

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

Ollie Wild  changed:

   What|Removed |Added

 CC||aaw at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |aaw at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from Ollie Wild  2012-08-13 18:04:21 UTC 
---
The issue is that these cause a COMPOUND_EXPR to be passed to
extend_ref_init_temps_1.

I have a patch which replaces the second operand of the COMPOUND_EXPR with
another call to extend_ref_init_temps_1.  Testing now.  Will send out for
review shortly.

[Bug c++/54197] [4.7/4.8 regression] Lifetime of reference not properly extended

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/54243] [OOP] ICE (segfault) in gfc_type_compatible for invalid BT_CLASS

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from janus at gcc dot gnu.org 2012-08-13 19:21:15 UTC ---
I think the proper fix for both this one and PR 54244 would be the following:

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 190186)
+++ gcc/fortran/resolve.c(working copy)
@@ -5793,6 +5795,9 @@ check_typebound_baseobject (gfc_expr* e)

   gcc_assert (base->ts.type == BT_DERIVED || base->ts.type == BT_CLASS);

+  if (base->ts.type == BT_CLASS && !gfc_expr_attr (base).class_ok)
+return FAILURE;
+
   /* F08:C611.  */
   if (base->ts.type == BT_DERIVED && base->ts.u.derived->attr.abstract)
 {


This aborts the resolution of the type-bound call rather early (if the passed
object was not properly declared), avoiding all problems that one could
possibly run into later. It is also general enough that it should work for
other similar cases.

[Bug tree-optimization/54245] [4.8 regression] incorrect optimisation

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-08-13
 AssignedTo|unassigned at gcc dot   |wschmidt at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from William J. Schmidt  2012-08-13 
19:29:06 UTC ---
I'll take a look.  Might be a day or two as my queue is kind of full.

[Bug libstdc++/54185] [4.7/4.8 Regression] condition_variable not properly destructed

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  2012-08-13 
19:56:55 UTC ---
Author: redi
Date: Mon Aug 13 19:56:50 2012
New Revision: 190356

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190356
Log:
2012-08-13  David Adler  

PR libstdc++/54185
* src/c++11/condition_variable.cc (condition_variable): Always
destroy native type in destructor.
* testsuite/30_threads/condition_variable/54185.cc: New.

Added:
trunk/libstdc++-v3/testsuite/30_threads/condition_variable/54185.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/condition_variable.cc

[Bug libstdc++/54185] [4.7/4.8 Regression] condition_variable not properly destructed

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  2012-08-13 
19:56:55 UTC ---
Author: redi
Date: Mon Aug 13 19:56:50 2012
New Revision: 190356

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190356
Log:
2012-08-13  David Adler  

PR libstdc++/54185
* src/c++11/condition_variable.cc (condition_variable): Always
destroy native type in destructor.
* testsuite/30_threads/condition_variable/54185.cc: New.

Added:
trunk/libstdc++-v3/testsuite/30_threads/condition_variable/54185.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/condition_variable.cc

--- Comment #11 from Jonathan Wakely  2012-08-13 
19:57:36 UTC ---
Author: redi
Date: Mon Aug 13 19:57:31 2012
New Revision: 190357

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190357
Log:
2012-08-13  David Adler  

PR libstdc++/54185
* src/c++11/condition_variable.cc (condition_variable): Always
destroy native type in destructor.
* testsuite/30_threads/condition_variable/54185.cc: New.

Added:
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/30_threads/condition_variable/54185.cc
Modified:
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/condition_variable.cc

[Bug libstdc++/54185] [4.7/4.8 Regression] condition_variable not properly destructed

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  2012-08-13 
19:57:36 UTC ---
Author: redi
Date: Mon Aug 13 19:57:31 2012
New Revision: 190357

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190357
Log:
2012-08-13  David Adler  

PR libstdc++/54185
* src/c++11/condition_variable.cc (condition_variable): Always
destroy native type in destructor.
* testsuite/30_threads/condition_variable/54185.cc: New.

Added:
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/30_threads/condition_variable/54185.cc
Modified:
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
branches/gcc-4_7-branch/libstdc++-v3/src/c++11/condition_variable.cc

[Bug fortran/54247] New: OpenMP code fails at execution in AMD Interlagos

[longb at cray dot com]

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

 Bug #: 54247
   Summary: OpenMP code fails at execution in AMD Interlagos
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lo...@cray.com


> cat test.f90
!  derived from OpenMP test omp31f/F31_A_16_1.F90
!based on Example A.16.1f, p. 213 lines 1-19 in OpenMP API Ver 3.1.
program F31_A_16_1
   use omp_lib
   implicit none
   integer, parameter :: ITERATIONS = 2**17 ! Adjustable parameter
   integer(kind=omp_lock_kind) :: lock
   integer :: count_something_useful = 0, count_something_critical = 0

   call omp_set_num_threads(16)
   call omp_set_dynamic(.false.)
   call omp_init_lock(lock)

!$omp parallel
!$omp single
   call foo(lock, ITERATIONS)
!$omp end single
!$omp end parallel

   if(count_something_useful /= ITERATIONS .or. &
  count_something_critical /= ITERATIONS) then
  write (6, '(*(G0))') ' FAIL - ', &
 '(count_something_useful,count_something_critical) == (', &
 count_something_useful, ',', count_something_critical, &
 '), expected (', ITERATIONS, ',', ITERATIONS, ')'
   end if

contains
   ! from OpenMP 3.1 Example A.16.1f
   subroutine foo ( lock, n )
  use omp_lib
  integer (kind=omp_lock_kind) :: lock
  integer n
  integer i
  do i = 1, n
!$omp task
  call something_useful()
  do while ( .not. omp_test_lock(lock) ) 
!$omp taskyield
  end do
  call something_critical()
  call omp_unset_lock(lock)
!$omp end task
  end do
   end subroutine

   subroutine something_useful()
  !$omp atomic update
  count_something_useful = count_something_useful+1
   end subroutine something_useful

   subroutine something_critical
  ! isn't necessary to protect with atomic update, as invocations of this
  ! subroutine are protected by a lock
  count_something_critical = count_something_critical+1
   end subroutine something_critical

end program F31_A_16_1


> ftn -fopenmp test.f90
> ilrun -n1 -d16 ./a.out
 FAIL - (count_something_useful,count_something_critical) == (131072,131070),
expected (131072,131072)
Application 8535547 resources: utime ~6s, stime ~1s
> mcrun -n1 -d16 ./a.out
Application 8535554 resources: utime ~0s, stime ~1s

The code triggers a FAIL trap on interlagos processors, but not on the previous
generation Magny-Cours AMD chips.

Command explanation:

ilrun -n1 -d16

--> Execute on a node with Interlagos processors, 1 node, 16 threads

mcrun -n1 -d16

--> Execute on a node with Magny-Cours processors, 1 node, 16 threads  [2
sockets in SMP node]

ftn

--> wrapper for Cray systems to get the "right" (we hope) set of libraries and
default options for the current compilation environment.  For the gcc
environment, the options implied are here are COLLECT_GCC_OPTIONS='-u'
'pthread_mutex_trylock' '-fno-second-underscore' '-march=bdver1' '-static' '-v'
'-fopenmp'

[Bug libstdc++/54185] [4.7/4.8 Regression] condition_variable not properly destructed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.2

--- Comment #12 from Jonathan Wakely  2012-08-13 
20:00:40 UTC ---
fixed for 4.7.2

[Bug fortran/54247] OpenMP code fails at execution in AMD Interlagos

[longb at cray dot com]

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

Bill Long  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Bill Long  2012-08-13 20:38:33 UTC 
---
Our internal OpenMP gurus spotted that in line 36 the

!$omp task

should be 

!$omp task default(shared)


With that change, the code executes correctly on Interlagos nodes.  

Conclusion is that there is a bug in the OpenMP 3.1 examples, so still
potentially useful information.  But the initial complaint is not valid.

[Bug tree-optimization/54240] Routine hoist_adjacent_loads does not work properly after r189366

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from William J. Schmidt  2012-08-13 
20:39:59 UTC ---
Something else is broken, too, as the optab handlers for cmov on powerpc64
appear to have gone missing.  I'll get one of our back-end specialists to help
me understand that.

[Bug c++/53836] [4.7/4.8 Regression] ICE: unexpected expression of kind template_parm_index

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #4 from H.J. Lu  2012-08-13 21:07:04 
UTC ---
It was fixed by revision 172942:

http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg01138.html

on 4.6 branch.  However, the same patch was never applied
on trunk.

[Bug tree-optimization/54240] Routine hoist_adjacent_loads does not work properly after r189366

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  2012-08-13 
21:59:33 UTC ---
(In reply to comment #7)
> Something else is broken, too, as the optab handlers for cmov on powerpc64
> appear to have gone missing.  I'll get one of our back-end specialists to help
> me understand that.

They are only enabled for TARGET_ISEL which is either TARGET_ISEL or 
TARGET_ISEL64 which is correct as ppc64 does not have isel by default.

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

[PHHargrove at lbl dot gov]

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

--- Comment #8 from Paul H. Hargrove  2012-08-13 
22:04:40 UTC ---
The following is a transcript of a test I just tried one of my systems where
Gary and I have observed this bug.  The test appears to show that the gcc
provided by Fedora Core 6 does generate "sldi" instructions and the
system-provided assembler understands them.  So, whatever is causing the build
failures that Gary and I see, it is *not* simply a matter of an assembler not
supporting the instructions.

-Paul

{phargrov@fc6 ~}$ cat q.c
unsigned long long foo(void) { return 0x7FFFLLU; }

{phargrov@fc6 ~}$ gcc -m64 -O -S q.c

{phargrov@fc6 ~}$ cat q.s
.file   "q.c"
.section".toc","aw"
.section".text"
.align 2
.globl foo
.section".opd","aw"
.align 3
foo:
.quad   .L.foo,.TOC.@tocbase
.previous
.type   foo, @function
.L.foo:
lis 3,0x7fff
sldi 3,3,16
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size   foo,.-.L.foo
.ident  "GCC: (GNU) 4.1.2 20070626 (Red Hat 4.1.2-13)"
.section.note.GNU-stack,"",@progbits

{phargrov@fc6 ~}$ as -a64 -mppc64 q.s
[no errors]

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

[PHHargrove at lbl dot gov]

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

--- Comment #9 from Paul H. Hargrove  2012-08-13 
22:42:16 UTC ---
Following up on my previous experiment, I tried the same input with the xgcc
which is failing to build libdecnumber.  If also fails with the 1-line test
case:

{phargrov@fc6 ~}$ cat q.c
unsigned long long foo(void) { return 0x7FFFLLU; }

{phargrov@fc6 ~}$ /usr/local/upc/compiler/bld/./gcc/xgcc
-B/usr/local/upc/compiler/bld/./gcc/ -m64 -O  ~/q.c
/tmp/cctmw5wO.s: Assembler messages:
/tmp/cctmw5wO.s:14: Error: Unrecognized opcode: `sldi'


Examining stderr when "-v" is passed to the two compilers reveals a KEY
difference:

{phargrov@fc6 ~}$ gcc -m64 -O -v -c q.c 2>&1 | grep -w as
 as -a64 -mppc64 -many -V -Qy -o q.o /tmp/ccpjKGBl.s

{phargrov@fc6 ~}$ /usr/local/upc/compiler/bld/./gcc/xgcc
-B/usr/local/upc/compiler/bld/./gcc/ -m64 -O -v -c ~/q.c 2>&1 | grep -w as
 /usr/local/upc/compiler/bld/./gcc/as -v -a64 -mcom -many -o q.o
/tmp/cctEFZq2.s


The difference (other than the use of the built-time wrapper script) is
"-mppc64" for the Red Hat built gcc-4.2.1 vs "-mcom" for the 4.8.0 snapshot. 
The following shows that this flag, not the presence of the wrapper script is
the origin of the failure:

{phargrov@fc6 ~}$ /usr/local/upc/compiler/bld/./gcc/as  -a64 -mcom -many -o q.o
q.s
q.s: Assembler messages:
q.s:14: Error: Unrecognized opcode: `sldi'

{phargrov@fc6 ~}$ /usr/local/upc/compiler/bld/./gcc/as  -a64 -mppc64 -many -o
q.o q.s
[no error]

{phargrov@fc6 ~}$ /usr/bin/as  -a64 -mcom -many -o q.o q.s
q.s: Assembler messages:
q.s:14: Error: Unrecognized opcode: `sldi'

{phargrov@fc6 ~}$ /usr/bin/as  -a64 -mppc64 -many -o q.o q.s
[no error]

So, assuming gas is correct in rejecting 'sldi' and 'srdi' in "common" mode the
question becomes, "why is gcc by default specifying a target to the assembler
which doesn't support the instructions it is generating?"

Of course, if 'sldi' and 'slri' ARE supposed to be supported in "common" mode,
then this is a binutils bug.

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

[PHHargrove at lbl dot gov]

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

--- Comment #10 from Paul H. Hargrove  2012-08-13 
22:54:12 UTC ---
(In reply to comment #9)
> Following up on my previous experiment, I tried the same input with the xgcc
> which is failing to build libdecnumber.  If also fails with the 1-line test
> case:

Oops.
That should have said "failing to build libgcc2", not "libdecnumber".

[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 #11 from Gary Funck  2012-08-13 23:00:57 
UTC ---
It is possible that revision 189908 introduced the 'mcom' change.

Index: src/gcc/config/rs6000/rs6000.h
===
--- src/gcc/config/rs6000/rs6000.h  (revision 189907)
+++ src/gcc/config/rs6000/rs6000.h  (revision 189908)
@@ -101,17 +101,12 @@
you make changes here, make them also there.  */
 #define ASM_CPU_SPEC \
 "%{!mcpu*: \
-  %{mpower: %{!mpower2: -mpwr}} \
-  %{mpower2: -mpwrx} \
   %{mpowerpc64*: -mppc64} \
   %{!mpowerpc64*: %{mpowerpc*: -mppc}} \
-  %{mno-power: %{!mpowerpc*: -mcom}} \
-  %{!mno-power: %{!mpower*: %(asm_default)}}} \
+  %{!mpowerpc*: -mcom}} \
[...]

r189908 | segher | 2012-07-27 04:44:37 -0700 (Fri, 27 Jul 2012) | 115 lines

2012-07-26  Segher Boessenkool  

gcc/
* common/config/rs6000/rs6000-common.c (rs6000_handle_option):
Delete code for -mno-power, -mpower, and -mpower2.
* config/rs6000/aix43.h (NON_POWERPC_MASKS): Delete.
(SUBTARGET_OVERRIDE_OPTIONS): Delete check for POWER together
with -maix64.
[...]

[Bug target/31557] return 0x80000000UL code gen can be improved

[PHHargrove at lbl dot gov]

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

Paul H. Hargrove  changed:

   What|Removed |Added

 CC||PHHargrove at lbl dot gov

--- Comment #3 from Paul H. Hargrove  2012-08-13 
23:03:06 UTC ---
FWIW, 4.8.0 20120809 w/ -O1 or higher is now using just 4 instructions instead
of 5.  So, "half way there".


.L.f:
lis 3,0x8000
ori 3,3,1
rldicl 3,3,0,32
blr

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

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-13
   Target Milestone|--- |4.8.0
Summary|ppc64 build failure -   |[4.8 regression] ppc64
   |Unrecognized opcode: `sldi' |build failure -
   |(and `srdi`)|Unrecognized opcode: `sldi'
   ||(and `srdi`)
 Ever Confirmed|0   |1

--- Comment #12 from Andreas Schwab  2012-08-13 23:14:04 
UTC ---
Confirmed.

[Bug target/17108] Store with update not generated for a simple loop

[PHHargrove at lbl dot gov]

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

Paul H. Hargrove  changed:

   What|Removed |Added

 CC||PHHargrove at lbl dot gov

--- Comment #7 from Paul H. Hargrove  2012-08-13 
23:19:45 UTC ---
FWIW:
With GCC 4.8.0 20120809 the test code is fully unrolled at -O3:
.L.foo:
stfs 1,0(3)
stfs 1,4(3)
stfs 1,8(3)
stfs 1,12(3)
stfs 1,16(3)
stfs 1,20(3)
stfs 1,24(3)
stfs 1,28(3)
blr

However, at -O2 the code shown in comment #6 is still being generated (except
with different register allocations).  This is true even when "-mupdate" is
passed to explicitly enable store/update instructions.

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

[PHHargrove at lbl dot gov]

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

--- Comment #13 from Paul H. Hargrove  2012-08-14 
00:01:08 UTC ---
(In reply to comment #9)
> Of course, if 'sldi' and 'slri' ARE supposed to be supported in "common" mode,
> then this is a binutils bug.

I've confirmed that these instruction are NOT in the POWER ISA, and thus gas is
correct in rejecting them in "-mcom" mode.

Reference:

"Appendix F. New Instructions"
in "Book I: PowerPC User Instruction Set Architecture"
which is one volume in "PowerPC Architecture Book, Version 2.02"
PDF:
http://download.boulder.ibm.com/ibmdl/pub/software/dw/library/es-ppcbook1.zip

Specifically, the Appendix F table lists instructions in the PowerPC ISA that
are not part of the POWER ISA.  The "rldicl" and "rldicr" instructions are
among those listed (and as noted previously, "sldi" and "srdi" are just
"extended mnemonics" for those two).

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

[matt at use dot net]

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

--- Comment #2 from Matt Hargett  2012-08-14 00:26:35 UTC 
---
Okay. I filed this bug at your request last year because of your concerns that
some of the improvements seen with multiple iterations might be "papering over"
existing bugs in the optimizers. Does this mean that in this zlib case the
passes are all fine, but multiple iterations legitimately helps?

The original discussion was in the context of Maxim's devirt patches. Would the
approach you mention still allow for the testcases from his proposed patches to
pass? (We can discuss this second question on-list, if you like.)

Thanks for reviving this; we saw dramatic performance improvements with the
4.6-based deliverable we got from Maxim.

[Bug target/31557] return 0x80000000UL code gen can be improved

[PHHargrove at lbl dot gov]

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

--- Comment #4 from Paul H. Hargrove  2012-08-14 
00:31:14 UTC ---
(In reply to comment #3)
> FWIW, 4.8.0 20120809 w/ -O1 or higher is now using just 4 instructions instead
> of 5.  So, "half way there".
> 
> 
> .L.f:
> lis 3,0x8000
> ori 3,3,1
> rldicl 3,3,0,32
> blr

That was for a 64-bit target, where the need to zero the upper half of r3
(which is 0x due to sign extension of 0x8000 by 'lis') accounts for the
4th instruction.  So, there is still room for improvement using the originally
proposed 3-instruction sequence (since 'oris' won't sign-extend as 'lis' does).


For a 32-bit target, it appears that GCC 4.8.0 20120809 has reached the desired
three instructions:

f:
lis 3,0x8000
ori 3,3,1
blr

[Bug target/53194] [4.8 Regression] Many x86 failures

[eraman at gcc dot gnu.org]

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

--- Comment #8 from eraman at gcc dot gnu.org 2012-08-14 00:51:15 UTC ---
Author: eraman
Date: Tue Aug 14 00:51:10 2012
New Revision: 190375

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190375
Log:
2012-08-13   Easwaran Raman  
Backport the following patches from trunk to add support for Intel
Transactional Memory Instructions support (Google ref b/6496405):
r185218, r185223, r187051, r187084.

r185218,r185223:
2012-02-12  Kirill Yukhin  
* doc/invoke.texi: Document -mrtm option.
* common/config/i386/i386-common.c (OPTION_MASK_ISA_RTM_SET):
New.
(OPTION_MASK_ISA_RTM_UNSET): Ditto.
(ix86_handle_option): Handle OPT_mrtm.
* config.gcc (i[34567]86-*-*): Add rtmintrin.h and
xtestintrin.h.
(x86_64-*-*): Ditto.
* i386-builtin-types.def (INT_FTYPE_VOID): New.
* config/i386/i386-c.c (ix86_target_macros_internal): Define
__RTM__ if needed.
(ix86_target_string): Define -mrtm option.
(PTA_RTM): New.
(ix86_option_override_internal): Extend "corei7-avx" with
RTM option. Handle new option.
(ix86_valid_target_attribute_inner_p): Add OPT_mrtm.
(ix86_builtins): Add IX86_BUILTIN_XBEGIN, IX86_BUILTIN_XEND,
IX86_BUILTIN_XTEST.
(bdesc_special_args): Ditto.
(ix86_init_mmx_sse_builtins): Add IX86_BUILTIN_XABORT.
(ix86_expand_special_args_builtin): Handle new built-in type.
(ix86_expand_builtin): Handle XABORT instruction.
* config/i386/i386.h (TARGET_RTM): New.
* config/i386/i386.md (UNSPECV_XBEGIN): New.
(UNSPECV_XEND): Ditto.
(UNSPECV_XABORT): Ditto.
(UNSPECV_XTEST): Ditto.
(xbegin): Ditto.
(xbegin_1): Ditto.
(xend): Ditto.
(xabort): Ditto
(xtest): Ditto.
(xtest_1): Ditto.
* config/i386/i386.opt (mrtm): New.
* config/i386/immintrin.h: Include rtmintrin.h and
xtestintrin.h.
* config/i386/rtmintrin.h: New header.
* config/i386/xtestintrin.h: Ditto.

r187051:
2012-05-02  Kirill Yukhin  
Andi Kleen 

* coretypes (MEMMODEL_MASK): New.
* builtins.c (get_memmodel): Add val. Call target.memmodel_check
and return new variable.
(expand_builtin_atomic_exchange):  Mask memmodel values.
(expand_builtin_atomic_compare_exchange): Ditto.
(expand_builtin_atomic_load): Ditto.
(expand_builtin_atomic_store): Ditto.
(expand_builtin_atomic_clear): Ditto.
* doc/extend.texi: Mention port-dependent memory model flags.
* config/i386/cpuid.h (bit_HLE): New.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect
HLE support.
* config/i386/i386-protos.h (ix86_generate_hle_prefix): New.
* config/i386/i386-c.c (ix86_target_macros_internal): Set
HLE defines.
(ix86_target_string)<-mhle>: New.
(ix86_valid_target_attribute_inner_p): Ditto.
* config/i386/i386.c (ix86_target_string):
New.
(ix86_valid_target_attribute_inner_p): Ditto.
(ix86_option_override_internal): New switch, set it
enabled for generic, generic64 and core-avx2.
(ix86_print_operand): Generate HLE lock prefixes.
(ix86_memmodel_check): New.
(TARGET_MEMMODEL_CHECK): Ditto.
* config/i386/i386.h (OPTION_ISA_HLE): Ditto.
(IX86_HLE_ACQUIRE): Ditto.
(IX86_HLE_RELEASE): Ditto.
* config/i386/i386.h (ix86_generate_hle_prefix): Ditto.
* config/i386/i386.opt (mhle): Ditto.
* config/i386/sync.md(atomic_compare_and_swap): Pass
success model to instruction emitter.
(atomic_fetch_add): Ditto.
(atomic_exchange): Ditto.
(atomic_add): Ditto.
(atomic_sub): Ditto.
(atomic_): Ditto.
(*atomic_compare_and_swap_doubledi_pic): Ditto.
(atomic_compare_and_swap_single): Define and use argument
for success model.
(atomic_compare_and_swap_double): Ditto.
* configure.ac: Check if assembler support HLE prefixes.
* configure: Regenerate.
* config.in: Ditto.

r187084:
2012-05-03  Jakub Jelinek  
PR target/53194
* config/i386/i386-c.c (ix86_target_macros_internal): Don't
define __ATOMIC_HLE_* macros here.
(ix86_target_macros): But here, using cpp_define_formatted.

testsuite/ChangeLog.google-4_7:

2012-08-13   Easwaran Raman  
Backport the following patches from trunk to add support for Intel
Transactional Memory Instructions support (Google ref b/6496405):
r185218, r185223, r187051, r187089, r187094.

r85218,r185223:
2012-03-12  Kirill Yukhin  
* gcc.target/i386/rtm-xabort-1.c: New.
* gcc.target/i386/rtm-xbegin-1.c: Ditto.
* gcc.target/i386/rtm-xend-1.c: Ditto.
* gcc.target/i386/rtm-xtest-1.c: 

[Bug target/54246] Bytemark FOURIER 54% slower in X32 chroot

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-08-14
 CC||areg.melikadamyan at gmail
   ||dot com, hjl.tools at gmail
   ||dot com
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2012-08-14 01:07:58 
UTC ---
Please try hjl/x32/gcc-4_7-branch branch from

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

[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||bkoz at gcc dot gnu.org

--- Comment #3 from Hans-Peter Nilsson  2012-08-14 
02:46:23 UTC ---
(In reply to comment #2)
> I don't think that is right.

See the reference.  The sites changed are where semantics has changed to be
per-type rather than per-object.  See the referenced URL: "Edit paragraph 2 as
follows. The function atomic_is_lock_free (29.6) indicates whether the type is
lock-free. In any given program execution, the result of the lock-free query
shall be consistent for all pointers of the same type."

Adding the committer to CC for further comments.

[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[amacleod at redhat dot com]

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

--- Comment #4 from Andrew Macleod  2012-08-14 
03:20:09 UTC ---

A GCC port is incorrect if it is issuing any kind of lock.  GCC is only allowed
to issue a lock free sequence of some sort.  If a lock is required, then a call
to libatomic must be made.

So if there is a type which is sometimes lock free and sometimes not due to
alignment or anything else,   __atomic_always_lock_free should return FALSE for
that type.  I think your current problem is that the infrastructure change for
__atomic_always_lock_free to handle alignment issues is not present yet. So it
erroneously says TRUE for this type when in fact it shouldn't.   

I don't think this will be resolved properly in GCC 4.7 since c++11 is still
experimental (I could be wrong, we'll see how invasive the support changes
are).


Its important that the libstdc++ routines call the __atomic_is_lock_free() so
that the answer can be determined at runtime if libatomic is utilized for any
atomic sequences. 

__atomic_always_lock_free() is *always* resolved to a 1 or a 0 at compile time.
The compiler is only capable of answering the question, "Does the compiler
always generate a lock free sequence".

__atomic_is_lock_free() will return true if __atomic_always_lock_free() returns
true. Otherwise it is left as a runtime call into libatomic so it can answer
the q.  libatomic is

[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[amacleod at redhat dot com]

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

--- Comment #5 from Andrew Macleod  2012-08-14 
03:27:28 UTC ---
huh, somehow this got submitted before I finished. :-P

For libstdc++, the macros SHOULD use __atomic_always_lock_free() since they are
intended to be used in #ifdef's and such and we want those resolved at compile
time for use with compiler sequences.   

The is_lock_free() method should continue to call the __atomic_is_lock_free().
That question may not be answerable without asking whatever libatomic is linked
into the executable.  Just because the compiler doesn't know a type is lock
free doesn't mean the library doesn't have a lock free implementation.

[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||crowl at gcc dot gnu.org

--- Comment #6 from Hans-Peter Nilsson  2012-08-14 
03:52:07 UTC ---
(In reply to comment #4)
> A GCC port is incorrect if it is issuing any kind of lock.  GCC is only 
> allowed
> to issue a lock free sequence of some sort.  If a lock is required, then a 
> call
> to libatomic must be made.
> 
> So if there is a type which is sometimes lock free and sometimes not due to
> alignment or anything else,   __atomic_always_lock_free should return FALSE 
> for
> that type.

Yes...

>  I think your current problem is that the infrastructure change for
> __atomic_always_lock_free to handle alignment issues is not present yet. So it
> erroneously says TRUE for this type when in fact it shouldn't.

This PR is about the libstdc++ library is_lock_free function using the
*per-object* builtin query when it should use the *per-type* query as per the
referenced discussion.  And that's been corrected.

It's separate to my other target woes; an incidental observation.  I agree the
function has a name intuitively leading to thinking it should be per-object,
but it isn't.

> Its important that the libstdc++ routines call the __atomic_is_lock_free() so
> that the answer can be determined at runtime if libatomic is utilized for any
> atomic sequences.

Maybe elsewhere, but not this particular code.  If your argument is that
is_lock_free should be per-object, then you'll have to argue with the
standard-guys; I'm just quoting the reference above.

> __atomic_always_lock_free() is *always* resolved to a 1 or a 0 at compile 
> time.
> The compiler is only capable of answering the question, "Does the compiler
> always generate a lock free sequence".

Which is exactly the kind of answer sought here.  Is the n2992 reference
incorrect or am I (and bkoz) misinterpreting it?  Are things about to change
again standard-wise?  Let's try and ask mr. Crowl.

[Bug c/54113] -Wmissing-prototypes cries wolf for C99 inline functions

[eggert at gnu dot org]

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

--- Comment #1 from eggert at gnu dot org 2012-08-14 04:08:17 UTC ---
In  Jim
Meyering reports that GCC 4.8.0 20120803 issues a different (but still bogus)
warning for this program.  It reports "error: no previous declaration for 'FOO' 
[-Werror=missing-declarations]" if FOO is an inline function.  This warning
should not be emitted either.

[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 #30 from Gary Funck  2012-08-14 04:24:54 
UTC ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00839.html

[Bug libstdc++/54248] New: Comment in standard library header talks about boost

[zeratul976 at hotmail dot com]

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

 Bug #: 54248
   Summary: Comment in standard library header talks about boost
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com


This is rather trivial thing, but bits/concept_check.h contains the following
comment near the bottom:


// Note that the obvious and elegant approach of
//
//#define glibcxx_function_requires(C) boost::function_requires< boost::C >()
//
// won't work due to concept templates with more than one parameter, e.g.,
// BinaryPredicateConcept.  The preprocessor tries to split things up on
// the commas in the template argument list.  We can't use an inner pair of
// parenthesis to hide the commas, because "boost::(Temp)" isn't
// a valid instantiation pattern.  Thus, we steal a feature from C99.


Should this comment really be talking about boost?