[Bug c/49820] Explicit check for integer negative after abs optimized away

[agner at agner dot org]

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

--- Comment #10 from Agner Fog  2011-07-25 07:43:58 UTC 
---
I still think that a compiler should be predictable and consistent. It is
inconsistent that  a+5

[Bug c/49820] Explicit check for integer negative after abs optimized away

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  2011-07-25 
07:45:36 UTC ---
> -Wall produces the warning "assuming signed overflow does not occur when
> assuming that (X + c) < X is always false" in the above example, but there is
> no warning when it assumes that abs(a) < 0 is always false.

As already mentioned in comment #7, you need to pass -Wstrict-overflow for this
case.  There are various levels of -Wstrict-overflow, see the manual.

> I believe that the behavior of a compiler must be predictable. An ordinary
> programmer would never predict that the compiler can optimize away an explicit
> check for overflow, no matter how many C++ textbooks he has read. If the
> compiler can remove a security check without warning then we have a security
> issue.

The behavior of the compiler is predictable, no doubt about that.  And it's
documented at length in the manual.  And explained in blogs, etc.  It's only a
matter of learning how to write overflow checks in C, that's all.

[Bug tree-optimization/49715] Could do more efficient unsigned-to-float to conversions based on range information

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-07-25 
08:30:50 UTC ---
Author: rguenth
Date: Mon Jul 25 08:30:46 2011
New Revision: 176735

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176735
Log:
2011-07-25  Richard Guenther  

PR tree-optimization/49715
* tree-vrp.c: Include expr.h and optabs.h.
(range_fits_type_): New function.
(simplify_float_conversion_using_ranges): Likewise.
(simplify_stmt_using_ranges): Call it.
* Makefile.in (tree-vrp.o): Add $(EXPR_H) and $(OPTABS_H) dependencies.
* optabs.c (can_float_p): Export.
* optabs.h (can_float_p): Declare.

* gcc.target/i386/pr49715-1.c: New testcase.
* gcc.target/i386/pr49715-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr49715-1.c
trunk/gcc/testsuite/gcc.target/i386/pr49715-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/optabs.c
trunk/gcc/optabs.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug tree-optimization/49715] Could do more efficient unsigned-to-float to conversions based on range information

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Guenther  2011-07-25 
08:31:25 UTC ---
Fixed.

[Bug rtl-optimization/49799] gcc arm generates illegal sbfx instruction

[carrot at google dot com]

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

Carrot  changed:

   What|Removed |Added

  Component|target  |rtl-optimization

--- Comment #4 from Carrot  2011-07-25 08:39:27 UTC 
---
After some combine, gcc gets the following expression

(ashiftrt:SI (ashift:SI (reg:SI 145 [ *K_2(D) ])
(const_int -1 [0x]))
(const_int 16 [0x10]))

Then gcc tries to simplify it by calling make_compound_operation, in this
function at line 7786, it detects the cases that shift left and right and
replaces it with bit field extraction. It is a good optimization for usual
cases. But for this ill formed case, we can't make a valid bit field extraction
since we don't know what's the target field.

Add the following condition for the transformation should prevent the illegal
instruction.
  INTVAL (XEXP (lhs, 1)) >= 0

[Bug target/49487] Internal compiler error in AVR code (bytewise rotate)

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||jh.gcc-bugzilla at plonk
   ||dot de

--- Comment #8 from Georg-Johann Lay  2011-07-25 
08:43:04 UTC ---
*** Bug 47509 has been marked as a duplicate of this bug. ***

[Bug target/47509] avr-gcc error: could not split insn

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Georg-Johann Lay  2011-07-25 
08:43:04 UTC ---
There is MEM in the clobber, it's PR49487.

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

[Bug rtl-optimization/49799] gcc arm generates illegal sbfx instruction

[rearnsha at gcc dot gnu.org]

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

--- Comment #5 from Richard Earnshaw  2011-07-25 
09:03:30 UTC ---
We should never generate a shift of -1.  Instead the code that does that should
return (clobber const_int 0).

[Bug debug/49831] arm-linux-gnueabi bootstrap failures due to ICE in dwarf2cfi.c connect_traces

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Guenther  2011-07-25 
09:11:52 UTC ---
Fixed.

[Bug bootstrap/49835] [4.7 Regression] Revision 176720 caused bootstrap failure

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #3 from Richard Guenther  2011-07-25 
09:11:36 UTC ---
Fix.ed

[Bug bootstrap/49829] [4.7 Regression] --disable-static --enable-shared regression: cannot find -lstdc++

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.25 09:13:28
  Component|other   |bootstrap
 CC||iant at google dot com
 Ever Confirmed|0   |1
Summary|--disable-static|[4.7 Regression]
   |--enable-shared regression: |--disable-static
   |cannot find -lstdc++|--enable-shared regression:
   ||cannot find -lstdc++
   Target Milestone|--- |4.7.0

--- Comment #1 from Richard Guenther  2011-07-25 
09:13:28 UTC ---
Hm, I suppose disabling the static libstdc++ isn't supposed to work anymore.
Ian - should we in this case link libstdc++ dynamically with all the possible
issues that might have?

[Bug debug/49827] [4.7 regression] sparc64-linux and cris-elf bootstrap failures due to ICE in dwarf2cfi.c connect_traces

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Richard Guenther  2011-07-25 
09:14:45 UTC ---
Fixed.

[Bug rtl-optimization/49799] gcc arm generates illegal sbfx instruction

[carrot at google dot com]

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

--- Comment #6 from Carrot  2011-07-25 09:25:22 UTC 
---
(In reply to comment #5)
> We should never generate a shift of -1.  Instead the code that does that 
> should
> return (clobber const_int 0).

I'm afraid this method may impact gcc too much. I added the following to the
source code

K[1] = K[1] << -1;

gcc only generates a warning

auto_corr_to_refl_coef.i:19:5: warning: left shift count is negative [enabled
by default]

and generates following code

ldrsh   r1, [r0, #2]
mvn ip, #0
mov r1, r1, asl ip
strhr1, [r0, #2]

What do you think?

[Bug target/49821] [4.6 regression] ICE in dwarf2out_cfi_begin_epilogue, at dwarf2out.c:3015

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.2

[Bug tree-optimization/49809] [4.7 regression] gimple_check failure at -O3

[rsandifo at gcc dot gnu.org]

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

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

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.25 09:43:58
 AssignedTo|unassigned at gcc dot   |rsandifo at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug rtl-optimization/49799] gcc arm generates illegal sbfx instruction

[rearnsha at gcc dot gnu.org]

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

--- Comment #7 from Richard Earnshaw  2011-07-25 
09:45:51 UTC ---
No, you miss the point.

Internally we must not generate (ashift (reg) (const_int)) where the const is
negative.

Note that your testcasegenerates a reg shift.

[Bug c++/49043] [OpenMP & C++0x]: Compiler error when lambda-function within OpenMP loop

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-07-25 
09:54:13 UTC ---
*** Bug 49100 has been marked as a duplicate of this bug. ***

[Bug c++/49100] [OpenMP]: Compiler error when inline method defined within OpenMP loop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Jakub Jelinek  2011-07-25 
09:54:13 UTC ---
The first comment has been resolved by PR49043, at least I can't reproduce this
anymore with current trunk or 4.6.
The second is a user bug, OpenMP standard says that you shouldn't reference in
a parallel region the original copy of the variable and you do exactly that
through the nested function.

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

[Bug libstdc++/49836] New: vector::push_back() should not require T to be (move-)assignable

[zeratul976 at hotmail dot com]

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

   Summary: vector::push_back() should not require T to be
(move-)assignable
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com


In the current std::vector implementation, push_back() requires the vector's
element type to be assignable.

For example, in the following code T is copy-constructible but not
copy-assignable, and I attempt to push_back() an T object to a vector:

#include 

struct T
{
T() = default;
T(const T&) = default;
T& operator=(const T&) = delete;
};

int main()
{
std::vector v;
T t;
v.push_back(t);
}

And I get the following errors (with --std=c++0x):

In file included from include/c++/4.7.0/vector:70:0,
 from test3.cpp:1:
include/c++/4.7.0/bits/vector.tcc: In member function 'void std::vector<_Tp,
_Alloc>::_M_insert_aux(std::vector<_Tp, _Alloc>::iterator, _Args&& ...) [with
_Args = {const T&}, _Tp = T, _Alloc = std::allocator, std::vector<_Tp,
_Alloc>::iterator = __gnu_cxx::__normal_iterator >, typename
std::_Vector_base<_Tp, _Alloc>::pointer = T*]':
include/c++/4.7.0/bits/stl_vector.h:905:4:   required from 'void
std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = T, _Alloc =
std::allocator, std::vector<_Tp, _Alloc>::value_type = T]'
test3.cpp:14:18:   required from here
include/c++/4.7.0/bits/vector.tcc:332:4: error: use of deleted function 'T&
T::operator=(const T&)'
test3.cpp:7:8: error: declared here
In file included from include/c++/4.7.0/vector:61:0,
 from test3.cpp:1:
include/c++/4.7.0/bits/stl_algobase.h: In static member function 'static _BI2
std::__copy_move_backward::__copy_move_b(_BI1, _BI1, _BI2) [with _BI1 =
T*, _BI2 = T*]':
include/c++/4.7.0/bits/stl_algobase.h:581:18:   required from '_BI2
std::__copy_move_backward_a(_BI1, _BI1, _BI2) [with bool _IsMove = true, _BI1 =
T*, _BI2 = T*]'
include/c++/4.7.0/bits/stl_algobase.h:590:34:   required from '_BI2
std::__copy_move_backward_a2(_BI1, _BI1, _BI2) [with bool _IsMove = true, _BI1
= T*, _BI2 = T*]'
include/c++/4.7.0/bits/stl_algobase.h:661:15:   required from '_BI2
std::move_backward(_BI1, _BI1, _BI2) [with _BI1 = T*, _BI2 = T*]'
include/c++/4.7.0/bits/vector.tcc:326:4:   required from 'void std::vector<_Tp,
_Alloc>::_M_insert_aux(std::vector<_Tp, _Alloc>::iterator, _Args&& ...) [with
_Args = {const T&}, _Tp = T, _Alloc = std::allocator, std::vector<_Tp,
_Alloc>::iterator = __gnu_cxx::__normal_iterator >, typename
std::_Vector_base<_Tp, _Alloc>::pointer = T*]'
include/c++/4.7.0/bits/stl_vector.h:905:4:   required from 'void
std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = T, _Alloc =
std::allocator, std::vector<_Tp, _Alloc>::value_type = T]'
test3.cpp:14:18:   required from here
include/c++/4.7.0/bits/stl_algobase.h:546:6: error: use of deleted function 'T&
T::operator=(const T&)'
test3.cpp:7:8: error: declared here

