[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[burnus at gcc dot gnu.org]

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

--- Comment #17 from Tobias Burnus  2010-11-16 
08:18:12 UTC ---
(In reply to comment #16)
>   ipn->offset = -1;
>   span.9 = 8;
> 
> I think we want ipn->span = 8;

While I am sure that we want to have ipn->span, I am not sure we can. My
understanding is that there is no space left in the array descriptor for
anything - not even for a sm(stride multiplier)/span. Thus, the main
implementation was deferred and an extra 'span' variable was introduced which
often but not always works.

If my understanding is correct, we can either try to extend the 'span' hack to
make it work for more cases - or we defer it to the array descriptor updated
and possibly error out when it is known that the hack does not work.

[Bug ada/46490] For four major i386 BSDs, GNAT fails FP to static integer conversion with -O2,-O3 optimization

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.16 08:22:33
 CC||ebotcazou at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1

--- Comment #4 from Eric Botcazou  2010-11-16 
08:22:33 UTC ---
There is a known issue for FreeBSD.  GNAT requires 64-bit precision on the x87
so it resets it in ada/init.c:__gnat_init_float.  This runs afoul of:

/* FreeBSD sets the rounding precision of the FPU to 53 bits.  Let the
   compiler get the contents of  and std::numeric_limits correct.  */
#undef TARGET_96_ROUND_53_LONG_DOUBLE
#define TARGET_96_ROUND_53_LONG_DOUBLE (!TARGET_64BIT)

in config/i386/freebsd.h so you'd need to force it to 0 unconditionally for
GNAT.


For the stack checking, you should try to define:

/* Static stack checking is supported by means of probes.  */
#define STACK_CHECK_STATIC_BUILTIN 1

like in config/i386/freebsd.h.

[Bug middle-end/46488] [4.5 regression] server/core_filters.c from apache httpd 2.2.17 miscompiled with optimization

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Target||sparc64-sun-solaris2.*
 CC||ebotcazou at gcc dot
   ||gnu.org
   Host||sparc64-sun-solaris2.*
   Target Milestone|--- |4.5.2
Summary|server/core_filters.c from  |[4.5 regression]
   |apache httpd 2.2.17 does|server/core_filters.c from
   |not produce good code with  |apache httpd 2.2.17
   |optimizations (-O) used on  |miscompiled with
   |Solaris Sparc 64-bit|optimization
  Build||sparc64-sun-solaris2.*

--- Comment #1 from Eric Botcazou  2010-11-16 
08:28:32 UTC ---
Any clue as to which function/which lines are miscompiled exactly?  Does it
work if you compile the file with -O -fno-delayed-branch?

[Bug libstdc++/46455] resource leaks due to missing destructors for mutexes and condvars

[internet at 123gen dot com]

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

--- Comment #17 from Zouzou  2010-11-16 08:37:02 
UTC ---
(In reply to comment #16)
> Created attachment 22413 [details]
> add destructors in 
> could you try applying this patch to ext/concurrence.h and let me know if it
> works on Windows?  I'm testing on Linux, FreeBSD and OpenBSD but they all use
> the pthreads model and I don't have a Windows system to test on.

hi,

the patch first produced a trivial compiler error:
In file included from
c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/memory:7
8:0,
 from test.cpp:15:
c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/ext/concurrence.h: In
destruct
or '__gnu_cxx::__recursive_mutex::~__recursive_mutex()':
c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/ext/concurrence.h:224:35:
erro
r: cannot convert '__gthread_recursive_mutex_t*' to '__gthread_mutex_t*' for
arg
ument '1' to 'void __gthread_mutex_destroy(__gthread_mutex_t*)'

i worked around it by making the pointer cast explicit in the __recursive_mutex
destructor:
__gthread_mutex_destroy(reinterpret_cast<__gthread_mutex_t*>(&_M_mutex));

it then compiles fine and correctly fixes the issue at hand.

[Bug fortran/46496] New: Missing strlen check / interop warnings with BIND(C) and non-C_* kinds

[burnus at gcc dot gnu.org]

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

   Summary: Missing strlen check / interop warnings with BIND(C)
and non-C_* kinds
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


(a) is a wording nit  (by Richard Main)
(b) be able to turn off the warning  (common request by Richard Main et al.)
(c) to (e) are warning inconsistencies (examples by James Van Buskirk)
(f) is a missing constraint check (examples by James Van Buskirk)


gfortran warns if one does not use
  kind=
where  is a constant defined in ISO_C_BINDING or a constant which has been
derived from it by direct assignment.

I think that's OK, however, many do not like it as one can see, e.g., at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/44d572766bce0e6f



a) The warning should use "dummy argument" and not the C-speak "parameter":

"Variable 'x' at (1) is a parameter to the BIND(C) procedure 'all_subs'
but may not be C interoperable" 


b) There should be some way to turn off this warning (and only this one) -
currently it is enabled by default and can only be turned of by "-w" which
silents all warnings.


c) One should consider allowing:
 KIND(variable/parameter with the bind-c-compatible kind)
   Currently, using such a kind parameter gives a warning, e.g. for

module mytypes
   use ISO_C_BINDING
   implicit none
   private
   public T
   type, bind(C) :: T
  character(len=1,kind=kind(C_CHAR_'A')) item ! kind=KIND(): Gives warning
   end type T
end module mytypes


d) The following should show a warning as one sets the LEN= and not the KIND=
parameter; the len=C_char is OK, but the kind=c_char is missing.

module mytypes
   use ISO_C_BINDING
   implicit none
   private
   public T
   type, bind(C) :: T
  character(C_CHAR) item  ! len=c_char: Warning is missing
   end type T
end module mytypes 


e) Ditto for:

module mytypes
   use ISO_C_BINDING
   implicit none
   private
   public T
   type, bind(C) :: T
  character*(C_CHAR), item
   end type T
end module mytypes 


f) The following two examples are invalid - but seemingly gfortran does not
check the string length of DT character components:

module mytypes
   use ISO_C_BINDING
   implicit none
   private
   public T
   type, bind(C) :: T
  character(len=2,kind=C_CHAR) item ! INVALID length: 2
   end type T
end module mytypes

module mytypes
   use ISO_C_BINDING
   implicit none
   private
   public T
   type, bind(C) :: T
  character(len=*,kind=C_CHAR) item*(2) ! INVALID length of 2
   end type T
end module mytypes

[Bug libstdc++/46455] resource leaks due to missing destructors for mutexes and condvars

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

--- Comment #18 from Jonathan Wakely  2010-11-16 
09:14:29 UTC ---
Thanks for testing it.  The cast makes me uncomfortable so I'll look into
adding a __gthread_recursive_mutex_destroy function...

[Bug tree-optimization/46493] [4.3/4.4 Regression] ICE: verify_flow_info failed when casting-out attribute noreturn

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.3.6

[Bug tree-optimization/46494] [4.3/4.4/4.5/4.6 Regression] ICE: verify_flow_info failed when casting-out attribute noreturn with -fno-tree-ccp -fno-tree-fre -ftree-vrp

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.3.6

[Bug libstdc++/46455] resource leaks due to missing destructors for mutexes and condvars

[paolo.carlini at oracle dot com]

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

--- Comment #19 from Paolo Carlini  2010-11-16 
10:25:40 UTC ---
Jon, sometimes finding a reviewer for those gthr changes takes a bit of time...
and we are already in Stage 3... Thus, I would recommend doing our best to
figure out first a decent library-only fix.

[Bug target/46483] Built-in memcpy() does not handle unaligned int for ARM

[mikpe at it dot uu.se]

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

--- Comment #8 from Mikael Pettersson  2010-11-16 
10:35:41 UTC ---
The misaligned __builtin_memcpy was fixed for 4.6 by r163189, Richard
Guenther's conservative alignment tracking (2nd try) patch:
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00831.html
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00400.html

[Bug ada/46490] For four major i386 BSDs, GNAT fails FP to static integer conversion with -O2,-O3 optimization

[gnugcc at marino dot st]

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

--- Comment #5 from John Marino  2010-11-16 10:35:54 
UTC ---
Hi Eric,
Thanks for you comment, but I don't think that is it for several reasons:

1) I am aware of both those quirks, and my codebase is patched with both of
those suggestions.

2) There's no problem with stack checking on FreeBSD i386.  There are no
failures whatsoever on either ACATS or gnat.dejagnu except for this particular
case of c460007.  NetBSD stack-checking doesn't work, but that's outside this
bug report.

3) The test passes with optimization level 0 or 1.  It fails with O2 and O3
settings.

4) There are no other rounding issues.  If TARGET_96_ROUND_53_LONG_DOUBLE is
not set correctly, multiple tests fail.

5) It's occurring identically on all four i386 platforms which are pretty
divergent.


This looks like a problem in the optimization stage.
The two test cases I provided are interesting as you can see the test will pass
if the EQUAL function is nested inside the main procedure rather than being
called as a separate package (also pointing to a problem in optimization I
would think.)

This warrants a closer look, it's not a configuration thing.
Thanks,
John

[Bug c++/46497] New: [C++0x] Defaulted vs declared move constructor vs is_convertible

[paolo.carlini at oracle dot com]

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

   Summary: [C++0x] Defaulted vs declared move constructor vs
is_convertible
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paolo.carl...@oracle.com


I'm seeing the strange behavior summarized below, which prevents me from
implementing as-is the bit of N3140 about the defaulted move constructor.



#include 

template
  struct pair
  {
_T1 first;

pair(const pair&) = default;
pair(pair&&) = default;  // The static_assert triggers.
// pair(pair&&); // Works! 

template
  pair(pair<_U1>&&) { }
  };

struct move_only
{
  move_only(move_only&&) = default;
};

template
  class map
  {
static_assert(std::is_convertible,
  pair>::value, "");
  };

