[Bug c++/51476] [c++0x] [4.7 Regression] ICE with invalid pointer-to-member template parameter

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Dodji Seketeli  2011-12-14 
08:47:01 UTC ---
Fixed in trunk (4.7).

[Bug c++/51476] [c++0x] [4.7 Regression] ICE with invalid pointer-to-member template parameter

[dodji at gcc dot gnu.org]

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

--- Comment #3 from Dodji Seketeli  2011-12-14 
08:46:27 UTC ---
Author: dodji
Date: Wed Dec 14 08:46:13 2011
New Revision: 182324

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182324
Log:
PR c++/51476 - ICE on PTRMEM_CST as template argument in c++11

gcc/cp/

PR c++/51476
* pt.c (convert_nontype_argument): Don't call maybe_constant_value
for PTRMEM_CST nodes.

gcc/testsuite/

PR c++/51476
* g++.dg/cpp0x/ptrmem-cst-arg1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/ptrmem-cst-arg1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/51529] [OOP] gfortran.dg/class_to_type_1.f03 is miscompiled: Uninitialized variable used

[paul.richard.thomas at gmail dot com]

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

--- Comment #3 from paul.richard.thomas at gmail dot com  2011-12-14 08:55:08 UTC ---
Dear Tobias,

> However, I do now understand why one needs for SOURCE= to memset the source to
> NULL - at least as long _copy not only copies the data but also frees it. The
> latter could be also left to _free. - Actually, I am in favour of separating
> _copy and _free. As this issue shows, there are cases where one does not want
> to combine them, leading to work around actions (memset). I think only for
> polymorphic assignment, one needs _free + _copy, for allocate with SOURCE= a
> _copy should be enough.

The memset came about for similar reasons with class objects with
allocatable components.  I had missed this wrinkle with the testcase.
My inclination is to restire the memset and keep the PR open.

I am am trying to clear up some issues of functionality, starting with
the failure of a%disp() to scalarize properly in class_array_3.f03.
Then I have mind to understand the failure of vector indexing in
gfc_trans_call and finally to deal with class array components and
class array subreferences.  After the tidy up :-)

Cheers

Paul

[Bug c++/51475] [c++0x] [4.7 Regression] ICE with invalid initializer_list

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

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

--- Comment #5 from Dodji Seketeli  2011-12-14 
09:07:00 UTC ---
OK, I'll look at it some more.

[Bug c/51548] It is impossible to provide translations of some gcc error messages

[niva at niisi dot msk.ru]

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

--- Comment #1 from niva at niisi dot msk.ru 2011-12-14 09:20:37 UTC ---
I have reworked c_parse_error in gcc-4.1.2 using c-common.c from gcc-3.4.6 as a
sample. I have also used gcc/po/exgettext from gcc-4.5.1 in order to put
messages passed from functions c_parse_require, c_parse_require_keyword, etc.
(c-parser.c) to gcc.pot. This seems to solve the problem.

[Bug libstdc++/51540] partial_sum (int *, int *, int *, multiplies < int >) does not use operator +(complex, complex)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #4 from Paolo Carlini  2011-12-14 
09:38:39 UTC ---
When you follow?!? Simply there are no complex numbers in your code. Full stop.

