[Bug middle-end/42130] [graphite-branch] dealII fails

[spop at gcc dot gnu dot org]

--- Comment #7 from spop at gcc dot gnu dot org  2009-12-15 08:21 ---
I will add -fgraphite-identity to the testcase as otherwise we're not going to
test graphite on trunk...

diff --git a/gcc/testsuite/g++.dg/graphite/pr42130.C
b/gcc/testsuite/g++.dg/graphite/pr42130.C
index ca00227..5652139 100644
--- a/gcc/testsuite/g++.dg/graphite/pr42130.C
+++ b/gcc/testsuite/g++.dg/graphite/pr42130.C
@@ -1,4 +1,4 @@
-/* { dg-options "-O2 -fno-tree-ch" } */
+/* { dg-options "-O2 -fgraphite-identity -fno-tree-ch" } */
 #include 

 using std::vector;


-- 


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

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

--- Comment #7 from irar at il dot ibm dot com  2009-12-15 08:25 ---
I can't reproduce it with current mainline on powerpc64-suse-linux. Could you
please attach vectorizer dump? Does the good old version gets vectorized? If
so, could you please attach it as well?

Thanks,
Ira


-- 


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

[Bug middle-end/42130] [graphite-branch] dealII fails

[spop at gcc dot gnu dot org]

--- Comment #8 from spop at gcc dot gnu dot org  2009-12-15 08:27 ---
Also, I don't know why the test fails at runtime like this:

FAIL: g++.dg/graphite/pr42130.C execution test


-- 


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

[Bug fortran/41235] Missing explicit interface for variable-length character functions

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-12-15 08:37 ---
Subject: Bug 41235

Author: burnus
Date: Tue Dec 15 08:37:41 2009
New Revision: 155247

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155247
Log:
2009-12-15  Tobias Burnus  
Daniel Franke  

PR fortran/41235
* resolve.c (resolve_global_procedure): Add check for
presence of an explicit interface for nonconstant,
nonassumed character-length functions.
(resolve_fl_procedure): Remove check for nonconstant
character-length functions.

2009-12-15  Tobias Burnus  

PR fortran/41235
* auto_char_len_1.f90: New test.
* auto_char_len_2.f90: New test.
* auto_char_len_4.f90: Correct test.


Added:
trunk/gcc/testsuite/gfortran.dg/auto_char_len_1.f90
trunk/gcc/testsuite/gfortran.dg/auto_char_len_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/auto_char_len_4.f90


-- 


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

[Bug tree-optimization/42334] segfault in graphite-poly.h for 200.sixtrack

[spop at gcc dot gnu dot org]

--- Comment #2 from spop at gcc dot gnu dot org  2009-12-15 08:39 ---
Subject: Bug 42334

Author: spop
Date: Tue Dec 15 08:39:25 2009
New Revision: 155248

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155248
Log:
Fix PR42334: correct the update of the LST on loop interchange and
distribution.

2009-12-15  Sebastian Pop  

PR middle-end/42178
PR middle-end/42334
* graphite-interchange.c (lst_perfect_nestify): Reset to NULL the LSTs
that are empty.
(lst_do_interchange_1): Renamed lst_interchange_select_inner.
(lst_try_interchange): Reimplemented.
(lst_interchange_select_inner): Same.
(lst_do_interchange): Renamed lst_interchange_select_outer.
Reimplemented.
(scop_do_interchange): Update use of lst_interchange_select_outer.

* testsuite/g++.dg/graphite/pr42130.C: Add -fgraphite-identity.
* testsuite/gcc.dg/graphite/block-0.c: Un-XFAILed.
* testsuite/gcc.dg/graphite/pr42211.c: New.
* testsuite/gfortran.dg/graphite/pr42334.f90: New.

Added:
branches/graphite/gcc/testsuite/gcc.dg/graphite/pr42211.c
branches/graphite/gcc/testsuite/gfortran.dg/graphite/pr42334.f90
Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/graphite-interchange.c
branches/graphite/gcc/testsuite/g++.dg/graphite/pr42130.C
branches/graphite/gcc/testsuite/gcc.dg/graphite/block-0.c


-- 


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

[Bug middle-end/42178] [4.5 Regression] gcc.dg/graphite/interchange-8.c causes ICE

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2009-12-15 08:39 ---
Subject: Bug 42178

Author: spop
Date: Tue Dec 15 08:39:25 2009
New Revision: 155248

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155248
Log:
Fix PR42334: correct the update of the LST on loop interchange and
distribution.

2009-12-15  Sebastian Pop  

PR middle-end/42178
PR middle-end/42334
* graphite-interchange.c (lst_perfect_nestify): Reset to NULL the LSTs
that are empty.
(lst_do_interchange_1): Renamed lst_interchange_select_inner.
(lst_try_interchange): Reimplemented.
(lst_interchange_select_inner): Same.
(lst_do_interchange): Renamed lst_interchange_select_outer.
Reimplemented.
(scop_do_interchange): Update use of lst_interchange_select_outer.

* testsuite/g++.dg/graphite/pr42130.C: Add -fgraphite-identity.
* testsuite/gcc.dg/graphite/block-0.c: Un-XFAILed.
* testsuite/gcc.dg/graphite/pr42211.c: New.
* testsuite/gfortran.dg/graphite/pr42334.f90: New.

Added:
branches/graphite/gcc/testsuite/gcc.dg/graphite/pr42211.c
branches/graphite/gcc/testsuite/gfortran.dg/graphite/pr42334.f90
Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/graphite-interchange.c
branches/graphite/gcc/testsuite/g++.dg/graphite/pr42130.C
branches/graphite/gcc/testsuite/gcc.dg/graphite/block-0.c


-- 


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

[Bug tree-optimization/42376] New: [4.5] Performance regression of generated code

[martin at mpa-garching dot mpg dot de]

I have noticed a big performance decrease in one of my numerical codes
when switching from gcc 4.4 to gcc 4.5. A small test case is attached.
When compiling this test case with "gcc -O3 perf.c -lm -std=c99"
and executing the resulting binary, the CPU time with the head of
the 4.4 branch is about 1.1s, with the head of the trunk it is 2.1s.

This is on a Pentium D CPU. I have verified that both binaries produce
identical results.

Verbose output of gcc-4.4:

~/tmp/wigner3j>gcc -O3 perf.c -lm -std=c99 -save_temps -v
Using built-in specs.
gcc: unrecognized option '-save_temps'
Target: i686-pc-linux-gnu
Configured with: /scratch/martin/gcc44/configure
--prefix=/scratch/martin/ugcc44
 --enable-languages=c++,fortran --enable-target=all --disable-bootstrap
--enable
-checking=release
Thread model: posix
gcc version 4.4.3 20091130 (prerelease) [gcc-4_4-branch revision 154765] (GCC) 
COLLECT_GCC_OPTIONS='-O3' '-std=c99' '-save_temps' '-v' '-mtune=generic'
 /scratch/martin/ugcc44/libexec/gcc/i686-pc-linux-gnu/4.4.3/cc1 -quiet -v
perf.c
 -quiet -dumpbase perf.c -mtune=generic -auxbase perf -O3 -std=c99 -version -o
/
tmp/cc3D10Yi.s
ignoring nonexistent directory
"/scratch/martin/ugcc44/lib/gcc/i686-pc-linux-gnu
/4.4.3/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /scratch/martin/ugcc44/include
 /scratch/martin/ugcc44/lib/gcc/i686-pc-linux-gnu/4.4.3/include
 /scratch/martin/ugcc44/lib/gcc/i686-pc-linux-gnu/4.4.3/include-fixed
 /usr/include
End of search list.
GNU C (GCC) version 4.4.3 20091130 (prerelease) [gcc-4_4-branch revision
154765]
 (i686-pc-linux-gnu)
