[Bug target/50202] ICE: in final_scan_insn, at final.c:2709 (could not split insn) with __builtin_ia32_pcmpistri128

[uros at gcc dot gnu.org]

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

--- Comment #1 from uros at gcc dot gnu.org 2011-08-27 07:46:38 UTC ---
Author: uros
Date: Sat Aug 27 07:46:35 2011
New Revision: 178130

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178130
Log:
PR target/50202
* config/i386/sse.md (sse4_2_pcmpestr): Emit NOTE_INSN_DELETED note
when all outputs are unused.
(sse4_2_pcmpestr): Ditto.

testsuite/ChangeLog:

PR target/50202
* gcc.target/i386/pr50202.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr50202.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/50207] [4.7 Regression] G++ segv's on reduced test case

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0
Summary|G++ segv's on reduced test  |[4.7 Regression] G++ segv's
   |case|on reduced test case

[Bug bootstrap/50206] Internal compiler error in xgcc while trying to bootstrap 4.6.1

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Richard Guenther  2011-08-27 
08:01:58 UTC ---
It is gmp that is aborting.  Do you run from inside a virtual machine?  Make
sure that kvm/qemu is configured for an existing CPU, gmp is known to abort()
on the impossible default values kvm/qemu returns for cpuid().

Not a GCC bug.

[Bug rtl-optimization/50205] [4.6/4.7 Regression] ICE: in code_motion_path_driver, at sel-sched.c:6581 with -fselective-scheduling2 and custom flags

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.2

[Bug rtl-optimization/33353] Vector RTL arithmetic operations with constant arguments are not fully folded.

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.2

--- Comment #1 from Uros Bizjak  2011-08-27 08:11:22 
UTC ---
This is fixed at least from gcc version 4.6.2 20110827 (prerelease) onward:

f:
.LFB0:
.cfi_startproc
subq$40, %rsp
.cfi_def_cfa_offset 48
movq%rsp, %rdi
movl$0, (%rsp)
movl$2, 4(%rsp)
movl$4, 8(%rsp)
movl$6, 12(%rsp)
movl$8, 16(%rsp)
movl$10, 20(%rsp)
movl$12, 24(%rsp)
movl$14, 28(%rsp)
callg
movq%rsp, %rdi
movl$0, (%rsp)
movl$2, 4(%rsp)
movl$4, 8(%rsp)
movl$6, 12(%rsp)
movl$8, 16(%rsp)
movl$10, 20(%rsp)
movl$12, 24(%rsp)
movl$14, 28(%rsp)
callg
addq$40, %rsp
.cfi_def_cfa_offset 8
ret

[Bug tree-optimization/50204] [4.5/4.6/4.7 Regression] Missed fully redundant load found in crafty (SPEC 2k)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-27
 CC||rguenth at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-08-27 
08:13:12 UTC ---
This is because we have, for the 2nd load

:
  # .MEM_4 = PHI <.MEM_7(3), .MEM_6(D)(4), .MEM_8(5)>
  # VUSE <.MEM_4>
  opening.0_3 = opening;
  if (opening.0_3 != 4)


Thus three incoming edges.  The walker in SCCVN does not try to handle
more than two, see tree-ssa-alias.c:get_continuation_for_phi ().

In principle one can handle N PHI arguments by reducing them to
N - 1 PHI arguments by handling two of them and reducing them to
the dominating continuation.  And then iterate.  But the idea of
get_continuation_for_phi () is to make this walk linear which it
wouldn't be for this case.

Confirmed anyway.

I suppose it's not performance critical for crafty to see this redundant
load?

[Bug target/50202] ICE: in final_scan_insn, at final.c:2709 (could not split insn) with __builtin_ia32_pcmpistri128

[uros at gcc dot gnu.org]

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