[Bug tree-optimization/51254] Missed Optimization: IVOPTS don't handle unaligned memory access.

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  
2011-12-14 09:38:51 UTC ---
On Wed, 14 Dec 2011, duyuehai at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51254
> 
> --- Comment #5 from Yuehai Du  2011-12-14 02:29:07 
> UTC ---
> (In reply to comment #4)
> > On Tue, 13 Dec 2011, duyuehai at gmail dot com wrote:
> > 
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51254
> > > 
> > > Yuehai Du  changed:
> > > 
> > >What|Removed |Added
> > > 
> > >  CC||duyuehai at gmail dot 
> > > com,
> > >||rguenth at gcc dot 
> > > gnu.org
> > > 
> > > --- Comment #2 from Yuehai Du  2011-12-13 
> > > 04:15:12 UTC ---
> > > Hi Richard
> > >   would it be ok if i submit a patch like this to fix this bug:
> > > 
> > > Index: gcc/tree-ssa-loop-ivopts.c
> > > ===
> > > --- gcc/tree-ssa-loop-ivopts.c(版本 182270)
> > > +++ gcc/tree-ssa-loop-ivopts.c(工作副本)
> > > @@ -102,6 +102,7 @@ along with GCC; see the file COPYING3.  If not see
> > > cost of different addressing modes.  This should be moved to a TBD
> > > interface between the GIMPLE and RTL worlds.  */
> > >  #include "expr.h"
> > > +#include "optabs.h"
> > > 
> > >  /* The infinite cost.  */
> > >  #define INFTY 1000
> > > @@ -1771,6 +1772,7 @@ find_interesting_uses_address (struct ivopts_data
> > >  }
> > >else
> > >  {
> > > +  enum machine_mode mem_mode;
> > >ifs_ivopts_data.ivopts_data = data;
> > >ifs_ivopts_data.stmt = stmt;
> > >ifs_ivopts_data.step = size_zero_node;
> > > @@ -1786,7 +1788,9 @@ find_interesting_uses_address (struct ivopts_data
> > > 
> > >/* Moreover, on strict alignment platforms, check that it is
> > >   sufficiently aligned.  */
> > > -  if (STRICT_ALIGNMENT && may_be_unaligned_p (base, step))
> > > +  mem_mode = TYPE_MODE (TREE_TYPE (*op_p));
> > > +  if (STRICT_ALIGNMENT && may_be_unaligned_p (base, step)
> > > +  && optab_handler (movmisalign_optab, mem_mode) == 
> > > CODE_FOR_nothing)
> > >  goto fail;
> > > 
> > >base = build_fold_addr_expr (base);
> > 
> > This won't fix it - the movmisalign optab will not be used at expansion
> > time as IVOPTs does not properly transfer the misalignment to the
> > access type.
> 
> sorry, i made a mistake here. 
> My initial target is to make IVOPTS work on vector type misaligned access. And
> i see the misalignment information for unaligned vector type access is stored
> in type and pointer.
> tree-ssa-loop-ivopts.c:
> else if (DR_MISALIGNMENT (first_dr) == -1)
>   {
> TREE_TYPE (data_ref)
>   = build_aligned_type (TREE_TYPE (data_ref),
> TYPE_ALIGN (elem_type));
> pi->align = TYPE_ALIGN_UNIT (elem_type);
> pi->misalign = 0;
>   }
> else
>   {
> TREE_TYPE (data_ref)
>   = build_aligned_type (TREE_TYPE (data_ref),
> TYPE_ALIGN (elem_type));
> pi->misalign = DR_MISALIGNMENT (first_dr);
>   }
> 
> and IVOPTS will create same type mem_ref when it rewrite use for address. 
> 
> so do this work?
>   align = TYPE_ALIGN(TREE_TYPE(*op_p));
>   if (STRICT_ALIGNMENT && may_be_unaligned_p (base, step)
>   && !(mem_mode != BLK_MODE 
>   && align < GET_MODE_ALIGNMENT (mem_mode)
>   && optab_handler (movmisalign_optab, mem_mode) !=
> CODE_FOR_nothing
>   )
> 
> )
> goto fail;

I suppose this should work.



> --
> Yuehai Du
> 
> 
> > 
> > Richard.
> 
>

[Bug c++/51475] [c++0x] [4.7 Regression] ICE with invalid initializer_list

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  2011-12-14 
09:42:42 UTC ---
Right, error-recovery. The problem is, in release-mode the category can easily
change. I'm also not  100% sure that all the PRs are properly cat in terms of
that, but this is a practical issue.

[Bug c++/18248] c_parse_error i18n problems

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||niva at niisi dot msk.ru

--- Comment #4 from Manuel López-Ibáñez  2011-12-14 
09:44:16 UTC ---
*** Bug 51548 has been marked as a duplicate of this bug. ***

[Bug c/51548] It is impossible to provide translations of some gcc error messages

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #2 from Manuel López-Ibáñez  2011-12-14 
09:44:16 UTC ---
GCC 4.1.2 is ancient history. Please provide a patch against GCC 4.7. 

Anyway, this is a well-known and old problem, unless you decide to work on it
yourself and submit patches to fix it, it is very likely that nobody else will
do in the next few years.

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

[Bug fortran/51550] New: ICE in gfc_get_derived_type, at fortran/trans-types.c:2401

[arjen.markus at deltares dot nl]

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

 Bug #: 51550
   Summary: ICE in gfc_get_derived_type, at
fortran/trans-types.c:2401
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arjen.mar...@deltares.nl


Created attachment 26078
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26078
Program causing the ICE

The attached program causes an ICE in gfc_get_derived_type, at
fortran/trans-types.c:2401, both in version 4.6.2 and 4.7.0 20111212 (a very
recent nightly build). The reported location is the same.

It may be related to other reported bugs vis-a-vis gfc_get_derived_type, but
as far as I can tell, they concern a different location in the source file.

The report is:

Driving: gfortran -v -o json json_problem.f90 -l gfortran -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=d:/gfortran47/bin/../libexec/gcc/i586-pc-mingw32/4.7.0/lto-wrapper.exe
Target: i586-pc-mingw32
Configured with: ../gcc-trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/brad/gfortran/dependencies
--disable-werror --enable-threads --disable-nls --build=i586-pc-mingw32
--enable-libgomp --enable-shared --disable-win32-registry --with-dwarf2
--disable-sjlj-exceptions --enable-lto
Thread model: win32
gcc version 4.7.0 20111212 (experimental) [trunk revision 182257] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-o' 'json.exe' '-shared-libgcc' '-mtune=pentium'
'-march=pentium'
 d:/gfortran47/bin/../libexec/gcc/i586-pc-mingw32/4.7.0/f951.exe
json_problem.f90 -quiet -dumpbase json_problem.f90 -mtune=pentium
-march=pentium -auxbase json_problem -version -fintrinsic-modules-path
d:/gfortran47/bin/../lib/gcc/i586-pc-mingw32/4.7.0/finclude -o
e:\Temp\cc481Bzh.s
GNU Fortran (GCC) version 4.7.0 20111212 (experimental) [trunk revision 182257]
(i586-pc-mingw32)
compiled by GNU C version 4.7.0 20111212 (experimental) [trunk revision
182257], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.7.0 20111212 (experimental) [trunk revision 182257]
(i586-pc-mingw32)
compiled by GNU C version 4.7.0 20111212 (experimental) [trunk revision
182257], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
json_problem.f90:50:0: internal compiler error: in gfc_get_derived_type, at
fortran/trans-types.c:2401
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Regards,

Arjen

[Bug target/50931] [avr] Support a 24-bit scalar integer mode

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  2011-12-14 
10:01:04 UTC ---
Author: gjl
Date: Wed Dec 14 10:00:56 2011
New Revision: 182328

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182328
Log:
libgcc/
PR target/50931
* config/avr/t-avr (LIB1ASMSRC): Add _mulpsi3, _mulsqipsi3.
* config/avr/lib1funcs.S (__mulpsi3, __mulsqipsi3): New functions.
gcc/
PR target/50931
* config/avr/avr.md (mulpsi3): New expander.
(*umulqihipsi3, *umulhiqipsi3): New insns.
(*mulsqipsi3.libgcc, *mulpsi3.libgcc): New insns.
(mulsqipsi3, *mulpsi3): New insn-and-splits.
(ashlpsi3): Turn to expander.  Move insn code to...
(*ashlpsi3): ...this new insn.
testsuite/
PR target/50931
* gcc.target/avr/torture/int24-mul.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.target/avr/torture/int24-mul.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.md
trunk/gcc/testsuite/ChangeLog
trunk/libgcc/ChangeLog
trunk/libgcc/config/avr/lib1funcs.S
trunk/libgcc/config/avr/t-avr

[Bug libstdc++/51540] partial_sum (int *, int *, int *, multiplies < int >) does not use operator +(complex, complex)

[giecrilj at stegny dot 2a.pl]

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

Christopher Yeleighton  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #5 from Christopher Yeleighton  
2011-12-14 10:20:29 UTC ---
(In reply to comment #4)
> When you follow?!? Simply there are no complex numbers in your code. Full 
> stop.

When you follow the hyperlink, you land at the description of operator +
(complex, complex).  When you hover, you are being told "returns new value
complex x + y" (not in Lynx though).

My code does not contain complex numbers but the algorithm is documented to use
an operator that uses complex numbers.

[Bug fortran/51550] ICE in gfc_get_derived_type, at fortran/trans-types.c:2401

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  2011-12-14 
10:26:05 UTC ---
I think it is a duplicate of pr47545, pr48654, pr49050, pr51075, and pr51393
(note that only pr48654 is marked as a duplicate of pr47545; if there is an
agreement about it, I can mark the other PRs as duplicate). From
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49050#c2 :

It is known that deferred character length components do not work - they have
not been implemented. I think we really should add a gfc_error("Sorry not
implemented") as it is not the first such bug has been reported.

 * * *

By the way, the documentation states this - albeit a bit hidden:

http://gcc.gnu.org/gcc-4.6/changes.html#fortran
http://gcc.gnu.org/wiki/GFortran#GCC4.6
 "Deferred type parameter: For scalar allocatable and pointer variables
  the character length can be deferred."
 (In particular: For components and for arrays, the length cannot be deferred.)

And a bit more explicitly:
  http://gcc.gnu.org/wiki/Fortran2003Status
  http://gcc.gnu.org/onlinedocs/gfortran/Fortran-2003-status.html

[Bug lto/45475] target use in libcpp breaks LTO bootstrap

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #13 from Eric Botcazou  2011-12-14 
10:29:00 UTC ---
> Fixed for quite some time

You shouldn't close a PR without installing the testcase in the testsuite.  Had
you done so, you would have seen that it isn't fixed at all:

eric@atlantis:~/build/gcc/native32-lto> prev-gcc/xgcc -B prev-gcc -o pr45475
pr45475.c -flto
In file included from pr45475.c:15:0,
 from :0:
pr45475.c: In function 'foo':
pr45475.c:16:15: internal compiler error: in convert_move, at expr.c:330
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: prev-gcc/xgcc returned 1 exit status

eric@atlantis:~/build/gcc/native32-lto> prev-gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=prev-gcc/xgcc
Target: i586-suse-linux
Configured with: /home/eric/svn/gcc/configure --build=i586-suse-linux
--prefix=/home/eric/install/gcc --with-as=/home/eric/install/gcc/bin/as
--with-ld=/home/eric/install/gcc/bin/ld --enable-languages=c,ada,lto
--enable-stage1-languages=c,ada,lto --with-build-config=bootstrap-lto
--enable-checking=yes,rtl --enable-__cxa_atexit --disable-nls
--disable-libmudflap
Thread model: posix
gcc version 4.7.0 20111214 (experimental) [trunk revision 182322] (GCC)

Thus reopening...

[Bug target/51523] LTO keeps unneeded functions (mingw32 target)

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-12-14 
10:36:15 UTC ---
This looks more like a linker bug which doesn't seem to account for the
contents of the .exp file.  It works properly on linux targets with providing a
version script, -Wl,--version-script=t.map with t.map containing

FOO_1.0 {
global:
  foo;
  bar;
local:
  *;
};

[Bug libstdc++/51540] partial_sum (int *, int *, int *, multiplies < int >) does not use operator +(complex, complex)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #6 from Paolo Carlini  2011-12-14 
10:36:42 UTC ---
Hey, please do not re-open PRs at will, and let's not waste further time at
will. We know the documentation is **our** documentation after all. You are
mistaken, you are not using complex numbers  in your code, in particular you
are *not* providing *any* overloaded operator+ in your code. There is nothing
to fix here, if you are not convinced, just try any other implementation of the
Standard lib around.

[Bug c++/51549] QList::operator[] crash in 32bit release version on MacOS for gcc 4.2.1

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
   Severity|critical|normal

--- Comment #2 from Jonathan Wakely  2011-12-14 
10:58:51 UTC ---
The GCC project no longer supports GCC 4.2.1, so either try a newer version or
report it to your vendor. You're using an Apple build, so bugs should be
reported to Apple.

[Bug libstdc++/51540] partial_sum (int *, int *, int *, multiplies < int >) does not use operator +(complex, complex)

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  2011-12-14 
11:02:39 UTC ---
(In reply to comment #5)
> My code does not contain complex numbers but the algorithm is documented to 
> use
> an operator that uses complex numbers.

That's just a doxygen bug, linking to the wrong operator+

If you want to report a documentation bug, say so, instead of being vague and
claiming the code is doing the wrong thing.

Your code fails to run because your assertion tests the wrong thing, not
because partial_sum is wrong.
If you don't know what partial_sum does, it's documented in many other places
e.g. http://www.sgi.com/tech/stl/partial_sum.html

[Bug libstdc++/51540] doxygen documentation for partial_sum misleading

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Keywords||documentation
   Last reconfirmed||2011-12-14
 AssignedTo|unassigned at gcc dot   |redi at gcc dot gnu.org
   |gnu.org |
 Resolution|INVALID |
 Ever Confirmed|0   |1
Summary|partial_sum (int *, int *,  |doxygen documentation for
   |int *, multiplies < int >)  |partial_sum misleading
   |does not use operator   |
   |+(complex, complex) |
   Severity|normal  |minor

--- Comment #8 from Jonathan Wakely  2011-12-14 
11:05:04 UTC ---
I'll fix those docs, the overload taking a predicate doesn't even use operator+
anyway.

[Bug libstdc++/51540] doxygen documentation for partial_sum misleading

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini  2011-12-14 
11:17:44 UTC ---
Thanks for the docs, Jon.

[Bug fortran/51529] [OOP] gfortran.dg/class_to_type_1.f03 is miscompiled: Uninitialized variable used

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2011-12-14 
11:18:21 UTC ---
(In reply to comment #3)
> The memset came about for similar reasons with class objects with
> allocatable components.  I had missed this wrinkle with the testcase.
> My inclination is to restire the memset and keep the PR open.

I am fine with it, but state in the comment above the memset that it is needed
as _copy tries to free the allocatable components of "dest" - that makes clear
why the memset is need for our implementation.

[Bug middle-end/51521] [4.7 Regression]: build fails on cris-elf and others building libstdc++-v3: verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #9 from Richard Guenther  2011-12-14 
11:30:28 UTC ---
Fixed.

[Bug c++/51547] auto, type deduction, reference collapsing and const: invalid initialization of reference of type 'const X&&' from expression of type 'const X'

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||jason at gcc dot gnu.org
  Known to work||4.7.0

--- Comment #1 from Jonathan Wakely  2011-12-14 
11:34:39 UTC ---
compiles fine with 4.7.0 2026, but I'm not sure if it's fixed or just
latent

[Bug c++/51151] Invalid -Woverflow warning in C++ frontend

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu.org

--- Comment #3 from Andreas Krebbel  2011-12-14 
12:00:55 UTC ---
r182175 fixed one failure on s390x but introduced a couple of new fails:

< FAIL: libgomp.c/atomic-2.c execution test
---
> FAIL: libgomp.c++/for-2.C  -O0  (test for excess errors)
> WARNING: libgomp.c++/for-2.C  -O0  compilation failed to produce executable
> FAIL: libgomp.c++/for-2.C  -O1  (test for excess errors)
> WARNING: libgomp.c++/for-2.C  -O1  compilation failed to produce executable
> FAIL: libgomp.c++/for-2.C  -O2  (test for excess errors)
> WARNING: libgomp.c++/for-2.C  -O2  compilation failed to produce executable
> FAIL: libgomp.c++/for-2.C  -O3 -fomit-frame-pointer  (test for excess errors)
> WARNING: libgomp.c++/for-2.C  -O3 -fomit-frame-pointer  compilation failed to 
> produce executable
> FAIL: libgomp.c++/for-2.C  -O3 -fomit-frame-pointer -funroll-loops  (test for 
> excess errors)
> WARNING: libgomp.c++/for-2.C  -O3 -fomit-frame-pointer -funroll-loops  
> compilation failed to produce executable
> FAIL: libgomp.c++/for-2.C  -O3 -fomit-frame-pointer -funroll-all-loops 
> -finline-functions  (test for excess errors)
> WARNING: libgomp.c++/for-2.C  -O3 -fomit-frame-pointer -funroll-all-loops 
> -finline-functions  compilation failed to produce executable
> FAIL: libgomp.c++/for-2.C  -O3 -g  (test for excess errors)
> WARNING: libgomp.c++/for-2.C  -O3 -g  compilation failed to produce executable
> FAIL: libgomp.c++/for-2.C  -Os  (test for excess errors)
> WARNING: libgomp.c++/for-2.C  -Os  compilation failed to produce executable

[Bug c++/51151] Invalid -Woverflow warning in C++ frontend

[krebbel at gcc dot gnu.org]

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

--- Comment #4 from Andreas Krebbel  2011-12-14 
12:02:47 UTC ---
libgomp/testsuite/libgomp.c++/for-2.C: In function 'void f7(int, int, int)':^M
libgomp/testsuite/libgomp.c++/for-2.C:87:3: error: invalid increment
expression^M
compiler exited with status 1
output is:
libgomp/testsuite/libgomp.c++/for-2.C: In function 'void f7(int, int, int)':^M
libgomp/testsuite/libgomp.c++/for-2.C:87:3: error: invalid increment
expression^M

FAIL: libgomp.c++/for-2.C  -O0  (test for excess errors)
Excess errors:
libgomp/testsuite/libgomp.c++/for-2.C:87:3: error: invalid increment expression

WARNING: libgomp.c++/for-2.C  -O0  compilation failed to produce executable

[Bug c++/51532] Invalid Code Generated for cpu32.

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

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

--- Comment #4 from Andreas Schwab  2011-12-14 12:11:34 
UTC ---
Created attachment 26079
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26079
Patch

Please try the attached patch.

[Bug c++/51532] Invalid Code Generated for cpu32.

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-14
 Ever Confirmed|0   |1

[Bug lto/51497] [4.7 Regression] The run time for the polyhedron test nf.f90 is ~10% slower with -flto after revision 182107

[rguenth at gcc dot gnu.org]

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

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  2011-12-14 
12:50:52 UTC ---
Created attachment 26080
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26080
patch candidate

Ok, so the reason is that we now stream the VLA types for, for example 'x',
locally.  Thus they do not go through the type merging machinery (no
problem) - but they also do not get a TYPE_CANONICAL computed, which would
not be bad either would it be itself, but it is NULL_TREE and thus
references to such VLA arrays get alias-set zero.

The function local LTO sections are not structured in a way we can
arrange to call uniquify_nodes, but we should be able to fixup
canonical types (and variant types).

[Bug c++/51151] Invalid -Woverflow warning in C++ frontend

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  2011-12-14 
13:05:35 UTC ---
> r182175 fixed one failure on s390x but introduced a couple of new fails:
>
> < FAIL: libgomp.c/atomic-2.c execution test
> ---
> > FAIL: libgomp.c++/for-2.C  -O0  (test for excess errors)
> > ...

It looks like pr51496 fixed by revision 182257.

[Bug lto/48508] ICE in output_die, at dwarf2out.c:11409

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther  2011-12-14 
14:33:27 UTC ---
Even more reduced, fails with

> ./g++ -B. -g -O -r -nostdlib 1.ii 2.ii -flto -finline-small-functions
lto1: internal compiler error: in output_die, at dwarf2out.c:8401

1.ii

class Value;
bool js_ValueToAtom(const Value &v);
void
js_InternNonIntElementIdSlow(const Value &idval)
{
  js_ValueToAtom(idval);
} 

2.ii

class Value;
void
js_InternNonIntElementId(const Value &idval)
{
  extern void js_InternNonIntElementIdSlow(const Value &);
  js_InternNonIntElementIdSlow(idval);
}
void
Interpret(const Value &idval_)
{
  js_InternNonIntElementId(idval_);
}

Appearantly it is required that js_InternNonIntElementId is inlined
eary while js_InternNonIntElementIdSlow is inlined two times at IPA
time, both into js_InternNonIntElementId and Interpret.

[Bug debug/51517] [4.5/4.6/4.7 Regression] Wrong debug information for pointers with negative strides.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-14
 CC||burnus at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||matz at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2011-12-14 
14:33:50 UTC ---
There are multiple issues here:
1) the fortran FE adds DECL_INITIAL to the span variable, which doesn't make
any
sense for an automatic variable (and isn't needed for TREE_STATIC either,
because
those are initialized to 0 by default).

--- gcc/fortran/trans-decl.c.jj2011-12-11 22:02:37.0 +0100
+++ gcc/fortran/trans-decl.c2011-12-14 15:20:03.656835603 +0100
@@ -1434,7 +1434,6 @@ gfc_get_symbol_decl (gfc_symbol * sym)
   gfc_finish_var_decl (span, sym);
   TREE_STATIC (span) = TREE_STATIC (decl);
   DECL_ARTIFICIAL (span) = 1;
-  DECL_INITIAL (span) = build_int_cst (gfc_array_index_type, 0);

   GFC_DECL_SPAN (decl) = span;
   GFC_TYPE_ARRAY_SPAN (TREE_TYPE (decl)) = span;

If the FE wants to initialize the span.N variable to zero when it is not
TREE_STATIC, it really should add a statement to a right spot that initializes
it to 0, having DECL_INITIAL does nothing and just confuses dwarf2out.

2) for some reason the span.0 variable doesn't get DECL_RTL during expansion,
actually it gets it to one MEM location for the span.0_?? = 4; store and a
different location for the span.0_?? = 44; store:
  /* For the benefit of debug information at -O0 (where vartracking
 doesn't run) record the place also in the base DECL if it's
 a normal variable (not a parameter).  */
  if (x && x != pc_rtx && TREE_CODE (SSA_NAME_VAR (t)) == VAR_DECL)
{
  tree var = SSA_NAME_VAR (t);
  /* If we don't yet have something recorded, just record it now.  */
  if (!DECL_RTL_SET_P (var))
SET_DECL_RTL (var, x);
  /* If we have it set already to "multiple places" don't
 change this.  */
  else if (DECL_RTL (var) == pc_rtx)
;
  /* If we have something recorded and it's not the same place
 as we want to record now, we have multiple partitions for the
 same base variable, with different places.  We can't just
 randomly chose one, hence we have to say that we don't know.
 This only happens with optimization, and there var-tracking
 will figure out the right thing.  */
  else if (DECL_RTL (var) != x)
SET_DECL_RTL (var, pc_rtx);
}

Apparently we have multiple partitions for the same base variable at -O0 :(.
The variable is !DECL_IGNORED_P, although it is DECL_ARTIFICIAL.
Micha, any ideas why it got two partitions instead of just one as expected?

The 1) patch would turn this from invalid debug info into valid, but
incomplete, debug info.  Figuring out 2) would supposedly turn it into valid
complete debug info.
And, one would hope that if/when the array descriptor format finally changes
(is it now scheduled for 4.8, or later?) and stride will be in bytes rather
than whatever units it currently is, this span.N stuff will be no longer
needed.

[Bug target/51534] Bad code gen for vcgtq_u32 NEON intrinsic

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-14
 Ever Confirmed|0   |1

--- Comment #2 from Richard Earnshaw  2011-12-14 
14:36:51 UTC ---
Confirmed.

The VCGT ..., #0 instruction only operates on signed types.  Also applies to
VCLE.


Alternatives for unsigned are:
- load 0 into a register
- convert the comparison to VCEQ then, for GT only, invert the result.

[Bug lto/48508] ICE in output_die, at dwarf2out.c:11409

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Guenther  2011-12-14 
15:00:23 UTC ---
Even more reduced:

void __attribute__((externally_visible))
foo (int i)
{
}

-

static void
bar (void)
{
  extern void foo (int);
  foo (0);
}
int main()
{
  bar ();
}

which also links ok when it works.  Does not fail with C but only C++
but is valid source for both.

[Bug debug/51517] [4.5/4.6/4.7 Regression] Wrong debug information for pointers with negative strides.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  2011-12-14 
15:14:22 UTC ---
Created attachment 26081
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26081
gcc47-pr51517.patch

Untested fix.

OT, can anyone please explain the following in trans-decl.c
(gfc_trans_deferred_vars):

  else if ((!sym->attr.dummy || sym->ts.deferred)
&& (sym->ts.type == BT_CLASS
&& CLASS_DATA (sym)->attr.pointer))
break;

?  The break there will IMHO just cause the rest of the *->tlink chain deferred
vars not to be processed at all, is that the right thing to do?  continue; or ;
would make much more sense to me...

[Bug tree-optimization/51551] New: tree-loop-optimize chews all memory

[gjl at gcc dot gnu.org]

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

 Bug #: 51551
   Summary: tree-loop-optimize chews all memory
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Keywords: memory-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
  Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
 Build: i686-pc-linux-gnu


Created attachment 26082
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26082
bug-loop.c

The test program attached don't finish compilation and gcc is entering infinite
loop that chews up all of memory.

Compile with:

$ gcc bug-loop.c -S -Os

Following works:

$ gcc bug-loop.c -S -O2
$ gcc bug-loop.c -S -Os -fno-tree-loop-optimize

[Bug tree-optimization/51551] tree-loop-optimize chews all memory

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  2011-12-14 
15:21:45 UTC ---
Created attachment 26083
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26083
Compiler output with -v

[Bug lto/48508] ICE in output_die, at dwarf2out.c:11409

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #14 from Richard Guenther  2011-12-14 
15:23:18 UTC ---
Hm.  It seems that unlike the C FE the C++ FE emits new global fndecls for
each block-local extern it encounters.  So, for

extern void foo (int);
static void
bar (void)
{
  extern void foo (int);
  foo (0);
}
int main()
{
  extern void foo (int);
  bar ();
}

we'll have three FUNCTION_DECLs for the global foo, two queued in
BLOCK_VARS but with global context (the C FE would have a DECL_CONTEXT
of the enclosing function declaration, bar and main here).  So the C++
frontend will be still susceptible to PR48437, those local decls entering
the decl merging process.

Which means that if we fix this bug in another way this bug is fixed
as well!  One idea is to simply never treat trees that we output
when following TREE_CHAIN as indexable.

[Bug lto/51497] [4.7 Regression] The run time for the polyhedron test nf.f90 is ~10% slower with -flto after revision 182107

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Richard Guenther  2011-12-14 
15:31:48 UTC ---
Fixed.

[Bug lto/51497] [4.7 Regression] The run time for the polyhedron test nf.f90 is ~10% slower with -flto after revision 182107

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2011-12-14 
15:31:31 UTC ---
Author: rguenth
Date: Wed Dec 14 15:31:24 2011
New Revision: 182336

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182336
Log:
2011-12-14  Richard Guenther  

PR lto/51497
* lto-streamer-in.c (lto_read_body): Fixup local types
TYPE_CANONICAL and variant chain.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-in.c

[Bug lto/51497] [4.7 Regression] The run time for the polyhedron test nf.f90 is ~10% slower with -flto after revision 182107

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  
2011-12-14 15:36:19 UTC ---
> Created attachment 26080
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26080
> patch candidate
> ...

The patch fixes this pr without any visible side-effect on the other tests of
the polyhedron suite. Thanks.

[Bug c++/51532] Invalid Code Generated for cpu32.

[joel at gcc dot gnu.org]

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

--- Comment #5 from Joel Sherrill  2011-12-14 15:38:43 
UTC ---
This patch allows m68k-rtems4.11 to complete building the compiler and newlib
with C and C++. 

I haven't tried other languages, built RTEMS itself, or run tests yet. But the
patch looks good to me.

[Bug target/51523] LTO keeps unneeded functions (mingw32 target)

[d.g.gorbachev at gmail dot com]

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

--- Comment #6 from Dmitry Gorbachev  
2011-12-14 15:45:29 UTC ---
Filed a linker bug .

[Bug lto/48508] ICE in output_die, at dwarf2out.c:11409

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #15 from Richard Guenther  2011-12-14 
15:52:59 UTC ---
Bah, that doesn't work for local statics!  Let's see if the following works
(though it looks a bit too non-localized given the various callers to
streamer_write_chain - the FIELD_DECL chain is especially susceptible
considering C++ class methods).

[Bug c++/51406] [4.5/4.6/4.7 Regression][c++0x] Incorrect result of static_cast to rvalue reference to base class.

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  2011-12-14 
16:03:45 UTC ---
Author: jason
Date: Wed Dec 14 16:03:37 2011
New Revision: 182340

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182340
Log:
PR c++/51406
PR c++/51161
* typeck.c (build_static_cast_1): Fix cast of lvalue to
base rvalue reference.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/rv-cast3.C
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/rv-cast4.C
Modified:
branches/gcc-4_5-branch/gcc/cp/ChangeLog
branches/gcc-4_5-branch/gcc/cp/typeck.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug c++/51161] [C++0x] Illegal static_cast to rvalue reference to ambiguous base class

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-12-14 
16:03:16 UTC ---
Author: jason
Date: Wed Dec 14 16:03:07 2011
New Revision: 182339

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182339
Log:
PR c++/51406
PR c++/51161
* typeck.c (build_static_cast_1): Fix cast of lvalue to
base rvalue reference.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/rv-cast3.C
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/rv-cast4.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/typeck.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug c++/51406] [4.5/4.6/4.7 Regression][c++0x] Incorrect result of static_cast to rvalue reference to base class.

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  2011-12-14 
16:03:16 UTC ---
Author: jason
Date: Wed Dec 14 16:03:07 2011
New Revision: 182339

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182339
Log:
PR c++/51406
PR c++/51161
* typeck.c (build_static_cast_1): Fix cast of lvalue to
base rvalue reference.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/rv-cast3.C
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/rv-cast4.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/typeck.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug c++/51161] [C++0x] Illegal static_cast to rvalue reference to ambiguous base class

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-12-14 
16:03:44 UTC ---
Author: jason
Date: Wed Dec 14 16:03:37 2011
New Revision: 182340

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182340
Log:
PR c++/51406
PR c++/51161
* typeck.c (build_static_cast_1): Fix cast of lvalue to
base rvalue reference.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/rv-cast3.C
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/rv-cast4.C
Modified:
branches/gcc-4_5-branch/gcc/cp/ChangeLog
branches/gcc-4_5-branch/gcc/cp/typeck.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug c++/51406] [4.5/4.6/4.7 Regression][c++0x] Incorrect result of static_cast to rvalue reference to base class.

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Jason Merrill  2011-12-14 
16:34:19 UTC ---
Fixed for 4.5.4, 4.6.3, 4.7.0.