A similar problem occurs if I make T move-constructible but not
move-assignable, and try to push_back() an rvalue of type T into the vector.

However, FDIS section 23.2.3/16 specifies that push_back() requires only that T
is CopyInsertable into the vector (or MoveInsertable in the case of the rvalue
version of push_back()).

CopyInsertable is defined in section 23.2.1/13 as the expression 

allocator_traits::construct(m, p, v);

being valid (where m is the allocator, p is of type T*, and v is of type T).
For std::allocator, this is just:

::new((void*)p) T(v)

so basically we are requiring T to be copy-constructible (or move-constructible
if v is an rvalue). There is no requirement for T to be copy- or
move-assignable.


The offending statements in the vector implementation (i.e. those which try to
perform assignments) are in the _M_insert_aux helper function (lines 323-333 in
the current trunk):

#ifndef __GXX_EXPERIMENTAL_CXX0X__
  _Tp __x_copy = __x;
#endif
  _GLIBCXX_MOVE_BACKWARD3(__position.base(),
  this->_M_impl._M_finish - 2,
  this->_M_impl._M_finish - 1);
#ifndef __GXX_EXPERIMENTAL_CXX0X__
  *__position = __x_copy;
#else
  *__position = _Tp(std::forward<_Args>(__args)...);
#endif

However, this is in a code path that is not reached from push_back()
(push_back() only calls _M_insert_aux() if _M_impl._M_finish ==
_M_impl._M_end_of_storage, but these statements are in an "if
(this->_M_impl._M_finish != this->_M_impl._M_end_of_storage)" block in
_M_insert_aux()).

(This code path is exercised by other vector functions that call
_M_insert_aux(), such as insert() - and *these* functions *do* require T to be
Copy- or MoveAssignable).

The fix should therefore be simple: duplicate _M_insert_aux() into a separate
version used by push_back() and a separate version used by insert() etc, and
remove the of

[Bug c++/49100] [OpenMP]: Compiler error when inline method defined within OpenMP loop

[bisqwit at iki dot fi]

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

--- Comment #3 from Joel Yliluoma  2011-07-25 10:01:08 
UTC ---
While it's true that one should not reference the original variable within the
loop, question is, why does the inner function reference the original variable
rather than the inloop variable when there's no explicit reference to the
original variable. A reference is established, by name, within the loop, but
within the loop there should be no possible way to reference the outside-loop
variable because the inner-loop namespace shadows the outer one, and hence the
reference should bind into the inner-loop variable, thus conforming to OpenMP
specification.

[Bug c++/49100] [OpenMP]: Compiler error when inline method defined within OpenMP loop

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-07-25 
10:10:04 UTC ---
You are outside of the scope of OpenMP standard and C99 language.  GNU nested
functions and OpenMP simply don't play nicely together if the containing
function has #pragma omp parallel or #pragma omp task.

[Bug tree-optimization/49822] [4.7 regression] Segfault in remove_prop_source_from_use

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.25 10:17:10
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-07-25 
10:17:10 UTC ---
Confirmed.  Reproduced with a cross to arm-linux-eabi.  I have a patch.

[Bug libstdc++/49813] [C++0x] sinh vs asinh vs constexpr

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
  Component|c++ |libstdc++
 Resolution|FIXED   |
 AssignedTo|jason at gcc dot gnu.org|paolo.carlini at oracle dot
   ||com

--- Comment #27 from Paolo Carlini  2011-07-25 
10:19:17 UTC ---
Thanks Jason.

Let's reopen this as a library issue now: I have to mark constexpr the C++0x
library provided overloads (for float, long double, double too for the C90
functions). Will do momentarily.

[Bug c++/49837] New: File with UTF-8 BOM, included from pch, caused compilation error

[woodroof at gmail dot com]

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

   Summary: File with UTF-8 BOM, included from pch, caused
compilation error
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: woodr...@gmail.com


Created attachment 24823
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24823
Header file with bom

gcc -v:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)

Failed attempt:
g++ -x c++-header -c stable.h -o stable.gch/c++
g++ -include ./stable 1.cpp

Output:
In file included from stable.h:1,
 from 1.cpp:1:
1.h:4: error: redefinition of ‘template B convert(A)’
1.h:4: error: ‘template B convert(A)’ previously declared
here

Successful:
g++ 1.cpp

Empty output.

[Bug libstdc++/49813] [C++0x] sinh vs asinh vs constexpr

[paolo.carlini at oracle dot com]

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

--- Comment #28 from Paolo Carlini  2011-07-25 
10:21:57 UTC ---
(I meant to say -some- C90 functions, like std::abs, in most of the cases only
the overloads for float and long double require work)

[Bug target/49764] [avr-g++] Rejects attribute progmem

[gjl at gcc dot gnu.org]

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

--- Comment #17 from Georg-Johann Lay  2011-07-25 
10:23:07 UTC ---
Eric, would you confirm that all works fine with the
current 4.6 and 4.7 sources and close the PR?

This has already been fixed:

4_6-branch:
http://gcc.gnu.org/viewcvs?view=revision&revision=175810

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

[Bug c++/49837] File with UTF-8 BOM, included from pch, caused compilation error

[woodroof at gmail dot com]

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

--- Comment #1 from Danil Ilinykh  2011-07-25 
10:23:30 UTC ---
Created attachment 24824
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24824
Main file

[Bug c++/49100] [OpenMP]: Compiler error when inline method defined within OpenMP loop

[bisqwit at iki dot fi]

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

--- Comment #5 from Joel Yliluoma  2011-07-25 10:24:20 
UTC ---
Obviously :) All right, thanks.

[Bug c++/49837] File with UTF-8 BOM, included from pch, caused compilation error

[woodroof at gmail dot com]

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

--- Comment #2 from Danil Ilinykh  2011-07-25 
10:23:51 UTC ---
Created attachment 24825
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24825
Precompiled header

[Bug libstdc++/49836] [C++0x] vector::push_back() should not require T to be (move-)assignable

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.7.0
Summary|vector::push_back()  |[C++0x]
   |should not require T to be  |vector::push_back()
   |(move-)assignable   |should not require T to be
   ||(move-)assignable

--- Comment #1 from Paolo Carlini  2011-07-25 
10:29:51 UTC ---
Ok, thanks, I'll fix it ASAP. Can you also have a look to std::deque, see
whether there is the same problem, as easy to fix, etc..

[Bug libstdc++/49836] [C++0x] vector::push_back() should not require T to be (move-)assignable

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.25 10:30:09
 Ever Confirmed|0   |1

[Bug libstdc++/49813] [C++0x] sinh vs asinh vs constexpr

[rguenth at gcc dot gnu.org]

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