--- Comment #2 from uros at gcc dot gnu.org 2011-08-27 08:15:52 UTC ---
Author: uros
Date: Sat Aug 27 08:15:44 2011
New Revision: 178131

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178131
Log:
PR target/50202
* config/i386/sse.md (sse4_2_pcmpestr): Emit NOTE_INSN_DELETED note
when all outputs are unused.
(sse4_2_pcmpistr): Ditto.

testsuite/ChangeLog:

PR target/50202
* gcc.target/i386/pr50202.c: New test.


Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.target/i386/pr50202.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/i386/sse.md
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug target/50202] ICE: in final_scan_insn, at final.c:2709 (could not split insn) with __builtin_ia32_pcmpistri128

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-08/msg02218.htm
   ||l
 Resolution||FIXED
   Target Milestone|--- |4.6.2

--- Comment #3 from Uros Bizjak  2011-08-27 08:19:02 
UTC ---
Fixed.

[Bug middle-end/50199] [4.7 Regression] wrong code with -flto -fno-merge-constants

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-27
 CC||hubicka at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-08-27 
08:20:47 UTC ---
Hmmm.  Partitioning unshares string constants and I suppose ipa-cp propagates
one of it to the callee.

Not sure if this is a well-defined testcase though.  If it is we'd probably
need to add CONST_DECLs for address-taken constants and register them with
the varpool (and disallow &"..." in gimple).

It should be possible to make a non-LTO testcase that fails similarly
by instructing the assembler/linker not to merge strings.

Joseph, does C require that a string literal "..." has a single underlying
object or would the testcase be undefined?

[Bug c/50198] New test gcc.c-torture/execute/scal-to-vec1.c fails on many targets

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-08-27 
08:27:10 UTC ---
I suppose the FP comparisons fail for the division by 3. which is not exactly
representable?

[Bug target/49606] mips64: o64 Unrecognizable insn when one noreturn function calling another noreturn function

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011-08-27
 CC||rsandifo at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from rsandifo at gcc dot gnu.org  
2011-08-27 08:39:09 UTC ---
The problem here isn't really o64 itself (which is well
supported on *-elf targets, but less so on *-linux-gnu).
The problem is the combination of "-mabi=o64 -mlong64".
That isn't really a defined ABI.

As well as making longs 64 bits wide, -mlong64 makes
pointers 64 bits wide.  But you're still using a
32-bit file format.  If you want an LP64 ABI,
then n64 seems like a better choice.

So do you actually have a system that uses this ABI
(o64+mlong64)?  If so, could you give a few more details?
TBH, my instinctive reaction is that this is a missing
diagnostic bug, and that we should refuse to compile
-mabi=o64 -mlong64.

The immediate cause of the ICE is that the -mabicalls
support for o32 and o64 assumes that pointers are
32 bits wide.  It would be theoretically possible
to extend it to cope with 64-bit pointers, but that
shouldn't be necessary as far as the defined ABIs go.