[Bug c++/51161] [C++0x] Illegal static_cast to rvalue reference to ambiguous base class

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||FIXED
   Target Milestone|--- |4.5.4

--- Comment #4 from Jason Merrill  2011-12-14 
16:35:31 UTC ---
Fixed for 4.5.4, 4.6.3, 4.7.0.

[Bug tree-optimization/51551] tree-loop-optimize chews all memory

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-14
  Known to work||4.7.0
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-12-14 
16:36:12 UTC ---
It's complete unrolling (a known culprit).  4.7 works for some reason,
maybe because I fixed loop invariant motion (who knows ;)

[Bug c++/51248] [4.6/4.7 Regression] ICE with pointer to enum

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug c++/51463] [c++0x] [4.7 Regression] ICE declaring a member function virtual and static

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-12-14
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2011-12-14 
16:39:37 UTC ---
Created attachment 26084
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26084
gcc47-pr51463.patch

Untested fix.  Not very happy about the patch, it is not very nice, but
we decide to parse the initializer as NSDMI resp. normal static initializer
already before grokdeclarator is called, have apparently no access to that
initializer in there and because of the errors decide to clear staticp (and
override storage_class to sc_none).  So something that has been parsed as
static data member initializer is now used as NSDMI.

[Bug debug/51471] [4.7 Regression] gcc.c-torture/execute/20040811-1.c and gcc.c-torture/execute/vla-dealloc-1.c fails at -O3 -g on mips64-linux-gnu

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rsandifo at redhat dot com

