[Bug c++/46145] [C++0x] Should defaulted copy constructor imply default move constructor?

[tom.prince at ualberta dot net]

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

--- Comment #1 from tom.prince at ualberta dot net 2010-10-23 04:55:18 UTC ---
Created attachment 22131
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22131
Test case

[Bug c++/46145] New: [C++0x] Should defaulted copy constructor imply default move constructor?

[tom.prince at ualberta dot net]

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

   Summary: [C++0x] Should defaulted copy constructor imply
default move constructor?
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tom.pri...@ualberta.net


Does a class with an explicitly defaulted const& copy constructor have a
default move constructor?   n3126: 12.8.11 seems to indicate that it should.

However, the attached test case doesn't work.

[Bug middle-end/45720] [4.6 regression] Revision 164367 miscompiled SPEC CPU 2K

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #13 from H.J. Lu  2010-10-23 02:08:57 
UTC ---
Fixed as of revision 165840.

[Bug middle-end/46142] [4.6 Regression] FMA test failures

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  2010-10-23 00:46:01 
UTC ---
On Fedora 13/x86-64, you can use

CC="gcc -m32" CXX="g++ -m32" ../src-trunk/configure i686-linux

to bootstrap 32bit gcc.  You need to install 32bit libraries
used by gcc.

[Bug middle-end/46142] [4.6 Regression] FMA test failures

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2010-10-23 00:41:49 
UTC ---
I got

./xgcc -B./ -S ../../src-trunk/gcc/testsuite/gcc.target/i386/fma3-builtin-2.c
-O3 -mfma -mno-fma4 -S  
../../src-trunk/gcc/testsuite/gcc.target/i386/fma3-builtin-2.c: In function
‘vector_fma’:
../../src-trunk/gcc/testsuite/gcc.target/i386/fma3-builtin-2.c:19:1: internal
compiler error: in vect_is_simple_use_1, at tree-vect-stmts.c:5288
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/46142] [4.6 Regression] FMA test failures

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2010-10-23 00:40:08 
UTC ---
I saw

FAIL: gcc.target/i386/fma3-builtin-2.c (internal compiler error)
FAIL: gcc.target/i386/fma3-builtin-2.c (test for excess errors)
FAIL: gcc.target/i386/fma4-builtin-2.c (internal compiler error)
FAIL: gcc.target/i386/fma4-builtin-2.c (test for excess errors)

only 32bit gcc, not with 64bit gcc using -m32. It could be the 32bit HWI
problem.

[Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc

[jiez at gcc dot gnu.org]

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

--- Comment #23 from Jie Zhang  2010-10-23 00:38:16 
UTC ---
Author: jiez
Date: Sat Oct 23 00:38:13 2010
New Revision: 165880

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165880
Log:
PR rtl-optimization/37360
* config/mips/mips.c (cached_can_issue_more): New local variable.
(mips_sched_reorder_1): New.
(mips_sched_reorder): Use mips_sched_reorder_1.
(mips_sched_reorder2): New.
(mips_variable_issue): Set cached_can_issue_more.
(TARGET_SCHED_REORDER2): Define to mips_sched_reorder2
instead of mips_sched_reorder.

Revert
2008-09-09  Andrey Belevantsev  
PR rtl-optimization/37360
* haifa-sched.c (max_issue): Do not assert that we never issue more
insns than issue_rate.  Add comment.

testsuite/
PR rtl-optimization/37360
* gcc.dg/pr37360.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr37360.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/mips.c
trunk/gcc/haifa-sched.c
trunk/gcc/testsuite/ChangeLog

[Bug target/46144] [4.6 regression] gfortran.dg/vect/fast-math-vect-8.f90

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org
   Target Milestone|--- |4.6.0

--- Comment #1 from H.J. Lu  2010-10-23 00:34:29 
UTC ---
It is caused by revision 165856:

http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg01042.html

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[ian at airs dot com]

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

--- Comment #31 from Ian Lance Taylor  2010-10-22 23:55:44 
UTC ---
As I understand this, this is a request for a warning for any definition of a
global variable.  Is that correct?

Such a warning certainly can not be part of -Wall or -Wextra.  Global variables
are part of the C/C++ language and it is not incorrect for code to use them.

While global variables are the more common source of problems here, you can
also have problems due to multiple functions with the same name.  The proposed
option will not help with that case.  For example, you will get multiple
functions if you have two different C++ classes with the same name, and each
defines a method with the same name (perhaps the constructor or destructor),
and the method is declared as inline (perhaps because it was defined within the
class definition), and the methods are called, and the calls are not inlined
(perhaps because the code was compiled without optimization).

So I do not think that an option warning about global variables is a complete
solution for the problem you are describing.  I also think that such a warning
would be highly special purpose.

Unless we have a clear sign of demand for the proposed option, I would prefer
to see it implemented as a plugin rather than as a general compiler option.

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #30 from Ian Lance Taylor  2010-10-22 23:49:16 
UTC ---
The gold linker has a --detect-odr-violations option, which is reasonably
effective when used with C++ code which is compiled with -g and without any
optimization.

[Bug target/46144] New: [4.6 regression] gfortran.dg/vect/fast-math-vect-8.f90

[hjl.tools at gmail dot com]

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

   Summary: [4.6 regression] gfortran.dg/vect/fast-math-vect-8.f90
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, revision 165861 gave

export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/vect/fast-math-vect-8.f90
  -O2 -ftree-vectorize -fno-vect-cost-model -ftree-vectorizer-verbose=4
-fdump-tree-vect-stats -msse2 -ffast-math -S  -m32 -o fast-math-vect-8.s   
(timeout = 300)
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/vect/fast-math-vect-8.f90:
In function 'init_solve':^M
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/vect/fast-math-vect-8.f90:59:0:
error: insn does not satisfy its constraints:^M
(insn 724 701 702 28 (set (reg:V4SF 25 xmm4 [361])^M
(xor:V4SF (reg:V4SF 23 xmm2 [orig:229 vect_var_.79 ] [229])^M
(reg:V4SF 25 xmm4 [361])))
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/vect/fast-math-vect-8.f90:69
1265 {*xorv4sf3}^M
 (nil))^M
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/vect/fast-math-vect-8.f90:59:0:
internal compiler error: in copyprop_hardreg_forward_1, at regcprop.c:768^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See  for instructions.^M

Revision 165848 is OK.

[Bug c++/46143] __attribute__((optimize)) emits wrong code

[scovich at gmail dot com]

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

--- Comment #4 from Ryan Johnson  2010-10-22 23:06:53 
UTC ---
As I said, the stack smashing was only there to make the behavior consistent.
If the offending stack location happens to contain zero, the bug would go
unnoticed (try adding 'long n[1]' as another local, for me it makes the symptom
go away unless the stack smash exposes it.

In any case, here's a minimal testcase which doesn't do anything evil:

#include 
#include 

typedef std::vector intv;

int
#ifdef BUG
__attribute__((optimize(0)))
#endif
main() {
intv v;
intv::iterator it = v.begin();
assert(it == v.begin());
return 0;
}

[Bug c++/46143] __attribute__((optimize)) emits wrong code

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2010-10-22 
22:53:17 UTC ---
here's one which avoids invalid iterators and stack smashing:


#include 
#include 

struct foo { };
typedef std::vector foov;

foov v(1);

int
#ifdef BUG
__attribute__((optimize(0)))
#endif
main() {
foov::iterator it = v.begin();
assert( &*it == &v.front() );
return 0;
}

[Bug fortran/46140] [4.4/4.5/4.6 Regression] Include not found - but exit status code is zero

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  
2010-10-22 22:48:54 UTC ---
On Fri, Oct 22, 2010 at 09:42:36PM +, kargl at gcc dot gnu.org wrote:
> 
> Index: scanner.c
> ===
> --- scanner.c   (revision 165861)
> +++ scanner.c   (working copy)
> @@ -1867,7 +1867,9 @@ include_line (gfc_char_t *line)
>read by anything else.  */
> 
>filename = gfc_widechar_to_char (begin, -1);
> -  load_file (filename, NULL, false);
> +  if (load_file (filename, NULL, false) == FAILURE)
> +exit (1);
> +  
>gfc_free (filename);
>return true;
>  }
> 

The above patch passes regression testing without
any new regressions.

[Bug c++/46143] __attribute__((optimize)) emits wrong code

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2010-10-22 
22:47:09 UTC ---
that program has two kinds of undefined behaviour I can see

not only do two wrongs not make a right, but attribute((optimize(0))) doesn't
make it right either

do you have a testcase that doesn't rely on dereferencing a non-dereferenceable
iterator?

[Bug c++/46143] __attribute__((optimize)) emits wrong code

[scovich at gmail dot com]

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

Ryan Johnson  changed:

   What|Removed |Added

  Attachment #22129|0   |1
is obsolete||

--- Comment #1 from Ryan Johnson  2010-10-22 22:18:16 
UTC ---
Created attachment 22130
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22130
Test case showing wrong code with __attribute__((optimize(0)))

Oops... the previous version had stray marks from emacs+gdb.

[Bug c++/46143] New: __attribute__((optimize)) emits wrong code

[scovich at gmail dot com]

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

   Summary: __attribute__((optimize)) emits wrong code
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: scov...@gmail.com


Created attachment 22129
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22129
Test case showing wrong code with __attribute__((optimize(0)))

Applying '__attribute__((optimize(0)))' to a function causes it to call the
wrong variant/clone of an optimized callee that returns a struct by value.

The attached test case reproduces the problem when compiled with `g++ -O3 -DBUG
bug.cpp' 

The problem seems to be the way gcc optimizes return-by-value. The statement:

iterator it = v.begin()

becomes

tmp = alloca(sizeof(iterator))
vector::begin(tmp, &v)
iterator it(*(iterator*)tmp)

However, gcc actually calls the wrong variant of vector::begin, with the latter
thinking its first argument is &v._M_impl._M_start (an iterator to be copied)
and which has optimized away the struct completely to return only a pointer. It
therefore allocates a temporary and proceeds to "initialize" it using the
(uninitialized) return-value it was passed, then returns the temporary's
contents to the caller (main). As a result, 'it' points to whatever happened to
be on the stack at the time of the call. 

Note that the test case smashes the stack only to make the symptoms consistent;
the bug remains with or without it.

The relevant disassembly follows:

main:
# call vector::begin(&rval_ptr, &v)
subq$24, %rsp# allocate hidden tmp1
movqv(%rip), %rdx
movq%rdx, %rsi   # second arg is &v
movq%rsp, %rdi   # first arg is &tmp1
call_ZNSt6vectorIP3fooSaIS1_EE5beginEv.clone.1
...

_ZNSt6vectorIP3fooSaIS1_EE5beginEv.clone.1:
subq$24, %rsp# allocate hidden tmp2
movq%rdi, %rsi   # second arg expects &v but gets &tmp1
movq%rsp, %rdi   # first arg is &tmp2
call   
_ZN9__gnu_cxx17__normal_iteratorIPP3fooSt6vectorIS2_SaIS2_EEEC2ERKS3_.clone.0
movq(%rsp), %rax # return the contents of tmp2
addq$24, %rsp
ret

_ZN9__gnu_cxx17__normal_iteratorIPP3fooSt6vectorIS2_SaIS2_EEEC2ERKS3_.clone.0:
movq%rsi, (%rdi) # tmp2 = tmp1
ret

[Bug middle-end/46142] New: [4.6 Regression] FMA test failures

[hjl.tools at gmail dot com]

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

   Summary: [4.6 Regression] FMA test failures
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: r...@gcc.gnu.org


On Linux/ia32,  revision 165859 gave

FAIL: gcc.target/i386/fma3-builtin-2.c (internal compiler error)
FAIL: gcc.target/i386/fma3-builtin-2.c (test for excess errors)
FAIL: gcc.target/i386/fma4-builtin-2.c (internal compiler error)
FAIL: gcc.target/i386/fma4-builtin-2.c (test for excess errors)
FAIL: gfortran.dg/vect/fast-math-vect-8.f90 (internal compiler error)
FAIL: gfortran.dg/vect/fast-math-vect-8.f90 (test for excess errors)
ERROR: gcc.target/i386/fma3-builtin-2.c: error executing dg-final: couldn't
open "fma3-builtin-2.s": no such file or directory
ERROR: gcc.target/i386/fma4-builtin-2.c: error executing dg-final: couldn't
open "fma4-builtin-2.s": no such file or directory

Revision 165851 is OK.

[Bug c/46141] -fno-builtin-strstr changes __builtin_strstr

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Andrew Pinski  2010-10-22 
21:48:42 UTC ---
This is the correct behavior.  -fno-builtin-strstr means strstr is not a
builtin so it is not associated with __builtin_strstr and not merged.

[Bug c/46141] New: -fno-builtin-strstr changes __builtin_strstr

[hjl.tools at gmail dot com]

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

   Summary: -fno-builtin-strstr changes __builtin_strstr
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


I don't expect -fno-builtin-strstr to change the behavior
of __builtin_strstr.  But I got

[...@gnu-6 asm-1]$ cat x.c
extern char *strstr(const char *, const char *) __asm ("my_strstr");
char *foo (const char *a, const char *b)
{
  return __builtin_strstr (a, b);
}
[...@gnu-6 asm-1]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O -S x.c
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -fno-builtin-strstr -O -S x.c
-o y.s
[...@gnu-6 asm-1]$ cat x.s 
.file"x.c"
.text
.globlfoo
.typefoo, @function
foo:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
callmy_strstr
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.sizefoo, .-foo
.ident"GCC: (GNU) 4.6.0 20101021 (experimental)"
.section.note.GNU-stack,"",@progbits
[...@gnu-6 asm-1]$ cat y.s
.file"x.c"
.text
.globlfoo
.typefoo, @function
foo:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
callstrstr
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.sizefoo, .-foo
.ident"GCC: (GNU) 4.6.0 20101021 (experimental)"
.section.note.GNU-stack,"",@progbits
[...@gnu-6 asm-1]$ 

Shouldn't my_strstr be generated with -fno-builtin-strstr?

[Bug fortran/46140] [4.4/4.5/4.6 Regression] Include not found - but exit status code is zero

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org 2010-10-22 21:42:33 UTC ---
A patch as simple as

Index: scanner.c
===
--- scanner.c   (revision 165861)
+++ scanner.c   (working copy)
@@ -1867,7 +1867,9 @@ include_line (gfc_char_t *line)
   read by anything else.  */

   filename = gfc_widechar_to_char (begin, -1);
-  load_file (filename, NULL, false);
+  if (load_file (filename, NULL, false) == FAILURE)
+exit (1);
+  
   gfc_free (filename);
   return true;
 }

gives an exit status

troutmask:sgk[205] gfc4x -o z t.f90
t.f90:2: Error: Can't open included file 'notthere.inc'
troutmask:sgk[206] gfc4x -o z t.f90 ; echo $?
t.f90:2: Error: Can't open included file 'notthere.inc'
1

[Bug fortran/46140] [4.4/4.5/4.6 Regression] Include not found - but exit status code is zero

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2010-10-22 
21:20:16 UTC ---
(In reply to comment #1)
> Someone named Tobias broke this with

Which was part of the fix for PR 37821. The issue was that the file name of the
including file was not printed before.

I think there is another issue besides the missing exit status code: I think
the error message is always printed in English. I think one needs at least to
use _(...) or to use another mechanism.

Maybe one should try again to use gfc_error_now - but one needs somehow to make
the locus available - maybe by constructing one and passing it via %L? Or maybe
using a simple "at %C" works?

[Bug libstdc++/46139] bug in std::binary_search realisation

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Paolo Carlini  2010-10-22 
21:06:34 UTC ---
Thanks Jon.

[Bug c++/46103] [c++0x] moving from std::array copies the elements

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jason Merrill  2010-10-22 
20:55:59 UTC ---
Fixed.

[Bug libstdc++/46139] bug in std::binary_search realisation

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2010-10-22 
20:54:43 UTC ---
The standard is *very* clear about the operations used by binary_search and
both ahttp://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#631 which
was declared Not A Defect

[Bug libstdc++/46139] bug in std::binary_search realisation

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  2010-10-22 
20:51:51 UTC ---
I think this is invalid. The Standard talks exactly about the comparisons which
we are doing, ie, assumes are well formed, both for lower_bound and for
binary_search itself. Indeed, both the Dinkumware (the library delivered with
the Microsoft compiler) and the Roguewave (the library delivered with
SunStudio) implementations reject your snippets with the same error.

[Bug fortran/46140] [4.4/4.5/4.6 Regression] Include not found - but exit status code is zero

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2010-10-22 20:51:21 UTC ---
Someone named Tobias broke this with

troutmask:sgk[206] svn diff -r 141543:141544 | more

@@ -1791,7 +1802,8 @@ load_file (const char *realfilename, con
   input = gfc_open_included_file (realfilename, false, false);
   if (input == NULL)
{
- gfc_error_now ("Can't open included file '%s'", filename);
+ fprintf (stderr, "%s:%d: Error: Can't open included file '%s'\n",
+  current_file->filename, current_file->line, filename);
  return FAILURE;
}
 }

where the return value of load_file is never checked.

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[redi at gcc dot gnu.org]

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

--- Comment #29 from Jonathan Wakely  2010-10-22 
20:36:45 UTC ---
(In reply to comment #28)
> > Are those libraries that crash designed to be used via dlopen, rather than
> > linking to them explicitly?
> Apparently they are (the authors would have marked the shared object with the 
> nodlopen option :/).

that would imply they RTFM ;)

I'm not sure I can contribute anything more useful to this PR. I think it would
be awesome the compiler or linker could diagnose ODR violations, but I have no
idea how to go about doing that.  Personally I don't think a warning about
using global variables is the right solution unless it can be tuned to only
warn about potentially dangerous cases.

I'm not going to close this PR as invalid though, if someone else can see how
to make a useful warning then I'd be all for it

[Bug fortran/46140] New: [4.4/4.5/4.6 Regression] Include not found - but exit status code is zero

[burnus at gcc dot gnu.org]

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

   Summary: [4.4/4.5/4.6 Regression] Include not found - but exit
status code is zero
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Reported by Thomas Jahns by email and at
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561245

Compiling the following program gives
  Error: Can't open included file 'notthere.inc'

However, using GCC 4.4, 4.5 and 4.6 the exit status code is zero:

$ gfortran-4.3 test.f90; echo $?
Error: Can't open included file 'notthere.inc'
1

$ gfortran-4.4 test.f90; echo $?
test.f90:2: Error: Can't open included file 'notthere.inc'
0


program testinc
  include 'notthere.inc'
  print *, 'I''m running although I shouldn''t even compile.'
end program

[Bug tree-optimization/46137] [4.6 Regression] g++.dg/torture/pr45877.C FAILs with -fno-tree-dce

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Richard Guenther  2010-10-22 
20:11:39 UTC ---
Fixed.

[Bug libstdc++/46139] New: bug in std::binary_search realisation

[emathemat at gmail dot com]

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

   Summary: bug in std::binary_search realisation
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: emathe...@gmail.com


Created attachment 22128
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22128
files with problem cpps, workarounds and patches

Platform:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) 


Problem:
1) it is unable to compile std::binary_search with compare function, if type of
searched value mismatch container::value_type (see binary_search_*.cpp in
attached archive)

Compile Error for binary_search_left.cpp: 
g++ -Wall -o "binary_search_left" "binary_search_left.cpp" (in directory:
/home/hotdox/tmp)
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/algorithm:62,
 from binary_search_left.cpp:2:
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_algo.h:
In function ‘bool std::binary_search(_FIter, _FIter, const _Tp&, _Compare)
[with _FIter = __gnu_cxx::__normal_iterator > >, _Tp = TStruct, _Compare = bool (*)(int, const
TStruct&)]’:
binary_search_left.cpp:30:   instantiated from here
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_algo.h:2798:
error: cannot convert ‘const TStruct’ to ‘int’ in argument passing
Compilation failed.

Compile Error for binary_search_rigth.cpp: 
g++ -Wall -o "binary_search_rigth" "binary_search_rigth.cpp" (in directory:
/home/hotdox/tmp)
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/algorithm:62,
 from binary_search_rigth.cpp:2:
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_algo.h:
In function ‘_FIter std::lower_bound(_FIter, _FIter, const _Tp&, _Compare)
[with _FIter = __gnu_cxx::__normal_iterator > >, _Tp = TStruct, _Compare = bool (*)(const TStruct&,
int)]’:
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_algo.h:2797:
  instantiated from ‘bool std::binary_search(_FIter, _FIter, const _Tp&,
_Compare) [with _FIter = __gnu_cxx::__normal_iterator > >, _Tp = TStruct, _Compare = bool (*)(const TStruct&,
int)]’
binary_search_rigth.cpp:30:   instantiated from here
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_algo.h:2495:
error: invalid initialization of reference of type ‘const TStruct&’ from
expression of type ‘int’
Compilation failed.


2) it is unable to compile std::binary_search with compare functor with one
nameless operator, if type of searched value mismatch container::value_type
(see binary_search_functor_*.cpp in attached archive)

Compile Error for binary_search_functor_left.cpp: 
g++ -Wall -o "binary_search_functor_left" "binary_search_functor_left.cpp" (in
directory: /home/hotdox/tmp)
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/algorithm:62,
 from binary_search_functor_left.cpp:2:
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_algo.h:
In function ‘bool std::binary_search(_FIter, _FIter, const _Tp&, _Compare)
[with _FIter = __gnu_cxx::__normal_iterator > >, _Tp = TStruct, _Compare = TComparator]’:
binary_search_functor_left.cpp:32:   instantiated from here
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_algo.h:2798:
error: no match for call to ‘(TComparator) (const TStruct&, int&)’
binary_search_functor_left.cpp:14: note: candidates are: bool
TComparator::operator()(int, const TStruct&)
Compilation failed.

Compile Error for binary_search_functor_rigth.cpp:
g++ -Wall -o "binary_search_functor_rigth" "binary_search_functor_rigth.cpp"
(in directory: /home/hotdox/tmp)
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/algorithm:62,
 from binary_search_functor_rigth.cpp:2:
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_algo.h:
In function ‘_FIter std::lower_bound(_FIter, _FIter, const _Tp&, _Co

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #28 from Jeffrey Walton  2010-10-22 
19:49:26 UTC ---
(In reply to comment #26)
> I don't think dlmopen has anything to do with C++ namespaces, but I could be
> wrong
> 
> Are those libraries that crash designed to be used via dlopen, rather than
> linking to them explicitly?
Apparently they are (the authors would have marked the shared object with the 
nodlopen option :/). And in the case of nodlopen, I simply get back NULL, which
I can handle.

[Bug tree-optimization/46099] [4.5/4.6 Regression] ICE: in replace_ssa_name, at tree-cfg.c:5643 with -ftree-parallelize-loops -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2010-10-22 
19:06:27 UTC ---
The problem is that eliminate_local_variables{,_1} calls take_address_of on
ADDR_EXPR etc. in debug stmt expressions.  That affects code generation, so
definitely must not be done.  Either we need to first eliminate local variables
in normal stmts and then do separate processing on debug stmts, where those for
which take_address_of did something would use it, but it wouldn't create new
hash entries and otherwise just reset debug stmts or something, or we need to
reset them right away.

[Bug tree-optimization/46137] [4.6 Regression] g++.dg/torture/pr45877.C FAILs with -fno-tree-dce

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2010-10-22 
19:03:43 UTC ---
Author: rguenth
Date: Fri Oct 22 19:03:39 2010
New Revision: 165852

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165852
Log:
2010-10-22  Richard Guenther  

PR middle-end/46137
* gimple-fold.c (gimplify_and_update_call_from_tree): Properly
remove the virtual operands if they are not needed.

* c-c++-common/torture/pr46137.c: New testcase.

Added:
trunk/gcc/testsuite/c-c++-common/torture/pr46137.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/46129] [4.6 Regression] ICE: in tsubst_copy, at cp/pt.c:11375

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||FIXED

--- Comment #4 from Jason Merrill  2010-10-22 
18:48:02 UTC ---
Fixed.

[Bug c++/46134] constexpr vs. defaulted ctor

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||INVALID

--- Comment #2 from Jason Merrill  2010-10-22 
18:47:15 UTC ---
Not a bug.

[Bug c++/46129] [4.6 Regression] ICE: in tsubst_copy, at cp/pt.c:11375

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2010-10-22 
18:37:58 UTC ---
Author: jason
Date: Fri Oct 22 18:37:53 2010
New Revision: 165850

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165850
Log:
PR c++/46129
* pt.c (instantiate_class_template): Don't instantiate default
arguments.

Added:
trunk/gcc/testsuite/g++.dg/template/defarg14.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/46103] [c++0x] moving from std::array copies the elements

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  2010-10-22 
18:37:46 UTC ---
Author: jason
Date: Fri Oct 22 18:37:41 2010
New Revision: 165849

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165849
Log:
PR c++/46103
* init.c (build_vec_init): Handle memberwise move.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/implicit10.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/46137] [4.6 Regression] g++.dg/torture/pr45877.C FAILs with -fno-tree-dce

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  2010-10-22 18:22:30 
UTC ---
Created attachment 22127
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22127
reduced testcase

After reducing, the testcase no longer needs -fno-tree-dce:

$ gcc -O pr46137.C 
pr46137.C: In function 'X foo(X*)':
pr46137.C:19:1: error: missing definition
for SSA_NAME: .MEM_6 in statement:
# VUSE <.MEM_6>
return D.2092;
pr46137.C:19:1: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/46137] [4.6 Regression] g++.dg/torture/pr45877.C FAILs with -fno-tree-dce

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.10.22 17:31:49
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2010-10-22 
17:31:49 UTC ---
Mine.

[Bug c++/46133] constexpr needed for C99 complex type creation from ctor with two floating point types

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||FIXED

--- Comment #1 from Jason Merrill  2010-10-22 
17:19:45 UTC ---
Fixed.

[Bug debug/46138] New: ICE: SIGSEGV in htab_hash_string (hashtab.c:847) with -g -fenable-icf-debug for almost any fortran program

[zsojka at seznam dot cz]

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

   Summary: ICE: SIGSEGV in htab_hash_string (hashtab.c:847) with
-g -fenable-icf-debug for almost any fortran program
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


 testcase.f90 
PROGRAM main
CONTAINS
END PROGRAM main
--

Compiler output:
$ gcc -g -fenable-icf-debug testcase.f90 
testcase.f90:1:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Related valgrind output:
==18307== Invalid read of size 1
==18307==at 0x10A1D90: htab_hash_string (hashtab.c:847)
==18307==by 0x6487CE: lookup_filename (dwarf2out.c:21226)
==18307==by 0x659BD3: add_src_coords_attributes (dwarf2out.c:17594)
==18307==by 0x65B36A: add_name_and_src_coords_attributes
(dwarf2out.c:17640)
==18307==by 0x670FA5: gen_subprogram_die (dwarf2out.c:18838)
==18307==by 0x665F88: force_decl_die (dwarf2out.c:20493)
==18307==by 0x66605F: dwarf2out_direct_call (dwarf2out.c:21355)
==18307==by 0x6CD8CC: final_scan_insn (final.c:2685)
==18307==by 0x6CDA9D: final (final.c:1719)
==18307==by 0x6CDED8: rest_of_handle_final (final.c:4231)
==18307==by 0x7F2B7E: execute_one_pass (passes.c:1560)
==18307==by 0x7F2E14: execute_pass_list (passes.c:1615)
==18307==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==18307== 
testcase.f90:1:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165822 - crash
r158095 - crash
4.5 r165781 - crash

[Bug tree-optimization/46137] New: [4.6 Regression] g++.dg/torture/pr45877.C FAILs with -fno-tree-dce

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] g++.dg/torture/pr45877.C FAILs with
-fno-tree-dce
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Compiler output:
$ gcc -O -fno-tree-dce pr45877.ii 
pr45877.ii: In member function 'AnyType OneBinaryOperator::Op::operator()(Stack) const [with C = set_A_BI >, MI = OneBinaryOperatorMI, MIx = evalE_F2, AnyType =
AnyTypeWithOutCheck, Stack = void*]':
pr45877.ii:103:15: error: missing definition
for SSA_NAME: .MEM_26 in statement:
# VUSE <.MEM_26>
return D.2855;
pr45877.ii:103:15: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165822 - crash
r161659 - crash
r159696 - OK

[Bug target/46098] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.6.0   |4.5.2

--- Comment #8 from Uros Bizjak  2010-10-22 16:23:24 
UTC ---
Fixed.

[Bug target/45946] ICE: in extract_insn, at recog.c:2127 when using _Decimal128 with -Os -fno-omit-frame-pointer

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

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

--- Comment #7 from Uros Bizjak  2010-10-22 16:21:36 
UTC ---
Fixed.

[Bug target/46098] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org 2010-10-22 16:18:53 UTC ---
Author: uros
Date: Fri Oct 22 16:18:41 2010
New Revision: 165846

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165846
Log:
PR target/46098
* config/i386/sse.md (*avx_movup):
Rename from avx_movup.
(avx_movup): New expander.
(*_movup): Rename from
_movup.
(_movup): New expander.
(*avx_movdqu): Rename from avx_movdqu.
(avx_movdqu): New expander.
(*sse2_movdqu): Rename from sse2_movdqu.
(sse2_movdqu): New expander.

testsuite/ChangeLog:

PR target/46098
* gcc.target/i386/pr46098.c: New test.


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

[Bug target/46098] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org 2010-10-22 16:13:04 UTC ---
Author: uros
Date: Fri Oct 22 16:12:57 2010
New Revision: 165845

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165845
Log:
PR target/46098
* config/i386/sse.md (*avx_movu):
Rename from avx_movu.
(avx_movu): New expander.
(*_movu): Rename from _movu.
(_movu): New expander.
(*avx_movdqu): Rename from avx_movdqu.
(avx_movdqu): New expander.
(*sse2_movdqu): Rename from sse2_movdqu.
(sse2_movdqu): New expander.

testsuite/ChangeLog:

PR target/46098
* gcc.target/i386/pr46098.c: New test.


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

[Bug debug/46136] New: ICE: in size_of_dcall_table, at dwarf2out.c:12387 with -fenable-icf-debug

[zsojka at seznam dot cz]

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

   Summary: ICE: in size_of_dcall_table, at dwarf2out.c:12387 with
-fenable-icf-debug
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


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

Compiler output:
$ gcc -g -fenable-icf-debug pr46136.C 
pr46136.C:14:4: internal compiler error: in size_of_dcall_table, at
dwarf2out.c:12387
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165822 - crash
r161659 - crash
r153685 - crash

[Bug debug/46135] New: ICE: in splice_child_die, at dwarf2out.c:7627 with -g1 -femit-class-debug-always -fenable-icf-debug

[zsojka at seznam dot cz]

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

   Summary: ICE: in splice_child_die, at dwarf2out.c:7627 with -g1
-femit-class-debug-always -fenable-icf-debug
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


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

Compiler output:
$ gcc -g1 -femit-class-debug-always -fenable-icf-debug -fkeep-inline-functions
pr46135.C  
pr46135.C: In member function 'S S::f()':
pr46135.C:8:3: internal compiler error: in splice_child_die, at
dwarf2out.c:7874
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165822 - crash
r158095 - crash
r153685 - OK
4.5 r165781 - crash

[Bug c++/46134] constexpr vs. defaulted ctor

[bkoz at gcc dot gnu.org]

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

--- Comment #1 from Benjamin Kosnik  2010-10-22 
15:31:36 UTC ---
Created attachment 22124
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22124
pre-processed sources

[Bug c++/46134] New: constexpr vs. defaulted ctor

[bkoz at gcc dot gnu.org]

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

   Summary: constexpr vs. defaulted ctor
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b...@gcc.gnu.org


Changing std::chrono::duration's default constructor to "default" from an empty
body causes a new error.

Ie:

diff --git a/libstdc++-v3/include/std/chrono b/libstdc++-v3/include/std/chrono
index bbcb0ff..d346049 100644
--- a/libstdc++-v3/include/std/chrono
+++ b/libstdc++-v3/include/std/chrono
@@ -209,7 +209,7 @@ namespace std
static_assert(_Period::num > 0, "period must be positive");

// 20.8.3.1 construction / copy / destroy
-   constexpr duration() { }
+   constexpr duration() = default;

template::value


See attached pre-processed file for simple reproducer. Error message is:

In file included from
/mnt/share/src/gcc.git-constexpr/libstdc++-v3/testsuite/20_util/duration/cons/constexpr.cc:22:0:
/mnt/share/src/gcc.git-constexpr/libstdc++-v3/testsuite/util/testsuite_common_types.h:
In member function ‘void
__gnu_test::constexpr_default_constructible::operator()()::_Concept::__constraint()
[with _Tp = std::chrono::duration]’:
/mnt/share/src/gcc.git-constexpr/libstdc++-v3/testsuite/util/testsuite_common_types.h:629:17:
  instantiated from ‘void
__gnu_test::constexpr_default_constructible::operator()() [with _Tp =
std::chrono::duration]’
/mnt/share/src/gcc.git-constexpr/libstdc++-v3/testsuite/20_util/duration/cons/constexpr.cc:27:48:
  instantiated from here
/mnt/share/src/gcc.git-constexpr/libstdc++-v3/testsuite/util/testsuite_common_types.h:625:20:
error: uninitialized const ‘__v’ [-fpermissive]
/mnt/share/bld/gcc.git-constexpr/x86_64-unknown-linux-gnu/libstdc++-v3/include/chrono:201:14:
note: ‘const struct std::chrono::duration’ has no user-provided
default constructor
/mnt/share/bld/gcc.git-constexpr/x86_64-unknown-linux-gnu/libstdc++-v3/include/chrono:212:12:
note: constructor is not user-provided because it is explicitly defaulted in
the class body

[Bug target/45946] ICE: in extract_insn, at recog.c:2127 when using _Decimal128 with -Os -fno-omit-frame-pointer

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org 2010-10-22 15:15:22 UTC ---
Author: uros
Date: Fri Oct 22 15:15:16 2010
New Revision: 165836

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165836
Log:
PR target/45946
* config/i386/i386.md (*pushti2): New insn pattern.
(pushti2 splitter): New insn splitter.

testsuite/ChangLog:

PR target/45946
* gcc.target/i386/pr45946.c: New test.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr45946.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/i386/i386.md
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog

[Bug middle-end/46131] Some TLS execution tests fail on Tru64 UNIX with emutls

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  2010-10-22 14:59:32 UTC ---
> --- Comment #3 from Richard Henderson  2010-10-22 
> 14:51:59 UTC ---
> I don't see anything wrong in the assembler code for
> the test case.  I think you'll need to debug the libgcc
> routines to see what's going wrong in between there and
> the system thread library.

Ok, I'll have a look.  This will have to wait for a couple of days since
I'll be away on a short vacation in a few minutes.

Rainer

[Bug c++/46133] New: constexpr needed for C99 complex type creation from ctor with two floating point types

[bkoz at gcc dot gnu.org]

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

   Summary: constexpr needed for C99 complex type creation from
ctor with two floating point types
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b...@gcc.gnu.org


Small reproducer:

struct complex
{
  typedef float value_type;
  typedef __complex__ float _ComplexT;

  constexpr complex(_ComplexT __z) : _M_value(__z) { }

  constexpr complex(float __r = 0.0f, float __i = 0.0f)
  : _M_value(__r + __i * 1.0fi) { }

private:
  _ComplexT _M_value;
};

constexpr complex c1;

Gives:

%$bin/H-x86_64-gcc-constexpr.20101022/bin/g++ -c -std=gnu++0x complex_wanna.cc
complex_wanna.cc:16:19: error: ‘(__complex__ float){0.0f, 0.0f}’ is not a
constant expression
complex_wanna.cc:16:19: error: in expansion of ‘complex(0.0f, 0.0f)’

[Bug middle-end/46131] Some TLS execution tests fail on Tru64 UNIX with emutls

[rth at gcc dot gnu.org]

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

--- Comment #3 from Richard Henderson  2010-10-22 
14:51:59 UTC ---
I don't see anything wrong in the assembler code for
the test case.  I think you'll need to debug the libgcc
routines to see what's going wrong in between there and
the system thread library.

Of course this test passes at -O3 because in that
case we inline the function and simplify everything
away entirely.

[Bug debug/46132] New: ICE: in force_decl_die, at dwarf2out.c:20525 with -fenable-icf-debug

[zsojka at seznam dot cz]

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

   Summary: ICE: in force_decl_die, at dwarf2out.c:20525 with
-fenable-icf-debug
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


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

Compiler output:
$ gcc -O -g -fenable-icf-debug pr46132.c 
pr46132.c: In function 'regex_subst':
pr46132.c:5:1: internal compiler error: in force_decl_die, at dwarf2out.c:20525
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Compiler output - 4.5:
$ gcc -O -g -fenable-icf-debug pr46132.c 
pr46132.c: In function 'foo':
pr46132.c:4:1: internal compiler error: tree check: expected tree that contains
'decl minimal' structure, have 'string_cst' in lookup_decl_die, at
dwarf2out.c:7701
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Another issue with -fenable-icf-debug is PR44689

Tested revisions:
r165822 - crash
r153685 - crash
4.5 r165781 - crash

[Bug middle-end/45720] [4.6 regression] Revision 164367 miscompiled SPEC CPU 2K

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther  2010-10-22 
14:44:53 UTC ---
Author: rguenth
Date: Fri Oct 22 14:44:48 2010
New Revision: 165832

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165832
Log:
2010-10-22  Richard Guenther  

PR tree-optimization/45720
* tree-vect-data-refs.c (vect_update_misalignment_for_peel):
Handle negative step.
(vect_enhance_data_refs_alignment): Likewise.
* tree-vect-loop-manip.c (vect_gen_niters_for_prolog_loop): Likewise.
(vect_create_cond_for_align_checks): Likewise.
(vect_create_cond_for_alias_checks): Likewise.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr45720.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c
trunk/gcc/tree-vect-loop-manip.c

[Bug middle-end/46131] Some TLS execution tests fail on Tru64 UNIX with emutls

[ro at gcc dot gnu.org]

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

--- Comment #2 from Rainer Orth  2010-10-22 14:38:17 UTC 
---
Btw, this might be the root cause for PR target/45693.

[Bug middle-end/46131] Some TLS execution tests fail on Tru64 UNIX with emutls

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  2010-10-22 14:37:37 UTC 
---
Created attachment 22122
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22122
assembler output

[Bug middle-end/46131] New: Some TLS execution tests fail on Tru64 UNIX with emutls

[ro at gcc dot gnu.org]

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

   Summary: Some TLS execution tests fail on Tru64 UNIX with
emutls
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: r...@gcc.gnu.org
  Host: alpha-dec-osf5.1b
Target: alpha-dec-osf5.1b
 Build: alpha-dec-osf5.1b


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

Some TLS execution tests fail on Tru64 UNIX V5.1B.  The platform has no native
TLS support, so emutls is in use:

FAIL: g++.dg/tls/diag-1.C (internal compiler error)
FAIL: g++.dg/tls/diag-1.C (test for excess errors)
FAIL: g++.dg/tls/static-1.C execution test
FAIL: gcc.dg/tls/opt-11.c execution test
FAIL: gcc.dg/tls/opt-12.c execution test
FAIL: gcc.dg/tls/thr-init-2.c execution test
FAIL: gcc.dg/torture/tls/thr-init-2.c  -O0  execution test
FAIL: gcc.dg/torture/tls/thr-init-2.c  -O1  execution test
FAIL: gcc.dg/torture/tls/thr-init-2.c  -Os  execution test
FAIL: objc.dg/torture/tls/thr-init-2.m  -O0  execution test
FAIL: objc.dg/torture/tls/thr-init-2.m  -O1  execution test
FAIL: objc.dg/torture/tls/thr-init-2.m  -Os  execution test
FAIL: objc.dg/torture/tls/thr-init.m  -O0  execution test
FAIL: objc.dg/torture/tls/thr-init.m  -O1  execution test
FAIL: objc.dg/torture/tls/thr-init.m  -Os  execution test

As an example, I've looked at the gcc.dg/tls/thr-init-2.c case: it aborts. 
With
the abort replaced by a printf, I find:

$ gcc -o thr-init-2.exe thr-init-2.c
$ ./thr-init-2.exe 
a = 2 fstat = 1

The test fails at -O0 and -O1, but passes at -O3 and higher.
I'm attaching the preprocessed source and assembler output for investigation.

[Bug debug/44689] -fenable-icf-debug -fprofile-generate causes segfault in cp_function_decl_explicit_p

[zsojka at seznam dot cz]

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

--- Comment #3 from Zdenek Sojka  2010-10-22 14:33:22 
UTC ---
Created attachment 22120
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22120
different testcase

This one doesn't need -fprofile-generate

$ gcc -fenable-icf-debug -g pr44689-2.C
==20573== Invalid read of size 2
==20573==at 0x57: cp_function_decl_explicit_p (cp-objcp-common.c:164)
==20573==by 0x74F14E: gen_subprogram_die (dwarf2out.c:18861)
==20573==by 0x744B68: force_decl_die (dwarf2out.c:20493)
==20573==by 0x744C3F: dwarf2out_direct_call (dwarf2out.c:21355)
==20573==by 0x7AC4AC: final_scan_insn (final.c:2685)
==20573==by 0x7AC67D: final (final.c:1719)
==20573==by 0x7ACAB8: rest_of_handle_final (final.c:4231)
==20573==by 0x8D33DE: execute_one_pass (passes.c:1560)
==20573==by 0x8D3674: execute_pass_list (passes.c:1615)
==20573==by 0x8D3686: execute_pass_list (passes.c:1616)
==20573==by 0x8D3686: execute_pass_list (passes.c:1616)
==20573==by 0xA204E5: tree_rest_of_compilation (tree-optimize.c:422)
==20573==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==20573== 
pr44689-2.C:5:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/46130] [4.6 Regression] ICE: SIGSEGV in walk_stmt_load_store_addr_ops (gimple.c:4894) with -O2 -fno-tree-dce

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.0

--- Comment #4 from Richard Guenther  2010-10-22 
14:08:18 UTC ---
Mine.

[Bug tree-optimization/46130] [4.6 Regression] ICE: SIGSEGV in walk_stmt_load_store_addr_ops (gimple.c:4894) with -O2 -fno-tree-dce

[zsojka at seznam dot cz]

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

--- Comment #3 from Zdenek Sojka  2010-10-22 14:05:10 
UTC ---
Created attachment 22119
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22119
different crash

Very similiar testcase, but it crashes with different message:

$ gcc -O2 -fno-tree-dce pr46130-3.c 
pr46130-3.c: In function 'foo':
pr46130-3.c:16:1: internal compiler error: in split_function, at
ipa-split.c:1014
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165822 - crash
r163636 - crash
r161659 - segfault (the same as in other testcases)

[Bug tree-optimization/46130] [4.6 Regression] ICE: SIGSEGV in walk_stmt_load_store_addr_ops (gimple.c:4894) with -O2 -fno-tree-dce

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.22 13:58:34
 CC||hjl.tools at gmail dot com,
   ||rguenth at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from H.J. Lu  2010-10-22 13:58:34 
UTC ---
It is caused by revision 161655:

http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html

[Bug c++/46103] [c++0x] moving from std::array copies the elements

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.10.22 13:52:19
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug tree-optimization/46130] [4.6 Regression] ICE: SIGSEGV in walk_stmt_load_store_addr_ops (gimple.c:4894) with -O2 -fno-tree-dce

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  2010-10-22 13:48:55 
UTC ---
Created attachment 22118
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22118
another testcase

This testcase is shorter and doesn't take address of an function, but it needs
-flto

$ gcc -O2 -flto -fno-tree-dce pr46130-2.c
==30450== Invalid read of size 2
==30450==at 0x6EA541: walk_stmt_load_store_addr_ops (gimple.c:4894)
==30450==by 0xAAB87A: rebuild_cgraph_edges (cgraphbuild.c:471)
==30450==by 0x796C5E: execute_one_pass (passes.c:1560)
==30450==by 0x796EF4: execute_pass_list (passes.c:1615)
==30450==by 0x79616B: do_per_function_toporder (passes.c:1153)
==30450==by 0x7973A5: execute_ipa_pass_list (passes.c:1932)
==30450==by 0xAB09D7: cgraph_optimize (cgraphunit.c:1696)
==30450==by 0xAB0B99: cgraph_finalize_compilation_unit (cgraphunit.c:1016)
==30450==by 0x4ABB8B: c_write_global_declarations (c-decl.c:9828)
==30450==by 0x88A553: toplev_main (toplev.c:931)
==30450==by 0x658ABBC: (below main) (in /lib64/libc-2.11.2.so)
==30450==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==30450== 
pr46130-2.c: In function 'foo':
pr46130-2.c:8:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/46129] [4.6 Regression] ICE: in tsubst_copy, at cp/pt.c:11375

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #2 from H.J. Lu  2010-10-22 13:47:54 
UTC ---
It is caused by revision 165307:

http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg00490.html

[Bug tree-optimization/46130] New: [4.6 Regression] ICE: SIGSEGV in walk_stmt_load_store_addr_ops (gimple.c:4894) with -O2 -fno-tree-dce

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: SIGSEGV in
walk_stmt_load_store_addr_ops (gimple.c:4894) with -O2
-fno-tree-dce
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


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

Compiler output:
$ gcc -O2 -fno-tree-dce pr46130.c
pr46130.c: In function 'foo':
pr46130.c:15:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Related valgrind output:
==22348== Invalid read of size 2
==22348==at 0x6EA541: walk_stmt_load_store_addr_ops (gimple.c:4894)
==22348==by 0xAAB87A: rebuild_cgraph_edges (cgraphbuild.c:471)
==22348==by 0x796C5E: execute_one_pass (passes.c:1560)
==22348==by 0x796EF4: execute_pass_list (passes.c:1615)
==22348==by 0x79616B: do_per_function_toporder (passes.c:1153)
==22348==by 0x7973A5: execute_ipa_pass_list (passes.c:1932)
==22348==by 0xAB09D7: cgraph_optimize (cgraphunit.c:1696)
==22348==by 0xAB0B99: cgraph_finalize_compilation_unit (cgraphunit.c:1016)
==22348==by 0x4ABB8B: c_write_global_declarations (c-decl.c:9828)
==22348==by 0x88A553: toplev_main (toplev.c:931)
==22348==by 0x658ABBC: (below main) (in /lib64/libc-2.11.2.so)
==22348==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==22348== 
testcase.c: In function 'foo':
testcase.c:15:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Tested revisions:
r165822 - crash
r161659 - crash
r159696 - OK
4.5 r165781 - OK

[Bug rtl-optimization/46114] [4.6 regression] g++ SEGV when built with gld on Solaris 10+/x86

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  2010-10-22 13:35:08 UTC ---
> --- Comment #10 from Bernd Schmidt  2010-10-22 
> 13:24:53 UTC ---
> I'll also need preprocessed source since I'm lacking Solaris includes.  I'll 
> be
> away for a few weeks so there might be no progress on this bug during that
> time.

It should suffice to replace the includes with declarations of size_t,
abort, calloc, malloc, strcmp, and strlen in pr46114.c:

typedef unsigned int size_t;
extern void abort(void);
extern void *calloc(size_t, size_t);
extern void *malloc(size_t);
extern int strcmp(const char *, const char *);
extern size_t strlen(const char *);

I've replaced those by the corresponding includes so one can compile and
run the testcase on other platforms.

I'll be away until next tuesday myself and won't be reading email during
that time.  I very much hope this can be fixed before 4.6.0 is released.

Rainer

[Bug c++/46108] constexpr ICE: streambuf_iterator.h:97

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Jason Merrill  2010-10-22 
13:27:30 UTC ---
Fixed.

[Bug rtl-optimization/46114] [4.6 regression] g++ SEGV when built with gld on Solaris 10+/x86

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #10 from Bernd Schmidt  2010-10-22 
13:24:53 UTC ---
I'll also need preprocessed source since I'm lacking Solaris includes.  I'll be
away for a few weeks so there might be no progress on this bug during that
time.

[Bug middle-end/45720] [4.6 regression] Revision 164367 miscompiled SPEC CPU 2K

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Guenther  2010-10-22 
13:22:18 UTC ---
Created attachment 22116
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22116
untested patch

Patch which fixes the testcase (and some more).

[Bug tree-optimization/46126] [4.6 Regression] Revision 165777 failed to build 254.gap in SPEC CPU 2K

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Ira Rosen  2010-10-22 12:52:00 UTC 
---
Fixed.

[Bug tree-optimization/46126] [4.6 Regression] Revision 165777 failed to build 254.gap in SPEC CPU 2K

[irar at gcc dot gnu.org]

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

--- Comment #3 from irar at gcc dot gnu.org 2010-10-22 12:48:26 UTC ---
Author: irar
Date: Fri Oct 22 12:48:15 2010
New Revision: 165825

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

PR tree-optimization/46126
* tree-vect-stmts.c (vect_analyze_stmt): Pass NODE to
vectorizable_shift in case of basic block vectorization.


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr46126.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug bootstrap/46121] [4.6 regression] LTO bootstrap failed

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from H.J. Lu  2010-10-22 12:29:14 
UTC ---
It was fixed between revision 165780 and 165783.

[Bug target/45946] ICE: in extract_insn, at recog.c:2127 when using _Decimal128 with -Os -fno-omit-frame-pointer

[uros at gcc dot gnu.org]

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

--- Comment #5 from uros at gcc dot gnu.org 2010-10-22 12:29:09 UTC ---
Author: uros
Date: Fri Oct 22 12:29:03 2010
New Revision: 165824

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165824
Log:
PR target/45946
* config/i386/i386.md (*pushti2): New insn pattern.
(pushti2 splitter): New insn splitter.

testsuite/ChangeLog:

PR target/45946
* gcc.target/i386/pr45946.c: New test.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr45946.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/i386/i386.md
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog

[Bug middle-end/45720] [4.6 regression] Revision 164367 miscompiled SPEC CPU 2K

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.22 12:25:43
 Ever Confirmed|0   |1

--- Comment #10 from Richard Guenther  2010-10-22 
12:25:43 UTC ---
Peeling for alignment needs adjustment:

float val[256];
float x;
void __attribute__((noinline,noclone))
foo(int len, int beg)
{
  int i;
  for (i = len - 1; i >= beg; --i)
x += val[i] * 2;
}
int main()
{
  foo(256-3, 0);
  return 0;
}

segfaults.  We align &val[len-1] instead of &val[len-4].

[Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  2010-10-22 12:08:57 UTC ---
On Fri, 22 Oct 2010, Jacob.Bramley at arm dot com wrote:

> There is currently no mechanism for detecting different versions of VFP using
> the pre-processor. In C code, this is not a problem, but it is necessary
> information when writing in-line assembly code that needs to be portable 
> across
> ARM platforms.

 refers to a 
"draft ACLE" document as specifying the existing __ARM_PCS and 
__ARM_PCS_VFP preprocessor symbols.  I haven't seen that document - could 
someone post a copy/link?  Does it define symbols for VFP versions?  If 
not, perhaps it should be revised to do so?

> In that example, Siahei wrote an in-line assembly block that constructs
> scripted arguments according to EABI ('hard' variant), then calls the 
> specified
> function. However, in order to do this safely, we have to specify all the
> scratch registers in the clobber list, including D16-D31. Luckily, it seems
> that GCC accepts these in the clobber list even on VFPv3-D16, but will that
> always be the case?

Note that there may be problems clobbering D registers.  See bug 43440.  I 
don't think Richard Earnshaw's patch 
 ever got 
reviewed or pinged - it probably needs pinging.  (In general, unreviewed 
patches are best pinged about weekly.)

> More generally, it would be beneficial to be able to optimize routines using
> specific VFPv3 instructions (such as VMOV's immediate-operand form), or to 
> make
> use of VFPv4's fused-mulitply-accumulate instructions.

For fused multiply-add, the best approach is to describe them in the ARM 
.md files using the new fma: RTL facility, so that calls to fma / fmaf / 
__builtin_fma / __builtin_fmaf use the instructions automatically as on 
other targets whose .md files have been updated like this.

[Bug middle-end/45720] [4.6 regression] Revision 164367 miscompiled SPEC CPU 2K

[ubizjak at gmail dot com]

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

--- Comment #9 from Uros Bizjak  2010-10-22 11:21:27 
UTC ---
(In reply to comment #8)

> So I have no hypotheses about the reason of this exception.
> Maybe, it was indirect jump into the middle of instruction.
> I will continue attemts to create short test case after weekend.

Try to run the test under valgrind. This tool is much more powerful.

[Bug rtl-optimization/45352] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058

[zsojka at seznam dot cz]

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

--- Comment #16 from Zdenek Sojka  2010-10-22 11:17:55 
UTC ---
I gave this patch a lot of testing (compiled ~800 packages) and it seems to
solve all crashes in reset_sched_cycles_in_current_ebb, without introducing any
new problems.

[Bug fortran/46122] PROTECTED check too strict

[domob at gcc dot gnu.org]

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

--- Comment #2 from Daniel Kraft  2010-10-22 10:44:16 
UTC ---
I have to admit that I more or less copied that "check_intentin" business while
rewriting the code.  It seems to "make sense", but I didn't find (and care to
find) this in the standard.  So if you think that this is the correct behaviour
also for PROTECTED, then I think this patch is what we want.  But whether this
is correct or we even should do that for PURE is something I have no idea
about.

[Bug c++/46129] [4.6 Regression] ICE: in tsubst_copy, at cp/pt.c:11375

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.22 10:16:00
 CC||hjl.tools at gmail dot com
Summary|ICE: in tsubst_copy, at |[4.6 Regression] ICE: in
   |cp/pt.c:11375   |tsubst_copy, at
   ||cp/pt.c:11375
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2010-10-22 
10:16:00 UTC ---
HJ, can you do a binary search on this?

[Bug target/46098] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()

[ubizjak at gmail dot com]

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

--- Comment #5 from Uros Bizjak  2010-10-22 10:16:27 
UTC ---
Created attachment 22115
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22115
Patch in testing.

[Bug middle-end/45720] [4.6 regression] Revision 164367 miscompiled SPEC CPU 2K

[vladimir.a.kharchenko at intel dot com]

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

--- Comment #8 from Vladimir Kharchenko  2010-10-22 10:15:16 UTC ---
It can happen that this file is minimal test case. :(
The piece of source:
961  if ((l_maxabs = temp.s_max[rw]) < 0)
962  {
963 l_maxabs = fabs(u.row.val[len]);
964
965 for (i = len - 1; i >= beg; --i)
966if (l_maxabs < fabs(u.row.val[i]))  > Seg. fault
967   l_maxabs = fabs(u.row.val[i]);
968
969 temp.s_max[rw] = l_maxabs;   /* # */
970  }
is executed many times in this test before Segmentation fault.
GDB shows that all objects (l_maxabs, fabs(u.row.val[i]), len, i, beg) have
correct values after Seg exception. Instructions after disassembler:
0x0041385b :   
and$0x7,%r8d
0x0041385f :   
movapd 0x0(%rbp),%xmm2 > Seg. fault
0x00413864 :   
cmp%r11d,%edx
also looks correct. %rbp points to correct memory.

So I have no hypotheses about the reason of this exception.
Maybe, it was indirect jump into the middle of instruction.
I will continue attemts to create short test case after weekend.

[Bug rtl-optimization/46114] [4.6 regression] g++ SEGV when built with gld on Solaris 10+/x86

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE  2010-10-22 10:15:20 UTC ---
> --- Comment #6 from Bernd Schmidt  2010-10-21 
> 23:33:47 UTC ---
> I'm assuming you run the testcase on Solaris? Can you provide good/bad 
> assembly
> output?

Sure, both attached.  Each of them was compiled with gcc -g -O2 -S.

As could be expected, the bug has nothing to do with wether or nor gld
is in use, only with the details of the input.  It can be reproduced
with a gcc configured to use Sun as and ld instead of gas and gld.  The
attached -S output is for a compiler configured to use CVS gas and gld,
though.  The bad one is from r164552 (your patch), the good one from
r164551 (the last working rev).

Thanks.
Rainer

[Bug tree-optimization/46126] [4.6 Regression] Revision 165777 failed to build 254.gap in SPEC CPU 2K

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.10.22 10:10:48
 AssignedTo|unassigned at gcc dot   |irar at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Ira Rosen  2010-10-22 10:10:48 UTC 
---
It's a copy-paste error, testing:

Index: tree-vect-stmts.c
===
--- tree-vect-stmts.c   (revision 165814)
+++ tree-vect-stmts.c   (working copy)
@@ -4663,7 +4663,7 @@ vect_analyze_stmt (gimple stmt, bool *ne
 else
   {
 if (bb_vinfo)
-  ok = (vectorizable_shift (stmt, NULL, NULL, NULL)
+  ok = (vectorizable_shift (stmt, NULL, NULL, node)
 || vectorizable_operation (stmt, NULL, NULL, node)
 || vectorizable_assignment (stmt, NULL, NULL, node)
 || vectorizable_load (stmt, NULL, NULL, node, NULL)

Ira

[Bug rtl-optimization/46114] [4.6 regression] g++ SEGV when built with gld on Solaris 10+/x86

[ro at gcc dot gnu.org]

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

--- Comment #8 from Rainer Orth  2010-10-22 10:10:13 UTC 
---
Created attachment 22114
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22114
miscompiled assembler output

[Bug rtl-optimization/46114] [4.6 regression] g++ SEGV when built with gld on Solaris 10+/x86

[ro at gcc dot gnu.org]

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

--- Comment #7 from Rainer Orth  2010-10-22 10:09:26 UTC 
---
Created attachment 22113
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22113
working assembler output

[Bug bootstrap/46121] [4.6 regression] LTO bootstrap failed

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug c++/46129] New: ICE: in tsubst_copy, at cp/pt.c:11375

[marc.glisse at normalesup dot org]

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

   Summary: ICE: in tsubst_copy, at cp/pt.c:11375
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org


The following code recently (sometime in October) started failing to compile
with:

Sqrt_extension.cpp: In member function ‘void
Scalar_factor_traits::Scalar_factor::operator()(const Gmpz&) [with T =
int]’:
Sqrt_extension.cpp:15:7: internal compiler error: in tsubst_copy, at
cp/pt.c:11375
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


class Gmpz { };

template 
struct Scalar_factor_traits {
struct Scalar_factor
{
void operator () (const Gmpz& d_ = Gmpz() ) { }
};
};

void scalar_factor_traits_test(){
{
typedef Scalar_factor_traits SFT;
SFT::Scalar_factor sfac;
sfac();
}
}

[Bug target/46098] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |ubizjak at gmail dot com
   |gnu.org |

--- Comment #4 from Uros Bizjak  2010-10-22 09:05:54 
UTC ---
Hm ...

ASSIGNED to "Not yet assigned to anyone"?

"Assigned To:" field should IMO assign the bug automatically to the (logged in)
person setting the bug in ASSIGNED state.

[Bug target/46098] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Uros Bizjak  2010-10-22 09:03:01 
UTC ---
(In reply to comment #2)
> Well, that's a problem of the target.  The pattern that is supposed to match
> is:
> 
> (define_insn "_movu"
>   [(set (match_operand:SSEMODEF2P 0 "nonimmediate_operand" "=x,m")
> (unspec:SSEMODEF2P
>   [(match_operand:SSEMODEF2P 1 "nonimmediate_operand" "xm,x")]
>   UNSPEC_MOVU))]
>   "SSE_VEC_FLOAT_MODE_P (mode)
>&& !(MEM_P (operands[0]) && MEM_P (operands[1]))"
>   ...

> The third alternative would be to fix ix86_expand_special_args_builtin to
> emit the correct patterns from the start.
> 
> Whatever is done, it probably also needs to be done for some other patterns.
> 
> FWIW the second alternative would look like so:
> Index: config/i386/sse.md
> ===
> --- config/i386/sse.md  (revision 165503)
> +++ config/i386/sse.md  (working copy)
> @@ -412,8 +412,7 @@ (define_insn "_movu"
> (unspec:SSEMODEF2P
>   [(match_operand:SSEMODEF2P 1 "nonimmediate_operand" "xm,x")]
>   UNSPEC_MOVU))]
> -  "SSE_VEC_FLOAT_MODE_P (mode)
> -   && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
> +  "SSE_VEC_FLOAT_MODE_P (mode)"
>"movu\t{%1, %0|%0, %1}"
>[(set_attr "type" "ssemov")
> (set_attr "movu" "1")
> 
> and fixes the bug.

Er, no. This is a move, and all moves have the constraint that you removed.
Probably, we have to handle this via an expander that calls ix86_expand_move,
and this will fix the operands at expansion time.

[Bug middle-end/45720] [4.6 regression] Revision 164367 miscompiled SPEC CPU 2K

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2010-10-22 
08:59:56 UTC ---
We need some sort of a testcase.

[Bug c/46115] Feature request: anonymous functions (complementing anon aggregates)

[robert.staudinger at gmail dot com]

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

--- Comment #2 from Rob Staudinger  
2010-10-22 08:33:46 UTC ---
There obviously is some relation, but this proposal evades syntactical
overloading of operators, unlike C++ lambda functions or LLVM blocks.

[Bug target/46128] New: There is no mechanism for detecting VFP revisions in ARM GCC.

[Jacob.Bramley at arm dot com]

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

   Summary: There is no mechanism for detecting VFP revisions in
ARM GCC.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jacob.bram...@arm.com
CC: rearn...@gcc.gnu.org
Target: ARM


There is currently no mechanism for detecting different versions of VFP using
the pre-processor. In C code, this is not a problem, but it is necessary
information when writing in-line assembly code that needs to be portable across
ARM platforms.

As a real-world example, consider the following Mozilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=601914

In that example, Siahei wrote an in-line assembly block that constructs
scripted arguments according to EABI ('hard' variant), then calls the specified
function. However, in order to do this safely, we have to specify all the
scratch registers in the clobber list, including D16-D31. Luckily, it seems
that GCC accepts these in the clobber list even on VFPv3-D16, but will that
always be the case?

More generally, it would be beneficial to be able to optimize routines using
specific VFPv3 instructions (such as VMOV's immediate-operand form), or to make
use of VFPv4's fused-mulitply-accumulate instructions.

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #27 from Jeffrey Walton  2010-10-22 
07:37:55 UTC ---
(In reply to comment #26)
> [SNIP]
> Are those libraries that crash designed to be used via dlopen, rather than
> linking to them explicitly?
I'm not sure. How can one tell?

[Bug target/36503] x86 can use x >> -y for x >> 32-y

[ubizjak at gmail dot com]

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

--- Comment #9 from Uros Bizjak  2010-10-22 07:37:22 
UTC ---
(In reply to comment #8)
> I built ffmpeg for x86-64 with --disable-asm with the attached patch and the
> regression tests failed. Reverting the patch fixes them. I saved the binaries
> but haven't investigated yet.

The problem is that new insn pattern clobbers %ecx. Currently, this is not
modeled correctly - if this is fixed, then the combine doesn't recognize
combined pattern.  So, either combine should be fixed to allow correct
(match_dup X) in the combined pattern or this transformation should be
implemented in generic part of the compiler.

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[redi at gcc dot gnu.org]

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

--- Comment #26 from Jonathan Wakely  2010-10-22 
07:34:55 UTC ---
I don't think dlmopen has anything to do with C++ namespaces, but I could be
wrong

Are those libraries that crash designed to be used via dlopen, rather than
linking to them explicitly?

[Bug target/46127] New: Use 16bit add instead of 32bit in thumb2

[carrot at google dot com]

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

   Summary: Use 16bit add instead of 32bit in thumb2
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
CC: car...@google.com
  Host: i686-linux
Target: arm-eabi
 Build: i686-linux


Compile the following code with options -march=armv7-a -mthumb -Os

unsigned long compressBound (unsigned long sourceLen)
{
  return sourceLen + (sourceLen >> 12) + (sourceLen >> 14) +
 (sourceLen >> 25) + 13;
}

GCC 4.6 generates:

compressBound:
add r3, r0, #13   // A
add r3, r3, r0, lsr #12
add r3, r3, r0, lsr #14
add r0, r3, r0, lsr #25
bx  lr

We can change the instruction order and register a little

compressBound:
add r3, r0, r0, lsr #12
add r3, r3, r0, lsr #14
add r0, r3, r0, lsr #25
add r0, r0, #13   // B
bx  lr

Now instruction A becomes instruction B. Instruction A is 32 bit, instruction B
is 16 bit, so it becomes shorter.

Don't know how to handle it in compiler.