map m;

[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #13 from Jakub Jelinek  2010-11-16 
10:54:36 UTC ---
Even if we add code to hardcode EDOM value for Linux targets and teach gcc that
errno is *__errno_location (), the first sqrtf could still be rounded to float
precision (because there is an optional __errno_location () call after it and
according to the ABI it might clobber %st(0)) while the remaining two could
very well be kept in extended precision and just rounded down to double
precision for varargs passing.

So I'm afraid there is nothing we can do about this in GCC and there is no GCC
bug, but simply the unpredictability of excess precision arithmetics.

Use -ffloat-store/-fexcess-precision=standard/volatile float to ensure it works
as expected if you care about it.

[Bug c++/46497] [C++0x] Defaulted vs declared move constructor vs is_convertible

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  2010-11-16 
10:56:07 UTC ---
And for the record what I'm doing for the time being in the actual std::pair
is:

  // XXX FIXME: should be defaulted per N3140. See c++/46497.
  pair(pair&& __p)
  : first(std::forward(__p.first)),
second(std::forward(__p.second)) { }

which works fine together with the rest of the C++0x features.

[Bug libstdc++/46455] resource leaks due to missing destructors for mutexes and condvars

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely  2010-11-16 
11:05:44 UTC ---
OK, that will be ugly though.  The cast from __gthread_recursive_mutex_t* to
__gthread_mutex_t* is not correct, because the "sema" member (the actual Win32
handle) is at a different offset in the two mutex types.

We want something like:

static inline int
__recursive_mutex_destroy(__gthread_recursive_mutex_t* __rmutex)
{
#ifdef _WIN32
  __gthread_mutex_t __tmp = { };
  __tmp.counter = __rmutex->counter;
  __tmp.sema = __rmutex->sema;
  __ghtread_mutex_t* __mutex = &__tmp;
#else
  __ghtread_mutex_t* __mutex = __rmutex;
#endif
  return ___gthread_mutex_destroy(__mutex);
}

[Bug ada/46490] ACATS cb460007 fails at -O2 or above

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target|FreeBSD, OpenBSD, NetBSD,   |i386-*-*
   |DragonFlyBSD: i386  |
   Host|Same as Target  |
Summary|For four major i386 BSDs,   |ACATS cb460007 fails at -O2
   |GNAT fails FP to static |or above
   |integer conversion with |
   |-O2,-O3 optimization|
  Build|Same as Target  |

--- Comment #6 from Eric Botcazou  2010-11-16 
11:16:40 UTC ---
> 5) It's occurring identically on all four i386 platforms which are pretty
> divergent.
> 
> This looks like a problem in the optimization stage.

OK, the summary is slightly misleading then, if this has nothing to do with
BSD.

Do you know if this fails with earlier versions?  Let me try on Linux.

[Bug ada/46490] ACATS cb460007 fails at -O2 or above

[gnugcc at marino dot st]

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

--- Comment #7 from John Marino  2010-11-16 11:25:31 
UTC ---
Eric, 
Actually I believe it is limited to the BSDs, although I can't explain why.  I
also ported GNAT to x86 OpenSolaris (SXCE 130) and that one passed all ACATS.  
I also have not seen this failure on any of the Linux testsuite reports for
4.6.0.

This error may have also been present in the 4.5.0 branch, but there were
several other failures back then so I wasn't paying particular attention to it
at the time.

FYI, here are recent test reports if you find this helpful:

DragonFly32 : http://www.dragonlace.net/gnataux/dragonfly32/
FreeBSD32   : http://www.dragonlace.net/gnataux/freebsd32/
OpenBSD32   : http://www.dragonlace.net/gnataux/openbsd32/
NetBSD32: http://www.dragonlace.net/gnataux/netbsd32/

Also, remember x86_64 works fine, there is no issue with -O2,-O3 with this test
on that architecture.

[Bug middle-end/45172] [4.6 Regression] internal compiler error: verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #10 from Richard Guenther  2010-11-16 
11:43:07 UTC ---
Fixed.

[Bug middle-end/45172] [4.6 Regression] internal compiler error: verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Guenther  2010-11-16 
11:42:53 UTC ---
Author: rguenth
Date: Tue Nov 16 11:42:50 2010
New Revision: 166794

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

PR middle-end/45172
* tree-eh.c (cleanup_empty_eh_unsplit): Avoid creating duplicate
edges.

* gfortran.dg/gomp/pr45172.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr45172.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-eh.c

[Bug ada/46490] ACATS c460007 fails at -O2 or above

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Botcazou  2010-11-16 
11:46:51 UTC ---
> Actually I believe it is limited to the BSDs, although I can't explain why.

You need -mtune=i386 to reproduce on Linux for example.

> FYI, here are recent test reports if you find this helpful:
> 
> DragonFly32 : http://www.dragonlace.net/gnataux/dragonfly32/
> FreeBSD32   : http://www.dragonlace.net/gnataux/freebsd32/
> OpenBSD32   : http://www.dragonlace.net/gnataux/openbsd32/
> NetBSD32: http://www.dragonlace.net/gnataux/netbsd32/

Thanks.  If the OpenBSD port is SJLJ, you can add an XFAIL for *-*-openbsd* to
gnat.dg/test_raise_from_pure.adb.

[Bug tree-optimization/44545] [4.5/4.6 regression] internal compiler error: in remove_unreachable_handlers, at tree-eh

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Guenther  2010-11-16 
11:48:10 UTC ---
Can't reproduce it on current trunk.  Looking at it on the branch.

[Bug libstdc++/46455] resource leaks due to missing destructors for mutexes and condvars

[paolo.carlini at oracle dot com]

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

--- Comment #21 from Paolo Carlini  2010-11-16 
11:52:20 UTC ---
Argh, I see. I think we should keep the option open, anyway, together with a
huge FIXME in the code, of course. I also think we should try to explain the
problem to the people actually maintaining the gthr stuff: if we can convince
those people that the change is localized and at the library-level we can only
do very ugly things, maybe we can win...

[Bug tree-optimization/44545] [4.5/4.6 regression] internal compiler error: in remove_unreachable_handlers, at tree-eh

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  2010-11-16 
12:06:42 UTC ---
> Can't reproduce it on current trunk.  Looking at it on the branch.

Try -fstack-check=generic on the trunk.

[Bug tree-optimization/44545] [4.5 Regression] internal compiler error: in remove_unreachable_handlers, at tree-eh

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Known to work||4.6.0
 Depends on||45232
Summary|[4.5/4.6 regression]|[4.5 Regression] internal
   |internal compiler error: in |compiler error: in
   |remove_unreachable_handlers |remove_unreachable_handlers
   |, at tree-eh|, at tree-eh

--- Comment #9 from Richard Guenther  2010-11-16 
12:13:12 UTC ---
The fix for PR45232 fixed it on the trunk.

[Bug middle-end/45838] [4.6 Regression] FAIL: libgomp.c/pr34513.c execution test

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

--- Comment #8 from Jakub Jelinek  2010-11-16 
12:13:53 UTC ---
Ah, hppa uses GOMP_atomic_{start,end}, and the leaf attribute makes fre think
it is ok to cache static var values for non-addressable vars across calls.  In
OpenMP, as they can be accessed by multiple threads, they can't be cached
across barrier points.  So I'll jus remove the leaf attribute from most of the
GOMP builtins that are barriers (and conservatively the starts too).  I've left
out just the omp_* functions and *_nowait.

[Bug middle-end/45838] [4.6 Regression] FAIL: libgomp.c/pr34513.c execution test

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2010-11-16 
12:16:52 UTC ---
Created attachment 22419
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22419
gcc46-pr45838.patch

Untested fix.

[Bug target/46483] Built-in memcpy() does not handle unaligned int for ARM

[mikpe at it dot uu.se]

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

--- Comment #9 from Mikael Pettersson  2010-11-16 
12:21:20 UTC ---
With gcc-4.5.1, the plain assignment is preserved until 141r.expand, which
expands it to a bitfield assignment due to the misalignment check in
expr.c:store_field lines 5836-5840.

The __builtin_memcpy is turned into a plain indirect assignment in 004t.gimple:

set_by_memcpy (struct unaligned_int * p, unsigned int x)
{
  unsigned int * D.2026;
  unsigned int * {ref-all} D.2027;
  unsigned int x.0;

  D.2026 = &p->number;
  D.2027 = (unsigned int * {ref-all}) D.2026;
  x.0 = x;
  *D.2027 = x.0;
}

and this misaligned assignment is never corrected by later passes.

[Bug libstdc++/46455] resource leaks due to missing destructors for mutexes and condvars

[redi at gcc dot gnu.org]

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

--- Comment #22 from Jonathan Wakely  2010-11-16 
12:32:36 UTC ---
... and when using gthr-mipssde.h / gthr-posix95.h / gthr-solaris.h:

static inline int
__recursive_mutex_destroy(__gthread_recursive_mutex_t* __rmutex)
{
  return ___gthread_mutex_destroy(__mutex->actual);
}

Adding the right preprocessor checks to the library will be messy, because
configure might have made gthr-default.h a symlink to one of the headers above
and we don't have a macro to test.  The right place for the destroy function is
in the gthr headers where __gthread_recursive_mutex_t is defined.

Hmm, I wonder if we could use sfinae, there are three cases:
- recursive mutex is the same type as the non-recursive mutex, or
- it has an "actual" member, or
- it has a "sema" member.

I'll try that this evening.

[Bug middle-end/45838] [4.6 Regression] FAIL: libgomp.c/pr34513.c execution test

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #22419|0   |1
is obsolete||

--- Comment #10 from Jakub Jelinek  2010-11-16 
12:47:31 UTC ---
Created attachment 22420
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22420
gcc46-pr45838.patch