--- Comment #7 from vries at gcc dot gnu.org 2011-12-14 17:04:46 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > So my question is: what is the mechanism that should prevent epilogue insns
> > from being moved to before the epilogue?
> 
> A full compiler barrier?  See PR38644 for an epilogue scheduling bug on ARM
> Thumb-1 that got fixed by prefixing the epilogue with a barrier.  That PR also
> refers to an older PowerPC bug that was fixed in a similar way.

Richard,

this tentative patch fixes both PR51471 and PR51271:
...
Index: src/gcc-mainline/gcc/config/mips/mips.c
===
--- src/gcc-mainline/gcc/config/mips/mips.c (revision 181878)
+++ src/gcc-mainline/gcc/config/mips/mips.c (working copy)
@@ -10400,6 +10400,9 @@ mips_expand_epilogue (bool sibcall_p)
   return;
 }

+  if (dwarf2out_do_frame ())
+emit_insn (gen_blockage ());
+
   /* In MIPS16 mode, if the return value should go into a floating-point
  register, we need to call a helper routine to copy it over.  */
   if (mips16_cfun_returns_in_fpr_p ())
...

Is the proper way to fix these PRs?

Thanks,
- Tom

[Bug debug/51471] [4.7 Regression] gcc.c-torture/execute/20040811-1.c and gcc.c-torture/execute/vla-dealloc-1.c fails at -O3 -g on mips64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  2011-12-14 
17:26:34 UTC ---
I don't think so, dwarf2out_do_frame () depends on (or may depend on) whether
compiling with -g or -g0.  So, doing code generation decisions based on it is
wrong, -fcompare-debug will then fail and generated code will be different
between -g and -g0.

