[Bug c++/51203] Recursive alias template specialization causes compiler segfault

[pubby.8 at gmail dot com]

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

Pubby8  changed:

   What|Removed |Added

   Severity|normal  |trivial

[Bug c/51206] New: Building Cross-Compiler for Linux/x86_64 multilibs fails due to FLAGS_FOR_TARGET

[gcc at rkeene dot org]

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

 Bug #: 51206
   Summary: Building Cross-Compiler for Linux/x86_64 multilibs
fails due to FLAGS_FOR_TARGET
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@rkeene.org


In gcc 4.6.1's top-level "configure.ac" the following line:

FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$(build_tooldir)/bin/
-B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include -isystem
$(build_tooldir)/sys-include'

causes build failure for "libgcc" when creating a (non-Canadian) cross-compiler
for Linux/x86_64 using multilibs.

The failure is triggered when the 64-bit "libgcc" is built.  The -B.../lib 
argument is passed to "xgcc" causing it to look in the 32-bit "lib" directory
for the 64-bit "crti.o", "crtn.o", and "libc.so".

Specifically what fails is:

/bin/sh ../../../gcc-4.6.1/libgcc/../mkinstalldirs .
/home/rkeene/root/cross-compilers/build-cc/gcc-x86_64-slackware-linux/./gcc/xgcc
-B/home/rkeene/root/cross-compilers/build-cc/gcc-x86_64-slackware-linux/./gcc/
-B/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux/bin/
-B/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux/lib/
-isystem
/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux/include
-isystem
/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux/sys-include
--sysroot=/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux
  -O2  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -DNATIVE_CROSS  -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector  -shared
-nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o
./libgcc_s.so.1.tmp -g -O2 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o
_ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o
_enable_execute_stack_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o
_addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o
_negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o
_clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o
_popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o
_powidf2_s.o _powixf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _divsc3_s.o
_divdc3_s.o _divxc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o
_fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o
_fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o
_floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o
_moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o
addtf3_s.o divtf3_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o
fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o
floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o
floatuntitf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o
trunctfdf2_s.o trunctfxf2_s.o getf2_s.o letf2_s.o eqtf2_s.o _divtc3_s.o
_multc3_s.o _powitf2_s.o unwind-dw2_s.o unwind-dw2-fde-glibc_s.o
unwind-sjlj_s.o gthr-gnat_s.o unwind-c_s.o emutls_s.o -lc && rm -f
./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1
./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1
&& ln -s libgcc_s.so.1 ./libgcc_s.so
/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux/bin/ld:
skipping incompatible
/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux/lib/libc.so
when searching for -lc
/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux/bin/ld:
i386 architecture of input file
`/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux/lib/crti.o'
is incompatible with i386:x86-64 output
/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux/bin/ld:
i386 architecture of input file
`/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux/lib/crtn.o'
is incompatible with i386:x86-64 output
collect2: ld returned 1 exit status

[Bug c/51206] Building Cross-Compiler for Linux/x86_64 multilibs fails due to FLAGS_FOR_TARGET

[gcc at rkeene dot org]

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

--- Comment #1 from gcc at rkeene dot org 2011-11-18 08:27:00 UTC ---
If I remove the "-B.../lib" argument from
x86_64-slackware-linux/libgcc/Makefile then both the 32-bit and the 64-bit
libgcc builds complete.

That is, if I change the line from:
CC =
/home/rkeene/root/cross-compilers/build-cc/gcc-x86_64-slackware-linux/./gcc/xgcc
-B/home/rkeene/root/cross-compilers/build-cc/gcc-x86_64-slackware-linux/./gcc/
-B/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux/bin/
-B/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux/lib/
-isystem
/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux/include
-isystem
/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux/sys-include
--sysroot=/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux


to:

CC =
/home/rkeene/root/cross-compilers/build-cc/gcc-x86_64-slackware-linux/./gcc/xgcc
-B/home/rkeene/root/cross-compilers/build-cc/gcc-x86_64-slackware-linux/./gcc/
-B/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux/bin/
-isystem
/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux/include
-isystem
/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux/sys-include
--sysroot=/home/rkeene/root/cross-compilers/x86_64-slackware-linux/x86_64-slackware-linux

[Bug c++/51194] ICE about template aliasing

[fate66260 at gmail dot com]

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

--- Comment #2 from fate66260 at gmail dot com 2011-11-18 08:59:28 UTC ---
http://ideone.com/lZEbs

g++ (GCC) 4.7.0 2012
g++ -std=c++0x a.cpp
--
a.cpp: In instantiation of 'struct enable_and':
a.cpp:110:19:   required from here
a.cpp:91:46: error: wrong number of template arguments (1, should be 2)
a.cpp:69:8: error: provided for 'template struct is_same'
a.cpp:91:46: error: wrong number of template arguments (1, should be 2)
a.cpp:69:8: error: provided for 'template struct is_same'
a.cpp:110:41: internal compiler error: tree check: expected class 'type', have
'
exceptional' (error_mark) in lookup_template_class_1, at cp/pt.c:7293
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
--

Lines 69 and 91,
[C++0x] Inner class alias-definition variadic template error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51180

[Bug fortran/51207] New: [OOP] Mark __def_init_... as FL_PARAMETER

[burnus at gcc dot gnu.org]

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

 Bug #: 51207
   Summary: [OOP] Mark __def_init_... as FL_PARAMETER
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


module m
type t
  integer :: i = 4
end type t
end module m


use m
class(t), allocatable :: x, y

allocate(t :: y)
allocate(x, mold=x)

if (x%i /= 4 ) call bfjkhskllf()
end

[Bug fortran/51207] [OOP] Mark __def_init_... as FL_PARAMETER

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2011-11-18 
09:50:39 UTC ---
Hit enter too early. The problem is that the __def_init_... is not marked as
FL_PARAMETER and hence not as TREE_READONLY.

However, even if one manually sets attr.flavor == FL_PARAMETER, the call does
not seem to get optimized away. I assume that's because one has:

  __builtin_memcpy (D.1947_18, &__def_init_m_T, D.1957_16);

which makes the analysis more difficult. Nevertheless, the default
initialization should be marked as TREE_READONLY.

[Bug tree-optimization/51118] [4.7 Regression] ICE: tree check: expected tree that contains ‘typed’ structure, have ‘block’ in fold_checksum_tree, at fold-const.c:14160

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org 2011-11-18 09:54:07 UTC ---
Author: uros
Date: Fri Nov 18 09:54:02 2011
New Revision: 181468

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181468
Log:
PR tree-optimization/51118
* fold-const.c (fold_checksum_tree): Check for TS_TYPED structure
before using TREE_TYPE accessor on expr.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c

[Bug libstdc++/51181] [4.7 regression] libstdc++.so __sync_sub_and_fetch_4 linkage error causing many test suite failures on m68k-linux

[mikpe at it dot uu.se]

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

--- Comment #8 from Mikael Pettersson  2011-11-18 
09:50:30 UTC ---
Testing Richard's patch ...

[Bug tree-optimization/51118] [4.7 Regression] ICE: tree check: expected tree that contains ‘typed’ structure, have ‘block’ in fold_checksum_tree, at fold-const.c:14160

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Target|x86 |
 Status|ASSIGNED|RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-11/msg01844.htm
   ||l
 Resolution||FIXED

--- Comment #7 from Uros Bizjak  2011-11-18 09:57:19 
UTC ---
Fixed for 4.7.

[Bug fortran/51208] New: [OOP] ALLOCATE with SOURCE= or MOLD=: Diagnose if variable occurs twice

[burnus at gcc dot gnu.org]

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

 Bug #: 51208
   Summary: [OOP] ALLOCATE with SOURCE= or MOLD=: Diagnose if
variable occurs twice
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


In ALLOCATE, one gets a diagnosis if one uses:

   integer, allocatable :: i
   allocate(i, stat=i)
   end

Namely:
   allocate(i, stat=i)
 1
   Error: Stat-variable at (1) shall not be ALLOCATEd within
  the same ALLOCATE statement

However, for SOURCE= and MOLD= it does not work:

  type t
integer :: i = 4
  end type t
  class(t), allocatable :: x, y

  allocate(t :: y)
  allocate(x, mold=x)   ! Not diagnosed
  allocate(x, source=x) ! Not diagnosed


The Intel compiler gives the error:
  error #8152: Neither the ERRMSG= variable nor any part of the source
  expression in SOURCE= or MOLD= specifiers may be allocated in the
  ALLOCATE statement in which it appears.   [X]

[Bug fortran/51207] [OOP] Mark __def_init_... as FL_PARAMETER

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2011-11-18 
10:00:43 UTC ---
  allocate(t :: y)
  allocate(x, mold=x)

The last line should be: "x, mold=y". (Cf. PR 51208.)