[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array

[baffo32 at gmail dot com]

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

baffo32 at gmail dot com changed:

   What|Removed |Added

 CC||baffo32 at gmail dot com

--- Comment #15 from baffo32 at gmail dot com 2011-08-27 08:53:59 UTC ---
(In reply to comment #13)
> GCC allows it too, otherwise it would be an error not a warning.

I believe GCC fails for multi-dimensional arrays?

array,2> a{ {1,2},{3,4} }; // won't compile without another pair
of {}

[Bug tree-optimization/50208] New: ICE: in vinfo_for_stmt at tree-vectorizer.h:598 with -ftree-vectorize -fno-tree-fre -fno-tree-pre

[zsojka at seznam dot cz]

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

 Bug #: 50208
   Summary: ICE: in vinfo_for_stmt at tree-vectorizer.h:598 with
-ftree-vectorize -fno-tree-fre -fno-tree-pre
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 25117
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25117
reduced testcase

Compiler output:
$ gcc -O2 -ftree-vectorize -fno-tree-fre -fno-tree-pre testcase.c 
testcase.c: In function 'foo':
testcase.c:4:6: internal compiler error: vector VEC(vec_void_p,base) index
domain error, in vinfo_for_stmt at tree-vectorizer.h:598
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The testcase was reduced from the PR50039 testcase.

Tested revisions:
r178096 - crash
r177913 - crash
r177543 - OK

[Bug tree-optimization/50208] [4.7 Regression] ICE: in vinfo_for_stmt at tree-vectorizer.h:598 with -ftree-vectorize -fno-tree-fre -fno-tree-pre

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||irar at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |4.7.0
Summary|ICE: in vinfo_for_stmt at   |[4.7 Regression] ICE: in
   |tree-vectorizer.h:598 with  |vinfo_for_stmt at
   |-ftree-vectorize|tree-vectorizer.h:598 with
   |-fno-tree-fre -fno-tree-pre |-ftree-vectorize
   ||-fno-tree-fre -fno-tree-pre

Re: [Bug middle-end/50199] [4.7 Regression] wrong code with -flto -fno-merge-constants

[Joseph S. Myers]

On Sat, 27 Aug 2011, rguenth at gcc dot gnu.org wrote:

> Hmmm.  Partitioning unshares string constants and I suppose ipa-cp propagates
> one of it to the callee.
> 
> Not sure if this is a well-defined testcase though.  If it is we'd probably
> need to add CONST_DECLs for address-taken constants and register them with
> the varpool (and disallow &"..." in gimple).
> 
> It should be possible to make a non-LTO testcase that fails similarly
> by instructing the assembler/linker not to merge strings.
> 
> Joseph, does C require that a string literal "..." has a single underlying
> object or would the testcase be undefined?

It's completely clear that once a pointer to a string literal has been 
assigned to a variable, that variable has a well-defined value pointing to 
that particular copy of the string literal, and so compares equal to 
itself.  So the testcase ought to pass.

I believe each instance of a string literal in the source code after 
preprocessing corresponds to just one object of static storage duration 
(so the values from different calls to the same function containing a 
string literal must also compare equal, for example) though the objects 
from separate string literals in the source code may or may not overlap or 
coincide.  (There is no requirement for, or restriction against, 
unification between copies of the same inline function included in 
different translation units.)  So the value of "foo" == "foo" is 
unspecified, but given

const char *return_foo (void) { return "foo"; }

the value of return_foo () == return_foo () must be 1.

-- 
Joseph S. Myers
jos...@codesourcery.com

[Bug middle-end/50199] [4.7 Regression] wrong code with -flto -fno-merge-constants

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  2011-08-27 09:46:39 UTC ---
On Sat, 27 Aug 2011, rguenth at gcc dot gnu.org wrote:

> Hmmm.  Partitioning unshares string constants and I suppose ipa-cp propagates
> one of it to the callee.
> 
> Not sure if this is a well-defined testcase though.  If it is we'd probably
> need to add CONST_DECLs for address-taken constants and register them with
> the varpool (and disallow &"..." in gimple).
> 
> It should be possible to make a non-LTO testcase that fails similarly
> by instructing the assembler/linker not to merge strings.
> 
> Joseph, does C require that a string literal "..." has a single underlying
> object or would the testcase be undefined?

It's completely clear that once a pointer to a string literal has been 
assigned to a variable, that variable has a well-defined value pointing to 
that particular copy of the string literal, and so compares equal to 
itself.  So the testcase ought to pass.

I believe each instance of a string literal in the source code after 
preprocessing corresponds to just one object of static storage duration 
(so the values from different calls to the same function containing a 
string literal must also compare equal, for example) though the objects 
from separate string literals in the source code may or may not overlap or 
coincide.  (There is no requirement for, or restriction against, 
unification between copies of the same inline function included in 
different translation units.)  So the value of "foo" == "foo" is 
unspecified, but given

const char *return_foo (void) { return "foo"; }

the value of return_foo () == return_foo () must be 1.

[Bug c++/50209] New: [C++0x] Braced-init-lists are rejected as function default arguments

[daniel.kruegler at googlemail dot com]

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

 Bug #: 50209
   Summary: [C++0x] Braced-init-lists are rejected as function
default arguments
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com
 Build: 4.7.0 20110813 (experimental)


This is a placeholder entry to remind for adapting the compiler to accept
braced-init-lists as function default arguments, as decided for in

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#994

gcc 4.7.0 20110813 (experimental) in C++0x mode rejects the following code:

-
struct S {
  S(int = {}); // #2
};
-

"2|error: expected primary-expression before '{' token"

[Bug fortran/35385] gfortran does not support the COCO preprocessor

[jb at gcc dot gnu.org]

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

--- Comment #2 from Janne Blomqvist  2011-08-27 11:29:16 
UTC ---
In case anyone digs this PR up, on 2011-05-10 part 3 of the Fortran standard
(that is, COCO) was officially withdrawn. See
ftp://ftp.nag.co.uk/sc22wg5/N1851-N1900/N1874.txt .

[Bug libstdc++/50196] [C++0x] std::thread not available under macos

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-27
  Component|c++ |libstdc++
Summary|std::thread can not use |[C++0x] std::thread not
   |under macos.|available under macos
 Ever Confirmed|0   |1

[Bug middle-end/50210] New: [4.6/4.7 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1137 with fgraphite-identity -ffast-math -fno-tree-scev-cprop -fstrict-overflow

[zsojka at seznam dot cz]

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

 Bug #: 50210
   Summary: [4.6/4.7 Regression] ICE: in
create_linear_expr_from_tree, at
graphite-sese-to-poly.c:1137 with fgraphite-identity
-ffast-math -fno-tree-scev-cprop -fstrict-overflow
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: s...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 25118
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25118
reduced testcase (the same as gfortran.dg/graphite/id-pr47691.f)

Even after fixing PR47691, the same ICE is sometimes reached with
-fno-tree-scev-cprop.

Compiler output with the attached testcase:
$ gcc -O -fgraphite-identity -ffast-math -fno-tree-scev-cprop -fstrict-overflow
testcase.f 
testcase.f: In function ‘MAIN__’:
testcase.f:2:0: internal compiler error: in create_linear_expr_from_tree, at
graphite-sese-to-poly.c:1137
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r178125 - crash
4.6 r177922 - crash
4.5 r177922 - OK

[Bug bootstrap/50103] gcc-4.4.6/gcc/config/rs6000/rs6000.md:153: internal compiler error: Segmentation fault

[murthys at us dot ibm.com]

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

--- Comment #5 from Sri  2011-08-27 13:13:05 UTC ---
Hi Richard

Here is the answer to the problem I reported:

http://gcc.gnu.org/install/specific.html#x-ibm-aix 

I will need fixes for AIX 6.1 APAR IZ98732  since I am at TL05

I have a PMR open with Austin and working with  them to get an I-FIX so that I
could beta test  the APAR.

Will let you know how it goes.

Sri

[Bug middle-end/50211] New: ICE: verify_flow_info: Incorrect fallthru 11->12 with -funroll-all-loops --param case-values-threshold=1

[zsojka at seznam dot cz]

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

 Bug #: 50211
   Summary: ICE: verify_flow_info: Incorrect fallthru 11->12 with
-funroll-all-loops --param case-values-threshold=1
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 25119
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25119
reduced testcase

Probably related to PR50200. --param case-values-threshold=1 seems to cause
various ICEs. This one has simpler testcase and less compiler flags.

Compiler output:
$ gcc -O -funroll-all-loops --param case-values-threshold=1 testcase.c
testcase.c: In function 'foo':
testcase.c:17:1: error: verify_flow_info: Incorrect fallthru 11->12
testcase.c:17:1: error: wrong insn in the fallthru edge
(barrier 96 101 105)
testcase.c:17:1: internal compiler error: in rtl_verify_flow_info, at
cfgrtl.c:2113
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r178125 - crash

[Bug rtl-optimization/50212] New: [4.7 Regression] ICE: in ei_container, at basic-block.h:610 with -fnon-call-exceptions -freorder-blocks-and-partition

[zsojka at seznam dot cz]

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

 Bug #: 50212
   Summary: [4.7 Regression] ICE: in ei_container, at
basic-block.h:610 with -fnon-call-exceptions
-freorder-blocks-and-partition
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 25120
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25120
reduced testcase

Compiler output:
$ gcc -O -fnon-call-exceptions -ftrapv -freorder-blocks-and-partition
testcase.C 
testcase.C: In function 'void foo(int)':
testcase.C:12:1: internal compiler error: in ei_container, at basic-block.h:610
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r178125 - crash
r177543 - crash
r173150 - OK
4.6 r177922 - OK

[Bug middle-end/50210] [4.6/4.7 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1137 with fgraphite-identity -ffast-math -fno-tree-scev-cprop -fstrict-overflow

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-27
 Ever Confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  2011-08-27 
13:47:25 UTC ---
4.6 r169161 - OK
4.6 r169790 - crash

[Bug libstdc++/50196] [C++0x] std::thread not available under macos

[watsonsong at foxmail dot com]

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

--- Comment #2 from watsonsong  2011-08-27 
14:36:44 UTC ---
I use macport to install gcc4.6 on my computer, and I add
-D_GLIBCXX_HAS_GTHREADS flag to g++ and it report errors:

/opt/local/include/gcc46/c++/x86_64-apple-darwin10/bits/c++config.h:159:20:
error: 'NULL' was not declared in this scope
/opt/local/include/gcc46/c++/x86_64-apple-darwin10/bits/c++config.h:159:38:
error: invalid type in declaration bebore ';' token
/opt/local/include/gcc46/c++/mutex:276:52: error: there are no arguments to
'__gthread_mutex_timedlock' that depend on a template parameter, so a
declaration of '__gthread_mutex_timedlock' must be availiable [-fpermissive]
/opt/local/include/gcc46/c++/mutex:383:62: error: there are no arguments to
'__gthread_recursive_mutex_timedlock' that depend on a template parameter, so a
declaration of '__gthread_recursive_mutex_timedlock' must be availiable
[-fpermissive]

It seems can not just define _GLIBCXX_HAS_GTHREADS.

[Bug libstdc++/50196] [C++0x] std::thread not available under macos

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-08-27 
15:35:55 UTC ---
No, of course not.  That's not what I meant.

I mean we (the library maintainers) could define _GLIBCXX_HAS_GTHREADS in
c++config.h when gthreads is available, and not require _POSIX_TIMEOUTS

[Bug middle-end/50210] [4.6/4.7 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1137 with fgraphite-identity -ffast-math -fno-tree-scev-cprop -fstrict-overflow

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.2

--- Comment #2 from Richard Guenther  2011-08-27 
15:53:16 UTC ---
It looks like it should be possible to pass down errors to build_poly_scop
instead of asserting.

[Bug middle-end/50211] ICE: verify_flow_info: Incorrect fallthru 11->12 with -funroll-all-loops --param case-values-threshold=1

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||g...@the-meissners.org

--- Comment #1 from Richard Guenther  2011-08-27 
15:54:51 UTC ---
Exposed by the new param.  Mike, can you have a look?

[Bug rtl-optimization/50212] [4.7 Regression] ICE: in ei_container, at basic-block.h:610 with -fnon-call-exceptions -freorder-blocks-and-partition

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

[hubicka at gcc dot gnu.org]

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

--- Comment #22 from Jan Hubicka  2011-08-27 
17:35:27 UTC ---
Carry,
is there any chance to move ahead on this problem?  I see you posted the
PREVAILING_DEF_IRONLY_EXP but it was never committed.

Concerning Rafael's comment:

 Why is PREVAILING_DEF_IRONLY_EXP needed? I think it can be solved with 
just PREVAILING_DEF if we say that the compiler can drop references to 
them if it knows they are provided in any DSO. The only case I can see 
where this would almost be a problem is something like

This is not possible with current formulation of plugin API. It explicitely
says "Any symbol marked PREVAILING_DEF must be defined in one object file added
to the link after WPA is done, or an undefined symbol error will result"

We could also go that route I guess, but
 1) We will have to bump API version or something to indicate whether compiler
is allowed to drop the symbols or not.  With current binutils implementation
bad things happens when compiler decided to drop the symbol it is not supposed
to (my original implementation did so and it resulted in problems, especially
in large dynamic linker tables)
 2) the LTO produced COMDAT function will likely be better, so we will lose bit
of code quality
 3) There are cases where function is output COMDAT but it is keyed (i.e. with
the repo files). In this case we will not be able to drop the symbol when it
becomes unnecessary at LTO time because we will not know whether the symbol is
used by non-LTO code or not.

All those reasons are rather side cases and thus weak, but because we are
effectively changing API anyway and because PREVAILING_DEF_IRONLY_EXP makes
compiler a bit more informed in well defined way, I would go for it.

Honza

[Bug rtl-optimization/50213] New: Regression in space-optimized code relative to 4.5.x

[bigotp at acm dot org]

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

 Bug #: 50213
   Summary: Regression in space-optimized code relative to 4.5.x
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: big...@acm.org


Some change between 4.5.x and 4.6.x decreased generated code quality,
especially noticeable with -Os, for the following function:

int checkTLV (unsigned char* tlv)
{
  unsigned int csum;
  extern unsigned int __info_segment_size;
  const unsigned int* p = (const unsigned int*)(tlv + __info_segment_size);

  csum = 0;
  while (--p > (const unsigned int*)tlv)
csum ^= *p;
  csum += *p;
  return 0 == csum;
}

In 4.5.2 -Os, the loop has an 11 byte body:

  11 000c EB02  jmp .L2 # 52jump[length = 2]
  12.L3:
  13 000e 3310  xorl(%rax), %edx# 15*xorsi_1/1 
[length = 2]
  14.L2:
  15 0010 4883E804  subq$4, %rax# 18*adddi_1/1 
[length = 4]
  16 0014 4839F8cmpq%rdi, %rax  # 20*cmpdi_1/1 
[length = 3]
  17 0017 77F5  ja  .L3 # 21*jcc_1  [length = 2]

while in 4.6.1 -Os the loop has a 15 byte body:

  11 000b EB06  jmp .L2 # 66jump[length = 2]
  12.L3:
  13 000d 3350FCxorl-4(%rax), %edx  # 29*xorsi_1/1 
[length = 3]
  14 0010 4889C8movq%rcx, %rax  # 21   
*movdi_internal_rex64/2 [length = 3]
  15.L2:
  16 0013 488D48FC  leaq-4(%rax), %rcx  # 57*lea_1  [length
= 4]
  17 0017 4839F9cmpq%rdi, %rcx  # 34*cmpdi_1/1 
[length = 3]
  18 001a 77F1  ja  .L3 # 35*jcc_1  [length = 2]

My hypothesis is that the label L2 is preventing the pseudo registers for the
loop variable and the memory access from being merged into the same hardware
register.  This is not specific to the x86 back-end: I noticed it in an
unsupported back-end, where the suboptimal register allocation causes a spill.

The current trunk (svn 178132) generates the same suboptimal code as 4.6.1.

[Bug target/50214] New: strmov/strset should use :P

[hjl.tools at gmail dot com]

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

 Bug #: 50214
   Summary: strmov/strset should use :P
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com
Target: i?86-*-* x86_64-*-*


strmov/strset in i386.md have comments like:

  /* If .md ever supports :P for Pmode, these can be directly
 in the pattern above.  */

There is

;; This mode iterator allows :P to be used for patterns that operate on
;; pointer-sized quantities.  Exactly one of the two alternatives will match.
(define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")])

Shouldn't they use :P now.

[Bug middle-end/50215] New: [4.7 Regression] FAIL: gcc.dg/guality/pr45882.c

[hjl.tools at gmail dot com]

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

 Bug #: 50215
   Summary: [4.7 Regression] FAIL: gcc.dg/guality/pr45882.c
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ber...@gcc.gnu.org


On Fedora 15/x86-64, revision 178135:

http://gcc.gnu.org/ml/gcc-cvs/2011-08/msg01151.html

caused:

FAIL: gcc.dg/guality/pr45882.c  -O1  line 16 b == 7
FAIL: gcc.dg/guality/pr45882.c  -O1  line 16 c == 11
FAIL: gcc.dg/guality/pr45882.c  -O1  line 16 d == 112
FAIL: gcc.dg/guality/pr45882.c  -O1  line 16 e == 142
FAIL: gcc.dg/guality/pr45882.c  -O2  line 16 b == 7
FAIL: gcc.dg/guality/pr45882.c  -O2  line 16 c == 11
FAIL: gcc.dg/guality/pr45882.c  -O2  line 16 d == 112
FAIL: gcc.dg/guality/pr45882.c  -O2  line 16 e == 142
FAIL: gcc.dg/guality/pr45882.c  -O2 -flto  line 16 b == 7
FAIL: gcc.dg/guality/pr45882.c  -O2 -flto  line 16 c == 11
FAIL: gcc.dg/guality/pr45882.c  -O2 -flto  line 16 d == 112
FAIL: gcc.dg/guality/pr45882.c  -O2 -flto  line 16 e == 142
FAIL: gcc.dg/guality/pr45882.c  -O2 -flto -flto-partition=none  line 16 b == 7
FAIL: gcc.dg/guality/pr45882.c  -O2 -flto -flto-partition=none  line 16 c == 11
FAIL: gcc.dg/guality/pr45882.c  -O2 -flto -flto-partition=none  line 16 d ==
112
FAIL: gcc.dg/guality/pr45882.c  -O2 -flto -flto-partition=none  line 16 e ==
142
FAIL: gcc.dg/guality/pr45882.c  -O3 -fomit-frame-pointer  line 16 b == 7
FAIL: gcc.dg/guality/pr45882.c  -O3 -fomit-frame-pointer  line 16 c == 11
FAIL: gcc.dg/guality/pr45882.c  -O3 -fomit-frame-pointer  line 16 d == 112
FAIL: gcc.dg/guality/pr45882.c  -O3 -fomit-frame-pointer  line 16 e == 142
FAIL: gcc.dg/guality/pr45882.c  -O3 -g  line 16 b == 7
FAIL: gcc.dg/guality/pr45882.c  -O3 -g  line 16 c == 11
FAIL: gcc.dg/guality/pr45882.c  -O3 -g  line 16 d == 112
FAIL: gcc.dg/guality/pr45882.c  -O3 -g  line 16 e == 142
FAIL: gcc.dg/guality/pr45882.c  -Os  line 16 b == 7
FAIL: gcc.dg/guality/pr45882.c  -Os  line 16 c == 11
FAIL: gcc.dg/guality/pr45882.c  -Os  line 16 d == 112
FAIL: gcc.dg/guality/pr45882.c  -Os  line 16 e == 142

[Bug c/50216] New: Double computations yield incorrect results

[williamsmth597 at gmail dot com]

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

 Bug #: 50216
   Summary: Double computations yield incorrect results
Classification: Unclassified
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: williamsmth...@gmail.com


Created attachment 25121
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25121
.i output from compilation

Under certain circumstances, complex double formulas result in incorrect
results.  Re-writing (breaking the formula into smaller statements), yields
correct results.

[Bug c/50216] Double computations yield incorrect results

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Andrew Pinski  2011-08-27 
20:59:00 UTC ---
The cast works as 0.4l is of type long double so you are calulating it in long
double really.
du * 0.4l / (log(zu / z0) - puz) is really:
((long double)du)* 0.4l / (long double)(log(zu / z0) - puz)