[Bug c++/51475] [c++0x] [4.7 Regression] ICE with invalid initializer_list

[dodji at gcc dot gnu.org]

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

--- Comment #7 from Dodji Seketeli  2011-12-14 
18:18:56 UTC ---
A candidate patch was sent to
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01120.html

[Bug target/51003] bfin ICE compiling libgcc in gen_const_vector, at emit-rtl.c:5476

[joel at gcc dot gnu.org]

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

--- Comment #2 from Joel Sherrill  2011-12-14 18:26:11 
UTC ---
Stuart Henderson sent this in response to my status report to gcc@ mailing
list.

This looks like a known, general issue which Bernd had a fix for, but it
doesn't appear to have been checked in yet:

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

This appears to let the build get further since it is now generating invalid
assembly building newlib.

[Bug target/51552] New: bfin generates bad assembly

[joel at gcc dot gnu.org]

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

 Bug #: 51552
   Summary: bfin generates bad assembly
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org


Created attachment 26085
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26085
Preprocessed test case

xgcc (GCC) 4.7.0 20111214 (experimental) [trunk revision 182330]
Target: bfin-rtems4.11 compiling newlib

/home2/joel/build/b-bfin-gcc/./gcc/xgcc -B/home2/joel/build/b-bfin-gcc/./gcc/
-nostdinc -B/home2/joel/build/b-bfin-gcc/bfin-rtems4.11/newlib/ -isystem
/home2/joel/build/b-bfin-gcc/bfin-rtems4.11/newlib/targ-include -isystem
/users/joel/test-gcc/gcc-svn/newlib/libc/include
-B/users/joel/test-gcc/install-svn/bfin-rtems4.11/bin/
-B/users/joel/test-gcc/install-svn/bfin-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-svn/bfin-rtems4.11/include -isystem
/users/joel/test-gcc/install-svn/bfin-rtems4.11/sys-include   
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"1.19.0\" -DPACKAGE_STRING=\"newlib\ 1.19.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I/users/joel/test-gcc/gcc-svn/newlib/libc/string -D_COMPILING_NEWLIB
-DMALLOC_PROVIDED -DEXIT_PROVIDED -DSIGNAL_PROVIDED
-DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL
-DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS
-D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -Wall -fno-builtin  -g -O2 -c -o
lib_a-strsignal.o `test -f 'strsignal.c' || echo
'/users/joel/test-gcc/gcc-svn/newlib/libc/string/'`strsignal.c
/tmp/cctEZ5VY.s: Assembler messages:
/tmp/cctEZ5VY.s:24: Error: syntax error. Input text was .LCFI1.
/tmp/cctEZ5VY.s:24: Error: 

Cutting this down, it appears to be the -g flag:


[joel@rtbf64a string]$ /home2/joel/build/b-bfin-gcc/./gcc/xgcc
-B/home2/joel/build/b-bfin-gcc/./gcc/ -O2 -c -fno-builtin j.c
[joel@rtbf64a string]$ /home2/joel/build/b-bfin-gcc/./gcc/xgcc
-B/home2/joel/build/b-bfin-gcc/./gcc/ -O2 -c -g -fno-builtin j.c
/tmp/ccwaXpNe.s: Assembler messages:
/tmp/ccwaXpNe.s:24: Error: syntax error. Input text was .LCFI1.
/tmp/ccwaXpNe.s:24: Error: 

The bad asm generated is here:

.LCFI0:
R2 = ROT R0 BY 0 ||
.LCFI1:
R7 = [P2] ||
nop;

I am guessing there should have been a semi-colon and maybe a nop before
.LCFI1.

[Bug c++/51553] New: brace initialization and conversion operators

[dave at boostpro dot com]

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

 Bug #: 51553
   Summary: brace initialization and conversion operators
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@boostpro.com


Please consider this test case:

-  
struct X
{
X();
};