compiled by GNU C version 4.2.3, GMP version 4.2.4, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 0428a618e74de3f947d92ab031f86f8a
COLLECT_GCC_OPTIONS='-O3' '-std=c99' '-save_temps' '-v' '-mtune=generic'
 as -V -Qy -o /tmp/cc6AnZqy.o /tmp/cc3D10Yi.s
GNU assembler version 2.18 (i686-pc-linux-gnu) using BFD version (GNU Binutils) 
2.18
COMPILER_PATH=/scratch/martin/ugcc44/libexec/gcc/i686-pc-linux-gnu/4.4.3/:/scrat
ch/martin/ugcc44/libexec/gcc/i686-pc-linux-gnu/4.4.3/:/scratch/martin/ugcc44/lib
exec/gcc/i686-pc-linux-gnu/:/scratch/martin/ugcc44/lib/gcc/i686-pc-linux-gnu/4.4
.3/:/scratch/martin/ugcc44/lib/gcc/i686-pc-linux-gnu/:/usr/libexec/gcc/i686-pc-l
inux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/
LIBRARY_PATH=/scratch/martin/ugcc44/lib/gcc/i686-pc-linux-gnu/4.4.3/:/scratch/ma
rtin/ugcc44/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-O3' '-std=c99' '-save_temps' '-v' '-mtune=generic'
 /scratch/martin/ugcc44/libexec/gcc/i686-pc-linux-gnu/4.4.3/collect2
--eh-frame-
hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o
/usr/lib/crti
.o /scratch/martin/ugcc44/lib/gcc/i686-pc-linux-gnu/4.4.3/crtbegin.o
-L/scratch/
martin/ugcc44/lib/gcc/i686-pc-linux-gnu/4.4.3
-L/scratch/martin/ugcc44/lib/gcc/i
686-pc-linux-gnu/4.4.3/../../.. /tmp/cc6AnZqy.o -lm -lgcc --as-needed -lgcc_s
--
no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/scratch/martin/ugcc44
/lib/gcc/i686-pc-linux-gnu/4.4.3/crtend.o /usr/lib/crtn.o

Verbose output of gcc-4.5:
~/tmp/wigner3j>gcc -O3 perf.c -lm -std=c99 -save-temps -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /scratch/martin/gcc/configure --enable-gold
--prefix=/afs/mpa/data/martin/ugcc --with-mpfr=/afs/mpa/data/martin/numlibs
--with-gmp=/afs/mpa/data/martin/numlibs --with-mpc=/afs/mpa/data/martin/numlibs
--enable-languages=c++,fortran --enable-target=all --enable-checking=release
Thread model: posix
gcc version 4.5.0 20091214 (experimental) [trunk revision 155208] (GCC) 
COLLECT_GCC_OPTIONS='-O3' '-std=c99' '-save-temps' '-v' '-mtune=generic'
 /afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.5.0/cc1 -E -quiet -v
perf.c -mtune=generic -std=c99 -O3 -fpch-preprocess -o perf.i
ignoring nonexistent directory
"/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /afs/mpa/data/martin/ugcc/include
 /afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.5.0/include
 /afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.5.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-O3' '-std=c99' '-save-temps' '-v' '-mtune=generic'
 /afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.5.0/cc1
-fpreprocessed perf.i -quiet -dumpbase perf.c -mtune=generic -auxbase perf -O3
-std=c99 -version -o perf.s
GNU C (GCC) version 4.5.0 20091214 (experimental) [trunk revision 155208]
(i686-pc-linux-gnu)
compiled by GNU C version 4.5.0 20091214 (experimental) [trunk revision
155208], GMP version 4.3.1, MPFR version 2.4.2, MPC version 0.8
GGC heuristics: --param ggc

[Bug tree-optimization/42334] segfault in graphite-poly.h for 200.sixtrack

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2009-12-15 08:41 ---
Fixed in the graphite branch.  I will commit this to trunk after further test.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/42178] [4.5 Regression] gcc.dg/graphite/interchange-8.c causes ICE

[spop at gcc dot gnu dot org]

--- Comment #4 from spop at gcc dot gnu dot org  2009-12-15 08:41 ---
Fixed in the graphite branch.  I will commit this to trunk after further test.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/42376] [4.5] Performance regression of generated code

[martin at mpa-garching dot mpg dot de]

--- Comment #1 from martin at mpa-garching dot mpg dot de  2009-12-15 08:41 
---
Created an attachment (id=19305)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19305&action=view)
test case


-- 


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

[Bug tree-optimization/42376] [4.5] Performance regression of generated code

[martin at mpa-garching dot mpg dot de]

--- Comment #2 from martin at mpa-garching dot mpg dot de  2009-12-15 08:42 
---
Created an attachment (id=19306)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19306&action=view)
assembler generated by gcc 4.5


-- 


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

[Bug tree-optimization/42376] [4.5] Performance regression of generated code

[martin at mpa-garching dot mpg dot de]

--- Comment #3 from martin at mpa-garching dot mpg dot de  2009-12-15 08:43 
---
Created an attachment (id=19307)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19307&action=view)
assembler generated by gcc 4.4


-- 


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

[Bug fortran/30668] -fwhole-file should catch function of wrong type

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2009-12-15 08:44 ---
It also should check (kind/length) type-parameters, cf.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d710371aed91e75f
This is kind of a follow up to PR 41235; cf. also PR 41603.


-- 


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

[Bug fortran/41235] Missing explicit interface for variable-length character functions

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2009-12-15 08:45 ---
FIXED


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/42374] 23_containers/map/operators/1_neg.cc fails test for errors on darwin10

[chris at bubblescope dot net]

--- Comment #1 from chris at bubblescope dot net  2009-12-15 08:54 ---
I see you are building with fink. Looking on the fink website, they do not seem
to have a gcc45 package. Where did you get it from? Or has it just not made it
to the website yet?


-- 

chris at bubblescope dot net changed:

   What|Removed |Added

 CC||chris at bubblescope dot net


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

[Bug target/42374] 23_containers/map/operators/1_neg.cc fails test for errors on darwin10

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-12-15 09:12 
---
And these can only be either target or, maybe, c++ front-end, certainly not
libstdc++ proper


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

  Component|libstdc++   |target


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

[Bug c++/42336] [c++0x] ICE with pointer-to-member-function decltype argument in template function

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-12-15 09:22 
---
Ok, thanks, I'll track that one instead...


-- 


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

[Bug c++/42364] C++ testsuite fails with -g

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-12-15 09:35 ---
make -j4 -k check-g++ RUNTESTFLAGS=--target_board=unix/-g


-- 


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

