[Bug c++/49756] g++ ICE

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-07-22 
08:33:42 UTC ---
Author: jakub
Date: Fri Jul 22 08:33:37 2011
New Revision: 176617

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176617
Log:
PR c++/49756
* libiberty.h (stack_limit_increase): New prototype.

* stack-limit.c: New file.
* Makefile.in: Regenerate deps.
(CFILES): Add stack-limit.c.
(REQUIRED_OFILES): Add ./stack-limit.$(objext).
* configure.ac (checkfuncs): Add getrlimit and setrlimit.
(AC_CHECK_FUNCS): Likewise.
* configure: Regenerated.
* config.in: Regenerated.

* gcc.c (main): Call stack_limit_increase (64MB).
* toplev.c (toplev_main): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcc.c
trunk/gcc/toplev.c
trunk/include/ChangeLog
trunk/include/libiberty.h
trunk/libiberty/ChangeLog
trunk/libiberty/Makefile.in
trunk/libiberty/config.in
trunk/libiberty/configure
trunk/libiberty/configure.ac

[Bug bootstrap/49797] CLooG use of LANGUAGE_C conflicts with MIPS compilers

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  2011-07-22 08:49:27 UTC 
---
Author: ro
Date: Fri Jul 22 08:49:23 2011
New Revision: 176618

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176618
Log:
PR bootstrap/49797
* graphite-clast-to-gimple.c (CLOOG_LANGUAGE_C): Provide if missing.
(set_cloog_options): Use it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-clast-to-gimple.c

[Bug bootstrap/49797] CLooG use of LANGUAGE_C conflicts with MIPS compilers

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-07/msg01747.htm
   ||l
 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-22 08:50:40 UTC 
---
Fixed for 4.7.0.

[Bug c++/49812] New: strange return type for built-in operator++(int, int)

[frederic.bron at m4x dot org]

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

   Summary: strange return type for built-in operator++(int, int)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: frederic.b...@m4x.org


The following code attempts to detect if operator++ returns void or not.
The program writes true (meaning that operator++ returns void) instead of
false.
msvc 10 and icpc 12.0 are right in writing false.

The standard states in 13.6/3 (Built-in operators):
"For every pair (T, VQ), where T is an arithmetic type, and VQ is
either volatile
or empty, there exist candidate operator functions of the form
VQ T& operator++(VQ T&);
T operator++(VQ T&, int);"

That means that for an "int volatile" variable the corresponding built-in
operator should be:
int operator++(int volatile &, int);
which should bind well with operator,(const int&, returns_void_t).

#include 
#include 

namespace detail {
  typedef char yes_type;
  struct no_type { char padding[8]; };

  struct returns_void_t {};
  static yes_type returns_void(returns_void_t);
  static no_type returns_void(int);
}
template  int operator,(const T&, ::detail::returns_void_t);
template  int operator,(const volatile T&,
::detail::returns_void_t);