--- Comment #29 from Richard Guenther  2011-07-25 
10:45:59 UTC ---
(In reply to comment #28)
> (I meant to say -some- C90 functions, like std::abs, in most of the cases only
> the overloads for float and long double require work)

You have to be careful though as we do not guarantee to fold things in
the middle-end.  For example I don't think mpfr handles all exceptional
values, so we might end up not folding those (like with -fsignalling-nans
or signed zeros).  Also for -frounding-math we do not constant fold
floating point expressions.

But I'm not sure what guarantee a constexpr marked overload of, say,
sqrt provides.  We at least don't fold sqrt (-1.0).

[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #30 from Paolo Carlini  2011-07-25 
10:51:19 UTC ---
Jason, looks like we have a remaining curious C++ front-end issue with isinf
for long double, see the below. Can you have a look? Thanks!

Paolo.

//

inline constexpr bool
isinf(long double __x)
{ return __builtin_isinf(__x); }

inline constexpr bool
isinf(double __x)
{ return __builtin_isinf(__x); }

inline constexpr bool
isnan(long double __x)
{ return __builtin_isnan(__x); }

int main()
{
  constexpr long double num1 = __builtin_isinf(1.l); // Ok.

  constexpr long double num2 = isinf(1.l);   // Error.

  constexpr double  num3 = isinf(1.);// Ok.

  constexpr long double num4 = isnan(1.l);   // Ok.
}

[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr

[paolo.carlini at oracle dot com]

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

--- Comment #31 from Paolo Carlini  2011-07-25 
10:54:24 UTC ---
Richard, as far as I can see, if we don't fold, we don't fold, that line of
user code with, eg constexpr data, will simply not compile. I don't think this
is a major issue...

[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr

[rguenther at suse dot de]

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

--- Comment #32 from rguenther at suse dot de  
2011-07-25 10:59:30 UTC ---
On Mon, 25 Jul 2011, paolo.carlini at oracle dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
> 
> --- Comment #31 from Paolo Carlini  
> 2011-07-25 10:54:24 UTC ---
> Richard, as far as I can see, if we don't fold, we don't fold, that line of
> user code with, eg constexpr data, will simply not compile. I don't think this
> is a major issue...

Ah, ok.  So a constexpr function only means the frontend has to "try"
to constant-fold it, and if it doesn't fold to a constant it's an
errorneous program.  I suppose only if the result is used in a
constexpr, that is (recursively so).

[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr

[vincenzo.innocente at cern dot ch]

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

--- Comment #33 from vincenzo Innocente  
2011-07-25 11:02:26 UTC ---
indeed
as noted in comment 8

20  static constexpr float nan1 = std::asin(1.45);
21  static constexpr float nan2 = std::sqrt(-1.45);
produces the quite confusion error message:
cexprMath.cpp:20:47: error: field initializer is not constant
cexprMath.cpp:21:48: error: field initializer is not constant
something saying that the argument is out-of-range may be more appropriate

[Bug debug/49828] reversed order of inlined function parameters

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2011-07-25 
11:02:15 UTC ---
I'd argue that gdb should here use the (correct) order of the parameters on the
abstract origin DIE.
I'm afraid the order of vars everywhere in gcc is pretty much random, and as
the concrete instances of the formal parameters (i.e. vars) can be added
through various means, it is hard to ensure the original ordering.

This particular testcase could be "fixed" by adding
  vars = nreverse (vars);
before:
  declare_inline_vars (id->blocks, vars);
in initialize_inlined_parameters, but that won't help e.g. if a VLA parameter
uses for its size other parameters, or if a function isn't inlined, but cloned
for versioning, etc.

[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr

[paolo.carlini at oracle dot com]

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

--- Comment #34 from Paolo Carlini  2011-07-25 
11:17:24 UTC ---
Better diagnostic would be always welcome, but probably we should deal with
that elsewhere (we *do* have PRs about constexpr vs diagnostics), because it's
a generic problem, isn't specific to the math functions in the library (quite a
special case actually, because C++11 does *not* even mandate those functions to
be constexpr)

[Bug c++/33255] A warning for "unused" typedefs?

[dodji at seketeli dot org]

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

--- Comment #21 from dodji at seketeli dot org  
2011-07-25 11:17:11 UTC ---
> --- Comment #18 from Paolo Carlini  
> 2011-07-24 22:37:39 UTC ---
> By the way, an obvious positive additional testcase, involving templates, 
> would
> be one inspired by libstdc++/33084 that is involving  *before* the
> fix for that bug. Shouldn't be too hard to figure out...

Thanks for the pointer.  I am adding this (hopefully equivalent) test
case to the patch:

+
+template
+struct S10
+{
+};
+
+template
+void
+test10(void)
+{
+  typedef typename ST::T bar; // { dg-warning "locally defined but not
used" }
+  typedef typename ST::T foo; // We shouldn't warn for this one, as
+ // it's used below.
+  S10 v;
+}

[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr

[paolo.carlini at oracle dot com]

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

--- Comment #36 from Paolo Carlini  2011-07-25 
11:43:02 UTC ---
Or, more correctly:

  constexpr float na = __builtin_nextafterf(0.0f, 0.0f);

[Bug c++/33255] A warning for "unused" typedefs?

[paolo.carlini at oracle dot com]

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

--- Comment #22 from Paolo Carlini  2011-07-25 
11:43:47 UTC ---
Excellent.

[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr

[paolo.carlini at oracle dot com]

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

--- Comment #38 from Paolo Carlini  2011-07-25 
11:46:00 UTC ---
Ah Ok, maybe I will be able to work on that. Just wanted to make sure we
understand where the problem is.

[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr

[rguenther at suse dot de]

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

--- Comment #37 from rguenther at suse dot de  
2011-07-25 11:44:12 UTC ---
On Mon, 25 Jul 2011, paolo.carlini at oracle dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
> 
> --- Comment #35 from Paolo Carlini  
> 2011-07-25 11:41:57 UTC ---
> Also, something seems wrong with nextafter, but for the intrinsic too this
> time, thus maybe is a middle-end issue (eg, not optimized at all?). Try:
> 
>   constexpr float na = __builtin_nextafter(0.0f, 0.0f);

Not all functions are folded by the middle-end.  Look into builtins.c.
Patches welcome.

[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr

[paolo.carlini at oracle dot com]

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

--- Comment #35 from Paolo Carlini  2011-07-25 
11:41:57 UTC ---
Also, something seems wrong with nextafter, but for the intrinsic too this
time, thus maybe is a middle-end issue (eg, not optimized at all?). Try:

  constexpr float na = __builtin_nextafter(0.0f, 0.0f);

[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr

[paolo.carlini at oracle dot com]

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

--- Comment #39 from Paolo Carlini  2011-07-25 
11:49:33 UTC ---
(however, the issue in Comment #30, isinf vs long double, seems a real glitch
somewhere, the intrinsic works fine)

[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr

[paolo.carlini at oracle dot com]

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

--- Comment #40 from Paolo Carlini  2011-07-25 
11:57:58 UTC ---
Created attachment 24826
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24826
Library bits, passes testing, the isinf overload for long double cannot be
marked constexpr

[Bug c++/49838] New: [C++0x] ICE in cp_parser_perform_range_for_lookup, at cp/parser.c:8796

[sscrisk at gmail dot com]

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

   Summary: [C++0x] ICE in cp_parser_perform_range_for_lookup, at
cp/parser.c:8796
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sscr...@gmail.com


The g++ 4.7.0 20110723 (experimental) compile the ill-formed codes
when compiler say (normal) compiler error and ICE messages.


Codes here:

int main()
{
 auto a;
 for(auto i: a)
  ;
}


Compiler messages:

$ g++4.7 -std=c++0x -Wall -Wextra -pedantic a.cpp
a.cpp: In function 'int main()':
a.cpp:3:7: error: declaration of 'auto a' has no initializer
a.cpp:4:14: error: unable to deduce 'auto&&' from 'a'
a.cpp:4:14: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in cp_parser_
perform_range_for_lookup, at cp/parser.c:8796
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Version info:

$ g++4.7 -v
Built by Equation Solution .
Using built-in specs.
COLLECT_GCC=C:\cygwin\home\RiSK\misc\gcc4.7\bin\g++.exe
COLLECT_LTO_WRAPPER=c:/cygwin/home/risk/misc/gcc4.7/bin/../libexec/gcc/i686-pc-mingw32/4.7.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-4.7-20110723-mingw/configure --host=i686-pc-mingw32
--build=x86_64-unknown-linux-gnu --target
=i686-pc-mingw32
--prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.7-20110723
--with-gcc --with-gnu
-as --with-gnu-ld --with-host-libstdcxx='-lstdc++ -lsupc++ -lm'
--with-ppl=/home/gfortran/gcc-home/binary/mingw32/nat
ive/x86_32/ppl
--with-cloog=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/cloog
--with-gmp=/home/gfortran/gcc-
home/binary/mingw32/native/x86_32/gmp
--with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr --with-mp
c=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpc
--with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cros
s/x86_32/gcc/4.7-20110723 --disable-shared --disable-nls --disable-tls
--disable-win32-registry --enable-libquadmath-
support --enable-libquadmath --enable-languages=c,c++,fortran --enable-libgomp
--enable-threads=win32 --enable-lto --
enable-static --enable-shared=lto-plugin --enable-plugins --enable-ld=yes
--enable-cloog-backend=ppl
Thread model: win32
gcc version 4.7.0 20110723 (experimental) (GCC)

[Bug c++/49838] [C++0x] ICE in cp_parser_perform_range_for_lookup, at cp/parser.c:8796

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.25 12:36:10
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2011-07-25 
12:36:10 UTC ---
Confirmed, seems easy to fix. Note, happens only with checking enabled.

[Bug c++/49838] [C++0x] ICE in cp_parser_perform_range_for_lookup, at cp/parser.c:8796

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug target/29560] [avr] Poor optimization for byte shifts

[gjl at gcc dot gnu.org]

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

--- Comment #9 from Georg-Johann Lay  2011-07-25 
12:48:29 UTC ---
Created attachment 24827
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24827
Fix PR29560 by adding peephole2 pattern.


PR target/29560
* config/avr/avr.md: Add peephole2 to map ashlhi3 to ashlqi3 if
high part of shift target is unused.

[Bug libstdc++/49836] [C++0x] vector::push_back() should not require T to be (move-)assignable

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  2011-07-25 
13:08:12 UTC ---
Ah good, std::deque seems already Ok, push_back doesn't share code with insert.

[Bug rtl-optimization/49839] New: Use constants in registers preferably to inline constants (-Os)

[etienne_lorrain at yahoo dot fr]

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

   Summary: Use constants in registers preferably to inline
constants (-Os)
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: etienne_lorr...@yahoo.fr


When GCC needs to zero out an integer in memory, and it already has one
register at value zero, it takes less code bytes to write the register than
inline a constant, i.e.:

etienne@etienne-server:~/projet$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/i386-linux-gnu/gcc/i486-linux-gnu/4.6.1/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-4'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-multiarch
--with-multiarch-defaults=i386-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/i386-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/i386-linux-gnu
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.6.1 (Debian 4.6.1-4) 

etienne@etienne-server:~/projet$ cat tmp.c
unsigned a, b;
unsigned fct (void)
  {
  a = b = 0;
  return 0;
  }
etienne@etienne-server:~/projet$ gcc -Os -fomit-frame-pointer tmp.c -c -o tmp.o
etienne@etienne-server:~/projet$ objdump -d tmp.o

tmp.o: file format elf32-i386


Disassembly of section .text:

 :
   0:c7 05 00 00 00 00 00 movl   $0x0,0x0
   7:00 00 00 
   a:31 c0xor%eax,%eax
   c:c7 05 00 00 00 00 00 movl   $0x0,0x0
  13:00 00 00 
  16:c3   ret
etienne@etienne-server:~/projet$ 

It would be shorter to get this assembly:
0:31 c0xor%eax,%eax
2:a3 00 00 00 00mov%eax,a
7:a3 00 00 00 00mov%eax,b
c:c3ret

Regards,
Etienne.

[Bug tree-optimization/49471] cactusADM/dealII build with autopar fails on x86, and fails on power7 when -m32 is enabled.

[razya at gcc dot gnu.org]

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

razya at gcc dot gnu.org changed:

   What|Removed |Added

Summary|cactusADM build with|cactusADM/dealII build with
   |autopar fails on x86, and   |autopar fails on x86, and
   |fails on power7 when -m32   |fails on power7 when -m32
   |is enabled. |is enabled.

--- Comment #6 from razya at gcc dot gnu.org 2011-07-25 13:31:50 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > (In reply to comment #1)
> > > > > Why is
> > > > >   D.7313_5 = MEM[(struct  *).paral_data_param_1(D)].D.7288; /*  
> > > > > Number of loop
> > > > > iterations.  */
> > > > > of type __int128?  That looks bogus.
> > > > 
> > > > the size of 128 was determined according to the precision of the ivs in
> > > > canonicalize_loop_ivs:
> > > > 
> > > > canonicalize_loop_ivs (struct loop *loop, tree *nit, bool bump_in_latch)
> > > > {
> > > >   unsigned precision = TYPE_PRECISION (TREE_TYPE (*nit));   
> > > >   for (psi = gsi_start_phis (loop->header); 
> > > >!gsi_end_p (psi); gsi_next (&psi))
> > > > {
> > > >   gimple phi = gsi_stmt (psi);
> > > >   tree res = PHI_RESULT (phi);
> > > > 
> > > >   if (is_gimple_reg (res) && TYPE_PRECISION (TREE_TYPE (res)) > 
> > > > precision)
> > > > precision = TYPE_PRECISION (TREE_TYPE (res));
> > > > }
> > > > 
> > > >   type = lang_hooks.types.type_for_size (precision, 1); // precision == 
> > > > 128 
> > > >   ...
> > > >  }
> > > > 
> > > > Does it seem that the precision should not determine the new type size, 
> > > > or that 
> > > > the precision itself being 128 is strange?
> > > Well, autopar seems to introduce this 128 bit type in the first place,
> > > and I wonder why it does that.  And it definitely should avoid doing this.
> > What happens is that autopar calls canonicalize_loop_ivs() when it is 
> > starting
> > to change the loop.
> > Here's a  part of the documentation of canonicalize_loop_ivs(): 
> >  "  When the IV type precision has to be larger
> >than *NIT type precision, *NIT is converted to the larger type, the
> >conversion code is inserted before the loop, and *NIT is updated to
> >the new definition.  "  
> > In this case of cactusADM, one of the loop's IVs indeed has a precision of 
> > 128,
> > and therefore a conversion to a type of 128 bit is created.
> > I checked the precision of the loop's IVs a few passes before autopar, and 
> > even
> > when I disable autopar, and indeed there is an IV that has a type with 128
> > precision.
> I tried to build cactusADM on linux-x86 with autopar enabled, and I get 
> segmentation fault due to the same reason.
> It happens when either -m32c or -m64 is enabled.
> /Develop/razya/gcc-cactus/bin/gcc -c -o PUGHReduce/ReductionNormInf.o
> -DSPEC_CPU -DNDEBUG  -Iinclude -I../include -DCCODE  -O2
> -ftree-parallelize-loops=4 -ffast-math   -DSPEC_CPU_LP64
> PUGHReduce/ReductionNormInf.c
> PUGHReduce/ReductionNormInf.c: In function 'PUGH_ReductionNormInf':
> PUGHReduce/ReductionNormInf.c:207:12: internal compiler error: Segmentation
> fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> specmake: *** [PUGHReduce/ReductionNormInf.o] Error 1
> The type is NULL at line 1218 in canonicalize_loop_ivs:
> 1214  type = lang_hooks.types.type_for_size (precision, 1);
> 1215
> 1216  if (original_precision != precision)
> 1217{
> 1218  *nit = fold_convert (type, *nit);
> 1219  *nit = force_gimple_operand (*nit, &stmts, true, NULL_TREE);
> 1220  if (stmts)
> 1221gsi_insert_seq_on_edge_immediate (loop_preheader_edge (loop),
> stmts);
> 1222}
> The size according to which the type is supposed to be created (line 1214) is
> 80.

dealII has the exact same behavior as cactusADM when autopar is enabled
on x86, or together with -m32 on powerpc.

[Bug target/49833] [x32] PIC doesn't work

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2011-07-25 13:59:10 
UTC ---
X32 dynamic linker is miscompiled:

Program received signal SIGSEGV, Segmentation fault.
0x00114821 in elf_machine_rela_relative (reloc_addr_arg=, 
l_addr=1114112, reloc=)
at ../sysdeps/x86_64/dl-machine.h:483
483  *reloc_addr = l_addr + reloc->r_addend;
(gdb) disass 0x00114808, 0x0011482c 
Dump of assembler code from 0x114808 to 0x11482c:
   0x00114808 <_dl_start+968>:lea(%rsi,%rdx,1),%edx
   0x0011480b <_dl_start+971>:mov-0xc(%rdx),%edx
   0x0011480e <_dl_start+974>:add%r13d,%edx
   0x00114811 <_dl_start+977>:cmpb   $0x8,0x4(%rax)
   0x00114815 <_dl_start+981>:jne0x114901 <_dl_start+1217>
   0x0011481b <_dl_start+987>:mov0x8(%rax),%ecx
   0x0011481e <_dl_start+990>:add%r13d,%ecx
=> 0x00114821 <_dl_start+993>:mov%ecx,(%rdx)
   0x00114823 <_dl_start+995>:lea0xc(%rax),%edx
   0x00114826 <_dl_start+998>:cmp%edx,%ebx
   0x00114828 <_dl_start+1000>:mov%edx,%eax
   0x0011482a <_dl_start+1002>:ja 0x114808 <_dl_start+968>
End of assembler dump.
(gdb) p/x $rdx
$1 = 0x111724
(gdb) 

Working one:

The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /export/build/gnu/glibc-x32/build-x86_64-linux/sunrpc/rpcgen 

Breakpoint 1, elf_machine_rela_relative (reloc_addr_arg=, 
l_addr=1114112, reloc=)
at ../sysdeps/x86_64/dl-machine.h:483
483  *reloc_addr = l_addr + reloc->r_addend;
(gdb) disass 0x00114768, 0x00114789
Dump of assembler code from 0x114768 to 0x114789:
   0x00114768 <_dl_start+968>:add%esi,%edx
   0x0011476a <_dl_start+970>:mov-0xc(%rdx),%edx
   0x0011476d <_dl_start+973>:add%r13d,%edx
   0x00114770 <_dl_start+976>:cmpb   $0x8,0x4(%rax)
   0x00114774 <_dl_start+980>:jne0x114859 <_dl_start+1209>
=> 0x0011477a <_dl_start+986>:mov0x8(%rax),%ecx
   0x0011477d <_dl_start+989>:add%r13d,%ecx
   0x00114780 <_dl_start+992>:mov%ecx,(%rdx)
   0x00114782 <_dl_start+994>:lea0xc(%rax),%edx
   0x00114785 <_dl_start+997>:cmp%edx,%ebx
   0x00114787 <_dl_start+999>:mov%edx,%eax
End of assembler dump.
(gdb) p/x $rdx
$3 = 0x32ed40
(gdb)

[Bug middle-end/49840] New: [4.7 Regression] New test failures

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] New test failures
   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: rgue...@gcc.gnu.org


On Linux/ia32, revision 176737 gave:

FAIL: c-c++-common/dfp/usual-arith-conv.c execution test
FAIL: c-c++-common/dfp/usual-arith-conv.c execution test
FAIL: gcc.dg/torture/fp-int-convert-float80.c  -O0  execution test
FAIL: gcc.dg/torture/fp-int-convert-float80.c  -O1  execution test
FAIL: gcc.dg/torture/fp-int-convert-float80.c  -O2  execution test
FAIL: gcc.dg/torture/fp-int-convert-float80.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/fp-int-convert-float80.c  -O2 -flto -flto-partition=none 
execution test
FAIL: gcc.dg/torture/fp-int-convert-float80.c  -O3 -fomit-frame-pointer 
execution test
FAIL: gcc.dg/torture/fp-int-convert-float80.c  -O3 -g  execution test
FAIL: gcc.dg/torture/fp-int-convert-float80.c  -Os  execution test
FAIL: gcc.dg/torture/fp-int-convert-long-double.c  -O0  execution test
FAIL: gcc.dg/torture/fp-int-convert-long-double.c  -O1  execution test
FAIL: gcc.dg/torture/fp-int-convert-long-double.c  -O2  execution test
FAIL: gcc.dg/torture/fp-int-convert-long-double.c  -O2 -flto  execution test
FAIL: gcc.dg/torture/fp-int-convert-long-double.c  -O2 -flto
-flto-partition=none  execution test
FAIL: gcc.dg/torture/fp-int-convert-long-double.c  -O3 -fomit-frame-pointer 
execution test
FAIL: gcc.dg/torture/fp-int-convert-long-double.c  -O3 -g  execution test
FAIL: gcc.dg/torture/fp-int-convert-long-double.c  -Os  execution test
FAIL: gfortran.fortran-torture/execute/random_2.f90 execution,  -O0 
FAIL: gfortran.fortran-torture/execute/random_2.f90 execution,  -O1 
FAIL: gfortran.fortran-torture/execute/random_2.f90 execution,  -O2 
FAIL: gfortran.fortran-torture/execute/random_2.f90 execution,  -O2
-fbounds-check 
FAIL: gfortran.fortran-torture/execute/random_2.f90 execution,  -O2
-fomit-frame-pointer -finline-functions 
FAIL: gfortran.fortran-torture/execute/random_2.f90 execution,  -O2
-fomit-frame-pointer -finline-functions -funroll-loops 
FAIL: gfortran.fortran-torture/execute/random_2.f90 execution,  -O3 -g 
FAIL: gfortran.fortran-torture/execute/random_2.f90 execution,  -Os 
FAIL: gfortran.fortran-torture/execute/random_2.f90 execution, -O2
-ftree-vectorize -msse2 

Revision 176734 is OK.

[Bug tree-optimization/49822] [4.7 regression] Segfault in remove_prop_source_from_use

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-07-25 
14:15:06 UTC ---
Author: rguenth
Date: Mon Jul 25 14:15:02 2011
New Revision: 176745

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176745
Log:
2011-07-25  Richard Guenther  

PR tree-optimization/49822
* tree-ssa-forwprop.c (remove_prop_source_from_use): Robustify
more.  Make sure to preserve stmts with side-effects.  Properly
handle virtual defs, follow a longer def chain.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug middle-end/49840] [4.7 Regression] New test failures

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||i?86-*-*
   Target Milestone|--- |4.7.0

--- Comment #1 from Richard Guenther  2011-07-25 
14:17:12 UTC ---
Can't reproduce this on a x86_64 host.  I tried -m32 -mno-sse -march=i386
and also -march=i686.

[Bug rtl-optimization/48830] [4.4/4.5/4.6 regression] unrecognized insn: storing invalid upper FP reg in SImode

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

[Bug debug/49841] New: dwarf2cfi ICE during bootstrap on AIX

[dje at gcc dot gnu.org]

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

   Summary: dwarf2cfi ICE during bootstrap on AIX
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gcc.gnu.org


/tmp/20110725/./gcc/xgcc -B/tmp/20110725/./gcc/
-B/farm/dje/install/powerpc-ibm-aix5.3.0.0-20110725/powerpc-ibm-aix5.3.0.0/bin/
-B/farm/dje/install/powerpc-ibm-aix5.3.0.0-20110725/powerpc-ibm-aix5.3.0.0/lib/
-isystem
/farm/dje/install/powerpc-ibm-aix5.3.0.0-20110725/powerpc-ibm-aix5.3.0.0/include
-isystem
/farm/dje/install/powerpc-ibm-aix5.3.0.0-20110725/powerpc-ibm-aix5.3.0.0/sys-include
   -g -O2 -O2  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -mlong-double-128 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector   -I. -I. -I../.././gcc
-I/farm/dje/src/src/libgcc -I/farm/dje/src/src/libgcc/.
-I/farm/dje/src/src/libgcc/../gcc -I/farm/dje/src/src/libgcc/../include 
-DHAVE_CC_TLS -DUSE_EMUTLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF
unwind-dw2.dep -fexceptions -c /farm/dje/src/src/libgcc/../gcc/unwind-dw2.c 

In file included from /farm/dje/src/src/libgcc/../gcc/unwind-dw2.c:1590:0:
/farm/dje/src/src/libgcc/../gcc/unwind.inc: In function
'_Unwind_RaiseException':
/farm/dje/src/src/libgcc/../gcc/unwind.inc:136:1: internal compiler error: in
maybe_record_trace_start, at dwarf2cfi.c:2444

  /* We ought to have the same state incoming to a given trace no
 matter how we arrive at the trace.  Anything else means we've
 got some kind of optimization error.  */
  gcc_checking_assert (cfi_row_equal_p (cur_row, ti->beg_row));

The ICE occurs during stage 1 build of libgcc for all multilib variants of
unwind-dw2.c

[Bug rtl-optimization/48840] [4.4/4.5 regression] assertion failure in reload1.c

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

[Bug c/49820] Explicit check for integer negative after abs optimized away

[agner at agner dot org]

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

--- Comment #12 from Agner Fog  2011-07-25 14:21:52 UTC 
---
No the behavior is not predictable when it sometimes warns about ignoring
overflow, and sometimes not. Please add a warning when it optimizes away an
overflow check after the abs function.

Unsafe optimizations are sometimes good, sometimes causing hard-to-find bugs.
The programmer can't always predict what kind of optimizations the compiler
makes. A warning feature is the best way to enable the programmer to check if
the compiler does the right thing. The programmer can then turn off specific
warnings after verifying that the optimizations are OK.

[Bug debug/49841] [4.7 regression] AIX bootstrap failure in dwarf2cfi.c:maybe_record_trace_start

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.25 14:23:09
 Ever Confirmed|0   |1

[Bug target/47947] Variables of type vector double are not copied correctly in gcc-4.5.1 and gcc-4.6.0

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #12 from David Edelsohn  2011-07-25 
14:25:26 UTC ---
Fixed with patch for PR 47862

[Bug middle-end/49840] [4.7 Regression] New test failures

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-07-25 
14:27:50 UTC ---
Does

Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c  (revision 176745)
+++ gcc/tree-vrp.c  (working copy)
@@ -7432,11 +7465,15 @@ range_fits_type_p (value_range_t *vr, un
 return false;

   tem = double_int_ext (tree_to_double_int (vr->min), precision, unsigned_p);
-  if (!double_int_equal_p (tree_to_double_int (vr->min), tem))
+  if ((TYPE_UNSIGNED (TREE_TYPE (vr->min)) != unsigned_p
+   && (TREE_INT_CST_HIGH (vr->min) < 0) != (tem.high < 0))
+  || !double_int_equal_p (tree_to_double_int (vr->min), tem))
 return false;

   tem = double_int_ext (tree_to_double_int (vr->max), precision, unsigned_p);
-  if (!double_int_equal_p (tree_to_double_int (vr->max), tem))
+  if ((TYPE_UNSIGNED (TREE_TYPE (vr->max)) != unsigned_p
+   && (TREE_INT_CST_HIGH (vr->max) < 0) != (tem.high < 0))
+  || !double_int_equal_p (tree_to_double_int (vr->max), tem))
 return false;

   return true;

fix it?

[Bug c++/33255] A warning for "unused" typedefs?

[dodji at seketeli dot org]

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

--- Comment #23 from dodji at seketeli dot org  
2011-07-25 14:29:15 UTC ---
> --- Comment #19 from Paolo Carlini  
> 2011-07-24 22:49:32 UTC ---
> Just as a note, wanted also to add that if I understand correctly the
> (temporary?!?) small issue with system headers, it would also affect people
> building their code with -D_GLIBCXX_CONCEPT_CHECKS (by itself largely
> deprecated and not being updated for c++0x). Again, I don't see this as a
> serious issue if the new warning remains, for now at least, outside
> -Wall.

Building libstdc++ itself without _GLIBCXX_CONCEPT_CHECKS
raises this warning for e.g:

  typedef typename iterator_traits<_II1>::value_type _ValueType1;
  typedef typename iterator_traits<_II2>::value_type _ValueType2;

 [..]
  __glibcxx_function_requires(_LessThanOpConcept<_ValueType1, _ValueType2>)
  __glibcxx_function_requires(_LessThanOpConcept<_ValueType2, _ValueType1>)

(in libstdc++-v3/include/bits/stl_algobase.h)

As the macro __glibcxx_function_requires is defined to nothing (without
-D_GLIBCXX_CONCEPT_CHECKS) _ValueType1 and _ValueType2 appear unused
here.

So yes, -Wunused-local-typedefs definitely needs to be put out of --Wall
-Extra (and -Wunused).

Thanks.

[Bug middle-end/49840] [4.7 Regression] New test failures

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|4.7.0   |---

--- Comment #3 from H.J. Lu  2011-07-25 14:30:49 
UTC ---
(In reply to comment #1)
> Can't reproduce this on a x86_64 host.  I tried -m32 -mno-sse -march=i386
> and also -march=i686.

On Linux/x86-64 host, please configure gcc with

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

This is how I test GCC for Linux/ia32 on Linux/x86-64.

[Bug target/49833] [x32] PIC doesn't work

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2011-07-25 14:36:23 
UTC ---
The miscompiled function is

auto inline void
__attribute ((always_inline))
elf_machine_rela_relative (ElfW(Addr) l_addr, const ElfW(Rela) *reloc,
   void *const reloc_addr_arg)
{
  ElfW(Addr) *const reloc_addr = reloc_addr_arg;
  assert (ELF32_R_TYPE (reloc->r_info) == R_X86_64_RELATIVE);
  *reloc_addr = l_addr + reloc->r_addend;
}

[Bug target/49404] ARM _Unwind_Backtrace returns _URC_FAILURE too eagerly

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #1 from Ramana Radhakrishnan  2011-07-25 
14:46:27 UTC ---
If I read the EHABI( IHI0038A_ehabi.pdf) from infocenter.arm.com correctly. I
see that this is the behaviour as per the ABI specification. Read section 7.3
(Phase1 Unwinding) so that's probably right.

[Bug target/49833] [x32] PIC doesn't work

[ubizjak at gmail dot com]

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

--- Comment #3 from Uros Bizjak  2011-07-25 14:52:12 
UTC ---
(In reply to comment #2)
> The miscompiled function is

Er, not a testcase ...

[Bug tree-optimization/49809] [4.7 regression] gimple_check failure at -O3

[rsandifo at gcc dot gnu.org]

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

--- Comment #1 from rsandifo at gcc dot gnu.org  
2011-07-25 14:51:50 UTC ---
Author: rsandifo
Date: Mon Jul 25 14:51:47 2011
New Revision: 176750

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176750
Log:
gcc/
PR tree-optimization/49809
* tree-ssa-phiopt.c (cond_if_else_store_replacement): Use
gimple_get_lhs instead of gimple_assign_lhs.

gcc/testsuite/
PR tree-optimization/49809
* gnat.dg/opt18.adb, gnat.dg/opt18.ads, gnat.dg/opt18_pkg.ads: New
test.

Added:
trunk/gcc/testsuite/gnat.dg/opt18.adb
trunk/gcc/testsuite/gnat.dg/opt18.ads
trunk/gcc/testsuite/gnat.dg/opt18_pkg.ads
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiopt.c

[Bug tree-optimization/49809] [4.7 regression] gimple_check failure at -O3

[rsandifo at gcc dot gnu.org]

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

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

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #2 from rsandifo at gcc dot gnu.org  
2011-07-25 14:55:54 UTC ---
Fixed in trunk.

[Bug target/47124] *solaris2 configurations configure, but don't build

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  2011-07-25 14:58:22 UTC 
---
Author: ro
Date: Mon Jul 25 14:58:18 2011
New Revision: 176751

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176751
Log:
PR target/47124
* config.gcc: Reject *-*-solaris2 configuration.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc

[Bug target/47124] *solaris2 configurations configure, but don't build

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-07/msg02158.htm
   ||l
 CC||ro at gcc dot gnu.org
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0

--- Comment #2 from Rainer Orth  2011-07-25 15:00:32 UTC 
---
Fixed for 4.7.0.

[Bug debug/49841] [4.7 regression] AIX bootstrap failure in dwarf2cfi.c:maybe_record_trace_start

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Henderson  2011-07-25 
15:02:37 UTC ---
Mine.

[Bug target/41849] optimization fails when register variables are used for an interrupt

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  2011-07-25 
15:19:28 UTC ---
Created attachment 24828
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24828
C test case

[Bug target/49833] [x32] PIC doesn't work

[ubizjak at gmail dot com]

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

--- Comment #4 from Uros Bizjak  2011-07-25 15:20:42 
UTC ---
A shot-in-the-dark change:

(define_insn "*add_1"
  [(set (match_operand:SWI48 0 "nonimmediate_operand" "=r,rm,r,r")
(plus:SWI48
  (match_operand:SWI48 1 "nonimmediate_operand" "%0,0,r,r")
  (match_operand:SWI48 2 "" "rme,re,0,le")))
   (clobber (reg:CC FLAGS_REG))]

and

(define_insn "addsi_1_zext"
  [(set (match_operand:DI 0 "register_operand" "=r,r,r")
(zero_extend:DI
  (plus:SI (match_operand:SI 1 "nonimmediate_operand" "%0,r,r")
   (match_operand:SI 2 "addsi_operand" "rme,0,le"
   (clobber (reg:CC FLAGS_REG))]

The constraints of operand 2 now fully follow addsi_operand predicate.

[Bug c++/49347] G++ rejects Solaris spawn.h use of __restrict

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-07/msg02165.htm
   ||l
 CC||ro at gcc dot gnu.org
   Target Milestone|--- |4.7.0

--- Comment #5 from Rainer Orth  2011-07-25 15:20:02 UTC 
---
Mine, patch posted.

Jason, will there be restrict support in C++ 2011?  If so, I might report this
to Oracle, otherwise (with __restrict) it's a pure g++ issue.

Thanks.
  Rainer

[Bug target/41849] optimization fails when register variables are used for an interrupt

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  2011-07-25 
15:21:54 UTC ---
Created attachment 24829
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24829
Test case from attachment 24828 as compiled with avr-gcc 4.4.2

For compiler options, see the attachment: -Os -mmcu=atmega8.

[Bug target/41849] optimization fails when register variables are used for an interrupt

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.4.2
 Resolution||WORKSFORME

--- Comment #4 from Georg-Johann Lay  2011-07-25 
15:26:02 UTC ---
Closed as WORKSFORME. avr-gcc 4.4.2 compiles the test case correctly.

[Bug tree-optimization/49309] [4.6 Regression] ICE with -fmudflap: verify_stmts failed: type mismatch in pointer plus expression

[ro at gcc dot gnu.org]

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

--- Comment #10 from Rainer Orth  2011-07-25 15:25:37 
UTC ---
Author: ro
Date: Mon Jul 25 15:25:32 2011
New Revision: 176752

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176752
Log:
gcc/testsuite:
PR testsuite/49753
* g++.dg/torture/pr49309.C: Add -fpreprocessed to dg-options.

Revert:
2011-07-15  Jakub Jelinek  

PR testsuite/49753
* g++.dg/torture/pr49309.C: Remove.

libmudflap:
Revert:
2011-07-15  Jakub Jelinek  

PR testsuite/49753
PR tree-optimization/49309
* testsuite/libmudflap.c++/pass68-frag.cxx: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr49309.C
  - copied, changed from r176751,
trunk/libmudflap/testsuite/libmudflap.c++/pass68-frag.cxx
Removed:
trunk/libmudflap/testsuite/libmudflap.c++/pass68-frag.cxx
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libmudflap/ChangeLog

[Bug testsuite/49753] [4.6/4.7 Regression] FAIL: g++.dg/torture/pr49309.C

[ro at gcc dot gnu.org]

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

--- Comment #6 from Rainer Orth  2011-07-25 15:25:37 UTC 
---
Author: ro
Date: Mon Jul 25 15:25:32 2011
New Revision: 176752

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176752
Log:
gcc/testsuite:
PR testsuite/49753
* g++.dg/torture/pr49309.C: Add -fpreprocessed to dg-options.

Revert:
2011-07-15  Jakub Jelinek  

PR testsuite/49753
* g++.dg/torture/pr49309.C: Remove.

libmudflap:
Revert:
2011-07-15  Jakub Jelinek  

PR testsuite/49753
PR tree-optimization/49309
* testsuite/libmudflap.c++/pass68-frag.cxx: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr49309.C
  - copied, changed from r176751,
trunk/libmudflap/testsuite/libmudflap.c++/pass68-frag.cxx
Removed:
trunk/libmudflap/testsuite/libmudflap.c++/pass68-frag.cxx
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libmudflap/ChangeLog

[Bug testsuite/49753] [4.6/4.7 Regression] FAIL: g++.dg/torture/pr49309.C

[ro at gcc dot gnu.org]

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

--- Comment #7 from Rainer Orth  2011-07-25 15:28:30 UTC 
---
Author: ro
Date: Mon Jul 25 15:28:27 2011
New Revision: 176753

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176753
Log:
gcc/testsuite:
PR testsuite/49753
* g++.dg/torture/pr49309.C: Add -fpreprocessed to dg-options.

Revert:
2011-07-15  Jakub Jelinek  

PR testsuite/49753
* g++.dg/torture/pr49309.C: Remove.

libmudflap:
Revert:
2011-07-15  Jakub Jelinek  

PR testsuite/49753
PR tree-optimization/49309
* testsuite/libmudflap.c++/pass68-frag.cxx: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/torture/pr49309.C
  - copied, changed from r176752,
branches/gcc-4_6-branch/libmudflap/testsuite/libmudflap.c++/pass68-frag.cxx
Removed:
branches/gcc-4_6-branch/libmudflap/testsuite/libmudflap.c++/pass68-frag.cxx
Modified:
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/libmudflap/ChangeLog

[Bug tree-optimization/49309] [4.6 Regression] ICE with -fmudflap: verify_stmts failed: type mismatch in pointer plus expression

[ro at gcc dot gnu.org]

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

--- Comment #11 from Rainer Orth  2011-07-25 15:28:30 
UTC ---
Author: ro
Date: Mon Jul 25 15:28:27 2011
New Revision: 176753

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176753
Log:
gcc/testsuite:
PR testsuite/49753
* g++.dg/torture/pr49309.C: Add -fpreprocessed to dg-options.

Revert:
2011-07-15  Jakub Jelinek  

PR testsuite/49753
* g++.dg/torture/pr49309.C: Remove.

libmudflap:
Revert:
2011-07-15  Jakub Jelinek  

PR testsuite/49753
PR tree-optimization/49309
* testsuite/libmudflap.c++/pass68-frag.cxx: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/torture/pr49309.C
  - copied, changed from r176752,
branches/gcc-4_6-branch/libmudflap/testsuite/libmudflap.c++/pass68-frag.cxx
Removed:
branches/gcc-4_6-branch/libmudflap/testsuite/libmudflap.c++/pass68-frag.cxx
Modified:
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/libmudflap/ChangeLog

[Bug c++/49838] [C++0x] ICE in cp_parser_perform_range_for_lookup, at cp/parser.c:8796

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  
2011-07-25 15:29:16 UTC ---
Author: paolo
Date: Mon Jul 25 15:29:13 2011
New Revision: 176754

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176754
Log:
/cp
2011-07-25  Paolo Carlini  

PR c++/49838
* parser.c (cp_parser_perform_range_for_lookup): Early return if
error_operand_p (range).

/testsuite
2011-07-25  Paolo Carlini  

PR c++/49838
* g++.dg/cpp0x/range-for19.C: New.


Added:
trunk/gcc/testsuite/g++.dg/cpp0x/range-for19.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/49838] [C++0x] ICE in cp_parser_perform_range_for_lookup, at cp/parser.c:8796

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Paolo Carlini  2011-07-25 
15:30:20 UTC ---
Done.

[Bug target/49842] New: sparc64-portbld-freebsd9.0 internal compiler error: in connect_traces, at dwarf2cfi.c:2632

[mexas at bristol dot ac.uk]

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

   Summary: sparc64-portbld-freebsd9.0  internal compiler error:
in connect_traces, at dwarf2cfi.c:2632
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: me...@bristol.ac.uk


I've gcc-4.7.0.20110709 built fine on sparc64 FreeBSD 9.0.
Updating to 20110723 snapshot I get this error:

/usr/ports/lang/gcc47/work/build/./gcc/xgcc
-B/usr/ports/lang/gcc47/work/build/./gcc/
-B/usr/local/sparc64-portbld-freebsd9.0/bin/
-B/usr/local/sparc64-portbld-freebsd9.0/lib/ -isystem
/usr/local/sparc64-portbld-freebsd9.0/include -isystem
/usr/local/sparc64-portbld-freebsd9.0/sys-include-g -O2 -pipe
-I/usr/local/include -fno-strict-aliasing -O2  -g -O2 -pipe
-I/usr/local/include -fno-strict-aliasing -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fPIC -pthread -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector   -I. -I. -I../.././gcc
-I../.././../gcc-4.7-20110723/libgcc -I../.././../gcc-4.7-20110723/libgcc/.
-I../.././../gcc-4.7-20110723/libgcc/../gcc
-I../.././../gcc-4.7-20110723/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o
_lshrdi3.o -MT _lshrdi3.o -MD -MP -MF _lshrdi3.dep -DL_lshrdi3 -c
../.././../gcc-4.7-20110723/libgcc/../gcc/libgcc2.c \
  -fvisibility=hidden -DHIDE_EXPORTS
../.././../gcc-4.7-20110723/libgcc/../gcc/libgcc2.c: In function '__lshrti3':
../.././../gcc-4.7-20110723/libgcc/../gcc/libgcc2.c:427:1: internal compiler
error: in connect_traces, at dwarf2cfi.c:2632
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
gmake[3]: *** [_lshrdi3.o] Error 1
gmake[3]: Leaving directory
`/usr/ports/lang/gcc47/work/build/sparc64-portbld-freebsd9.0/libgcc'

Surprisingly, it builds fine on ia64 FreeBSD.

I see in sparc64-portbld-freebsd9.0/libgcc/config.log:

conftest.c:58:1: internal compiler error: in connect_traces, at
dwarf2cfi.c:2632

config.log is attached.

[Bug target/49842] sparc64-portbld-freebsd9.0 internal compiler error: in connect_traces, at dwarf2cfi.c:2632

[mexas at bristol dot ac.uk]

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

--- Comment #1 from Anton Shterenlikht  2011-07-25 
15:33:50 UTC ---
Created attachment 24830
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24830
/usr/ports/lang/gcc47/work/build/sparc64-portbld-freebsd9.0/libgcc/config.log

[Bug libmudflap/49843] New: 64-bit libmudflap.c++/pass55-frag.cxx FAILs at -O

[ro at gcc dot gnu.org]

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

   Summary: 64-bit libmudflap.c++/pass55-frag.cxx FAILs at -O
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libmudflap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: f...@redhat.com
  Host: i386-pc-solaris2.1[01], sparc-sun-solaris2*,
x86_64-unknown-linux-gnu
Target: i386-pc-solaris2.1[01], sparc-sun-solaris2*,
x86_64-unknown-linux-gnu
 Build: i386-pc-solaris2.1[01], sparc-sun-solaris2*,
x86_64-unknown-linux-gnu


It seems that there's only one libmudflap test failing on most targets:

FAIL: libmudflap.c++/pass55-frag.cxx ( -O) execution test

It only fails for 64-bit multilibs and only at -O, -O[023] does work.

I wonder what to do about that. I do have a patch to XFAIL the test, but
strangely it turns the FAIL into a PASS, not XFAIL.

  Rainer

[Bug libgomp/45351] many unaligned accesses in libgomp tests

[ro at gcc dot gnu.org]

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

--- Comment #13 from Rainer Orth  2011-07-25 15:39:58 
UTC ---
Author: ro
Date: Mon Jul 25 15:39:52 2011
New Revision: 176755

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176755
Log:
PR libgomp/45351
* config/osf/sem.h: New file.
* configure.tgt (alpha*-dec-osf*): Prepend osf to config_path.

Added:
trunk/libgomp/config/osf/
trunk/libgomp/config/osf/sem.h
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/configure.tgt

[Bug target/39386] [avr] different computation results for O1 and O0 executables

[gjl at gcc dot gnu.org]

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

--- Comment #12 from Georg-Johann Lay  2011-07-25 
15:42:00 UTC ---
Author: gjl
Date: Mon Jul 25 15:41:55 2011
New Revision: 176756

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

PR target/39386
* config/avr/avr.c (out_shift_with_cnt): Use tmp_reg as
shift counter for x << x and x >> x shifts.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c

[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)

[rguenth at gcc dot gnu.org]

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

--- Comment #42 from Richard Guenther  2011-07-25 
15:39:54 UTC ---
With gas_dyn changed to use MINLOC (DTEMP, 1) we now inline the intrinsic
(but not with MINLOC (DTEMP), even though we know it'll be a single-element
array result ...).

We completely lack a way to fuse the loops though.  Inlining the intrinsic
gives a moderate 5% speedup.

[Bug libgomp/45351] many unaligned accesses in libgomp tests

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-07/msg02162.htm
   ||l
 Resolution||FIXED

--- Comment #14 from Rainer Orth  2011-07-25 15:40:44 
UTC ---
Fixed for 4.7.0.

[Bug target/39386] [avr] different computation results for O1 and O0 executables

[gjl at gcc dot gnu.org]

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

--- Comment #13 from Georg-Johann Lay  2011-07-25 
15:45:51 UTC ---
Author: gjl
Date: Mon Jul 25 15:45:47 2011
New Revision: 176757

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

PR target/39386
Backport from mainline r176756
2011-07-25  Georg-Johann Lay
* config/avr/avr.c (out_shift_with_cnt): Use tmp_reg as
shift counter for x << x and x >> x shifts.


Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/avr/avr.c

[Bug target/49404] ARM _Unwind_Backtrace returns _URC_FAILURE too eagerly

[akos.pasztory at gmail dot com]

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

--- Comment #2 from Akos PASZTORY  2011-07-25 
15:51:06 UTC ---
Does that also apply to _Unwind_Backtrace?  Unfortunately the specification I
found [1] doesn't elaborate on the return values.  Would anything bad happen if
it just returned the error code unmodified?

[1]
http://refspecs.freestandards.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/baselib--unwind-backtrace.html

[Bug c++/49347] G++ rejects Solaris spawn.h use of __restrict

[ro at gcc dot gnu.org]

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

--- Comment #6 from Rainer Orth  2011-07-25 15:56:31 UTC 
---
Author: ro
Date: Mon Jul 25 15:56:27 2011
New Revision: 176758

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176758
Log:
PR c++/49347
* inclhack.def (solaris_posix_spawn_restrict): New fix.
* fixincl.x: Regenerate.
* tests/base/spawn.h: New test.

Added:
trunk/fixincludes/tests/base/spawn.h
Modified:
trunk/fixincludes/ChangeLog
trunk/fixincludes/fixincl.x
trunk/fixincludes/inclhack.def

[Bug c++/49347] G++ rejects Solaris spawn.h use of __restrict

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |

--- Comment #7 from Rainer Orth  2011-07-25 15:58:38 UTC 
---
Fixed for 4.7.0, to be backported to 4.6 branch.

[Bug lto/49844] New: Building CodeBlocks on Windows using mingw gcc 4.6.1 "-flto -fuse-linker-plugin" results in many linker stage errors

[xunxun1982 at gmail dot com]

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

   Summary: Building CodeBlocks on Windows using mingw gcc 4.6.1
"-flto -fuse-linker-plugin" results in many linker
stage errors
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xunxun1...@gmail.com
  Host: i686-pc-mingw32
Target: i686-pc-mingw32
 Build: i686-pc-mingw32


My gcc4.6.1 configure with :
./configure --prefix=/mingw --host=i686-pc-mingw32 --build=i686-pc-mingw32
--target=i686-pc-mingw32 \
 --with-lto-plugin --with-host-libstdcxx=-lstdc++ --disable-bootstrap
--disable-werror --with-arch=i686 --with-tune=generic \
--enable-languages=c,c++,fortran --enable-libgomp --enable-threads=win32
--enable-lto --with-system-zlib \
--enable-libstdcxx-debug --enable-version-specific-runtime-libs
--enable-fully-dynamic-string \
--disable-sjlj-exceptions --with-dwarf2 --disable-symvers
--enable-checking=release \
--enable-plugins --enable-cloog-backend=isl --enable-static
--disable-shared \
--disable-nls --disable-win32-registry

My ld version is : 2.21.52.20110708

When I build Code::Blocks, if I add "-flto" to the compiler option, and add
"-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -s -flto -fuse-linker-plugin" to the
linker option, that will result in many linker stage errors:


g++.exe -shared  -Wl,--out-implib=devel\libwxpropgrid.a -Wl,--dll
-Lbase\tinyxml -LE:\MyPack\3rdLib\GUI\wxWidgets-2.8.12\lib\gcc_dll 
.objs\sdk\wxpropgrid\src\editors.o .objs\sdk\wxpropgrid\src\extras.o
.objs\sdk\wxpropgrid\src\manager.o .objs\sdk\wxpropgrid\src\odcombo.o
.objs\sdk\wxpropgrid\src\propgrid.o .objs\sdk\wxpropgrid\src\props.o
.objs\sdk\wxpropgrid\src\xh_propgrid.o .objs\sdk\wxpropgrid\src\advprops.o   -o
devel\wxpropgrid.dll -mthreads -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -s
-flto -fuse-linker-plugin -Wl,--allow-multiple-definition
-Wl,--enable-auto-image-base -Wl,--add-stdcall-alias -Wl,--enable-auto-import 
-lwxmsw28u
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x1913): undefined
reference to `_imp___ZTV17wxStringTokenizer.local.832'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x1aeb): undefined
reference to `_imp___ZTV15wxDirDialogBase.local.831'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x2658): undefined
reference to `_imp___ZTV18wxDataObjectSimple.local.823'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x308b): undefined
reference to `_imp___ZTV17wxStringTokenizer.local.832'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x3251): undefined
reference to `_imp___ZTV15wxDirDialogBase.local.831'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x4ef4): undefined
reference to `_imp___ZTV18wxBitmapButtonBase.local.822'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x4ff2): undefined
reference to `_imp___ZTV18wxBitmapButtonBase.local.822'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x5c8f): undefined
reference to `_imp___ZTV12wxRegionBase.local.837'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x5cdf): undefined
reference to `_imp___ZTV12wxRegionBase.local.837'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x5d25): undefined
reference to `_imp___ZTV11wxBrushBase.local.835'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x5d75): undefined
reference to `_imp___ZTV11wxBrushBase.local.835'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x5f33): undefined
reference to `_imp___ZTV15wxHashTableBase.local.795'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x5f6f): undefined
reference to `_imp___ZTV15wxHashTableBase.local.795'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x6859): undefined
reference to `_imp___ZTV17wxMBConvUTF16Base.local.829'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x6887): undefined
reference to `_imp___ZTV17wxMBConvUTF16Base.local.829'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x68ab): undefined
reference to `_imp___ZTV17wxMBConvUTF32Base.local.828'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x68d9): undefined
reference to `_imp___ZTV17wxMBConvUTF32Base.local.828'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x6c8f): undefined
reference to `_imp___ZTV18wxDataObjectSimple.local.823'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x6cbd): undefined
reference to `_imp___ZTV18wxDataObjectSimple.local.823'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x6f79): undefined
reference to `_imp___ZTV12wxObjectList.local.816'
F:\Temp\ccOvkJMp.ltrans0.ltrans.o:ccOvkJMp.ltrans0.o:(.text+0x6fa7): undefined
reference to `_im

[Bug target/39386] [avr] different computation results for O1 and O0 executables

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #14 from Georg-Johann Lay  2011-07-25 
16:08:04 UTC ---
Closed as FIXED.

[Bug debug/49827] [4.7 regression] sparc64-linux and cris-elf bootstrap failures due to ICE in dwarf2cfi.c connect_traces

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||mexas at bristol dot ac.uk

--- Comment #8 from Eric Botcazou  2011-07-25 
16:09:57 UTC ---
*** Bug 49842 has been marked as a duplicate of this bug. ***

[Bug target/49842] sparc64-portbld-freebsd9.0 internal compiler error: in connect_traces, at dwarf2cfi.c:2632

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ebotcazou at gcc dot
   ||gnu.org
 Resolution||DUPLICATE

--- Comment #2 from Eric Botcazou  2011-07-25 
16:09:57 UTC ---
The 'search' button is your friend.

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