[Bug c++/50956] New: -Wcast-qual does not work

[joerg.rich...@pdv-fs.de]

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

 Bug #: 50956
   Summary: -Wcast-qual does not work
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de


-Wcast-qual seems to be broken since at least GCC 4.1.1.

cat > t.cc <

[Bug c++/50941] [C++0x] user-defined string literals provide incorrect length for wchar_t, char16_t, and char32_t

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2011-11-02 
07:43:06 UTC ---
Please watch your formatting:
UNIT ( TREE_TYPE( TREE_TYPE(value
should have been:
UNIT (TREE_TYPE (TREE_TYPE (value

[Bug libstdc++/50957] New: complex ctor drops sign of zero (sometimes)

[kreckel at ginac dot de]

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

 Bug #: 50957
   Summary: complex ctor drops sign of zero (sometimes)
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: krec...@ginac.de


When compiling with -std=c++0x (and only then), the ctor of g++ drops the sign
of zero. (This sometimes devastates the correct choice of branch cuts in the
complex plain.) Interestingly, it doesn't happen with my mock complex class.

#include 
#include 
using namespace std;

template
struct mock_complex
{
typedef _Tp value_type;
_GLIBCXX_CONSTEXPR mock_complex(const _Tp& __r = _Tp(), const _Tp& __i =
_Tp())
: _M_real(__r), _M_imag(__i) { }
const _Tp
real() const { return _M_real; }
const _Tp
imag() const { return _M_imag; }
private:
_Tp _M_real;
_Tp _M_imag;
};

int main()
{
mock_complex z1(-0.0, 1.0);
cout << signbit(z1.real()) << signbit(z1.imag()) << endl;  // correct: 10

complex z2(-0.0, 1.0);
cout << signbit(z2.real()) << signbit(z2.imag()) << endl;  // wrong: 00
}

[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch

[kreckel at ginac dot de]

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

Richard B. Kreckel  changed:

   What|Removed |Added

   See Also||http://gcc.gnu.org/bugzilla
   ||/show_bug.cgi?id=50957

--- Comment #11 from Richard B. Kreckel  2011-11-02 
08:26:51 UTC ---
Paolo, I still intend to come forward with a patch for all these cases.
Unfortunately, I was distracted by what I've just filed as Bug 50957.

[Bug fortran/50933] Wrongly regards BIND(C) types as incompatible

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2011-11-02 
08:30:20 UTC ---
Untested patch:

--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -405,7 +405,7 @@ gfc_compare_derived_types (gfc_symbol *derived1, gfc_symbol
*derived2)
 return 1;

   /* Compare type via the rules of the standard.  Both types must have
- the SEQUENCE attribute to be equal.  */
+ the SEQUENCE or BIND(C) attribute to be equal.  */

   if (strcmp (derived1->name, derived2->name))
 return 0;
@@ -414,7 +414,8 @@ gfc_compare_derived_types (gfc_symbol *derived1, gfc_symbol
*derived2)
   || derived2->component_access == ACCESS_PRIVATE)
 return 0;

-  if (derived1->attr.sequence == 0 || derived2->attr.sequence == 0)
+  if (!(derived1->attr.sequence && derived2->attr.sequence)
+  && !(derived1->attr.is_bind_c && derived2->attr.is_bind_c))
 return 0;

   dt1 = derived1->components;

[Bug middle-end/50890] [4.7 Regression] ICE in fold_convert_loc, at fold-const.c:1894

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-11-02 
08:46:12 UTC ---
Author: rguenth
Date: Wed Nov  2 08:46:08 2011
New Revision: 180763

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180763
Log:
2010-11-02  Richard Guenther  

PR tree-optimization/50890
* gimple.h (gimple_fold_call): Remove.
* gimple-fold.c (fold_stmt_1): Move all call related code to ...
(gimple_fold_call): ... here.  Make static.  Update the
cannot-inline flag on direct calls.
* ipa-inline.c (early_inliner): Copy the cannot-inline flag
from the statements to the edges.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr50890.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/gimple.h
trunk/gcc/ipa-inline.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/50890] [4.7 Regression] ICE in fold_convert_loc, at fold-const.c:1894

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Richard Guenther  2011-11-02 
08:46:36 UTC ---
Fixed.

[Bug middle-end/50881] ICE Segfault on compare this pointer with reference

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Component|c++ |middle-end

--- Comment #7 from Richard Guenther  2011-11-02 
08:57:50 UTC ---
We have corrupt EH info during cfgcleaup right before expand.  Reducing.

[Bug middle-end/50881] [4.6 Regression] ICE Segfault on compare this pointer with reference

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Known to work||4.5.3
   Target Milestone|--- |4.6.3
Summary|ICE Segfault on compare |[4.6 Regression] ICE
   |this pointer with reference |Segfault on compare this
   ||pointer with reference
  Known to fail||4.6.1

--- Comment #8 from Richard Guenther  2011-11-02 
09:02:16 UTC ---
Reduced testcase:

class CompareThisRefICE {
CompareThisRefICE();
};
typedef unsigned short ushort;
class __attribute__((visibility("default"))) QString {
public:
~QString();
inline QString(const char *ch) : d(fromAscii_helper(ch)) { }
struct Data { ushort righttoleft : 11; };
Data *d;
static Data *fromAscii_helper(const char *str, int size = -1);
};
class B { };
CompareThisRefICE::CompareThisRefICE() {
CompareThisRefICE t;
if (!(this != &t)) {
QString b("boom");
throw B();
}
}

[Bug c++/50958] New: [C++0x] raw literal operator provides incorrect string for integer literal '0'

[daniel.kruegler at googlemail dot com]

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

 Bug #: 50958
   Summary: [C++0x] raw literal operator provides incorrect string
for integer literal '0'
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: 3dw...@verizon.net


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

//---
typedef decltype(sizeof(0)) size_type;

constexpr size_type cstrlen_impl(const char* s, size_type i)
{
  return s[i] ? cstrlen_impl(s, i + 1) : i;
}

constexpr size_type cstrlen(const char* s)
{
  return s ? cstrlen_impl(s, 0) : throw 0;
}

constexpr size_type operator "" _lenraw(const char* digits)
{
  return cstrlen(digits);
}

static_assert(1_lenraw == 1, "Ouch"); // OK
static_assert(0_lenraw == 1, "Ouch"); // Error
//---

The error I'm getting is:

main.cpp|19|error: non-constant condition for static assertion|
main.cpp|19|  in constexpr expansion of 'operator"" _lenraw(0u)'|
main.cpp|15|  in constexpr expansion of 'cstrlen(digits)'|
main.cpp|10|error: expression '' is not a
constant-expression|

This allows the conclusion, that the octal integer literal '0' is incorrectly
handled, instead of the expected string length of 1 the raw literal operator
gets a NULL string pointer. This seems to violate 2.14.8 p3 where 'n' would be
equal to '0' which should lead to the effective string literal argument "0" in
this case.

[Bug lto/50935] All slim LTO tests FAIL on 32-bit Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-11-02 09:18:04 UTC ---
> --- Comment #1 from Richard Guenther  2011-11-01 
> 09:27:20 UTC ---
> Confirmed.  Can you try writing a dg-effective-target test?

Sure, that's my plan once I'm done with the libgcc patches.

Rainer

[Bug tree-optimization/50912] [4.7 regression] gimple assertion failure at gimple.h:1940 with -msse2

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-11-02
 CC||irar at il dot ibm.com
 AssignedTo|unassigned at gcc dot   |irar at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Ira Rosen  2011-11-02 09:25:03 UTC 
---
This is a bug in SLP analysis.

[Bug target/49098] unused parameters in rx.c:rx_memory_move_cost

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #2 from Manuel López-Ibáñez  2011-11-02 
09:36:22 UTC ---
This seems FIXED, no?

[Bug c++/50957] [C++0x][constexpr] complex ctor drops sign of zero (sometimes)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2011-11-02
  Component|libstdc++   |c++
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1
Summary|complex ctor drops sign  |[C++0x][constexpr]
   |of zero (sometimes) |complex ctor drops sign
   ||of zero (sometimes)
  Known to fail||4.6.2

--- Comment #1 from Richard Guenther  2011-11-02 
09:36:44 UTC ---
Confirmed.  Looks like a frontend issue (probably related to constexpr?).
In .initial we have

{
  struct mock_complex z1 = {._M_real=-0.0, ._M_imag=1.0e+0};
  struct complex z2 = {._M_value=__complex__ (0.0, 1.0e+0)};

  <>;

thus z2 is already initialized from a bogus value.  Without -std=c++0x we have

  struct complex z2;
  <::complex (&z2, -0.0, 1.0e+0) >;

which is correct.

[Bug c++/50957] [C++0x][constexpr] complex ctor drops sign of zero (sometimes)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Paolo Carlini  2011-11-02 
09:39:20 UTC ---
This just PR48760 in a different form, mainline is fine.

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

[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch

[paolo.carlini at oracle dot com]

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

--- Comment #12 from Paolo Carlini  2011-11-02 
09:40:26 UTC ---
In my opinion BC2 is fine, I can take of applying it, if you still endorse it.

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-11-02
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |4.7.0
Summary|IVopts incorrectly rewrite  |[4.7 Regression] IVopts
   |the address of a global |incorrectly rewrite the
   |memory access into a local  |address of a global memory
   |form.   |access into a local form.
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-11-02 
09:42:23 UTC ---
I think we should prune any candidate that has more than one symbol in its
affine combination (or rather not add such candidates in the first place).

[Bug other/50953] Snow Leopard 10.6.8 - TinyOS - Segmentation Fault

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther  2011-11-02 
09:42:40 UTC ---
empyt.

[Bug other/50954] Snow Leopard 10.6.8 - TinyOS Oscilloscope - Segmentation Fault

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther  2011-11-02 
09:42:58 UTC ---
GCC 4.2 is no longer maintained.  Complain to apple.

[Bug libstdc++/48760] [4.6 Regression] std::complex constructor buggy in the face of NaN's

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||kreckel at ginac dot de

--- Comment #33 from Paolo Carlini  2011-11-02 
09:39:20 UTC ---
*** Bug 50957 has been marked as a duplicate of this bug. ***

[Bug middle-end/50950] warning missed when OR'ing to an uninitialized variable

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-11-02 
09:48:16 UTC ---
No, it's the lame warning-for-uninitialized-memory (your variables are
address-taken) code that triggered in 4.4 but not in newer releases.
Thus it's more related to PR50040.

Note that I don't think we should warn for bitwise OR with 1 (but we should for
bitwise AND), the testcase will simply make one bit initialized, not
using any uninitialized info.  Thus not warning for this particular case is
good.

[Bug middle-end/50950] warning missed when OR'ing to an uninitialized variable

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Richard Guenther  2011-11-02 
09:49:45 UTC ---
A dup actually (fixed on trunk):

t.c: In function 'f0':
t.c:14:5: warning: 'x' is used uninitialized in this function [-Wuninitialized]
t.c: In function 'f1':
t.c:22:11: warning: 'x.i32.i' is used uninitialized in this function
[-Wuninitialized]
t.c: In function 'ff1':
t.c:30:5: warning: 'x' is used uninitialized in this function [-Wuninitialized]
t.c: In function 'ff2':
t.c:40:11: warning: 'y.i32.i' is used uninitialized in this function
[-Wuninitialized]

even better than for 4.4.

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

[Bug middle-end/50040] [4.5/4.6 Regression] missed warning: ‘x.y’ is used uninitialized in this function

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||sezeroz at gmail dot com

--- Comment #7 from Richard Guenther  2011-11-02 
09:49:45 UTC ---
*** Bug 50950 has been marked as a duplicate of this bug. ***

[Bug libstdc++/50951] state of subtract_with_carry_engine not saved correctly to output stream

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  
2011-11-02 10:06:16 UTC ---
Author: paolo
Date: Wed Nov  2 10:06:08 2011
New Revision: 180764

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180764
Log:
2011-11-02  Paolo Carlini  

PR libstdc++/50951
* include/bits/random.tcc (operator<<(basic_ostream<>&,
const mersenne_twister_engine<>&): Output _M_p too.
(operator<<(basic_ostream<>&, const
subtract_with_carry_engine<>&): Likewise.
(operator>>(basic_istream<>&, mersenne_twister_engine<>&):
Reload it.
(operator>>(basic_istream<>&, subtract_with_carry_engine<>&):
Likewise.
* include/bits/random.h (mersenne_twister_engine<>::operator==):
Compare _M_p too.
(subtract_with_carry_engine<>::operator==): Compare _M_carry
and _M_p too.
(shuffle_order_engine<>::operator==): Compare _M_v(s) and _M_y too.
* testsuite/26_numerics/random/independent_bits_engine/
operators/serialize.cc: Extend.
* testsuite/26_numerics/random/subtract_with_carry_engine/
operators/serialize.cc: Likewise.
* testsuite/26_numerics/random/discard_block_engine/
operators/serialize.cc: Likewise.
* testsuite/26_numerics/random/mersenne_twister_engine/
operators/serialize.cc: Likewise.
* testsuite/26_numerics/random/linear_congruential_engine/
operators/serialize.cc: Likewise.
* testsuite/26_numerics/random/shuffle_order_engine/
operators/serialize.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/random.h
trunk/libstdc++-v3/include/bits/random.tcc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/discard_block_engine/operators/serialize.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/independent_bits_engine/operators/serialize.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/linear_congruential_engine/operators/serialize.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/mersenne_twister_engine/operators/serialize.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/shuffle_order_engine/operators/serialize.cc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/subtract_with_carry_engine/operators/serialize.cc

[Bug libstdc++/50951] state of subtract_with_carry_engine not saved correctly to output stream

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

  Known to work||4.7.0
   Target Milestone|--- |4.6.3

--- Comment #4 from Paolo Carlini  2011-11-02 
10:08:46 UTC ---
Fixed in mainline. Let's keep open the option to fix it in the branch too.

[Bug tree-optimization/50902] [4.7 Regression] intVar/dinternal.cc ICEs at -O2 -ftree-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Richard Guenther  2011-11-02 
10:20:51 UTC ---
Fixed.

[Bug tree-optimization/50902] [4.7 Regression] intVar/dinternal.cc ICEs at -O2 -ftree-vectorize

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Guenther  2011-11-02 
10:20:36 UTC ---
Author: rguenth
Date: Wed Nov  2 10:20:32 2011
New Revision: 180765

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180765
Log:
2011-11-02  Richard Guenther  

PR tree-optimization/50902
* tree-vect-stmts.c (vectorizable_load): Properly convert
an invariant initializer element.

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

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

[Bug fortran/50959] New: [OOP] Redundant setting of the vptr

[burnus at gcc dot gnu.org]

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

 Bug #: 50959
   Summary: [OOP] Redundant setting of the vptr
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org


It is pointless to store the vptr if one does not use it.

Example: The invalid ("x" is not allocated) code
  use m
  class(t), allocatable :: x
  j = x%i
produces the dump:
  x._data = 0B;
  (struct __vtype_m_T *) x._vptr = &__vtab_m_T;
  j = x._data->i;

There is no point for the "x._vptr = ". The vptr for pointers/allocatable
should only be set for ALLOCATE (explicit or polymorphic intrinsic) or pointer
assignment - but not as part of the initialization.

For a more real-world example, see below. There one has:

  (struct __vtype_m_T *) x._vptr = &__vtab_m_T;
  /* malloc block */
  (struct __vtype_m_T *) x._vptr = &__vtab_m_T;
where the last line is part of the ALLOCATE.


module m
  type t
  contains
procedure, nopass :: bar => base
  end type t

  type, extends(t) :: t2
  contains
procedure, nopass :: bar => ext
  end type t2
contains
  subroutine base()
write(*,*) 'BASE t1'
  end subroutine
  subroutine ext()
write(*,*) 'EXT t2'
  end subroutine
end module

program test
  use m
  class(t), allocatable :: x
  allocate (t :: x)
  call x%bar ()
end program test

[Bug fortran/50960] New: [OOP] vtables not marked as constant

[burnus at gcc dot gnu.org]

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

 Bug #: 50960
   Summary: [OOP] vtables not marked as constant
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org


< richi> and it seems the vtables are not initialized in a way the
 optimizers could use them
< richi> they are not constant
< richi> your testcase should be trivially de-virtualizable by early FRE

For the test case, see PR 50959 comment 0

[Bug translation/45116] config/ia64/vms_symvec_libgcc_s.opt not an options file

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  2011-11-02 10:49:50 UTC 
---
Author: ro
Date: Wed Nov  2 10:49:46 2011
New Revision: 180767

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180767
Log:
Move shlib support to toplevel libgcc

gcc:
PR translation/45116
* Makefile.in (slibdir): Remove, don't export.
(SHLIB_NM_FLAGS): Remove.
(libgcc.mvars): Don't emit SHLIB_LINK, SHLIB_INSTALL,
SHLIB_DLLDIR, SHLIB_EXT, SHLIB_MKMAP, SHLIB_MKMAP_OPTS,
SHLIB_MAPFILES, SHLIB_NM_FLAGS.
(DRIVER_DEFINES): Test SHLIB instead of SHLIB_LINK.
(gcc.o): Pass SHLIB instead of SHLIB_LINK.
(gccspec.o): Likewise.
(installdirs): Don't create $(DESTDIR)$(slibdir).
* configure.ac (slibdir): Remove.
* configure: Regenerate.
* libgcc-libsystem.ver: Move to ../libgcc/config.
* mkmap-flat.awk, mkmap-symver.awk: Move to ../libgcc.
* config/libgcc-glibc.ver: Move to ../libgcc/config.
* config/t-libunwind (SHLIB_LC): Remove.
* config/t-linux (SHLIB_MAPFILES): Remove.
* config/t-slibgcc-dummy: Rename to config/t-slibgcc.
* config/t-slibgcc-elf-ver: Remove.
* config/t-slibgcc-libgcc, config/t-slibgcc-nolc-override: Move to
../libgcc/config.
* config/alpha/libgcc-alpha-ldbl.ver, config/alpha/t-linux: Move
to ../libgcc/config/alpha.
* config/alpha/t-vms (shlib_version, SHLIB_EXT, SHLIB_OBJS,
SHLIB_NAME, SHLIB_MULTILIB, SHLIB_INSTALL, SHLIB_SYMVEC,
SHLIB_SYMVECX2, SHLIB_LINK): Remove.
* config/arm/libgcc-bpabi.ver: Move to ../libgcc/config/arm.
* config/arm/t-bpabi (SHLIB_MAPFILES): Remove.
* config/arm/t-netbsd (SHLIB_EXT, SHLIB_NAME, SHLIB_SONAME,
SHLIB_OBJS, SHLIB_LINK, SHLIB_INSTALL): Remove.
* config/arm/t-symbian (SHLIB_LC): Remove.
* config/bfin/libgcc-bfin.ver: Move to
../libgcc/config/bfin/libgcc-glibc.ver.
* config/bfin/t-bfin-linux (SHLIB_MAPFILES): Remove.
* config/c6x/libgcc-c6xeabi.ver: Move to
../libgcc/config/c6x/libgcc-eabi.ver.
* config/c6x/t-c6x-elf (SHLIB_MAPFILES): Remove.
* config/cris/libgcc.ver: Move to
../libgcc/config/cris/libgcc-glibc.ver.
* config/cris/t-linux (SHLIB_MAPFILES): Remove.
* config/frv/libgcc-frv.ver: Move to ../libgcc/config/frv.
* config/frv/t-linux (SHLIB_MAPFILES): Remove.
* config/i386/darwin-libgcc.10.4.ver: Move to
../libgcc/config/i386/libgcc-darwin.10.4.ver.
* config/i386/darwin-libgcc.10.5.ver: Move to
../libgcc/config/i386/libgcc-darwin.10.5.ver.
* config/i386/libgcc-glibc.ver: Move to ../libgcc/config/i386.
* config/i386/t-cygming (SHLIB_EXT, SHLIB_IMPLIB, SHLIB_SOVERSION,
SHLIB_SONAME, SHLIB_MAP, SHLIB_OBJS, SHLIB_DIR, SHLIB_SLIBDIR_QUAL)
SHLIB_PTHREAD_CFLAG, SHLIB_PTHREAD_LDFLAG, SHLIB_LINK,
SHLIB_INSTALL, SHLIB_MKMAP, SHLIB_MKMAP_OPTS, SHLIB_MAPFILES):
Remove.
* config/i386/t-cygwin (SHLIB_LC, SHLIB_EH_EXTENSION,
SHLIB_IMPLIB, SHLIB_SONAME, SHLIB_MKMAP_OPTS): Remove.
* config/i386/t-dlldir, config/i386/t-dlldir-x: Move to
../libgcc/config/i386.
* config/i386/t-dw2-eh, config/i386/t-sjlj-eh: Move to
../libgcc/config/i386.
* config/i386/t-linux: Move to ../libgcc/config/i386.
* config/i386/t-mingw-pthread: Move to ../libgcc/config/i386.
* config/i386/t-mingw-w32 (SHLIB_LC): Remove.
* config/i386/t-mingw-w64: Likewise.
* config/i386/t-mingw32: Remove.
* config/ia64/libgcc-glibc.ver, config/ia64/libgcc-ia64.ver: Move
to ../libgcc/config/ia64.
* config/ia64/t-glibc: Remove.
* config/ia64/t-hpux (SHLIB_EXT, SHLIB_LINK, SHLIB_INSTALL): Remove.
* config/ia64/t-ia64 (SHLIB_MAPFILES): Remove.
* config/ia64/t-vms (shlib_version, SHLIB_EXT, SHLIB_OBJS,
SHLIB_NAME, SHLIB_MULTILIB, SHLIB_INSTALL, SHLIB_LINK): Remove.
* config/ia64/vms_symvec_libgcc_s.opt: Remove.
* config/m32r/libgcc-glibc.ver: Move to ../libgcc/config/m32r.
* config/m32r/t-linux (SHLIB_MAPFILES): Remove.
* config/m68k/t-slibgcc-elf-ver: Move to ../libgcc/config/m68k.
* config/mips/t-libgcc-mips16 (SHLIB_MAPFILES): Remove.
* config/pa/t-hpux-shlib: Move to ../libgcc/config/pa/t-slibgcc-hpux.
* config/pa/t-slibgcc-dwarf-ver, config/pa/t-slibgcc-sjsj-ver:
Move to ../libgcc/config/pa.
* config/rs6000/darwin-libgcc.10.4.ver: Move to
../libgcc/config/rs6000/libgcc-darwin.10.4.ver.
* config/rs6000/darwin-libgcc.10.5.ver: Move to
../libgcc/config/rs6000/libgcc-darwin.10.5.ver.
* config/rs6000/t-aix43 (SHLIB_EXT, SHLIB_LINK, SHLIB_INSTALL,
SHLIB_LIBS, SHLIB_MKMAP, SHLIB_NM_FLAGS, AR_FLAGS_FOR_TARGET): Remove.
* config/rs6000/t-aix52: Likewise.
* config/sh/libgcc-excl.ver, config/sh/libgcc-glibc.ver: Move to
../libgcc/config/sh.
* config/sparc/libgcc-sparc-glibc.ver: Move to
../libgcc/config/sparc/libgcc-glibc.ver.
* config/sparc/t-linux: Move to ../libgcc/config/sparc.
* config/xtensa/t-linux (SHLIB_MAPFILES): Remove.
* config/xtensa/li

[Bug c++/50956] -Wcast-qual does not work

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  2011-11-02 
11:26:37 UTC ---
Well, "broken" seems in any case an exaggeration to me. In this case triggers
as expected, for example:

  char* p = (char*)"txt";

because it looks like a pure const_cast, from the C++ point of view. If it
doesn't and we proceed checking whether it's a static_cast, reinterpret_cast,
etc, we have this kind of comment (before build_static_cast_1):

/* Perform a static_cast from EXPR to TYPE.  When C_CAST_P is true,
   this static_cast is being attempted as one of the possible casts
   allowed by a C-style cast.  (In that case, accessibility of base
   classes is not considered, and it is OK to cast away
   constness.) ...

thus, the behavior seems *definitely* intended. Maybe Jason can help finishing
the triage of this.

[Bug fortran/50959] [OOP] Redundant setting of the vptr

[janus at gcc dot gnu.org]

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

--- Comment #1 from janus at gcc dot gnu.org 2011-11-02 11:28:51 UTC ---
(In reply to comment #0)
> It is pointless to store the vptr if one does not use it.

The problem is: How do we know if it will be used later on or not?


> Example: The invalid ("x" is not allocated) code
>   use m
>   class(t), allocatable :: x
>   j = x%i
> produces the dump:
>   x._data = 0B;
>   (struct __vtype_m_T *) x._vptr = &__vtab_m_T;
>   j = x._data->i;
> 
> There is no point for the "x._vptr = ". The vptr for pointers/allocatable
> should only be set for ALLOCATE (explicit or polymorphic intrinsic) or pointer
> assignment - but not as part of the initialization.

well, there is a reason for setting the vptr as part of the initialization: It
seems to be valid to call intrinsics like e.g. STORAGE_SIZE or EXTENDS_TYPE_OF
also on unallocated polymorphics (cf. PR47024, PR47180, PR47189, PR47194). I
think the standard says somewhere that the dynamic type of
unallocated/unassociated polymorphic variables equals the declared type (which
is why we set the vptr at initialization).



> For a more real-world example, see below. There one has:
> 
>   (struct __vtype_m_T *) x._vptr = &__vtab_m_T;
>   /* malloc block */
>   (struct __vtype_m_T *) x._vptr = &__vtab_m_T;
> where the last line is part of the ALLOCATE.

I don't see a good way of dealing with this, except for hoping that the
middle-end will optimize away such redundant assignments.

[Bug middle-end/50950] warning missed when OR'ing to an uninitialized variable

[sezeroz at gmail dot com]

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

--- Comment #3 from Ozkan Sezer  2011-11-02 11:29:20 
UTC ---
(In reply to comment #2)
> A dup actually (fixed on trunk):
> 

Thank you.  Can we expect a backport of the fix to 4.5 and 4.6?

> t.c: In function 'f0':
> t.c:14:5: warning: 'x' is used uninitialized in this function 
> [-Wuninitialized]
> t.c: In function 'f1':
> t.c:22:11: warning: 'x.i32.i' is used uninitialized in this function
> [-Wuninitialized]
> t.c: In function 'ff1':
> t.c:30:5: warning: 'x' is used uninitialized in this function 
> [-Wuninitialized]
> t.c: In function 'ff2':
> t.c:40:11: warning: 'y.i32.i' is used uninitialized in this function
> [-Wuninitialized]
> 
> even better than for 4.4.

Hmm, the warning is still selectively emitted only for the first uninitialized
variable, though.

[Bug c++/50961] New: Fails to decay template function properly(?)

[rguenth at gcc dot gnu.org]

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

 Bug #: 50961
   Summary: Fails to decay template function properly(?)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


template < class T > void foo () { }
int bad () {
return !foo < void >;
}

is rejected with

t.C: In function 'int bad()':
t.C:3:13: error: cannot resolve overloaded function 'foo' based on conversion
to type 'bool'
t.C:3:13: error: in argument to unary !

when it should be silently accepted.

[Bug target/48308] [4.6/4.7 Regression] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}

[madhu_k515 at yahoo dot co.in]

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

Madhu  changed:

   What|Removed |Added

 CC||madhu_k515 at yahoo dot
   ||co.in

--- Comment #12 from Madhu  2011-11-02 11:37:07 
UTC ---
Please tell me this bug is fixed in gcc 4.6.2 release? If this is fixed in
gcc4.6.2 release can I use the fix patch into gcc 4.6-linaro?

Thanks & Regards,
Madhu

[Bug target/48308] [4.6/4.7 Regression] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}

[ramana at gcc dot gnu.org]

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

--- Comment #13 from Ramana Radhakrishnan  
2011-11-02 11:40:44 UTC ---
(In reply to comment #12)
> Please tell me this bug is fixed in gcc 4.6.2 release? If this is fixed in
> gcc4.6.2 release can I use the fix patch into gcc 4.6-linaro?
> 
> Thanks & Regards,
> Madhu

This has not been fixed yet. That's evident from the status of the bug. 


Ramana

[Bug c++/50961] Fails to decay template function properly(?)

[giecrilj at stegny dot 2a.pl]

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

Christopher Yeleighton  changed:

   What|Removed |Added

 CC||giecrilj at stegny dot
   ||2a.pl

--- Comment #1 from Christopher Yeleighton  
2011-11-02 11:42:05 UTC ---
Originally at https://bugzilla.novell.com/show_bug.cgi?id=718633 >

[Bug fortran/50960] [OOP] vtables not marked as constant

[janus at gcc dot gnu.org]

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

--- Comment #1 from janus at gcc dot gnu.org 2011-11-02 11:57:44 UTC ---
(In reply to comment #0)
> < richi> and it seems the vtables are not initialized in a way the
>  optimizers could use them
> < richi> they are not constant

Right. I had thought of making them PARAMETERS earlier (to use Fortran
terminology). But in the early implementation this was not possible, since the
PPC members of the vtabs were not initialized statically. Now they are, so this
should work (in principle). I'll try if the following patch survives
regtesting:

Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c (revision 180713)
+++ gcc/fortran/class.c (working copy)
@@ -424,7 +424,7 @@ gfc_find_derived_vtab (gfc_symbol *derived)
{
  gfc_get_symbol (name, ns, &vtab);
  vtab->ts.type = BT_DERIVED;
- if (gfc_add_flavor (&vtab->attr, FL_VARIABLE, NULL,
+ if (gfc_add_flavor (&vtab->attr, FL_PARAMETER, NULL,
  &gfc_current_locus) == FAILURE)
goto cleanup;
  vtab->attr.target = 1;

[Bug target/50962] New: Additional opportunity for AGU stall avoidance optimization for Atom processor

[izamyatin at gmail dot com]

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

 Bug #: 50962
   Summary: Additional opportunity for AGU stall avoidance
optimization for Atom processor
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com


We have now following code for attached testcase:

foo:
.LFB0:
.cfi_startproc
movl4(%esp), %eax
testl   %eax, %eax
je  .L4
xorl%ecx, %ecx
jmp .L3
.p2align 4,,7
.p2align 3
.L5:
movl%eax, %ecx
movl%edx, %eax
.L3:
movl(%eax), %edx <--- AGU stall here on Atom since eax produced on
previous cycle. We should use lea in previous instruction.
movl%ecx, (%eax)
testl   %edx, %edx
jne .L5
ret
.L4:
xorl%eax, %eax
ret
.cfi_endproc

 So we can use lea before movl (%eax), %edx which is better for Atom.

[Bug target/50962] Additional opportunity for AGU stall avoidance optimization for Atom processor

[izamyatin at gmail dot com]

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

--- Comment #1 from Igor Zamyatin  2011-11-02 
12:00:55 UTC ---
Created attachment 25688
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25688
testcase

[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch

[gdr at gcc dot gnu.org]

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

Gabriel Dos Reis  changed:

   What|Removed |Added

 CC||gdr at gcc dot gnu.org

--- Comment #13 from Gabriel Dos Reis  2011-11-02 
12:22:26 UTC ---
(In reply to comment #2)
> Thus, to understand and clarify why this has not been noticed so far, you are
> on a target which doesn't support in the underlying C library these complex
> functions, right? Because normally (eg, on Linux) these days we just forward 
> to
> __builtin_cacosh*, the code you are touching is just a "surrogate", a
> "fallback", which doesn't get right all the special cases, NaNs, infinity.
> 
> Anyway, a similar tweak would touch also the C++11 version in std::
> 
> Gaby, can you have a look to this, double check the patch? For your 
> convenience
> the surrounding code is:
> 
>   template
> std::complex<_Tp>
> __complex_acosh(const std::complex<_Tp>& __z)
> {
>   std::complex<_Tp> __t((__z.real() - __z.imag())
> * (__z.real() + __z.imag()) - _Tp(1.0),
> _Tp(2.0) * __z.real() * __z.imag());
>   __t = std::sqrt(__t);
> 
>   return std::log(__t + __z);
> }

As I observed elsewhere, the test should be on the sign, no comparison
against 0.0, so that signed zero is handled correctly.

[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch

[gdr at gcc dot gnu.org]

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

--- Comment #14 from Gabriel Dos Reis  2011-11-02 
12:27:20 UTC ---
(In reply to comment #9)
> Created attachment 25654 [details]
> BC2

Since we are talking about branch cut and prespectiving
since zeros, I think we should avoid the 
the arithmetic z -/+ one, whee one is of a complex.
Rather the computation should be be directly on
the components.  This is to prevent signed zeros
to have their mutated.

[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch

[paolo.carlini at oracle dot com]

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

--- Comment #15 from Paolo Carlini  2011-11-02 
12:31:09 UTC ---
Ok, thanks for your feedback Gaby. Indeed, I also wondered if we shouldn't work
with the components.

Richard, can you send a version of Kahan's algorithm rewritten in terms of real
and imag, I think we can all agree on that and resolve the PR for good.

[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch

[paolo.carlini at oracle dot com]

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

--- Comment #16 from Paolo Carlini  2011-11-02 
12:44:06 UTC ---
Well, I guess this would be most of it:

  template
std::complex<_Tp>
__complex_acosh(const std::complex<_Tp>& __z)
{
  return _Tp(2.0) * std::log(std::sqrt(_Tp(0.5) * (__z + _Tp(1.0)))
 + std::sqrt(_Tp(0.5) * (__z - _Tp(1.0;
}

[Bug c++/50956] -Wcast-qual does not work

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-11-02
 Ever Confirmed|0   |1

--- Comment #2 from Jason Merrill  2011-11-02 
12:45:18 UTC ---
(In reply to comment #1)
> /* Perform a static_cast from EXPR to TYPE.  When C_CAST_P is true,
>this static_cast is being attempted as one of the possible casts
>allowed by a C-style cast.  (In that case, accessibility of base
>classes is not considered, and it is OK to cast away
>constness.) ...
> 
> thus, the behavior seems *definitely* intended.

It's intended that we accept the code ("OK" meaning "well-formed"), but
-Wcast-qual should still warn.

[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch

[gdr at gcc dot gnu.org]

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

--- Comment #17 from Gabriel Dos Reis  2011-11-02 
12:48:23 UTC ---
(In reply to comment #16)
> Well, I guess this would be most of it:
> 
>   template
> std::complex<_Tp>
> __complex_acosh(const std::complex<_Tp>& __z)
> {
>   return _Tp(2.0) * std::log(std::sqrt(_Tp(0.5) * (__z + _Tp(1.0)))
>  + std::sqrt(_Tp(0.5) * (__z - _Tp(1.0;
> }

looks good -- hoping for log implementation to do the right thing.

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-11-02 
12:48:23 UTC ---
The candidate

candidate 15
  depends on 3
  var_before ivtmp.161
  var_after ivtmp.161
  incremented before exit test
  type unsigned int
  base (unsigned int) pDst_39(D) - (unsigned int) &p1
  step (unsigned int) (pretmp.28_118 + 1)

is added via

#3  0x00c99c0b in add_derived_ivs_candidates (data=0x7fffd990)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-loop-ivopts.c:2531
2531  add_iv_value_candidates (data, use->iv, use);

for

$3 = {id = 7, type = USE_NONLINEAR_EXPR, iv = 0x1b3c840, 
  stmt = 0x2d2ed268, op_p = 0x0, related_cands = 0x1b33a10, 
  n_map_members = 0, cost_map = 0x0, selected = 0x0}
(gdb) call debug_gimple_stmt (0x2d2ed268)
D.6700_302 = D.6698_157 - p1.148_301;

which in turn is created by IVOPTs processing the innermost loop to:

:
  vect_pp1.50_189 = &p1;
  vect_pp1.57_199 = &MEM[(void *)&p1 + 1B];
  vect_pp1.66_217 = &MEM[(void *)&p1 + 2B];
  vect_cst_.72_231 = { 2, 2 };
  vect_cst_.74_236 = { 2, 2 };
  D.6600_244 = (sizetype) y_89;
  batmp.78_245 = pDst_88 + D.6600_244;
  vect_p.80_246 = batmp.78_245 + 1;
  ivtmp.127_156 = (unsigned int) &MEM[(void *)&p1 + 8B];

:
  # ivtmp.124_174 = PHI 
  # ivtmp.127_265 = PHI 
  D.6698_157 = (unsigned int) batmp.78_245;
  p1.148_301 = (unsigned int) &p1;
  D.6700_302 = D.6698_157 - p1.148_301;
  D.6701_303 = D.6700_302 + ivtmp.127_265;
  D.6702_304 = D.6701_303 + 4294967289;
  D.6703_305 = (vector(8) unsigned char *) D.6702_304;
  vect_p.77_247 = D.6703_305;
  D.6693_281 = (void *) ivtmp.127_265;
  vect_var_.51_192 = MEM[base: D.6693_281, offset: 4294967288B];
...
  MEM[(unsigned char *)vect_p.77_247] = vect_var_.75_243;
  ivtmp.124_280 = ivtmp.124_174 + 1;
  ivtmp.127_170 = ivtmp.127_265 + 8;
  if (ivtmp.124_280 < bnd.44_152)
goto ;
  else
goto ;

:
  goto ;

thus introducing this bogus pointer difference.


Reduced testcase:

void
foo1(unsigned char* pSrcLeft,
 unsigned char* pSrcAbove,
 unsigned char* pSrcAboveLeft,
 unsigned char* pDst,
 int dstStep,
 int leftStep, signed int y)
{
  signed int x, s;
  unsigned char  p1[5], p2[5],  p3;

  p1[0] = *pSrcAboveLeft;
  p2[0] = p1[0];
  p2[1] = pSrcLeft[0];
  pSrcLeft += leftStep;
  p2[2] = pSrcLeft[0];
  pSrcLeft += leftStep;
  p2[3] = pSrcLeft[0];
  pSrcLeft += leftStep;
  p2[4] = pSrcLeft[0];

  p1[1] = pSrcAbove[0];
  p1[2] = pSrcAbove[1];
  p1[3] = pSrcAbove[2];
  p1[4] = pSrcAbove[3];

  p3 = (unsigned char)(((signed int)p1[1] + (signed int)p2[1]
+ (signed int)p1[0] +(signed int)p1[0] + 2 ) >> 2 );

  for( x=y+1; x<4; x++ ) {
  s = ( p1[x-y-1] + p1[x-y] + p1[x-y] + p1[x-y+1] + 2 ) >> 2;
  pDst[x] = (unsigned char)s;
  }

  pDst[y] = p3;
}

[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch

[gdr at gcc dot gnu.org]

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

--- Comment #18 from Gabriel Dos Reis  2011-11-02 
12:48:47 UTC ---
(In reply to comment #16)
> Well, I guess this would be most of it:
> 
>   template
> std::complex<_Tp>
> __complex_acosh(const std::complex<_Tp>& __z)
> {
>   return _Tp(2.0) * std::log(std::sqrt(_Tp(0.5) * (__z + _Tp(1.0)))
>  + std::sqrt(_Tp(0.5) * (__z - _Tp(1.0;
> }

looks good -- hoping for log implementation to do the right thing.

[Bug c++/50956] -Wcast-qual does not work

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #3 from Paolo Carlini  2011-11-02 
13:00:52 UTC ---
Ok. Note that the *diagnostic* use of that c_cast_p flag is:

  if (!c_cast_p
  && check_for_casting_away_constness (intype, type, STATIC_CAST_EXPR,
   complain))
return error_mark_node;

Then, looks like we should just remove it from such conditionals (3 in static
and 1 in interpret)? Seems simple.

[Bug target/50962] Additional opportunity for AGU stall avoidance optimization for Atom processor

[enkovich.gnu at gmail dot com]

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

--- Comment #2 from Ilya Enkovich  2011-11-02 
13:05:46 UTC ---
Created attachment 25689
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25689
Proposed patch

[Bug target/50962] Additional opportunity for AGU stall avoidance optimization for Atom processor

[enkovich.gnu at gmail dot com]

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

Ilya Enkovich  changed:

   What|Removed |Added

 CC||enkovich.gnu at gmail dot
   ||com

--- Comment #3 from Ilya Enkovich  2011-11-02 
13:06:07 UTC ---
Current optimization use only splits to transform arithmetic into lea and vice
versa. It does not work for move because corresponding lea template will be
equal. We can check if lea is required during instruction emit. 

I have a patch to fix it. Bootstrap and make check passed. I'm currently
checking performance changes.

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-11-02 
13:09:40 UTC ---
It looks like IVOPTs fails to consider a candidate for the use inquestion
and thus, after choosing the final IV set ends up rewriting that use into
this stupid form (instead of using candidate 0).  The use is

use 3
  generic
  in statement vect_p.60_223 = PHI 

  at position
  type vector(8) unsigned char *
  base batmp.61_221 + 1
  step 8
  base object (void *) batmp.61_221
  is a biv
  related candidates

but costs say:

Use 3:
  cand  costcompl.  depends on
  0 8   1inv_expr:0
  1 4   1inv_expr:1
  2 4   1inv_expr:0
  3 4   1inv_expr:1
  4 4   1inv_expr:2

Initial set of candidates:
  cost: 24 (complexity 4)
  cand_cost: 10
  cand_use_cost: 10 (complexity 4)
  candidates: 0, 4
   use:0 --> iv_cand:4, cost=(2,1)
   use:1 --> iv_cand:4, cost=(2,1)
   use:2 --> iv_cand:4, cost=(2,1)
   use:3 --> iv_cand:4, cost=(4,1)
   use:4 --> iv_cand:0, cost=(0,0)
  invariants 7

Selected IV set:
candidate 0 (important)
  var_before ivtmp.107_150
  var_after ivtmp.107_256
  incremented before exit test
  type unsigned int
  base 0
  step 1
candidate 4 (important)
  var_before ivtmp.110_241
  var_after ivtmp.110_146
  incremented before exit test
  type unsigned int
  base (unsigned int) (&p1 + 8)
  step 8
  base object (void *) &p1

so expressing use 3 with candidate 4 is cheaper than with candidate 0...

Now, for address-uses we have

  if (address_p)
{
  /* Do not try to express address of an object with computation based
 on address of a different object.  This may cause problems in rtl
 level alias analysis (that does not expect this to be happening,
 as this is illegal in C), and would be unlikely to be useful
 anyway.  */
  if (use->iv->base_object
  && cand->iv->base_object
  && !operand_equal_p (use->iv->base_object, cand->iv->base_object, 0))
return infinite_cost;

in cost calculation, but in this case it's a nonlinear use, and we have

(gdb) call debug_generic_expr (use->iv->base_object)
(void *) batmp.61_221
(gdb) call debug_generic_expr (cand->iv->base_object)
(void *) &p1

[Bug c++/50956] -Wcast-qual does not work

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2011-11-02 
13:15:35 UTC ---
Well, we shouldn't early return error_mark_node, however.

Also, in the specific case at issue here we are still failing to warn, because
we return from build_static_cast_1 pretty early, here:

  if (result)
{
  result = convert_from_reference (result);

  /* [expr.static.cast]

 If T is a reference type, the result is an lvalue; otherwise,
 the result is an rvalue.  */
  if (TREE_CODE (type) != REFERENCE_TYPE)
result = rvalue (result);
  return result;
}

looks like one more call to check_for_casting_away_constness is missing.

[Bug target/48949] [4.6/4.7 Regression] gcc-4.6.0 regression with complex.h on i386-pc-solaris2.10

[mariah.lenox at gmail dot com]

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

--- Comment #8 from Mariah Lenox  2011-11-02 
13:18:52 UTC ---
> Please answer comment #3.

Answers provided on bug report 50944.

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||rakdver at gcc dot gnu.org

--- Comment #5 from Richard Guenther  2011-11-02 
13:33:21 UTC ---
It's not easy to detect this situation from IVOPTs (well, conservatively
at least).  Given that this is another case of alias analysis being
confused (TMR[&p1 + ivtmp] does not refer to object p1), dumbing down
that analysis would seem like a "solution" to this issue ... :/

That's of course not a sustainable approach ...

pointer analysis on MEM[symbol: p1, index: ivtmp.161_200, offset: 0B]
would figure that &p1 + ivtmp.161_200 also points to NONLOCAL, not only
to p1, but we do not have a SSA name to store points-to info in this
case (one more argument against TARGET_MEM_REF and an argument for
more complex address-computation trees instead).  Thus we'd for now
have to assume that a TARGET_MEM_REF points to anything ... that's
pretty bad for RTL optimization, for exactly which we improved alias
analysis for TARGET_MEM_REF in the first place.

Hum.

The issue only pops up because of the ->consider_all_candidates path.
Otherwise we do not apply this awkward choice.

Thus you can avoid the issue by --param iv-consider-all-candidates-bound=1.

Maybe we shouldn't really consider _all_ candidates, but only all bivs?

[Bug c++/50958] [C++0x] raw literal operator provides incorrect string for integer literal '0'

[3dw4rd at verizon dot net]

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

--- Comment #1 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-11-02 
14:00:11 UTC ---
In http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02804.html
I have a patch to address a resolution issue.

For some reason, this bug doesn't show up in that version.

I'll try to understand this bug but ultimately (and soon) I'd like to put a
version of that patch in and call it done.

[Bug c++/50956] -Wcast-qual does not work

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|paolo.carlini at oracle dot |
   |com |
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.7.0

--- Comment #5 from Paolo Carlini  2011-11-02 
14:23:52 UTC ---
Ah! If we can warn for (char*)"txt" it means we can just do the check in
build_const_cast_1

[Bug fortran/50959] [OOP] Redundant setting of the vptr

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #2 from Tobias Burnus  2011-11-02 
14:24:13 UTC ---
(In reply to comment #1)
> well, there is a reason for setting the vptr as part of the initialization: It
> seems to be valid to call intrinsics like e.g. STORAGE_SIZE or EXTENDS_TYPE_OF
> also on unallocated polymorphics

I completely forgot about those! Thus: Won't fix, not a bug.

[Bug fortran/50960] [OOP] vtables not marked as constant

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-11-02
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-11-02 
14:32:13 UTC ---
Does not help.  The vtable objects are still not in .rodata:

.data
.align 32
.type   __m_MOD___vtab_m_T2, @object
.size   __m_MOD___vtab_m_T2, 40
__m_MOD___vtab_m_T2:
.long   69979408
.long   0
.quad   __m_MOD___vtab_m_T
.quad   __m_MOD___def_init_m_T2
.quad   __m_MOD___copy_m_T2
.quad   __m_MOD_ext

nor are reads from them optimized (-fdump-tree-fre-details, t.f90.027t.fre1):


:
  D.1793_12 = &__vtab_m_T;
  D.1794_13 = D.1793_12->bar;
  D.1794_13 ();

should have been simplified to the constant __vtab_m_T.bar is initialized
from.

[Bug fortran/50960] [OOP] vtables not marked as constant

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-11-02 
14:37:35 UTC ---
The vtable object looks like (with the patch):

 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x75b37dc8
fields 
SI file t.f90 line 18 col 0
size 
unit size 
align 32 offset_align 128
offset 
bit offset  context
 chain > context 
pointer_to_this  chain >
addressable used public static BLK file t.f90 line 18 col 0 size
 unit size 
align 256 context  initial  chain >

it is not TREE_READONLY.  The constructor looks ok:

{._hash=6736034, ._size=0, ._extends=0B, ._def_init=&__def_init_m_T,
._copy=__copy_m_T, .bar=base}

Instead of a VAR_DECL it could maybe also be a CONST_DECL(?).  But first
try setting TREE_READONLY on it.

[Bug fortran/50960] [OOP] vtables not marked as constant

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-11-02 
14:40:09 UTC ---
Doing that in gdb yields to

:
  D.1793_12 = &__vtab_m_T;
  D.1794_13 = base;
  base ();

in the fre1 dump.

[Bug lto/44965] lto option code breaks file format with each added option

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-11-02
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #5 from Richard Guenther  2011-11-02 
14:54:23 UTC ---
I have a patch.

[Bug target/45640] gcc.c-torture/execute/20050316-2.c ICEs with -mno-mmx -m3dnow -flto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Guenther  2011-11-02 
14:57:02 UTC ---
This has been fixed.  Probably with more careful handling of the situation
during expand.

[Bug fortran/50960] [OOP] vtables not marked as constant

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2011-11-02 
14:57:34 UTC ---
(In reply to comment #1)
> - if (gfc_add_flavor (&vtab->attr, FL_VARIABLE, NULL,
> + if (gfc_add_flavor (&vtab->attr, FL_PARAMETER, NULL,

(In reply to comment #3)
> it is not TREE_READONLY.

I wonder whether there is a general missed-optimization issue for FL_PARAMETER
(for the case they are stored as actual data and not just as drop-in number).
One might need some special handling, but I also do not see "para"
("__m_MOD_para:") marked as .rodata for

module m
  integer, parameter :: PARA(*) = [1,2,3,4,5,6,7,8,9,10]
end module m

use m
print *, para
end

[Bug driver/47785] GCC with -flto does not pass options to the assembler

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-11-02 
15:01:09 UTC ---
For this to be fixed we'd need something similar to COLLECT_GCC_OPTIONS,
COLLECT_AS_OPTIONS for example, and lto-wrapper passing those on via
-Wa to the link-time driver.

[Bug fortran/50960] [OOP] vtables not marked as constant

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org 2011-11-02 15:08:28 UTC ---
(In reply to comment #1)
> I'll try if the following patch survives regtesting

It fails at least on:

FAIL: gfortran.dg/dynamic_dispatch_4.f03  -O0  (test for excess errors)
FAIL: gfortran.dg/dynamic_dispatch_5.f03  -O0  (test for excess errors)



> gfortran-4.7 dynamic_dispatch_4.f03 
dynamic_dispatch_4.f03:79.6:

  use s_bar_mod
  1
Error: Interface mismatch for procedure-pointer component 'getit' in structure
constructor at (1): Type/rank mismatch in argument 'a'



> gfortran-4.7 dynamic_dispatch_5.f03 
dynamic_dispatch_5.f03:176.8:

use s_mat_mod
1
Error: Interface mismatch for procedure-pointer component 's_scals' in
structure constructor at (1): Type/rank mismatch in argument 'a'

[Bug lto/48217] lto mishandles quotes in command line defines

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-11-02 
15:13:51 UTC ---
collect2 has extract_string () which handles unquoting from
COLLECT_GCC_OPTIONS.

[Bug fortran/50960] [OOP] vtables not marked as constant

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2011-11-02 
15:16:08 UTC ---
(In reply to comment #5)
> (In reply to comment #1)
> > - if (gfc_add_flavor (&vtab->attr, FL_VARIABLE, NULL,
> > + if (gfc_add_flavor (&vtab->attr, FL_PARAMETER, NULL,
> 
> (In reply to comment #3)
> > it is not TREE_READONLY.
> 
> I wonder whether there is a general missed-optimization issue for FL_PARAMETER
> (for the case they are stored as actual data and not just as drop-in number).
> One might need some special handling, but I also do not see "para"
> ("__m_MOD_para:") marked as .rodata for
> 
> module m
>   integer, parameter :: PARA(*) = [1,2,3,4,5,6,7,8,9,10]
> end module m
> 
> use m
> print *, para
> end

Definitely a missed optimization.  Optimizers will not be able to
propagate constants from that initializer.

[Bug middle-end/50963] New: TLS incompatible with -mcmodel=large & PIC

[drepper.fsp at gmail dot com]

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

 Bug #: 50963
   Summary: TLS incompatible with -mcmodel=large & PIC
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: drepper@gmail.com


Due to some build problems with the default models a program was compiled with
-mcmodel=large.  But that seems to be incompatible with TLS in PIC.  This tiny
code sequence blows up gcc as recently as 4.6.2 (from Fedora rawhide):

__thread int a;

int f(int b)
{
  return a;
}


The ICE message when compiled with 'g++ -c -mcmodel=large t.c -fpic' is:

t.c: In function ‘int f(int)’:
t.c:6:1: error: unrecognizable insn:
(call_insn/u 6 5 7 3 (parallel [
(set (reg:DI 0 ax)
(call:DI (mem:QI (symbol_ref:DI ("__tls_get_addr")) [0 S1 A8])
(const_int 0 [0])))
(unspec:DI [
(symbol_ref:DI ("a") [flags 0x10] )
] UNSPEC_TLS_GD)
]) t.c:5 -1
 (expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil))
(nil))
t.c:6:1: internal compiler error: in extract_insn, at recog.c:2109

[Bug bootstrap/50882] [4.6 Regression] internal compiler error: in extract_insn, at recog.c:2109 on powerpc-ibm-aix5.3.0.0

[greed at pobox dot com]

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

--- Comment #7 from Graham Reed  2011-11-02 15:28:55 
UTC ---
(In reply to comment #6)

Reverting config/rs6000/rs6000.md to the version in 4.6.1 clears the ICE in
that testcase.

[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

[patrick.marlier at gmail dot com]

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

Patrick Marlier  changed:

   What|Removed |Added

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

--- Comment #11 from Patrick Marlier  
2011-11-02 15:40:48 UTC ---
The latest version (probably thanks to Richard's code revision 180635) seems to
fix the ICE.

But one question with attachment 23459, at -O0 we get a unsafe function call
error but not at -O1. So my question : is it safe to have 2 different results
depending on the optimization level?

Also, I don't know if those testcases should be included in the tm testsuite.

Patrick Marlier.

g++ -O0 -fgnu-tm -c b1.c
b1.c:15:4: error: unsafe function call ‘GradientInfo::~GradientInfo()’ within
‘transaction_safe’ function

g++ -O1 -fgnu-tm -c b1.c

[Bug lto/48217] lto mishandles quotes in command line defines

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Guenther  2011-11-02 
15:52:14 UTC ---
I have a patch.

[Bug lto/50964] New: [trans-mem] no support for LTO

[patrick.marlier at gmail dot com]

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

 Bug #: 50964
   Summary: [trans-mem] no support for LTO
Classification: Unclassified
   Product: gcc
   Version: trans-mem
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: patrick.marl...@gmail.com
CC: al...@gcc.gnu.org, r...@gcc.gnu.org,
torv...@gcc.gnu.org


Created attachment 25690
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25690
generate ICE

A simple test (attached) shows that LTO does not support TM
(GIMPLE_TRANSACTION).

gcc -O0 -fgnu-tm -flto test.c -o test.o
test.c: In function ‘main’:
test.c:10:1: internal compiler error: in output_gimple_stmt, at
gimple-streamer-out.c:155
Please submit a full bug report,
with preprocessed source if appropriate.

Patrick Marlier.

[Bug tree-optimization/50672] [4.7 Regression] ice: verify_ssa failed: no immediate_use list

[vries at gcc dot gnu.org]

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

--- Comment #13 from vries at gcc dot gnu.org 2011-11-02 16:30:03 UTC ---
Author: vries
Date: Wed Nov  2 16:29:50 2011
New Revision: 180779

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180779
Log:
2011-11-02  Tom de Vries  

PR tree-optimization/50672
* g++.dg/pr50672.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr50672.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/50960] [OOP] vtables not marked as constant

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org 2011-11-02 16:44:56 UTC ---
(In reply to comment #6)
> It fails at least on:
> 
> FAIL: gfortran.dg/dynamic_dispatch_4.f03  -O0  (test for excess errors)

Here is a reduced test case:


module foo_mod
  type foo
  contains
procedure, pass(a) :: getit
  end type
  private :: getit
contains
  integer function getit(a)
class(foo) :: a
  end function
end module

module bar_mod 
  use foo_mod
  type :: bar
  end type
contains
  integer function getit(b)
class(bar) :: b
  end function
end module

  use bar_mod
end



  use bar_mod
  1
Error: Interface mismatch for procedure-pointer component 'getit' in structure
constructor at (1): Type/rank mismatch in argument 'a'


Apparently the error is due to two routines having the same names. When
resolving the vtab of foo in the main program, the wrong one is used (since the
other is not accessible). However, I don't quite see yet how that is connected
to the FL_PARAMETER change.

[Bug c++/50965] New: C++11 Non static member initializer are not run when class is initialized with {}

[ogoffart at kde dot org]

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

 Bug #: 50965
   Summary: C++11 Non static member initializer are not run when
class is initialized with {}
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ogoff...@kde.org


Using g++ (GCC) 4.7.0 20111031 (experimental)


struct A { int i = 42; };
int main() {
   A a{};
   std::cout << a.i << std::endl; // shows 0
   std::cout << A{}.i << std::endl; // shows 0
}

[Bug c++/50965] C++11 Non static member initializer are not run when class is initialized with {}

[ogoffart at kde dot org]

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

--- Comment #1 from Olivier Goffart  2011-11-02 
17:33:26 UTC ---
Created attachment 25691
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25691
Suggested patch

[Bug c++/50965] C++11 Non static member initializer are not run when class is initialized with {}

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2011-11-02 
17:42:05 UTC ---
Is there a reason why you are removing:
-  A a2 = { 24 };
-  if (a2.i != 24) return 2;

>From the testcase?

[Bug c++/50965] C++11 Non static member initializer are not run when class is initialized with {}

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  2011-11-02 
17:42:23 UTC ---
Also patches goto gcc-patches@.

[Bug tree-optimization/50763] [4.7 Regression] ICE: verify_gimple failed: missing PHI def with -ftree-tail-merge

[vries at gcc dot gnu.org]

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

--- Comment #20 from vries at gcc dot gnu.org 2011-11-02 18:01:25 UTC ---
Author: vries
Date: Wed Nov  2 18:01:18 2011
New Revision: 180785

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180785
Log:
2011-11-02  Tom de Vries  

PR tree-optimization/50763
* g++.dg/pr50763-3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr50763-3.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/50956] -Wcast-qual does not work

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org  
2011-11-02 18:04:53 UTC ---
Author: paolo
Date: Wed Nov  2 18:04:48 2011
New Revision: 180786

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180786
Log:
2011-11-02  Paolo Carlini  

PR c++/50956
* builtins.c (fold_builtin_memchr): Fix cast.

/cp
2011-11-02  Paolo Carlini  

PR c++/50956
* typeck.c (build_const_cast_1): Fix -Wcast-qual for false
comp_ptr_ttypes_const.

/testsuite
2011-11-02  Paolo Carlini  

PR c++/50956
* g++.dg/warn/Wcast-qual2.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wcast-qual2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/50956] -Wcast-qual does not work

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Paolo Carlini  2011-11-02 
18:06:14 UTC ---
Fixed for 4.7.0.

[Bug debug/48354] internal compiler error: in splice_child_die, at dwarf2out.c:8064

[howarth at nitro dot med.uc.edu]

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

--- Comment #16 from Jack Howarth  2011-11-02 
18:08:37 UTC ---
The original test case still fails on x86_64-apple-darwin11 as well at
r180780...

g++-fsf-4.7 -r -nostdlib -g -flto bug.ii
In file included from bug.ii:8:0,
 from :2:
bug.ii: In function ‘f’:
bug.ii:11:1: internal compiler error: in splice_child_die, at dwarf2out.c:5009
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: g++-fsf-4.7 returned 1 exit status
collect2: error: lto-wrapper returned 1 exit status

[Bug c++/50965] C++11 Non static member initializer are not run when class is initialized with {}

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Paolo Carlini  2011-11-02 
18:12:57 UTC ---
Let's add Jason in CC, maybe he wants to commit (a variant of) the patch at
once. But really, patches should always go to the mailing list.

[Bug target/50906] e500 exception unwinding under "-Os" causes SIGSEGV

[Kyle.D.Moffett at boeing dot com]

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

--- Comment #6 from Kyle Moffett  2011-11-02 
18:24:02 UTC ---
Created attachment 25692
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25692
Archive of RTL dumps of failing testcase built with "-Os"

I spent some time looking through the RTL dump.  It looks like the stack
references first show up in 194r.split2, but I couldn't understand enough of
what I was looking at to match it up with the assembly output or figure out
where the CFI information went wrong.

I've attached a tar.gz of the RTL dumps in case that helps isolate the issue.

Cheers,
Kyle Moffett

[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch

[paolo at gcc dot gnu.org]

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

--- Comment #19 from paolo at gcc dot gnu.org  
2011-11-02 18:43:31 UTC ---
Author: paolo
Date: Wed Nov  2 18:43:26 2011
New Revision: 180787

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180787
Log:
2011-11-02  Richard B. Kreckel  
Paolo Carlini  

PR libstdc++/50880
* include/std/complex (__complex_acosh): Fix in a better way,
use Kahan's formula.
* include/tr1/complex (__complex_acosh): Likewise.

Modified:
trunk/libstdc++-v3/include/std/complex
trunk/libstdc++-v3/include/tr1/complex

[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch

[paolo at gcc dot gnu.org]

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

--- Comment #20 from paolo at gcc dot gnu.org  
2011-11-02 18:43:46 UTC ---
Author: paolo
Date: Wed Nov  2 18:43:42 2011
New Revision: 180788

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180788
Log:
2011-11-02  Richard B. Kreckel  
Paolo Carlini  

PR libstdc++/50880
* include/std/complex (__complex_acosh): Fix in a better way,
use Kahan's formula.
* include/tr1/complex (__complex_acosh): Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog

[Bug middle-end/50966] New: [4.4/4.5/4.6/4.7 Regression] Missing 'is used uninitialized' warning (struct pointer dereference)

[belyshev at depni dot sinp.msu.ru]

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

 Bug #: 50966
   Summary: [4.4/4.5/4.6/4.7 Regression] Missing 'is used
uninitialized' warning (struct pointer dereference)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: minor
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: belys...@depni.sinp.msu.ru
CC: m...@gcc.gnu.org
Blocks: 24639


Manuel, after your commit r139347 gcc doesn't warn about dereference of 'bar'
in this testcase anymore:

struct foo
{
  int x;
};

int main (void)
{
  struct foo *bar;

  __builtin_printf ("%p\n", &bar->x);
  return 0;
}

[Bug fortran/50960] [OOP] vtables not marked as constant

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org 2011-11-02 18:49:35 UTC ---
(In reply to comment #6)
> It fails at least on:
> 
> FAIL: gfortran.dg/dynamic_dispatch_4.f03  -O0  (test for excess errors)
> FAIL: gfortran.dg/dynamic_dispatch_5.f03  -O0  (test for excess errors)


Those can be fixed by:

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 180780)
+++ gcc/fortran/resolve.c(working copy)
@@ -9503,7 +9503,7 @@ resolve_values (gfc_symbol *sym)
 {
   gfc_try t;

-  if (sym->value == NULL)
+  if (sym->value == NULL || sym->attr.use_assoc)
 return;

   if (sym->value->expr_type == EXPR_STRUCTURE)


Use-associated symbols should have been resolved before, so I guess we don't
need to do it again? (At least this produces no further regressions.)


Apart from the two failures above, the patch in comment 1 also fails on:

FAIL: gfortran.dg/class_15.f03  -O  (internal compiler error)
FAIL: gfortran.dg/extends_type_of_1.f03  -O0  (internal compiler error)
FAIL: gfortran.dg/extends_type_of_3.f90  -O  (internal compiler error)

Those are not cured by the patchlet above.

[Bug c++/50967] New: [C++0x] Literal operators are not found by using-declarations

[daniel.kruegler at googlemail dot com]

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

 Bug #: 50967
   Summary: [C++0x] Literal operators are not found by
using-declarations
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: 3dw...@verizon.net


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

//---
namespace n {
  int operator "" _xx(const char*);
}
using n::_xx;
//---

The error message is:

"'n::_xx' has not been declared"

The code should be accepted. 

According to 13.5.8 p2: "A declaration whose declarator-id is a
literal-operator-id shall be a declaration of a namespace-scope function or
function template [..] or a using-declaration (7.3.3)."

A using directives can be used as a workaround, though.

[Bug c++/50967] [C++0x] Literal operators are not found by using-declarations

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||jason at redhat dot com

--- Comment #1 from Daniel Krügler  
2011-11-02 19:01:54 UTC ---
It should be added, that the same problem occurs for literal operator templates
as well

[Bug c/50968] New: ICE on armhf building gcc-snapshot

[konstantinos.margaritis at linaro dot org]

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

 Bug #: 50968
   Summary: ICE on armhf building gcc-snapshot
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: konstantinos.margari...@linaro.org
  Host: arm-linux-gnueabihf
Target: arm-linux-gnueabihf
 Build: arm-linux-gnueabihf


Trying on armhf to build gcc-snapshot-2001-1 (svn 2001) package on
armhf, I got the following ICE:

Reading specs from /root/gcc-snapshot-2001/build/./gcc/specs
COLLECT_GCC=/root/gcc-snapshot-2001/build/./gcc/xgcc
COLLECT_LTO_WRAPPER=/root/gcc-snapshot-2001/build/./gcc/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 2001-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,c++,java,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id
--with-system-zlib --disable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.7-snap/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.7-snap
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.7-snap
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a
--with-float=hard --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror
--enable-checking=yes --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.7.0 2001 (experimental) [trunk revision 180743] (Debian
2001-1)
COLLECT_GCC_OPTIONS='-B' '/root/gcc-snapshot-2001/build/./gcc/' '-B'
'/usr/lib/gcc-snapshot/arm-linux-gnueabihf/bin/' '-B'
'/usr/lib/gcc-snapshot/arm-linux-gnueabihf/lib/' '-isystem'
'/usr/lib/gcc-snapshot/arm-linux-gnueabihf/include' '-isystem'
'/usr/lib/gcc-snapshot/arm-linux-gnueabihf/sys-include' '-g' '-O2' '-O2' '-I'
'.' '-I' '.' '-I' '../../src/gcc' '-I' '../../src/gcc/.' '-I'
'../../src/gcc/../include' '-I' '../../src/gcc/../libdecnumber' '-I'
'../../src/gcc/../libdecnumber/dpd' '-I' '../libdecnumber' '-I'
'../../src/gcc/../libgcc' '-g' '-O2' '-D' 'IN_GCC' '-Wextra' '-Wall'
'-Wwrite-strings' '-Wcast-qual' '-Wstrict-prototypes' '-Wmissing-prototypes'
'-Wold-style-definition' '-isystem' './include' '-fPIC' '-g' '-D'
'HAVE_GTHR_DEFAULT' '-D' 'IN_LIBGCC2' '-fbuilding-libgcc'
'-fno-stack-protector' '-I' '.' '-I' '.' '-I' '../.././gcc' '-I'
'../../../src/libgcc' '-I' '../../../src/libgcc/.' '-I'
'../../../src/libgcc/../gcc' '-I' '../../../src/libgcc/../include' '-D'
'HAVE_CC_TLS' '-MT' 'unwind-dw2.o' '-MD' '-MP' '-MF' 'unwind-dw2.dep'
'-fexceptions' '-fvisibility=hidden' '-D' 'HIDE_EXPORTS' '-v' '-c' '-o'
'unwind-dw2.i' '-march=armv7-a' '-mfloat-abi=hard' '-mfpu=vfpv3-d16' '-mthumb'
'-mtls-dialect=gnu'
 /root/gcc-snapshot-2001/build/./gcc/cc1 -quiet -v -I . -I . -I
../../src/gcc -I ../../src/gcc/. -I ../../src/gcc/../include -I
../../src/gcc/../libdecnumber -I ../../src/gcc/../libdecnumber/dpd -I
../libdecnumber -I ../../src/gcc/../libgcc -I . -I . -I ../.././gcc -I
../../../src/libgcc -I ../../../src/libgcc/. -I ../../../src/libgcc/../gcc -I
../../../src/libgcc/../include -imultilib . -imultiarch arm-linux-gnueabihf
-iprefix
/root/gcc-snapshot-2001/build/gcc/../lib/gcc/arm-linux-gnueabihf/4.7.0/
-isystem /root/gcc-snapshot-2001/build/./gcc/include -isystem
/root/gcc-snapshot-2001/build/./gcc/include-fixed -MD unwind-dw2.d -MF
unwind-dw2.dep -MP -MT unwind-dw2.o -D IN_GCC -D HAVE_GTHR_DEFAULT -D
IN_LIBGCC2 -D HAVE_CC_TLS -D HIDE_EXPORTS -isystem
/usr/lib/gcc-snapshot/arm-linux-gnueabihf/include -isystem
/usr/lib/gcc-snapshot/arm-linux-gnueabihf/sys-include -isystem ./include
../../../src/libgcc/unwind-dw2.c -quiet -dumpbase unwind-dw2.c -march=armv7-a
-mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -mtls-dialect=gnu -auxbase-strip
unwind-dw2.i -g -g -g -O2 -O2 -O2 -Wextra -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fPIC
-fbuilding-libgcc -fno-stack-protector -fexceptions -fvisibility=hidden -o
/tmp/cco4mgij.s
GNU C (Debian 2001-1) version 4.7.0 2001 (experimental) [trunk revision
180743] (arm-linux-gnueabihf)
compiled by GNU C version 4.6.1, GMP version 5.0.2, MPFR version 3.1.0,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/usr/lib/gcc-snapshot/arm-linux-gnueabihf/include"
ignoring nonexistent directory
"/usr/lib/gcc-snapshot/arm-linux-gnueabihf/sys-include"
ignoring nonexistent directory "./include"
ignoring nonexistent directory
"/root/gc

[Bug middle-end/50966] [4.4/4.5/4.6/4.7 Regression] Missing 'is used uninitialized' warning (struct pointer dereference)

[manu at gcc dot gnu.org]

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

--- Comment #1 from Manuel López-Ibáñez  2011-11-02 
19:19:39 UTC ---
Well, it did fix one of the oldest false positives in GCC:

PR middle-end/179
* tree-ssa.c (warn_uninit): Do not warn for variables that can be
initialized outside the current module.
(warn_uninitialized_var): Ignore left-hand side when walking the
trees. Ignore address expressions. Examine VUSE operands in gimple
statements with a variable declaration on the right-hand side.
testsuite/
* gcc.dg/uninit-6.c (make_something): Remove XFAIL.
* gcc.dg/uninit-6-O0.c (make_something): Remove XFAIL.
* gcc.dg/uninit-B.c (baz): Remove XFAIL.
* gcc.dg/uninit-B-2.c: New.
* gcc.dg/uninit-B-O0-2.c: New.
* gcc.dg/uninit-pr19430-O0.c: New.
* gcc.dg/uninit-pr19430.c: New.
* gcc.dg/uninit-pr19430-2.c: New.

so I think it is a good trade-off.

This may be easy to fix, but I don't have enough free time to look at it, and
the uninitialized warning code has changed a lot since that revision, so anyone
has as good chance to fix this as me. If you want some tips on where to start,
just let me know.

[Bug c/50968] ICE on armhf building gcc-snapshot

[konstantinos.margaritis at linaro dot org]

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

--- Comment #1 from Konstantinos Margaritis  2011-11-02 19:21:19 UTC ---
Created attachment 25693
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25693
minimal testcase produced using delta tool from src/libgcc/unwind-dw2.c

[Bug middle-end/50966] [4.4/4.5/4.6/4.7 Regression] Missing 'is used uninitialized' warning (struct pointer dereference)

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez  2011-11-02 
19:24:44 UTC ---
BTW, this could actually be a duplicate of PR19430, if bar uninitialized use
appears in a PHI op. One would need to look at the dumps and put a breakpoint
at the warning point to see what is going on.

[Bug target/50968] ICE on armhf building gcc-snapshot

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2011-11-02 
19:24:51 UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29693

[Bug target/50945] [4.7 regression] ICE on floating-point move with -msoft-float

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  2011-11-02 
20:03:32 UTC ---
Author: ebotcazou
Date: Wed Nov  2 20:03:27 2011
New Revision: 180791

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180791
Log:
PR target/50945
* config/sparc/sparc.md (movsf_insn): Reindent constraints.
(movdf_insn_sp32): Likewise.  Remove redundant G constraint.
(movdf_insn_sp64): Likewise.
(DFmode splitter): Do not test TARGET_FPU.
(movtf_insn_sp32): Reindent constraints.
(movtf_insn_sp32_no_fpu): Likewise.
(movtf_insn_sp64): Likewise.
(movtf_insn_sp64_hq): Likewise.
(movtf_insn_sp64_no_fpu): Likewise.

Added:
trunk/gcc/testsuite/gcc.target/sparc/2002-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.md
trunk/gcc/testsuite/ChangeLog

[Bug target/50945] [4.7 regression] ICE on floating-point move with -msoft-float

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  2011-11-02 
20:07:31 UTC ---
Author: ebotcazou
Date: Wed Nov  2 20:07:26 2011
New Revision: 180792

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180792
Log:
PR target/50945
* config/sparc/sparc.md (movsf_insn): Reindent constraints.
(movsf_insn_no_fpu): Likewise.
(movdf_insn_sp32): Likewise.
(movdf_insn_sp32_no_fpu): Likewise.
(movdf_insn_sp32_v9): Likewise.  Remove redundant GY constraint.
(movdf_insn_sp32_v9_no_fpu): Likewise.
(movdf_insn_sp64): Likewise.
(movdf_insn_sp64_no_fpu): Likewise.
(movtf_insn_sp32): Likewise.
(movtf_insn_sp32_no_fpu): Likewise.
(movtf_insn_sp64): Likewise.
(movtf_insn_sp64_hq): Likewise.
(movtf_insn_sp64_no_fpu): Likewise.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/sparc/sparc.md

[Bug target/50945] [4.7 regression] ICE on floating-point move with -msoft-float

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Eric Botcazou  2011-11-02 
20:09:12 UTC ---
Thanks for reporting the problem.

[Bug fortran/50960] [OOP] vtables not marked as constant

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org 2011-11-02 20:11:01 UTC ---
(In reply to comment #9)
> Apart from the two failures above, the patch in comment 1 also fails on:
> 
> FAIL: gfortran.dg/class_15.f03  -O  (internal compiler error)

The reason for this seems to be some module loading problem: The vtype of 't2'
is loaded from the module alright, while the vtab is not. As a consequence,
sym->value is not set correctly (in 'gfc_find_derived_vtab'). I'm currently not
sure how to fix the underlying problem, but the resulting segfault can be fixed
by:

Index: resolve.c
===
--- resolve.c   (revision 180780)
+++ resolve.c   (working copy)
@@ -11971,7 +11971,7 @@ resolve_fl_parameter (gfc_symbol *sym)
   /* Make sure the types of derived parameters are consistent.  This
  type checking is deferred until resolution because the type may
  refer to a derived type from the host.  */
-  if (sym->ts.type == BT_DERIVED
+  if (sym->ts.type == BT_DERIVED && sym->value
   && !gfc_compare_types (&sym->ts, &sym->value->ts))
 {
   gfc_error ("Incompatible derived type in PARAMETER at %L",