[Bug c/48552] ICE with void type expressions in asm inputs/outputs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Jakub Jelinek  2011-04-12 
07:04:44 UTC ---
Fixed.

[Bug c/48517] [4.6/4.7 Regression] ICE in build_unary_op, at c-typeck.c:3786

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2011-04-12 
07:06:24 UTC ---
Fixed.

[Bug testsuite/48565] libstdc++ testsuite failures when using -pipe

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-04-12 
07:48:36 UTC ---
Those tests have to use -save-temps to inspect the assembler output, I think
the answer is to not use -pipe

[Bug libstdc++/48566] libstdc++-v3 testsuite failures due to missing includes

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.12 07:50:00
  Component|testsuite   |libstdc++
   Target Milestone|--- |4.6.1
 Ever Confirmed|0   |1

--- Comment #2 from Paolo Carlini  2011-04-12 
07:50:00 UTC ---
Ok, thanks. Will apply your patch momentarily.

[Bug c++/48557] [C++0x][SFINAE] Hard errors with void as operand of binary built-in operators

[daniel.kruegler at googlemail dot com]

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

--- Comment #1 from Daniel Krügler  
2011-04-12 07:52:17 UTC ---
Oops: The first comment was supposed to mean:

"The following program is *ill-formed*, but should be well-formed according to
SFINAE rules:"

[Bug c/48564] good hello welell some.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Jonathan Wakely  2011-04-12 
08:52:01 UTC ---
invalid

[Bug c/48568] New: Missing documentation for __attribute__((visibility ("protected"))) on variables.

[nisse at lysator dot liu.se]

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

   Summary: Missing documentation for __attribute__((visibility
("protected"))) on variables.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ni...@lysator.liu.se


I discovered that __attribute__((visibility ("protected"))) is supported on
variables, not just on functions. This should be documented in the node
"Variable Attributes" in the GCC manual

This feature is useful in particular for accessing read-only tables (allocated
in the .rodata section) from PIC code. By default, access to such data in other
compilation units is done via the GOT table. Using the above attribute (and
assuming that the definition is linked into in the same shared library file),
the GOT lookup is omitted, and instead one gets a direct access via pc-relative
addressing. I was working on GNU/linux x86_64, where this corresponds to 

  .protected table
  lea table(%rip), %rax  # To get the address of the table

rather than the default

  mov table@GOTPCREL(%rip), %rax

in assembler input. I admit I don't fully understand the .protected pseudo op,
but it's appearantly essential for getting the linker to do the right thing
when linking the shared library (gcc -shared table-def.o table-use.o -o
lib.so).

Regards,
/Niels Möller

[Bug rtl-optimization/48434] [4.7 Regression] Large SpecCPUFP Performance Regression for Thumb-2

[ibolton at gcc dot gnu.org]

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

Ian Bolton  changed:

   What|Removed |Added

   Keywords||patch
 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Ian Bolton  2011-04-12 09:02:25 
UTC ---
This regression went away between r172185 and r172255.  Performance is back to
normal for SpecFP for Thumb-2 VFP.

It was most likely fixed as a result of the PR48435 fix.

The patch for that is here:
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00573.html.

[Bug testsuite/21164] libjava tests uses absolute paths

[ro at gcc dot gnu.org]

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

--- Comment #3 from Rainer Orth  2011-04-12 09:04:09 UTC 
---
Author: ro
Date: Tue Apr 12 09:04:05 2011
New Revision: 172302

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172302
Log:
libjava:
PR testsuite/21164
* testsuite/lib/libjava.exp: Load dg.exp.
* testsuite/libjava.jar/jar.exp (gcj_jar_interpret): Strip srcdir
from jarfile.
Use result for messages.
* testsuite/libjava.loader/loader.exp (gcj_loader_test_one): Pass
errname to libjava_invoke, fix testname.

gcc:
PR testsuite/21164
* lib/compat.exp (compat-execute): Declare unsupported after
stripping path from src1.
* lib/lto.exp (lto-execute): Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/compat.exp
trunk/gcc/testsuite/lib/lto.exp
trunk/libjava/ChangeLog
trunk/libjava/testsuite/lib/libjava.exp
trunk/libjava/testsuite/libjava.jar/jar.exp
trunk/libjava/testsuite/libjava.loader/loader.exp

[Bug libstdc++/48566] libstdc++-v3 testsuite failures due to missing includes

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  
2011-04-12 09:05:33 UTC ---
Author: paolo
Date: Tue Apr 12 09:05:30 2011
New Revision: 172303

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172303
Log:
2011-04-12  Allan McRae  

PR libstdc++/48566
* testsuite/tr1/6_containers/unordered_map/requirements/
iterator_null_neg.cc: Include .
* testsuite/tr1/6_containers/unordered_set/requirements/
iterator_null_neg.cc: Likewise.
* testsuite/27_io/basic_filebuf/seekoff/wchar_t/4.cc: Include
.
* testsuite/util/testsuite_common_types.h: Include .
* testsuite/29_atomics/atomic_integral/cons/assign_neg.cc:
Adjust dg-error line numbers.
* testsuite/29_atomics/atomic_integral/cons/copy_neg.cc: Likewise.
* testsuite/29_atomics/atomic_integral/operators/increment_neg.cc:
Likewise.
* testsuite/29_atomics/atomic_integral/operators/bitwise_neg.cc:
Likewise.
* testsuite/29_atomics/atomic_integral/operators/decrement_neg.cc:
Likewise.
* testsuite/29_atomics/atomic/cons/assign_neg.cc: Likewise.
* testsuite/29_atomics/atomic/cons/copy_neg.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/27_io/basic_filebuf/seekoff/wchar_t/4.cc
trunk/libstdc++-v3/testsuite/29_atomics/atomic/cons/assign_neg.cc
trunk/libstdc++-v3/testsuite/29_atomics/atomic/cons/copy_neg.cc
trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/assign_neg.cc
trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/copy_neg.cc
   
trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/operators/bitwise_neg.cc
   
trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/operators/decrement_neg.cc
   
trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/operators/increment_neg.cc
   
trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered_map/requirements/iterator_null_neg.cc
   
trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered_set/requirements/iterator_null_neg.cc
trunk/libstdc++-v3/testsuite/util/testsuite_common_types.h

[Bug libstdc++/48566] libstdc++-v3 testsuite failures due to missing includes

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  
2011-04-12 09:05:45 UTC ---
Author: paolo
Date: Tue Apr 12 09:05:41 2011
New Revision: 172304

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172304
Log:
2011-04-12  Allan McRae  

PR libstdc++/48566
* testsuite/tr1/6_containers/unordered_map/requirements/
iterator_null_neg.cc: Include .
* testsuite/tr1/6_containers/unordered_set/requirements/
iterator_null_neg.cc: Likewise.
* testsuite/27_io/basic_filebuf/seekoff/wchar_t/4.cc: Include
.
* testsuite/util/testsuite_common_types.h: Include .
* testsuite/29_atomics/atomic_integral/cons/assign_neg.cc:
Adjust dg-error line numbers.
* testsuite/29_atomics/atomic_integral/cons/copy_neg.cc: Likewise.
* testsuite/29_atomics/atomic_integral/operators/increment_neg.cc:
Likewise.
* testsuite/29_atomics/atomic_integral/operators/bitwise_neg.cc:
Likewise.
* testsuite/29_atomics/atomic_integral/operators/decrement_neg.cc:
Likewise.
* testsuite/29_atomics/atomic/cons/assign_neg.cc: Likewise.
* testsuite/29_atomics/atomic/cons/copy_neg.cc: Likewise.

Modified:
branches/gcc-4_6-branch/libstdc++-v3/ChangeLog
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/27_io/basic_filebuf/seekoff/wchar_t/4.cc
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/29_atomics/atomic/cons/assign_neg.cc
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/29_atomics/atomic/cons/copy_neg.cc
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/assign_neg.cc
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/copy_neg.cc
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/29_atomics/atomic_integral/operators/bitwise_neg.cc
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/29_atomics/atomic_integral/operators/decrement_neg.cc
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/29_atomics/atomic_integral/operators/increment_neg.cc
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/tr1/6_containers/unordered_map/requirements/iterator_null_neg.cc
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/tr1/6_containers/unordered_set/requirements/iterator_null_neg.cc
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/util/testsuite_common_types.h