struct Y
{
operator X() const;
};

struct Z
{
explicit operator X() const;
};

X a = { Y() };  // #1. error: could not convert '{Y()}' from '' to 'X'
X aa = Y(); // #1a. OK

X b{ Y() }; // #2. error: no matching function for call to
'X::X()'
X bb(Y());  // #2a. OK

X c = { Z() };  // #3 error: could not convert '{Z()}' from '' to 'X'
X cc = Z(); // #3a. error: conversion from 'Z' to non-scalar type 'X'
requested

X d{ Z() }; // #4 error: no matching function for call to
'X::X()'
X dd( Z() );// OK
-  

I can't find anything in the standard that justifies a difference between the
brace- and braceless-initialization cases.  Even in case #3, the difference in
error message leads me to think the code may be failing for the wrong reasons.

[Bug c++/51554] New: ICE in cp/semantics.c:cxx_eval_indirect_ref with -Wall

[dnovillo at gcc dot gnu.org]

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

 Bug #: 51554
   Summary: ICE in cp/semantics.c:cxx_eval_indirect_ref with -Wall
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dnovi...@gcc.gnu.org
CC: ja...@redhat.com, sing...@gcc.gnu.org


In:

static tree
cxx_eval_indirect_ref (const constexpr_call *call, tree t,
   bool allow_non_constant, bool addr,
   bool *non_constant_p)
{
[ ... ]
  if (r)
r = cxx_eval_constant_expression (call, r, allow_non_constant,
  addr, non_constant_p);
  else
{
  tree sub = op0;
  STRIP_NOPS (sub);
  if (TREE_CODE (sub) == ADDR_EXPR
  || TREE_CODE (sub) == POINTER_PLUS_EXPR)
{
==>  gcc_assert (!same_type_ignoring_top_level_qualifiers_p
==>  (TREE_TYPE (TREE_TYPE (sub)), TREE_TYPE (t)));
  /* DR 1188 says we don't have to deal with this.  */
  if (!allow_non_constant)

at the point of the failure, we have:

t: *((const uint8 *) &XX[0] + 1);
sub: (const uint8 *) &XX[0] + 1;

and (naturally) TREE_TYPE(t) is the same as TREE_TYPE(TREE_TYPE(sub)), so the
assertion fails trivially. 

The values for T and SUB seem to come unmodified all the way up from
process_init_constructor_array.  The original source code where this is coming
from is:

const uint8 F::V[] = {
  ...
  *(reinterpret_cast(&XX[0]) + 1),
  ...
};

This code seems to be enabled only with -Wall, the following reproducer only
fails if compiled with -Wall:

$ cat a.cc
typedef unsigned char uint8;
typedef unsigned int uint32;

const uint32 XX[] = { 1, 3, 7 };

const uint8 V[] = {
  *(reinterpret_cast(&XX[0]) + 0),
  *(reinterpret_cast(&XX[0]) + 1),
  *(reinterpret_cast(&XX[0]) + 2),
  *(reinterpret_cast(&XX[0]) + 3),
  *(reinterpret_cast(&XX[1]) + 0),
  *(reinterpret_cast(&XX[1]) + 1),
  *(reinterpret_cast(&XX[1]) + 2),
  *(reinterpret_cast(&XX[1]) + 3),
};

$ g++ -Wall -c a.cc
a.cc:15:1: internal compiler error: in cxx_eval_indirect_ref, at
cp/semantics.c:7321
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug ada/51555] New: Thinks System.Address is 64 bits wide when compiling with -m32

[baldrick at gcc dot gnu.org]

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

 Bug #: 51555
   Summary: Thinks System.Address is 64 bits wide when compiling
with -m32
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: baldr...@gcc.gnu.org


When using -m32 on a 64 bit system, the compiler thinks that System.Address
does
not have the same size as a pointer.  Compiling the following testcase gives:
  $ gcc -S m32.adb -m32
  m32.adb:4:07: warning: types for unchecked conversion have different sizes

with System;
package M32 is
   type P is access Integer;
   function C (A : System.Address) return P;
end;
with Ada.Unchecked_Conversion;
package body M32 is
   function C (A : System.Address) return P is
  function D is new Ada.Unchecked_Conversion (System.Address, P);
   begin
  return D (A);
   end;
end;

[Bug debug/51471] [4.7 Regression] gcc.c-torture/execute/20040811-1.c and gcc.c-torture/execute/vla-dealloc-1.c fails at -O3 -g on mips64-linux-gnu

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-12-14
 AssignedTo|unassigned at gcc dot   |pinskia at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #9 from Andrew Pinski  2011-12-14 
20:27:14 UTC ---
I am working on this, Using http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50283
as a base and expending it to be generic.

[Bug c++/51556] New: Bizarre member template protection errors

[luto at mit dot edu]

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

 Bug #: 51556
   Summary: Bizarre member template protection errors
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l...@mit.edu


Created attachment 26086
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26086
Failing test

I'm not really sure what's going on here, so this test case isn't very well
reduced.

multiindex_success.cc compiles (as IMO it should).  multiindex_failure.cc fails
to compile (which is IMO wrong) with this error:

/usr/include/boost/multi_index/detail/index_base.hpp: In member function ‘void
A::Test2(const Irrelevant&) [with Irrelevant = int]’:
/usr/include/boost/multi_index/detail/index_base.hpp:49:44: error: ‘typedef
struct boost::multi_index::detail::index_node_base
> boost::multi_index::detail::index_base,
boost::multi_index::member > >, std::allocator
>::node_type’ is protected
multiindex_failure.cc:42:11: error: within this context

The error is garbage, since there is no reference to node_type in that context.

The two test cases are identical except that I've reversed the order of two
member functions.

Preprocessed source attached, because I haven't yet reproduced this without
using boost libraries.

Seen on g++ (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1) and an old-ish 4.7 trunk
build.

[Bug c++/51556] Bizarre member template protection errors

[luto at mit dot edu]

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

--- Comment #1 from Andy Lutomirski  2011-12-14 20:28:28 
UTC ---
Created attachment 26087
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26087
Working test

[Bug debug/51471] [4.7 Regression] gcc.c-torture/execute/20040811-1.c and gcc.c-torture/execute/vla-dealloc-1.c fails at -O3 -g on mips64-linux-gnu

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  2011-12-14 
20:28:34 UTC ---
*** Bug 51536 has been marked as a duplicate of this bug. ***

[Bug debug/51536] [4.7 Regression] ICE on mips64 with -march=octeon -O2 -g -fno-omit-frame-pointer

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Andrew Pinski  2011-12-14 
20:28:34 UTC ---
The patch which I am working on for PR 51471 will also fix this one.  Closing
as a dup.

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

[Bug c++/51556] Bizarre member template protection errors

[luto at mit dot edu]

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

--- Comment #2 from Andy Lutomirski  2011-12-14 20:30:01 
UTC ---
Created attachment 26088
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26088
Preprocessed test cases

[Bug rtl-optimization/51505] [4.5/4.6/4.7 Regression] ICE: in form_sum, at reload.c:5349 with -O --param max-cse-insns=1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug middle-end/51544] uninitialized variable false positive prevents bootstrap with -fipa-cp-clone

[matt at use dot net]

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

Matt Hargett  changed:

   What|Removed |Added

Summary|uninitialized variable  |uninitialized variable
   |false positive prevents |false positive prevents
   |bootstrap at -O3|bootstrap with
   ||-fipa-cp-clone

--- Comment #2 from Matt Hargett  2011-12-14 20:52:30 UTC 
---
Narrowed this down to -O2 -fipa-cp-clone that triggers the warning.

[Bug bootstrap/50148] GCC fails to bootstrap with -O3 due to "may be used uninitialized" errors

[matt at use dot net]

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

Matt Hargett  changed:

   What|Removed |Added

 CC||matt at use dot net

--- Comment #4 from Matt Hargett  2011-12-14 20:56:55 UTC 
---
It's only when -fipa-cp-clone is used. If you use all -O3 flags except that
one, it works around the issue.

Andrew, can we add a pragma to that specific file with a pointer to this bug?

[Bug c++/51556] Bizarre member template protection errors

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  2011-12-14 
21:23:13 UTC ---
It fails with GCC 4.7 revision 180166.

It compiles cleanly with clang 3.1.

[Bug c++/51475] [c++0x] [4.7 Regression] ICE with invalid initializer_list

[dodji at gcc dot gnu.org]

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

--- Comment #8 from Dodji Seketeli  2011-12-14 
21:49:57 UTC ---
Author: dodji
Date: Wed Dec 14 21:49:52 2011
New Revision: 182343

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182343
Log:
PR c++/51475 - ICE with invalid initializer-list

gcc/cp/

PR c++/51475
* call.c (struct conversion): Update comment.
(next_conversion): New static function.
(convert_like_real): Use it.

gcc/testsuite/

PR c++/51475
* g++.dg/cpp0x/initlist63.C: New test.

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

[Bug c++/51475] [c++0x] [4.7 Regression] ICE with invalid initializer_list

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Dodji Seketeli  2011-12-14 
21:52:22 UTC ---
This should be fixed in trunk (4.7).

[Bug tree-optimization/51557] New: [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2244 with custom flags

[zsojka at seznam dot cz]

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

 Bug #: 51557
   Summary: [4.7 Regression] ICE: in maybe_record_trace_start, at
dwarf2cfi.c:2244 with custom flags
Classification: Unclassified
   Product: gcc
   Version: 4.7.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


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

Compiler output:
$ gcc -Os -fno-asynchronous-unwind-tables -g -fsel-sched-pipelining
-fselective-scheduling2 testcase.c 
testcase.c: In function 'synth':
testcase.c:13:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2244
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) list
2239{
2240
2241  /* We ought to have the same state incoming to a given trace no
2242 matter how we arrive at the trace.  Anything else means we've
2243 got some kind of optimization error.  */
2244  gcc_checking_assert (cfi_row_equal_p (cur_row, ti->beg_row));
2245
2246  /* The args_size is allowed to conflict if it isn't actually
used.  */
2247  if (ti->beg_true_args_size != args_size)
2248ti->args_size_undefined = true;
(gdb) bt
#0  fancy_abort (file=0x124de40 "/mnt/svn/gcc-trunk/gcc/dwarf2cfi.c",
line=2244, function=0x124f160 "maybe_record_trace_start")
at /mnt/svn/gcc-trunk/gcc/diagnostic.c:898
#1  0x006f2434 in maybe_record_trace_start (start=Unhandled dwarf
expression opcode 0xf3
) at /mnt/svn/gcc-trunk/gcc/dwarf2cfi.c:2244
#2  0x006f2ff9 in scan_trace (trace=Unhandled dwarf expression opcode
0xf3
) at /mnt/svn/gcc-trunk/gcc/dwarf2cfi.c:2421
#3  0x006f43cd in create_cfi_notes () at
/mnt/svn/gcc-trunk/gcc/dwarf2cfi.c:2551
#4  execute_dwarf2_frame () at /mnt/svn/gcc-trunk/gcc/dwarf2cfi.c:2909
#5  0x008f8ee5 in execute_one_pass (pass=0x17beea0) at
/mnt/svn/gcc-trunk/gcc/passes.c:2079
#6  0x008f9285 in execute_pass_list (pass=0x17beea0) at
/mnt/svn/gcc-trunk/gcc/passes.c:2134
#7  0x008f9297 in execute_pass_list (pass=0x17bfe80) at
/mnt/svn/gcc-trunk/gcc/passes.c:2135
#8  0x008f9297 in execute_pass_list (pass=0x17bfee0) at
/mnt/svn/gcc-trunk/gcc/passes.c:2135
#9  0x00a5acfe in tree_rest_of_compilation (fndecl=0x75672d00) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:421
#10 0x006ada3a in cgraph_expand_function (node=0x755637e0) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1818
#11 0x006af7dc in cgraph_expand_all_functions () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1885
#12 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2198
#13 0x006aff4a in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1327
#14 0x0058d640 in c_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/c-decl.c:10026
#15 0x009ee0b4 in compile_file (argc=17, argv=0x7fffda58) at
/mnt/svn/gcc-trunk/gcc/toplev.c:573
#16 do_compile (argc=17, argv=0x7fffda58) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1928
#17 toplev_main (argc=17, argv=0x7fffda58) at
/mnt/svn/gcc-trunk/gcc/toplev.c:2004
#18 0x761570ed in __libc_start_main () from /lib64/libc.so.6
#19 0x00570e11 in _start ()