#define RETURNS_VOID(Expr)\
  sizeof(::detail::yes_type)\
  ==\
  sizeof(::detail::returns_void(((Expr), ::detail::returns_void_t(

int main() {
  int volatile one_int_volatile;
  std::cout<

[Bug c++/49812] strange return type for built-in operator++(int, int)

[frederic.bron at m4x dot org]

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

--- Comment #1 from Frédéric Bron  2011-07-22 
08:58:31 UTC ---
Created attachment 24809
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24809
program that fails

This program should write false but writes true.

[Bug bootstrap/49794] [4.7 regression] Solaris 10/x86 bootstrap broken by C++ build

[ro at gcc dot gnu.org]

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

--- Comment #2 from Rainer Orth  2011-07-22 08:58:28 UTC 
---
Author: ro
Date: Fri Jul 22 08:58:25 2011
New Revision: 176620

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176620
Log:
2011-07-20  Rainer Orth  
Ralf Wildenhues  

gcc:
PR bootstrap/49794
* configure.ac: Test AM_ICONV with CXX.
* configure: Regenerate.
* config/sol2-c.c (solaris_format_types): Use EXPORTED_CONST.

gcc/ada:
PR bootstrap/49794
* init.c [sun && __SVR4 && !__vxworks] (__gnat_install_handler):
Assign to act.sa_sigaction.
* tracebak.c [USE_GENERIC_UNWINDER] (__gnat_backtrace): Cast
current->return_address to char * before arithmetic.

libcpp:
PR bootstrap/49794
* configure.ac: Test AM_ICONV with CXX.
* configure: Regenerate.
* system.h (HAVE_DESIGNATED_INITIALIZERS): Never define for C++.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/init.c
trunk/gcc/ada/tracebak.c
trunk/gcc/config/sol2-c.c
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/libcpp/ChangeLog
trunk/libcpp/configure
trunk/libcpp/configure.ac
trunk/libcpp/system.h

[Bug bootstrap/49794] [4.7 regression] Solaris 10/x86 bootstrap broken by C++ build

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #3 from Rainer Orth  2011-07-22 09:00:47 UTC 
---
Fixed for 4.7.0.

[Bug c++/49756] g++ ICE

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2011-07-22 
09:21:52 UTC ---
Author: jakub
Date: Fri Jul 22 09:21:49 2011
New Revision: 176622

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176622
Log:
PR c++/49756
* libiberty.h (stack_limit_increase): New prototype.

* stack-limit.c: New file.
* Makefile.in: Regenerate deps.
(CFILES): Add stack-limit.c.
(REQUIRED_OFILES): Add ./stack-limit.$(objext).
* configure.ac (checkfuncs): Add getrlimit and setrlimit.
(AC_CHECK_FUNCS): Likewise.
* configure: Regenerated.
* config.in: Regenerated.

* gcc.c (main): Call stack_limit_increase (64MB).
* toplev.c (toplev_main): Likewise.

Added:
trunk/libiberty/stack-limit.c

[Bug middle-end/45819] [4.5 Regression] unexpected unaligned access to volatile int

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.22 09:49:13
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #10 from Richard Guenther  2011-07-22 
09:49:13 UTC ---
Testing a fix for the volatile issue in comment #9.

I can't reproduce anything wrong with the testcase from the initial comment,
that looks like a target / expander issue.

The issues probably should have had different bugs instead of lumping them
together here.

[Bug middle-end/49310] [4.7 Regression] Compile time hog in var-tracking emit

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #9 from Jakub Jelinek  2011-07-22 
09:52:45 UTC ---
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176538

[Bug c++/49812] strange return type for built-in operator++(int, int)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.22 10:15:28
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1

[Bug c++/49813] New: sinh vs asinh vs constexpr

[paolo.carlini at oracle dot com]

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

   Summary: sinh vs asinh vs constexpr
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paolo.carl...@oracle.com


Hi. This issue, pointed out in private email by Vincenzo, puzzles me, I'm not
even sure whether it's a C++ proper or an optimization issue related to the way
we are lately able to optimize at compile time, mathematical functions of
compile time constant arguments. To be safe, I'm adding in CC both Jason and
Richi.

(Note, I'm using math.h instead of cmath for avoidance of doubt that this may
have to do with the library...)

//

#include 

int main()
{
  constexpr double ds  = sinh(1.0);   // Ok
  constexpr double das = asinh(1.0);  // Doesn't compile.
}

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

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target|x86_64-linux|

--- Comment #1 from Richard Guenther  2011-07-22 
10:38:42 UTC ---
We do have code to constant fold asinh in builtins.c:

static tree
fold_builtin_1 (location_t loc, tree fndecl, tree arg0, bool ignore)
{
...
CASE_FLT_FN (BUILT_IN_ASINH):
  if (validate_arg (arg0, REAL_TYPE))
return do_mpfr_arg1 (arg0, type, mpfr_asinh, NULL, NULL, 0);
break;

It works for C:

#include 

int main()
{
const double ds  = sinh(1.0);   // Ok
const double das = asinh(1.0);  // Doesn't compile.
}

in the .original dump:

;; Function main (null)
;; enabled by -tree-original


{
  const double ds = 1.175201193643801378385660427738912403583526611328125e+0;
  const double das = 8.8137358701954304773806825323845259845256805419921875e-1;

const double ds = 1.175201193643801378385660427738912403583526611328125e+0;
const double das =
8.8137358701954304773806825323845259845256805419921875e-1;
}

[Bug c++/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 #2 from Richard Guenther  2011-07-22 
10:41:36 UTC ---
With C++ I get

> ./cc1plus -quiet t.c -fdump-tree-original -std=c++0x
t.c: In function 'int main()':
t.c:6:39: error: 'asinh' was not declared in this scope

without -std=c++0x the asinh declaration is there (this seems to be
a glibc issue?).  Look at the output from -dD -E -std=c++0x vs. w/o -std=c++0x.

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

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #3 from Richard Guenther  2011-07-22 
10:48:09 UTC ---
Because __STRICT_ANSI__ is defined.  Works with -std=gnu++0x.

[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

 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |

--- Comment #4 from Paolo Carlini  2011-07-22 
10:48:51 UTC ---
Richard, we need a target here, because not all targets have asinh (a C99
function) in math.h.

Otherwise, if you take out constexpr, of course it works. Only with constexpr
the issue is interesting, because, roughly speaking, it looks like the
front-end doesn't realize that the whole initialization of das can happen at
compile time. But I'm confused here, because I don't know the details about the
way the C++0x front-end figures out whether a function *not* marked constexpr,
like asinh, actually is being called with compile time constant argument and
thus calling it to initialize constexpr data is fine.

[Bug bootstrap/49810] [4.7 Regression] ld: Unsatisfied symbol "strsignal(int)" in file collect2.o

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

--- Comment #2 from Richard Guenther  2011-07-22 
10:50:10 UTC ---
You probably get different prototypes with C vs. C++ for strsignal.

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

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.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

--- Comment #5 from Paolo Carlini  2011-07-22 
10:52:03 UTC ---
We don't want this to depend on -std=gnu++0x vs -std=c++0x!!

The function is there, declared and callable, as removing constexpr reveals,
the behavior wrt constexpr data cannot depend on __STRICT_ANSI__.

[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 #6 from rguenther at suse dot de  
2011-07-22 10:56:51 UTC ---
On Fri, 22 Jul 2011, paolo.carlini at oracle dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
> 
> --- Comment #5 from Paolo Carlini  
> 2011-07-22 10:52:03 UTC ---
> We don't want this to depend on -std=gnu++0x vs -std=c++0x!!
> 
> The function is there, declared and callable, as removing constexpr reveals,
> the behavior wrt constexpr data cannot depend on __STRICT_ANSI__.

No, with -std=c++0x asinh is not declared and I get the error above.
With -std=gnu++0x the testcase works for me, even with constexpr.

No bug here.

[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 #7 from Paolo Carlini  2011-07-22 
11:02:01 UTC ---
I just tried. This:

#include 

int main()
{
  double ds  = sinh(1.0);
  double das = asinh(1.0);
}

this compiles fine with -std=c++0x for me. On Linux of course, other targets
have specific issues not relevant here. Or, for that matter:

#include 

int main()
{
  double ds  = std::sinh(1.0);
  double das = std::asinh(1.0);
}

we *really* want the latter to work fine both with -std=c++0x and -std=gnu++0x.

[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 #8 from vincenzo Innocente  
2011-07-22 11:06:41 UTC ---
what about other "new C99 functions" such as
cexprMath.cpp:16:64: error: 'float std::nextafter(float, float)' is not
'constexpr'
cexprMath.cpp:17:58: error: 'float std::trunc(float)' is not 'constexpr'
cexprMath.cpp:18:48: error: 'float std::lgamma(float)' is not 'constexpr'
cexprMath.cpp:19:46: error: 'float std::erfc(float)' is not 'constexpr'
?
have not tested all (yet).

from
#include 

struct foo {
  static constexpr float a = std::cos(3.);
  static constexpr float c = std::exp(3.);
  static constexpr float d = std::log(3.);
  static constexpr float e1 = std::asin(1.);
  static constexpr float h = std::sqrt(.1);
  static constexpr float p = std::pow(1.3,-0.75);
  static constexpr float es = std::sinh(1.);
  static constexpr float ec = std::cosh(1.);
  static constexpr float et = std::tanh(1.);
  static constexpr float zs = std::asinh(1.2);
  static constexpr float zc = std::acosh(1.2);
  static constexpr float zt = std::atanh(.5);
  static constexpr float pi1 =std::nextafter(std::cos(-1.f),0.f);
  static constexpr float three =std::trunc(std::cos(-1.f));
  static constexpr float l0 = std::lgamma(0.45f);
  static constexpr float er = std::erfc(0.45f);

};



as we are on the subject:
if the argument of the function is invalid such as

  static constexpr float nan1 = std::asin(1.45f);
  static constexpr float nan2 = std::sqrt(-1.45f);
I get exactly the same error as above which is a bit confusing

cexprMath.cpp:20:48: error: call to non-constexpr function 'float
std::asin(float)'
cexprMath.cpp:20:48: error: field initializer is not constant
cexprMath.cpp:21:49: error: call to non-constexpr function 'float
std::sqrt(float)'
cexprMath.cpp:21:49: error: field initializer is not constant

(the test of the message has changed between 4.6 and 4.7)

[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 #9 from Paolo Carlini  2011-07-22 
11:09:55 UTC ---
Yes, Vincenzo, all the other C99-only functions should be audited. I suppose a
clean fix will automatically deal with all of them.

[Bug bootstrap/49810] [4.7 Regression] ld: Unsatisfied symbol "strsignal(int)" in file collect2.o

[dave.anglin at bell dot net]

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

--- Comment #3 from dave.anglin at bell dot net 2011-07-22 11:12:01 UTC ---
On 22-Jul-11, at 6:50 AM, rguenth at gcc dot gnu.org wrote:
> You probably get different prototypes with C vs. C++ for strsignal.


The prototype has to come from libiberty since the system doesn't have  
strsignal:

/* Return a signal message string for a signal number
(e.g., strsignal (SIGHUP) returns something like "Hangup").  */
/* This is commented out as it can conflict with one in system headers.
We still document its existence though.  */

/*extern const char *strsignal (int);*/

Dave
--
John David Anglindave.ang...@bell.net

[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 #10 from rguenther at suse dot de  
2011-07-22 11:17:38 UTC ---
On Fri, 22 Jul 2011, paolo.carlini at oracle dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
> 
> --- Comment #9 from Paolo Carlini  
> 2011-07-22 11:09:55 UTC ---
> Yes, Vincenzo, all the other C99-only functions should be audited. I suppose a
> clean fix will automatically deal with all of them.

Looking at -original it seems that libstdc++ lacks C99 overloads for
double - it has them for float and long double only.

Or that

  inline float
  asinh(float __x)
  { return __builtin_asinhf(__x); }

  inline long double
  asinh(long double __x)
  { return __builtin_asinhl(__x); }

  template
inline typename __gnu_cxx::__enable_if<__is_integer<_Tp>::__value,
   double>::__type
asinh(_Tp __x)
{ return __builtin_asinh(__x); }

isn't constexpr compatible.

Doesn't sound like a middle-end issue but either a library or frontend
issue to me.

That said, it works fine if you give a asinh declaration in the
testcase.

Richard.

[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 #11 from Paolo Carlini  2011-07-22 
11:20:36 UTC ---
It does *not* Richi, there is an using ::asinh above. Exactly the same for
sinh.

[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 #12 from rguenther at suse dot de  
2011-07-22 11:20:52 UTC ---
On Fri, 22 Jul 2011, rguenther at suse dot de wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
> 
> --- Comment #10 from rguenther at suse dot de  
> 2011-07-22 11:17:38 UTC ---
> On Fri, 22 Jul 2011, paolo.carlini at oracle dot com wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
> > 
> > --- Comment #9 from Paolo Carlini  
> > 2011-07-22 11:09:55 UTC ---
> > Yes, Vincenzo, all the other C99-only functions should be audited. I 
> > suppose a
> > clean fix will automatically deal with all of them.
> 
> Looking at -original it seems that libstdc++ lacks C99 overloads for
> double - it has them for float and long double only.
> 
> Or that
> 
>   inline float
>   asinh(float __x)
>   { return __builtin_asinhf(__x); }
> 
>   inline long double
>   asinh(long double __x)
>   { return __builtin_asinhl(__x); }
> 
>   template
> inline typename __gnu_cxx::__enable_if<__is_integer<_Tp>::__value,
>double>::__type
> asinh(_Tp __x)
> { return __builtin_asinh(__x); }
> 
> isn't constexpr compatible.
> 
> Doesn't sound like a middle-end issue but either a library or frontend
> issue to me.
> 
> That said, it works fine if you give a asinh declaration in the
> testcase.

Btw, asinh is

  template
inline typename __gnu_cxx::__promote<_Tp>::__type
asinh(_Tp __x)
{
  typedef typename __gnu_cxx::__promote<_Tp>::__type __type;
  return asinh(__type(__x));
}

vs. sinh which is

  template
inline typename __gnu_cxx::__enable_if<__is_integer<_Tp>::__value,
double>::__type
sinh(_Tp __x)
{ return __builtin_sinh(__x); }

note the lack of __gnu_cxx::__promote

[Bug lto/49796] [4.7 Regression] 483.xalancbmk/447.dealII in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  2011-07-22 
11:23:42 UTC ---
Patch submitted to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01925.html

[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 #13 from Paolo Carlini  2011-07-22 
11:24:21 UTC ---
... and let's decide to look at mainline, first at least.

[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 #14 from rguenther at suse dot de  
2011-07-22 11:29:04 UTC ---
On Fri, 22 Jul 2011, paolo.carlini at oracle dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
> 
> --- Comment #11 from Paolo Carlini  
> 2011-07-22 11:20:36 UTC ---
> It does *not* Richi, there is an using ::asinh above. Exactly the same for
> sinh.

There is also a using ::asinhf but still std:: provides an
overload.

Please provide a _complete_ standalone testcase that you think should
work and does not (w/o any includes).

I suspect it's because of

DEF_C99_BUILTIN(BUILT_IN_CASINH, "casinh", 
BT_FN_COMPLEX_DOUBLE_COMPLEX_DOUBLE, ATTR_MATHFN_FPROUNDING)

so if -std=c++0x does not include C99 functions then we have no
implicit builtin support and the following does not work:

extern "C" double asinh(double x);

namespace std {
using ::asinh;
}

int main()
{
  constexpr double das = std::asinh(1.0);
}

it also does not work with

namespace std {
double asinh (double x) { return __builtin_asinh (x); }
}

int main()
{
  constexpr double das = std::asinh(1.0);  // Doesn't compile.
}

but it works with

int main()
{
  constexpr double das = __builtin_asinh(1.0);  // Doesn't compile.
}

which means this is still a C++ frontend / library issue.

[Bug c++/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 #15 from Richard Guenther  2011-07-22 
11:30:38 UTC ---
Also works with

namespace std {
constexpr double asinh (double x) { return __builtin_asinh (x); }
}

int main()
{
  constexpr double das = std::asinh(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

--- Comment #16 from Paolo Carlini  2011-07-22 
11:40:07 UTC ---
(In reply to comment #14)
> There is also a using ::asinhf but still std:: provides an overload.

So? This is what C++0x says we should have.

As regards a complete testcase, I gave two, one using , one a *real
world* piece of C++0x code, compiled with -std=c++0x on Linux.

#include 

int main()
{
  constexpr double cds  = std::sinh(1.0);  // Ok
  constexpr double cdas = std::asinh(1.0); // Not Ok.
  double das = std::asinh(1.0);// Ok.
}

we don't want those inconsistencies.

By the way, I find your:

constexpr double cdas = __builtin_asinh(1.0);

very interesting. Looks like really the front-end is doing something strange
wrt declarations of C99 functions: if  provided by glibc is include
then the declarations are definitely there, in strict c++0x mode too, but the
front-end is trying to invent something on its own, disregards those
declarations somehow, but *only* when dealing with constexpr data, not
otherwise.

[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 #17 from rguenther at suse dot de  
2011-07-22 11:43:57 UTC ---
On Fri, 22 Jul 2011, paolo.carlini at oracle dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
> 
> --- Comment #16 from Paolo Carlini  
> 2011-07-22 11:40:07 UTC ---
> (In reply to comment #14)
> > There is also a using ::asinhf but still std:: provides an overload.
> 
> So? This is what C++0x says we should have.
> 
> As regards a complete testcase, I gave two, one using , one a *real
> world* piece of C++0x code, compiled with -std=c++0x on Linux.
> 
> #include 
> 
> int main()
> {
>   constexpr double cds  = std::sinh(1.0);  // Ok
>   constexpr double cdas = std::asinh(1.0); // Not Ok.
>   double das = std::asinh(1.0);// Ok.
> }
> 
> we don't want those inconsistencies.
> 
> By the way, I find your:
> 
> constexpr double cdas = __builtin_asinh(1.0);
> 
> very interesting. Looks like really the front-end is doing something strange
> wrt declarations of C99 functions: if  provided by glibc is include
> then the declarations are definitely there, in strict c++0x mode too, but the
> front-end is trying to invent something on its own, disregards those
> declarations somehow, but *only* when dealing with constexpr data, not
> otherwise.

Is it valid in C++0x to provide a global function

double asinh (double x)
{
  abort ();
}

?  In that case we can't inject __builtin_asinh as asinh into the
global namespace (as -std=gnu++0x does) and the using ::asinh
is bogus(?)

If the above is invalid then with -std=c++0x the C++ frontend should
set flag_iso_c99 to true.

Richard.

[Bug target/49798] .quad instead of .long is used for address for x32

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #18 from H.J. Lu  2011-07-22 11:54:45 
UTC ---
Won't fix.

[Bug middle-end/45819] [4.5 Regression] unexpected unaligned access to volatile int

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Guenther  2011-07-22 
11:55:33 UTC ---
Author: rguenth
Date: Fri Jul 22 11:55:30 2011
New Revision: 176623

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

PR tree-optimization/45819
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Properly
preserve volatile and notrap flags.

* gcc.dg/pr45819.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr45819.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable

[burnus at gcc dot gnu.org]

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

--- Comment #13 from Tobias Burnus  2011-07-22 
12:08:28 UTC ---
Regarding the LHS (in addition to comment 6):

- It may not be coindexed ("!gfc_is_conindexed(e)")
- It may not be a coarray ("!gfc_expr_attr (e).codimension")
- It may not have a coarray component ("!gfc_expr_attr (e).coarray_comp")

Cf. F2008, 7.2.1.2, item (1) and (3).

[Bug middle-end/45819] [4.5 Regression] unexpected unaligned access to volatile int

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther  2011-07-22 
12:19:25 UTC ---
Author: rguenth
Date: Fri Jul 22 12:19:21 2011
New Revision: 176624

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

PR tree-optimization/45819
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Properly
preserve volatile and notrap flags.

* gcc.dg/pr45819.c: New testcase.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr45819.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/tree-ssa-forwprop.c

[Bug middle-end/45819] [4.5 Regression] unexpected unaligned access to volatile int

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #13 from Richard Guenther  2011-07-22 
12:20:30 UTC ---
Comment #9 should be fixed now.  That leaves the initial report which I
can't reproduce - thus, not mine anymore.

Please someone verify comment #9 on arm.

[Bug middle-end/45819] [4.5 Regression] unexpected unaligned access to volatile int

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Guenther  2011-07-22 
12:21:30 UTC ---
Oh, the initial testcase was invalid anyway.

[Bug middle-end/45819] [4.5 Regression] unexpected unaligned access to volatile int

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #15 from Richard Guenther  2011-07-22 
12:25:01 UTC ---
struct ehci_regs {  
char x; 
unsigned int port_status[0];
} __attribute__ ((packed)); 
//} __attribute__ ((packed,aligned(__alignof__(int; 

struct ehci_hcd{
struct ehci_regs *regs; 
};  

int ehci_hub_control (  
 struct ehci_hcd *ehci, 
 int wIndex 
) { 
 unsigned int *status_reg = &ehci->regs->port_status[wIndex];   
 return *(volatile unsigned int *)status_reg;   
}

this one is invalid as well, with or without the aligned attribute.

ehci->regs->port_status[wIndex] _is_ unaligned.  I don't think there
is currently a way to tell GCC that the struct layout of ehci_regs is
packed but port_status is properly aligned to the natural alignment of int.

[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 #18 from Paolo Carlini  2011-07-22 
12:31:05 UTC ---
Before any other discussion (I believe we want to hear Jason now) I only want
to add this: I think the whole discussion about -std=c++0x vs -std=gnu++0x can
only possibly be useful in so far as it helps figuring out where is the bug.
Because, really, part of the C++11 standard is certainly the unconditional
availability of all of the C99 mathematical functions (more generally, the
reference C language is everywhere C99 instead of C89, as it should be in
2011). Thus, I don't know at this point where exactly is the bug/issue, in the
front-end, in some glibc bits vs C++11, in interactions, but I'm pretty sure we
*do* have an issue here. To restate, from the C++11 point of view, sinh and
asinh are 100% on a par. If we see an inconsistency in our implementers "world"
about the way we are dealing in strict c++0x mode with those mathematical
functions, it's our fault, a bug or a QoI issue.

[Bug bootstrap/49815] New: [4.7 regression] ICE in cselib_record_set, at cselib.c:2241 compiling 64-bit libjava on SPARC

[ro at gcc dot gnu.org]

runk/local/gcc/cgraphunit.c:2126
#15 0x001efda4 in cgraph_finalize_compilation_unit () at
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1304
#16 0x00340e70 in write_global_declarations () at
/vol/gcc/src/hg/trunk/local/gcc/langhooks.c:303
#17 0x00170844 in java_write_globals () at
/vol/gcc/src/hg/trunk/local/gcc/java/class.c:3241
#18 0x00437c20 in compile_file (argc=19, argv=0xffbff3ec) at
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:564
#19 do_compile (argc=19, argv=0xffbff3ec) at
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:1886
#20 toplev_main (argc=19, argv=0xffbff3ec) at
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:1962
#21 0x00166ef4 in _start ()
The last working bootstrap was on 20110715 (r176317), 20110720 (unknown rev)
was already broken, 20110722 (r176317) still is.

[Bug bootstrap/49815] [4.7 regression] ICE in cselib_record_set, at cselib.c:2241 compiling 64-bit libjava on SPARC

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug bootstrap/49815] [4.7 regression] ICE in cselib_record_set, at cselib.c:2241 compiling 64-bit libjava on SPARC

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  2011-07-22 12:55:48 UTC 
---
Created attachment 24810
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24810
jc1 input file

[Bug bootstrap/49815] [4.7 regression] ICE in cselib_record_set, at cselib.c:2241 compiling 64-bit libjava on SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #2 from Eric Botcazou  2011-07-22 
13:07:18 UTC ---
> Solaris/SPARC bootstrap is currently broken:

Java though, which is pretty much useless on this platform.

> Here's a reduced command line:
> 
> $ jc1 ccd.list -fuse-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions
> -fkeep-inline-functions -mptr64 -mstack-bias -mno-v8plus -mcpu=v9 -quiet -m64
> -g -O2 -ffilelist-file -fencoding=UTF-8 -fbootstrap-classes -fPIC
> -fbootclasspath=./:/vol/gcc/src/hg/trunk/local/libjava/classpath/lib/
> 
> I'm attaching the ccd.list file.
> 
> Stacktrace is
> 
> #0  fancy_abort (file=0x956890 "/vol/gcc/src/hg/trunk/local/gcc/cselib.c",
> line=2241, function=0x956ad0 "cselib_record_set") at
> /vol/gcc/src/hg/trunk/local/gcc/diagnostic.c:893
> #1  0x001f94a4 in cselib_record_set (insn=0x6cf02870) at
> /vol/gcc/src/hg/trunk/local/gcc/cselib.c:2241
> #2  cselib_record_sets (insn=0x6cf02870) at
> /vol/gcc/src/hg/trunk/local/gcc/cselib.c:2422

Could you run 'debug_rtx(insn)' on the problematic insn?

[Bug bootstrap/49815] [4.7 regression] ICE in cselib_record_set, at cselib.c:2241 compiling 64-bit libjava on SPARC

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-07-22 13:14:39 UTC ---
> --- Comment #2 from Eric Botcazou  2011-07-22 
> 13:07:18 UTC ---
>> Solaris/SPARC bootstrap is currently broken:
>
> Java though, which is pretty much useless on this platform.

But it used to work until now.

>> Stacktrace is
>> 
>> #0  fancy_abort (file=0x956890 "/vol/gcc/src/hg/trunk/local/gcc/cselib.c",
>> line=2241, function=0x956ad0 "cselib_record_set") at
>> /vol/gcc/src/hg/trunk/local/gcc/diagnostic.c:893
>> #1  0x001f94a4 in cselib_record_set (insn=0x6cf02870) at
>> /vol/gcc/src/hg/trunk/local/gcc/cselib.c:2241
>> #2  cselib_record_sets (insn=0x6cf02870) at
>> /vol/gcc/src/hg/trunk/local/gcc/cselib.c:2422
>
> Could you run 'debug_rtx(insn)' on the problematic insn?

Sure:

(insn/f:TI 129 100 9 2 (parallel [
(set (reg:DI 24 %i0 [ this ])
(reg:DI 8 %o0 [ this ]))
(clobber:DI (reg:DI 8 %o0))
(set (reg:DI 25 %i1 [ defaults ])
(reg:DI 9 %o1 [ defaults ]))
(clobber:DI (reg:DI 9 %o1))
(set (reg:DI 24 %i0 [ this ])
(reg:DI 8 %o0 [ this ]))
(clobber:DI (reg:DI 8 %o0))
(set (reg:DI 25 %i1 [ id+-4 ])
(reg:DI 9 %o1 [ id+-4 ]))
(clobber:DI (reg:DI 9 %o1))
(set (reg:DI 26 %i2 [ e ])
(reg:DI 10 %o2 [ e ]))
(clobber:DI (reg:DI 10 %o2))
(set (reg:DI 27 %i3 [ target ])
(reg:DI 11 %o3 [ target ]))
(clobber:DI (reg:DI 11 %o3))
]) javax/swing/plaf/basic/BasicInternalFrameUI.java:868 393
{window_save}
 (expr_list:REG_CFA_DEF_CFA (plus:DI (reg/f:DI 30 %fp)
(const_int 2047 [0x7ff]))
(expr_list:REG_CFA_WINDOW_SAVE (const_int 0 [0])
(expr_list:REG_CFA_REGISTER (set (reg:DI 31 %i7)
(reg:DI 15 %o7))
(nil)

Rainer

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  2011-07-22 
13:49:59 UTC ---
After reviewing the listread.c and the test case I see that the touched should
have nothing to do with this test case since the case has nothing to do with
derived types.

I think the flaw is that touched should be combined with BT_DERIVED if used
here at all. This leads me to believe we are missing a parenthesis around
BT_DERIVED and touched and they should be ANDed in some manner..

Tobias patch is probably safe, but it may be possible to dream up a test case
with derived types that will fail. (There is probably one buried in my archives
but finding it would be a chore)

[Bug bootstrap/49815] [4.7 regression] ICE in cselib_record_set, at cselib.c:2241 compiling 64-bit libjava on SPARC

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2011-07-22 
13:58:06 UTC ---
That's strange why i0/o0 and i1/o1 pairs were added twice.
Can you put a breakpoint into vt_add_function_parameter where it adds
for #ifdef HAVE_window_save p->outgoing = incoming; and for the problematic
function see why it is called twice with i0/o0 and i1/o1?

[Bug middle-end/49545] [4.6 Regression] New C++ test failures

[hp at gcc dot gnu.org]

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

--- Comment #11 from Hans-Peter Nilsson  2011-07-22 
14:01:50 UTC ---
Looks like this got "unfixed" on trunk?
It worked on r176507, had reappeared on r176524.

[Bug bootstrap/49815] [4.7 regression] ICE in cselib_record_set, at cselib.c:2241 compiling 64-bit libjava on SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  2011-07-22 
14:09:15 UTC ---
> (insn/f:TI 129 100 9 2 (parallel [
> (set (reg:DI 24 %i0 [ this ])
> (reg:DI 8 %o0 [ this ]))
> (clobber:DI (reg:DI 8 %o0))
> (set (reg:DI 25 %i1 [ defaults ])
> (reg:DI 9 %o1 [ defaults ]))
> (clobber:DI (reg:DI 9 %o1))
> (set (reg:DI 24 %i0 [ this ])
> (reg:DI 8 %o0 [ this ]))
> (clobber:DI (reg:DI 8 %o0))
> (set (reg:DI 25 %i1 [ id+-4 ])
> (reg:DI 9 %o1 [ id+-4 ]))
> (clobber:DI (reg:DI 9 %o1))
> (set (reg:DI 26 %i2 [ e ])
> (reg:DI 10 %o2 [ e ]))
> (clobber:DI (reg:DI 10 %o2))
> (set (reg:DI 27 %i3 [ target ])
> (reg:DI 11 %o3 [ target ]))
> (clobber:DI (reg:DI 11 %o3))
> ]) javax/swing/plaf/basic/BasicInternalFrameUI.java:868 393
> {window_save}
>  (expr_list:REG_CFA_DEF_CFA (plus:DI (reg/f:DI 30 %fp)
> (const_int 2047 [0x7ff]))
> (expr_list:REG_CFA_WINDOW_SAVE (const_int 0 [0])
> (expr_list:REG_CFA_REGISTER (set (reg:DI 31 %i7)
> (reg:DI 15 %o7))
> (nil)

I see, thanks.  Very likely an oversight of mine, patch to be attached.

If you still have the build tree around, would you mind checking that it fixes
the problem?  For example, apply it to the tree, run 'make quickstrap' from
within the gcc/ subdir of the build dir and then 'make all-target-libjava' from
the build dir itself.

[Bug bootstrap/49815] [4.7 regression] ICE in cselib_record_set, at cselib.c:2241 compiling 64-bit libjava on SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.22 14:10:16
 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot
   |gnu.org |gnu.org
 Ever Confirmed|0   |1

--- Comment #6 from Eric Botcazou  2011-07-22 
14:10:16 UTC ---
Created attachment 24811
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24811
Tentative fix

[Bug bootstrap/49815] [4.7 regression] ICE in cselib_record_set, at cselib.c:2241 compiling 64-bit libjava on SPARC

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-07-22 
14:14:07 UTC ---
Ah, I see.  adjust_insn call isn't guarded by MAY_HAVE_DEBUG_STMTS, therefore
if -fvar-tracking-assignments gives up due to insanely large hash tables, it
won't be reset during vt_finalize.

BTW, wouldn't it be better to model the insn completely rather than partially?
In particular, in addition to the arguments being copied have also the
copy/clobber for all the other arguments, except for the sp = sp - something
which would be another set.

[Bug bootstrap/49815] [4.7 regression] ICE in cselib_record_set, at cselib.c:2241 compiling 64-bit libjava on SPARC

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2011-07-22 
14:17:14 UTC ---
That tentative fix is obviously correct and preapproved.  But please think
about the rest of sets/clobbers and especially keeping the sp = sp -
constant/reg
explicit - var-tracking is certainly interested in any stack pointer changes.

[Bug bootstrap/49815] [4.7 regression] ICE in cselib_record_set, at cselib.c:2241 compiling 64-bit libjava on SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  2011-07-22 
14:37:50 UTC ---
> Ah, I see.  adjust_insn call isn't guarded by MAY_HAVE_DEBUG_STMTS, therefore
> if -fvar-tracking-assignments gives up due to insanely large hash tables, it
> won't be reset during vt_finalize.

My assumption as well.

> BTW, wouldn't it be better to model the insn completely rather than partially?
> In particular, in addition to the arguments being copied have also the
> copy/clobber for all the other arguments, except for the sp = sp - something
> which would be another set.

What other arguments?  Does vt_add_function_parameters not see them all?  I'm
not sure I understand the need to model the stack decrement either given that
the CFA register is the frame pointer.

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

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.22 14:41:46
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #19 from Jason Merrill  2011-07-22 
14:41:46 UTC ---
Strictly speaking, the bug is that

  constexpr double ds  = sinh(1.0);   // Ok

is accepted; the standard doesn't say that sinh is constexpr, so it isn't
usable in a constant expression.  G++ treating built-ins as constexpr is an
extension, which should be disabled in strict conformance mode.  Paolo, can you
raise the question of marking C library functions as constexpr with the library
WG?

But practically speaking, we should have C90 builtins in C++98, and C99
builtins in C++11.  I suppose that means setting flag_isoc94 and flag_isoc99 in
C++.

[Bug bootstrap/49815] [4.7 regression] ICE in cselib_record_set, at cselib.c:2241 compiling 64-bit libjava on SPARC

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  2011-07-22 
14:46:49 UTC ---
(In reply to comment #9)
> > BTW, wouldn't it be better to model the insn completely rather than 
> > partially?
> > In particular, in addition to the arguments being copied have also the
> > copy/clobber for all the other arguments, except for the sp = sp - something
> > which would be another set.
> 
> What other arguments?  Does vt_add_function_parameters not see them all?  I'm

I meant registers.  Especially with the planned shrink wrapping, say if code
before the prologue stores some argument into %o5 register that doesn't hold
any parameter and then prologue does perform a save, that value is now live in
%i5 rather than %o5 and var-tracking should handle that transparently.

> not sure I understand the need to model the stack decrement either given that
> the CFA register is the frame pointer.

Var-tracking should be told that this window save instruction initializes the
hard frame pointer (%i6 <= %o6) and that %o6 has been decremented, without that
it is possible it will give wrong answers where values live in.

[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 #20 from Paolo Carlini  2011-07-22 
15:07:53 UTC ---
I see, everything makes sense now. And OK, I'll raise the issue (in fact, we
have Daniel in CC, in this bug... ;)

[Bug bootstrap/49815] [4.7 regression] ICE in cselib_record_set, at cselib.c:2241 compiling 64-bit libjava on SPARC

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-07-22 15:14:13 UTC ---
> If you still have the build tree around, would you mind checking that it fixes
> the problem?  For example, apply it to the tree, run 'make quickstrap' from
> within the gcc/ subdir of the build dir and then 'make all-target-libjava' 
> from
> the build dir itself.

I just did that and the libjava build completed just find.

Thanks for the blindingly fast fix.

Rainer

[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 #21 from Paolo Carlini  2011-07-22 
15:31:15 UTC ---
Hum (Jason and Daniel, in particular) I'm wondering if the issue could fall
under http://lwg.github.com/issues/lwg-active.html#2013 but then, we would be
able to assume / do it only for glibc on which we have control?!? I have no
idea if the implementations in the various libc out there all satisfy the
prerequisites for a function to be marked constexpr. Do you see my point? Or
Jason you mean something else entirely?

[Bug lto/49796] [4.7 Regression] 483.xalancbmk/447.dealII in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  2011-07-22 
15:35:54 UTC ---
Author: jamborm
Date: Fri Jul 22 15:35:48 2011
New Revision: 176630

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176630
Log:
2011-07-22  Martin Jambor  

PR lto/49796
* cgraphunit.c (verify_edge_corresponds_to_fndecl): Return false
if decl node is in another partition, call cgraph_get_node only
once.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c

[Bug lto/49796] [4.7 Regression] 483.xalancbmk/447.dealII in SPEC CPU 2006 failed to build

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Martin Jambor  2011-07-22 
15:39:43 UTC ---
Should be fixed now.

[Bug target/49816] New: arm.c:3999:12: error: converting 'false' to pointer type 'rtx'

[danglin at gcc dot gnu.org]

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

   Summary: arm.c:3999:12: error: converting 'false' to pointer
type 'rtx'
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: armv5tejl-unknown-linux-gnueabi
Target: armv5tejl-unknown-linux-gnueabi
 Build: armv5tejl-unknown-linux-gnueabi


/home/dave/gnu/gcc/objdir/./prev-gcc/g++
-B/home/dave/gnu/gcc/objdir/./prev-gcc/
 -B/home/dave/opt/gnu/gcc/gcc-4.7/armv5tejl-unknown-linux-gnueabi/bin/
-nostdinc
++
-B/home/dave/gnu/gcc/objdir/prev-armv5tejl-unknown-linux-gnueabi/libstdc++-v3
/src/.libs
-B/home/dave/gnu/gcc/objdir/prev-armv5tejl-unknown-linux-gnueabi/libs
tdc++-v3/libsupc++/.libs
-I/home/dave/gnu/gcc/objdir/prev-armv5tejl-unknown-linu
x-gnueabi/libstdc++-v3/include/armv5tejl-unknown-linux-gnueabi
-I/home/dave/gnu/
gcc/objdir/prev-armv5tejl-unknown-linux-gnueabi/libstdc++-v3/include
-I/home/dav
e/gnu/gcc/gcc/libstdc++-v3/libsupc++
-L/home/dave/gnu/gcc/objdir/prev-armv5tejl-
unknown-linux-gnueabi/libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir/prev-armv5tejl-unknown-linux-gnueabi/libstdc++-v3/libsupc++/.libs
-c  -g -O2 -gtoggle -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror   -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc
-I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I/home/dave/opt/gnu/include  -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber  
-I/home/dave/opt/gnu/include \
../../gcc/gcc/config/arm/arm.c -o arm.o
../../gcc/gcc/config/arm/arm.c: In function 'rtx_def*
aapcs_vfp_allocate_return_reg(arm_pcs, machine_mode, const_tree)':
../../gcc/gcc/config/arm/arm.c:3999:12: error: converting 'false' to pointer
type 'rtx' [-Werror=conversion-null]
cc1plus: all warnings being treated as errors

[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

[ubizjak at gmail dot com]

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

--- Comment #18 from Uros Bizjak  2011-07-22 15:50:58 
UTC ---
The patch that increased RLIMIT_STACK in the driver as well as compiler (PR
c++/49756) [1] fixed this on linux targets.

Jakub, you have a patch pending in Comment #17. Do you plan to commit it?

Can we close this PR?

[1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01766.html

[Bug debug/47393] g++.dg/debug/dwarf2/icf.C FAILs on IRIX

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth  2011-07-22 16:02:30 UTC 
---
Author: ro
Date: Fri Jul 22 16:02:25 2011
New Revision: 176633

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176633
Log:
PR debug/47393
* g++.dg/debug/dwarf2/icf.C: XFAIL some scan-assembler on
mips-sgi-irix*.

Modified:
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/debug/dwarf2/icf.C

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

[jason at gcc dot gnu.org]

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

--- Comment #22 from Jason Merrill  2011-07-22 
16:06:13 UTC ---
Author: jason
Date: Fri Jul 22 16:06:08 2011
New Revision: 176635

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176635
Log:
PR c++/49813
* c-opts.c (set_std_cxx0x): Set flag_isoc94 and flag_isoc99.
* c-pretty-print.c (pp_c_cv_qualifiers): Check c_dialect_cxx as well
as flag_isoc99 for 'restrict'.
(pp_c_specifier_qualifier_list): Likewise for _Complex.

Added:
trunk/gcc/testsuite/g++.dg/opt/builtins2.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-opts.c
trunk/gcc/c-family/c-pretty-print.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/other/error27.C

[Bug debug/47393] g++.dg/debug/dwarf2/icf.C FAILs on IRIX

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #6 from Rainer Orth  2011-07-22 16:31:27 UTC 
---
XFAILed on the 4.5 and 4.6 branches, gone on mainline.

[Bug debug/47393] g++.dg/debug/dwarf2/icf.C FAILs on IRIX

[ro at gcc dot gnu.org]

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

--- Comment #7 from Rainer Orth  2011-07-22 16:31:56 UTC 
---
Author: ro
Date: Fri Jul 22 16:31:52 2011
New Revision: 176640

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176640
Log:
PR debug/47393
* g++.dg/debug/dwarf2/icf.C: XFAIL some scan-assembler on
mips-sgi-irix*.

Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/debug/dwarf2/icf.C

[Bug bootstrap/49815] [4.7 regression] ICE in cselib_record_set, at cselib.c:2241 compiling 64-bit libjava on SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  2011-07-22 
16:41:22 UTC ---
> I meant registers.  Especially with the planned shrink wrapping, say if code
> before the prologue stores some argument into %o5 register that doesn't hold
> any parameter and then prologue does perform a save, that value is now live in
> %i5 rather than %o5 and var-tracking should handle that transparently.

I guess I'll wait and see here, because I don't understand how you can make a
value live through the save insn in the RTL stream if it isn't a parameter.

> Var-tracking should be told that this window save instruction initializes the
> hard frame pointer (%i6 <= %o6) and that %o6 has been decremented, without 
> that
> it is possible it will give wrong answers where values live in.

Do you mean when you put a breakpoint before the save or after the restore?  If
so, I'm not sure the local variables are (still) in scope.  I guess the restore
would also need to be handled then.

[Bug libstdc++/49293] 22_locale/time_get/get_weekday/char/38081-[12].cc fail with glibc 2.14

[uros at gcc dot gnu.org]

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

--- Comment #8 from uros at gcc dot gnu.org 2011-07-22 16:47:24 UTC ---
Author: uros
Date: Fri Jul 22 16:47:20 2011
New Revision: 176643

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176643
Log:
Backport from mainline
2011-06-07  Paolo Carlini  

PR libstdc++/49293
* testsuite/22_locale/time_get/get_weekday/char/38081-1.cc: Tweak
for glibc 2.14.
* testsuite/22_locale/time_get/get_weekday/char/38081-2.cc: Likewise.


Modified:
branches/gcc-4_6-branch/libstdc++-v3/ChangeLog
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/22_locale/time_get/get_weekday/char/38081-1.cc
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/22_locale/time_get/get_weekday/char/38081-2.cc

[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 #23 from vincenzo Innocente  
2011-07-22 16:48:35 UTC ---
would  http://lwg.github.com/issues/lwg-active.html#2013 allow gcc to declare
constexpr the x86 builtins (and corresponding wrapper functions)?
I would be interested to have constepxr vectors (__m128 etc)

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

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.22 16:48:39
 AssignedTo|unassigned at gcc dot   |dodji at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug debug/47393] g++.dg/debug/dwarf2/icf.C FAILs on IRIX

[ccoutant at gcc dot gnu.org]

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

Cary Coutant  changed:

   What|Removed |Added

 CC||ccoutant at gcc dot gnu.org

--- Comment #8 from Cary Coutant  2011-07-22 
16:49:11 UTC ---
Why not just remove the test entirely instead of XFAIL it? The functionality
that it was testing has been removed and replaced with something else.

[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 #14 from Paolo Carlini  2011-07-22 
17:00:57 UTC ---
Somebody should add a "Thumb Up" button to Bugzilla.

[Bug debug/47393] g++.dg/debug/dwarf2/icf.C FAILs on IRIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-07-22 17:02:11 UTC ---
> --- Comment #8 from Cary Coutant  2011-07-22 
> 16:49:11 UTC ---
> Why not just remove the test entirely instead of XFAIL it? The functionality
> that it was testing has been removed and replaced with something else.

That's something for mainline, while my patch dealt with the 4.5 and 4.6
branches.

I'll leave that to the interested parties :-)

Rainer

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-07-22 17:04:33 UTC ---
To make completely sure that this isn't a gcc problem of some sort, I've
derived a testcase from libgomp.  If built with cc -c99 or gcc, it shows
the same unaligned access, so this is really just a silly librt bug,
nothing else.

Rainer

[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 #24 from Paolo Carlini  2011-07-22 
17:16:43 UTC ---
As far as I can see, Vincenzo, in that case the problem is a bit different,
because those functions aren't ISO: should Intel issue an updated document
describing the builtins and acknowledging the new C++? To be honest I know
little about the way those builtins are "standardized", the way Intel issues
updates to the specs. Maybe you could open about that a separate "exploratory"
Bugzilla (in CC people like Uros)?!?

[Bug bootstrap/49786] [4.7 Regression] bootstrap failed with bootstrap-profiled

[hjl.tools at gmail dot com]

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

--- Comment #17 from H.J. Lu  2011-07-22 17:39:59 
UTC ---
It isn't fixed by 176630:

http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00897.html

See:

http://gcc.gnu.org/ml/gcc-regression/2011-07/msg00403.html

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

[longb at cray dot com]

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

Bill Long  changed:

   What|Removed |Added

 CC||longb at cray dot com

--- Comment #6 from Bill Long  2011-07-22 17:53:49 UTC 
---
Since most other compilers support ieee_arithmetic now, the lack of support in
gfortran is becoming a portability issue.  Simple test case with 4.6.1:

> cat t1.f90
program test
   use,intrinsic :: ieee_arithmetic

   real :: x
   read *, x
   if (ieee_is_nan(x)) then
  print *, "Nan"
   else
  print *, "Not NaN"
   end if
end program test
> gfortran t1.f90
t1.f90:2.35:

   use,intrinsic :: ieee_arithmetic
   1
Fatal Error: Can't find an intrinsic module named 'ieee_arithmetic' at (1)

[Bug debug/49815] [4.7 regression] ICE in cselib_record_set, at cselib.c:2241 compiling 64-bit libjava on SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  2011-07-22 
18:47:21 UTC ---
Author: ebotcazou
Date: Fri Jul 22 18:47:17 2011
New Revision: 176647

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176647
Log:
PR debug/49815
* var-tracking.c (vt_finalize): Always free windowed_parm_regs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c

[Bug debug/49815] [4.7 regression] ICE in cselib_record_set, at cselib.c:2241 compiling 64-bit libjava on SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #14 from Eric Botcazou  2011-07-22 
18:50:49 UTC ---
Thanks for reporting the problem.

[Bug c++/30112] pragma redefine_extname fails when namespaces are involved

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  2011-07-22 
19:59:51 UTC ---
Author: jason
Date: Fri Jul 22 19:59:49 2011
New Revision: 176650

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176650
Log:
PR c++/30112
gcc/c-family/
* c-common.h: Declare c_linkage_bindings.
* c-pragma.c (handle_pragma_redefine_extname): Use it.
gcc/
* c-decl.c (c_linkage_bindings): Define.
gcc/cp/
* decl.c (cp_finish_decl): Apply pragma redefine_extname in
other namespaces as well.
* name-lookup.c (c_linkage_bindings): Define.
(lookup_extern_c_fun_in_all_ns): Rename from
lookup_extern_c_fun_binding_in_all_ns.  Return tree.
(pushdecl_maybe_friend_1): Adjust.  Copy DECL_ASSEMBLER_NAME.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-decl.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/c-pragma.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/other/pragma-re-1.C

[Bug other/32998] -frecord-gcc-switches issues

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  2011-07-22 
20:03:35 UTC ---
Author: jakub
Date: Fri Jul 22 20:03:33 2011
New Revision: 176652

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176652
Log:
PR other/32998
* common.opt (grecord-gcc-switches, gno-record-gcc-switches): New
options.
* dwarf2out.c: Include opts.h.
(dchar_p): New typedef.  Define heap VEC for it.
(producer_string): New variable.
(gen_producer_string): New function.
(gen_compile_unit_die): Use it.
(dwarf2out_finish): Fix up comp_unit_die () DW_AT_producer
if needed.
* Makefile.in (dwarf2out.o): Depend on $(OPTS_H).
* doc/invoke.texi: Document -grecord-gcc-switches and
-gno-record-gcc-switches, add a -grecord-gcc-switches reference
to -frecord-gcc-switches description.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/common.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/dwarf2out.c

[Bug c++/30112] pragma redefine_extname fails when namespaces are involved

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  2011-07-22 
20:07:04 UTC ---
Fixed for 4.7.

[Bug c++/6709] [DR743] decltype cannot be used with the :: operator

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0

--- Comment #20 from Jason Merrill  2011-07-22 
21:24:35 UTC ---
Implemented for 4.7.

[Bug c++/49793] Narrowing conversion from int/short/char to double with -std=c++0x

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-07-22 
21:30:40 UTC ---
The compiler is, unfortunately, following the standard.  8.5.4/7: 

A narrowing conversion is an implicit conversion
...
* from an integer type or unscoped enumeration type to a floating-point type,
except where the source is a constant expression and the actual value after
conversion will fit into the target type and will produce the original value
when converted back to the original type, or 

With the consts, some of the local variables are usable in a constant
expression, so we can verify that their constant values are suitable.  But for
non-constant expressions we can't and have to give an error.

I think we should probably add a -Wno-narrowing flag and downgrade narrowing
complaints to pedwarn.

[Bug c++/49793] [C++0x] Narrowing conversion from int/short/char to double

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.22 21:46:10
Summary|Narrowing conversion from   |[C++0x] Narrowing
   |int/short/char to double|conversion from
   |with -std=c++0x |int/short/char to double
 Ever Confirmed|0   |1

--- Comment #3 from Paolo Carlini  2011-07-22 
21:46:10 UTC ---
Thanks Jason. I'm going to change this to NEW in terms of -Wno-narrowing etc.

[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L

[paolo.carlini at oracle dot com]

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

--- Comment #87 from Paolo Carlini  2011-07-22 
21:49:49 UTC ---
Now the pragma issue is solved. Good. I don't know Rainer if that means we can
do something, I'm afraid it surfaced only as one of the last stumbling blocks
in your analysis...

[Bug target/49817] New: libiberty/stack-limit.c causes a bootstrap failure on all FreeBSD targets

[gerald at pfeifer dot com]

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

   Summary: libiberty/stack-limit.c causes a bootstrap failure on
all FreeBSD targets
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ger...@pfeifer.com


...with the following failure mode:

/scratch/tmp/gerald/gcc-HEAD/libiberty/stack-limit.c: In function
'stack_limit_$
/scratch/tmp/gerald/gcc-HEAD/libiberty/stack-limit.c:49: error: 'uint64_t'
unde$

I have a patch for this which I am testing right now.

[Bug fortran/49708] [4.5/4.6/4.7 Regression] ICE with allocate and no dimensions

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org 2011-07-22 22:24:22 UTC ---
Author: janus
Date: Fri Jul 22 22:24:19 2011
New Revision: 176659

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176659
Log:
2011-07-23  Janus Weil  

PR fortran/49708
* resolve.c (resolve_allocate_expr): Fix diagnostics for pointers.


2011-07-23  Janus Weil  

PR fortran/49708
* gfortran.dg/allocate_error_3.f90: New.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/allocate_error_3.f90
Modified:
branches/gcc-4_6-branch/gcc/fortran/ChangeLog
branches/gcc-4_6-branch/gcc/fortran/resolve.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

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

--- Comment #12 from Tobias Burnus  2011-07-22 
22:44:24 UTC ---
Author: burnus
Date: Fri Jul 22 22:44:20 2011
New Revision: 176661

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176661
Log:
2011-07-23  Tobias Burnus  

PR fortran/49791
* io/list_read.c (nml_parse_qualifier): Remove check to
enabled extended read for another case.

2011-07-23  Tobias Burnus  

PR fortran/49791
* gfortran.dg/namelist_72.f: New.


Added:
trunk/gcc/testsuite/gfortran.dg/namelist_72.f
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c

[Bug target/49817] libiberty/stack-limit.c causes a bootstrap failure on all FreeBSD targets

[gerald at gcc dot gnu.org]

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

--- Comment #1 from gerald at gcc dot gnu.org  
2011-07-22 22:52:57 UTC ---
Author: gerald
Date: Fri Jul 22 22:52:55 2011
New Revision: 176662

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176662
Log:
PR target/49817
* stack-limit.c: Include .

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/stack-limit.c

[Bug libstdc++/49818] New: libsupc++ does not export __cxa_get_globals or related functions

[coppro at users dot sf.net]

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

   Summary: libsupc++ does not export __cxa_get_globals or related
functions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cop...@users.sf.net


Some functions, including __cxa_get_globals, are not exported properly by
libsupc++. This is contrary to the ABI, which requires these to be in cxxabi.h,
and makes it impossible to implement std::uncaught_exception() properly in a
different standard library on top of libsupc++. These functions are in
unwind-cxx.h, which are not in the public interface of the library.

[Bug target/49817] libiberty/stack-limit.c causes a bootstrap failure on all FreeBSD targets

[gerald at pfeifer dot com]

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

Gerald Pfeifer  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |gerald at pfeifer dot com
   |gnu.org |

--- Comment #2 from Gerald Pfeifer  2011-07-22 
22:59:03 UTC ---
Fix committed.

[Bug tree-optimization/48648] internal compiler error: in translate_clast, at graphite-clast-to-gimple.c:1123

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.22 23:07:37
 AssignedTo|unassigned at gcc dot   |spop at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #9 from Sebastian Pop  2011-07-22 23:07:37 
UTC ---
Patch
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02020.html

[Bug tree-optimization/48648] internal compiler error: in translate_clast, at graphite-clast-to-gimple.c:1123

[spop at gcc dot gnu.org]

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

--- Comment #10 from Sebastian Pop  2011-07-22 
23:11:14 UTC ---
*** Bug 49040 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/49040] ICE in translate_clast, at graphite-clast-to-gimple.c:1123

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #3 from Sebastian Pop  2011-07-22 23:11:14 
UTC ---
Duplicate: the only CLAST that could fall in that gcc_unreachable 
is clast_assignment.  The patch solving PR48648 should take care of this.

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

[Bug ada/49819] New: gcc/ada/gcc-interface/Makefile.in refers to g-trasym-dwarf.adb which does not exist

[ludo...@ludovic-brenta.org]

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

   Summary: gcc/ada/gcc-interface/Makefile.in refers to
g-trasym-dwarf.adb which does not exist
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ludo...@ludovic-brenta.org
Target: powerpc-linux-gnu


This patch, committed in Subversion as revision 165921:

2010-10-25  Jose Ruiz  

* gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS for powerpc-linux):
Reorganize target pairs so that it works on linux and ElinOS.

included this change:

--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -1790,31 +1790,15 @@ ifeq ($(strip $(filter-out powerpc% linux%,$(arch)
$(osys))),)
   s-intman.adbhttp://bugs.debian.org/635112]

[Bug c++/49793] [C++0x] Narrowing conversion from int/short/char to double

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  2011-07-23 
00:14:53 UTC ---
Author: jason
Date: Sat Jul 23 00:14:46 2011
New Revision: 176665

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176665
Log:
PR c++/49793
* typeck2.c (check_narrowing): Downgrade permerror to pedwarn.
Make conditional on -Wnarrowing.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/initlist17.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist36.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist5.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist52.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist7.C

[Bug middle-end/49806] [4.7 Regression] FAIL: gcc.dg/tree-ssa/vrp47.c

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #4 from John David Anglin  2011-07-23 
01:06:26 UTC ---
With revision 176606, I also see dom1 fail on hppa64-hp-hpux11.11:

FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times dom1 "x[^ ]* & y" 1
FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp1 "x[^ ]* \^ 1" 1

[Bug target/49817] libiberty/stack-limit.c causes a bootstrap failure on all FreeBSD targets

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2011-07-23 
06:29:00 UTC ---
Maybe you should report that to FreeBSD, because that is an obvious bug in
their headers.