[Bug testsuite/21164] libjava tests uses absolute paths

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Rainer Orth  2011-04-12 09:06:01 UTC 
---
Fixed for 4.7.0.

[Bug libstdc++/48566] libstdc++-v3 testsuite failures due to missing includes

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Paolo Carlini  2011-04-12 
09:08:09 UTC ---
Done.

[Bug libstdc++/48476] [C++0x] conversion between std::tuple which have reference member is rejected

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #9 from Paolo Carlini  2011-04-12 
09:10:38 UTC ---
On it.

[Bug testsuite/48565] libstdc++ testsuite failures when using -pipe

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-04-12 
09:44:47 UTC ---
Or sed it out of C{XXFLAGS} when determining what flags to pass to the
testsuite.

[Bug c++/48569] New: internal compiler error: in build_zero_init_1, at cp/init.c:278

[mario-baumann at web dot de]

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

   Summary: internal compiler error: in build_zero_init_1, at
cp/init.c:278
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mario-baum...@web.de


Created attachment 23961
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23961
bzipped preprocessed c++ source

Hi all,

attached preprocessed c++ source fails with ICE in build_zero_init_1, at
cp/init.c:278

It fails with '-m32', '-O0' and '-O1' too!

Mario.

> uname -a
Linux ahsoka.intec.dom 2.6.32-71.24.1.el6.x86_64 #1 SMP Sat Mar 26 16:05:19 EDT
2011 x86_64 x86_64 x86_64 GNU/Linux

> rpm -qa "glibc*" | grep -e 'glibc-[0-9]' | sort -u
glibc-2.12-1.7.el6_0.5.i686
glibc-2.12-1.7.el6_0.5.x86_64

> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/app2/gcc/4.7.0-20110411-svn172252/x86_64/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/app2/gcc/4.7.0-20110411-svn172252/x86_64
--enable-languages=c,c++,fortran --disable-nls
--with-gmp=/app2/gcc/4.7.0-20110411-svn172252/x86_64/aux
--with-mpfr=/app2/gcc/4.7.0-20110411-svn172252/x86_64/aux
--with-mpc=/app2/gcc/4.7.0-20110411-svn172252/x86_64/aux
--with-ppl=/app2/gcc/4.7.0-20110411-svn172252/x86_64/aux
--with-cloog=/app2/gcc/4.7.0-20110411-svn172252/x86_64/aux
Thread model: posix
gcc version 4.7.0 20110411 (experimental) (GCC) 

> ld -v
GNU ld (GNU Binutils) 2.21.51.20110411

[Bug bootstrap/48556] Gcc 4.6.0 bootstrap fails with in-tree GMP/MPFR/MPC

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-04-12 
10:27:10 UTC ---
You should always prefer the system versions of these libraries.  For example
ppl links against gmp already.

[Bug middle-end/48558] -Warray-bounds fails to detect the out of bound array access

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.12 10:28:18
 Ever Confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #3 from Richard Guenther  2011-04-12 
10:28:18 UTC ---
Confirmed.

[Bug middle-end/48560] [4.6/4.7 Regression] -Warray-bounds fails to detect the out of bound array access

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX
   Target Milestone|--- |4.6.1

--- Comment #1 from Richard Guenther  2011-04-12 
10:31:23 UTC ---
Because we fold s[30] to '\0' before the warning code gets a chance to trigger.
The code contains undefined behavior so we can do that.

[Bug libstdc++/48476] [C++0x] conversion between std::tuple which have reference member is rejected

[paolo at gcc dot gnu.org]

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

--- Comment #10 from paolo at gcc dot gnu.org  
2011-04-12 10:31:37 UTC ---
Author: paolo
Date: Tue Apr 12 10:31:33 2011
New Revision: 172309

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172309
Log:
2011-04-12  Takaya Saito  

PR libstdc++/48476
* include/std/tuple (_Tuple_impl<>::_Tuple_impl(_Tuple_impl<>&&),
_Tuple_impl<>::operator=(_Tuple_impl&&), _Tuple_impl<>::operator=
(_Tuple_impl<>&&), tuple_cat): Use std::forward where appropriate.
* testsuite/20_util/tuple/cons/48476.cc: New.
* testsuite/20_util/tuple/48476.cc: Likewise.
* testsuite/20_util/tuple/creation_functions/48476.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/20_util/tuple/48476.cc
trunk/libstdc++-v3/testsuite/20_util/tuple/cons/48476.cc
trunk/libstdc++-v3/testsuite/20_util/tuple/creation_functions/48476.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/tuple

[Bug c/48561] internal compiler error: in change_address_1, at emit-rtl.c:1954

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.04.12 10:32:00
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-04-12 
10:32:00 UTC ---
-EMISSINGATTACHMENT

[Bug middle-end/48563] EOF not at EOL

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.04.12 10:35:13
 Ever Confirmed|0   |1

--- Comment #3 from Richard Guenther  2011-04-12 
10:35:13 UTC ---
GCC 3.4.x is no longer supported.  Please update to at least 4.3.x, preferably
4.5.x or 4.6.0 though.

Also we need preprocessed source, not just the C file.  You can obtain it
by appending -save-temps to the compile command that fails.

[Bug c/48568] Missing documentation for __attribute__((visibility ("protected"))) on variables.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||documentation
   Severity|normal  |enhancement