Tested revisions:
r182321 - crash
r178498 - crash
4.6 r180325 - OK

[Bug c/51542] bootstrap failure due to uninitialized variable use in c-parser

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||marc.glisse at normalesup
   ||dot org

--- Comment #2 from Marc Glisse  2011-12-14 
22:22:41 UTC ---
And PR 44938 before that.

[Bug c++/51554] ICE in cp/semantics.c:cxx_eval_indirect_ref with -Wall

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2011-12-14 
22:26:27 UTC ---
Author: jason
Date: Wed Dec 14 22:26:24 2011
New Revision: 182346

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182346
Log:
PR c++/51554
* semantics.c (cxx_eval_indirect_ref): Fix sanity check.

Added:
trunk/gcc/testsuite/g++.dg/init/constant1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/51545] missing -Wparentheses diagnostic with compound assignment used as condition

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||marc.glisse at normalesup
   ||dot org

--- Comment #1 from Marc Glisse  2011-12-14 
22:27:15 UTC ---
PR 44949?

[Bug c++/51248] [4.6/4.7 Regression] ICE with pointer to enum

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-12-14 
22:26:16 UTC ---
Author: jason
Date: Wed Dec 14 22:26:13 2011
New Revision: 182345

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182345
Log:
PR c++/51248
* decl.c (copy_type_enum): Also update variants.
(finish_enum): Allow variants of complete enums.

Added:
trunk/gcc/testsuite/g++.dg/other/enum2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/51558] New: Declaration of unspecialized std::hash<_Tp>::operator()(_Tp) turns compile-time errors into link-time errors

[jyasskin at gcc dot gnu.org]

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

 Bug #: 51558
   Summary: Declaration of unspecialized
std::hash<_Tp>::operator()(_Tp) turns compile-time
errors into link-time errors
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org


Created attachment 26090
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26090
Declare std::hash instead of defining it.

libstdc++'s current definition of the unspecialized std::hash template gives
bad error messages when a user forgets to define a hash function for their
type. Specifically, providing a declaration but no definition of operator()
moves the error from compile to link time:

$ cat test.cc
#include 
struct MyStruct {
  int i;
};
bool operator==(const MyStruct& lhs, const MyStruct& rhs) {
  return lhs.i == rhs.i;
}
int main() {
  std::unordered_set s;
  s.insert(MyStruct{3});
}
$ g++ -g -std=c++11 test.cc -o test
/tmp/cclzhwaU.o: In function `std::__detail::_Hash_code_base, std::equal_to,
std::hash, std::__detail::_Mod_range_hashing,
std::__detail::_Default_ranged_hash, true>::_M_hash_code(MyStruct const&)
const':
.../include/c++/4.7.0/bits/hashtable_policy.h:702: undefined reference to
`std::hash::operator()(MyStruct) const'
collect2: error: ld returned 1 exit status

With the attached patch, the error is much more informative, if not exactly
concise:

$ g++ -g -std=c++11 test.cc -o test
In file included from .../include/c++/4.7.0/bits/hashtable.h:35:0,
 from .../include/c++/4.7.0/unordered_set:45,
 from test.cc:1:
.../include/c++/4.7.0/bits/hashtable_policy.h: In instantiation of ‘struct
std::__detail::_Hash_code_base,
std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, true>’:
.../include/c++/4.7.0/bits/hashtable.h:149:11:   required from ‘class
std::_Hashtable,
std::_Identity, std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, true, true, true>’
.../include/c++/4.7.0/bits/unordered_set.h:46:11:   required from ‘class
std::__unordered_set, std::equal_to,
std::allocator, true>’
.../include/c++/4.7.0/bits/unordered_set.h:277:11:   required from ‘class
std::unordered_set’
test.cc:9:32:   required from here
.../include/c++/4.7.0/bits/hashtable_policy.h:740:20: error:
‘std::__detail::_Hash_code_base<_Key, _Value, _ExtractKey, _Equal, _H1, _H2,
std::__detail::_Default_ranged_hash, true>::_M_h1’ has incomplete type
...

In particular, the "required from here" line points at the actual source
location that needs to be able to find the definition.


I believe the patch is allowed by C++11 since I can't find a specification of
the contents of the unspecialized template, and libc++ uses basically the same
technique:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__functional_base?view=markup.