[Bug middle-end/42372] Error: undefined symbol `.LPIC7' in operation

[ramana at gcc dot gnu dot org]

--- Comment #3 from ramana at gcc dot gnu dot org  2009-12-15 09:50 ---
Created an attachment (id=19308)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19308&action=view)
Reduced testcase.

Reduced testcase attached - Compiling with -c -Os -frename-registers exposes
the problem.


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #19300|0   |1
is obsolete||


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

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

--- Comment #8 from dominiq at lps dot ens dot fr  2009-12-15 09:58 ---
> I can't reproduce it with current mainline on powerpc64-suse-linux. 

I know;)

> Does the good old version gets vectorized?

I don't have any working 4.5 version, but 4.4.2 is working. The differences are

(4.4.2)

where_2.f90:5: note: LOOP VECTORIZED.
where_2.f90:2: note: vectorized 1 loops in function.

(4.5.0)

where_2.f90:11: note: LOOP VECTORIZED.
where_2.f90:11: note: not vectorized: relevant stmt not supported: cond.23_79 =
D.1255_78 > 6;

where_2.f90:11: note: not vectorized: relevant stmt not supported: cond.15_57 =
D.1238_56 == 0;

where_2.f90:11: note: not vectorized: relevant stmt not supported: cond.9_43 =
D.1227_42 < 0;

where_2.f90:5: note: LOOP VECTORIZED.
where_2.f90:2: note: vectorized 2 loops in function.


> Could you please attach vectorizer dump?  If so, could you please attach it 
> as well?

I'll attach the files dumped with -fdump-tree-vect for 4.4 and 4.5.

Note that I make a mistake when looking to my log files: the last working
revision is 149758 and the first failing one is 150041.


-- 


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

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

--- Comment #9 from dominiq at lps dot ens dot fr  2009-12-15 09:59 ---
Created an attachment (id=19309)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19309&action=view)
dump file for gfortran 4.4.2


-- 


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

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

--- Comment #10 from dominiq at lps dot ens dot fr  2009-12-15 10:00 ---
Created an attachment (id=19310)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19310&action=view)
dump file for gfortran 4.5.0 revision 155196


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

--- Comment #99 from dominiq at lps dot ens dot fr  2009-12-15 10:14 ---
> i686-apple-darwin9 bootstraps without dsymutil fails at 155225, thanks Jakub.

powerpc-apple-darwin9 too at 155239. For x86_64-apple-darwin10, I think the
problem is fixed too, but between revisions 154996 and 155016 (likely 155012)
libtool stopped to call dsymutil (any idea about that? should I open a new pr
for it?).

If there is no objection, I'll close the PR as fixed in a few days.

Thanks all for debugging and fixing the problem.


-- 


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

[Bug c++/41183] [4.4 Regression] ICE compiling chromium

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-08-28 17:48:16 |2009-12-15 10:25:17
   date||


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

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

--- Comment #11 from irar at il dot ibm dot com  2009-12-15 10:59 ---
Looks that it has to be my patch that enables vectorization of conditions:

r149806 | irar | 2009-07-20 14:59:10 +0300 (Mon, 20 Jul 2009) | 19 lines


* tree-vectorizer.h (vectorizable_condition): Add parameters.
* tree-vect-loop.c (vect_is_simple_reduction): Support COND_EXPR.
(get_initial_def_for_reduction): Likewise.
(vectorizable_reduction): Skip the check of first operand in case
of COND_EXPR. Add check that it is outer loop vectorization if
nested cycle was detected. Call vectorizable_condition() for
COND_EXPR. If reduction epilogue cannot be created do not fail for
nested cycles (if it is not double reduction). Assert that there
is only one type in the loop in case of COND_EXPR. Call
vectorizable_condition() to vectorize COND_EXPR.
* tree-vect-stmts.c (vectorizable_condition): Update comment.
Add parameters. Allow nested cycles if called from
vectorizable_reduction(). Use reduction vector variable if provided.
(vect_analyze_stmt): Call vectorizable_reduction() before
vectorizable_condition().
(vect_transform_stmt): Update call to vectorizable_condition().

I'll try to find out what's wrong with it.

Thanks,
Ira


-- 


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

[Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression

[rguenth at gcc dot gnu dot org]

--- Comment #37 from rguenth at gcc dot gnu dot org  2009-12-15 11:08 
---
No, there isn't.  I'd simply allow TREE_THIS_NOTRAP on all expression codes
that in principle could.  Now of course the middle-end would still need to
make use of this (like transition it to a stmt flag on a tuple).


-- 


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

[Bug libstdc++/42377] New: libstdc++.dll.a misses a definition of std::string::reserve

[rainer at emrich-ebersheim dot de]

Even though libstdc++-6.dll has: 6fc94700 T
std::string::reserve(unsigned long long),
libstdc++.dll.a misses a definition of std::string::reserve!

Which makes it impossible to build libgmpxx against a shared version of
libstdc++-6, see:

/bin/sh ./libtool --mode=link g++  -O2 -pedantic -m64 -mtune=k8   -o
libgmpxx.la -rpath /home/rainer/tmp/install/lib -no-undefined
-Wl,--export-all-symbols -Wl,--output-def,.libs/libgmp-3.dll.def
-Wl,--output-def,.libs/libgmpxx-3.dll.def -version-info 5:0:1 dummy.lo
cxx/isfuns.lo cxx/ismpf.lo cxx/ismpq.lo cxx/ismpz.lo cxx/ismpznw.lo
cxx/osdoprnti.lo cxx/osfuns.lo cxx/osmpf.lo cxx/osmpq.lo cxx/osmpz.lo libgmp.la 
rm -fr  .libs/libgmpxx.dll.a
g++ -shared -nostdlib
c:/mingw/x86_64-w64/x86_64-w64/x86_64-w64/gcc-4.5.0-test/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/dllcrt2.o
c:/mingw/x86_64-w64/x86_64-w64/x86_64-w64/gcc-4.5.0-test/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/crtbegin.o
 .libs/dummy.o cxx/.libs/isfuns.o cxx/.libs/ismpf.o cxx/.libs/ismpq.o
cxx/.libs/ismpz.o cxx/.libs/ismpznw.o cxx/.libs/osdoprnti.o cxx/.libs/osfuns.o
cxx/.libs/osmpf.o cxx/.libs/osmpq.o cxx/.libs/osmpz.o  ./.libs/libgmp.dll.a
-Lc:/mingw/x86_64-w64/x86_64-w64/x86_64-w64/gcc-4.5.0-test/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0
-Lc:/mingw/x86_64-w64/x86_64-w64/x86_64-w64/gcc-4.5.0-test/mingw/bin/../lib/gcc
-Lc:/mingw/x86_64-w64/x86_64-w64/x86_64-w64/gcc-4.5.0-test/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../lib64
-Lc:/mingw/x86_64-w64/x86_64-w64/x86_64-w64/gcc-4.5.0-test/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib
-Lc:/mingw/x86_64-w64/x86_64-w64/x86_64-w64/gcc-4.5.0-test/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../..
-Lc:/mingw/x86_64-w64/x86_64-w64/x86_64-w64/gcc-4.5.0-test/mingw/bin/../../mingw/mingw/lib
/mingw/x86_64-w64/x86_64-w64/x86_64-w64/gcc-4.5.0-test/mingw/lib/../lib64/libstdc++.dll.a
-L/home/rainer/software/build/x86_64-w64/x86_64-w64/x86_64-w64/gcc-4.5.0-test/gcc-4.5.0-bootstrap/x86_64-w64-mingw32/libstdc++-v3/src
-L/home/rainer/software/build/x86_64-w64/x86_64-w64/x86_64-w64/gcc-4.5.0-test/gcc-4.5.0-bootstrap/x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/mingw/x86_64-w64/x86_64-w64/x86_64-w64/gcc-4.5.0-test/mingw/x86_64-w64-mingw32/lib
-L/mingw/x86_64-w64/x86_64-w64/x86_64-w64/gcc-4.5.0-test/mingw/mingw/lib
-lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32
-ladvapi32 -lshell32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt
c:/mingw/x86_64-w64/x86_64-w64/x86_64-w64/gcc-4.5.0-test/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/crtend.o
 -m64 -mtune=k8 -Wl,--export-all-symbols -Wl,--output-def
-Wl,.libs/libgmp-3.dll.def -Wl,--output-def -Wl,.libs/libgmpxx-3.dll.def -o
.libs/libgmpxx-4.dll -Wl,--enable-auto-image-base -Xlinker --out-implib
-Xlinker .libs/libgmpxx.dll.a
Info: resolving std::basic_string,
std::allocator >::_Rep::_S_empty_rep_storage by linking to
__imp___ZNSs4_Rep20_S_empty_rep_storageE (auto-import)
Creating library file:
.libs/libgmpxx.dll.ac:/mingw/x86_64-w64/x86_64-w64/x86_64-w64/gcc-4.5.0-test/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
warning: auto-importing has been activated without --enable-auto-import
specified on the command line.
This should work unless it involves constant data structures referencing
symbols from auto-imported DLLs.
cxx/.libs/isfuns.o:isfuns.cc:(.text+0x180): undefined reference to
`std::string::reserve(unsigned long long)'
cxx/.libs/isfuns.o:isfuns.cc:(.text+0x228): undefined reference to
`std::string::reserve(unsigned long long)'
cxx/.libs/isfuns.o:isfuns.cc:(.text+0x2a8): undefined reference to
`std::string::reserve(unsigned long long)'
cxx/.libs/ismpf.o:ismpf.cc:(.text+0x2f8): undefined reference to
`std::string::reserve(unsigned long long)'
cxx/.libs/ismpf.o:ismpf.cc:(.text+0x3a7): undefined reference to
`std::string::reserve(unsigned long long
)'
/bin/sh ./libtool --mode=link g++  -O2 -pedantic -m64 -mtune=k8   -o
libgmpxx.la -rpath /home/rainer/tmp/install/lib -no-undefined
-Wl,--export-all-symbols -Wl,--output-def,.libs/libgmp-3.dll.def
-Wl,--output-def,.libs/libgmpxx-3.dll.def -version-info 5:0:1 dummy.lo
cxx/isfuns.lo cxx/ismpf.lo cxx/ismpq.lo cxx/ismpz.lo cxx/ismpznw.lo
cxx/osdoprnti.lo cxx/osfuns.lo cxx/osmpf.lo cxx/osmpq.lo cxx/osmpz.lo libgmp.la 
rm -fr  .libs/libgmpxx.dll.a
g++ -shared -nostdlib
c:/mingw/x86_64-w64/x86_64-w64/x86_64-w64/gcc-4.5.0-test/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/dllcrt2.o
c:/mingw/x86_64-w64/x86_64-w64/x86_64-w64/gcc-4.5.0-test/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/crtbegin.o
 .libs/dummy.o cxx/.libs/isfuns.o cxx/.libs/ismpf.o cxx/.libs/ismpq.o