[Bug c/46076] [4.6/4.7 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[rguenth at gcc dot gnu.org]

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

--- Comment #24 from Richard Guenther  2011-04-12 
10:44:20 UTC ---
Author: rguenth
Date: Tue Apr 12 10:44:15 2011
New Revision: 172310

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

PR tree-optimization/46076
* gimple.h (struct gimple_statement_call): Add fntype field.
(gimple_call_fntype): Adjust.
(gimple_call_set_fntype): New function.
* gimple.c (gimple_build_call_1): Set the call function type.
* gimplify.c (gimplify_call_expr): Preserve the function
type the frontend used for the call.
(gimplify_modify_expr): Likewise.
* lto-streamer-in.c (input_gimple_stmt): Input the call stmts
function type.
* lto-streamer-out.c (output_gimple_stmt): Output the call stmts
function type.
* tree-ssa.c (useless_type_conversion_p): Function pointer
conversions are useless.

* gcc.dg/tree-ssa/pr46076.c: Un-XFAIL.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple.c
trunk/gcc/gimple.h
trunk/gcc/gimplify.c
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer-out.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr46076.c
trunk/gcc/tree-ssa.c

[Bug java/48515] [4.6] GCJ fails to compile jni.cc because of reflection errors on i686-w64-mingw32 target

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.04.12 10:52:07
 CC||ktietz at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Kai Tietz  2011-04-12 10:52:07 
UTC ---
Bug is fixed on trunk. Not sure if java-maintainer want a back-merge of it to
4.6

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[mh+gcc at glandium dot org]

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

--- Comment #84 from Mike Hommey  2011-04-12 
10:53:44 UTC ---
(In reply to comment #83)
> > I am not sure if this is GCC bug or elfhack, but I would guess for
> elfhack actually.
> 
> I guess you're right, because when I move the swap definitions:
> 
> template 
> inline void Elf_Ehdr_Traits::swap(T &t, R &r)
> ...
> 
> from elf.cpp to elfxx.h (where they actually belong) the 
> link error vanishes.

I'm not convinced they belong there. But wouldn't removing the "inline" keyword
work equally well?

[Bug rtl-optimization/48549] [4.6/4.7 Regression] Combiner ICE with -g

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-04-12 
10:53:50 UTC ---
Author: jakub
Date: Tue Apr 12 10:53:47 2011
New Revision: 172311

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172311
Log:
PR rtl-optimization/48549
* combine.c (propagate_for_debug): Also stop after BB_END of
this_basic_block.  Process LAST and just stop processing after it.
(combine_instructions): If last_combined_insn has been deleted,
set last_combined_insn to its PREV_INSN.

* g++.dg/opt/pr48549.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr48549.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug target/48519] wrong return-value, with an if () {} after return

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #6 from Kai Tietz  2011-04-12 11:00:19 
UTC ---
Hmm, tested it for 32-bit and 64-bit mingw on trunk and for 4.6.x and can't
reproduce the issue.
It shows always:
abc
10

as expected.

[Bug regression/48570] New: gcc-4.6: wrong subscription with -std=c++0x

[holger.hopp at sap dot com]

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

   Summary: gcc-4.6: wrong subscription with -std=c++0x
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: holger.h...@sap.com


gcc-4.6 and trunk produce wrong results here.
I expect return 1 (==), but gcc-4.6 and trunk return 0 (!=).

$ g++ -std=c++0x t.c && ./a.out

gcc-4.5 and gcc-4.6 without -std=c++0x work correctly,
char type works correctly, but not wchar_t, char16_t, char32_t.


int main()
{
  wchar_t z = (L"01234")[1];
  return (z == L'1');
}

[Bug regression/48570] gcc-4.6: wrong subscription with -std=c++0x

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.12 12:16:25
 CC||jakub at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2011-04-12 
12:16:25 UTC ---
Confirmed, though better would be to test for != so that the correct exit value
is 0:

// PR c++/48570
// { dg-do run }
// { dg-options "-std=c++0x" }

int
main ()
{
  wchar_t z = L"01234"[1];
  return z != L'1';
}

This started failing with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170488

[Bug tree-optimization/48571] New: Missed data-dependence for (bogus?) reconstructed array-refs

[rguenth at gcc dot gnu.org]

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

   Summary: Missed data-dependence for (bogus?) reconstructed
array-refs
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
Target: i?86-*-*


We vectorize the following loop, ignoring dependences between c[i] and c[i-1].

unsigned int c[624];
void
bar (void)
{
  unsigned int i;
  for (i = 1; i < 624; ++i)
/* Obfuscated c[i] = c[i-1] * 2.  */
*(unsigned int *)((void *)c + (__SIZE_TYPE__)i * 4)
= *(unsigned int *)((void *)c + ((__SIZE_TYPE__)i +
((__SIZE_TYPE__)-4)/4) * 4) * 2;
}

This is because we re-construct array-refs

:
  # i_17 = PHI 
  # ivtmp.8_21 = PHI 
  D.2689_3 = (long unsigned int) i_17;
  D.2692_7 = D.2689_3 + 1073741823;
  D.2695_10 = MEM[(unsigned int *)&c][D.2692_7]{lb: 0 sz: 4};
  D.2696_11 = D.2695_10 * 2;
  MEM[(unsigned int *)&c][D.2689_3]{lb: 0 sz: 4} = D.2696_11;

and the array index D.2692_7 is out of bounds (but of course the address
computation will make the access wrap into the correct place).

The middle-end happily performs such obfuscation via
fold_plusminus_mult_expr from (i*4 + -4U).
The array-refs are re-built by forwprop.

I'm not sure who is wrong here - bogus constrained interpretation of
array-refs by data dependence analysis or bogus construction of
constrained array-refs from pointer arithmetic.

Executable testcase, x86_64, -O3 -msse2 -m32:

unsigned int c[624];
void __attribute__((noinline))
bar (void)
{
  unsigned int i;
  /* Obfuscated c[i] = c[i-1] * 2.  */
  for (i = 1; i < 624; ++i)
*(unsigned int *)((void *)c + (__SIZE_TYPE__)i * 4)
= 2 * *(unsigned int *)((void *)c + ((__SIZE_TYPE__)i +
((__SIZE_TYPE__)-4)/4) * 4);
}
extern void abort (void);
int
main()
{
  unsigned int i, j;
  for (i = 0; i < 624; ++i)
c[i] = 1;
  bar();
  j = 1;
  for (i = 0; i < 624; ++i)
{
  if (c[i] != j)
abort ();
  j = j * 2;
}
  return 0;
}

[Bug regression/48570] gcc-4.6: wrong subscription with -std=c++0x

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.1

[Bug tree-optimization/48571] [4.5/4.6/4.7 Regression] Missed data-dependence for (bogus?) reconstructed array-refs

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Known to work||4.4.4
   Target Milestone|--- |4.5.3
Summary|Missed data-dependence for  |[4.5/4.6/4.7 Regression]
   |(bogus?) reconstructed  |Missed data-dependence for
   |array-refs  |(bogus?) reconstructed
   ||array-refs
  Known to fail||4.5.2, 4.6.0, 4.7.0

[Bug regression/48570] gcc-4.6: wrong subscription with -std=c++0x

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-04-12 
12:21:48 UTC ---
Breakpoint 1, main () at sub.cc:4
4 const wchar_t& z0 = (L"01234")[0];
(gdb) n
5 const wchar_t& z1 = (L"01234")[1];
(gdb)
6 const wchar_t& z2 = (L"01234")[2];
(gdb)
7 const wchar_t& z3 = (L"01234")[3];
(gdb)
8 return (z1 == L'1');
(gdb) p z0
$1 = (const wchar_t &) @0x7fffe590: 48 L'0'
(gdb) p z1
$2 = (const wchar_t &) @0x7fffe594: 0 L'\000'
(gdb) p z2
$3 = (const wchar_t &) @0x7fffe598: 0 L'\000'
(gdb) p z3
$4 = (const wchar_t &) @0x7fffe59c: 0 L'\000'

The string literal contains zeroes past the first character

[Bug tree-optimization/48571] [4.5/4.6/4.7 Regression] Missed data-dependence for (bogus?) reconstructed array-refs

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-04-12 
12:24:46 UTC ---
To also fail for 64bit change it to

  for (i = 1; i < 624; ++i)
{
  __SIZE_TYPE__ ii = (__SIZE_TYPE__)i + ((__SIZE_TYPE__)-4)/4;
  *(unsigned int *)((void *)c + (__SIZE_TYPE__)i * 4)
  = 2 * *(unsigned int *)((void *)c + ii * 4);
}

to prevent fold from pulling the multiplication inside.

[Bug regression/48570] gcc-4.6: wrong subscription with -std=c++0x

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-04-12 
12:30:54 UTC ---
Yeah, cxx_eval_array_reference doesn't expect to have sizeof (x) > 1 accesses
to STRING_CSTs.  Unfortunately, fold_read_from_constant_string doesn't handle
those either, and as for C++0x I fear it must always succeed, it will need to
handle all the endianity fun.

[Bug regression/48570] gcc-4.6: wrong subscription with -std=c++0x

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  2011-04-12 12:44:03 UTC ---
There are lots of optimizations that are only present for narrow strings 
but logically make sense for wide strings as well (for example, some str* 
and mem* built-in functions should logically have wcs* and wmem* analogues 
... it was while looking at that some time ago that I found glibc's 
wmemcmp was wrongly comparing wide characters as type wint_t instead of 
wchar_t).  Hopefully not many cases need addressing to fix this wrong-code 
bug, but the infrastructure for extracting values from wide string 
constants could be of use in future for dealing with the more general 
missing optimizations.

[Bug tree-optimization/48571] [4.5/4.6/4.7 Regression] Missed data-dependence for (bogus?) reconstructed array-refs

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-04-12 
13:11:56 UTC ---
Re-constructing array-refs (and thus an index space) is invalid.  Which means
the C frontend should better change its behavior and not lower all array
accesses to pointer arithmetic and dereferences.

[Bug target/48572] New: [4.7 regression] gcc.target/mips/mips-{3d,ps}-?.c tests ICE on IRIX 6.5

[ro at gcc dot gnu.org]

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

   Summary: [4.7 regression] gcc.target/mips/mips-{3d,ps}-?.c
tests ICE on IRIX 6.5
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: richard.sandif...@linaro.org
  Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
 Build: mips-sgi-irix6.5


Between 20110322 and 20110401,several mips-3d-?.c and mips-ps-?.c tests started
to fail on IRIX 6.5, e.g.

Downgraded to a 'link' test due to unsupported option '-mips3d'
Downgraded to an 'assemble' test due to incompatible arch option (-march=mips3
changed to -mips64)
Executing on host: /var/gcc/regression/trunk/6.5-gcc/build/gcc/xgcc
-B/var/gcc/regression/trunk/6.5-gcc/build/gcc/  
-DNOMIPS16=__attribute__((nomips16)) -mips64 -mhard-float -mfp64 -mips3d -O2
-mpaired-single -c  -o mips-3d-1.o
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/mips/mips-3d-1.c   
(timeout = 600)
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/mips/mips-3d-1.c: In
function 'main':

/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/mips/mips-3d-1.c:127:1:
error: unable to find a register to spill in class 'GR_REGS'

/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/mips/mips-3d-1.c:127:1:
error: this is the insn:

(insn 26 6 28 2 (set (reg:CCV2 253)

(unspec:CCV2 [

(reg/v:V2SF 34 $f2 [orig:197 c ] [197])

(reg/v:V2SF 35 $f3 [orig:194 d ] [194])

(const_int 2 [0x2])

] UNSPEC_C))
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/mips/mips-3d-1.c:31 677
{mips_c_cond_ps}

 (expr_list:REG_DEAD (reg/v:V2SF 34 $f2 [orig:197 c ] [197])

(expr_list:REG_DEAD (reg/v:V2SF 35 $f3 [orig:194 d ] [194])

(expr_list:REG_EQUAL (unspec:CCV2 [

(reg/v:V2SF 34 $f2 [orig:197 c ] [197])

(const_vector:V2SF [

(const_double:SF 4.6e+1 [0x0.b8p+6])

(const_double:SF 1.12e+2 [0x0.ep+7])

])

(const_int 2 [0x2])

] UNSPEC_C)

(nil)

/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/mips/mips-3d-1.c:127:1:
internal compiler error: in spill_failure, at reload1.c:2113

This is a regression from 4.6.

[Bug target/48519] wrong return-value, with an if () {} after return

[hilmar.ackermann at googlemail dot com]

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

--- Comment #7 from Herbert  2011-04-12 
13:41:06 UTC ---
Hi,

I don't know why I am the only one with the bug ..? The bug doesn't happen if I
write a second return at the end of the function, so I can solve the problem,
but anyway it's curious.. Maybe someone with the integrated installation of
MinGW in Code::Blocks can test this, perhaps there is a bug, don't know ..  ;)

regards

[Bug target/48090] [4.5 Regression] gcc 4.5.2 miscompilation when building on arm

[ramana at gcc dot gnu.org]

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

--- Comment #12 from Ramana Radhakrishnan  
2011-04-12 13:42:52 UTC ---
Author: ramana
Date: Tue Apr 12 13:42:48 2011
New Revision: 172318

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

Fix PR target/48090

2011-04-12  Ramana Radhakrishnan  

   PR target/48090
   * config/arm/arm.md (*arm_negdi2): Fix early clobber constraints.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md

[Bug rtl-optimization/48549] [4.6/4.7 Regression] Combiner ICE with -g

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-04-12 
13:44:35 UTC ---
Author: jakub
Date: Tue Apr 12 13:44:33 2011
New Revision: 172319

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172319
Log:
PR rtl-optimization/48549
* combine.c (propagate_for_debug): Also stop after BB_END of
this_basic_block.  Process LAST and just stop processing after it.
(combine_instructions): If last_combined_insn has been deleted,
set last_combined_insn to its PREV_INSN.

* g++.dg/opt/pr48549.C: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/opt/pr48549.C
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/combine.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/48549] [4.6/4.7 Regression] Combiner ICE with -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Jakub Jelinek  2011-04-12 
13:45:23 UTC ---
Fixed.

[Bug target/48090] [4.5 Regression] gcc 4.5.2 miscompilation when building on arm

[ramana at gcc dot gnu.org]

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

--- Comment #13 from Ramana Radhakrishnan  
2011-04-12 13:52:49 UTC ---
Author: ramana
Date: Tue Apr 12 13:52:46 2011
New Revision: 172320

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

Fix PR target/48090


Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/arm/arm.md

[Bug target/48090] [4.5 Regression] gcc 4.5.2 miscompilation when building on arm

[ramana at gcc dot gnu.org]

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

--- Comment #14 from Ramana Radhakrishnan  
2011-04-12 13:53:39 UTC ---
Still need to backport and test on the 4.6 branch. That is next.

Ramana

[Bug target/48090] [4.5 Regression] gcc 4.5.2 miscompilation when building on arm

[froydnj at codesourcery dot com]

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

--- Comment #15 from froydnj at codesourcery dot com  2011-04-12 13:55:57 UTC ---
On Tue, Apr 12, 2011 at 01:53:48PM +, ramana at gcc dot gnu.org wrote:
> Still need to backport and test on the 4.6 branch. That is next.

Small procedural note: it is preferred to go trunk -> 4.6 -> 4.5, rather
than trunk -> 4.5 -> 4.6, even if the bug is reported against 4.5.

[Bug regression/48570] gcc-4.6: wrong subscription with -std=c++0x

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-04-12 
14:01:38 UTC ---
Created attachment 23962
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23962
gcc46-pr48570.patch

Untested fix (tested just on the new testcase, both on x86_64 and with powerpc
cross to deal with endianity).

[Bug middle-end/48573] New: [4.7 Regression] Many testcase failures

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] Many testcase failures
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/ia32, revision 172316 gave

FAIL: c-c++-common/torture/complex-sign-mul-minus-one.c  -Os  (internal
compiler error)
FAIL: c-c++-common/torture/complex-sign-mul-minus-one.c  -Os  (internal
compiler error)
FAIL: c-c++-common/torture/complex-sign-mul-minus-one.c  -Os  (test for excess
errors)
FAIL: c-c++-common/torture/complex-sign-mul-minus-one.c  -Os  (test for excess
errors)
FAIL: c-c++-common/torture/complex-sign-mul-one.c  -Os  (internal compiler
error)
FAIL: c-c++-common/torture/complex-sign-mul-one.c  -Os  (internal compiler
error)
FAIL: c-c++-common/torture/complex-sign-mul-one.c  -Os  (test for excess
errors)
FAIL: c-c++-common/torture/complex-sign-mul-one.c  -Os  (test for excess
errors)
FAIL: gcc.c-torture/compile/20031208-1.c  -Os  (internal compiler error)
FAIL: gcc.c-torture/compile/20031208-1.c  -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/20080628-1.c  -Os  (internal compiler error)
FAIL: gcc.c-torture/compile/20080628-1.c  -Os  (test for excess errors)
FAIL: gcc.c-torture/execute/20020413-1.c compilation,  -Os  (internal compiler
error)
FAIL: gcc.c-torture/execute/20080502-1.c compilation,  -Os  (internal compiler
error)
FAIL: gcc.c-torture/execute/960513-1.c compilation,  -Os  (internal compiler
error)
FAIL: gcc.c-torture/execute/ieee/fp-cmp-8l.c compilation,  -Os  (internal
compiler error)
FAIL: gcc.c-torture/execute/ieee/inf-2.c compilation,  -Os  (internal compiler
error)
FAIL: gcc.c-torture/execute/ieee/inf-3.c compilation,  -Os  (internal compiler
error)
FAIL: gcc.c-torture/execute/pr44942.c compilation,  -Os  (internal compiler
error)
FAIL: gcc.c-torture/execute/stdarg-1.c compilation,  -Os  (internal compiler
error)
FAIL: gcc.c-torture/execute/stdarg-2.c compilation,  -Os  (internal compiler
error)
FAIL: gcc.dg/pr19402-2.c (internal compiler error)
FAIL: gcc.dg/pr19402-2.c (test for excess errors)
FAIL: gcc.dg/pr43305.c (internal compiler error)
FAIL: gcc.dg/pr43305.c (test for excess errors)
FAIL: gcc.dg/torture/builtin-convert-4.c  -Os  (internal compiler error)
FAIL: gcc.dg/torture/builtin-convert-4.c  -Os  (test for excess errors)
FAIL: gcc.dg/torture/builtin-math-2.c  -Os  (internal compiler error)
FAIL: gcc.dg/torture/builtin-math-2.c  -Os  (test for excess errors)
FAIL: gfortran.dg/c_kind_params.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/c_kind_params.f90  -Os  (test for excess errors)
FAIL: gfortran.dg/default_format_2.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/default_format_2.f90  -Os  (test for excess errors)
FAIL: gfortran.dg/default_format_denormal_2.f90  -Os  (internal compiler error)
FAIL: gfortran.dg/default_format_denormal_2.f90  -Os  (test for excess errors)
FAIL: gfortran.dg/large_real_kind_2.F90  -Os  (internal compiler error)
FAIL: gfortran.dg/large_real_kind_2.F90  -Os  (test for excess errors)
FAIL: libffi.call/float2.c -Os (test for excess errors)
FAIL: libgomp.c++/ctor-5.C  -Os  (internal compiler error)
FAIL: libgomp.c++/ctor-5.C  -Os  (test for excess errors)
FAIL: libgomp.fortran/allocatable2.f90  -Os  (internal compiler error)
FAIL: libgomp.fortran/allocatable2.f90  -Os  (test for excess errors)
FAIL: libgomp.fortran/appendix-a/a.22.7.f90  -Os  (internal compiler error)
FAIL: libgomp.fortran/appendix-a/a.22.7.f90  -Os  (test for excess errors)
FAIL: libgomp.fortran/threadprivate2.f90  -Os  (internal compiler error)
FAIL: libgomp.fortran/threadprivate2.f90  -Os  (test for excess errors)
FAIL: libgomp.fortran/threadprivate3.f90  -Os  (internal compiler error)
FAIL: libgomp.fortran/threadprivate3.f90  -Os  (test for excess errors)

revision 172311 is OK.

[Bug middle-end/48573] [4.7 Regression] Many testcase failures

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2011-04-12 14:03:18 
UTC ---
I got

/export/gnu/import/svn/gcc-test-ia32corei7/src-trunk/gcc/testsuite/gcc.c-torture/compile/20031208-1.c:
In function 'bar':^M
/export/gnu/import/svn/gcc-test-ia32corei7/src-trunk/gcc/testsuite/gcc.c-torture/compile/20031208-1.c:6:1:
error: unrecognizable insn:^M
(insn 6 5 7 3 (set (reg:SI 61)^M
(pre_dec:SI (reg/f:SI 7 sp)))
/export/gnu/import/svn/gcc-test-ia32corei7/src-trunk/gcc/testsuite/gcc.c-torture/compile/20031208-1.c:4
-1^M
 (nil))^M
/export/gnu/import/svn/gcc-test-ia32corei7/src-trunk/gcc/testsuite/gcc.c-torture/compile/20031208-1.c:6:1:
internal compiler error: in extract_insn, at recog.c:2109^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See  for instructions.^M

FAIL: gcc.c-torture/compile/20031208-1.c  -Os  (internal compiler error) 
FAIL: gcc.c-torture/compile/20031208-1.c  -Os  (test for excess errors)

[Bug middle-end/48573] [4.7 Regression] Many testcase failures

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org
   Target Milestone|--- |4.7.0

[Bug c++/48574] New: ICE (regression w.r.t. 4.6.0)

[vincenzo.innocente at cern dot ch]

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

   Summary: ICE (regression w.r.t. 4.6.0)
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


Created attachment 23963
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23963
unfiltered source file (after preprocessor) requires -mavx to compile

with 
data/newusr/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/data/newusr/bin/g++
COLLECT_LTO_WRAPPER=/data/newusr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/data/newusr -enable-gold=yes
--enable-lto --with-fpmath=avx --with-build-config=bootstrap-lto
--with-gmp-lib=/usr/local/lib64 --with-mpfr-lib=/usr/local/lib64
-with-mpc-lib=/usr/local/lib64
Thread model: posix
gcc version 4.6.1 20110408 (prerelease) (GCC) 

(and 20110401) 

I get
/data/newusr/bin/g++ -c produceICE.ii -std=c++0x -Wall -mavx
In file included from
/data/CMSSW_4_2_0_pre6/src/CommonTools/RecoAlgos/plugins/EtaPtMinGsfElectronFullCloneSelector.cc:16:0:
/data/CMSSW_4_2_0_pre6/src/CommonTools/RecoAlgos/interface/GsfElectronSelector.h:
In member function 'void
helper::GsfElectronCollectionStoreManager::cloneAndStore(const I&, const I&,
edm::Event&)':
/data/CMSSW_4_2_0_pre6/src/CommonTools/RecoAlgos/interface/GsfElectronSelector.h:49:60:
internal compiler error: Segmentation fault

This the first serious ICE I got compiling many 1000 of source units.

It compiles fine with
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/build/460e/slc5_amd64_gcc460/external/gcc/4.6.0/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure
--prefix=/build/460e/slc5_amd64_gcc460/external/gcc/4.6.0
--enable-languages=c,c++,fortran
--with-gmp=/build/460e/slc5_amd64_gcc460/external/gcc/4.6.0
--with-mpfr=/build/460e/slc5_amd64_gcc460/external/gcc/4.6.0
--with-mpc=/build/460e/slc5_amd64_gcc460/external/gcc/4.6.0
--with-ppl=/build/460e/slc5_amd64_gcc460/external/gcc/4.6.0
--with-cloog=/build/460e/slc5_amd64_gcc460/external/gcc/4.6.0
--enable-cloog-backend=isl --enable-shared CC='gcc -fPIC' CXX='c++ -fPIC'
Thread model: posix
gcc version 4.6.0 (GCC)

[Bug c++/48468] [C++0x][SFINAE] noexcept operator does not handle function templates well

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  2011-04-12 
14:33:15 UTC ---
Fixed for 4.6.1.

[Bug rtl-optimization/48575] New: RTL vector patterns are limited to 26 elements

[hjl.tools at gmail dot com]

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

   Summary: RTL vector patterns are limited to 26 elements
   Product: gcc
   Version: 4.7.0
   URL: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02105.htm
l
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


genrecog.c uses 26 lower case letters for vector elements.
Patterns like

;;(define_insn "vec_interleave_evenv32qi"
;;  [(set (match_operand:V32QI 0 "register_operand" "=r")
;;(vec_select:V32QI
;;  (vec_concat:V64QI
;;(match_operand:V32QI 1 "register_operand" "0")
;;(match_operand:V32QI 2 "register_operand" "r"))
;;  (parallel [(const_int  0) (const_int 32)
;; (const_int  2) (const_int 34)
;; (const_int  4) (const_int 36)
;; (const_int  6) (const_int 38)
;; (const_int  8) (const_int 40)
;; (const_int 10) (const_int 42)
;; (const_int 12) (const_int 44)
;; (const_int 14) (const_int 46)
;; (const_int 16) (const_int 48)
;; (const_int 18) (const_int 50)
;; (const_int 20) (const_int 52)
;; (const_int 22) (const_int 54)
;; (const_int 24) (const_int 56)
;; (const_int 26) (const_int 58)
;; (const_int 28) (const_int 60)
;; (const_int 30) (const_int 62)])))]
;;  ""
;;  "rimihv\t%0,%2,8,15,8"
;;  [(set_attr "type" "rimi")])

don't work since they have more 26 elements. There is no
fundamental reason to use lower case letters for vector
elements. A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02105.html

to use [0x80...UCHAR_MAX] for vector elements.

[Bug middle-end/48573] [4.7 Regression] Many testcase failures

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2011-04-12 14:40:54 
UTC ---
This is caused by revision 172316:

http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00511.html

[Bug c++/48574] ICE (regression w.r.t. 4.6.0)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.12 14:49:18
  Known to work||4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-04-12 
14:49:18 UTC ---
Confirmed.  Works with r171596.

#0  0x005fad6b in fixed_type_or_null (instance=0x7fffeb1116c0, 
nonnull=0x0, cdtorp=0x7fffb25c)
at /space/rguenther/src/svn/gcc-4_6-branch/gcc/cp/class.c:5828
#1  0x005fc452 in fixed_type_or_null (instance=0x7fffeb10c460, 
nonnull=0x0, cdtorp=0x7fffb25c)
at /space/rguenther/src/svn/gcc-4_6-branch/gcc/cp/class.c:5947
#2  0x005fae8e in fixed_type_or_null (instance=0x7fffeb111900, 
nonnull=0x0, cdtorp=0x7fffb25c)
at /space/rguenther/src/svn/gcc-4_6-branch/gcc/cp/class.c:5831
#3  0x005fc5a9 in resolves_to_fixed_type_p (instance=0x7fffeb111900, 
nonnull=0x0) at /space/rguenther/src/svn/gcc-4_6-branch/gcc/cp/class.c:5980
#4  0x004c28f9 in build_new_method_call (instance=0x7fffeb111900, 
fns=0x7fffebffbf00, args=0x7fffb888, conversion_path=0x7fffebff40d0, 
flags=3, fn_p=0x0, complain=3)
at /space/rguenther/src/svn/gcc-4_6-branch/gcc/cp/call.c:6978
(gdb) l
5823#define RECUR(T) fixed_type_or_null((T), nonnull, cdtorp)
5824
5825  switch (TREE_CODE (instance))
5826{
5827case INDIRECT_REF:
5828  if (POINTER_TYPE_P (TREE_TYPE (instance)))
5829return NULL_TREE;
5830  else
5831return RECUR (TREE_OPERAND (instance, 0));
5832
(gdb) p instance->base.code
$3 = INDIRECT_REF
(gdb) p instance->common.type
$4 = (tree) 0x0


Reducing.

[Bug c++/48574] [4.6/4.7 Regression] ICE (regression w.r.t. 4.6.0)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |4.6.1
Summary|ICE (regression w.r.t.  |[4.6/4.7 Regression] ICE
   |4.6.0)  |(regression w.r.t. 4.6.0)
  Known to fail||4.6.1, 4.7.0

[Bug c++/48574] ICE (regression w.r.t. 4.6.0)

[vincenzo.innocente at cern dot ch]

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

vincenzo Innocente  changed:

   What|Removed |Added

Summary|[4.6/4.7 Regression] ICE|ICE (regression w.r.t.
   |(regression w.r.t. 4.6.0)   |4.6.0)
  Known to fail|4.6.1, 4.7.0|

--- Comment #2 from vincenzo Innocente  
2011-04-12 14:53:58 UTC ---
while looking for a work-around I discovered that
sed -i 's/const GsfElectron & ele =/GsfElectron ele =/g' produceICE.ii
that affects line
grep -n "const GsfElectron & ele =" produceICE.ii
185392: const GsfElectron & ele = * * i;

"make it compiling"

[Bug c++/48574] ICE (regression w.r.t. 4.6.0)

[vincenzo.innocente at cern dot ch]

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

--- Comment #3 from vincenzo Innocente  
2011-04-12 14:55:26 UTC ---
sorry Richard,
I suspect I've overwritten your changes by mistake

vincenzo

On 12 Apr, 2011, at 4:52 PM, rguenth at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48574
> 
> Richard Guenther  changed:
> 
>   What|Removed |Added
> 
>   Priority|P3  |P1
>   Target Milestone|--- |4.6.1
>Summary|ICE (regression w.r.t.  |[4.6/4.7 Regression] ICE
>   |4.6.0)  |(regression w.r.t. 4.6.0)
>  Known to fail||4.6.1, 4.7.0
> 
> -- 
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.

[Bug target/48576] New: wrong code when accessing variables in a large stack frame

[akos.pasztory at gmail dot com]

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

   Summary: wrong code when accessing variables in a large stack
frame
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: akos.paszt...@gmail.com
Target: arm-linux-gnueabi


Created attachment 23964
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23964
preprocessed source

Tried with 4.5.2 (and 4.6.0), stage1 compiler:

../gcc-4.5.2/configure \
  --target=arm-linux-gnueabi \
  --disable-shared \
  --disable-bootstrap \
  --with-sysroot=/usr/arm-linux-gnueabi \
  --disable-threads \
  --disable-libmudflap \
  --disable-libssp \
  --with-arch=armv7-a --with-tune=cortex-a8 --with-float=hard --with-fpu=neon \
  --enable-languages=c \
  --with-newlib

When compiling the attached source with:

./cc1 -O1 -fgcse -fno-omit-frame-pointer jaj.i

gcc produces this code to do "arr[n] = strdup(str)":
...
blstrdup
subr3, fp, #4096
ldrr3, [r3, #-132]  @ this kills r3
ldrr2, [r3, #-128]  @ and this doesn't know about it
strr0, [r2, r3, asl #2]
...

The problem is first visible in jaj.i.192r.ira when using -fdump-rtl-all. 
Omitting frame pointer "helps" but I think it's pure coincidence.  Apologies
about the messy test code but I was not able to reduce it more without changing
the output.

[Bug c++/48574] [4.6/4.7 Regression] ICE

[vincenzo.innocente at cern dot ch]

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

vincenzo Innocente  changed:

   What|Removed |Added

 Target||4.6.1
Summary|ICE (regression w.r.t.  |[4.6/4.7 Regression] ICE
   |4.6.0)  |
  Known to fail||4.6.1, 4.7.0
   Severity|normal  |critical

[Bug c++/48574] [4.6/4.7 Regression] ICE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2011-04-12 
15:12:22 UTC ---
Likely constexpr related, running delta now to reduce it a little bit.

[Bug target/48576] wrong code when accessing variables in a large stack frame

[siarhei.siamashka at gmail dot com]

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

Siarhei Siamashka  changed:

   What|Removed |Added

 CC||siarhei.siamashka at gmail
   ||dot com

--- Comment #1 from Siarhei Siamashka  
2011-04-12 15:23:02 UTC ---
This reminds me about bug 41074 (apparently the same hard to trigger large
stack frame related issue).

[Bug c/48006] Inefficient optimization depends on builtin integer type of same size.

[carlo at gcc dot gnu.org]

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

Carlo Wood  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |
   Target Milestone|--- |4.6.1

--- Comment #2 from Carlo Wood  2011-04-12 15:48:07 
UTC ---
I couldn't get it to work with restrict, but after changing all size_t into
int, the difference indeed disappears, so I guess you're right and this is
caused by strict aliasing.

[Bug c/48006] Inefficient optimization depends on builtin integer type of same size.

[carlo at gcc dot gnu.org]

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

Carlo Wood  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Carlo Wood  2011-04-12 15:50:31 
UTC ---
My last remark accidently opened it again. Closing again.

[Bug middle-end/48573] [4.7 Regression] Many testcase failures

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from H.J. Lu  2011-04-12 16:10:53 
UTC ---
Fixed by revision 172321:

http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00516.html

[Bug middle-end/48413] [4.7 Regression] 403.gcc in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from H.J. Lu  2011-04-12 16:13:47 
UTC ---
Fixed as of 172238:

http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00958.html

[Bug middle-end/48367] [4.7 Regression] 200.sixtrack/301.apsi in SPEC CPU 2000 are miscompiled

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #7 from H.J. Lu  2011-04-12 16:15:20 
UTC ---
Fixed as of revision 172273:

http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00958.html

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #85 from Jan Hubicka  2011-04-12 
16:22:13 UTC ---
Thanks for analysis. removing inline should work too.
while as qoi issue gcc can find the missing bodu, i think it is better to avoid
more hacks. for 4.7 i will implement the new comdat proposal.
does elfhack work for you now?

[Bug c/46076] [4.6/4.7 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[matt at use dot net]

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

--- Comment #25 from Matt Hargett  2011-04-12 16:24:33 UTC 
---
backport to 4.6 for 4.6.1? I'll apply locally and report any issues in the
meantime.

[Bug testsuite/47400] Several UCN tests FAIL on Tru64 UNIX V5.1B and IRIX 6.5

[ro at gcc dot gnu.org]

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

--- Comment #7 from Rainer Orth  2011-04-12 16:37:08 UTC 
---
Author: ro
Date: Tue Apr 12 16:37:04 2011
New Revision: 172326

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172326
Log:
gcc:
Backport from mainline:
2011-02-11  Rainer Orth  

PR testsuite/47400
* doc/sourcebuild.texi (Require Support): Document
dg-require-ascii-locale.

gcc/testsuite:
Backport from mainline:
2011-02-11  Rainer Orth  

PR testsuite/47400
* lib/target-supports.exp (check_ascii_locale_available): New proc.
* lib/target-supports-dg.exp (dg-require-ascii-locale): New proc.
* gcc.dg/attr-alias-5.c: Use dg-require-ascii-locale.
* gcc.dg/ucnid-10.c: Likewise.
* gcc.dg/ucnid-13.c: Likewise.
* gcc.dg/ucnid-7.c: Likewise.
* gcc.dg/ucnid-8.c: Likewise.
Adapt dg-warning line number.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/doc/sourcebuild.texi
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/attr-alias-5.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/ucnid-10.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/ucnid-13.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/ucnid-7.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/ucnid-8.c
branches/gcc-4_5-branch/gcc/testsuite/lib/target-supports-dg.exp
branches/gcc-4_5-branch/gcc/testsuite/lib/target-supports.exp

[Bug c++/48577] New: "unexpected ast of kind unordered_expr" using isnan()

[jens.maurer at gmx dot net]

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

   Summary: "unexpected ast of kind unordered_expr" using isnan()
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jens.mau...@gmx.net


extern "C" {
  extern int isnan (double __value) throw () __attribute__ ((__const__));
}

int main()
{
double v = 0;
const bool b = isnan(v);
}


compiling with  "g++ -std=gnu++0x bug.cc"
yields:

bug.cc: In function ‘int main()’:
bug.cc:11:27: sorry, unimplemented: unexpected ast of kind unordered_expr
bug.cc:11: confused by earlier errors, bailing out


(Using -std=c++0x avoids the issue.)

[Bug c++/48577] "unexpected ast of kind unordered_expr" using isnan()

[jens.maurer at gmx dot net]

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

--- Comment #1 from Jens Maurer  2011-04-12 
16:39:03 UTC ---
It works with gcc 4.5.2, so it seems to be a 4.6 regression.

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[markus at trippelsdorf dot de]

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

--- Comment #86 from Markus Trippelsdorf  
2011-04-12 16:42:34 UTC ---
(In reply to comment #85)
> does elfhack work for you now?

Yes, no problems anymore.

[Bug c++/48577] [C++0x] [4.6 Regression] "unexpected ast of kind unordered_expr" using isnan()

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.12 16:44:29
 CC||jason at gcc dot gnu.org
Summary|"unexpected ast of kind |[C++0x] [4.6 Regression]
   |unordered_expr" using   |"unexpected ast of kind
   |isnan() |unordered_expr" using
   ||isnan()
 Ever Confirmed|0   |1

--- Comment #2 from Paolo Carlini  2011-04-12 
16:44:29 UTC ---
Eh, this is just crazy (normally should never happen that with -std=gnu++0x we
accept less than with -std=c++0x).

I can reproduce only on the 4_6-branch, not mainline.

[Bug c++/48574] [4.6/4.7 Regression] ICE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  2011-04-12 
16:53:27 UTC ---
Reduction is running slowly.
Anyway, this started with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171461
i.e. PR48289 fix.

[Bug c++/48577] [C++0x] [4.6 Regression] "unexpected ast of kind unordered_expr" using isnan()

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-04-12 
16:56:08 UTC ---
isn't this PR 48369 ?

[Bug c++/48577] [C++0x] [4.6 Regression] "unexpected ast of kind unordered_expr" using isnan()

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2011-04-12 
16:59:41 UTC ---
Yes it looks identical - is it still present on the 4.6 branch?
Did Jason only fix the ICE, not the "sorry" ?

[Bug c++/48577] [C++0x] [4.6 Regression] "unexpected ast of kind unordered_expr" using isnan()

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||paolo.carlini at oracle dot
   ||com
 Resolution||DUPLICATE

--- Comment #5 from Paolo Carlini  2011-04-12 
17:08:31 UTC ---
The problem is my 4_6 dates back to the day before the day fixed the issue ;)
Thus, closing as duplicate, thanks Jon.

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

[Bug c++/48369] [4.6 Regression] [C++0x] ICE in potential_constant_expression_1, at cp/semantics.c:7746

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jens.maurer at gmx dot net

--- Comment #4 from Paolo Carlini  2011-04-12 
17:08:32 UTC ---
*** Bug 48577 has been marked as a duplicate of this bug. ***

[Bug c++/48578] New: Range-based for-loops do not compile when -nostdinc is given

[jobnoorman at gmail dot com]

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

   Summary: Range-based for-loops do not compile when -nostdinc is
given
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jobnoor...@gmail.com


Created attachment 23965
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23965
Simple file which produces the error

When using range-based for-loops when -nostdinc is given, GCC gives an error
about 'begin' and 'end' not being declared while they definitely are.

I've attached a simple file which produces this error.

Here's the output of "g++ -v -save-temps -std=c++0x -nostdinc main.cpp":

Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ./configure --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-nostdinc'
'-shared-libgcc' '-mtune=generic' '-march=pentiumpro'
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/cc1plus -E -quiet -nostdinc -v
-D_GNU_SOURCE main.cpp -mtune=generic -march=pentiumpro -std=c++0x
-fpch-preprocess -o main.ii
#include "..." search starts here:
#include <...> search starts here:
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-nostdinc'
'-shared-libgcc' '-mtune=generic' '-march=pentiumpro'
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/cc1plus -fpreprocessed main.ii
-quiet -dumpbase main.cpp -mtune=generic -march=pentiumpro -auxbase main
-std=c++0x -version -o main.s
GNU C++ (GCC) version 4.6.0 (i686-pc-linux-gnu)
compiled by GNU C version 4.6.0, GMP version 4.3.2, MPFR version
3.0.0-p8, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.6.0 (i686-pc-linux-gnu)
compiled by GNU C version 4.6.0, GMP version 4.3.2, MPFR version
3.0.0-p8, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 07532dd28c9f528a39c397b207537ed2
main.cpp: In function ‘int main()’:
main.cpp:11:18: error: ‘begin’ was not declared in this scope
main.cpp:11:18: error: ‘end’ was not declared in this scope

[Bug c++/48577] [C++0x] [4.6 Regression] "unexpected ast of kind unordered_expr" using isnan()

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2011-04-12 
17:34:00 UTC ---
(In reply to comment #5)
> The problem is my 4_6 dates back to the day before the day fixed the issue ;)

aha :)

[Bug c++/48569] internal compiler error: in build_zero_init_1, at cp/init.c:278

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.12 17:37:12
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2011-04-12 
17:37:12 UTC ---
Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172141
i.e. PR48449 fix.

[Bug c++/48569] internal compiler error: in build_zero_init_1, at cp/init.c:278

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2011-04-12 
17:38:15 UTC ---
Created attachment 23966
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23966
pr48569.ii

Slightly reduced testcase.

[Bug c++/48578] Range-based for-loops do not compile when -nostdinc is given

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Jonathan Wakely  2011-04-12 
17:39:15 UTC ---
According to the current C++0x draft that loop should call begin(l) and end(l)
but there are no declarations of those functions in your testcase, with or
without -nostdinc

According to the C++0x FDIS your example would work, but that's not implemented
in G++ 4.6.0

[Bug c/46076] [4.6/4.7 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek  2011-04-12 
17:39:29 UTC ---
No, such big changes shouldn't be backported to release branches.

[Bug tree-optimization/43270] array-bounds false negative

[matt at use dot net]

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

Matt Hargett  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #21 from Matt Hargett  2011-04-12 18:13:30 UTC 
---
verified fixed in 4.6.0.

[Bug c/46076] [4.6/4.7 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

[matt at use dot net]

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

--- Comment #27 from Matt Hargett  2011-04-12 18:15:33 UTC 
---
That's unfortunate. Can you adjust the target milestone, then?

[Bug c++/46890] [4.6 Regression] Failed to compile scummvm's player_v4a.cpp

[matt at use dot net]

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

Matt Hargett  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #12 from Matt Hargett  2011-04-12 18:15:56 UTC 
---
Verified fixed in 4.6.0.

[Bug middle-end/48579] New: ICE: verify_flow_info: too many outgoing branch edges from bb 3 with asm goto

[zsojka at seznam dot cz]

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

   Summary: ICE: verify_flow_info: too many outgoing branch edges
from bb 3 with asm goto
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc testcase.c
testcase.c: In function 'foo':
testcase.c:5:3: warning: asm operand 0 probably doesn't match constraints
[enabled by default]
testcase.c:5:3: error: impossible constraint in 'asm'
testcase.c:6:1: error: too many outgoing branch edges from bb 3
testcase.c:6:1: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r172314 - crash
4.6 r171597 - crash
4.5 r171597 - crash
4.4 r171597 - doesn't know asm goto

[Bug middle-end/42371] dead code not eliminated during folding with whole-program

[matt at use dot net]

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

Matt Hargett  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #10 from Matt Hargett  2011-04-12 18:29:28 UTC 
---
I just tested and it looks like this is actually fixed in 4.6 for this specific
example and another one I had.

I'm still seeing remnants with C++, but I'll file a separate bug for that.

[Bug c++/48578] Range-based for-loops do not compile when -nostdinc is given

[jobnoorman at gmail dot com]

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

--- Comment #2 from Job Noorman  2011-04-12 
18:29:41 UTC ---
Ok I see. Thanks for the clarification!

[Bug tree-optimization/48195] ICE: vector VEC(ipa_node_params_t,base) index domain error, in ipa_analyze_node at ipa-prop.c:1525 with -flto --param partial-inlining-entry-probability=101

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  2011-04-12 
18:31:58 UTC ---
Author: jamborm
Date: Tue Apr 12 18:31:55 2011
New Revision: 172332

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172332
Log:
2011-04-12  Martin Jambor  

PR tree-optimization/48195
* ipa-cp.c (ipcp_driver): Call ipa_check_create_node_params and
ipa_check_create_edge_args.
(ipcp_generate_summary): Do not call ipa_check_create_node_params and
ipa_check_create_edge_args.
* ipa-inline.c (inline_generate_summary): Do not call
ipa_check_create_node_params and ipa_check_create_edge_args.
* ipa-prop.c (ipa_analyze_node): Call ipa_check_create_node_params and
ipa_check_create_edge_args.

* testsuite/gcc.dg/ipa/pr48195.c: New test.


Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/ipa/pr48195.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/ipa-cp.c
branches/gcc-4_6-branch/gcc/ipa-inline.c
branches/gcc-4_6-branch/gcc/ipa-prop.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/48580] New: missed optimization: integer overflow checks

[zackw at panix dot com]

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

   Summary: missed optimization: integer overflow checks
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: za...@panix.com


To the best of my knowledge, this is the only safe way (without -fwrapv) to
check whether the product of two signed integers overflowed:

bool product_does_not_overflow(signed x, signed y)
{
  unsigned tmp = x * unsigned(y);

  return signed(tmp) > 0 && tmp / x == unsigned(y);
}

(I believe C and C++ are the same in this regard but I could be wrong.  If
there is a better way to write this test I would love to know about it.)

g++ 4.6 produces this assembly dump on x86-64:

_Z25product_does_not_overflowii:
movl%esi, %edx
xorl%eax, %eax
imull%edi, %edx
testl%edx, %edx
jle.L2
movl%edx, %eax
xorl%edx, %edx
divl%edi
cmpl%eax, %esi
sete%al
.L2:
rep
ret

but, if I understand the semantics of IMUL correctly, it could do this instead:

_Z25product_does_not_overflowii:
xorl%eax, %eax
imull%edi, %esi
setno%al
ret

which is a pretty substantial micro-win, particularly in getting rid of a
divide.

[Bug tree-optimization/48195] ICE: vector VEC(ipa_node_params_t,base) index domain error, in ipa_analyze_node at ipa-prop.c:1525 with -flto --param partial-inlining-entry-probability=101

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Martin Jambor  2011-04-12 
18:37:26 UTC ---
Fixed on both trunk and the 4.6 branch.

[Bug libstdc++/48559] parallel-mode vs C++0x

[singler at gcc dot gnu.org]

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

sing...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.12 19:02:06
 CC||singler at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from singler at gcc dot gnu.org  
2011-04-12 19:02:06 UTC ---
We should try to tweak the algorithms to use just moves.  Since memory
bandwidth often limits parallel performance, it could even be particularly
efficient.

On the other hand, we sometimes need references to elements of the
random-access input sequence(s).  We could always use an iterator, but that
might be inefficient.  And we cannot take the lvalue reference or the address
of a dereferenced random access iterator, can we?  (Although this is
unfortunately done so far in multiseq_selection.h.)  Can we always take the
rvalue reference of a dereferenced random access iterator?

random_shuffle and partition will be the easiest cases, so we should start
there.

[Bug target/46898] libgcc build failure on lm32-elf

[tnorth at fedoraproject dot org]

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

Thibault North  changed:

   What|Removed |Added

 CC||tnorth at fedoraproject dot
   ||org

--- Comment #15 from Thibault North  
2011-04-12 19:07:04 UTC ---
Same problem with the AVR arch, using the same testcase:
avr-gcc-4.5.2: OK
avr-gcc-4.6.0: avr-gcc -gdwarf-2 foo.c 
foo.c:1:0: internal compiler error: in dwarf2out_frame_init, at
dwarf2out.c:4260
Please submit a full bug report,
with preprocessed source if appropriate.

$ avr-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/avr-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/avr/4.6.0/lto-wrapper
Target: avr
Configured with: ../gcc-4.6.0/configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --target=avr --enable-languages=c,c++ --disable-nls
--disable-libssp --with-system-zlib --enable-version-specific-runtime-libs
--with-pkgversion='Fedora 4.6.0-1.fc14'
--with-bugurl=https://bugzilla.redhat.com/
Thread model: single
gcc version 4.6.0 (Fedora 4.6.0-1.fc14)

[Bug fortran/48456] [4.6/4.7 Regression] Realloc on assignment: ICE in fold_binary_loc

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  2011-04-12 19:14:53 
UTC ---
Author: pault
Date: Tue Apr 12 19:14:49 2011
New Revision: 172339

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172339
Log:
2011-04-12  Paul Thomas  

PR fortran/48360
PR fortran/48456
* trans-array.c (get_std_lbound): For derived type variables
return array valued component lbound.

2011-04-12  Paul Thomas  

PR fortran/48360
PR fortran/48456
* gfortran.dg/realloc_on_assign_6.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_6.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/48360] [4.6/4.7 Regression] ICE on array assignment statement with allocatable LHS

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  2011-04-12 19:14:52 
UTC ---
Author: pault
Date: Tue Apr 12 19:14:49 2011
New Revision: 172339

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172339
Log:
2011-04-12  Paul Thomas  

PR fortran/48360
PR fortran/48456
* trans-array.c (get_std_lbound): For derived type variables
return array valued component lbound.

2011-04-12  Paul Thomas  

PR fortran/48360
PR fortran/48456
* gfortran.dg/realloc_on_assign_6.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_6.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/48559] parallel-mode vs C++0x

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-04-12 
19:20:29 UTC ---
(In reply to comment #2)
> On the other hand, we sometimes need references to elements of the
> random-access input sequence(s).  We could always use an iterator, but that
> might be inefficient.  And we cannot take the lvalue reference or the address
> of a dereferenced random access iterator, can we?

Yes you can for most iterators (not for move_iterator, but that's unusual)

>  (Although this is
> unfortunately done so far in multiseq_selection.h.)  Can we always take the
> rvalue reference of a dereferenced random access iterator?

No (you can for move_iterator).

For most iterators (especially random access iterators including pointers)
iterator_traits::reference will be an lvalue reference.

[Bug c++/48581] New: [C++0x][SFINAE] Lack of ADL in default template argument types

[daniel.kruegler at googlemail dot com]

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

   Summary: [C++0x][SFINAE] Lack of ADL in default template
argument types
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com


gcc 4.7 in C++0x mode rejects the following program, but accepts it, when the
define USE_AS_RET_TYPE is activated by uncommenting:

--
template
T&& create();

//#define USE_AS_RET_TYPE

#ifndef USE_AS_RET_TYPE
template()))
>
auto f(int) -> char;
#else
template
auto f(int) -> decltype(foo(create()), char());
#endif

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

struct S {};

void foo(S);

static_assert(sizeof(f(0)) == 1, "Error"); // (#)

int main() {}
--

(#) "error: 'foo' was not declared in this scope"

Instantiation of the f(int) overload should properly honor ADL because of the
type-dependent expression as it does in the alternative form as part of the
return type.