Actually, that's just too conservative, the *start function except
*parallel*start* and single_copy_start aren't barriers of any kind nor can call
functions from the current TU, so those should be okay.

[Bug target/46483] Built-in memcpy() does not handle unaligned int for ARM

[mikpe at it dot uu.se]

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

--- Comment #10 from Mikael Pettersson  2010-11-16 
13:08:53 UTC ---
The test cases also fail with gcc-4.5.1 on sparc64-linux.  On that platform
alignment errors are fatal and the program dies with a SIGBUS on the misaligned
int-sized write generated for the __builtin_memcpy.

[Bug bootstrap/46086] fail to build gcc 4.5.2 on sparc64-portbld-freebsd9.0 - configure: error: cannot compute suffix of object files: cannot compile

[mexas at bristol dot ac.uk]

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

--- Comment #7 from Anton Shterenlikht  2010-11-16 
13:18:39 UTC ---
As it is hard to downgrade the port versions (it might break port
interdependency), I tried instead to use a more recent gcc to build
the ports in question and gcc45 itself.

I rebuilt gmp-5.0.1, mpfr-3.0.0 and binutils-2.20.1_3 with gcc 4.4.6 20101026.

I'm now trying to build gcc45 also with gcc 4.4.6 20101026, instead of the
system default 4.2.1 20070719.

I now get stopped here:

gmake[3]: Leaving directory
`/usr/ports/lang/gcc45/work/build/sparc64-portbld-freebsd9.0/libgcc'
Checking multilib configuration for libgomp...
Configuring stage 1 in sparc64-portbld-freebsd9.0/libgomp
configure: loading cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for --enable-generated-files-in-srcdir... no
checking build system type... sparc64-portbld-freebsd9.0
checking host system type... sparc64-portbld-freebsd9.0
checking target system type... sparc64-portbld-freebsd9.0
checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p...
../.././../gcc-4.5-2010/libgomp/../install-sh -c -d
checking for gawk... nawk
checking whether gmake sets $(MAKE)... yes
checking for sparc64-portbld-freebsd9.0-gcc...
/usr/ports/lang/gcc45/work/build/./gcc/xgcc
-B/usr/ports/lang/gcc45/work/build/./gcc/
-B/usr/local/sparc64-portbld-freebsd9.0/bin/
-B/usr/local/sparc64-portbld-freebsd9.0/lib/ -isystem
/usr/local/sparc64-portbld-freebsd9.0/include -isystem
/usr/local/sparc64-portbld-freebsd9.0/sys-include   
checking for C compiler default output file name... 
configure: error: in
`/usr/ports/lang/gcc45/work/build/sparc64-portbld-freebsd9.0/libgomp':
configure: error: C compiler cannot create executables
See `config.log' for more details.
gmake[2]: *** [configure-stage1-target-libgomp] Error 77
gmake[2]: Leaving directory `/usr/ports/lang/gcc45/work/build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/usr/ports/lang/gcc45/work/build'
gmake: *** [bootstrap-lean] Error 2
*** Error code 1

[Bug target/46040] crtstuff.c:308:26: error: '__DTOR_LIST__' undeclared

[laurent at guerby dot net]

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

Laurent GUERBY  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.16 13:36:34
 CC||laurent at guerby dot net
 Ever Confirmed|0   |1

--- Comment #4 from Laurent GUERBY  2010-11-16 
13:36:34 UTC ---
Any reason why this patch isn't submitted/commited? 

I still get the __DTOR_LIST__ error as of today on arm-linux without the patch.
With the patch bootstrap succeeds.

[Bug middle-end/45838] [4.6 Regression] FAIL: libgomp.c/pr34513.c execution test

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2010-11-16 
13:37:28 UTC ---
Created attachment 22421
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22421
gcc46-pr45838.patch

Another, alternate, untested fix.