cxx/.libs/ismpz.o cxx/.libs/ismpznw.o cxx/.libs/osdoprnti.o cxx/.libs/osfuns.o
cxx/.libs/osmpf.o cxx/.libs/osmpq.o cxx/.libs/os

[Bug c++/42336] [c++0x] ICE with pointer-to-member-function decltype argument in template function

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2009-12-15 11:29 
---
FYI, I have checked, however, that the last posted patch for 42225

  http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00755.html

doesn't fix this one at once.


-- 


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

[Bug c++/42336] [c++0x] ICE with pointer-to-member-function decltype argument in template function

[dodji at seketeli dot org]

--- Comment #6 from dodji at seketeli dot org  2009-12-15 11:48 ---
Subject: Re:  [c++0x] ICE with pointer-to-member-function
 decltype argument in template function

> FYI, I have checked, however, that the last posted patch for 42225
> doesn't fix this one at once.

To be honest, I am not sure to understand how these two bugs would be
linked, but I haven't looked at this one in depth yet.


-- 


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

[Bug target/42377] libstdc++.dll.a misses a definition of std::string::reserve

[davek at gcc dot gnu dot org]

--- Comment #1 from davek at gcc dot gnu dot org  2009-12-15 11:49 ---
Hi Rainer,  it'll take a little time but I'll set myself up a build environment
and see if I can reproduce this.

The libtool dependency libs stuff is a known problem in libtool IIRC.  Details
to follow.


-- 


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

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

--- Comment #12 from dominiq at lps dot ens dot fr  2009-12-15 13:05 ---
> Looks that it has to be my patch that enables vectorization of conditions:

I am doing a clean bootstrap of C and FORTRAN of revision 149805 to see if the
test works for it (allow for ~6h on my poor G5). Then I'll update to 149806.


-- 


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

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

--- Comment #13 from irar at il dot ibm dot com  2009-12-15 13:07 ---
(In reply to comment #12)
> > Looks that it has to be my patch that enables vectorization of conditions:
> I am doing a clean bootstrap of C and FORTRAN of revision 149805 to see if the
> test works for it (allow for ~6h on my poor G5). Then I'll update to 149806.

1) Thanks. I got confused by the var names, but actually there is no COND_EXPR
there. But still, it can be this patch. So it worth checking. 

2) The vectorizer's code for powerpc64-suse-linux I got is identical to
darwin's except that the first has calls:

   _gfortran_set_args (argc_1(D), argv_2(D));
_gfortran_set_options (8, &options.36[0]);

in the begining

and the second one has this bb:

:
  dt_parm.33.common.filename = &"where_2.f90"[1]{lb: 1 sz: 1};
  dt_parm.33.common.line = 20;
  dt_parm.33.common.flags = 128;
  dt_parm.33.common.unit = 6;
  _gfortran_st_write (&dt_parm.33);
  parm.34.dtype = 265;
  parm.34.dim[0].lbound = 1;
  parm.34.dim[0].ubound = 10;
  parm.34.dim[0].stride = 1;
  parm.34.data = &temp[0];
  parm.34.offset = -1;
  _gfortran_transfer_array (&dt_parm.33, &parm.34, 4, 0);
  _gfortran_st_write_done (&dt_parm.33);

(I am attaching my dump).

3) The only difference between the targets I am aware of is natural alignment,
but we don't do peeling, so it shouldn't make any difference here.

4) We do force alignment. Between in the revisions range there is this patch
that may be somehow related:

r149853 | pbrook | 2009-07-21 15:35:38 +0300 (Tue, 21 Jul 2009) | 12 lines

2009-07-21  Paul Brook 

gcc/
* tree-vectorizer.c (increase_alignment): Handle nested arrays.
Terminate debug dump with newline.

gcc/testsuite/
* gcc.dg/vect/section-anchors-nest-1.c: New test.
* lib/target-supports.exp (check_effective_target_section_anchors):
Add arm*-*-*.

5) Also looking at the assembly may help. Could you please attach it as well?

Thanks,
Ira


-- 


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

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

--- Comment #14 from irar at il dot ibm dot com  2009-12-15 13:08 ---
Created an attachment (id=19311)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19311&action=view)
powerpc64-suse-linux vect dump


-- 


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