[Bug target/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11

[iains at gcc dot gnu.org]

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

--- Comment #60 from Iain Sandoe  2011-11-18 10:52:37 
UTC ---
Author: iains
Date: Fri Nov 18 10:52:32 2011
New Revision: 181469

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

toplevel:

PR target/49992
* configure.ac: Remove ranlib special-casing for Darwin.
* configure: Regenerate.

gcc:

PR target/49992
* configure.ac: Remove ranlib special-casing for Darwin.
* configure: Regenerate.


Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/gcc/configure.ac

[Bug target/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11

[iains at gcc dot gnu.org]

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

--- Comment #61 from Iain Sandoe  2011-11-18 10:54:24 
UTC ---
Author: iains
Date: Fri Nov 18 10:54:21 2011
New Revision: 181470

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

gcc/ada:

2011-11-18  Tristan Gingold  
Iain Sandoe  

PR target/49992
* mlib-tgt-specific-darwin.adb (Archive_Indexer_Options): Remove.
* gcc-interface/Makefile.in (darwin): Remove ranlib special-casing
for Darwin.


Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/Makefile.in
trunk/gcc/ada/mlib-tgt-specific-darwin.adb

[Bug libfortran/50016] [4.7 Regression] Drastic I/O performance regression on Windows

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #20 from Janne Blomqvist  2011-11-18 
11:38:02 UTC ---
Fixed, closing.

[Bug target/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11

[iains at gcc dot gnu.org]

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

--- Comment #62 from Iain Sandoe  2011-11-18 11:45:48 
UTC ---
Author: iains
Date: Fri Nov 18 11:45:44 2011
New Revision: 181471

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

toplevel:

PR target/49992
* configure.ac: Remove ranlib special-casing for Darwin.
* configure: Regenerate.
gcc:

PR target/49992
* configure.ac: Remove ranlib special-casing for Darwin.
* configure: Regenerate.


Modified:
branches/gcc-4_6-branch/ChangeLog
branches/gcc-4_6-branch/configure
branches/gcc-4_6-branch/configure.ac
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/configure
branches/gcc-4_6-branch/gcc/configure.ac

[Bug target/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11

[iains at gcc dot gnu.org]

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

--- Comment #63 from Iain Sandoe  2011-11-18 11:47:01 
UTC ---
Author: iains
Date: Fri Nov 18 11:46:58 2011
New Revision: 181472

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

gcc/ada:

2011-11-18  Tristan Gingold  
Iain Sandoe  

PR target/49992
* mlib-tgt-specific-darwin.adb (Archive_Indexer_Options): Remove.
* gcc-interface/Makefile.in (darwin): Remove ranlib special-casing
for Darwin.


Modified:
branches/gcc-4_6-branch/gcc/ada/ChangeLog
branches/gcc-4_6-branch/gcc/ada/gcc-interface/Makefile.in
branches/gcc-4_6-branch/gcc/ada/mlib-tgt-specific-darwin.adb

[Bug c/51147] attribute((mode(byte))) on an enum generates wrong code

[pkoning at gcc dot gnu.org]

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

--- Comment #3 from Paul Koning  2011-11-18 
11:49:56 UTC ---
That workaround seems to do the right thing for what I need, so I'm no longer
stuck.  Thanks for the suggestion.

[Bug target/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #64 from Iain Sandoe  2011-11-18 11:48:54 
UTC ---
fixed, although it might be nice one day if we could rationalize the error
interfaces so that it is not necessary to link both sets for the plugin
generator files.

[Bug c++/51145] [C++11][DR 1131] Alias template in elaborated-type-specifier accepted

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-11-18 
13:11:48 UTC ---
(In reply to comment #2)
> -  error ("using typedef-name %qD after %qs", decl, tag_name (tag_code));
> -  error ("%q+D has a previous declaration here", decl);
> +  if (alias_template_specialization_p (type))
> + error ("using alias template specialization %qT after %qs",
> +type, tag_name (tag_code));
> +  else
> + {
> +   error ("using typedef-name %qD after %qs", decl, tag_name (tag_code));
> +   error ("%q+D has a previous declaration here", decl);
> + }

Let's share the "previous declaration" message between the two cases, and
change it to inform.

[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

--- Comment #57 from Iain Sandoe  2011-11-18 13:19:29 
UTC ---
Author: iains
Date: Fri Nov 18 13:19:25 2011
New Revision: 181474

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

gcc/ada:

PR target/50678
* init.c (__gnat_error_handler) [Darwin]: Move work-around to the
bug filed as radar #10302855 from __gnat_error_handler ...
... to (__gnat_adjust_context_for_raise) [Darwin]: New.
(HAVE_GNAT_ADJUST_CONTEXT_FOR_RAISE) [Darwin]: Define.
(__gnat_error_handler) [Darwin]: Use __gnat_adjust_context_for_raise.


Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/init.c

[Bug other/51011] FAIL: gcc.dg/atomic-generic.c (test for excess errors)

[dave.anglin at bell dot net]

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

--- Comment #10 from dave.anglin at bell dot net 2011-11-18 13:24:22 UTC ---
On 17-Nov-11, at 4:49 PM, amacleod at redhat dot com wrote:

> Created attachment 25846
>  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25846
> potential second patch


Testing.  With this change, is_builtin_name could be static.

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

[Bug c++/51150] [C++11][4.6/4.7 Regression] ICE when result of -> initializes const variable of different type

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot
   |com |gnu.org

[Bug fortran/51197] [4.7 Regression] Backtrace information less useful

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011-11-18
 Ever Confirmed|0   |1

--- Comment #4 from Tobias Burnus  2011-11-18 
13:44:38 UTC ---
(In reply to comment #2)
> So it would be nice to actually write the SIG* information also
> to stderr.

(In reply to comment #3)
> So to get back to the stdout/stderr issue, in 4.7 the last line of the output
> is not printed by libgfortran but rather by the OS (libc?) default signal
> handler for that signal (just like happens with -fno-backtrace). So 
> libgfortran
> has no say in where it goes.

Harald, does this solve the issue? Or do you think that gfortran should replace
the standard handler?

[Bug c++/51191] [C++0x] SEGV on deducing template aliases with non-template alias declarations

[dodji at gcc dot gnu.org]

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

--- Comment #3 from Dodji Seketeli  2011-11-18 
14:07:49 UTC ---
Author: dodji
Date: Fri Nov 18 14:07:41 2011
New Revision: 181475

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181475
Log:
PR c++/51191 - ICE on alias of alias template instantiation

gcc/cp/

PR c++/51191
* pt.c (primary_template_instantiation_p): Don't forget to
consider alias declarations.

gcc/testsuite/

PR c++/51191
* g++.dg/cpp0x/alias-decl-13.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/51150] [C++11][4.6/4.7 Regression] ICE when result of -> initializes const variable of different type

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #3 from Paolo Carlini  2011-11-18 
14:08:44 UTC ---
Let's try again ;)

[Bug c++/51191] [C++0x] SEGV on deducing template aliases with non-template alias declarations

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Dodji Seketeli  2011-11-18 
14:53:02 UTC ---
Should be fixed in trunk (4.7).

[Bug c++/51194] [C++0x] ICE about template aliasing

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

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

--- Comment #3 from Dodji Seketeli  2011-11-18 
15:09:19 UTC ---
Confirmed.  Thanks.

[Bug libstdc++/51209] New: The template _M_find_node in hashtable.h has a bad return value

[hartmut.brandt at dlr dot de]

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

 Bug #: 51209
   Summary: The template _M_find_node in hashtable.h has a bad
return value
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hartmut.bra...@dlr.de


The function starting on line 872 of bits/hashtable.c should return a pointer
but contains a 'return false;' statement. Replacing the false with a nullptr
seems the correct solution.

[Bug tree-optimization/50605] ice in ipa_get_jf_pass_through_result with -O3

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  2011-11-18 
15:13:58 UTC ---
Author: jamborm
Date: Fri Nov 18 15:13:54 2011
New Revision: 181477

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181477
Log:
2011-11-18  Martin Jambor  

PR tree-optimization/50605
* gimple.c (is_gimple_ip_invariant_address): Also handle MEM_REFs
of IPA invariant decls.

* testsuite/g++.dg/ipa/pr50605.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr50605.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/51150] [C++11][4.6/4.7 Regression] ICE when result of -> initializes const variable of different type

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  
2011-11-18 15:31:45 UTC ---
Author: paolo
Date: Fri Nov 18 15:31:38 2011
New Revision: 181478

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

PR c++/51150
* pt.c (tsubst_copy_and_build): Handle FIX_TRUNC_EXPR.

/testsuite
2011-11-18  Paolo Carlini  

PR c++/51150
* g++.dg/cpp0x/pr51150.C: New.

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

[Bug libstdc++/51209] The template _M_find_node in hashtable.h has a bad return value

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-11-18
 CC|hartmut.brandt at dlr dot   |
   |de  |
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2011-11-18 
15:38:51 UTC ---
Eh, this nit is pretty old, I'll fix it momentarily, thanks.

[Bug c++/51150] [C++11][4.6/4.7 Regression] ICE when result of -> initializes const variable of different type

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #6 from Paolo Carlini  2011-11-18 
15:52:30 UTC ---
Fixed for 4.6.3 and mainline.

[Bug c++/51150] [C++11][4.6/4.7 Regression] ICE when result of -> initializes const variable of different type

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  
2011-11-18 15:51:47 UTC ---
Author: paolo
Date: Fri Nov 18 15:51:41 2011
New Revision: 181479

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

PR c++/51150
* pt.c (tsubst_copy_and_build): Handle FIX_TRUNC_EXPR.

/testsuite
2011-11-18  Paolo Carlini  

PR c++/51150
* g++.dg/cpp0x/pr51150.C: New.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/pr51150.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/pt.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug fortran/51208] [OOP] ALLOCATE with SOURCE= or MOLD=: Diagnose if variable occurs twice

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2011-11-18 15:53:51 UTC ---
(In reply to comment #0)
> In ALLOCATE, one gets a diagnosis if one uses:
> 
>integer, allocatable :: i
>allocate(i, stat=i)
>end
> 
> Namely:
>allocate(i, stat=i)
>  1
>Error: Stat-variable at (1) shall not be ALLOCATEd within
>   the same ALLOCATE statement

The above error is easy to produce, because gfortran
only has to check if an alloc-object is used as a
stat-variable.

> 
> However, for SOURCE= and MOLD= it does not work:
> 
>   type t
> integer :: i = 4
>   end type t
>   class(t), allocatable :: x, y
> 
>   allocate(t :: y)
>   allocate(x, mold=x)   ! Not diagnosed
>   allocate(x, source=x) ! Not diagnosed

Doing a check here requires a walk of the mold-expr
and the source-expr, which is of course much more
work (unless gfortran already has a helper function
to check if a variable is used within an expression).

Here's a simple example where walking source-expr
may find the use of the alloc-object:

module bar
  real, allocatable :: x(:)
  contains
  function f(a)
real f
real :: a(:)
f = sum(a)
  end function
end module bar

program foo
  use bar
  allocate(x(2), source=f(x))
  print *, x
end program foo
!
!program foo
!  use bar
!  allocate(x(2), source=f([1., 2.]))
!  print *, x
!end program foo


and here's a more complicated example.

module bar
  real, allocatable :: x(:)
  contains
  function f(a)
real f
real :: a
f = sum(a * x)  ! x used un-allocated?
  end function
end module bar

program foo
  use bar
  allocate(x(2), source=f(2.))
  print *, x
end program foo

[Bug fortran/51208] [OOP] ALLOCATE with SOURCE= or MOLD=: Diagnose if variable occurs twice

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2011-11-18 
16:03:04 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> >allocate(i, stat=i)
> >  1
> >Error: Stat-variable at (1) shall not be ALLOCATEd within
> >   the same ALLOCATE statement
> 
> The above error is easy to produce, because gfortran
> only has to check if an alloc-object is used as a
> stat-variable.

Well, you can make it also more complicated:
  allocate (a(1)%i, stat=a%(2-1)%i)

Or extremely complicated:

  integer, pointer :: ptr
  allocate (ptr, stat=f())
contains
  function f()
integer, pointer :: f
f => ptr
  end function
end

(Recall that a pointer-function result is a variable in Fortran 2008.)


> > However, for SOURCE= and MOLD= it does not work:
> 
> Doing a check here requires a walk of the mold-expr
> and the source-expr, which is of course much more
> work

Well, it is not. One can restrict one to the common case of expr->expr_type ==
EXPR_VARIABLE and just do the same as for STAT=: Checking whether the variable
is the same.


Will that catch all wrong usage? No, but it will catch the most common mistake
of choosing the wrong variable. That's as illustrated above the same with
STAT=.

I am sure that Intel's compiler does not do anything more advanced - and it
would have found the mistake I made in PR 51207.

[Bug libstdc++/51209] The template _M_find_node in hashtable.h has a bad return value

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  
2011-11-18 16:09:36 UTC ---
Author: paolo
Date: Fri Nov 18 16:09:29 2011
New Revision: 181480

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181480
Log:
2011-11-18  Harti Brandt  

PR libstdc++/51209
* include/bits/hashtable.h (_Hashtable<>::_M_find_node): Return
nullptr when no node is found.
* include/tr1/hashtable.h (_Hashtable<>::_M_find_node): Return
zero when no node is found.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/hashtable.h
trunk/libstdc++-v3/include/tr1/hashtable.h

[Bug libstdc++/51209] The template _M_find_node in hashtable.h has a bad return value

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Paolo Carlini  2011-11-18 
16:11:43 UTC ---
Done.

[Bug libstdc++/51209] The template _M_find_node in hashtable.h has a bad return value

[hartmut.brandt at dlr dot de]

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

--- Comment #4 from Harti Brandt  2011-11-18 
16:16:31 UTC ---
Thanks a lot,

harti

From: paolo.carlini at oracle dot com [gcc-bugzi...@gcc.gnu.org]
Sent: Friday, November 18, 2011 5:11 PM
To: Brandt, Hartmut
Subject: [Bug libstdc++/51209] The template _M_find_node in hashtable.h has a
bad return value

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Paolo Carlini  2011-11-18
16:11:43 UTC ---
Done.

--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You reported the bug.

[Bug tree-optimization/50605] ice in ipa_get_jf_pass_through_result with -O3

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Martin Jambor  2011-11-18 
16:32:42 UTC ---
Fixed.

[Bug target/49868] Implement named address space to place/access data in flash memory

[gjl at gcc dot gnu.org]

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

--- Comment #8 from Georg-Johann Lay  2011-11-18 
16:44:12 UTC ---
Author: gjl
Date: Fri Nov 18 16:44:00 2011
New Revision: 181482

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181482
Log:
gcc/
PR target/49868
* config/avr/avr.h (base_arch_s): Add field n_segments.
(ADDR_SPACE_PGM1, ADDR_SPACE_PGM2, ADDR_SPACE_PGM3,
ADDR_SPACE_PGM4, ADDR_SPACE_PGM5, ADDR_SPACE_PGMX): New address spaces.
(AVR_HAVE_ELPM, AVR_HAVE_ELPMX): New defines.
(INIT_EXPANDERS): New define.
* config/avr/avr-protos.h (avr_mem_pgmx_p): New.
(avr_init_expanders): New.
(avr_emit_movmemhi, avr_out_movmem): New.
(avr_xload_libgcc_p): New.
* config/avr/avr-c.c (avr_register_target_pragmas): Register
address spaces __pgm1, __pgm2,  __pgm3,  __pgm4  __pgm5,  __pgmx.
(avr_cpu_cpp_builtins): Add built-in defines __PGM1,
__PGM2, __PGM3, __PGM4, __PGM5, __PGMX.
* config/avr/avr-devices.c (avr_arch_types): Set field n_segments.

* config/avr/avr.c (AVR_SECTION_PROGMEM): Change define to cover
3 bits instead of just 1.
(xstring_empty, xstring_e, rampz_rtx): New static GTYed variables.
(progmem_section): Change from section to array of sections.
(progmem_section_prefix): New static variable.
(avr_file_start): Print set for __RAMPZ__
(avr_option_override): Move initialization of RTXes from here...
(avr_init_expanders): ...to this new function.
(avr_pgm_segment): New static function.
(avr_decl_pgm_p): Handle error_mark_node.
(avr_mem_pgmx_p, avr_decl_pgmx_p): New static functions.
(avr_out_xload,avr_find_unused_d_reg): New static functions.
(expand_prologue, expand_epilogue): Use rampz_rtx.
(print_operand): Hande CONST_STRING.
(avr_xload_libgcc_p): New static function.
(avr_out_lpm_no_lpmx, avr_out_lpm): Handle ELPM.
(avr_progmem_p): Return 2 for 24-bit flash address space.
(avr_out_sbxx_branch): Clean-up code from ASn macros.
(out_movqi_r_mr, out_movqi_mr_r): Ditto. And recognize RAMPZ's
address and print symbolically.
(avr_asm_named_section, avr_section_type_flags,
avr_encode_section_info, avr_asm_select_section,
avr_addr_space_address_mode, avr_addr_space_pointer_mode,
avr_addr_space_legitimate_address_p, avr_addr_space_convert,
avr_addr_space_legitimize_address): Handle new address spaces.
(avr_output_progmem_section_asm_op): New static function.
(avr_asm_init_sections): Initialize progmem_section[].
(adjust_insn_length): Handle ADJUST_LEN_XLOAD, ADJUST_LEN_MOVMEM.
(avr_const_address_lo16): New static function.
(avr_assemble_integer): Use it to handle 3-byte integers.
(avr_emit_movmemhi, avr_out_movmem): New functions.

* config/avr/predicates.md (nox_general_operand): Handle new
address spaces.
* config/avr/avr.md (unspec): Add UNSPEC_MOVMEM.
(adjust_len): Add xload, movmem.
(SP_ADDR): New define_constants.
(isa): Add "lpm", "lpmx", "elpm", "elpmx".
(enabled): Handle them.
(load_libgcc): New expander.
(*load..libgcc): Rename to load__libgcc.
(xload8_A, xload_A): New insn-and-splits.
(xload_8, xload__libgcc, xload_, loadmem_elpm): New insns.
(mov): Handle new address spaces.
(movmemhi): Rewrite using avr_emit_movmemhi.
(MOVMEM_r_d): New mode attribute.
(movmem_, movmem_qi_elpm): New insns.
(setmemhi, *clrmemqi, *clrmemhi, strlenhi, *strlenhi): Unquote
C-code.  Use label instead of hard-coded instrunction lengths.

libgcc/
PR target/49868
* config/avr/t-avr (LIB1ASMFUNCS): Add _xload_2 _xload_3 _xload_4.
* config/avr/lib1funcs.S (__xload_2, __xload_3, __xload_4):
New functions.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr-c.c
trunk/gcc/config/avr/avr-devices.c
trunk/gcc/config/avr/avr-protos.h
trunk/gcc/config/avr/avr.c
trunk/gcc/config/avr/avr.h
trunk/gcc/config/avr/avr.md
trunk/gcc/config/avr/predicates.md
trunk/libgcc/ChangeLog
trunk/libgcc/config/avr/lib1funcs.S
trunk/libgcc/config/avr/t-avr

[Bug c++/51210] New: [C++11][DR 547] std::type_info works incorrectly with function types with cv-qualifier-seq

[daniel.kruegler at googlemail dot com]

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

 Bug #: 51210
   Summary: [C++11][DR 547] std::type_info works incorrectly with
function types with cv-qualifier-seq
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@gcc.gnu.org


gcc 4.7 2012 (experimental) in C++11 mode outputs 

1

in the following program:

//---
#include 
#include 

typedef void FC() const;

int main() {
 std::cout << (typeid(void()) == typeid(FC)) << std::endl;
}
//---

As of C++11 it has been clarified that FC still contains the information of a
function that has a const qualifier. There is no evidence from 5.2.8 that says
that

void() const

and

void()

should give std::type_info objects that evaluate to equal.

The program should output

0

instead.

In regard to the upcoming implementation for functions with ref-qualifier the
same constraints should hold, i.e.

//---
#include 
#include 

typedef void FLR() &;
typedef void FRR() &&;

int main() {
 std::cout << (typeid(void()) == typeid(FLR)) << std::endl;
 std::cout << (typeid(void()) == typeid(FRR)) << std::endl;
}
//---

should output:

0
0

[Bug middle-end/51211] New: ICE: SIGSEGV in execute_tm_mark (trans-mem.c:2242) with -fgnu-tm -O -freorder-blocks -ftracer --param hot-bb-frequency-fraction=1 and __transaction_atomic

[zsojka at seznam dot cz]

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

 Bug #: 51211
   Summary: ICE: SIGSEGV in execute_tm_mark (trans-mem.c:2242)
with -fgnu-tm -O -freorder-blocks -ftracer --param
hot-bb-frequency-fraction=1 and __transaction_atomic
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: amacl...@redhat.com, patrick.marl...@gmail.com
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 25852
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25852
reduced testcase (from g++.dg/tm/nested-2.C)

Compiler output:
$ gcc -fgnu-tm -O -freorder-blocks -ftracer --param hot-bb-frequency-fraction=1
testcase.c
==11106== Invalid read of size 1
==11106==at 0x9DFE6E: execute_tm_mark() (trans-mem.c:2242)
==11106==by 0x8DF684: execute_one_pass(opt_pass*) (passes.c:2074)
==11106==by 0x8DFA24: execute_pass_list(opt_pass*) (passes.c:2129)
==11106==by 0x8DFA36: execute_pass_list(opt_pass*) (passes.c:2130)
==11106==by 0xA4169D: tree_rest_of_compilation(tree_node*)
(tree-optimize.c:420)
==11106==by 0x694D19: cgraph_expand_function(cgraph_node*)
(cgraphunit.c:1819)
==11106==by 0x696ABB: cgraph_optimize() (cgraphunit.c:1886)
==11106==by 0x697229: cgraph_finalize_compilation_unit()
(cgraphunit.c:1327)
==11106==by 0x574EDF: c_write_global_declarations() (c-decl.c:10023)
==11106==by 0x9D4923: toplev_main(int, char**) (toplev.c:581)
==11106==by 0x674ED2C: (below main) (in /lib64/libc-2.12.2.so)
==11106==  Address 0xb0 is not stack'd, malloc'd or (recently) free'd
==11106== 
testcase.c: In function 'foo':
testcase.c:4:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r181442 - crash

[Bug other/51174] AIX unexpected error_mark node in new TM tests

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |aldyh at gcc dot gnu.org
   |gnu.org |

--- Comment #11 from Aldy Hernandez  2011-11-18 
17:39:34 UTC ---
Created attachment 25853
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25853
proposed patch

David, so from the logic in trans-mem.c I assume that DECL_COMDAT is set on AIX
but DECL_COMDAT_GROUP is NULL.  Is this correct?

If that is the case, can you see if this patch fixes your problem?

[Bug rtl-optimization/51187] miscompilation of genrecog.c at -O2 for --target=avr

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|c   |rtl-optimization

--- Comment #6 from Eric Botcazou  2011-11-18 
17:41:01 UTC ---
Recategorizing.

[Bug target/33944] streaming 64-bit integer stores

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-11/msg01938.htm
   ||l
   Last reconfirmed||2011-11-18
 CC||hjl.tools at gmail dot com
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2011-11-18 18:00:24 
UTC ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01938.html

[Bug middle-end/51212] New: ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -fgnu-tm -fnon-call-exceptions and transaction_callable

[zsojka at seznam dot cz]

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

 Bug #: 51212
   Summary: ICE: verify_flow_info failed: BB 3 can not throw but
has an EH edge with -fgnu-tm -fnon-call-exceptions and
transaction_callable
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: amacl...@redhat.com
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -fgnu-tm -fnon-call-exceptions testcase.C 
testcase.C: In function 'void foo(int*)':
testcase.C:9:6: error: BB 3 can not throw but has an EH edge
testcase.C:9:6: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) bt
#0  internal_error (gmsgid=0x1403c6b "verify_flow_info failed") at
/mnt/svn/gcc-trunk/gcc/diagnostic.c:839
#1  0x007ff57f in verify_flow_info () at
/mnt/svn/gcc-trunk/gcc/cfghooks.c:259
#2  0x00a6a0ef in execute_function_todo (data=Unhandled dwarf
expression opcode 0xf3
) at /mnt/svn/gcc-trunk/gcc/passes.c:1722
#3  0x00a6a93d in execute_todo (flags=16392) at
/mnt/svn/gcc-trunk/gcc/passes.c:1751
#4  0x00a6db5a in execute_one_pass (pass=0x199a740) at
/mnt/svn/gcc-trunk/gcc/passes.c:2097
#5  0x00a6de85 in execute_pass_list (pass=0x199a740) at
/mnt/svn/gcc-trunk/gcc/passes.c:2129
#6  0x00bcfafe in tree_rest_of_compilation (fndecl=0x756fdf00) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:420
#7  0x00823b5a in cgraph_expand_function (node=0x755876c0) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1819
#8  0x00825c96 in cgraph_output_in_order () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1984
#9  cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2194
#10 0x0082606a in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1327
#11 0x0064779b in cp_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/cp/decl2.c:4050
#12 0x00b62d84 in compile_file (argc=15, argv=0x7fffdab8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:581
#13 do_compile (argc=15, argv=0x7fffdab8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1931
#14 toplev_main (argc=15, argv=0x7fffdab8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:2007
#15 0x76178d2d in __libc_start_main () from /lib64/libc.so.6
#16 0x0056ba39 in _start ()

Tested revisions:
r181442 - crash

[Bug tree-optimization/50744] [4.7 Regression] ice in good_cloning_opportunity_p

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  2011-11-18 
18:06:18 UTC ---
Proposed fix posted to the mailing list:

http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01935.html

[Bug middle-end/51211] ICE: SIGSEGV in execute_tm_mark (trans-mem.c:2242) with -fgnu-tm -O -freorder-blocks -ftracer --param hot-bb-frequency-fraction=1 and __transaction_atomic

[patrick.marlier at gmail dot com]

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

Patrick Marlier  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #1 from Patrick Marlier  
2011-11-18 18:11:56 UTC ---
This seems to solve the issue but we need to figure out why we get _ITM_RU
here.
Thanks for reporting :)

Patrick Marlier.

Index: trans-mem.c
===
--- trans-mem.c (revision 181466)
+++ trans-mem.c (working copy)
@@ -2211,6 +2211,9 @@
   if (fn_decl == builtin_decl_explicit (BUILT_IN_TM_MEMSET))
 transaction_subcode_ior (region, GTMA_HAVE_STORE);

+  if (flags_from_decl_or_type (fn_decl) & ECF_TM_BUILTIN)
+return false;
+
   if (is_tm_pure_call (stmt))
 return false;

[Bug other/51174] AIX unexpected error_mark node in new TM tests

[dje at gcc dot gnu.org]

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

--- Comment #12 from David Edelsohn  2011-11-18 
18:20:50 UTC ---
Your patch will fix the problem, but, as I wrote in comment 10, I think it is
wrong.  I guess you can change the semantics of tm_mangle() to return NULL for
NULL argument, but it covers up potential bugs.  tm_mangle() should not be
called with NULL argument and any caller that does should be fixed.

[Bug c++/51204] g++ does not link getaddrinfo with -lxnet on OpenIndiana

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  2011-11-18 
18:28:17 UTC ---
Rainer, any idea what is this about?

[Bug c++/51204] g++ does not link getaddrinfo with -lxnet on OpenIndiana

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-11-18 18:38:11 UTC ---
> --- Comment #1 from Paolo Carlini  
> 2011-11-18 18:28:17 UTC ---
> Rainer, any idea what is this about?

No, the testcase links fine for me as with both gcc and g++ 4.6.0, on
Solaris 10 as well as 11.  I don't have OpenIndiana anywhere to try this
myself.

I see that gcc is configured to use GNU ld, against the strong advise to
use Sun ld in the installation guide.

Rainer

[Bug fortran/51208] [OOP] ALLOCATE with SOURCE= or MOLD=: Diagnose if variable occurs twice

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  
2011-11-18 18:40:31 UTC ---
On Fri, Nov 18, 2011 at 04:03:04PM +, burnus at gcc dot gnu.org wrote:
> 
> Well, it is not. One can restrict one to the common case of expr->expr_type ==
> EXPR_VARIABLE and just do the same as for STAT=: Checking whether the variable
> is the same.
> 
> Will that catch all wrong usage? No, but it will catch the most common mistake
> of choosing the wrong variable. That's as illustrated above the same with
> STAT=.
> 
> I am sure that Intel's compiler does not do anything more advanced - and it
> would have found the mistake I made in PR 51207.
> 

Although I think this is equilavent to putting a bandaid
on a AK-47 bullet hole, here you go

troutmask:sgk[246] cat foo.f90

program foo
  use bar
  allocate(x(2), source=x)
end program foo


troutmask:sgk[245] gfc4x -o z -Wall -Wextra foo.f90
foo.f90:4.11-24:

  allocate(x(2), source=x)
   12
Error: Allocate-object at (1) shall not appear in a source-expr or mold-expr at
(2)


Index: resolve.c
===
--- resolve.c(revision 181489)
+++ resolve.c(working copy)
@@ -7173,6 +7173,38 @@ resolve_allocate_deallocate (gfc_code *c
   }
 }

+  /* If source-expr or mold-expr is a variable, check that it
+ is not an alloc-object.  */
+  if (code->expr3 && code->expr3->expr_type == EXPR_VARIABLE)
+{
+  for (p = code->ext.alloc.list; p; p = p->next)
+if (p->expr->symtree->n.sym->name == code->expr3->symtree->n.sym->name)
+  {
+gfc_ref *ref1, *ref2;
+bool found = true;
+
+for (ref1 = p->expr->ref, ref2 = code->expr3->ref; ref1 && ref2;
+ ref1 = ref1->next, ref2 = ref2->next)
+  {
+if (ref1->type != REF_COMPONENT || ref2->type != REF_COMPONENT)
+  continue;
+if (ref1->u.c.component->name != ref2->u.c.component->name)
+  {
+found = false;
+break;
+  }
+  }
+
+if (found)
+  {
+gfc_error ("Allocate-object at %L shall not appear in a "
+   "source-expr or mold-expr at %L",
+&p->expr->where, &code->expr3->where);
+break;
+  }
+  }
+}
+
   /* Check that an allocate-object appears only once in the statement.  
  FIXME: Checking derived types is disabled.  */
   for (p = code->ext.alloc.list; p; p = p->next)

[Bug c++/51141] [4.7 regression] rev181359 causes Chromium build failure

[fabien at gcc dot gnu.org]

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

--- Comment #4 from fabien at gcc dot gnu.org 2011-11-18 18:44:25 UTC ---
Author: fabien
Date: Fri Nov 18 18:44:23 2011
New Revision: 181490

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

2011-11-18  Fabien Chene  

PR c++/51141
* g++.dg/lookup/using46.C: New.
* g++.dg/lookup/using47.C: New.
* g++.dg/lookup/using48.C: New.
* g++.dg/lookup/using49.C: New.
* g++.dg/lookup/using50.C: New.

gcc/cp/ChangeLog

2011-11-18  Fabien Chene  

PR c++/51141
* search.c (lookup_field_1): Handle USING_DECLs for the storted
case.

Added:
trunk/gcc/testsuite/g++.dg/debug/using6.C
trunk/gcc/testsuite/g++.dg/lookup/using46.C
trunk/gcc/testsuite/g++.dg/lookup/using47.C
trunk/gcc/testsuite/g++.dg/lookup/using48.C
trunk/gcc/testsuite/g++.dg/lookup/using49.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/search.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/51208] [OOP] ALLOCATE with SOURCE= or MOLD=: Diagnose if variable occurs twice

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2011-11-18 
19:02:25 UTC ---
(In reply to comment #3)
> Although I think this is equivalent to putting a bandaid
> on a AK-47 bullet hole, here you go

Thanks for the patch. Only one remark: For
  allocate (x(2)%a, source=x(1)%a)
one gets a false positive.

[Bug target/33944] streaming 64-bit integer stores

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  2011-11-18 
19:02:49 UTC ---
Author: hjl
Date: Fri Nov 18 19:02:45 2011
New Revision: 181491

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

2011-11-18  H.J. Lu  

PR target/33944
* doc/extend.texi: Document __builtin_ia32_movnti64.

* config/i386/emmintrin.h (_mm_stream_si64): New.

* config/i386/i386-builtin-types.def: Add VOID_FTYPE_PLONGLONG_LONGLONG.

* config/i386/i386.c (ix86_builtins): Add IX86_BUILTIN_MOVNTI64.
(bdesc_special_args): Update __builtin_ia32_movnti.  Add
__builtin_ia32_movnti64.
(ix86_expand_special_args_builtin): Handle
VOID_FTYPE_PLONGLONG_LONGLONG.

* config/i386/i386.md (UNSPEC_MOVNTI): New.

* config/i386/sse.md (sse2_movntsi): Renamed to ...
(sse2_movnti): This.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/emmintrin.h
trunk/gcc/config/i386/i386-builtin-types.def
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/sse.md
trunk/gcc/doc/extend.texi

[Bug c++/51203] [C++0x] Recursive alias template specialization causes compiler segfault

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #2 from Daniel Krügler  
2011-11-18 19:03:14 UTC ---
(In reply to comment #1)
> template 
> struct foo {
>   template 
>   using next = typename foo::next;
>   template <>
>   using next<10> = int; // not sure if alias templates can be specialized
> };

Alias templates cannot be specialized, this is by design.

[Bug c++/51204] g++ does not link getaddrinfo with -lxnet on OpenIndiana

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #3 from Paolo Carlini  2011-11-18 
19:12:53 UTC ---
Thanks. Thus I say let's close this as worksforme, please re-open if something
similar happens also with Sun ld.

[Bug c++/51145] [C++11][DR 1131] Alias template in elaborated-type-specifier accepted

[dodji at gcc dot gnu.org]

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

--- Comment #4 from Dodji Seketeli  2011-11-18 
19:16:52 UTC ---
A candidate fix has been posted to
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01945.html

[Bug c++/51194] [C++0x] ICE about template aliasing

[dodji at gcc dot gnu.org]

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

--- Comment #4 from Dodji Seketeli  2011-11-18 
19:18:46 UTC ---
Here is a smaller reproducer:

template
struct foo {};

template
struct P {};

template class... TT>
struct bar {
template
using mem = P...>;
};

bar::mem b;

[Bug fortran/51197] [4.7 Regression] Backtrace information less useful

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  2011-11-18 19:34:38 
UTC ---
(In reply to comment #4)
> (In reply to comment #2)
> > So it would be nice to actually write the SIG* information also
> > to stderr.
> 
> (In reply to comment #3)
> > So to get back to the stdout/stderr issue, in 4.7 the last line of the 
> > output
> > is not printed by libgfortran but rather by the OS (libc?) default signal
> > handler for that signal (just like happens with -fno-backtrace). So 
> > libgfortran
> > has no say in where it goes.
> 
> Harald, does this solve the issue? Or do you think that gfortran should 
> replace
> the standard handler?

If this means writing

Program received signal 8 (SIGFPE).

to stderr (which is where the backtrace dump goes)
before the actual backtrace, this would be perfect.

(I could even live well without "A fatal error occurred!",
but I'll leave that up to you.)

No need to mess with anything else.

Thanks,
Harald

[Bug fortran/51208] [OOP] ALLOCATE with SOURCE= or MOLD=: Diagnose if variable occurs twice

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  
2011-11-18 19:49:32 UTC ---
On Fri, Nov 18, 2011 at 07:02:25PM +, burnus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51208
> 
> --- Comment #4 from Tobias Burnus  2011-11-18 
> 19:02:25 UTC ---
> (In reply to comment #3)
> > Although I think this is equivalent to putting a bandaid
> > on a AK-47 bullet hole, here you go
> 
> Thanks for the patch. Only one remark: For
>   allocate (x(2)%a, source=x(1)%a)
> one gets a false positive.
> 

bandaid (adj) -- Informal. serving as a makeshift, limited,
or temporary aid or solution

:-)

The error message can be disable for derived type objects via

  if (found && p->expr->symtree->n.sym->ts.type != BT_DERIVED)

now one may get accepts-invalid over a false-positive.

[Bug java/1131] make fails on solaris 2.5.1 and 2.6

[dodji at seketeli dot org]

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

--- Comment #5 from dodji at seketeli dot org  
2011-11-18 19:50:42 UTC ---
"jason at gcc dot gnu.org"  a écrit:
>
> --- Comment #3 from Jason Merrill  2011-11-18 
> 13:11:48 UTC ---
> (In reply to comment #2)
> Let's share the "previous declaration" message between the two cases, and
> change it to inform.

Woops, I somehow managed to miss this message before posting my patch.
I'll amend the patch, chase the tests cases to update and re-submit the
patch. 

Thanks.

[Bug c++/51204] g++ does not link getaddrinfo with -lxnet on OpenIndiana

[johann at myrkraverk dot com]

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

Johann 'Myrkraverk' Oskarsson  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |

--- Comment #4 from Johann 'Myrkraverk' Oskarsson  2011-11-18 19:54:40 UTC ---
The system supplied g++, 4.6.1, which uses the Sun ld also fails:

  johann@asuka:C++/CompilerBugs(1)% g++ SolarisG++4.6.2-lxnet.c++ -lxnet
  Undefined  first referenced
   symbolin file
  __xnet_getaddrinfo  /var/tmp//ccFXaiyD.o
  ld: fatal: symbol referencing errors. No output written to a.out
  collect2: ld returned 1 exit status
  johann@asuka:C++/CompilerBugs(1)%

[Bug c++/51213] New: [C++11][DR 1170] Access control checking has to be done under SFINAE conditions

[daniel.kruegler at googlemail dot com]

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

 Bug #: 51213
   Summary: [C++11][DR 1170] Access control checking has to be
done under SFINAE conditions
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@gcc.gnu.org


gcc 4.7 2012 (experimental) in C++11 mode rejects the following code:

//---
class C {
  typedef int type; // Line 2
};

template
auto f(int) -> char;

template
auto f(...) -> char (&)[2];

static_assert(sizeof(f(0)) == 2, "Ouch"); // Line 11

template
auto g(int) -> decltype(typename T::type(), char());

template
auto g(...) -> char (&)[2];

static_assert(sizeof(g(0)) == 2, "Ouch"); // Line 19

int main() {}
//---

"main.cpp|11|error: static assertion failed: "Ouch"|
main.cpp||In function 'decltype ((typename T::type(), char())) g(int) [with T =
C; decltype ((typename T::type(), char())) = char; typename T::type = int]':|
main.cpp|2|error: 'typedef int C::type' is private|
main.cpp|19|error: within this context|
main.cpp|19|error: static assertion failed: "Ouch"|"

After approval of DR 1170:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1170

access checking has become part of the template substitution process as
described in 14.8.2 p8:

"If a substitution results in an invalid type or expression, type deduction
fails. An invalid type or expression is one that would be ill-formed if written
using the substituted arguments. [ Note: Access checking is done as part of the
substitution process. —end note ] [..]"

This means as of C++11 above program should be accepted.

[Bug c/37187] please provide a way to treat -pedantic as warning when using -Werror

[skunk at iskunk dot org]

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

Daniel Richard G.  changed:

   What|Removed |Added

 CC||skunk at iskunk dot org

--- Comment #5 from Daniel Richard G.  2011-11-18 
20:06:13 UTC ---
There is still no way to defang -pedantic warnings with -Werror as of GCC
4.6.1.

[Bug c++/51214] New: [C++11] name lookup issue with c++11 enums

[fabien at gcc dot gnu.org]

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

 Bug #: 51214
   Summary: [C++11] name lookup issue with c++11 enums
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fab...@gcc.gnu.org


Noticed while working on PR c++/51188, I have launched the c++ testsuite with
the patch below:
Index: class.c
===
--- class.c(revision 181491)
+++ class.c(working copy)
@@ -6007,7 +6007,7 @@ finish_struct_1 (tree t)
  hierarchy), and we want this failure to occur quickly.  */

   n_fields = count_fields (TYPE_FIELDS (t));
-  if (n_fields > 7)
+  if (n_fields > 0)

And it has raised two errors related to c++11 enums: forw_enum5.C and
forw_enum9.C. Thus, here is a reproducer, comming from forw_enum5.C:

// { dg-do compile }
// { dg-options "-std=c++0x" }

namespace one
{
struct S
{
enum { A = 1, B = 2 };
struct T
{
int i1, i2, i3, i4, i5, i6, i7;

enum { B = 102 };

enum class E1;
enum E2 : int;
};
};

static_assert(int(S::T::A1) == 1, "error");
static_assert(int(S::T::B1) == 102, "error");
static_assert(int(S::T::C1) == 103, "error");
}

The following errors are issued:

error: 'A1' is not a member of 'one::S::T'

error: 'B1' is not a member of 'one::S::T'

error: 'C1' is not a member of 'one::S::T'


Most likely an issue in the sorted case of lookup_field_1. Mine.

[Bug c++/51214] [C++11] name lookup issue with c++11 enums

[fabien at gcc dot gnu.org]

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

fabien at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug tree-optimization/50802] [4.7 Regression] FAIL: gcc.c-torture/execute/arith-rand-ll.c execution at -O2 and -Os

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu.org

--- Comment #13 from Jorn Wolfgang Rennecke  
2011-11-18 20:20:22 UTC ---
(In reply to comment #1)

> The r2 value is wrong.

I see the same problem on Epiphany.
The result of the modulo operation for short int is recycled for signed char.
arith-rand-ll.c.079t.copyrename3 looks OK, but in arith-rand-ll.c.080t.dom1
I see that ill-advised recycling of the modulo result, D.2263_64 in the
below dump snippets:

:
  xx_56 = (short int) x_5;
  # DEBUG xx => xx_56
  yy_57 = (short int) y_6;
  # DEBUG yy => yy_57
  D.2260_58 = (int) x_5;
  D.2261_59 = (int) y_6;
  D.2262_60 = D.2260_58 / D.2261_59;
  # DEBUG r1 => (short int) D.2262_60
  D.2263_64 = D.2260_58 % D.2261_59;
  r2_65 = (short int) D.2263_64;
  # DEBUG r2 => r2_65
  D.2266_66 = (int) r2_65;
  D.2267_67 = ABS_EXPR ;
  if (yy_57 >= 0)
goto ;
  else
goto ;
...
:
  r1.4_73 = (short unsigned int) D.2262_60;
  yy.3_74 = (short unsigned int) y_6;
  D.2276_75 = r1.4_73 * yy.3_74;
  r2.5_76 = (short unsigned int) D.2263_64;
  D.2278_77 = D.2276_75 + r2.5_76;
  D.2279_78 = (short int) D.2278_77;
  if (D.2279_78 != xx_56)
goto ;
  else
goto ;
...
:
  xx_89 = (signed char) x_5;
  # DEBUG xx => xx_89
  yy_90 = (signed char) y_6;
  # DEBUG yy => yy_90
  D.2291_91 = D.2260_58;
  D.2292_92 = D.2261_59;
  D.2293_93 = D.2262_60;
  # DEBUG r1 => (signed char) D.2262_60
  D.2294_97 = D.2263_64;
  r2_98 = (signed char) D.2263_64;
  # DEBUG r2 => r2_98
  D.2297_99 = (int) r2_98;
  D.2298_100 = ABS_EXPR ;
  if (yy_90 >= 0)
goto ;
  else
goto ;
...
:
  r1.8_106 = (unsigned char) D.2262_60;
  yy.7_107 = (unsigned char) y_6;
  D.2307_108 = r1.8_106 * yy.7_107;
  r2.9_109 = (unsigned char) D.2263_64;
  D.2309_110 = D.2307_108 + r2.9_109;
  D.2310_111 = (signed char) D.2309_110;
  if (D.2310_111 != xx_89)
goto ;
  else
goto ;

[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'

[fabien at gcc dot gnu.org]

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

--- Comment #14 from fabien at gcc dot gnu.org 2011-11-18 20:32:08 UTC ---
Author: fabien
Date: Fri Nov 18 20:32:04 2011
New Revision: 181492

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

2011-11-18  Fabien Chene  

PR c++/51188
* g++.dg/lookup/using46.C: New.
* g++.dg/lookup/using47.C: New.
* g++.dg/lookup/using48.C: New.
* g++.dg/lookup/using49.C: New.
* g++.dg/lookup/using50.C: New.

gcc/cp/ChangeLog

2011-11-18  Fabien Chene  

PR c++/51188
* search.c (lookup_field_1): Handle USING_DECLs for the storted
case.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug c++/51188] invalid static_cast from type 'XBase' to type 'int'

[fabien at gcc dot gnu.org]

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

fabien at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #15 from fabien at gcc dot gnu.org 2011-11-18 20:36:54 UTC ---
Fixed by rev 181490, not 181492.

[Bug tree-optimization/50802] [4.7 Regression] FAIL: gcc.c-torture/execute/arith-rand-ll.c execution at -O2 and -Os

[amylaar at gcc dot gnu.org]

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

--- Comment #14 from Jorn Wolfgang Rennecke  
2011-11-18 21:02:01 UTC ---
(In reply to comment #2)
> Introduced by the following change:
> 
> 2011-10-17  Richard Guenther  
> 
> PR tree-optimization/50729
> * tree-vrp.c (extract_range_from_unary_expr_1): Remove
> redundant test.
> (simplify_conversion_using_ranges): Properly test the
> intermediate result.

I can confirm that backing out this patch makes the arith-rand-ll.c
failure go away on Epiphany.
Backing out only the first hunk doesn't help.
Backing out only the send hunk does.
And, FWIW, LOAD_EXTEND_OP is also ZERO_EXTEND on the Epiphany.

[Bug other/51125] FAIL: g++.dg/tm/pr45940-3.C

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-11-18
 CC||aldyh at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #4 from Aldy Hernandez  2011-11-18 
21:12:01 UTC ---
Michael.

This regression was caused by the following patch.  Perhaps the reason nobody
caught it was because it came 5 hours after the transactional-memory branch was
merged, perhaps too close for everyone to have re-tested their patches.

Do you mind taking a look at this?

r181172 | matz | 2011-11-08 10:47:16 -0600 (Tue, 08 Nov 2011) | 44 lines

* gengtype.c (write_field_root): Avoid out-of-scope access of newv.

* tree-stdarg.c (execute_optimize_stdarg): Accept clobbers.
* tree.h (TREE_CLOBBER_P): New macro.
* gimple.h (gimple_clobber_p): New inline function.
* gimplify.c (gimplify_bind_expr): Add clobbers for all variables
that go out of scope and live in memory.
* tree-ssa-operands.c (get_expr_operands): Transfer volatility also
for constructors.
* cfgexpand.c (decl_to_stack_part): New static variable.
(add_stack_var): Allocate it, and remember mapping.
(fini_vars_expansion): Deallocate it.
(stack_var_conflict_p): Add early outs.
(visit_op, visit_conflict, add_scope_conflicts_1,
add_scope_conflicts): New static functions.
(expand_used_vars_for_block): Don't call add_stack_var_conflict, tidy.
(expand_used_vars): Add scope conflicts.
(expand_gimple_stmt_1): Expand clobbers to nothing.
(expand_debug_expr): Ditto.

[Bug tree-optimization/50802] [4.7 Regression] FAIL: gcc.c-torture/execute/arith-rand-ll.c execution at -O2 and -Os

[amylaar at gcc dot gnu.org]

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

--- Comment #15 from Jorn Wolfgang Rennecke  
2011-11-18 22:15:29 UTC ---
Created attachment 25855
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25855
Preprocessed testcase for epiphany

I can't reproduce the test on gcc20, I think this is a 32 vs. 64 bit
build and/or host machine issue.

I can reproduce the problem on a 32 bit system:
Linux purzah 3.1.1-1.fc16.i686.PAE #1 SMP Fri Nov 11 22:04:40 UTC 2011 i686
i686 i386 GNU/Linux

I have used trunk revision 181442 .

configured for --target=epiphany-elf .

You don't need Epiphany for this, you can just make "all-gcc", and when
it has configured the gcc build directory, you can stop the build, cd to the
gcc build directory, and build just cc1.

compile the preprocessed sources with:

./cc1 -O2 -dumpbase arith-rand-ll.c arith-rand-ll.i -o arith-rand-ll.s
-fdump-tree-all

in arith-rand-ll.c.080t.dom1, you can see in line 543
  r2_98 = (signed char) D.2263_64

earlier, the same ssa variable has been used in
  r2_65 = (short int) D.2263_64;

both uses are, in fact, incorrect, because D.2263_64 is calculated as 32
bit signed modulo of 32 bit x and y.

[Bug target/51204] g++ does not link getaddrinfo with -lxnet on OpenIndiana

[johann at myrkraverk dot com]

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

Johann 'Myrkraverk' Oskarsson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #5 from Johann 'Myrkraverk' Oskarsson  2011-11-18 22:24:08 UTC ---
This has been reported as a bug 1794 in Illumos.

[Bug target/51204] g++ does not link getaddrinfo with -lxnet on OpenIndiana

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  2011-11-18 
22:27:22 UTC ---
Ah Ok, let's add this: https://www.illumos.org/issues/1794

[Bug tree-optimization/50802] [4.7 Regression] FAIL: gcc.c-torture/execute/arith-rand-ll.c execution at -O2 and -Os

[amylaar at gcc dot gnu.org]

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

--- Comment #16 from Jorn Wolfgang Rennecke  
2011-11-18 22:45:10 UTC ---
(In reply to comment #15)

I can also replicate this on gcc45 using trunk revision 181496.

[Bug c++/51215] New: [4.7 Regression] ICE with invalid array initializer

[reichelt at gcc dot gnu.org]

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

 Bug #: 51215
   Summary: [4.7 Regression] ICE with invalid array initializer
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


The following invalid line of code triggers an ICE on trunk:

==
int x[] = { [0.] {} };
==

bug.cc:1:14: error: expected identifier before numeric constant
bug.cc:1:21: internal compiler error: in check_array_designated_initializer, at
cp/decl.c:4679
Please submit a full bug report, [etc.]

[Bug c++/51215] [4.7 Regression] ICE with invalid array initializer

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
   Target Milestone|--- |4.7.0

[Bug middle-end/51211] ICE: SIGSEGV in execute_tm_mark (trans-mem.c:2242) with -fgnu-tm -O -freorder-blocks -ftracer --param hot-bb-frequency-fraction=1 and __transaction_atomic

[patrick.marlier at gmail dot com]

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

--- Comment #2 from Patrick Marlier  
2011-11-18 22:52:44 UTC ---
After looking at it. I guess the problem was in the tracer...
The tracer tries to duplicate the BB where the __transaction_atomic is.
Unfortunately this is not valid with trans-mem passes. Either duplicate all
blocks of the transaction or forbid the duplicate of the block. I choose the
second one.

Patrick Marlier.

Index: gcc/tracer.c
===
--- gcc/tracer.c(revision 181425)
+++ gcc/tracer.c(working copy)
@@ -90,10 +90,14 @@
 static bool
 ignore_bb_p (const_basic_block bb)
 {
+  gimple g;
   if (bb->index < NUM_FIXED_BLOCKS)
 return true;
   if (optimize_bb_for_size_p (bb))
 return true;
+  g = last_stmt (CONST_CAST_BB (bb));
+  if (g && gimple_code (g) == GIMPLE_TRANSACTION)
+return true;
   return false;
 }

[Bug c++/51216] New: [4.6/4.7 Regression] ICE with statement expression

[reichelt at gcc dot gnu.org]

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

 Bug #: 51216
   Summary: [4.6/4.7 Regression] ICE with statement expression
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


The following code snippet triggers an ICE since GCC 4.6.0 when compiled with
"-std=c++0x":

==
void foo()
{
  int i = ({ if (1) ; });
}
==

bug.cc: In function 'void foo()':
bug.cc:3:24: sorry, unimplemented: unexpected AST of kind if_stmt
bug.cc:3:24: internal compiler error: in potential_constant_expression_1, at
cp/semantics.c:8426
Please submit a full bug report, [etc.]

[Bug c/51217] New: Cannot disable bootstrap in gcc 3.4.0

[songlinhai0543 at gmail dot com]

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

 Bug #: 51217
   Summary: Cannot disable bootstrap in gcc 3.4.0
Classification: Unclassified
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: songlinhai0...@gmail.com


I am doing an experiment on gcc 3.4.0, and my experiment requires that build a
gcc under version 3.4.0 without bootstrap. 

But after I add --disable-bootstrap in my configure, gcc is still built with
bootstrap.

Any suggestions about how to fix this?

[Bug c++/51216] [4.6/4.7 Regression] ICE with statement expression

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   Target Milestone|--- |4.6.3

[Bug bootstrap/51217] Cannot disable bootstrap in gcc 3.4.0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |bootstrap
 Resolution||WONTFIX

--- Comment #1 from Andrew Pinski  2011-11-18 
23:00:18 UTC ---
Yes, just use "make all-gcc" . Also 3.4.x is no longer supported. and IIRC it
did not have toplevel bootstrap which means you have to build with make
bootstrap to get a bootstrapped compiler.

[Bug fortran/51218] New: [4.7 Regression] Potential optimization bug

[anlauf at gmx dot de]

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

 Bug #: 51218
   Summary: [4.7 Regression] Potential optimization bug
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: anl...@gmx.de


Hi all,

the attached code crashes at runtime with gfortran 4.7
(svn rev. 181390) when compiled with optimization (-O1 and higher).

It works when compiled with -O0, with gfortran 4.6 and earlier
at any optimization level tested, and a series of other compilers.

Can anybody shed some light on this problem?

Depending on the active line in the main program,

!
! Either expression leads to a crash:
  u  = sum(xi*wi) + sum(xi*wi)
! u  = sum(xi*wi  + xi*wi)
!

I get a backtrace or a

*** glibc detected *** ./a.out: double free or corruption (fasttop): 0x080743a0
*

Activating the following print

!###
!print *, "vector_times_vector: barrier"
!###

in module mo_dec_matrix makes the crash disappear.

Thanks,
Harald

[Bug fortran/51218] [4.7 Regression] Potential optimization bug

[anlauf at gmx dot de]

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

--- Comment #1 from Harald Anlauf  2011-11-18 23:08:09 
UTC ---
Created attachment 25856
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25856
Source archive

[Bug target/49868] Implement named address space to place/access data in flash memory

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords|patch   |
   Target Milestone|--- |4.7.0

[Bug tree-optimization/50729] [4.7 Regression] Silent code gen fault: Value range propagation seems to propagate values across narrowing/widening

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||amylaar at gcc dot gnu.org
 Resolution|FIXED   |

--- Comment #7 from Jorn Wolfgang Rennecke  
2011-11-18 23:13:49 UTC ---
When innerop is unsigned, and middleop is signed, the value computed
for middlemax is bogus.
The original test would catch that condition, the new test doesn't.

[Bug middle-end/39976] [4.5/4.6/4.7 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
 AssignedTo|unassigned at gcc dot   |wschmidt at gcc dot gnu.org
   |gnu.org |

--- Comment #40 from William J. Schmidt  
2011-11-18 23:21:25 UTC ---
OK, sounds good.  I'll take this one.

[Bug c++/51216] [4.6/4.7 Regression] ICE with statement expression

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #1 from Paolo Carlini  2011-11-18 
23:21:46 UTC ---
Likewise for { while (1) ; } or { for (;;) ; } for example.

[Bug c++/51219] New: ICE with structure initializer

[reichelt at gcc dot gnu.org]

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

 Bug #: 51219
   Summary: ICE with structure initializer
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


The following valid code snippet triggers an ICE on trunk:

===
struct A
{
  int i;
  int : 8;
};

void foo()
{
  A a = { .i = 0 };
}
===

bug.cc: In function 'void foo()':
bug.cc:7:6: error: non-trivial conversion at assignment
signed char
int
a.D.1836 = 0;

bug.cc:7:6: internal compiler error: verify_gimple failed
Please submit a full bug report, [etc.]

[Bug fortran/51218] [4.7 Regression] Potential optimization bug

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  2011-11-18 
23:27:01 UTC ---
Revision 171100 is OK
revision  171653 segfault .

[Bug fortran/51218] [4.7 Regression] Potential optimization bug

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #3 from Dominique d'Humieres  2011-11-19 
00:03:49 UTC ---
The miscompilation is triggered by -ffrontend-optimize, work-around: use
-fno-frontend-optimize.
Revision 171653 is dealing with the frontend optimization. If I am not
mistaken, it is the only change dealing with frontend optimization after
r171100, although I don't understand how this revision could cause a
miscompilation.

The crash occurs in __mo_dec_matrix_MOD_sum_vector.

[Bug tree-optimization/50729] [4.7 Regression] Silent code gen fault: Value range propagation seems to propagate values across narrowing/widening

[amylaar at gcc dot gnu.org]

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

--- Comment #8 from Jorn Wolfgang Rennecke  
2011-11-19 00:03:56 UTC ---
More specifically, the problem appears when innerop has a different signedness
than middleop, and the value range of middleop is such that the topmost bit
of a double_int is used.
E.g. the full value range of a 64 bit long long with 32 bit HOST_WIDE_INT,
or a 128 bit integer type with a 64 bit HOST_WIDE_INT.

OTOH both the old and the new test will reject some simplifications that
would be OK when considering a narrow finaltype, and/or same-size
signed/unsigned conversion.

The basic problem is that when a signedness change happens, we are no longer
necessarily considering a single range, but possibly two.

[Bug fortran/51218] [4.7 Regression] Potential optimization bug

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org 2011-11-19 00:40:49 UTC ---
(In reply to comment #3)
> The miscompilation is triggered by -ffrontend-optimize, work-around: use
> -fno-frontend-optimize.
> Revision 171653 is dealing with the frontend optimization. If I am not
> mistaken, it is the only change dealing with frontend optimization after
> r171100, although I don't understand how this revision could cause a
> miscompilation.
> 
> The crash occurs in __mo_dec_matrix_MOD_sum_vector.

Looks like a bug in the application, but the interesting
coding style makes it hard for me to read.  If one removes

call delete_storage (x)

in sum_vector the problem goes away.  That is, it looks like
over-active memory management hidden beneath a layer of 
obfusication.

[Bug tree-optimization/50802] [4.7 Regression] FAIL: gcc.c-torture/execute/arith-rand-ll.c execution at -O2 and -Os

[amylaar at gcc dot gnu.org]

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

--- Comment #17 from Jorn Wolfgang Rennecke  
2011-11-19 02:05:05 UTC ---
Created attachment 25857
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25857
Proposed patch

Could you test if this also fixes your regressions?

[Bug tree-optimization/50729] [4.7 Regression] Silent code gen fault: Value range propagation seems to propagate values across narrowing/widening

[amylaar at gcc dot gnu.org]

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

--- Comment #9 from Jorn Wolfgang Rennecke  
2011-11-19 02:06:36 UTC ---
I've added a patch attachment to PR50802 that replaces the test.

[Bug fortran/51218] [4.7 Regression] Potential optimization bug

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  
2011-11-19 03:47:39 UTC ---
On Sat, Nov 19, 2011 at 12:40:49AM +, kargl at gcc dot gnu.org wrote:
> > The miscompilation is triggered by -ffrontend-optimize, work-around: use
> > -fno-frontend-optimize.
> > Revision 171653 is dealing with the frontend optimization. If I am not
> > mistaken, it is the only change dealing with frontend optimization after
> > r171100, although I don't understand how this revision could cause a
> > miscompilation.
> > 
> > The crash occurs in __mo_dec_matrix_MOD_sum_vector.
> 
> Looks like a bug in the application, but the interesting
> coding style makes it hard for me to read.  If one removes
> 
> call delete_storage (x)
> 
> in sum_vector the problem goes away.  That is, it looks like
> over-active memory management hidden beneath a layer of 
> obfusication.
> 

Having looked at the code some more, I believe it is noconforming,
and this PR should be closed with INVALID,

[Bug tree-optimization/50904] [4.7 regression] pessimization when -fno-protect-parens is enabled by -Ofast

[venkataramanan.kumar.gnu at gmail dot com]

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

--- Comment #16 from Venkataramanan Kumar  2011-11-19 04:25:27 UTC ---
(In reply to comment #13)
> (In reply to comment #12)
> > Created attachment 25764 [details]
> > Tentative fix (3)
> > Final version.  Can someone try it on his favorite Fortran benchmark?
> Ok I will check and let you know the results.

Hi Eric, 

I tested on machine with -march=amdfam10, with your patch induct run time
improves by ~5%. Other benchmarks are not affected much. 

With your patch, CPU2006 benchmark "416.gamess" fails during validation.
Mimimal flag -O3 -fno-tree-pre -mfma4. I am trying to reduce the test case.
Please let me know if you have any other suggestions.

[Bug c++/50306] ambiguous templated conversion operators accepted

[malaperle at omnialabs dot net]

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

--- Comment #3 from Marc-Andre Laperle  
2011-11-19 05:38:32 UTC ---
I tried 4.6.2, r181503 and r180166 and they all compiled the sample code
without error. Do you have any local changes or special parameters that made it
not compile?

[Bug tree-optimization/50904] [4.7 regression] pessimization when -fno-protect-parens is enabled by -Ofast

[ebotcazou at gcc dot gnu.org]

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

--- Comment #17 from Eric Botcazou  2011-11-19 
07:17:58 UTC ---
> I tested on machine with -march=amdfam10, with your patch induct run time
> improves by ~5%. Other benchmarks are not affected much. 

OK, thanks.

> With your patch, CPU2006 benchmark "416.gamess" fails during validation.
> Mimimal flag -O3 -fno-tree-pre -mfma4. I am trying to reduce the test case.
> Please let me know if you have any other suggestions.

I think that this should be handled at the Tree level.  The missed optimization
opportunities are there, with or without -fprotect-parens.