[Bug bootstrap/46086] fail to build gcc 4.5.2 on sparc64-portbld-freebsd9.0 - configure: error: cannot compute suffix of object files: cannot compile

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  2010-11-16 
13:38:21 UTC ---
(In reply to comment #7)
> configure: error: in
> `/usr/ports/lang/gcc45/work/build/sparc64-portbld-freebsd9.0/libgomp':
> configure: error: C compiler cannot create executables
> See `config.log' for more details.

Why do people always ignore this line?

At a guess, I'd say you don't have the prerequisites installed in a system dir,
or haven't re-run ldconfig, so the dynamic linker can't find the libs, in which
case try setting LD_LIBRARY_PATH

[Bug target/46483] Built-in memcpy() does not handle unaligned int for ARM

[mikpe at it dot uu.se]

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

--- Comment #11 from Mikael Pettersson  2010-11-16 
13:40:32 UTC ---
The test cases work with gcc-4.3.5.  For arm it generates the following for the
__builtin_memcpy case:

set_by_memcpy:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
str lr, [sp, #-4]!
sub sp, sp, #12
add r3, sp, #8
str r1, [r3, #-4]!
mov r1, r3
mov r2, #4
add r0, r0, #1
bl  memcpy
add sp, sp, #12
ldmfd   sp!, {pc}

and for sparc it generates:

set_by_memcpy:
st  %o1, [%sp+72]
ldub[%sp+72], %g1
add %sp, 72, %g3
stb %g1, [%o0+1]
ldub[%g3+3], %g1
add %o0, 1, %o0
stb %g1, [%o0+3]
ldub[%g3+1], %g2
stb %g2, [%o0+1]
ldub[%g3+2], %g1
jmp %o7+8
 stb%g1, [%o0+2]

[Bug bootstrap/46086] fail to build gcc 4.5.2 on sparc64-portbld-freebsd9.0 - configure: error: cannot compute suffix of object files: cannot compile

[mexas at bristol dot ac.uk]

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

--- Comment #9 from Anton Shterenlikht  2010-11-16 
13:44:48 UTC ---
Created attachment 22422
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22422
config.log showing configure errors

[Bug bootstrap/46086] fail to build gcc 4.5.2 on sparc64-portbld-freebsd9.0 - configure: error: cannot compute suffix of object files: cannot compile

[mexas at bristol dot ac.uk]

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

--- Comment #10 from Anton Shterenlikht  2010-11-16 
13:46:30 UTC ---
here's the relevant bit, I guess:

configure:3658: checking for C compiler default output file name
configure:3680: /usr/ports/lang/gcc45/work/build/./gcc/xgcc
-B/usr/ports/lang/gcc45/work/build/./gcc
/ -B/usr/local/sparc64-portbld-freebsd9.0/bin/
-B/usr/local/sparc64-portbld-freebsd9.0/lib/ -isystem
 /usr/local/sparc64-portbld-freebsd9.0/include -isystem
/usr/local/sparc64-portbld-freebsd9.0/sys-in
clude-g -O2 -pipe -I/usr/local/include -fno-strict-aliasing   conftest.c 
>&5
xgcc: Internal error: Segmentation fault: 11 (program cc1)
Please submit a full bug report.
See  for instructions.
configure:3684: $? = 1
configure:3721: result:
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU OpenMP Runtime Library"
| #define PACKAGE_TARNAME "libgomp"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU OpenMP Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgomp/";
| #define PACKAGE "libgomp"
| #define VERSION "1.0"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3727: error: in
`/usr/ports/lang/gcc45/work/build/sparc64-portbld-freebsd9.0/libgomp':
configure:3731: error: C compiler cannot create executables

[Bug fortran/46487] allocatable scalars leak memory (allocatable_scalar_5.f90)

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2010-11-16 
13:49:58 UTC ---
Well, the problem is actually simple:

program test
  implicit none
  integer :: b
  b = func()
contains
  function func ()
integer, allocatable ::  func
allocate(func)
func = 5332
  end function func
end program test

The function "func" returns the allocatable scalar as:
  return __result_func;

In the main program, one has:
  b = *func ();
or - if "b" is allocatable:
  *b = *func ()

However, the proper method should be:
  {
 tmp = func()
 b = *tmp
 free (tmp);
  }

(Or replace: "free (tmp)" by "if (tmp != NULL) free(tmp)", which is identical
as free also accepts NULL.)

For arrays, it currently works without this detour as there the argument is
passed by value; doing likewise for allocatable scalars would be one -- ABI
breaking -- alternative.

[Bug tree-optimization/44545] [4.5 Regression] internal compiler error: in remove_unreachable_handlers, at tree-eh

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Guenther  2010-11-16 
13:53:53 UTC ---
Author: rguenth
Date: Tue Nov 16 13:53:50 2010
New Revision: 166796

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

PR tree-optimization/44545
* tree-ssa-reassoc.c (linearize_expr_tree): Possibly throwing
statements are not reassociatable.
(reassociate_bb): Likewise.

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

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr44545.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/tree-ssa-reassoc.c

[Bug rtl-optimization/46366] gcc.target/i386/pr45352-2.c failed

[abel at gcc dot gnu.org]

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

--- Comment #4 from Andrey Belevantsev  2010-11-16 
14:11:47 UTC ---
Author: abel
Date: Tue Nov 16 14:11:39 2010
New Revision: 166798

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166798
Log:
PR rtl-optimization/46366
* gcc.target/i386/pr45352-2.c: Silence warnings by using appropriate
casts.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr45352-2.c

[Bug tree-optimization/44545] [4.5 Regression] internal compiler error: in remove_unreachable_handlers, at tree-eh

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Guenther  2010-11-16 
14:15:59 UTC ---
Author: rguenth
Date: Tue Nov 16 14:15:55 2010
New Revision: 166799

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

PR tree-optimization/44545
* tree-ssa-reassoc.c (linearize_expr_tree): Possibly throwing
statements are not reassociatable.
(reassociate_bb): Likewise.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr44545.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug tree-optimization/44545] [4.5 Regression] internal compiler error: in remove_unreachable_handlers, at tree-eh

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #12 from Richard Guenther  2010-11-16 
14:17:33 UTC ---
Fixed.

[Bug tree-optimization/23286] missed fully redundant expression

[rguenth at gcc dot gnu.org]

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

--- Comment #31 from Richard Guenther  2010-11-16 
14:39:50 UTC ---
(In reply to comment #29)
> I intended to work on this for GCC 4.6.  There are many vectorizer failures
> with the v3 patch. My local copy of the patch is at v6 :-)  I'll see if I can
> make some time to "forward-port" the differences between my v3 and v6 to
> Richi's updated patch.

I don't remember if you did send me your v6 privately (I at least can't find
it),
can you simply dump your most current variant here?

Thx.

[Bug fortran/45129] I/O edit descriptors: Warn if the format field is too small for the E and F edit descriptor

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2010-11-16 
14:44:56 UTC ---
The question is whether the warning should be only printed if the problem
definitely occurs or only if it likely

  WRITE (*,'(f12.10)') 1.e0 ! prints 1.00
  WRITE (*,'(f12.10)') 1.e1 ! prints 

In this case, ifort prints with "-stand f03":
  The field width is too small for the number of fractional digits.

[Bug other/46332] __cxa_demangle yields excess parentheses for function types

[ian at airs dot com]

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

--- Comment #17 from Ian Lance Taylor  2010-11-16 14:51:44 
UTC ---
I have added this patch to the binutils 2.21 release branch, so it will be in
the GNU binutils 2.21 release.

[Bug tree-optimization/46498] New: [4.5/4.6 Regression] ICE: in eliminate_unnecessary_stmts, at tree-ssa-dce.c:1112 with -O -funsafe-math-optimizations -fno-tree-dominator-opts -fno-tree-reassoc

[zsojka at seznam dot cz]

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

   Summary: [4.5/4.6 Regression] ICE: in
eliminate_unnecessary_stmts, at tree-ssa-dce.c:1112
with -O -funsafe-math-optimizations
-fno-tree-dominator-opts -fno-tree-reassoc
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


- testcase.c -
void foo (double d) {}
--

Compiler output:
$ gcc -O -funsafe-math-optimizations -fno-tree-dominator-opts -fno-tree-reassoc
testcase.c
testcase.c: In function 'foo':
testcase.c:1:6: internal compiler error: in eliminate_unnecessary_stmts, at
tree-ssa-dce.c:1181
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r166795 - crash
r153685 - crash
4.5 r166509 - crash
4.4 r166509 - OK

[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin

[davek at gcc dot gnu.org]

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

Dave Korn  changed:

   What|Removed |Added

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

--- Comment #18 from Dave Korn  2010-11-16 15:03:21 
UTC ---
Testing went well, submitting the patch shortly.

[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment

[paul.richard.thomas at gmail dot com]

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

--- Comment #18 from paul.richard.thomas at gmail dot com  2010-11-16 15:04:39 UTC ---
Dear Tobias,


> If my understanding is correct, we can either try to extend the 'span' hack to
> make it work for more cases - or we defer it to the array descriptor updated
> and possibly error out when it is known that the hack does not work.

Your understanding is correct.  The case at point here should be
easily fixed.  It is a question of getting the span right by obtaining
the element size of the array. ie. you need to go through the
references until a REF_ARRAY is found and to take theelement size of
that array.

Passing these beasts to pointer formal arguments is a tad awkward.
The only way that I know to extend the current mechanism is to pass
'span' variable in the same way as character variables; only when the
formal argument is a pointer, however.  This would mean that all dummy
pointers would have to have a 'span' associated with them.

Note that we could do array descriptor reform in two steps; first add
all the extra fields and then, possibly, change the dimension
structure.  I say possibly about the latter because I am not convinced
that it is necessary and my first attempts this summer indicated what
a hard job it will be. We could get an SoC student going on it?

Cheers

Paul

[Bug c++/46304] [4.5 Regression] g++ crashes with ICE in bitmap_first_set_bit, at bitmap.c:770

[apataki at apataki dot net]

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

--- Comment #8 from Andras Pataki  2010-11-16 
15:11:04 UTC ---
I can confirm that my test case now compiles and runs correctly with the
20101113 snapshot of the 4.6 compiler.

However, I've noticed another strangeness relating to complex numbers.  Both
the 4.5.x and the 4.6 snapshot do not treat complex constants quite the way I'd
expect:

#include 

class A
{
static const complex double x = 1.0 + 2.0i;
};


4.5.1 says:
z9.cc:5:41: error: ‘A::x’ cannot be initialized by a non-constant expression
when being declared

4.6-20101113 says:
z9.cc:5:40: error: field initializer is not constant

but 4.4.5 compiles it without complaints.
This is the same even if I use the notation 1.0 + 2.0*I for the constant.

Andras

[Bug c++/46497] [C++0x] Defaulted vs declared move constructor vs is_convertible

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.16 15:13:01
 Ever Confirmed|0   |1

--- Comment #2 from Jason Merrill  2010-11-16 
15:13:01 UTC ---
Reduced:


template
  struct A
  {
T first;

A(const A&) = default;
A(A&&) = default;

template
A(A<_U1>&&);
  };

struct move_only
{
  move_only(move_only&&) = default;
};

A&& f();
void g(A);

template
static decltype(g(f())) h();

int main()
{
  g(f());
  h();
}

There seems to be a problem with non-dependent types in templates; the plain
call to g(f()) works fine, but the call in the decltype fails.

[Bug tree-optimization/46499] New: gcc.c-torture/execute/20051021-1.c FAILs with -fno-tree-dominator-opts -fno-tree-ccp

[zsojka at seznam dot cz]

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

   Summary: gcc.c-torture/execute/20051021-1.c FAILs with
-fno-tree-dominator-opts -fno-tree-ccp
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Command line:
$ gcc -O -fno-omit-frame-pointer -fno-tree-ccp -fno-tree-dominator-opts
-finline-small-functions 20051021-1.i
$ ./a.out
Segmentation fault

In the assembly output, there seems to be missing end of main():
00400508 :
  400508:   55  push   %rbp
  400509:   48 89 e5mov%rsp,%rbp
  40050c:   83 05 15 0b 20 00 02addl   $0x2,0x200b15(%rip)#
601028 
  400513:   90  nop
 nop nop nop ...

Tested revisions:
r166763 - fail
4.5 r166509 - fail
4.4 r166509 - OK

[Bug tree-optimization/46499] gcc.c-torture/execute/20051021-1.c FAILs with -fno-tree-dominator-opts -fno-tree-ccp

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  2010-11-16 15:45:09 
UTC ---
Created attachment 22423
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22423
testcase causing RTL check ICE

While reducing the testcase, I got to this, which crashes with RTL checking:

$ gcc -O -fno-tree-ccp -fno-tree-dominator-opts pr46499.c 
pr46499.c: In function 'main':
pr46499.c:14:1: internal compiler error: RTL check: expected elt 3 type 'B',
have '0' (rtx barrier) in rtl_verify_flow_info_1, at cfgrtl.c:1846
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/46498] [4.5/4.6 Regression] ICE: in eliminate_unnecessary_stmts, at tree-ssa-dce.c:1112 with -O -funsafe-math-optimizations -fno-tree-dominator-opts -fno-tree-reassoc

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.16 15:59:26
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.5.2
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2010-11-16 
15:59:26 UTC ---
Mine.

[Bug tree-optimization/46499] [4.5/4.6 Regression] gcc.c-torture/execute/20051021-1.c FAILs with -fno-tree-dominator-opts -fno-tree-ccp

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.16 16:02:49
   Target Milestone|--- |4.5.2
Summary|gcc.c-torture/execute/20051 |[4.5/4.6 Regression]
   |021-1.c FAILs with  |gcc.c-torture/execute/20051
   |-fno-tree-dominator-opts|021-1.c FAILs with
   |-fno-tree-ccp   |-fno-tree-dominator-opts
   ||-fno-tree-ccp
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2010-11-16 
16:02:49 UTC ---
Confirmed.

[Bug middle-end/46500] New: target.h includes tm.h

[amylaar at gcc dot gnu.org]

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

   Summary: target.h includes tm.h
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
Blocks: 46489


Because some hooks are defined in terms of CUMULATIVE_ARGS, target.h includes
tm.h .  That defeats the purpose of the target hooks.

[Bug target/44762] score/predicates.md warnings

[amylaar at gcc dot gnu.org]

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

--- Comment #2 from Jorn Wolfgang Rennecke  
2010-11-16 16:12:19 UTC ---
Author: amylaar
Date: Tue Nov 16 16:12:14 2010
New Revision: 166807

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166807
Log:
PR target/44762
* config/score/score3.c (score3_return_in_memory): Constify arguments.
(score3_in_small_data_p, score3_function_value): Likewise.
(score3_trampoline_init): Use LCT_NORMAL.
(score3_print_operand): Initialize code as UNKNOWN.
* config/score/predicates.md (score_load_multiple_operation):
Remove unused variable.
(score_store_multiple_operation): Likewise.
* config/score/score7.c (score7_return_in_memory): Constify arguments.
(score7_in_small_data_p, score7_function_value): Likewise.
(score7_trampoline_init): Use LCT_NORMAL.
(score7_print_operand): Initialize code as UNKNOWN.
* config/score/score3.h (score3_return_in_memory): Update prototype.
(score3_in_small_data_p, score3_function_value): Likewise.
* config/score/score-protos.h (score_function_value): Likewise.
* config/score/score7.h (score7_return_in_memory): Update prototype.
(score7_in_small_data_p, score7_function_value): Likewise.
* config/score/score.c (TARGET_PROMOTE_PROTOTYPES): Constify.
(score_return_in_memory, score_pass_by_reference): Constify arguments.
(score_output_mi_thunk, score_function_prologue): Don't return a value.
(score_function_epilogue, score_in_small_data_p): Likewise.
(score_option_override, score_asm_trampoline_template): Likewise.
(score_trampoline_init, score_print_operand): Likewise.
(score_print_operand_address, score_prologue): Likewise.
(score_epilogue, score_call, score_call_value): Likewise.
(score_movsicc, score_movdi, score_zero_extract_andi): Likewise.
(score_function_arg_advance): Likewise. Make static.
(score_asm_file_end): Mark parameter value with ATTRIBUTE_UNUSED.
(score_function_arg, score_legitimate_address_p): Make static.
(score_function_value): Mark parameter func with ATTRIBUTE_UNUSED.
* config/score/score.h (REGNO_REG_CLASS): Cast value to enum reg_class.
* config/score/score-conv.h (UIMM_IN_RANGE, SIMM_IN_RANGE):
Allow (W) == HOST_BITS_PER_WIDE_INT.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/score/predicates.md
trunk/gcc/config/score/score-conv.h
trunk/gcc/config/score/score-protos.h
trunk/gcc/config/score/score.c
trunk/gcc/config/score/score.h
trunk/gcc/config/score/score3.c
trunk/gcc/config/score/score3.h
trunk/gcc/config/score/score7.c
trunk/gcc/config/score/score7.h

[Bug driver/46501] New: Relocatable toolchains still search --prefix

[nightstrike at gmail dot com]

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

   Summary: Relocatable toolchains still search --prefix
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nightstr...@gmail.com


See related bugs:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300

Creating a relocatable toolchain allows a person to build a toolchain, install
it anywhere, and then move that toolchain to any location and still have the
various compilers find all of their pieces.

This doesn't always work, however.

The value of --prefix passed to configure winds up making its way into the
search paths, which has been causing some weird issues.  We do this by setting
prefix equal to with-sysroot, which is a legal way of building a relocatable
toolchain.  Doing so, however, forces gcc to look in relative paths outside of
the directory tree where gcc resides.

Initially, we were compiling on windows hosts with a prefix set to G:\.  This
resulted in unusual error messages when that toolchain was used on machines
with drive G: set to a removable disk drive with nothing in it.  We solved that
by just not using a G:\ prefix, and instead mounting that partition in the C:\
hierarchy (since C:\ is pretty much guaranteed to exist on a Windows platform).

The issue reared its head again when a user tried moving one of our cross
compilers into /usr.  We use the moniker "root" for the top level of the
installation prefix (for instance, ../configure --prefix=something/root).  This
then caused gcc to look in /usr/bin/../../root for its additional programs. 
That directory usually exists on linux systems, and it's usually only
accessible by the root user.  That causes obvious problems, with a kludgey
workaround being to just move the toolchain to /usr/local.

And yes, that works.  But it masks the actual problem, which is that gcc should
not be looking at anything outside of its own directory structure when compiled
in "relocatable" mode.

[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin

[davek at gcc dot gnu.org]

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

Dave Korn  changed:

   What|Removed |Added

   Keywords||patch
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2010-11/msg01688.htm
   ||l

--- Comment #19 from Dave Korn  2010-11-16 16:19:39 
UTC ---
Posted.

[Bug lto/46502] New: collect2 LTO marker detection is fragile wrt. to nm output format

[ro at gcc dot gnu.org]

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

   Summary: collect2 LTO marker detection is fragile wrt. to nm
output format
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


When investigating why some users of GCC mainline on Solaris 2 saw more
LTO-related testsuite failures than I, it turned out that collect2 calls some
version of nm to search the object's symbol tables for __gnu_lto_v1.
Unfortunately, this relies on the output format produced by GNU nm -n, and
silently fails if the format is different (i.e. the LTO markers aren't found
and lto1 isn't called).  I noticed this change between Solaris 10 (where I had
no instance of GNU nm in PATH, neither as nm nor as gnm) and Solaris 11 (where
there's /usr/bin/gnm in the default PATH).

This is very fragile, hard to find, and the requirement isn't even documented.

[Bug lto/46503] New: collect2's search for nm makes LTO support fragile

[ro at gcc dot gnu.org]

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

   Summary: collect2's search for nm makes LTO support fragile
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
Depends on: 46502


I've noticed that unlike the way as and ld are handled (where the versions used
at configure time are hard-coded), collect2 does a runtime search for a version
of nm to use.  This makes LTO support quite fragile, causing LTO not to work
depending on the users' PATH.

This is related to PR lto/46502, where collect2 can only cope with GNU nm -n
output format.  I've seen that if GNU nm happens to be in PATH, LTO works since
LTO markers are found in the object files, while it fails with Solaris nm -n, 
which produces a completely different output format by default.

[Bug middle-end/46488] [4.5 regression] server/core_filters.c from apache httpd 2.2.17 miscompiled with optimization

[lk0946 at att dot com]

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

--- Comment #2 from Lance Kinley  2010-11-16 16:37:20 
UTC ---
Adding -fno-delayed-branch does not resolve the issue.

I don't know which function is the culprit.  I'll try to dig into it more.

[Bug middle-end/46488] [4.5 regression] server/core_filters.c from apache httpd 2.2.17 miscompiled with optimization

[lk0946 at att dot com]

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

--- Comment #3 from Lance Kinley  2010-11-16 16:48:11 
UTC ---
My apologies, -O -fno-delayed-branch does fix it.

-O3 -fno-delayed-branch does not work, however.

[Bug target/46470] "add $0x8,%rsp" no longer optimized to pop

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.16 16:55:44
 AssignedTo|unassigned at gcc dot   |rth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Richard Henderson  2010-11-16 
16:55:44 UTC ---
Mine.

[Bug rtl-optimization/46490] [4.6 regression] ACATS c460007 fails at -O2 or above

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|ada |rtl-optimization
  Known to work||4.5.1
   Target Milestone|--- |4.6.0
Summary|ACATS c460007 fails at -O2  |[4.6 regression] ACATS
   |or above|c460007 fails at -O2 or
   ||above

--- Comment #9 from Eric Botcazou  2010-11-16 
17:07:00 UTC ---
Recategorizing.

[Bug middle-end/46488] [4.5 regression] server/core_filters.c from apache httpd 2.2.17 miscompiled with optimization

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.11.16 17:11:11
 Ever Confirmed|0   |1

--- Comment #4 from Eric Botcazou  2010-11-16 
17:11:11 UTC ---
> My apologies, -O -fno-delayed-branch does fix it.
> 
> -O3 -fno-delayed-branch does not work, however.

There might be several issues then.  Could you try the latest 4.5.x snapshot?
At least a couple of issues related to -fdelayed-branch were fixed in between.

[Bug bootstrap/46086] fail to build gcc 4.5.2 on sparc64-portbld-freebsd9.0 - configure: error: cannot compute suffix of object files: cannot compile

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  2010-11-16 
17:16:11 UTC ---
> configure:3658: checking for C compiler default output file name
> configure:3680: /usr/ports/lang/gcc45/work/build/./gcc/xgcc
> -B/usr/ports/lang/gcc45/work/build/./gcc
> / -B/usr/local/sparc64-portbld-freebsd9.0/bin/
> -B/usr/local/sparc64-portbld-freebsd9.0/lib/ -isystem
>  /usr/local/sparc64-portbld-freebsd9.0/include -isystem
> /usr/local/sparc64-portbld-freebsd9.0/sys-in
> clude-g -O2 -pipe -I/usr/local/include -fno-strict-aliasing   conftest.c 
> >&5
> xgcc: Internal error: Segmentation fault: 11 (program cc1)
> Please submit a full bug report.
> See  for instructions.

Probably the same issue.  Did you run 'make check' for GMP and MPFR?  If there
are failures, it's not worthwhile to try to build GCC with them.

[Bug driver/46501] Relocatable toolchains still search --prefix

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #1 from Ian Lance Taylor  2010-11-16 17:33:19 
UTC ---
If at all possible, please list the precise cases where the value passed to
--prefix appears in a search path incorrectly.  Please indicate precisely how
gcc was configured, precisely how gcc was installed, and which incorrect search
path was used.

Without that information, any fix that we make is unlikely to actually fix your
problem, as you are probably doing something which we will inadvertently fail
to test.

Thanks.

[Bug lto/46504] New: LTO failed on 483.xalancbmk in SPEC CPU 2006

[hjl.tools at gmail dot com]

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

   Summary: LTO failed on 483.xalancbmk in SPEC CPU 2006
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, revision 166795 gave

/export/gnu/import/svn/gcc-test-spec/usr/bin/g++  -O3 -funroll-loops
-ffast-math
 -fwhole-program -flto=jobserver  -DSPEC_CPU_LP64 ...
In file included from :617:0:
./xercesc/internal/ValidationContextImpl.hpp: In member function
‘getValidatingMemberType’:
./xercesc/internal/ValidationContextImpl.hpp:175:0: internal compiler error: in
get_alias_set, at alias.c:717
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [/tmp/cckGnQ6e.ltrans6.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
collect2: lto-wrapper returned 1 exit status

[Bug lto/46505] New: LTO miscompiled 416.gamess in SPEC CPU 2006

[hjl.tools at gmail dot com]

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

   Summary: LTO miscompiled 416.gamess in SPEC CPU 2006
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, revision 166795 with  -O3 -funroll-loops -ffast-math
-fwhole-program -flto=jobserver -ffixed-form gave

  Running 416.gamess test peak lto default


Contents of exam29.err

STOP IN ABRT



*** Miscompare of exam29.out; for details see
   
/export/gnu/import/svn/gcc-test-spec/spec/2006/x86_64/spec/benchspec/CPU2006/416.gamess/run/run_peak_test_lto./exam29.out.mis

[Bug lto/46506] New: LTO miscompiled 465.tonto in SPEC CPU 2006

[hjl.tools at gmail dot com]

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

   Summary: LTO miscompiled 465.tonto in SPEC CPU 2006
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, revision 166795 with  -O3 -funroll-loops -ffast-math
-fwhole-program -flto=jobserver -ffixed-form gave

  Running 465.tonto test peak lto default

*** Miscompare of stdout; for details see
   
/export/gnu/import/svn/gcc-test-spec/spec/2006/x86_64/spec/benchspec/CPU2006
/465.tonto/run/run_peak_test_lto./stdout.mis

[Bug driver/46501] Relocatable toolchains still search --prefix

[nightstrike at gmail dot com]

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

--- Comment #2 from nightstrike  2010-11-16 
17:48:32 UTC ---
Configure:
../../../build/gcc/src/configure \
--target=i686-w64-mingw32 \
 \
--prefix=/buildbot/mingw-w64/linux-x86_64-x86/build/build/root \
--with-sysroot=/buildbot/mingw-w64/linux-x86_64-x86/build/build/root \
--enable-languages=all,obj-c++ \
--enable-fully-dynamic-string --disable-multilib


Build toolchain, install to $prefix.

cd $prefix && tar cjf a.tbz2 * (or similar)
cd /usr && tar xjf a.tbz2 (or equivalent)


So what we are doing is essentially building a "relocatable" toolchain,
installing it to some location, tarring up that location, and then extracting
it wherever we want.  The user referenced in the URL attached this PR wanted to
extract it to /usr (thus causing the issue of the embedded directory "root"),
but the eventual location you extract to doesn't affect the inclusion of
directories outside of the gcc hierarchy.  Observe:


i686-w64-mingw32-gcc -print-search-dirs:

install: /usr/bin/../lib/gcc/i686-w64-mingw32/4.6.0/ programs:
=/usr/bin/../libexec/gcc/i686-w64-mingw32/4.6.0/:/usr/bin/../libexec/gcc/:/usr/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/bin/i686-w64-mingw32/4.6.0/:/usr/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/bin/
libraries:
=/usr/bin/../lib/gcc/i686-w64-mingw32/4.6.0/:/usr/bin/../lib/gcc/:/usr/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/i686-w64-mingw32/4.6.0/:/usr/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib/:/usr/bin/../../root/mingw/lib/i686-w64-mingw32/4.6.0/:/usr/bin/../../root/mingw/lib/../lib/:/usr/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/:/usr/bin/../../root/mingw/lib/


You can see in there where there are references to "root".  These are what are
incorrect.

Please let me know if that is enough information for you.

[Bug c++/11137] [3.3 Regression] Linux shared library constructors not called unless there's one global object

[hjl at gcc dot gnu.org]

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

--- Comment #6 from hjl at gcc dot gnu.org  2010-11-16 
17:56:57 UTC ---
Author: hjl
Date: Tue Nov 16 17:56:50 2010
New Revision: 166810

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166810
Log:
Properly demangle a global constructor symbol.

2010-11-16  H.J. Lu  

PR other/42670
PR binutils/11137
* cp-demangle.c (d_make_demangle_mangled_name): New.
(d_demangle_callback): Use it on DCT_GLOBAL_XTORS.

* testsuite/demangle-expected: Updated.

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/cp-demangle.c
trunk/libiberty/testsuite/demangle-expected

[Bug other/42670] demangler doesn't completely demangle a global constructor symbol

[hjl at gcc dot gnu.org]

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

--- Comment #6 from hjl at gcc dot gnu.org  2010-11-16 
17:56:56 UTC ---
Author: hjl
Date: Tue Nov 16 17:56:50 2010
New Revision: 166810

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166810
Log:
Properly demangle a global constructor symbol.

2010-11-16  H.J. Lu  

PR other/42670
PR binutils/11137
* cp-demangle.c (d_make_demangle_mangled_name): New.
(d_demangle_callback): Use it on DCT_GLOBAL_XTORS.

* testsuite/demangle-expected: Updated.

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/cp-demangle.c
trunk/libiberty/testsuite/demangle-expected

[Bug tree-optimization/46507] New: std::tuple missed optimization

[miles at gnu dot org]

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

   Summary: std::tuple missed optimization
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org


My understanding is that std::tuple should offer largely the same optimization
opportunities as std::pair (while being more flexible).

However gcc-4.6 seems to miss some optimizations with std::tuple that it
doesn't with pair.

E.g. the following code ("tp.cc"):

 start 
   #include 
   #include 

   struct A
   {
 virtual void f () const;
   };

   void arg_tuple_test (const std::tuple &t)
   {
 std::get<0>(t).f ();
   }

   void extern_tuple_test ()
   {
 extern const std::tuple &t;
 std::get<0>(t).f ();
   }

   void arg_pair_test (const std::pair &t)
   {
 t.first.f ();
   }
 end 

compiled with:

  g++-snapshot -std=c++0x -O2 -march=amdfam10 -S tp.cc

results in the following assembly:

   arg_tuple_test(std::tuple const&):
   movq(%rdi), %rax
   movq(%rax), %rax
   jmp*%rax

   extern_tuple_test():
   movqt(%rip), %rdi
   movq(%rdi), %rax
   movq(%rax), %rax
   jmp*%rax

   arg_pair_test(std::pair const&):
   jmpA::f() const

   .ident"GCC: (Debian 20101114-1) 4.6.0 20101114 (experimental) [trunk
revision 166728]"


It seems like all of these functions should use a direct jump to A::f, but the
tuple versions do not.

Note that when I tried this same test yesterday, on a different machine (but
the same compiler version), "extern_tuple_test" (but not "arg_tuple_test")
_did_ result in a direct jump to A::f!  So maybe something funny is going on...


Thanks,

-Miles

[Bug other/42670] demangler doesn't completely demangle a global constructor symbol

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #7 from H.J. Lu  2010-11-16 17:58:57 
UTC ---
Fixed.

[Bug rtl-optimization/46366] gcc.target/i386/pr45352-2.c failed

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #5 from H.J. Lu  2010-11-16 18:54:32 
UTC ---
Fixed.

[Bug tree-optimization/46507] std::tuple missed optimization

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #1 from Paolo Carlini  2010-11-16 
19:04:37 UTC ---
Interesting. Not that I think it would make a huge difference, but probably
this is a more "fair" comparison:

   #include 
   #include 

   struct A
   {
 virtual void f () const;
   };

   void arg_tuple_test (const std::tuple &t)
   {
 std::get<0>(t).f ();
   }

   void extern_tuple_test ()
   {
 extern const std::tuple &t;
 std::get<0>(t).f ();
   }

   void arg_pair_test (const std::pair &t)
   {
 std::get<0>(t).f ();
   }

[Bug tree-optimization/46507] std::tuple missed optimization

[miles at gnu dot org]

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

--- Comment #2 from miles at gnu dot org 2010-11-16 19:06:02 UTC ---
> Note that when I tried this same test yesterday, on a different machine (but
> the same compiler version), "extern_tuple_test" (but not "arg_tuple_test")
> _did_ result in a direct jump to A::f!  So maybe something funny is going 
> on...

Actually this is wrong:  the version of "extern_tuple_test" which worked
yesterday was really this:

   void extern_tuple_test ()
   {
 extern const std::tuple t;
 std::get<0>(t).f ();
   }

resulting in:

   extern_tuple_test():
movl$t, %edi
jmpA::f() const

Still, it seems like "arg_tuple_test" (and the previous version of
"extern_tuple_tst") should also received the same optimization.

[Bug target/46483] Built-in memcpy() does not handle unaligned int for ARM

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #12 from Mikael Pettersson  2010-11-16 
19:11:03 UTC ---
The bug was introduced between 4.3 and 4.4 in r142061, Jakub's "More aggressive
__builtin_memcpy optimizations (PR middle-end/29215)" patch:
http://gcc.gnu.org/ml/gcc-cvs/2008-11/msg00562.html
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00637.html

[Bug tree-optimization/46507] std::tuple missed optimization

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2010-11-16 
19:27:48 UTC ---
Paolo, your example *does* show a significant difference:  the missed
optimisation is in std::get() and not tuple itself, as shown by 

#include 
#include 

struct A
{
virtual void f () const;
};

void arg_tuple_test (const std::pair &t)
{
std::get<0>(t).f ();
}

void arg_pair_test (const std::pair &t)
{
t.first.f ();
}

The second function jumps directly to A::f

[Bug preprocessor/17349] // comments cause weird behaviour with options -E -C

[ktietz at gcc dot gnu.org]

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

--- Comment #3 from Kai Tietz  2010-11-16 19:50:22 
UTC ---
Author: ktietz
Date: Tue Nov 16 19:50:17 2010
New Revision: 166817

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166817
Log:
2010-11-16  Kai Tietz  

PR preprocessor/17349
* lex.c (save_comment): Handle in argument passing c++
comments special.

2010-11-16  Kai Tietz  

PR preprocessor/17349
* gcc.dg/cpp/cmdlne-C3.c: New.


Added:
trunk/gcc/testsuite/gcc.dg/cpp/cmdlne-C3.c   (with props)
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/lex.c

Propchange: trunk/gcc/testsuite/gcc.dg/cpp/cmdlne-C3.c
('svn:eol-style' added)

Propchange: trunk/gcc/testsuite/gcc.dg/cpp/cmdlne-C3.c
('svn:mime-type' added)

[Bug preprocessor/17349] // comments cause weird behaviour with options -E -C

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Kai Tietz  2010-11-16 19:59:17 
UTC ---
Removed from repository checkin the eol-style and mine-type property. I don't
plan to back-merge this fix. So I close it.

[Bug rtl-optimization/46395] [4.6 regression] FAIL: 22_locale/numpunct/members/pod/2.cc execution test

[schwab at gcc dot gnu.org]

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

--- Comment #2 from Andreas Schwab  2010-11-16 
20:17:38 UTC ---
Author: schwab
Date: Tue Nov 16 20:17:31 2010
New Revision: 166820

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166820
Log:
PR rtl-optimization/46395
* gcc/postreload.c (reload_combine): Invalidate register use
information on all control flow insns.

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

[Bug rtl-optimization/46395] [4.6 regression] FAIL: 22_locale/numpunct/members/pod/2.cc execution test

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Andreas Schwab  2010-11-16 20:19:11 
UTC ---
Fixed.

[Bug c++/46401] [4.5/4.6 Regression] very slow compile time with -Wsequence-point

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2010-11-16 
20:50:04 UTC ---
Author: jakub
Date: Tue Nov 16 20:49:57 2010
New Revision: 166823

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166823
Log:
PR c++/46401
* c-common.c (warning_candidate_p): Don't track non-const calls
or STRING_CSTs.

* g++.dg/warn/Wsequence-point-3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wsequence-point-3.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

[Bug libffi/46508] New: [4.6 regression] "Add ARM VFP ABI support to libffi" broke build for armv5tel-linux-gnueabi with binutils-2.20.1

[mikpe at it dot uu.se]

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

   Summary: [4.6 regression] "Add ARM VFP ABI support to libffi"
broke build for armv5tel-linux-gnueabi with
binutils-2.20.1
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libffi
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@it.uu.se


Attempting to build gcc-4.6-20101113 with --enable-languages=java (which
enables libffi) for armv5tel-linux-gnueabi with binutils-2.20.1 fails due to
the assembler complaining about VFP instructions in libffi's arm sysv.S:

> /tmp/gcc-4.6-20101113/configure --target=armv5tel-unknown-linux-gnueabi 
> --with-arch=armv5te --prefix=/home/mikpe/pkgs/linux-x86/cross-armv5tel 
> --disable-nls --disable-shared --disable-libmudflap --disable-multilib 
> --enable-threads=posix --enable-checking=release --enable-languages=c,c++,java
> make
...
libtool: compile:  /tmp/objdir/./gcc/xgcc -B/tmp/objdir/./gcc/
-B/home/mikpe/pkgs/linux-x86/cross-armv5tel/armv5tel-unknown-linux-gnueabi/bin/
-B/home/mikpe/pkgs/linux-x86/cross-armv5tel/armv5tel-unknown-linux-gnueabi/lib/
-isystem
/home/mikpe/pkgs/linux-x86/cross-armv5tel/armv5tel-unknown-linux-gnueabi/include
-isystem
/home/mikpe/pkgs/linux-x86/cross-armv5tel/armv5tel-unknown-linux-gnueabi/sys-include
-DHAVE_CONFIG_H -I. -I/tmp/gcc-4.6-20101113/libffi -I.
-I/tmp/gcc-4.6-20101113/libffi/include -Iinclude
-I/tmp/gcc-4.6-20101113/libffi/src -I. -I/tmp/gcc-4.6-20101113/libffi/include
-Iinclude -I/tmp/gcc-4.6-20101113/libffi/src -g -O2 -MT src/arm/sysv.lo -MD -MP
-MF src/arm/.deps/sysv.Tpo -c /tmp/gcc-4.6-20101113/libffi/src/arm/sysv.S -o
src/arm/sysv.o
/tmp/gcc-4.6-20101113/libffi/src/arm/sysv.S: Assembler messages:
/tmp/gcc-4.6-20101113/libffi/src/arm/sysv.S:266: Error: selected processor does
not support `flddle d0,[ip]'
/tmp/gcc-4.6-20101113/libffi/src/arm/sysv.S:267: Error: selected processor does
not support `fldmiadgt ip,{d0-d7}'
/tmp/gcc-4.6-20101113/libffi/src/arm/sysv.S:307: Error: selected processor does
not support `fstseq s0,[r2]'
/tmp/gcc-4.6-20101113/libffi/src/arm/sysv.S:311: Error: selected processor does
not support `fstdeq d0,[r2]'
/tmp/gcc-4.6-20101113/libffi/src/arm/sysv.S:316: Error: selected processor does
not support `fstmiadeq r2,{d0-d3}'
/tmp/gcc-4.6-20101113/libffi/src/arm/sysv.S:400: Error: selected processor does
not support `fstmfdd sp!,{d0-d7}'
/tmp/gcc-4.6-20101113/libffi/src/arm/sysv.S:438: Error: selected processor does
not support `flds s0,[sp]'
/tmp/gcc-4.6-20101113/libffi/src/arm/sysv.S:441: Error: selected processor does
not support `fldd d0,[sp]'
/tmp/gcc-4.6-20101113/libffi/src/arm/sysv.S:450: Error: selected processor does
not support `fldmiad sp,{d0-d1}'
/tmp/gcc-4.6-20101113/libffi/src/arm/sysv.S:453: Error: selected processor does
not support `fldmiad sp,{d0-d3}'
make[4]: *** [src/arm/sysv.lo] Error 1
make[4]: Leaving directory `/tmp/objdir/armv5tel-unknown-linux-gnueabi/libffi'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/tmp/objdir/armv5tel-unknown-linux-gnueabi/libffi'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/objdir/armv5tel-unknown-linux-gnueabi/libffi'
make[1]: *** [all-target-libffi] Error 2
make[1]: Leaving directory `/tmp/objdir'
make: *** [all] Error 2

Notes:
1. If binutils is downgraded to 2.19.1 then gas no longer complains.
2. gcc-4.6-20101023 built Ok with the same configuration (a number of
bootstrap-unbreaking patches were applied though). This error is a regression
from r166032, "Add ARM VFP ABI support to libffi":
http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg01219.html
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02419.html

[Bug other/42670] demangler doesn't completely demangle a global constructor symbol

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||hjl.tools at gmail dot com
 Resolution|FIXED   |

--- Comment #8 from H.J. Lu  2010-11-16 21:13:09 
UTC ---
A regression:

FAIL: abi/demangle/regression/cw-13.cc execution test

Proposed fix:

http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01725.html

[Bug fortran/32049] Support on x86_64 also kind=16

[burnus at gcc dot gnu.org]

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

--- Comment #11 from Tobias Burnus  2010-11-16 
21:23:28 UTC ---
Author: burnus
Date: Tue Nov 16 21:23:19 2010
New Revision: 166825

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166825
Log:
/
2010-11-13  Francois-Xavier Coudert  
Tobias Burnus  

PR fortran/32049
* Makefile.def: Add libquadmath; build it with language=fortran.
* configure.ac: Add libquadmath.
* Makefile.tpl: Handle multiple libs in check-[+language+].
* Makefile.in: Regenerate.
* configure: Regenerate.

libquadmath/
2010-11-13  Francois-Xavier Coudert  
Tobias Burnus  

PR fortran/32049
Initial implementation and checkin.

gcc/fortran/
2010-11-13  Francois-Xavier Coudert  
Tobias Burnus  

PR fortran/32049
* gfortranspec.c (find_spec_file): New function.
(lang_specific_driver): Try to find .spec file and use it.
* trans-io.c (iocall): Define
* IOCALL_X_REAL128/COMPLEX128(,write).
(gfc_build_io_library_fndecls): Build decl for __float128 I/O.
(transfer_expr): Call __float128 I/O functions.
* trans-types.c (gfc_init_kinds): Allow kind-16 belonging
to __float128.

gcc/testsuite/
2010-11-13  Francois-Xavier Coudert  
Tobias Burnus  

PR fortran/32049
* gfortran.dg/quad_1.f90: New.
* lib/gcc-defs.exp (gcc-set-multilib-library-path): Use also
compiler arguments.
* lib/gfortran.exp (gfortran_link_flags): Add libquadmath to
library search path; call gcc-set-multilib-library-path with
arguments such that libgfortran.spec is found.
(gfortran_init): Add path for libgfortran.spec to
GFORTRAN_UNDER_TEST.

libgomp/
2010-11-13  Francois-Xavier Coudert  
Tobias Burnus  

PR fortran/32049
* configure.ac: 
* configure: Regenerate.

libgfortran/
2010-11-13  Francois-Xavier Coudert  
Tobias Burnus  

PR fortran/32049
* Makefile.am: Add missing pow_r16_i4.c, add transfer128.c,
link libquadmath, if used.
* acinclude.m4 (LIBGFOR_CHECK_FLOAT128): Add.
* configure.ac: Use it, touch spec file.
* gfortran.map: Add pow_r16_i4 and
transfer_(real,complex)128(,write) functions.
* intrinsics/cshift0.c (cshift0): Handle __float128 type.
* intrinsics/erfc_scaled_inc.c: Ditto.
* intrinsics/pack_generic.c (pack): Ditto
* intrinsics/spread_generic.c (spread): Ditto.
* intrinsics/unpack_generic.c (unpack1): Ditto.
* io/read.c (convert_real): Ditto.
* io/transfer.c: Update comments.
* io/transfer128.c: New file.
* io/write_float.def (write_float): Handle __float128 type.
* libgfortran.h: #include quadmath_weak.h, define __builtin_infq
and nanq.
* m4/mtype.m4: Handle __float128 type.
* runtime/in_pack_generic.c (internal_pack): Ditto.
* runtime/in_unpack_generic.c (internal_unpack): Ditto.
* kinds-override.h: New file.
* libgfortran.spec.in: Ditto.
* generated/pow_r16_i4.c: Generated.
* Makefile.in: Regenerate.
* configure: Regenerate.
* config.h: Regenerate.
* bessel_r10.c: Regenerate.
* bessel_r16.c: Regenerate.
* bessel_r4.c: Regenerate.
* bessel_r8.c: Regenerate.
* exponent_r16.c: Regenerate.
* fraction_r16.c: Regenerate.
* nearest_r16.c: Regenerate.
* norm2_r10.c: Regenerate.
* norm2_r16.c: Regenerate.
* norm2_r4.c: Regenerate.
* norm2_r8.c: Regenerate.
* rrspacing_r16.c: Regenerate.
* set_exponent_r16.c: Regenerate.
* spacing_r16.c: Regenerate.


Added:
trunk/gcc/testsuite/gfortran.dg/quad_1.f90
trunk/libgfortran/generated/pow_r16_i4.c
trunk/libgfortran/io/transfer128.c
trunk/libgfortran/kinds-override.h
trunk/libgfortran/libgfortran.spec.in
trunk/libquadmath/
trunk/libquadmath/COPYING.LIB
trunk/libquadmath/ChangeLog
trunk/libquadmath/Makefile.am
trunk/libquadmath/Makefile.in
trunk/libquadmath/acinclude.m4
trunk/libquadmath/aclocal.m4
trunk/libquadmath/config.h.in
trunk/libquadmath/configure
trunk/libquadmath/configure.ac
trunk/libquadmath/gdtoa/
trunk/libquadmath/gdtoa/README.gdtoa
trunk/libquadmath/gdtoa/arith.h
trunk/libquadmath/gdtoa/dmisc.c
trunk/libquadmath/gdtoa/g_Qfmt.c
trunk/libquadmath/gdtoa/g__fmt.c
trunk/libquadmath/gdtoa/gd_qnan.h
trunk/libquadmath/gdtoa/gdtoa.c
trunk/libquadmath/gdtoa/gdtoa.h
trunk/libquadmath/gdtoa/gdtoa_fltrnds.h
trunk/libquadmath/gdtoa/gdtoaimp.h
trunk/libquadmath/gdtoa/gethex.c
trunk/libquadmath/gdtoa/gmisc.c
trunk/libquadmath/gdtoa/hd_init.c
trunk/libquadmath/gdtoa/hexnan.c
trunk/libquadmath/gdtoa/makefile
trunk/libquadmath/gdtoa/misc.c

[Bug c++/46401] [4.5 Regression] very slow compile time with -Wsequence-point

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.16 21:28:46
  Known to work||4.6.0
Summary|[4.5/4.6 Regression] very   |[4.5 Regression] very slow
   |slow compile time with  |compile time with
   |-Wsequence-point|-Wsequence-point
 Ever Confirmed|0   |1
  Known to fail|4.6.0   |

--- Comment #3 from Jakub Jelinek  2010-11-16 
21:28:46 UTC ---
Fixed for 4.6 so far.

[Bug fortran/32049] Support on x86_64 also kind=16

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #12 from Tobias Burnus  2010-11-16 
21:31:25 UTC ---
Hooray! REAL(16) is now available with GCC 4.6!

Close as fixed!

[Bug libstdc++/46455] resource leaks due to missing destructors for mutexes and condvars

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Attachment #22413|0   |1
is obsolete||

--- Comment #23 from Jonathan Wakely  2010-11-16 
21:38:01 UTC ---
Created attachment 22424
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22424
add destructors in 

here's another patch, this one uses SFINAE to select an appropriate overload
based on the type of __gthread_recursive_mutex_t and if necessary extracts a
__gthread_mutex_t from it to pass to __gthread_mutex_destroy

this will be wrong if a recursive mutex type needs more cleanup than just
destroying its non-recursive mutex, though I don't think that's a problem for
any current systems supported by gthreads.

could be improved upon by disabling the third _S_destroy overload when
recursive_mutex_type is not the same as mutex_type, but it's ugly enough
already.

Zouzou, could you test this on mingw? thanks

[Bug java/46386] negative shift count in build_constants_constructor for 16 bit pointer targets

[amylaar at gcc dot gnu.org]

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

--- Comment #2 from Jorn Wolfgang Rennecke  
2010-11-16 21:46:37 UTC ---
Author: amylaar
Date: Tue Nov 16 21:46:28 2010
New Revision: 166826

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166826
Log:
2010-11-09  Joern Rennecke  
Andrew Haley  

PR java/46386
gcc/java:
* constants.c (build_constants_constructor): Avoid negative shift.
gcc:
* config/pdp11/t-pdp11 (java/constants.o-warn): Remove.
* config/t-pnt16-warn (java/constants.o-warn): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pdp11/t-pdp11
trunk/gcc/config/t-pnt16-warn
trunk/gcc/java/ChangeLog
trunk/gcc/java/constants.c

[Bug java/46386] negative shift count in build_constants_constructor for 16 bit pointer targets

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Jorn Wolfgang Rennecke  
2010-11-16 21:49:42 UTC ---
Patch has been applied to trunk.

[Bug target/44762] score/predicates.md warnings

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Jorn Wolfgang Rennecke  
2010-11-16 21:51:36 UTC ---
patch has been applied to trunk.

[Bug bootstrap/41337] [LTO] Parallel build failure

[dmitrij.ledkov at ubuntu dot com]

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

Dima  changed:

   What|Removed |Added

 CC||dmitrij.ledkov at ubuntu
   ||dot com

--- Comment #2 from Dima  2010-11-16 21:53:42 
UTC ---
I have the same error. Would please share your pilot error and how you have
fixed it? Maybe I'm doing the same thing

[Bug testsuite/46422] [4.6 Regression] FAIL: g++.dg/other/i386-?.C

[qneill at gcc dot gnu.org]

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

--- Comment #2 from Quentin Neill  2010-11-16 
22:12:08 UTC ---
Fix is posted at http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01597.html

[Bug rtl-optimization/46315] [4.5 regression] -O2 -fno-strict-overflow causes wrong code generation

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  2010-11-16 
22:13:56 UTC ---
Author: ebotcazou
Date: Tue Nov 16 22:13:52 2010
New Revision: 166827

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166827
Log:
PR rtl-optimization/46315
* rtl.h (remove_reg_equal_equiv_notes_for_regno): Declare.
* rtlanal.c (remove_reg_equal_equiv_notes_for_regno): New function
extracted from...
* dce.c (delete_corresponding_reg_eq_notes): ...here.  Rename into...
(remove_reg_equal_equiv_notes_for_defs): ...this.
(delete_unmarked_insns): Adjust to above renaming.
* ifcvt.c (dead_or_predicable): Remove REG_EQUAL and REG_EQUIV notes
referring to registers set in the insns being moved, if any.

* df-core.c (df_ref_dump): New function extracted from...
(df_refs_chain_dump): ...here.  Call it.
(df_regs_chain_dump): Likewise.
* df-problems.c (df_chain_dump): Print 'e' for uses in notes.
* df-scan.c (df_scan_start_dump): Likewise.  Fix long line.

Added:
trunk/gcc/testsuite/gcc.dg/pr46315.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dce.c
trunk/gcc/df-core.c
trunk/gcc/df-problems.c
trunk/gcc/df-scan.c
trunk/gcc/ifcvt.c
trunk/gcc/rtl.h
trunk/gcc/rtlanal.c
trunk/gcc/testsuite/ChangeLog

[Bug c/46509] New: -Wparentheses shouldn't warn about: A || Y && "foo"

[sabre at nondot dot org]

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

   Summary: -Wparentheses shouldn't warn about: A || Y && "foo"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sa...@nondot.org


Per the subject, -Wparentheses shouldn't warn about possible ||/&& precedence
issues if the operand to the or is always false or the operand to && is always
true.  These should not warn:

if (a || b && 1) 
if (0 || a && b) 

They shouldn't warn because even if the user is confused about precedence, the
order of evaluation doesn't affect the result of the computation.

This happens to come up frequently for coding standards that use messages in
asserts, e.g.:

assert(A == 1 || A == 3 && "some reason this property should hold"); 

-Chris

[Bug rtl-optimization/46315] [4.5 regression] -O2 -fno-strict-overflow causes wrong code generation

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  2010-11-16 
22:17:22 UTC ---
Author: ebotcazou
Date: Tue Nov 16 22:17:17 2010
New Revision: 166828

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166828
Log:
PR rtl-optimization/46315
* rtl.h (remove_reg_equal_equiv_notes_for_regno): Declare.
* rtlanal.c (remove_reg_equal_equiv_notes_for_regno): New function
extracted from...
* dce.c (delete_corresponding_reg_eq_notes): ...here.  Rename into...
(remove_reg_equal_equiv_notes_for_defs): ...this.
(delete_unmarked_insns): Adjust to above renaming.
* ifcvt.c (dead_or_predicable): Remove REG_EQUAL and REG_EQUIV notes
referring to registers set in the insns being moved, if any.

* df-core.c (df_ref_dump): New function extracted from...
(df_refs_chain_dump): ...here.  Call it.
(df_regs_chain_dump): Likewise.
* df-problems.c (df_chain_dump): Print 'e' for uses in notes.
* df-scan.c (df_scan_start_dump): Likewise.  Fix long line.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr46315.c
  - copied unchanged from r166827, trunk/gcc/testsuite/gcc.dg/pr46315.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/dce.c
branches/gcc-4_5-branch/gcc/df-core.c
branches/gcc-4_5-branch/gcc/df-problems.c
branches/gcc-4_5-branch/gcc/df-scan.c
branches/gcc-4_5-branch/gcc/ifcvt.c
branches/gcc-4_5-branch/gcc/rtl.h
branches/gcc-4_5-branch/gcc/rtlanal.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug c/46509] -Wparentheses shouldn't warn about: A || Y && "foo"

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2010-11-16 
22:17:45 UTC ---
>A == 1 || A == 3 && "some reason this property should hold"

To the untrained eye this looks funny really.  The parentheses makes the code
look cleaner and better understood as far as I can tell.