[Bug tree-optimization/42376] [4.5 Regression] Performance regression of generated code

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-12-15 13:15 ---
This is because (quoting http://gcc.gnu.org/gcc-4.5/changes.html):

"GCC now supports handling floating-point excess precision arising from use of
the x87 floating-point unit in a way that conforms to ISO C99. This is enabled
with -fexcess-precision=standard and with standards conformance options such as
-std=c99, and may be disabled using -fexcess-precision=fast."

GCC with -std=c99 makes sure to properly handle the i387 FPU excess precision.
With -fexcess-precision=fast the code is as fast (and non-conforming) like
with GCC 4.4.  Using -std=gnu99 is also an option.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX
Summary|[4.5] Performance regression|[4.5 Regression] Performance
   |of generated code   |regression of generated code
   Target Milestone|--- |4.5.0


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

[Bug libffi/42378] New: cls_*double_va.c failures on powerpc-apple-darwin9

[dominiq at lps dot ens dot fr]

I have started to see the following failures between revisions 148215 and
148502 (likely 148285, which means that these tests never passed on
powerpc-apple-darwin9):

Running target unix
FAIL: libffi.call/cls_double_va.c -O0 -W -Wall output pattern test, is -0.0
FAIL: libffi.call/cls_longdouble_va.c -O0 -W -Wall output pattern test, is -0.0
FAIL: libffi.call/cls_double_va.c -O2 output pattern test, is -0.0
FAIL: libffi.call/cls_longdouble_va.c -O2 output pattern test, is -0.0
FAIL: libffi.call/cls_double_va.c -O3 output pattern test, is -0.0
FAIL: libffi.call/cls_longdouble_va.c -O3 output pattern test, is -0.0
FAIL: libffi.call/cls_double_va.c -Os output pattern test, is -0.0
FAIL: libffi.call/cls_longdouble_va.c -Os output pattern test, is -0.0
FAIL: libffi.call/cls_double_va.c -O2 -fomit-frame-pointer output pattern test,
is -0.0
FAIL: libffi.call/cls_longdouble_va.c -O2 -fomit-frame-pointer output pattern
test, is -0.0

Note that libffi.call/nested_struct5.c also fails (see pr34311).


-- 
   Summary: cls_*double_va.c failures on powerpc-apple-darwin9
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libffi
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: powerpc-apple-darwin9
  GCC host triplet: powerpc-apple-darwin9
GCC target triplet: powerpc-apple-darwin9


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

[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures

[dominiq at lps dot ens dot fr]

--- Comment #26 from dominiq at lps dot ens dot fr  2009-12-15 13:21 ---
I have open pr42378 for the remaining failures in comment #21 (I did not
include  libffi.call/nested_struct5.c that is pr34311). Closing this PR as
fixed, please reopen if you disagree.


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

--- Comment #15 from dominiq at lps dot ens dot fr  2009-12-15 13:29 ---
> and the second one has this bb:
>
> :
>   dt_parm.33.common.filename = &"where_2.f90"[1]{lb: 1 sz: 1};
> ...
>   _gfortran_st_write_done (&dt_parm.33);

This is probably due to a print I put in the code to look at the array temp:

...
   print *, temp
   if (any (temp .ne. (/100, 100, 100, 210, 210, 210, 310, 310, 337, 337/))) &
...

I forgot to mention it.


-- 


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

[Bug middle-end/42372] Error: undefined symbol `.LPIC7' in operation

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-12-15 13:33 ---
Is this a regression?  If so please mark it so.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu dot
   ||org


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

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

--- Comment #16 from irar at il dot ibm dot com  2009-12-15 13:35 ---
But in comment #5 you wrote that it passes with the print, right? So, this dump
contains correct or incorrect code?


-- 


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

[Bug tree-optimization/42375] trunk hangs during diffutils configure

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-12-15 13:35 ---
This is a bug in the test.  Early inter-procedural SRA avoids passing array by
reference in the recurse() function and instead passes the first element
which is the only one read.  Thus the function is optimized to
an endless loop.

  static int
  recurse (char *p)
  {
char array[500];
array[0] = 1;
return *p + recurse (array);
  }

  int
  main (void)
  {
return recurse ("\1");
  }

on i686 (or with -m32) this does not happen - Martin, any idea why?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org
  Component|other   |tree-optimization
   GCC host triplet|x86_64-unknown-linux-gnu|
 GCC target triplet||i?86-*-*
   Keywords||missed-optimization


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

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

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-12-15 13:38 ---
This is because we never re-compute the address-taken flag of functions.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2009-12-15 13:38:42
   date||


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

[Bug tree-optimization/42326] segfault in tree-data-ref.c with Graphite building 200.sixtrack

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-12-15 13:50 ---
I can reproduce it with the testcase in comment #1 on i?86-linux:

$ ./f951  -quiet t.f -O2 -floop-strip-mine -fprefetch-loop-arrays -msse2
t.f: In function 'blts':
t.f:1:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Program received signal SIGSEGV, Segmentation fault.
0x086197d5 in initialize_matrix_A (A=0xb778ecb0, chrec=0xb77d36e4, index=2, 
mult=-1) at /home/richard/src/trunk/gcc/tree-data-ref.c:1914
1914  A[index][0] = mult * int_cst_value (CHREC_RIGHT (chrec));
(gdb) p A[index]
$4 = (lambda_vector) 0x6


-- 


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

[Bug tree-optimization/42326] [4.5 Regression] segfault in tree-data-ref.c with Graphite building 200.sixtrack

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-12-15 13:51 ---
Works for me with 4.4.2 on i?86-linux.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.4.2
   Priority|P3  |P1
Summary|segfault in tree-data-ref.c |[4.5 Regression] segfault in
   |with Graphite building  |tree-data-ref.c with
   |200.sixtrack|Graphite building
   ||200.sixtrack
   Target Milestone|--- |4.5.0


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

[Bug target/42374] 23_containers/map/operators/1_neg.cc fails test for errors on darwin10

[howarth at nitro dot med dot uc dot edu]

--- Comment #3 from howarth at nitro dot med dot uc dot edu  2009-12-15 
13:53 ---
I am building with custom fink packaging for the gcc45 pre-releases. All the
important build information should be in the specs output of the compiler.


-- 


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

[Bug tree-optimization/42185] [4.5 Regression] [graphite] expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs_code, at gimple.h:1820

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-12-15 13:54 ---
Still fails the same way for me.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

--- Comment #17 from dominiq at lps dot ens dot fr  2009-12-15 14:15 ---
> But in comment #5 you wrote that it passes with the print, right? So, this 
> dump
> contains correct or incorrect code?

The dump for 4.5 is from the incorrect code. The behavior of this bug has
change over time, it started for -m64 only with/without print, then it failes
also with -m32, finally at revision 155239 it fails with the print:

...
   print *, temp
   if (any (temp .ne. (/100, 100, 100, 210, 210, 210, 310, 310, 337, 337/))) &
  call abort
end program
[karma] f90/bug% gfc -O3 where_2.f90
[karma] f90/bug% a.out 
 100 100 100 210 210 210   
 310 337 310 310
Abort
[karma] f90/bug% gfc -m64 -O3 where_2.f90
[karma] f90/bug% a.out
 100 100 100 210 210 210   
 310 337 310 337
Abort

Note that the content of temp change with the mode.


-- 


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

[Bug target/42377] libstdc++.dll.a misses a definition of std::string::reserve

[rainer at emrich-ebersheim dot de]

--- Comment #2 from rainer at emrich-ebersheim dot de  2009-12-15 14:25 
---
(In reply to comment #1)
> Hi Rainer,  it'll take a little time but I'll set myself up a build 
> environment
> and see if I can reproduce this.
> 
> The libtool dependency libs stuff is a known problem in libtool IIRC.  Details
> to follow.
> 

Dave thanks for your help. Interestingly for i686-pc-mingw32 this works, but
the dependency_libs is bogus too.

Rainer


-- 


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

[Bug c++/41183] [4.4 Regression] ICE compiling chromium

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2009-12-15 15:13 ---
Subject: Bug 41183

Author: jakub
Date: Tue Dec 15 15:13:08 2009
New Revision: 155254

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155254
Log:
PR c++/41183
* cp-tree.h (current_class_ptr): Give NULL even when cfun
has NULL cfun->language.

* g++.dg/torture/pr41183.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr41183.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/42379] New: [4.5 Regression] Revision 155245 failed 1_neg.cc

[hjl dot tools at gmail dot com]

Revision 155245:

http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00389.html

caused:

FAIL: 23_containers/map/operators/1_neg.cc  (test for errors, line 212)
FAIL: 23_containers/map/operators/1_neg.cc  (test for errors, line 216)
FAIL: 23_containers/map/operators/1_neg.cc (test for excess errors)
FAIL: 23_containers/set/operators/1_neg.cc  (test for errors, line 287)
FAIL: 23_containers/set/operators/1_neg.cc  (test for errors, line 291)
FAIL: 23_containers/set/operators/1_neg.cc (test for excess errors)


-- 
   Summary: [4.5 Regression] Revision 155245 failed 1_neg.cc
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c++/41183] [4.4 Regression] ICE compiling chromium

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2009-12-15 15:15 ---
Subject: Bug 41183

Author: jakub
Date: Tue Dec 15 15:14:59 2009
New Revision: 155255

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155255
Log:
PR c++/41183
* cp-tree.h (current_class_ptr): Give NULL even when cfun
has NULL cfun->language.

* g++.dg/torture/pr41183.C: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr41183.C
Modified:
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/cp-tree.h
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/42374] 23_containers/map/operators/1_neg.cc fails test for errors on darwin10

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2009-12-15 15:16 ---
See also http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg01308.html for
i686-pc-linux-gnu.


-- 


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

[Bug tree-optimization/42185] [4.5 Regression] [graphite] expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs_code, at gimple.h:1820

[aldyh at gcc dot gnu dot org]

--- Comment #4 from aldyh at gcc dot gnu dot org  2009-12-15 15:18 ---
Subject: Bug 42185

Author: aldyh
Date: Tue Dec 15 15:17:46 2009
New Revision: 155256

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155256
Log:
   PR graphite/42185
* graphite-sese-to-poly.c (is_reduction_operation_p): Assert that
we are a GIMPLE_ASSIGN.  Do not calculate rhs code twice.
(follow_ssa_with_commutative_ops): Return NULL on non assignment.


Added:
trunk/gcc/testsuite/gfortran.dg/graphite/pr42185.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-sese-to-poly.c


-- 


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

[Bug tree-optimization/42185] [4.5 Regression] [graphite] expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs_code, at gimple.h:1820

[aldyh at gcc dot gnu dot org]

--- Comment #5 from aldyh at gcc dot gnu dot org  2009-12-15 15:18 ---
That's because I hadn't committed.  Tests pass.  Committing and closing.


-- 

aldyh at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug testsuite/41146] FAIL: gcc.target/powerpc/asm-es-2.c scan-assembler *

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2009-12-15 15:37 ---
A patch has been posted to
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00772.html .


-- 


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

[Bug c++/42379] [4.5 Regression] Revision 155245 failed 1_neg.cc

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-12-15 15:42 ---
*** Bug 42374 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||howarth at nitro dot med dot
   ||uc dot edu


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

[Bug target/42374] 23_containers/map/operators/1_neg.cc fails test for errors on darwin10

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-12-15 15:42 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/42379] [4.5 Regression] Revision 155245 failed 1_neg.cc

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.5 Regression] Revision   |[4.5 Regression] Revision
   |155245 failed 1_neg.cc  |155245 failed 1_neg.cc
   Target Milestone|--- |4.5.0


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

[Bug c++/42379] [4.5 Regression] Revision 155245 failed 1_neg.cc

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-12-15 15:59 
---
It's trivial, just one more "candidates are" which must be adjusted to
"candidate is" in the dg-error strings.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-15 15:59:12
   date||


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

[Bug c++/42379] [4.5 Regression] Revision 155245 failed 1_neg.cc

[paolo at gcc dot gnu dot org]

--- Comment #3 from paolo at gcc dot gnu dot org  2009-12-15 16:11 ---
Subject: Bug 42379

Author: paolo
Date: Tue Dec 15 16:11:32 2009
New Revision: 155258

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155258
Log:
2009-12-15  Paolo Carlini  

PR c++/42379
* testsuite/23_containers/set/operators/1_neg.cc: Fix dg-error strings.
* testsuite/23_containers/map/operators/1_neg.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/23_containers/map/operators/1_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/set/operators/1_neg.cc


-- 


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

[Bug c++/42379] [4.5 Regression] Revision 155245 failed 1_neg.cc

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-12-15 16:12 
---
Done.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/27425] [4.3/4.4/4.5 regression] ICE with invalid template-template-parameter

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.5.0   |4.4.3


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

[Bug c++/34274] [4.3/4.4/4.5 regression] Broken diagnostic: 'template_template_parm' not supported by dump_decl

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.5.0   |4.4.3


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

[Bug c++/33492] [4.3 regression] Broken diagnostic: 'must_not_throw_expr' not supported by dump_expr

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.4.0
Summary|[4.2/4.3 regression] Broken |[4.3 regression] Broken
   |diagnostic: |diagnostic:
   |'must_not_throw_expr' not   |'must_not_throw_expr' not
   |supported by dump_expr  |supported by dump_expr
   Target Milestone|4.4.3   |4.3.5


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

[Bug debug/39412] [4.3 Regression] ICE in gen_tagged_type_instantiation_die

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.2/4.3 Regression] ICE in |[4.3 Regression] ICE in
   |gen_tagged_type_instantiatio|gen_tagged_type_instantiatio
   |n_die   |n_die
   Target Milestone|4.4.3   |4.3.5


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

[Bug middle-end/40106] [4.4/4.5 Regression] Time increase for the Polyhedron test air.f90 due to bad optimization

[rguenth at gcc dot gnu dot org]

--- Comment #34 from rguenth at gcc dot gnu dot org  2009-12-15 16:40 
---
4.4 is also slow, we know what causes it so this can't be P1.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P1  |P2


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

[Bug debug/42380] New: CFI statements vs. -pg

[tschwinge at gcc dot gnu dot org]

See .

To sum up: the question is whether the CFA needs to be adjusted after push
{lr}, and before calling __gnu_mcount_nc.  Currently it is not valid until
__gnu_mcount_nc returns.


-- 
   Summary: CFI statements vs. -pg
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tschwinge at gcc dot gnu dot org
GCC target triplet: arm-none-linux-gnueabi


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

[Bug debug/42380] CFI statements vs. -pg

[tschwinge at gcc dot gnu dot org]

--- Comment #1 from tschwinge at gcc dot gnu dot org  2009-12-15 16:57 
---
Richard Earnshaw wrote:
> I'm not sure what other architectures do in this case.  Do they also put
> out adjustments to the cfi?

I had a look at x86 and x86_64 -- they still need a frame pointer together with
-pg, which is thus set-up (with CFI information) before calling mcount.  I'll
try to locate and have a look at another architecture.


-- 


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

[Bug libstdc++/24803] [c++0x] reference_wrapper and pointers to member functions

[paolo dot carlini at oracle dot com]

--- Comment #17 from paolo dot carlini at oracle dot com  2009-12-15 17:00 
---
At the moment, not actively working on this...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler

[paolo dot carlini at oracle dot com]

--- Comment #14 from paolo dot carlini at oracle dot com  2009-12-15 17:02 
---
Is this still an issue?


-- 


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

[Bug libstdc++/38923] symbol versioning disabled due to non-portable sed script

[paolo dot carlini at oracle dot com]

--- Comment #18 from paolo dot carlini at oracle dot com  2009-12-15 17:04 
---
I'm closing this as fixed for 4.5.0.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jakub at redhat dot com
 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug libstdc++/34419] Weirdness with numeric_limits in special functions

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2009-12-15 17:17 
---
Ok, let's close this as invalid.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/35968] nth_element fails to meet its complexity requirements

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2009-12-15 17:19 
---
Roger, are you still actively working on this?


-- 


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

[Bug libstdc++/42381] New: deque shouldn't reserve that much memory

[kraemer at informatik dot uni-kl dot de]

In bits/stl_deque.h, line 80ff the minimal allocated size is set fixed to 512.
This should be configurable, at least via a macro.
In case of small memory systems (embedded devices) resveration of this amount
of memory is much too high.


-- 
   Summary: deque shouldn't reserve that much memory
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kraemer at informatik dot uni-kl dot de


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

[Bug debug/42288] please emit empty .debug_aranges section

[rth at gcc dot gnu dot org]

--- Comment #6 from rth at gcc dot gnu dot org  2009-12-15 17:36 ---
 rth: sorry... yeah, I tested the aranges patch and it worked for me. 
but it isn't clear we will need it now, we're discussing some form of caching
w/ gdb rather than using the index sections
 ok.  i'll leave the patch alone until you tell me we need it.


-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |SUSPENDED


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

[Bug libstdc++/42381] deque shouldn't reserve that much memory

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-12-15 17:38 
---
Changing the value, via macro or whatever is trivial, and I can tell you for
sure from some experiment I did, that a *larger* value is much better, when
memory is available, for operations like copies. Changing the value however,
breaks the binary compatibility between objects (e.g, one allocating, the other
deallocating the same deque), it's a dangerous option.


-- 


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

[Bug libstdc++/42381] deque shouldn't reserve that much memory

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

--- Comment #18 from dominiq at lps dot ens dot fr  2009-12-15 17:47 ---
The tests (with/without print) pass at revision 149806 (a clean bootstrap of
149805, followed by an update to 149806). I am currently bootstrapping 149852.


-- 


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

[Bug libstdc++/42381] deque shouldn't reserve that much memory

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-12-15 17:57 
---
Let's add a macro (with a *big* warning), will be also useful for experimenting
when I will add (soon) the segmented iterator optimization for copies.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-15 17:57:38
   date||


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

[Bug tree-optimization/42205] [4.5 Regression] [graphite] internal compiler error: verify_ssa failed with -ffast-math -floop-interchange

[zsojka at seznam dot cz]

--- Comment #5 from zsojka at seznam dot cz  2009-12-15 18:41 ---
(In reply to comment #4)
> Created an attachment (id=19250)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19250&action=view) [edit]
> different testcase, this one is using doubles
> 
> tested r155020, crashes with:
> -O1 -funsafe-math-optimizations -floop-interchange
> -O1 -funsafe-math-optimizations -floop-strip-mine
> -O1 -funsafe-math-optimizations -floop-block
> 
> pr42205-2.c:1:8: internal compiler error: gimple check: expected
> gimple_assign(error_mark), have gimple_nop() in gimple_assign_rhs_code, at
> gimple.h:1820
> 

This testcase crashes in r155248, but doesn't crash anymore in r155256 (most
likely a dup of pr42185).

The original testcase (comment #1) still crashes with:
-O1 -funsafe-math-optimizations -fgraphite-identity


-- 


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

[Bug c++/42373] g++.dg/cpp0x/lambda/lambda-mangle.C scan-assembler weak[ \t]*_?_ZN1RIiE1xMUlvE_clEv fails on x86_64-apple-darwin

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2009-12-15 18:57 ---
Subject: Bug 42373

Author: jason
Date: Tue Dec 15 18:57:30 2009
New Revision: 155266

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155266
Log:
PR c++/42373
* g++.dg/cpp0x/lambda/lambda-mangle.C: Adjust regexps for darwin.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-mangle.C


-- 


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

[Bug c++/42358] [4.5 Regression][C++0x] Assembler failure on libstdc++-v3/testsuite/23_containers/multimap/init-list.cc with -O0

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2009-12-15 18:57 ---
Subject: Bug 42358

Author: jason
Date: Tue Dec 15 18:57:39 2009
New Revision: 155267

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155267
Log:
PR c++/42358
* pt.c (iterative_hash_template_arg): Completely ignore
ARGUMENT_PACK_SELECT.

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


-- 


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

[Bug c++/42373] g++.dg/cpp0x/lambda/lambda-mangle.C scan-assembler weak[ \t]*_?_ZN1RIiE1xMUlvE_clEv fails on x86_64-apple-darwin

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2009-12-15 18:58 ---
fixed, I think.  Needs confirmation.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING


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

[Bug c++/42358] [4.5 Regression][C++0x] Assembler failure on libstdc++-v3/testsuite/23_containers/multimap/init-list.cc with -O0

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2009-12-15 18:58 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/42382] New: _Bool foo &= bar; vs _Bool foo = foo && bar; vs _Bool foo = foo & bar; emitted code different

[joe at perches dot com]

gcc 4.4.1 produces different code for these equivalent inputs.
optimization levels -Os -O2 -O3

It'd be good if the produced code were identical.

#include 
#include 
#include 

int main(int argc, char** argv)
{
  _Bool foo;
  _Bool bar;

  foo = !!rand();
  bar = !!rand();

  foo &= bar;

  printf("%u %u\n", foo, bar);

  foo = !!rand();
  bar = !!rand();

  foo = foo & bar;

  printf("%u %u\n", foo, bar);

  foo = !!rand();
  bar = !!rand();

  foo = foo && bar;

  printf("%u %u\n", foo, bar);

  return 0;
}


-- 
   Summary: _Bool foo &= bar; vs _Bool foo = foo && bar; vs _Bool
foo = foo & bar; emitted code different
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joe at perches dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug c++/42336] [c++0x] ICE with pointer-to-member-function decltype argument in template function

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2009-12-15 20:04 ---
You're right, they probably aren't; this doesn't involve typedefs.


-- 


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

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[armand dot potter at free dot fr]

--- Comment #13 from armand dot potter at free dot fr  2009-12-15 20:48 
---
I'm using about the same configuration (cross-LFS build but with gcc 4.4.2) and
got the same error. I did some investigations and the problem is that fenv.h
file from build tree is first included (and defines _GLIBCXX_FENV_H to 1) and
then include_next includes fenv.h from host (installed in
/usr/TARGET/include/c++/VERSION/fenv.h) and this time as _GLIBCXX_FENV_H is
already defined, does nothing so fenv.h from glibc is never included.

For a native build, just compiled c++ compiler is used with the -nostdinc++
flag so that /usr/TARGET/include/c++/VERSION/fenv.h is not seen and
include_next works as expected including glibc header.

I don't know what is the correct solution but at least you know what the real
problem is. 
~   


-- 

armand dot potter at free dot fr changed:

   What|Removed |Added

 CC||armand dot potter at free
   ||dot fr


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

[Bug libstdc++/42381] deque shouldn't reserve that much memory

[paolo at gcc dot gnu dot org]

--- Comment #3 from paolo at gcc dot gnu dot org  2009-12-15 20:58 ---
Subject: Bug 42381

Author: paolo
Date: Tue Dec 15 20:58:29 2009
New Revision: 155271

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155271
Log:
2009-12-15  Paolo Carlini  

PR libsdtc++/42381
* include/bits/stl_deque.h (_GLIBCXX_DEQUE_BUF_SIZE): Add.
(__deque_buf_size(size_t)): Use it.
* testsuite/23_containers/deque/requirements/dr438/
assign_neg.cc: Adjust dg-error line numbers.
* testsuite/23_containers/deque/requirements/dr438/
insert_neg.cc: Likewise.
* testsuite/23_containers/deque/requirements/dr438/
constructor_1_neg.cc: Likewise.
* testsuite/23_containers/deque/requirements/dr438/
constructor_2_neg.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_deque.h
   
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/assign_neg.cc
   
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc
   
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_2_neg.cc
   
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/insert_neg.cc


-- 


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

[Bug c++/42355] Segmentation fault

[peter_foelsche at agilent dot com]

--- Comment #6 from peter_foelsche at agilent dot com  2009-12-15 20:58 
---
Created an attachment (id=19313)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19313&action=view)
tmp.cpp

g++ -c tmp.cpp -I ~/boost_1_40_0 -g

-g is important


-- 


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

[Bug libstdc++/42381] deque shouldn't reserve that much memory

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-12-15 21:01 
---
Done.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug middle-end/42178] [4.5 Regression] gcc.dg/graphite/interchange-8.c causes ICE

[spop at gcc dot gnu dot org]

--- Comment #5 from spop at gcc dot gnu dot org  2009-12-15 21:12 ---
Subject: Bug 42178

Author: spop
Date: Tue Dec 15 21:11:48 2009
New Revision: 155273

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155273
Log:
Fix fall outs from Fix-PR42334.

2009-12-15  Sebastian Pop  

PR middle-end/42178
PR middle-end/42334
* graphite-interchange.c (lst_try_interchange): Do not increment the
the OUTER index when there is no AFTER kernel.  Do not increment the
OUTER index for after processing the AFTER kernel.
(lst_interchange_select_inner): Call lst_try_interchange only on loops.
(lst_interchange_select_outer): Do not pass in a pointer to the OUTER
index.  Do not pass to lst_interchange_select_inner the OUTER index.
(scop_do_interchange): Update use of lst_interchange_select_outer.

* testsuite/gfortran.dg/graphite/graphite.exp
(DEFAULT_FLAGS_GRAPHITE_IDENTITY): Remove -fdump-tree-graphite-all.
* testsuite/gfortran.dg/graphite/interchange-1.f: Add comment.  Clean
the graphite dump file.
* testsuite/gfortran.dg/graphite/interchange-2.f: Same.
* testsuite/gfortran.dg/graphite/pr42334-1.f: New.

Added:
branches/graphite/gcc/testsuite/gfortran.dg/graphite/pr42334-1.f
Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/graphite-interchange.c
branches/graphite/gcc/testsuite/gfortran.dg/graphite/graphite.exp
branches/graphite/gcc/testsuite/gfortran.dg/graphite/interchange-1.f
branches/graphite/gcc/testsuite/gfortran.dg/graphite/interchange-2.f


-- 


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

[Bug tree-optimization/42334] segfault in graphite-poly.h for 200.sixtrack

[spop at gcc dot gnu dot org]

--- Comment #4 from spop at gcc dot gnu dot org  2009-12-15 21:12 ---
Subject: Bug 42334

Author: spop
Date: Tue Dec 15 21:11:48 2009
New Revision: 155273

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155273
Log:
Fix fall outs from Fix-PR42334.

2009-12-15  Sebastian Pop  

PR middle-end/42178
PR middle-end/42334
* graphite-interchange.c (lst_try_interchange): Do not increment the
the OUTER index when there is no AFTER kernel.  Do not increment the
OUTER index for after processing the AFTER kernel.
(lst_interchange_select_inner): Call lst_try_interchange only on loops.
(lst_interchange_select_outer): Do not pass in a pointer to the OUTER
index.  Do not pass to lst_interchange_select_inner the OUTER index.
(scop_do_interchange): Update use of lst_interchange_select_outer.

* testsuite/gfortran.dg/graphite/graphite.exp
(DEFAULT_FLAGS_GRAPHITE_IDENTITY): Remove -fdump-tree-graphite-all.
* testsuite/gfortran.dg/graphite/interchange-1.f: Add comment.  Clean
the graphite dump file.
* testsuite/gfortran.dg/graphite/interchange-2.f: Same.
* testsuite/gfortran.dg/graphite/pr42334-1.f: New.

Added:
branches/graphite/gcc/testsuite/gfortran.dg/graphite/pr42334-1.f
Modified:
branches/graphite/gcc/ChangeLog.graphite
branches/graphite/gcc/graphite-interchange.c
branches/graphite/gcc/testsuite/gfortran.dg/graphite/graphite.exp
branches/graphite/gcc/testsuite/gfortran.dg/graphite/interchange-1.f
branches/graphite/gcc/testsuite/gfortran.dg/graphite/interchange-2.f


-- 


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

[Bug c/42384] New: attribute((warning(""))) should warn on function addresses

[ebb9 at byu dot net]

Right now, use of attribute((warning)) only triggers a warning when
encountering a direct call of a labeled function (line 13 in the example below)
or simple indirection that can trivially be reduced to a direct call (line 17).
 But there is a hole: any time the address of a function is not immediately
used for a function call, the warning is lost.  It would be nice if a warning
were instead issued at any place where the address of a function is taken (and
not further optimized out of the program), thus causing additional warnings on
lines 14 and 15 in the example.  After all, the resulting function calls in
lines 14 and 16 are no safer than any of the other calls in the example.

$ cat foo.c
static int oops (int) __attribute__ ((__warning__ ("message")));

static int
oops (int x)
{
  return x;
}

int
main (int argc, char **argv)
{
  int (*func) (int);
  oops (1);
  (func = &oops) (1);
  func = oops;
  func (1);
  (&oops) (1);
  return 0;
}
$ gcc -o foo foo.c
foo.c: In function ‘main’:
foo.c:13: warning: call to ‘oops’ declared with attribute warning: message
foo.c:17: warning: call to ‘oops’ declared with attribute warning: message
$


-- 
   Summary: attribute((warning(""))) should warn on function
addresses
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ebb9 at byu dot net


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

[Bug tree-optimization/42221] [4.5 Regression] ICE from '-Os -fgraphite-identity'

[spop at gcc dot gnu dot org]

--- Comment #2 from spop at gcc dot gnu dot org  2009-12-15 21:28 ---
Mine.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |spop at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-15 21:28:23
   date||


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

[Bug tree-optimization/42221] [4.5 Regression] ICE from '-Os -fgraphite-identity'

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2009-12-15 21:41 ---
Reduced testcase as follows:


static void b2w(unsigned int *out, const unsigned char *in, unsigned int len)
{
  const unsigned char *bpend = in + len;
  for (; in != bpend; in += 4, ++out)
  {
*out = (unsigned int) (in[0] ) |
  (unsigned int) (in[3] << 24);
  }
}
static void md4step(unsigned int state[4], const unsigned char *data)
{
  unsigned int A, X[16];
  b2w(X, data, 64);
  state[0] += A;
}
void md4sum(void)
{
  unsigned char final[128];
  unsigned int state[4];
  md4step(state, final);
  md4step(state, final + 64);
}


-- 


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

[Bug libstdc++/42273] atomic_2.h:111: = instead of == in if

[bkoz at gcc dot gnu dot org]

--- Comment #9 from bkoz at gcc dot gnu dot org  2009-12-15 21:46 ---
Fixed.


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/42336] [c++0x] ICE with pointer-to-member-function decltype argument in template function

[jason at gcc dot gnu dot org]

--- Comment #8 from jason at gcc dot gnu dot org  2009-12-15 21:54 ---
The problem here is that after we're done parsing the translation unit, we do
IPA optimizations, and IPA decides to change the type of X::func from a
METHOD_TYPE to a FUNCTION_TYPE.

Then later we're emitting debug information about b, and ask the compiler
for that name.  So we try to substitute X into decltype(&T::func) to see if the
argument we have is the same as the default argument.  But at this point
T::func resolves to a function with FUNCTION_TYPE, whereas we were expecting
one with METHOD_TYPE, and boom.

I suppose we can't do any tsubsting after IPA runs.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-15 21:54:02
   date||


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

[Bug libstdc++/41865] map as class static member variable causing crash on process exit

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-12-15 21:55 
---
Feedback not forthcoming, closing. If you mean to provide a reproducer, please
re-open, thanks.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug target/39640] MIPS : buggy va_list with float, long long and long double arguments

[xavier dot guerin at imag dot fr]

--- Comment #2 from xavier dot guerin at imag dot fr  2009-12-15 22:13 
---
Hello list,

Just checking if anyone had time to dig into this issue.
If necessary, I can provide more material.

Regards,
Xavier


-- 


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

[Bug c++/42336] ICE with pointer-to-member-function argument in template function

[jason at gcc dot gnu dot org]

--- Comment #9 from jason at gcc dot gnu dot org  2009-12-15 22:24 ---
It does seem kind of dodgy that IPA is modifying the types of functions
directly, though...

Here's a non-C++0x testcase:

struct X {
  void func() {}
};

template
void b(T) {}

int main() {
  b(X()); /* line 9 */
  X().func();

  return 0;
}

So, this could be fixed by

1) Not relying on function types being sensible once IPA begins.
1a) Generating names for debug info earlier
1b) Giving up on trying not to print default args in names for debug info
2) Keeping function types sensible.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org
Summary|[c++0x] ICE with pointer-to-|ICE with pointer-to-member-
   |member-function decltype|function argument in
   |argument in template|template function
   |function|


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

[Bug target/39640] MIPS : buggy va_list with float, long long and long double arguments

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-12-15 22:26 
---
If you are willing to help more I think you can do two things: 1- Double check
if the problem still exists in the current, that is 4.4, release branch and in
mainline; 2- Actually provide "less" material, that is a *minimal* testcase
still showing the problem.


-- 


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