[Bug tree-optimization/49773] New: use of class data members prevent vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49773
Summary: use of class data members prevent vectorization
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
in this example below the loop in the first method does not vectorize, the
second does.
struct Foo {
float a;
float b;
void compute1(float * __restrict__ x, float const * __restrict__ y, int N)
const;
void compute2(float * __restrict__ x, float const * __restrict__ y, int N)
const;
};
void Foo::compute1(float * __restrict__ x, float const * __restrict__ y, int N)
const {
for (int i=0; i!=N; ++i)
x[i] = a + b*y[i];
}
void Foo::compute2(float * __restrict__ x, float const * __restrict__ y, int N)
const {
float la=a, lb=b;
for (int i=0; i!=N; ++i)
x[i] = la + lb*y[i];
}
test/vectClass.cpp:11: note: not vectorized: loop contains function calls or
data references that cannot be analyzed
test/vectClass.cpp:10: note: vectorized 0 loops in function.
vs
test/vectClass.cpp:17: note: Profitability threshold is 5 loop iterations.
test/vectClass.cpp:17: note: LOOP VECTORIZED.
test/vectClass.cpp:15: note: vectorized 1 loops in function.
[Bug fortran/49708] [4.5/4.6/4.7 Regression] ICE with allocate and no dimensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49708 --- Comment #5 from Tobias Burnus 2011-07-18 07:33:07 UTC --- Janus, what's the status? (In reply to comment #4) > I just verified that this patch is free of testsuite regressions. The patch is OK with a test case, ChangeLog - and CCing it to fortran@/gcc-patches@.
[Bug middle-end/49675] [4.6/4.7 Regression] ICE (segfault) with -finstrument-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49675 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.07.18 07:46:56 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek 2011-07-18 07:46:56 UTC --- Created attachment 24786 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24786 gcc47-pr49675.patch Untested fix.
[Bug tree-optimization/49140] [4.6 regression] wrong code with -O2 and -O3, not with -O3 -no-inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49140 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.07.18 08:02:02 Ever Confirmed|0 |1 --- Comment #6 from Richard Guenther 2011-07-18 08:02:02 UTC --- This PR lacks an executable testcase for easy verification of the bug. Thus, can people try with the fix for PR49651 installed?
[Bug lto/46798] [4.6 Regression] invalid conversion in gimple call; verify_stmts failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46798 Richard Guenther changed: What|Removed |Added Known to work||4.7.0 Summary|[4.6/4.7 Regression]|[4.6 Regression] invalid |invalid conversion in |conversion in gimple call; |gimple call; verify_stmts |verify_stmts failed |failed | --- Comment #7 from Richard Guenther 2011-07-18 08:04:07 UTC --- Might be worth adding a testcase to trunk.
[Bug middle-end/49545] [4.6 Regression] New C++ test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49545 Richard Guenther changed: What|Removed |Added Known to work||4.7.0 Target Milestone|4.7.0 |4.6.2 Summary|[4.7 Regression] New C++|[4.6 Regression] New C++ |test failures |test failures --- Comment #9 from Richard Guenther 2011-07-18 08:12:50 UTC --- Can you check what patch caused it on the 4.6 branch? I suppose "fixed" on the trunk.
[Bug c/35634] [4.4/4.5/4.6/4.7 Regression] operand of pre-/postin-/decrement not promoted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634 --- Comment #31 from Richard Guenther 2011-07-18 08:16:58 UTC --- Well, I'd still go for comment#14 ... we could teach VRP to shorten the operations again, if possible, to avoid the optimization regressions.
[Bug target/49742] [4.7 Regression] ICE for gcc.dg/vect/O3-pr39675-2.c on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49742 --- Comment #5 from Richard Guenther 2011-07-18 08:24:40 UTC --- This must be an artifact of the load-/store-lanes stuff. It looks like they play foul with aliasing. It might also be that predictive commoning simply does not know how to re-materialize calls (they seem to be analyzed as only loading the memory arguments by data-reference analysis, so if predcom tries to split them that will obviously fail - not sure if it's a good idea to do the call handling the way get_references_in_stmt does).
[Bug tree-optimization/49772] [4.7 Regression] ICE: in ipa_pta_execute, at tree-ssa-structalias.c:6790 with -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49772 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.18 08:27:57 CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2011-07-18 08:27:57 UTC --- Honza, now that we error instead of sorry (which immediately aborts compilation), should we fixup the cgraph to point to non-inline variants?
[Bug tree-optimization/49770] [4.7 Regression] wrong code with -fno-tree-forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49770 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 --- Comment #3 from Richard Guenther 2011-07-18 08:30:23 UTC --- Mine.
[Bug tree-optimization/49771] [4.7 Regression] wrong code with -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49771 Richard Guenther changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Target Milestone|--- |4.7.0
[Bug other/49767] __mulsc3 runs into infinite recursion if GCC is compiled with -O0 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49767 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther 2011-07-18 08:47:33 UTC --- Fixed in 4.3.3
[Bug c/49768] [4.6/4.7 Regression] C99 style union initializations does not work as expected with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49768 --- Comment #5 from Richard Guenther 2011-07-18 08:47:01 UTC --- I suppose fold produces some BIT_FIELD_REF here, giving up probably is easiest for now.
[Bug middle-end/49774] New: [meta-bug] restrict qualification aliasing issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49774 Summary: [meta-bug] restrict qualification aliasing issues Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org Depends on: 49761 Meta-bug to track restrict qualification issues.
[Bug tree-optimization/49761] restrict keyword ignored if in structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49761 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.18 08:51:48 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-07-18 08:51:48 UTC --- Yes, you can declare an array restricted in a structure. GCC will however not be able to track this for anonymous storage.
[Bug tree-optimization/49760] vectorization inhibited if indices are references
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49760 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||missed-optimization Last reconfirmed||2011.07.18 08:57:31 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Richard Guenther 2011-07-18 08:57:31 UTC --- The issue is that *k may be aliased by a store to the int array pointed to by out. That is because the middle-end treats int & k the same as int * k (not sure if there is a semantic difference in C++), so it might as well point to out.a[27]. Which means int & k should be restrict qualified as well (why even pass it as reference?)
[Bug testsuite/49757] FAIL: gcc.target/tic6x/*.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49757 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Richard Guenther 2011-07-18 08:59:57 UTC --- Fixed.
[Bug other/49775] New: [4.6.1 Regression on AVR] ICE in based_loc_descr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49775 Summary: [4.6.1 Regression on AVR] ICE in based_loc_descr Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: anitha.boyap...@atmel.com AVR target built with specs: Using built-in specs. COLLECT_GCC=avr-gcc COLLECT_LTO_WRAPPER=/home/anitha/install/libexec/gcc/avr/4.6.1/lto-wrapper Target: avr Configured with: ../configure --prefix=/home/anitha/install --target=avr --with-gmp=/proj/install/gmp-4.3.2/ --with-mpfr=/proj/install/mpfr-2.4.2/ --with-mpc=/proj/install/mpc-0.8.2/ --enable-languages=c,c++ --disable-libssp --disable-nls --with-dwarf2 Thread model: single gcc version 4.6.1 (GCC) The above compiler gives an ICE in based_loc_descr() of dwarf2out.c for 2 testcases present in gcc/testsuite/gcc.c-torture/compile/pr17906.c and gcc/testsuite/gcc.c-torture/compile/pr35432.c. Output for pr17906.c /home/anitha/patch-upgrade/gcc-4.6.1/gcc/testsuite/gcc.c-torture/compile/pr17906.c: In function 'usc_recressive_func': /home/anitha/patch-upgrade/gcc-4.6.1/gcc/testsuite/gcc.c-torture/compile/pr17906.c:7:1: internal compiler error: in based_loc_descr, at dwarf2out.c:13563 Output for pr35432.c /gcc-4.6.1/gcc/testsuite/gcc.c-torture/compile/pr35432.c(timeout = 300) /home/anitha/patch-upgrade/gcc-4.6.1/gcc/testsuite/gcc.c-torture/compile/pr35432.c: In function 'foo': /home/anitha/patch-upgrade/gcc-4.6.1/gcc/testsuite/gcc.c-torture/compile/pr35432.c:11:1: internal compiler error: in based_loc_descr, at dwarf2out.c:13563
[Bug other/49775] [4.6.1 Regression on AVR] ICE in based_loc_descr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49775 --- Comment #1 from Anitha Boyapati 2011-07-18 09:01:36 UTC --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17906 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35432
[Bug other/49752] [4.7 Regression] Non-existing struct `tree_type' in fold_checksum_tree in fold-const.c, can't build with `--enable-checking=fold'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49752 Richard Guenther changed: What|Removed |Added Keywords||build Target Milestone|--- |4.7.0 Summary|Non-existing struct |[4.7 Regression] |`tree_type' in |Non-existing struct |fold_checksum_tree in |`tree_type' in |fold-const.c, can't build |fold_checksum_tree in |with|fold-const.c, can't build |`--enable-checking=fold'|with ||`--enable-checking=fold'
[Bug target/47744] [x32] ICE: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744 --- Comment #28 from Uros Bizjak 2011-07-18 09:08:39 UTC --- Here is my latest proposed patch: --cut here-- Index: i386.c === --- i386.c(revision 176386) +++ i386.c(working copy) @@ -11149,8 +11149,13 @@ return 0; break; +case SUBREG: + /* Allow only subregs of DImode hard regs in PLUS chains. */ + if (!register_no_elim_operand (SUBREG_REG (op), DImode)) +return 0; + /* FALLTHRU */ + case REG: -case SUBREG: if (!base) base = op; else if (!index) --cut here-- The patch will also benefit x86_64 and x86_32. The patch allows only SUBREGs with DImode non-eliminable hard register. This way paradoxical subregs are avoided, and at the same time, the patch makes sure that PLUS RTX in wider mode won't enter the address RTX (via combine pass, register elimination in reload, etc).
[Bug tree-optimization/49749] Reassociation rank algorithm does not include all non-NULL operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49749 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.18 09:07:11 Ever Confirmed|0 |1 --- Comment #8 from Richard Guenther 2011-07-18 09:07:11 UTC --- First of call, confirmed.
[Bug c++/49756] g++ ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49756
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.07.18 09:16:59
CC||jason at gcc dot gnu.org
Component|tree-optimization |c++
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther 2011-07-18
09:16:59 UTC ---
I see a very deep recursion in the C++ frontend instead which blows my stack.
#7701 0x0079ae0f in cp_genericize_r (stmt_p=0x75b81a98,
walk_subtrees=0x7fffd100, data=0x7fffd4c0)
at /space/rguenther/src/svn/gcc-4_6-branch/gcc/cp/cp-gimplify.c:1023
1023 cp_walk_tree (&BIND_EXPR_BODY (stmt),
(gdb)
#7700 0x00f00a6d in walk_tree_1 (tp=0x748ba630,
func=0x7985ba , data=0x7fffd4c0, pset=0x0,
lh=0x731537 )
at /space/rguenther/src/svn/gcc-4_6-branch/gcc/tree.c:10386
10386 WALK_SUBTREE (*tsi_stmt_ptr (i));
(gdb)
#7699 0x00f022f9 in walk_tree_1 (tp=0x759c38f8,
func=0x7985ba , data=0x7fffd4c0, pset=0x0,
lh=0x731537 )
at /space/rguenther/src/svn/gcc-4_6-branch/gcc/tree.c:10529
10529 /* Go through the subtrees. We need to do this in forward
order so
(gdb)
#7698 0x00f00a6d in walk_tree_1 (tp=0x77ff2178,
func=0x7985ba , data=0x7fffd4c0, pset=0x0,
lh=0x731537 )
at /space/rguenther/src/svn/gcc-4_6-branch/gcc/tree.c:10386
10386 WALK_SUBTREE (*tsi_stmt_ptr (i));
they are all TRY_CATCH_EXPRs. Gimplification will probably run into
similar recursion issues.
I can't reproduce the isssue with an unlimited stack with release
checking compiled FSF 4.6.1 or 4.5.3 releases.
For some reason the C++ compiler nests constructing the members:
;; Function Container::Container() (null)
;; enabled by -tree-original
{
;
try
{
;
try
{
;
try
{
Jason, can't we do something more optimal here?
[Bug tree-optimization/49760] vectorization inhibited if indices are references
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49760
--- Comment #2 from vincenzo Innocente
2011-07-18 09:39:49 UTC ---
Thanks for the detailed explanation.
In the real life code, "out" is filled calling "foo" multiple times (a sort of
nested loop), "k" was used to track the current size of it.
It is true that in this particular case I can just k+=N; at the end of the
loop.
The issue is more with
"for (int i=0; i!=in.size; ++i)" as in foo2
because of
"not vectorized: number of iterations cannot be computed"
while copying it locally in N works.
b.t.w.
void foo(SoA const & __restrict__ in, SoB & __restrict__ out, int &
__restrict__ k) {
int N=in.size;
for (int i=0; i!=N; ++i) {
out.b[k] = in.c[i]+in.b[i];
out.a[k] = in.a[i];
++k;
}
}
does not vectorize either
[Bug tree-optimization/49760] vectorization inhibited if indices are references
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49760
--- Comment #3 from rguenther at suse dot de
2011-07-18 09:44:23 UTC ---
On Mon, 18 Jul 2011, vincenzo.innocente at cern dot ch wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49760
>
> --- Comment #2 from vincenzo Innocente
> 2011-07-18 09:39:49 UTC ---
> Thanks for the detailed explanation.
> In the real life code, "out" is filled calling "foo" multiple times (a sort
> of
> nested loop), "k" was used to track the current size of it.
> It is true that in this particular case I can just k+=N; at the end of the
> loop.
>
> The issue is more with
> "for (int i=0; i!=in.size; ++i)" as in foo2
> because of
> "not vectorized: number of iterations cannot be computed"
> while copying it locally in N works.
Probably the same issue - the out array may point to in.size and
thus clobber it (yes - only if the loop runs exactly once, but we
don't use that information yet).
>
> b.t.w.
> void foo(SoA const & __restrict__ in, SoB & __restrict__ out, int &
> __restrict__ k) {
> int N=in.size;
> for (int i=0; i!=N; ++i) {
> out.b[k] = in.c[i]+in.b[i];
> out.a[k] = in.a[i];
> ++k;
> }
> }
> does not vectorize either
I suppose we can't vectorize the k iterator (or rather we don't
apply store motion). You should avoid using induction variables
that live in memory.
[Bug bootstrap/49769] [4.7 regression] configuration mismatch -- extra parts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49769 Rainer Orth changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-07/msg01242.htm ||l --- Comment #3 from Rainer Orth 2011-07-18 09:55:45 UTC --- I've posted a patch, but nobody cared to comment or even approve. Rainer
[Bug tree-optimization/49760] vectorization inhibited if indices are references
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49760 --- Comment #4 from vincenzo Innocente 2011-07-18 10:07:10 UTC --- Fair enough. I think I can persuade developers to use only local variables as induction variable. More difficult will be to make them to copy also all other variables stored in memory (see PR49773).
[Bug middle-end/49029] [4.6/4.7 Regression] ICE in simplify_subreg, at simplify-rtx.c:5266
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49029 Anitha Boyapati changed: What|Removed |Added CC||anitha.boyapati at atmel ||dot com --- Comment #7 from Anitha Boyapati 2011-07-18 10:17:13 UTC --- For 4.6.1 release, the corresponding testcase from regression fails for AVR target... /home/anitha/patch-upgrade/gcc-4.6.1/gcc/testsuite/gcc.c-torture/compile/pr49029.c:2:8: error: width of 'g' exceeds its type compiler exited with status 1 FAIL: gcc.c-torture/compile/pr49029.c -O0 (test for excess errors) Compiler specs -- Using built-in specs. COLLECT_GCC=avr-gcc COLLECT_LTO_WRAPPER=/home/anitha/install/libexec/gcc/avr/4.6.1/lto-wrapper Target: avr Configured with: ../configure --prefix=/home/anitha/install --target=avr --with-gmp=/proj/install/gmp-4.3.2/ --with-mpfr=/proj/install/mpfr-2.4.2/ --with-mpc=/proj/install/mpc-0.8.2/ --enable-languages=c,c++ --disable-libssp --disable-nls --with-dwarf2 Thread model: single gcc version 4.6.1 (GCC)
[Bug tree-optimization/49140] [4.6 regression] wrong code with -O2 and -O3, not with -O3 -no-inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49140 --- Comment #7 from Matthias Klose 2011-07-18 10:19:28 UTC --- the pari tests still fail
[Bug tree-optimization/49770] [4.7 Regression] wrong code with -fno-tree-forwprop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49770 --- Comment #4 from Richard Guenther 2011-07-18 10:46:28 UTC --- Ok, it's sth I worried about when doing the patch. Namely: /* Make sure to use a valueized reference ... */ if (!ao_ref_init_from_vn_reference (&r, vr1.set, vr1.type, vr1.operands)) ao_ref_init (&r, op); else /* ... but also preserve a full reference tree for advanced TBAA. */ r.ref = op; preserving op as r.ref is playing foul of the aliasing code which assumes that the base in r.ref is the one that corresponds to the r.base, r.offset pair. That is not the case when we valueized &MEM[&b]._M_finish into MEM[D.1719_29]._M_cur. Not doing the above loses some TBAA related disambiguations. I'm thinking about a good solution.
[Bug c++/49776] New: [C++0x]ICE in build_data_member_initialization, at cp/semantics.c:5499
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49776
Summary: [C++0x]ICE in build_data_member_initialization, at
cp/semantics.c:5499
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sscr...@gmail.com
Codes:
struct s
{
int i[1];
template
constexpr s(Types... args)
: i{args...}
{}
};
int main()
{
s test = nullptr;
}
Compiler messages:
$ g++4.7 -std=c++0x -Wall -Wextra -pedantic a.cpp
a.cpp: In constructor 'constexpr s::s(Types ...) [with Types =
{std::nullptr_t}]':
a.cpp:13:11: required from here
a.cpp:7:14: error: cannot convert 'std::nullptr_t' to 'int' in initialization
a.cpp:8:3: internal compiler error: in build_data_member_initialization, at
cp/semantics.c:5499
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Info:
$ g++4.7 -v
Built by Equation Solution .
Using built-in specs.
COLLECT_GCC=C:\cygwin\home\RiSK\misc\gcc4.7\bin\g++.exe
COLLECT_LTO_WRAPPER=c:/cygwin/home/risk/misc/gcc4.7/bin/../libexec/gcc/i686-pc-mingw32/4.7.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-4.7-20110716-mingw/configure --host=i686-pc-mingw32
--build=x86_64-unknown-linux-gnu --target
=i686-pc-mingw32
--prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.7-20110716
--with-gcc --with-gnu
-as --with-gnu-ld --with-host-libstdcxx='-lstdc++ -lsupc++ -lm'
--with-ppl=/home/gfortran/gcc-home/binary/mingw32/nat
ive/x86_32/ppl
--with-cloog=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/cloog
--with-gmp=/home/gfortran/gcc-
home/binary/mingw32/native/x86_32/gmp
--with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr --with-mp
c=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpc
--with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cros
s/x86_32/gcc/4.7-20110716 --disable-shared --disable-nls --disable-tls
--disable-win32-registry --enable-libquadmath-
support --enable-libquadmath --enable-languages=c,c++,fortran --enable-libgomp
--enable-threads=win32 --enable-lto --
enable-static --enable-shared=lto-plugin --enable-plugins --enable-ld=yes
--enable-cloog-backend=ppl
Thread model: win32
gcc version 4.7.0 20110716 (experimental) (GCC)
[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49541 --- Comment #16 from Rainer Orth 2011-07-18 12:09:22 UTC --- Author: ro Date: Mon Jul 18 12:09:18 2011 New Revision: 176393 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176393 Log: PR target/49541 * testsuite/lib/libgomp.exp (libgomp_init): Don't add -lgomp to ldflags. Modified: trunk/libgomp/ChangeLog trunk/libgomp/testsuite/lib/libgomp.exp
[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49541 --- Comment #17 from Rainer Orth 2011-07-18 12:10:39 UTC --- Author: ro Date: Mon Jul 18 12:10:34 2011 New Revision: 176394 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176394 Log: PR target/49541 * testsuite/lib/libgomp.exp (libgomp_init): Don't add -lgomp to ldflags. Modified: branches/gcc-4_6-branch/libgomp/ChangeLog branches/gcc-4_6-branch/libgomp/testsuite/lib/libgomp.exp
[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49541 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #18 from Rainer Orth 2011-07-18 12:14:44 UTC --- Fixed for 4.6.2, 4.7.0.
[Bug tree-optimization/49768] [4.6/4.7 Regression] C99 style union initializations does not work as expected with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49768 --- Comment #6 from Jakub Jelinek 2011-07-18 12:47:36 UTC --- Created attachment 24787 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24787 gcc47-pr49768.patch The easier fix attached. The more complicated would probably mean if we see possible overlaps keeping recurding on all overlapping feelds and if the result from them is INTEGER_CST, shift, mask and or them together.
[Bug target/47744] [x32] ICE: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744 --- Comment #29 from H.J. Lu 2011-07-18 13:55:05 UTC --- (In reply to comment #28) > Here is my latest proposed patch: > > --cut here-- > Index: i386.c > === > --- i386.c(revision 176386) > +++ i386.c(working copy) > @@ -11149,8 +11149,13 @@ > return 0; >break; > > +case SUBREG: > + /* Allow only subregs of DImode hard regs in PLUS chains. */ > + if (!register_no_elim_operand (SUBREG_REG (op), DImode)) > +return 0; > + /* FALLTHRU */ > + > case REG: > -case SUBREG: >if (!base) > base = op; >else if (!index) > --cut here-- > > The patch will also benefit x86_64 and x86_32. The patch allows only SUBREGs > with DImode non-eliminable hard register. This way paradoxical subregs are > avoided, and at the same time, the patch makes sure that PLUS RTX in wider > mode > won't enter the address RTX (via combine pass, register elimination in reload, > etc). This patch increases bootstrap time from 5173.47user 394.52system 14:59.75elapsed 618%CPU (0avgtext+0avgdata 362556maxresident)k to 7742.94user 475.20system 19:19.84elapsed 708%CPU (0avgtext+0avgdata 362556maxresident)k
[Bug target/47744] [x32] ICE: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744 --- Comment #30 from Uros Bizjak 2011-07-18 14:00:43 UTC --- (In reply to comment #29) > This patch increases bootstrap time from On which target?
[Bug target/47744] [x32] ICE: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744 --- Comment #31 from H.J. Lu 2011-07-18 14:04:13 UTC --- (In reply to comment #30) > (In reply to comment #29) > > > This patch increases bootstrap time from > > On which target? I used --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-languages=c,c++,fortran,objc --prefix=/usr/gcc-4.7.0-x32 --with-local-prefix=/usr/local --enable-gnu-indirect-function --with-multilib-list=m32,m64,mx32 --enable-cloog-backend=isl --with-ppl-include=/opt/gnu/include --with-ppl-lib=/opt/gnu/lib64 --with-cloog-include=/opt/gnu/include --with-cloog-lib=/opt/gnu/lib64 --with-fpmath=sse But I was running SPEC CPU at the same time. I will re-time it.
[Bug tree-optimization/49773] use of class data members prevent vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49773 --- Comment #1 from vincenzo Innocente 2011-07-18 14:11:11 UTC --- I just upgraded to c++ -v Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin10.8.0/4.7.0/lto-wrapper Target: x86_64-apple-darwin10.8.0 Configured with: ./configure --enable-languages=c,c++,fortran --enable-lto --with-build-config=bootstrap-lto CFLAGS='-O2 -ftree-vectorize -fPIC' CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden' Thread model: posix gcc version 4.7.0 20110716 (experimental) (GCC) and it seem to vectorize fine… was stil not ok in gcc version 4.7.0 20110702 (experimental) (GCC) it still pretends to check for test/vectClass.cpp:11: note: Detected interleaving this_9(D)->a and this_9(D)->b test/vectClass.cpp:11: note: versioning for alias required: can't determine dependence between this_9(D)->a and *D.1537_8 test/vectClass.cpp:11: note: mark for run-time aliasing test between this_9(D)->a and *D.1537_8 test/vectClass.cpp:11: note: versioning for alias required: can't determine dependence between this_9(D)->b and *D.1537_8 test/vectClass.cpp:11: note: mark for run-time aliasing test between this_9(D)->b and *D.1537_8 I hope it will be addressed in PR49774
[Bug tree-optimization/49771] [4.7 Regression] wrong code with -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49771 --- Comment #2 from Jakub Jelinek 2011-07-18 14:12:49 UTC --- That commit looks bogus, the change it made is: # ivtmp.37_45 = PHI vect_pa.7_44 = (vector(4) int *) ivtmp.37_45; - D.2731_1 = vect_pa.7_44 < &a; - D.2733_14 = vect_pa.7_44 > &a[1000]; + D.2731_1 = vect_pa.7_44 <= &a; + D.2733_14 = vect_pa.7_44 >= &a[1000]; D.2734_23 = D.2733_14 | D.2731_1; if (D.2734_23 != 0) vect_pa.7_44 is the pointer that goes from &a[0] to &a[999]. While in this case it is fine to change the second > to >=, changing the first one is of course wrong, because in the first iteration it will overlap, yet this test will say that they do not. What is weird is that segment_length_a in vect_create_cond_for_alias_checks is 0 instead of 4 (sizeof (int)) I'd expect, while segment_length_b is the expected 4000. Apparently DR_STEP in the first case is 0. I wonder whether the change of the comparison should only be done if one segment length is empty (and thus clearly doesn't include all bytes of the read/store), or something similar.
[Bug c++/49756] g++ ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49756 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | --- Comment #2 from Jason Merrill 2011-07-18 14:17:34 UTC --- (In reply to comment #1) > I can't reproduce the isssue with an unlimited stack with release > checking compiled FSF 4.6.1 or 4.5.3 releases. > > For some reason the C++ compiler nests constructing the members: > Jason, can't we do something more optimal here? The nesting is inherent in the language; after the initialization of an object which needs a cleanup, anything that throws needs to destroy that object. So each variable implies a TRY_FINALLY_EXPR to follow it. For walk_tree we could probably do tail recursion into the try operand, but that won't work for gimplification since we need to process the try before the finally. I think cc1plus should use setrlimit to raise the stack size limit.
[Bug libmudflap/49550] Many libmudflap tests fail on Solaris 11/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49550 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-06/msg02376.htm ||l Resolution||FIXED AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 --- Comment #3 from Rainer Orth 2011-07-18 14:23:29 UTC --- Fixed for 4.7.0.
[Bug c++/49756] g++ ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49756 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek 2011-07-18 14:24:56 UTC --- More probably the gcc/g++ driver already, because inside of tbe main of a program it might be too late to increase the stack limits - if something is already mmapped right below the old smaller stack the increase won't be effective. I guess increasing the RLIMIT_STACK in the driver to MIN (hard_limit, MAX (soft_limit, 30MB)) wouldn't be a bad idea.
[Bug boehm-gc/49381] Unresolved symbols in libgcjgc.a when linking gctest
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49381 --- Comment #1 from Rainer Orth 2011-07-18 14:30:23 UTC --- Author: ro Date: Mon Jul 18 14:30:14 2011 New Revision: 176401 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176401 Log: PR boehm-gc/49381 Backport from mainline: 2011-01-31 Rainer Orth * configure.ac (*-*-solaris2*): Add -lrt to THREADLIBS. * configure: Regenerate. Modified: branches/gcc-4_5-branch/boehm-gc/ChangeLog branches/gcc-4_5-branch/boehm-gc/configure branches/gcc-4_5-branch/boehm-gc/configure.ac
[Bug c++/49777] New: for c++ code, without -g option, cannot generate PIC *.so library.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49777
Summary: for c++ code, without -g option, cannot generate PIC
*.so library.
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hekun_he...@163.com
test.cc:
int f_b ()
{
return 1;
}
int f_a () throw ()
{
return f_b();
}
without -g:
$ armv7a-linux-gnueabi-gcc -S -fPIC -DPIC test.cc -o test.s
$ armv7a-linux-gnueabi-gcc -c test.s -o test.o
$ armv7a-linux-gnueabi-gcc -shared test.o -o test.so
$ armv7a-linux-gnueabi-readelf -d test.so | grep TEXTREL
0x0016 (TEXTREL)0x0
with -g:
$ armv7a-linux-gnueabi-gcc -S -fPIC -DPIC test.cc -o test-g.s -g
$ armv7a-linux-gnueabi-gcc -c test-g.s -o test.o
$ armv7a-linux-gnueabi-gcc -shared test.o -o test.so
$ armv7a-linux-gnueabi-readelf -d test.so | grep TEXTREL
nothing output.
the content of test.s:
1 .arch armv7-a
2 .eabi_attribute 27, 3
3 .fpu vfpv3-d16
4 .eabi_attribute 20, 1
5 .eabi_attribute 21, 1
6 .eabi_attribute 23, 3
7 .eabi_attribute 24, 1
8 .eabi_attribute 25, 1
9 .eabi_attribute 26, 2
10 .eabi_attribute 30, 6
11 .eabi_attribute 18, 4
12 .file "test.cc"
13 .text
14 .align 2
15 .global _Z3f_bv
16 .type _Z3f_bv, %function
17 _Z3f_bv:
18 .fnstart
19 .LFB0:
20 .cfi_startproc
21 @ args = 0, pretend = 0, frame = 0
22 @ frame_needed = 1, uses_anonymous_args = 0
23 @ link register save eliminated.
24 str fp, [sp, #-4]!
25 .save {fp}
26 .cfi_def_cfa_offset 4
27 .setfp fp, sp, #0
28 add fp, sp, #0
29 .cfi_offset 11, -4
30 .cfi_def_cfa_register 11
31 mov r3, #1
32 mov r0, r3
33 add sp, fp, #0
34 ldmfd sp!, {fp}
35 bx lr
36 .cfi_endproc
37 .LFE0:
38 .fnend
39 .size _Z3f_bv, .-_Z3f_bv
40 .align 2
41 .global _Z3f_av
42 .type _Z3f_av, %function
43 _Z3f_av:
44 .fnstart
45 .LFB1:
46 .cfi_startproc
47 .cfi_personality 0x0,__gxx_personality_v0
48 .cfi_lsda 0x0,.LLSDA1
49 @ args = 0, pretend = 0, frame = 0
50 @ frame_needed = 1, uses_anonymous_args = 0
51 stmfd sp!, {fp, lr}
52 .save {fp, lr}
53 .cfi_def_cfa_offset 8
54 .setfp fp, sp, #4
55 add fp, sp, #4
56 .cfi_offset 14, -4
57 .cfi_offset 11, -8
58 .cfi_def_cfa 11, 4
59 .LEHB0:
60 bl _Z3f_bv(PLT)
61 .LEHE0:
62 mov r3, r0
63 mov r0, r3
64 ldmfd sp!, {fp, pc}
65 .L5:
66 mov r3, r0
67 mov r2, r1
68 cmn r2, #1
69 beq .L4
70 .LEHB1:
71 bl __cxa_end_cleanup(PLT)
72 .L4:
73 mov r0, r3
74 bl __cxa_call_unexpected(PLT)
75 .LEHE1:
76 .cfi_endproc
77 .LFE1:
78 .global __gxx_personality_v0
79 .personality__gxx_personality_v0
80 .handlerdata
81 .align 2
82 .LLSDA1:
83 .byte 0xff
84 .byte 0x0
85 .uleb128 .LLSDATT1-.LLSDATTD1
86 .LLSDATTD1:
87 .byte 0x1
88 .uleb128 .LLSDACSE1-.LLSDACSB1
89 .LLSDACSB1:
90 .uleb128 .LEHB0-.LFB1
91 .uleb128 .LEHE0-.LEHB0
92 .uleb128 .L5-.LFB1
93 .uleb128 0x1
94 .uleb128 .LEHB1-.LFB1
95 .uleb128 .LEHE1-.LEHB1
96 .uleb128 0x0
97 .uleb128 0x0
98 .LLSDACSE1:
99 .byte 0x7f
100 .byte 0x0
101 .align 2
102 .LLSDATT1:
103 .word 0
104 .fnend
105 .size _Z3f_av, .-_Z3f_av
106 .ident "GCC: (GNU) 4.5.1"
107 .section.note.GNU-stack,"",%progbits
the content of test-g.s:
1 .arch armv7-a
2 .eabi_attribute 27, 3
3 .fpu vfpv3-d16
4 .eabi_attribute 20, 1
5 .eabi_attribute 21, 1
6 .eabi_attribute 23, 3
7 .eabi_attribute 24, 1
8 .eabi_attribute 25, 1
9 .eabi_attribute 26, 2
10 .eabi_attribute 30, 6
11 .eabi
[Bug middle-end/49545] [4.6 Regression] New C++ test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49545 --- Comment #10 from Ulrich Weigand 2011-07-18 14:35:44 UTC --- (In reply to comment #9) > Can you check what patch caused it on the 4.6 branch? It is this one: http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00431.html 2011-07-11 Martin Jambor PR tree-optimization/49094 * tree-sra.c (tree_non_mode_aligned_mem_p): New function. (build_accesses_from_assign): Use it. > I suppose "fixed" on the trunk. Yes, that's correct.
[Bug boehm-gc/49381] Unresolved symbols in libgcjgc.a when linking gctest
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49381 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-07/msg01403.htm ||l CC||ro at gcc dot gnu.org Resolution||FIXED AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.5.4 --- Comment #2 from Rainer Orth 2011-07-18 14:36:27 UTC --- Fixed for 4.5.4. Rainer
[Bug target/47744] [x32] ICE: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744 --- Comment #32 from H.J. Lu 2011-07-18 14:54:31 UTC --- (In reply to comment #31) > > But I was running SPEC CPU at the same time. I will re-time it. Is isn't too bad: 5182.95user 396.13system 15:32.41elapsed 598%CPU (0avgtext+0avgdata 362556maxresident)k It passed SPEC CPU 2K and I am running SPEC CPU 2006 now. Can you check in your patch? Thanks.
[Bug tree-optimization/49170] [4.7 regression] Several libstdc++ tests fail to link on Solaris 8/9: cexp missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49170 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #7 from Rainer Orth 2011-07-18 15:16:07 UTC --- Fixed.
[Bug c++/49756] g++ ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49756 --- Comment #4 from Jason Merrill 2011-07-18 15:22:11 UTC --- For this testcase, even 30MB isn't enough, but 40MiB is, so I think I'll round up to 64MB. I think it's probably best to raise the limit in both places to avoid confusion when invoking cc1plus directly.
[Bug go/48223] gob/check fails on Solaris 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48223 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Rainer Orth 2011-07-18 15:23:15 UTC --- Failure is gone after 20110701.
[Bug driver/46944] gcc should accept -fuse-linker-plugin only if linker handles -plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46944 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from Rainer Orth 2011-07-18 15:36:31 UTC --- Long fixed.
[Bug target/46023] gcc.dg/vect/pr43430-2.c FAILs on Solaris 8 and 9/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46023 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Rainer Orth 2011-07-18 15:38:18 UTC --- Fixed since 20101123.
[Bug tree-optimization/46021] 3 tree-ssa tests XPASS almost everywhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46021 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #8 from Rainer Orth 2011-07-18 15:41:21 UTC --- Long fixed.
[Bug tree-optimization/49771] [4.7 Regression] wrong code with -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49771
Ira Rosen changed:
What|Removed |Added
CC||irar at il dot ibm.com
--- Comment #3 from Ira Rosen 2011-07-18 15:55:49 UTC
---
(In reply to comment #2)
> That commit looks bogus, the change it made is:
># ivtmp.37_45 = PHI
>vect_pa.7_44 = (vector(4) int *) ivtmp.37_45;
> - D.2731_1 = vect_pa.7_44 < &a;
> - D.2733_14 = vect_pa.7_44 > &a[1000];
> + D.2731_1 = vect_pa.7_44 <= &a;
> + D.2733_14 = vect_pa.7_44 >= &a[1000];
>D.2734_23 = D.2733_14 | D.2731_1;
>if (D.2734_23 != 0)
>
> vect_pa.7_44 is the pointer that goes from &a[0] to &a[999]. While in this
> case it is fine to change the second > to >=, changing the first one is of
> course wrong, because in the first iteration it will overlap, yet this test
> will say that they do not.
> What is weird is that segment_length_a in vect_create_cond_for_alias_checks
> is 0 instead of 4 (sizeof (int)) I'd expect, while segment_length_b is the
> expected 4000. Apparently DR_STEP in the first case is 0.
The step of a[i] is indeed 0 in the j loop.
> I wonder whether
> the change of the comparison should only be done if one segment length is
> empty
> (and thus clearly doesn't include all bytes of the read/store), or something
> similar.
We can create a segment of length sizeof(type) for the zero step case:
Index: tree-vect-loop-manip.c
===
--- tree-vect-loop-manip.c (revision 176389)
+++ tree-vect-loop-manip.c (working copy)
@@ -2356,9 +2356,14 @@ static tree
vect_vfa_segment_size (struct data_reference *dr, tree length_factor)
{
tree segment_length;
- segment_length = size_binop (MULT_EXPR,
- fold_convert (sizetype, DR_STEP (dr)),
- fold_convert (sizetype, length_factor));
+
+ if (!compare_tree_int (DR_STEP (dr), 0))
+segment_length = TYPE_SIZE_UNIT (TREE_TYPE (DR_REF (dr)));
+ else
+segment_length = size_binop (MULT_EXPR,
+fold_convert (sizetype, DR_STEP (dr)),
+fold_convert (sizetype, length_factor));
+
if (vect_supportable_dr_alignment (dr, false)
== dr_explicit_realign_optimized)
{
(tested only with the vectorizer testsuite).
Ira
[Bug libstdc++/48430] std::hash partial specialization for std::unique_ptr and std::shared_ptr are using unary_function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48430 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.18 16:01:24 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini 2011-07-18 16:01:24 UTC --- Jon is of course right, in terms of conformance. But I think we can start using __hash_base there too, just for consistency. Will do momentarily.
[Bug driver/45508] Does adding configure-options for specs-hardcoding make sense?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45508 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.18 16:06:22 CC||ro at gcc dot gnu.org Component|middle-end |driver Ever Confirmed|0 |1 --- Comment #8 from Rainer Orth 2011-07-18 16:06:22 UTC --- I think handling this via specs is the wrong (read: far too complicated) approach. I agree that gcc/g++/... not adding needed RPATHs to its runtime libraries is a major nuissance for every site with more than a single system and a central installation of gcc and it has bothered me for a long time. I'm (slowly) working towards a generic approach to solve this problem, maybe I'll have something ready for gcc 4.7.0.
[Bug libstdc++/48430] std::hash partial specialization for std::unique_ptr and std::shared_ptr are using unary_function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48430 --- Comment #3 from paolo at gcc dot gnu.org 2011-07-18 16:07:34 UTC --- Author: paolo Date: Mon Jul 18 16:07:24 2011 New Revision: 176405 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176405 Log: 2011-07-18 Paolo Carlini PR libstdc++/48430 * include/bits/shared_ptr.h (struct hash>): Use __hash_base. * include/bits/unique_ptr.h (struct hash>): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/shared_ptr.h trunk/libstdc++-v3/include/bits/unique_ptr.h
[Bug libstdc++/48430] std::hash partial specialization for std::unique_ptr and std::shared_ptr are using unary_function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48430 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Paolo Carlini 2011-07-18 16:08:38 UTC --- Done.
[Bug bootstrap/44642] bootstrap fails to build libgcc when gold is built (at least on Solaris_x86)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44642 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #2 from Rainer Orth 2011-07-18 16:12:02 UTC --- Until very recently, gold was useless on Solaris. Several bugs have now been fixed for PR gold/12525, at least enough that (with a few workarounds) you can bootstrap gcc with it. But unfortunately, testsuite results are terrible. Until PRs gold/12987, gold/12990, and gold/12991 are fixed, I'd stay away from it.
[Bug debug/44171] gcc -gdwarf-2 -dA unconditionally emits .ascii
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44171 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #1 from Rainer Orth 2011-07-18 16:15:24 UTC --- While this is an issue with very old versions of Solaris 8 (and 9?) as, no fix is needed with the versions I currently use, so this is probably not worth bothering with. Rainer
[Bug libgomp/44093] Linking libgomp.so fails on Solaris 9/x86 with Sun as: relocations remain
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44093 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Rainer Orth 2011-07-18 16:17:18 UTC --- Long fixed.
[Bug target/43324] core dump on throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43324 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #4 from Rainer Orth 2011-07-18 16:18:54 UTC --- No feedback in more than a year and not reproducible for me, so closing. Rainer
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Known to fail|| --- Comment #15 from Rainer Orth 2011-07-18 16:22:34 UTC --- Fixed for 4.5, no feedback in more than a year, so I assume no backport is necessary. Rainer
[Bug debug/42278] [4.4 Regression] incorrect dwarf data gcc-4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42278 Rainer Orth changed: What|Removed |Added Status|NEW |RESOLVED Known to work|| Resolution||FIXED Known to fail|| --- Comment #5 from Rainer Orth 2011-07-18 16:23:26 UTC --- Long fixed.
[Bug libstdc++/49778] New: Can't take pointer to std::make_pair in c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49778
Summary: Can't take pointer to std::make_pair in c++0x
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bugzilla.gcc.gnu@sklep.czarko.net
When g++ is using c++0x standard the following code doesn't compile:
#include
#include
#include
#include
#include
int main()
{
std::vector< int > inputs1 = { 1, 2, 3 };
std::vector< int > inputs2 = { 2, 5, 9 };
std::map< int, int > tmp;
std::transform(
inputs1.begin(),
inputs1.end(),
inputs2.begin(),
std::inserter( tmp, tmp.begin() ),
&std::make_pair< int, int >
);
for ( const std::pair< int, int > & i : tmp )
{
std::cout << "( " << i.first << " -> " << i.second << " )\n";
}
return 0;
}
The error is:
In file included from
/usr/lib/gcc/i686-redhat-linux/4.6.0/../../../../include/c++/4.6.0/algorithm:63:0,
from a.cpp:1:
/usr/lib/gcc/i686-redhat-linux/4.6.0/../../../../include/c++/4.6.0/bits/stl_algo.h:
In function ‘_OIter std::transform(_IIter1, _IIter1, _IIter2, _OIter,
_BinaryOperation) [with _IIter1 = __gnu_cxx::__normal_iterator >, _IIter2 = __gnu_cxx::__normal_iterator >, _OIter = std::insert_iterator >,
_BinaryOperation = std::pair (*)(int&&, int&&)]’:
a.cpp:19:9: instantiated from here
/usr/lib/gcc/i686-redhat-linux/4.6.0/../../../../include/c++/4.6.0/bits/stl_algo.h:4843:2:
error: invalid initialization of reference of type ‘int&&’ from expression of
type ‘int’
This can be fixed with a custom replacement for std::make_pair and using it
instead:
template < typename T1, typename T2 >
const std::pair< T1, T2 > MakePair( const T1 t1, const T2 t2 )
{
return std::pair< T1, T2 >( t1, t2 );
}
Note that this is similar to bug 43785 but I don't see here any way of avoiding
explicit template arguments.
[Bug target/41810] Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Rainer Orth 2011-07-18 16:25:13 UTC --- Long fixed.
[Bug target/40483] gcc 4.x needs to utilize better COMDAT mechanism under Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40483 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Rainer Orth 2011-07-18 16:27:06 UTC --- Fixed for 4.7.0.
[Bug driver/40227] Solaris standard link libraries missing /lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40227 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-06/msg01514.htm ||l Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Rainer Orth 2011-07-18 16:29:20 UTC --- Fixed for 4.7.0.
[Bug target/40183] g++.dg/tls/static-1.C, execution abort
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40183 Rainer Orth changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #5 from Rainer Orth 2011-07-18 16:30:52 UTC --- Fixed for 4.7.0.
[Bug bootstrap/39810] [melt] - revision 146327 - compiler-probe.c:106: undefined reference to `unlikely'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39810 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ro at gcc dot gnu.org Resolution||FIXED --- Comment #4 from Rainer Orth 2011-07-18 16:32:30 UTC --- Seems long fixed.
[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #17 from Ramana Radhakrishnan
2011-07-18 16:35:22 UTC ---
(In reply to comment #16)
> (In reply to comment #15)
> > The machine-dependent reorg pass does something unexpected:
> >
> > (insn 30 18 14 3 (set (reg/f:SI 11 fp)
> > (plus:SI (reg/f:SI 11 fp)
> > (const_int 36 [0x24]))) 4 {*arm_addsi3}
> > (nil))
> >
> > (insn 14 30 16 3 (use (reg/f:SI 11 fp)) -1
> > (nil))
> >
> > (insn 16 14 24 3 (unspec_volatile [
> > (const_int 0 [0])
> > ] VUNSPEC_BLOCKAGE) 252 {blockage}
> > (nil))
> >
> > (insn 24 16 27 3 (set (reg/i:SI 0 r0)
> > (mem/c:SI (plus:SI (reg/f:SI 11 fp)
> > (const_int -56 [0xffc8])) [6 %sfp+-20 S4 A32]))
> > comp-goto-2.c:26 176 {*arm_movsi_insn}
> > (nil))
> >
> > is reordered into:
> >
> > (insn 14 18 16 (use (reg/f:SI 11 fp)) -1
> > (nil))
> >
> > (insn 16 14 24 (unspec_volatile [
> > (const_int 0 [0])
> > ] VUNSPEC_BLOCKAGE) 252 {blockage}
> > (nil))
> >
> > (insn 24 16 30 (set (reg/i:SI 0 r0)
> > (mem/c:SI (plus:SI (reg/f:SI 11 fp)
> > (const_int -20 [0xffec])) [6 %sfp+-20 S4 A32]))
> > comp-goto-2.c:26 176 {*arm_movsi_insn}
> > (nil))
> >
> > (insn 30 24 27 (set (reg/f:SI 11 fp)
> > (plus:SI (reg/f:SI 11 fp)
> > (const_int 36 [0x24]))) 4 {*arm_addsi3}
> > (nil))
> >
> > despite the blockage.
>
> Hmmm I'm not sure I see this - what's the configure and arch. specific flags
> you used just in case ?
>
Just in case - I am using -march=armv5t -marm -Os on the command line.
Ramana
>
> cheers
> Ramana
[Bug testsuite/39215] Running Testsuite with Multilib Flags exposes many errors in Testsuite (and gcc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39215 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Rainer Orth 2011-07-18 16:34:28 UTC --- Solaris/x86 testresults are practically clean these days, for both multilibs and both 32-bit default and 64-bit default configurations.
[Bug target/39186] Configury incorrect for 64-bit Targets on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ro at gcc dot gnu.org Resolution||DUPLICATE Target Milestone|--- |4.7.0 --- Comment #12 from Rainer Orth 2011-07-18 16:36:37 UTC --- gcc 4.7.0 will have a x86_64-pc-solaris2.1? configuration for real. Rainer *** This bug has been marked as a duplicate of bug 39150 ***
[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150 --- Comment #24 from Rainer Orth 2011-07-18 16:36:37 UTC --- *** Bug 39186 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #16 from Ramana Radhakrishnan
2011-07-18 16:31:12 UTC ---
(In reply to comment #15)
> The machine-dependent reorg pass does something unexpected:
>
> (insn 30 18 14 3 (set (reg/f:SI 11 fp)
> (plus:SI (reg/f:SI 11 fp)
> (const_int 36 [0x24]))) 4 {*arm_addsi3}
> (nil))
>
> (insn 14 30 16 3 (use (reg/f:SI 11 fp)) -1
> (nil))
>
> (insn 16 14 24 3 (unspec_volatile [
> (const_int 0 [0])
> ] VUNSPEC_BLOCKAGE) 252 {blockage}
> (nil))
>
> (insn 24 16 27 3 (set (reg/i:SI 0 r0)
> (mem/c:SI (plus:SI (reg/f:SI 11 fp)
> (const_int -56 [0xffc8])) [6 %sfp+-20 S4 A32]))
> comp-goto-2.c:26 176 {*arm_movsi_insn}
> (nil))
>
> is reordered into:
>
> (insn 14 18 16 (use (reg/f:SI 11 fp)) -1
> (nil))
>
> (insn 16 14 24 (unspec_volatile [
> (const_int 0 [0])
> ] VUNSPEC_BLOCKAGE) 252 {blockage}
> (nil))
>
> (insn 24 16 30 (set (reg/i:SI 0 r0)
> (mem/c:SI (plus:SI (reg/f:SI 11 fp)
> (const_int -20 [0xffec])) [6 %sfp+-20 S4 A32]))
> comp-goto-2.c:26 176 {*arm_movsi_insn}
> (nil))
>
> (insn 30 24 27 (set (reg/f:SI 11 fp)
> (plus:SI (reg/f:SI 11 fp)
> (const_int 36 [0x24]))) 4 {*arm_addsi3}
> (nil))
>
> despite the blockage.
Hmmm I'm not sure I see this - what's the configure and arch. specific flags
you used just in case ?
cheers
Ramana
[Bug bootstrap/49769] [4.7 regression] configuration mismatch -- extra parts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49769 --- Comment #4 from Rainer Orth 2011-07-18 16:42:00 UTC --- Author: ro Date: Mon Jul 18 16:41:55 2011 New Revision: 176406 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176406 Log: PR bootstrap/49769 * config.gcc (alpha*-*-linux*): Add crtfastmath.o to extra_parts. (alpha*-*-freebsd*): Likewise. (i[34567]86-*-linux*, i[34567]86-*-kfreebsd*-gnu, i[34567]86-*-knetbsd*-gnu, i[34567]86-*-gnu*, i[34567]86-*-kopensolaris*-gnu): Add crtprec32.o, crtprec64.o, crtprec80.o, crtfastmath.o to extra_parts for all targets. (ia64*-*-elf*): Remove extra_parts. (sparc-*-linux*): Add crtfastmath.o to extra_parts. (sparc64-*-linux*): Likewise. (sparc64-*-freebsd*): Likewise. Revert: * config.gcc (ia64*-*-freebsd*): Remove crtfastmath.o from extra_parts. (ia64*-*-linux*): Likewise. (mips64*-*-linux*): Likewise. (mips*-*-linux*): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc
[Bug bootstrap/49769] [4.7 regression] configuration mismatch -- extra parts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49769 Rainer Orth changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | --- Comment #5 from Rainer Orth 2011-07-18 16:47:05 UTC --- Should be fixed now. Rainer
[Bug bootstrap/39111] gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #10 from Rainer Orth 2011-07-18 16:52:44 UTC --- No response in a year.
[Bug target/47744] [x32] ICE: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744 --- Comment #33 from Uros Bizjak 2011-07-18 16:52:59 UTC --- (In reply to comment #32) > Is isn't too bad: > > 5182.95user 396.13system 15:32.41elapsed 598%CPU (0avgtext+0avgdata > 362556maxresident)k My check on unloaded SNB (using current mainline at r176403, default configure flags and make -j 8) was in favor of patched gcc: (unpached) real28m40.314s user154m2.612s sys8m16.934s vs: (patched) real27m8.057s user142m42.522s sys7m41.875s > It passed SPEC CPU 2K and I am running SPEC CPU 2006 now. Can > you check in your patch? Thanks. Will do. Please also note, that there is no need for new lea_x32 patterns anymore.
[Bug bootstrap/39024] static libelf needs to be built PIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39024 Rainer Orth changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Rainer Orth 2011-07-18 16:54:01 UTC --- Given that mainline doesn't use libelf any longer, there's no point in fixing or documenting this.
[Bug target/47744] [x32] ICE: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744 --- Comment #34 from H.J. Lu 2011-07-18 16:55:35 UTC --- (In reply to comment #33) > > Please also note, that there is no need for new lea_x32 patterns anymore. My x32 branch has 2011-07-18 Uros Bizjak PR target/47744 * config/i386/i386.c (ix86_decompose_address): Allow only subregs of DImode hard regs in PLUS chains. 2011-07-17 H.J. Lu * config/i386/i386.c (ix86_decompose_address): Don't support 32bit address in x32 mode. 2011-07-17 H.J. Lu * config/i386/i386.c (ix86_fixup_binary_operands): Revert x32 change. 2011-07-17 H.J. Lu * config/i386/i386.md (*lea_0_x32): Removed. (*lea_2_x32): Likewise. (*lea_2_zext_x32): Likewise. (X32 LEA zero-extend split): Likewise. 2011-07-17 Uros Bizjak PR target/47744 * config/i386/i386.c (ix86_decompose_address): Properly handle SUBREG for x32. 2011-07-17 H.J. Lu * config/i386/i386.c (ix86_simplify_base_index_disp): Removed. (ix86_decompose_address): Don't call it.
[Bug libstdc++/49778] Can't take pointer to std::make_pair in c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49778
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||DUPLICATE
--- Comment #1 from Paolo Carlini 2011-07-18
16:57:38 UTC ---
The C++0x std::make_pair is slightly different, there is very little we can do
at the implementation level. Anyway, I would probably use a lambda in such
cases, like: [] (int f, int s) { return std::make_pair(f, s); }
*** This bug has been marked as a duplicate of bug 43785 ***
[Bug libstdc++/43785] [C++0x] std::make_pair vs explicit template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785 Paolo Carlini changed: What|Removed |Added CC||bugzilla.gcc.gnu.com at ||sklep dot czarko.net --- Comment #21 from Paolo Carlini 2011-07-18 16:57:38 UTC --- *** Bug 49778 has been marked as a duplicate of this bug. ***
[Bug inline-asm/38804] libgcj multilib fails if not able to exec "non" native programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.18 17:00:08 CC||ro at gcc dot gnu.org Component|libgcj |inline-asm Ever Confirmed|0 |1 --- Comment #12 from Rainer Orth 2011-07-18 17:00:08 UTC --- It has always been the case that configure needs to be able to execute code for all multilibs. If you have a target where this is not possible (like Solaris or IRIX), you need to configure with --disable-multilibs (or on some targets restrict the set of multilibs built). This has nothing to do with libgcj, but affects most target libraries. A documentation issue probably. Rainer
[Bug target/38730] gcc 4.4.0 20090104 - "make -i check" - over 60 FAILs in "C" compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38730 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ro at gcc dot gnu.org Resolution||FIXED --- Comment #5 from Rainer Orth 2011-07-18 17:03:50 UTC --- I don't test the 4.4 branch any longer, but testsuite results for newer releases are practically clean. Rainer
[Bug fortran/49708] [4.5/4.6/4.7 Regression] ICE with allocate and no dimensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49708 --- Comment #6 from janus at gcc dot gnu.org 2011-07-18 17:08:43 UTC --- (In reply to comment #5) > Janus, what's the status? Well, mostly "busy with other things" mixed with a bit of "waiting for comments and/or approval" ;) > The patch is OK with a test case, ChangeLog - and CCing it to > fortran@/gcc-patches@. Thanks, will commit soonish.
[Bug target/47744] [x32] ICE: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744 --- Comment #35 from Uros Bizjak 2011-07-18 17:17:55 UTC --- (In reply to comment #34) > 2011-07-17 H.J. Lu > > * config/i386/i386.c (ix86_decompose_address): Don't support > 32bit address in x32 mode. This one is also not needed anymore.
[Bug c/49779] New: Wrong code generated for while loop with guard containing continue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49779
Summary: Wrong code generated for while loop with guard
containing continue
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bagn...@cs.unipr.it
GCC turns a program that should loop forever into one that terminates:
$ cat q.c
int main() {
do {
while (({ continue; 1; })) {
return 1;
}
} while (0);
return 0;
}
$ gcc q.c
$ a.out && echo yes
yes
Apparently, GCC erroneously associates the `continue' to the outer `do' loop.
[Bug target/38239] The function mcount in gmon.o changes register ecx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38239 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #1 from Rainer Orth 2011-07-18 17:28:37 UTC --- At least in gcc 4.5 and up, this is correct. Don't have a recent 4.4 version handy to check, though. Rainer
[Bug c/49779] Wrong code generated for while loop with guard containing continue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49779 --- Comment #1 from Andrew Pinski 2011-07-18 17:36:38 UTC --- Hmm, statement expressions are an extension to the C language.
[Bug target/36356] gcc-4.2.4 bootstrap failure on Solaris/x86 caused by PR31868 fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36356 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ro at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Rainer Orth 2011-07-18 17:38:13 UTC --- I'm pretty certain this is a duplicate. *** This bug has been marked as a duplicate of bug 33100 ***
[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100 --- Comment #37 from Rainer Orth 2011-07-18 17:38:13 UTC --- *** Bug 36356 has been marked as a duplicate of this bug. ***
[Bug c/49779] Wrong code generated for while loop with guard containing continue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49779
--- Comment #2 from bagnara at cs dot unipr.it 2011-07-18 17:42:39 UTC ---
An extension that is still supported by GCC, right?
Here is another testcase showing the same phenomenon with `break':
int main() {
do {
while (({ break; 1; })) {
;
}
return 0;
} while (0);
return 1;
}
[Bug bootstrap/36330] i386-pc-solaris2.10 configure: error: C compiler cannot create executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36330 Rainer Orth changed: What|Removed |Added Status|WAITING |RESOLVED CC||ro at gcc dot gnu.org Known to work|| Resolution||DUPLICATE Known to fail|| --- Comment #15 from Rainer Orth 2011-07-18 17:45:29 UTC --- *** This bug has been marked as a duplicate of bug 33100 ***
[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100 --- Comment #38 from Rainer Orth 2011-07-18 17:45:29 UTC --- *** Bug 36330 has been marked as a duplicate of this bug. ***
[Bug c/49779] Wrong code generated for while loop with guard containing continue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49779 --- Comment #3 from Andrew Pinski 2011-07-18 17:47:49 UTC --- (In reply to comment #2) > An extension that is still supported by GCC, right? Yes but the semantics are not well defined in this area IIRC.
[Bug target/47744] [x32] ICE: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744 --- Comment #36 from hjl at gcc dot gnu.org 2011-07-18 17:49:04 UTC --- Author: hjl Date: Mon Jul 18 17:49:01 2011 New Revision: 176409 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176409 Log: Remove ix86_simplify_base_index_disp. 2011-07-17 Uros Bizjak PR target/47744 * config/i386/i386.c (ix86_decompose_address): Properly handle SUBREG for x32. 2011-07-17 H.J. Lu * config/i386/i386.c (ix86_simplify_base_index_disp): Removed. (ix86_decompose_address): Don't call it. Added: branches/x32/gcc/ChangeLog.addr32 Modified: branches/x32/gcc/config/i386/i386.c
[Bug target/47744] [x32] ICE: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744 --- Comment #37 from uros at gcc dot gnu.org 2011-07-18 17:51:36 UTC --- Author: uros Date: Mon Jul 18 17:51:33 2011 New Revision: 176413 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176413 Log: PR target/47744 * config/i386/i386.c (ix86_decompose_address): Allow only subregs of DImode hard registers in PLUS address chains. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/47744] [x32] ICE: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47744 --- Comment #38 from hjl at gcc dot gnu.org 2011-07-18 17:53:46 UTC --- Author: hjl Date: Mon Jul 18 17:53:43 2011 New Revision: 176414 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176414 Log: Allow only subregs of DImode hard regs in PLUS chains. 2011-07-18 Uros Bizjak PR target/47744 * config/i386/i386.c (ix86_decompose_address): Allow only subregs of DImode hard regs in PLUS chains. Modified: branches/x32/gcc/ChangeLog.addr32 branches/x32/gcc/config/i386/i386.c
