[Bug tree-optimization/34048] [4.3 Regression]: Revision 130040 miscompiles 450.soplex
--- Comment #14 from bonzini at gnu dot org 2007-11-11 07:16 ---
It could also be possible to do something like this to avoid default
construction.
@@ -46,8 +46,8 @@ namespace soplex
class UnitVector : public SVector
{
private:
- Element themem; ///< memory for 1st sparse vector entry (size)
- Element themem1; ///< memory for 2nd sparse vector entry (idx,1.0)
+ char themem[sizeof(Element[2])]; ///< memory for 1st sparse vector entry
(size)
+ /*Element themem1;*/ ///< memory for 2nd sparse vector entry (idx,1.0)
public:
/// returns value = 1
@@ -62,23 +62,22 @@ public:
/// construct \c i 'th unit vector.
UnitVector(int i = 0)
- : SVector(2, &themem)
+ : SVector(2, reinterpret_cast (themem))
{
- add(i, 1.0);
+ new(themem[0]) Element (); new (themem[sizeof (Element)]) Element ();
add(i, 1.0);
}
/// copy constructor
UnitVector(const UnitVector& rhs)
- : SVector(2, &themem)
- , themem (rhs.themem)
- , themem1(rhs.themem1)
- {}
+ : SVector(2, reinterpret_cast (themem))
+ { new(themem[0]) Element (reinterpret_cast (rhs.themem[0]));
+ new(themem[sizeof (Element)]) Element (reinterpret_cast
(rhs.themem[sizeof (Element)])); }
/// assignment
UnitVector& operator=(const UnitVector& rhs)
{
if ( this != &rhs )
- themem1 = rhs.themem1;
+ new(themem[sizeof (Element)]) Element (reinterpret_cast
(rhs.themem[sizeof (Element)]));
return *this;
}
Not the cleanest possible code, but I doubt SPEC will like to introduce a
src.alt that makes previous reports not comparable with the new ones.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug target/32406] [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3
--- Comment #7 from daney at gcc dot gnu dot org 2007-11-11 07:05 --- Created an attachment (id=14528) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14528&action=view) Proposed patch second half. Completely untested patch. It will probably take me a couple of weeks to test it fully. I will start testing on mipsel-linux... Q: Is the first exception_receiver define_expand redundant (with "TARGET_CALL_CLOBBERED_GP")? Does it just defer to the nonlocal_goto_receiver? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32406
[Bug target/32406] [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3
-- daney at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|mipsel-linux-gnu|mips*-linux-gnu GCC host triplet|mipsel-linux-gnu|mips*-linux-gnu GCC target triplet|mipsel-linux-gnu|mips*-linux-gnu Last reconfirmed|-00-00 00:00:00 |2007-11-11 06:34:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32406
[Bug target/32406] [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3
--- Comment #6 from daney at gcc dot gnu dot org 2007-11-11 06:32 --- Well the fix only works for o32. As noted in PR 34062, n32 is broken. I would guess n64 as well. I will take another try at fixing it. Perhaps the second attempt will work out a little better than the first. -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32406
[Bug target/34062] [4.3 Regression] MIPS n32 fails gcc.c-torture/execute/nestfunc-6.c
--- Comment #1 from daney at gcc dot gnu dot org 2007-11-11 06:29 --- The problem is that $gp is clobbered at the nonlocal_goto_receiver but it is not being restored. Currently the nonlocal_goto_receiver has a condition of TARGET_CALL_CLOBBERED_GP, but this is not correct. I think it should be unconditional. In: http://gcc.gnu.org/viewcvs?view=rev&revision=125941 I renamed this from exception_receiver. I wonder if the exception_receiver really should be conditional on TARGET_CALL_CLOBBERED_GP in which case there should be both an exception_receiver and nonlocal_goto_receiver. It would seem so as the unwinder should restore $gp making it redundant in the exception_receiver. Hmm. This is really the same as bug 32406 I will mark it as a duplicate and reopen 32406 *** This bug has been marked as a duplicate of 32406 *** -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34062
[Bug target/32406] [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3
--- Comment #5 from daney at gcc dot gnu dot org 2007-11-11 06:29 --- *** Bug 34062 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32406
[Bug fortran/32046] [4.3 Regression] wrong code with -O2 for gfortran.dg/interface_12.f90 & result_in_spec_1.f90
--- Comment #12 from daney at gcc dot gnu dot org 2007-11-11 06:25 --- Well obviously my commit attributed to this bug mentioned the wrong bug number. I wonder if I can find the proper bug... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32046
[Bug c++/34063] ICE: build2_stat, at tree.c:3115
--- Comment #1 from rwgk at yahoo dot com 2007-11-11 05:53 --- Created an attachment (id=14527) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14527&action=view) reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34063
[Bug c++/34063] New: ICE: build2_stat, at tree.c:3115
Platform: Fedora release 7 (Moonshine) Linux idle.lbl.gov 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux % g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /net/rosie/scratch2/rwgk/gcc_trunk/configure --prefix=/net/cci-filer1/vol1/tmp/rwgk/gcc_trunk_130073_x86_64_fc7 --enable-languages=c,c++,fortran --with-mpfr=/usr Thread model: posix gcc version 4.3.0 20071110 (experimental) (GCC) I'll upload a small standalone reproducer. To reproduce the problem: % g++ -c -O1 ice_build2_stat.cpp ice_build2_stat.cpp: In function 'void foo()': ice_build2_stat.cpp:13: internal compiler error: in build2_stat, at tree.c:3115 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. It works with this alternative command: g++ -c ice_build2_stat.cpp It also works with many other compilers including all older g++. Ralf -- Summary: ICE: build2_stat, at tree.c:3115 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34063
[Bug target/34062] [4.3 Regression] MIPS n32 fails gcc.c-torture/execute/nestfunc-6.c
-- daney at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.0 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34062
[Bug tree-optimization/19097] [4.1/4.2/4.3 regression] Quadratic behavior with many sets for the same register in VRP
--- Comment #44 from sebpop at gmail dot com 2007-11-11 05:16 --- Subject: Re: [4.1/4.2/4.3 regression] Quadratic behavior with many sets for the same register in VRP > IMVHO this should be closed as WONTFIX. Steven, why isn't your patch from comment #37 not a candidate for fixing this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097
[Bug target/34062] New: [4.3 Regression] MIPS n32 fails gcc.c-torture/execute/nestfunc-6.c
On the trunk r129918 configured: ../trunk/configure --with-arch=r5000 --disable-java-awt --without-x --enable-__cxa_atexit --disable-jvmpi --disable-libgomp --disable-static --enable-languages=c,c++,java --disable-fixed-point --enable-checking=release --with-gmp=/home/daney/mp --with-mpfr=/home/daney/mp With glibc-2.6.1 I am getting (with n32 ABI): FAIL: gcc.c-torture/execute/nestfunc-6.c execution, -O2 FAIL: gcc.c-torture/execute/nestfunc-6.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/nestfunc-6.c execution, -O3 -g FAIL: gcc.c-torture/execute/nestfunc-6.c execution, -Os All these cases are failing with SIGSEGV It seems that they used to work: http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00660.html -- Summary: [4.3 Regression] MIPS n32 fails gcc.c- torture/execute/nestfunc-6.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: daney at gcc dot gnu dot org GCC build triplet: mips64-unknown-linux-gnu GCC host triplet: mips64-unknown-linux-gnu GCC target triplet: mips64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34062
[Bug bootstrap/33992] Building libstdc++-v3: include/limits: stray '\275' in program
--- Comment #8 from dirtyepic at gentoo dot org 2007-11-11 02:42 --- reproduced with gcc-4.3-20071109 snapshot. [EMAIL PROTECTED] ~/tmp/gccbuild $ ../gcc-4.3-20071109/configure --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --enable-multilib --enable-languages=c,c++ [EMAIL PROTECTED] ~/tmp/gccbuild $ make profiledbootstrap -j1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33992
[Bug bootstrap/34045] gcc does not build on Debian etch AMD64
--- Comment #4 from miles at gnu dot org 2007-11-11 00:54 --- Wouldn't it be nice if the configure script caught this sort of thing automatically? It's obviously going to be a very common problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34045
[Bug tree-optimization/34027] [4.3 regression] -Os code size nearly doubled
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-11-10 23:54 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-11-08 21:45:30 |2007-11-10 23:54:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34027
[Bug tree-optimization/34029] [4.3 Regression] internal compiler error: verify_stmts failed
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-10 22:26 --- D.1533_20 = (long unsigned int) &s[6 - () &s]; should really folded to just 6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34029
[Bug tree-optimization/34029] [4.3 Regression] internal compiler error: verify_stmts failed
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-10 22:25 --- Hmm: D.1532_19: [&s[6 - () &s], &s[6 - () &s]] I think this my fault with respect of pointer plus merge. taking over. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-10 22:25:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34029
[Bug tree-optimization/34036] [4.2/4.3 Regression] ICE with control flow in the middle of basic block for -fnon-call-exceptions
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-11-10 22:18 --- This is also a 4.2 regression. Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-10 22:18:27 date|| Summary|[4.3 Regression] ICE with |[4.2/4.3 Regression] ICE |control flow in the middle |with control flow in the |of basic block for -fnon- |middle of basic block for - |call-exceptions |fnon-call-exceptions Target Milestone|4.3.0 |4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34036
[Bug tree-optimization/34036] [4.3 Regression] ICE with control flow in the middle of basic block for -fnon-call-exceptions
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-10 22:15 --- The rewrite of tree-ssa-reassoc.c caused this. That is the crash is after tree-ssa-reassoc.c runs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34036
[Bug tree-optimization/34036] [4.3 Regression] ICE with control flow in the middle of basic block for -fnon-call-exceptions
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-10 22:14 --- D.2119_6 = xMeasure_4(D) * zMeasure_7(D); D.2120_8 = D.2119_6 * yMeasure_5(D); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34036
[Bug tree-optimization/34036] [4.3 Regression] ICE with control flow in the middle of basic block for -fnon-call-exceptions
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-10 22:05 --- Hmm, I think these options are a bit weird: -ffast-math -fsignaling-nans -ffast-math enables -fno-signal-math so how can NaNs signal? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34036
[Bug middle-end/33335] [4.3 Regression] FAIL: 26_numerics/complex/inserters_extractors/wchar_t/1.cc
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-11-10 22:03 --- And also the ones on powerpc64-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
[Bug bootstrap/34045] gcc does not build on Debian etch AMD64
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-10 21:28 --- Use --disable-multilib as you don't have a full install of GNU/Linux glibc on x86_64 which includes the 32bits headers/libraries. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34045
[Bug c++/8570] line number in error message is badly placed with illegal template friend declaration
--- Comment #5 from manu at gcc dot gnu dot org 2007-11-10 21:28 --- Still valid in GCC 4.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8570
[Bug c++/34061] [4.3 regression] ICE with template-template parameters and inheritance
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34061
[Bug c++/34061] New: [4.3 regression] ICE with template-template parameters and inheritance
The following invalid code snippet triggers an ICE on mainline:
===
template class ...T> struct A : T<0> {};
===
bug.cc:1: error: parameter packs not expanded with `...':
bug.cc:1: note: 'template > class T'
bug.cc:1: internal compiler error: tree check: expected template_type_parm or
template_template_parm or bound_template_template_parm, have error_mark in
current_template_args, at cp/pt.c:3186
Please submit a full bug report, [etc.]
The testcase didn't crash before 2007-11-03, so it's probably fallout from
http://gcc.gnu.org/ml/gcc-cvs/2007-11/msg00120.html
--
Summary: [4.3 regression] ICE with template-template parameters
and inheritance
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34061
[Bug c++/34060] [4.3 regression] ICE with invalid specialization of variadic template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34060
[Bug c++/34060] New: [4.3 regression] ICE with invalid specialization of variadic template
The following invalid code snippet triggers an ICE on mainline:
==
template struct A
{
template struct B {};
template struct B {};
};
A<0>::B b;
==
bug.cc:5: error: parameter packs not expanded with `...':
bug.cc:5: note: 'T'
bug.cc:5: error: template parameters not used in partial specialization:
bug.cc:5: error: 'T'
bug.cc:8: internal compiler error: tree check: expected tree_vec, have
error_mark in get_innermost_template_args, at cp/pt.c:514
Please submit a full bug report, [etc.]
The testcase didn't crash before 2007-11-03, so it's probably fallout from
http://gcc.gnu.org/ml/gcc-cvs/2007-11/msg00120.html
--
Summary: [4.3 regression] ICE with invalid specialization of
variadic template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34060
[Bug c++/33468] [4.1/4.2/4.3 Regression] C++: Invalid interpretation of friendness with nested classes
--- Comment #2 from simartin at gcc dot gnu dot org 2007-11-10 20:33 --- For information, the compiler accepts this because it implements DR 45 (http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#45). It looks like the implementation has been in for a long time, but the it did not work completely, and it was fixed to fix PR#18681. This could explain why this code was accepted up to 4.0.3. -- simartin at gcc dot gnu dot org changed: What|Removed |Added CC||simartin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33468
[Bug c++/34059] [4.1/4.2/4.3 regression] ICE with invalid base type for class member
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34059
[Bug c++/34059] New: [4.1/4.2/4.3 regression] ICE with invalid base type for class member
The following invalid code snippet triggers an ICE since GCC 4.1.2:
===
struct A
{
template void foo();
};
struct B : A {};
struct C : A {};
void bar()
{
B().C::foo<0>();
}
===
bug.cc: In function 'void bar()':
bug.cc:11: internal compiler error: in build_base_path, at cp/class.c:272
Please submit a full bug report, [etc.]
Before GCC 3.4.0 we generated a correct diagnostic:
bug.cc:11: error: type `C' is not a base type for type `B'
GCC 3.4.0 - 4.1.1 wrongly accepted the code.
--
Summary: [4.1/4.2/4.3 regression] ICE with invalid base type for
class member
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34059
[Bug c++/34058] [4.3 regression] ICE with variadic template and typedef
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34058
[Bug c++/34058] New: [4.3 regression] ICE with variadic template and typedef
The following invalid code snippet triggers an ICE on mainline:
=
template struct A
{
typedef T X;
};
A a;
=
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'T'
bug.cc:3: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in handle_vector_size_attribute, at c-common.c:6039
Please submit a full bug report, [etc.]
The testcase didn't crash before 2007-11-03, so it's probably fallout from
http://gcc.gnu.org/ml/gcc-cvs/2007-11/msg00120.html
--
Summary: [4.3 regression] ICE with variadic template and typedef
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34058
[Bug c++/34057] [4.3 regression] ICE with variadic template and vector attribute
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34057
[Bug c++/34057] New: [4.3 regression] ICE with variadic template and vector attribute
The following invalid code snippet triggers an ICE on mainline:
=
template struct A
{
typedef T X __attribute__((vector_size(8)));
};
=
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'T'
bug.cc:3: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in handle_vector_size_attribute, at c-common.c:6039
Please submit a full bug report, [etc.]
The testcase didn't crash before 2007-11-03, so it's probably fallout from
http://gcc.gnu.org/ml/gcc-cvs/2007-11/msg00120.html
--
Summary: [4.3 regression] ICE with variadic template and vector
attribute
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34057
[Bug c++/34056] [4.3 regression] ICE with parameter pack and pointer
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34056
[Bug c++/34056] New: [4.3 regression] ICE with parameter pack and pointer
The following invalid code snippet triggers an ICE on mainline:
=
template struct A
{
void foo(T*) { ++p; }
T* p;
};
=
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'T'
bug.cc: In member function 'void A::foo()':
bug.cc:3: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in build_unary_op, at cp/typeck.c:4296
Please submit a full bug report, [etc.]
The testcase didn't crash before 2007-11-03, so it's probably fallout from
http://gcc.gnu.org/ml/gcc-cvs/2007-11/msg00120.html
--
Summary: [4.3 regression] ICE with parameter pack and pointer
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34056
[Bug tree-optimization/34036] [4.3 Regression] ICE with control flow in the middle of basic block for -fnon-call-exceptions
--- Comment #1 from law at redhat dot com 2007-11-10 19:51 --- I don't see how my patch could be the root cause -- more likely than not my patch is exposing a latent bug elsewhere. I'm on an extended leave-of-absence from GCC stuff, but I'll try to take a looksie and at least get someone pointed in the right direction. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34036
[Bug c++/34055] [4.3 regression] ICE with invalid specialization of variadic template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34055
[Bug c++/34055] New: [4.3 regression] ICE with invalid specialization of variadic template
The following invalid code snippet triggers an ICE on mainline:
=
template struct A;
template struct A
{
void foo();
};
template void A::foo() {}
=
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'T'
bug.cc:3: error: template parameters not used in partial specialization:
bug.cc:3: error: 'T'
bug.cc:8: internal compiler error: same canonical type node for different types
* and T*
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE with invalid specialization of
variadic template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34055
[Bug tree-optimization/34048] [4.3 Regression]: Revision 130040 miscompiles 450.soplex
--- Comment #13 from hjl at lucon dot org 2007-11-10 19:42 --- Created an attachment (id=14526) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14526&action=view) A patch This patch seems to work. -- hjl at lucon dot org changed: What|Removed |Added Attachment #14525|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug c++/34054] [4.3 regression] ICE with parameter pack in return type
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34054
[Bug c++/34054] New: [4.3 regression] ICE with parameter pack in return type
The following invalid code snippet triggers an ICE on mainline:
=
template T foo() {}
=
bug.cc:1: error: parameter packs not expanded with `...':
bug.cc:1: note: 'T'
bug.cc: In function 'foo()':
bug.cc:1: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in check_function_type, at cp/decl.c:10902
Please submit a full bug report, [etc.]
The testcase didn't crash before 2007-11-03, so it's probably fallout from
http://gcc.gnu.org/ml/gcc-cvs/2007-11/msg00120.html
--
Summary: [4.3 regression] ICE with parameter pack in return type
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34054
[Bug c++/34050] [4.3 regression] ICE derived classes and variadic templates
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-11-10 19:30 --- > How can this be a regression? Support variadic templates did not exist in > previous releases. The C++ frontend shouldn't crash with any input, even with line-noise. It didn't crash with this input in previous releases, but now it crashes (even without the "-std=gnu++0x" switch). That's a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34050
[Bug fortran/34053] -frecursive: No need to use the stack for local variables of the main program
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-10 19:23 --- As follow up, currently -frecursive is implemented as: /* Implied -frecursive; implemented as -fmax-stack-var-size=-1. */ if (gfc_option.flag_max_stack_var_size == -2 && gfc_option.flag_openmp) gfc_option.flag_max_stack_var_size = -1; I'm thus not sure how to handle this easily (i.e. what limit to use for the main PROGRAM?). Maybe one should leave the status quo, or not? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34053
[Bug fortran/34053] New: -frecursive: No need to use the stack for local variables of the main program
Using -fopenmp or -frecursive, local variables are put on the stack. This makes sense, but for the main program there is no need for the stack and the static memory can be used. This seems to be done what sunf95 does (contrary to ifort and gfortran). The following example is based on the thread at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/9a7daa8d75084b6b/ and using static memory should have no negative side effects. Example: Run the following program with -fopenmp or -frecursive and ulimit -S -s 8192 Due to this low stack size, it will crash. program sums implicit none integer, parameter :: sp = kind(1.0) integer, parameter :: dp = selected_real_kind(2*precision(1.0_sp)) integer, parameter :: num_steps = 200 real:: t1, t2 integer :: i, j real(kind=dp), dimension(0:num_steps-1) :: y call cpu_time(t1) y = 0.0_dp !$omp parallel do do j=0,num_steps-1 do i=0,49 y(j) = y(j) + 0.7_dp**i end do end do !$omp end parallel do call cpu_time(t2) print *, "y(end) = ", y(num_steps-1) print *, "Reached result in ", t2-t1, " seconds processor time." end program sums -- Summary: -frecursive: No need to use the stack for local variables of the main program Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34053
[Bug tree-optimization/34048] [4.3 Regression]: Revision 130040 miscompiles 450.soplex
--- Comment #12 from hjl at lucon dot org 2007-11-10 19:17 --- (In reply to comment #7) > Created an attachment (id=14525) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14525&action=view) [edit] > patch for 450.soplex > This patch is incomplete. I got unitvector.cc: In member function 'bool soplex::UnitVector::isConsistent() const': unitvector.cc:30: error: comparison between distinct pointer types 'soplex::SVector::Element*' and 'const soplex::SVector::Element (*)[2]' lacks a cast unitvector.cc:32: error: 'themem1' was not declared in this scope specmake[1]: *** [unitvector.o] Error 1 -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug c++/17577] [4.0/4.1/4.2/4.3 Regression] #pragma implementation no longer diagnoses use after file to which it applies
--- Comment #10 from patchapp at dberlin dot org 2007-11-10 19:00 --- Subject: Bug number PR c++/17577 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00564.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17577
[Bug c++/33160] wrong "NULL used in arithmetic" warning
--- Comment #2 from patchapp at dberlin dot org 2007-11-10 18:55 --- Subject: Bug number PR c++/33160 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00563.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33160
[Bug tree-optimization/34048] [4.3 Regression]: Revision 130040 miscompiles 450.soplex
--- Comment #11 from hjl at lucon dot org 2007-11-10 18:41 --- (In reply to comment #10) > Subject: Re: [4.3 Regression]: Revision 130040 > miscompiles 450.soplex > > On Sat, 10 Nov 2007, bonzini at gnu dot org wrote: > > > --- Comment #9 from bonzini at gnu dot org 2007-11-10 18:10 --- > > You should report the problem to SPEC so they update > > http://www.spec.org/cpu2006/Docs/450.soplex.html and create a src.alt (I > > think, > > at least this is how it was for CPU2000). > > I'll leave that to HJ who has done so in the past. > I will take care of it. Thanks, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug tree-optimization/34048] [4.3 Regression]: Revision 130040 miscompiles 450.soplex
--- Comment #10 from rguenther at suse dot de 2007-11-10 18:20 --- Subject: Re: [4.3 Regression]: Revision 130040 miscompiles 450.soplex On Sat, 10 Nov 2007, bonzini at gnu dot org wrote: > --- Comment #9 from bonzini at gnu dot org 2007-11-10 18:10 --- > You should report the problem to SPEC so they update > http://www.spec.org/cpu2006/Docs/450.soplex.html and create a src.alt (I > think, > at least this is how it was for CPU2000). I'll leave that to HJ who has done so in the past. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug tree-optimization/34048] [4.3 Regression]: Revision 130040 miscompiles 450.soplex
--- Comment #9 from bonzini at gnu dot org 2007-11-10 18:10 --- You should report the problem to SPEC so they update http://www.spec.org/cpu2006/Docs/450.soplex.html and create a src.alt (I think, at least this is how it was for CPU2000). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug fortran/30285] gfortran excessive memory usage with COMMON blocks in modules
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2007-11-10 18:09 --- (In reply to comment #20) > I would love to test it with a i586/i686-compatible build. (f951 should > be sufficient that can be used as a replacement in one of those regular > builds provided on FX's web page. Unfortunately I don't have the > resourced to build gfortran myself.) I made a build of the patched compiler that you can download from http://www.coudert.name/tmp/gfortran-i686-linux-20071110.tar.gz > I think the > first "benchmark" is to have the module files of the reworked > example to all have the same size and essentially same contents. > From comment #14 I presume that this will indeed be the case. Yes, it is the case. Please let us know how your real-life testing goes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug target/16350] gcc only understands little endian ARM systems
--- Comment #20 from patchapp at dberlin dot org 2007-11-10 18:05 --- Subject: Bug number PR16350 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00358.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350
[Bug fortran/33592] FAIL: gfortran.dg/array_constructor_11.f90 -O1 execution test
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-11-10 18:04 --- Problem fixed. Thanks for investigating this, Dave! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33592
[Bug fortran/33592] FAIL: gfortran.dg/array_constructor_11.f90 -O1 execution test
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-11-10 18:02 --- Subject: Bug 33592 Author: fxcoudert Date: Sat Nov 10 18:02:18 2007 New Revision: 130072 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130072 Log: PR fortran/33592 * trans.c (gfc_call_realloc): Fix the logic and rename variables. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33592
[Bug fortran/33592] FAIL: gfortran.dg/array_constructor_11.f90 -O1 execution test
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-10 17:49 --- Subject: Re: FAIL: gfortran.dg/array_constructor_11.f90 -O1 execution test > My mistake. This comes from a typo in trans.c (a EQ_EXPR instead of an > NE_EXPR). Could you test this patch? Works for me. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33592
[Bug c++/34052] [4.3 regression] Trouble with variadic templates as template-template parameter
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34052
[Bug c++/34052] New: [4.3 regression] Trouble with variadic templates as template-template parameter
The following code snippet is IMHO wrongly accepted on mainline:
=
template class U> struct A {};
=
A slightly modified example ICE's:
=
template class U> struct A
{
template U foo();
};
=
bug.cc:3: internal compiler error: in tsubst, at cp/pt.c:8466
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] Trouble with variadic templates as
template-template parameter
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, accepts-invalid, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34052
[Bug c++/34051] [4.3 regression] ICE in dependent_type_p with variadic templates
--- Comment #1 from steven at gcc dot gnu dot org 2007-11-10 17:27 --- Why is this a regression? Previous GCC releases did not even support variadic templates. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34051
[Bug fortran/33945] PROCEDURE in module somtimes wrongly rejected
--- Comment #7 from patchapp at dberlin dot org 2007-11-10 17:26 --- Subject: Bug number PR33945 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00416.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33945
[Bug c/29062] unclear diagnostic for declaration after label
--- Comment #10 from patchapp at dberlin dot org 2007-11-10 17:25 --- Subject: Bug number PR c/29062 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00111.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29062
[Bug c++/34050] [4.3 regression] ICE derived classes and variadic templates
--- Comment #1 from steven at gcc dot gnu dot org 2007-11-10 17:23 --- How can this be a regression? Support variadic templates did not exist in previous releases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34050
[Bug c++/34051] [4.3 regression] ICE in dependent_type_p with variadic templates
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34051
[Bug c++/34051] New: [4.3 regression] ICE in dependent_type_p with variadic templates
The following (probably invalid) code snippet triggers an ICE on mainline:
===
struct A
{
operator int();
};
template struct B : A
{
using A::operator T;
};
B b;
===
bug.cc: In instantiation of 'B':
bug.cc:11: instantiated from here
bug.cc:8: internal compiler error: in dependent_type_p, at cp/pt.c:15327
Please submit a full bug report, [etc.]
Another code snippet that ICE's in the same place:
===
template struct A
{
int i __attribute__((aligned(__alignof(T;
};
A a;
===
bug.cc: In instantiation of 'A':
bug.cc:6: instantiated from here
bug.cc:3: internal compiler error: in dependent_type_p, at cp/pt.c:15327
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE in dependent_type_p with variadic
templates
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34051
[Bug c++/34050] [4.3 regression] ICE derived classes and variadic templates
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34050
[Bug c++/34050] New: [4.3 regression] ICE derived classes and variadic templates
The following code snippet triggers an ICE on mainline:
===
struct A {};
template struct B : T...
{
B() : T()... {}
};
B b;
===
bug.cc: In constructor 'B::B() [with T = A]':
bug.cc:8: instantiated from here
bug.cc:5: internal compiler error: tree check: expected tree_list, have
void_type in tsubst_initializer_list, at cp/pt.c:14981
Please submit a full bug report, [etc.]
I guess, the code is invalid, but I'm not sure.
--
Summary: [4.3 regression] ICE derived classes and variadic
templates
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34050
[Bug tree-optimization/33974] memory partitioning sucks
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-10 17:07 --- *** Bug 30735 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33974
[Bug tree-optimization/30735] [4.3 Regression] 50% slow down due to mem-ssa merge
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-11-10 17:07 --- Likewise. *** This bug has been marked as a duplicate of 33974 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30735
[Bug tree-optimization/33974] memory partitioning sucks
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-10 17:06 --- *** Bug 31090 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33974
[Bug tree-optimization/31090] [4.3 Regression] Revision 121302 causes 30% performance regression
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-11-10 17:06 --- Let's close it as a dup of PR33974. *** This bug has been marked as a duplicate of 33974 *** -- 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=31090
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #43 from steven at gcc dot gnu dot org 2007-11-10 17:05 --- What is the status of this bug now? Re. comment #39, a meta-bug for what? There is only one open bug left that depends on this one. Are we still tracking an issue in this bug? If so, what? If not, please close this bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug tree-optimization/31090] [4.3 Regression] Revision 121302 causes 30% performance regression
--- Comment #17 from steven at gcc dot gnu dot org 2007-11-10 16:57 --- HJ, what is up with this bug 31090? Not only is the status of the bug itself unclear, but it is also keeping bug 30735 open for vague reasons. Do we have an issue here, or not? If not, can you please close this bug and also bug 30735? Have you compared pre-r121302 and current performance numbers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
--- Comment #20 from steven at gcc dot gnu dot org 2007-11-10 16:51 --- "Next week" has come and gone... News? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug target/33923] [4.3 Regression] ICE in reload_cse_simplify_operands (insn does not satisfy its constraints)
--- Comment #6 from steven at gcc dot gnu dot org 2007-11-10 16:49 --- Eric, the PRE issue you mention was fixed (xf. bug 32540). The target issue is still open. The test case you posted in the patch from the Patch URL is already in the test suite as gcc/testsuite/gcc.dg/tree-ssa/pr33922.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33923
[Bug tree-optimization/34048] [4.3 Regression]: Revision 130040 miscompiles 450.soplex
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-11-10 16:44 --- So, invalid. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug tree-optimization/34048] [4.3 Regression]: Revision 130040 miscompiles 450.soplex
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-11-10 16:43 --- Created an attachment (id=14525) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14525&action=view) patch for 450.soplex -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug tree-optimization/34048] [4.3 Regression]: Revision 130040 miscompiles 450.soplex
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-10 16:42 ---
This looks like a bug in soplex. It does:
class UnitVector : public SVector
{
private:
Element themem;
Element themem1;
public:
...
UnitVector(int i = 0)
: SVector(2, &themem)
{
add(i, 1.0);
}
and:
class SVector
{
...
struct Element
{
Real val;
int idx;
};
Element *m_elem;
...
SVector(int n = 0, Element* p_mem = 0)
{
setMem(n, p_mem);
}
...
void setMem(int n, Element* elmem)
{
(static_cast (0));
if (n > 0)
{
(static_cast (0));
elmem->val = 0;
m_elem = &(elmem[1]);
set_size( 0 );
set_max ( n - 1 );
}
else
m_elem = 0;
}
that is, SVector accesses themem, themem1 as array (obviously to avoid
unneccessary default construction). If you fix this, the miscompile
goes away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug tree-optimization/30132] [4.1/4.2/4.3 Regression] ICE in find_lattice_value, at tree-complex.c:133
--- Comment #14 from steven at gcc dot gnu dot org 2007-11-10 16:40 --- Patch is waiting for approval of the C++ bits. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30132
[Bug tree-optimization/34048] [4.3 Regression]: Revision 130040 miscompiles 450.soplex
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-10 16:09 --- Again aliasing is completely dependent on whether unrelated functions are present or not. *sigh* -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug bootstrap/33992] Building libstdc++-v3: include/limits: stray '\275' in program
--- Comment #7 from dirtyepic at gentoo dot org 2007-11-10 15:56 --- looks like this only occurs with profiledbootstrap. i'll test a vanilla build to see if this is Gentoo specific. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33992
[Bug fortran/30285] gfortran excessive memory usage with COMMON blocks in modules
--- Comment #20 from anlauf at gmx dot de 2007-11-10 15:17 --- Tobias, > Harald, can you test the patch at > http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00552.html > with your real-world program? I would love to test it with a i586/i686-compatible build. (f951 should be sufficient that can be used as a replacement in one of those regular builds provided on FX's web page. Unfortunately I don't have the resourced to build gfortran myself.) > And for the other tests I have, the compile time does not > significantly change (too much noise to see the effect). The essential problem was actually the virtual memory used by f951 when I last tried to compile the app with MPI enabled. I think the first "benchmark" is to have the module files of the reworked example to all have the same size and essentially same contents. >From comment #14 I presume that this will indeed be the case. Thanks, -ha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug bootstrap/15212] [4.0/4.1/4.2/4.3 Regression] bootstrap fails on interix3
--- Comment #37 from oshima at eng dot niigata-u dot ac dot jp 2007-11-10 14:58 --- Created an attachment (id=14524) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14524&action=view) A proposed patch for bootstrapping GCC-4.2.2 on Interix 6 The attached patch is to bootstrap GCC 4.2.2 on Interix 6.0, based on Martin's. The compilers bootstrapped successfully with the following config. ../gcc-4.2.2/configure --verbose \ --prefix=/dev/fs/D/ohshima/OpenFOAM/interix/gcc-4.2.2 \ --with-gmp=/dev/fs/D/ohshima/OpenFOAM/interix/gcc-4.2.2 \ --with-mpfr=/dev/fs/D/ohshima/OpenFOAM/interix/gcc-4.2.2 \ --enable-version-specific-runtime-libs --enable-threads=posix \ --disable-win32-registry --disable-libssp --with-stabs \ --enable-fully-dynamic-string --enable-shared \ --enable-languages=c,c++,fortran However the failure rates of the testsuites (make -f check), as indicated below, are considerably higher compared to other platforms. Moreover, the numbers of failures slightly vary across the test runs. I'd be grateful if anyone can look into and revise the patch. === g++ Summary === # of expected passes12703 # of unexpected failures67 # of unexpected successes 2 # of expected failures 65 # of unresolved testcases 42 # of untested testcases 30 # of unsupported tests 150 === gcc Summary === # of expected passes40371 # of unexpected failures525 # of unexpected successes 1 # of expected failures 109 # of unresolved testcases 2 # of untested testcases 245 # of unsupported tests 405 === gfortran Summary === # of expected passes14296 # of unexpected failures1484 # of expected failures 5 # of unsupported tests 80 === libstdc++ Summary === # of expected passes2936 # of unexpected failures84 # of expected failures 13 # of unsupported tests 158 With kind regards, Takuya -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
[Bug tree-optimization/34048] [4.3 Regression]: Revision 130040 miscompiles 450.soplex
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-10 14:36 --- : # SFT.2355_186 = VDEF D.37036.themem.val = 0.0; D.45669_134 = &D.37036.themem + 16; ... : # VUSE n_142 = D.45672_138->idx; pretmp.2399_154 = (long unsigned int) n_142; pretmp.2399_151 = pretmp.2399_154 * 16; pretmp.2401_143 = n_142 + 1; : # prephitmp.2402_141 = PHI <1(22), pretmp.2401_143(11)> # prephitmp.2400_148 = PHI <0(22), pretmp.2399_151(11)> # prephitmp.2400_153 = PHI <0(22), pretmp.2399_154(11)> # n_145 = PHI <0(22), n_142(11)> D.45674_144 = prephitmp.2400_153; D.45675_146 = prephitmp.2400_148; D.45676_147 = D.45669_134 + D.45675_146; # SFT.2357_206 = VDEF D.45676_147->idx = newdim_31; # SFT.2356_209 = VDEF D.45676_147->val = 1.0e+0; so D.45676_147->val cannot just alias with SFT.2356. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, dnovillo at gcc dot gnu ||dot org Keywords||alias, wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug tree-optimization/34048] [4.3 Regression]: Revision 130040 miscompiles 450.soplex
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-10 14:31 --- tree-ssa-sink is the culprit (we re-compute aliasing after PRE, right before sink, so an error there might be the bug as well): Sinking newdim_31 = newdim_1 + -1 from bb 15 to bb 12 Sinking # SFT.2356_213 = VDEF D.45672_138->idx = D.45677_152 from bb 12 to bb 14 Sinking D.45677_152 = prephitmp.2402_141 from bb 12 to bb 14 Sinking # SFT.2356_209 = VDEF D.45676_147->val = 1.0e+0 from bb 12 to bb 14 Sinking # SFT.2355_200 = VDEF D.45672_138->val = 1.0e+0 from bb 10 to bb 14 Sinking # SFT.2354_136 = VDEF D.37036.D.34678.m_elem = D.45669_134 from bb 10 to bb 14 Sinking # SFT.2355_186 = VDEF D.37036.themem.val = 0.0 from bb 10 to bb 14 virtual void soplex::SoPlex::reDim() (this) at least ptr->val with only a single SFT looks suspicious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug c++/33160] wrong "NULL used in arithmetic" warning
--- Comment #1 from manu at gcc dot gnu dot org 2007-11-10 14:11 --- Testing a patch. -- manu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |manu at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-08-23 10:46:57 |2007-11-10 14:11:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33160
[Bug tree-optimization/34048] [4.3 Regression]: Revision 130040 miscompiles 450.soplex
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-10 13:35 --- All the tree difference is in virtual void soplex::SoPlex::reDim() (this) and it looks like an alias issue (what else...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug tree-optimization/34048] [4.3 Regression]: Revision 130040 miscompiles 450.soplex
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-10 13:26 --- soplex.o is miscompiled. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-10 13:26:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34048
[Bug middle-end/33713] [4.3 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #14 from bonzini at gnu dot org 2007-11-10 13:04 --- I reviewed the patch and it seems ok except that the option should be kept undocumented for 4.3. fforce-addr - Common Report Var(flag_force_addr) Optimization - Copy memory address constants into registers before use + Common + Does nothing. Preserved for backward compatibility. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33713
[Bug fortran/30285] gfortran excessive memory usage with COMMON blocks in modules
--- Comment #19 from burnus at gcc dot gnu dot org 2007-11-10 12:29 --- Harald, can you test the patch at http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00552.html with your real-world program? Due to .mod changes, the "gfc-excessive.tar.gz" does not work. And for the other tests I have, the compile time does not significantly change (too much noise to see the effect). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug c++/34049] New: Parentheses-enclosed expression.
gcc rejects following valid code.
//test.c
struct foo
{
int operator[](int) const { return 0; }
};
int main()
{
(foo()[0]);
return 0;
}
--
Summary: Parentheses-enclosed expression.
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34049
[Bug middle-end/33713] [4.3 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #13 from steven at gcc dot gnu dot org 2007-11-10 10:46 --- Created an attachment (id=14523) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14523&action=view) Nukes -fforce-addr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33713
[Bug bootstrap/34045] gcc does not build on Debian etch AMD64
--- Comment #2 from laurent dot bonnaud at inpg dot fr 2007-11-10 08:30 --- I get exactly the same error: $ ../gcc-4.2.2/configure --prefix=/usr/local/gcc-4.2 $ make bootstrap [...] checking for x86_64-unknown-linux-gnu-gcc... /var/tmp/LB/build/./gcc/xgcc -B/var/tmp/LB/build/./gcc/ -B/usr/local/gcc-4.2/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gcc-4.2/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gcc-4.2/x86_64-unknown-linux-gnu/include -isystem /usr/local/gcc-4.2/x86_64-unknown-linux-gnu/sys-include -m32 checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. make[1]: *** [configure-target-libmudflap] Error 1 make[1]: Leaving directory `/var/tmp/LB/build' make: *** [bootstrap] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34045