Another way to accomplish something similar would be to delete the operator()
declaration from the std::hash definition. I believe that's not as good
because it produces error messages saying that std::hash lacks an operator()
rather than that the template has incomplete type. Better yet would be finding
a way to include "please specialize me" in the error message.

[Bug c++/51554] ICE in cp/semantics.c:cxx_eval_indirect_ref with -Wall

[dnovillo at google dot com]

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

--- Comment #2 from dnovillo at google dot com  
2011-12-14 22:32:33 UTC ---
Wow, that was quick, thanks!


Diego.

On Wed, Dec 14, 2011 at 17:26, jason at gcc dot gnu.org
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51554
>
> --- Comment #1 from Jason Merrill  2011-12-14 
> 22:26:27 UTC ---
> Author: jason
> Date: Wed Dec 14 22:26:24 2011
> New Revision: 182346
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182346
> Log:
>    PR c++/51554
>    * semantics.c (cxx_eval_indirect_ref): Fix sanity check.
>
> Added:
>    trunk/gcc/testsuite/g++.dg/init/constant1.C
> Modified:
>    trunk/gcc/cp/ChangeLog
>    trunk/gcc/cp/semantics.c
>    trunk/gcc/testsuite/ChangeLog
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.

[Bug c++/51248] [4.6/4.7 Regression] ICE with pointer to enum

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-12-14 
22:33:42 UTC ---
Author: jason
Date: Wed Dec 14 22:33:39 2011
New Revision: 182348

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182348
Log:
PR c++/51248
* decl.c (copy_type_enum): Also update variants.
(finish_enum): Allow variants of complete enums.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/other/enum2.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/decl.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug c++/51248] [4.6/4.7 Regression] ICE with pointer to enum

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2011-12-14 
22:38:19 UTC ---
Fixed, thanks.

[Bug middle-end/16458] PowerPC - redundant compare

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner  2011-12-14 
22:42:57 UTC ---
Created attachment 26091
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26091
Another partial fix...

Answering Nathan's comment from his patch:

+/* These are unsigned values, perhaps there will be a later
+   ordering compare that can be shared with this one.
+   Unfortunately we cannot detect the signedness of the operands
+   for non-subregs.  */

Actually, there is a way to tell whether some of our non-subreg operands are
unsigned or not.  For register operands of user defined variables:

  TYPE_UNSIGNED (TREE_TYPE (REG_EXPR (rtx)))

will be true if the operand is unsigned.  I've attached a patch that implements
that and it does fix the test case.  It also fixes a problem I encountered with
switch statements and -fno-jump-tables:

  enum CASE_VALUES {
CASE0 = 0,
CASE1,
CASE2,
CASE3,
CASE4
  };

  int
  test_switch (enum CASE_VALUES index)
  {
switch (index)
  {
case CASE0: return case0 ();
case CASE1: return case1 ();
case CASE2: return case2 ();
case CASE3: return case3 ();
case CASE4: return case4 ();
default:return cased ();
  }
  }

Currently, GCC generates (-fno-jump-tables) the following, because it notices
that the enum contains no negative values, so it marks index as unsigned and we
end up with unsigned compares (modulo the equality compares) so we cannot CSE
them:

test_switch:
cmpwi 7,3,2
beq 7,.L5
cmplwi 7,3,2
ble 7,.L10
cmpwi 7,3,3
beq 7,.L6
...

With the attached patch, we generate all unsigned compares and CSE is able to
remove the redundant compares:

test_switch:
cmplwi 7,3,2
beq 7,.L5
ble 7,.L10
cmplwi 7,3,3
beq 7,.L6
...

The patch still does not handle:

  if (*a == *b)
...
  else if (*a > *b)
...

or:

  switch (*index)
  ...

but we couldn't handle those before anyway.

[Bug c++/51559] New: decimal128 operates incorrectly compared to decimal32 and decimal64

[mingodad at gmail dot com]

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

 Bug #: 51559
   Summary: decimal128 operates incorrectly compared to decimal32
and decimal64
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mingo...@gmail.com


Created attachment 26092
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26092
Program that demostrates decimal128 fault

Testing the new decimal classes on g++ mingw4.6.1.2 with this program the
decimal32 and decimal64 are showing the expected answer but decimal128 doesn't
all parameters are equal but the result not.

With all 3 decimal classes three instances are created with the following
values:

std::decimal::decimal* dn(.3), dn2(.099), dn3(1000), dn4(201);
dn-=dn2;
dn*=dn3;
cout << "decimal* = "  << (dn==dn4) << " : " << decimal*_to_double(dn) << endl;

Expects "dn==dn4" on all but decimal128 fails.

[Bug c++/51554] ICE in cp/semantics.c:cxx_eval_indirect_ref with -Wall

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  2011-12-14 
22:55:50 UTC ---
Fixed.

[Bug c++/51228] [4.5/4.6/4.7 Regression] ICE with transparent union

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-12-14
 CC||jason at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug libstdc++/51558] Declaration of unspecialized std::hash<_Tp>::operator()(_Tp) turns compile-time errors into link-time errors

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-12-14 
22:57:11 UTC ---
Could we put a static_assert in the default operator() definition?

[Bug debug/51471] [4.7 Regression] gcc.c-torture/execute/20040811-1.c and gcc.c-torture/execute/vla-dealloc-1.c fails at -O3 -g on mips64-linux-gnu

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski  2011-12-14 
22:58:55 UTC ---
This is the patch which I am testing:
Index: genattrtab.c
===
--- genattrtab.c(revision 182342)
+++ genattrtab.c(working copy)
@@ -4280,6 +4280,11 @@ write_eligible_delay (const char *kind)
   printf ("  if (!INSN_P (candidate_insn))\n");
   printf ("return 0;\n");
   printf ("\n");
+  /* Frame related instructions are hard to put in the delay slot for
+ debugging info reasons. */
+  printf ("  if (RTX_FRAME_RELATED_P (candidate_insn))\n");
+  printf ("return 0;\n");
+  printf ("\n");

   /* If more than one delay type, find out which type the delay insn is.  */

[Bug c++/51473] [c++0x] ICE with auto and friend

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

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

[Bug c++/51457] Add warning about impossible boolean comparisons

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Andrew Pinski  2011-12-14 
23:09:55 UTC ---
Dup of bug 44077

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

[Bug c/44077] -Wtype-limits fails to warn for _Bool comparisons

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-14
 Ever Confirmed|0   |1

--- Comment #2 from Andrew Pinski  2011-12-14 
23:10:40 UTC ---
Confirmed, happens for both the C and C++ front-ends.

[Bug c/44077] -Wtype-limits fails to warn for _Bool comparisons

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||lloyd at randombit dot net

--- Comment #1 from Andrew Pinski  2011-12-14 
23:09:55 UTC ---
*** Bug 51457 has been marked as a duplicate of this bug. ***

[Bug target/51050] [AVR, attiny26] ICE: invalid rtl sharing found in the insn

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-14
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

[Bug tree-optimization/51557] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2244 with custom flags

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-12-14
 CC||jakub at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

[Bug c/50286] Missed optimization, fails to propagate bool

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-14
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2011-12-14 
23:23:20 UTC ---
++i<1+flag gets changed to:
++i<=flag

Which we don't turn back into:
++i<(flag?1:2)

[Bug c++/51458] [4.7 Regression] Accepts invalid designated initializers

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-12-14
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug rtl-optimization/51353] GCC incorrectly optimizes away assignment to return address

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2011-12-14 
23:28:00 UTC ---
I think this should be:
*(((volatile void **)__builtin_frame_address(0))+1) = exc;

GCC thinks it does not alias thing which is why it is removing it.

[Bug c++/51331] [4.6/4.7 Regression] bad code generated when explicitly calling auto-generated constructor of virtual base

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||4.1.2
   Target Milestone|--- |4.6.3
Summary|bad code generated when |[4.6/4.7 Regression] bad
   |explicitly calling  |code generated when
   |auto-generated constructor  |explicitly calling
   |of virtual base |auto-generated constructor
   ||of virtual base

[Bug middle-end/51279] xplor-nih-2.27/nmrPot/solnScatPot.cc ICEs on -O1 -funroll-loops

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #7 from Andrew Pinski  2011-12-14 
23:39:47 UTC ---
So closing as fixed.

[Bug tree-optimization/51557] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2244 with custom flags

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2011-12-14 
23:40:58 UTC ---
Created attachment 26093
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26093
gcc47-pr51557.patch

Untested fix.