[Bug tree-optimization/35629] [4.4 Regression] gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times profile fails
--- Comment #10 from hubicka at gcc dot gnu dot org 2009-01-30 08:00 --- Yes, it is harmless, so P4 should be better match. The test is checking that loop disambugiation is done one way not the other way while both are correct choices. Honza -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35629
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #28 from ktietz at gcc dot gnu dot org 2009-01-30 08:54 --- (In reply to comment #19) Anyone else could test it, please? ok, I tested it for linux64 and and for w64 without any new problems. I applied the patch (see rev. #143780). Just the testcase is missing. Do you apply it and set then the bug as fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #29 from jakub at gcc dot gnu dot org 2009-01-30 09:23 --- Subject: Bug 39002 Author: jakub Date: Fri Jan 30 09:22:48 2009 New Revision: 143782 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143782 Log: PR target/39002 * g++.dg/torture/pr39002.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr39002.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug target/39002] [4.4 Regression] codegen bug, stack pointer is not restored
--- Comment #30 from jakub at gcc dot gnu dot org 2009-01-30 09:29 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug target/39039] segfault with common block and -O1 -ftree-vectorize -msse2
--- Comment #1 from ubizjak at gmail dot com 2009-01-30 09:56 --- You can workaround this PE/COFF problem with -fno-common. *** This bug has been marked as a duplicate of 37216 *** -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39039
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #51 from ubizjak at gmail dot com 2009-01-30 09:56 --- *** Bug 39039 has been marked as a duplicate of this bug. *** -- ubizjak at gmail dot com changed: What|Removed |Added CC||billingd at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug fortran/38956] tests gfortran.dg/chmod_{1,2,3}.f90 fails on i686-pc-cygwin
--- Comment #5 from bonzini at gnu dot org 2009-01-30 10:01 --- The posted patch seems wrong, since the test is testing chmod you should use stat to check the result. -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38956
[Bug middle-end/38157] -fconserve-stack enabled by default
--- Comment #3 from hariharans at picochip dot com 2009-01-30 10:04 --- Index: gcc/common.opt === --- gcc/common.opt (revision 143749) +++ gcc/common.opt (working copy) @@ -386,7 +386,7 @@ Do not put uninitialized globals in the common section fconserve-stack -Common Var(flag_conserve_stack,0) Optimization +Common Var(flag_conserve_stack) Optimization Do not perform optimizations increasing noticeably stack usage fcprop-registers This patch was commited to mainline (for 4.4.0). -- hariharans at picochip dot com changed: What|Removed |Added CC||hariharans at picochip dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38157
[Bug c++/38928] infinite loop on error message in C++ only
--- Comment #4 from paolo dot carlini at oracle dot com 2009-01-30 10:18 --- The diagnostic issue is trivial, just add a check for error_mark_node on the return value of reshape_init_r, consistently with other calls. However, I'm still analyzing whether we really want to reject. As data points, ICC doesn't, even in strict mode; on the other hand Comeau rejects the identifier family already... Mark, do you have a quick opinion? Thanks in advance... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38928
[Bug tree-optimization/39041] New: ICE on valid during vrp2
The attached file causes an ICE with gcc-4.3.2 and gcc-4.3.3 on at least two targets (ix86 Linux and Blackfin) when compiled with -O2. bug.i: In function 'foo': bug.i:18: internal compiler error: in get_addr_dereference_operands, at tree-ssa-operands.c:1698 This happens during the vrp2 pass: ber...@beaker /local/blackfin/b-4.3/gcc $ tail bug.i.115t.vrp2 prephitmp.29_38: [0, 1] SMT.36_57: VARYING Substituing values and folding statements Folded statement: pretmp.28_29 = *D.1312_16; into: pretmp.28_29 = *cpumask.bits[0]; -- Summary: ICE on valid during vrp2 Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bernds_cb1 at t-online dot de GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39041
[Bug tree-optimization/39041] ICE on valid during vrp2
--- Comment #1 from bernds_cb1 at t-online dot de 2009-01-30 10:51 --- Created an attachment (id=17212) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17212action=view) Testcase to reproduce the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39041
[Bug middle-end/39015] [4.3/4.4 regression] wrong code building libgsf
--- Comment #13 from jakub at gcc dot gnu dot org 2009-01-30 10:58 --- Nothing changed in gsf-scan.c, but out of the 3 objects in libgsf.so that changed it seems to be gsf-output-csv.c where r143570 makes difference for gsf-scan. Looking at it now... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug middle-end/39015] [4.3/4.4 regression] wrong code building libgsf
--- Comment #14 from jakub at gcc dot gnu dot org 2009-01-30 11:38 --- And clearly the bug is in libgsf, not in gcc. g_enum_register_static documentation says: GObject keeps a reference to the data, so it cannot be stack-allocated. so this relies on this optimization. gsf_output_csv_quoting_mode_get_type just needs to be fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Keywords|wrong-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug middle-end/39015] [4.3/4.4 regression] wrong code building libgsf
--- Comment #15 from jakub at gcc dot gnu dot org 2009-01-30 11:39 --- Created an attachment (id=17213) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17213action=view) libgsf-enum-register.patch Patch that fixes this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug middle-end/39015] [4.3/4.4 regression] wrong code building libgsf
--- Comment #16 from jakub at gcc dot gnu dot org 2009-01-30 11:40 --- Invalid. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||caolanm at redhat dot com Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug libstdc++/30928] add casts to libc overloads
--- Comment #1 from jakub at gcc dot gnu dot org 2009-01-30 11:48 --- For very recent glibc this has been fixed with http://gcc.gnu.org/viewcvs?root=gccview=revrev=143773 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30928
[Bug c++/39028] [4.3/4.4 Regression] C++ front-end rejects __label__ at the beginning of a block after for and while
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-30 12:00:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39028
[Bug libstdc++/30928] add casts to libc overloads
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-30 12:07:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30928
[Bug libstdc++/30928] add casts to libc overloads
--- Comment #2 from paolo dot carlini at oracle dot com 2009-01-30 12:08 --- *** Bug 33935 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30928
[Bug libstdc++/33935] overloads in C headers
--- Comment #3 from paolo dot carlini at oracle dot com 2009-01-30 12:08 --- This is really the same as libstdc++/30928. *** This bug has been marked as a duplicate of 30928 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33935
[Bug tree-optimization/39041] ICE on valid during vrp2
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-30 13:39 --- Confirmed. There's a type mismatch in the substituted statement: pretmp.27_29 = *cpumask.bits[0] arg 1 indirect_ref 0x775267c0 type integer_type 0x77e89540 int arg 0 addr_expr 0x7752a180 type pointer_type 0x77f71f00 constant invariant arg 0 array_ref 0x77514730 type integer_type 0x77e89600 unsigned int arg 0 component_ref 0x775147d0 type array_type 0x77f71e40 arg 0 var_decl 0x77f3c8c0 cpumask arg 1 field_decl 0x77f3c820 bits arg 1 integer_cst 0x77e79c00 constant invariant 0 we have int and unsigned int. The INDIRECT_REF has the wrong type. forwprop causes this and creates int * a; ... a_15 = cpumask.bits[D.1587_13]; -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-30 13:39:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39041
[Bug tree-optimization/39041] ICE on valid during vrp2
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-30 13:46 --- 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|2009-01-30 13:39:10 |2009-01-30 13:46:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39041
[Bug tree-optimization/39041] [4.3 Regression] ICE on valid during vrp2
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-30 13:47 --- 4.2 works, the problem is latent in 4.4 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Known to work||4.2.4 Summary|ICE on valid during vrp2|[4.3 Regression] ICE on ||valid during vrp2 Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39041
[Bug c/18624] GCC does not detect local variable set but never used
--- Comment #12 from dcb314 at hotmail dot com 2009-01-30 13:48 --- (In reply to comment #1) Yes this would be slightly useful but one has to be care full of what is warned about. Agreed. For a first cut, a simple straight forward job, without considering the complex cases, could be the way forward. For example, all bets would be off for any variable that has it's address taken. To get some data on how many times this set but not used problem occurs in real code, I just had a go at compiling almost half the Suse Linux distribution source tree with Intel C/C++. For source codes [a-k]*, there where 906 occurrences of the set but not used warning from Intel C/C++. Given that Intel can't compile a lot of the GNU specific code, I estimate at least 2,000 and maybe 2,500 occurrences of this problem in Suse Linux distribution. Other distributions are different sizes, but at least this gives us a single data point on how frequently the set but not used problem occurs in practice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18624
[Bug lto/38995] lto1 uses unaligned data accesses
--- Comment #6 from hjl at gcc dot gnu dot org 2009-01-30 14:14 --- Subject: Bug 38995 Author: hjl Date: Fri Jan 30 14:13:50 2009 New Revision: 143789 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143789 Log: gcc/ 2009-01-30 H.J. Lu hongjiu...@intel.com PR lto/38995 * langhooks.c (lhd_begin_section): Call assemble_align to align LTO sections to POINTER_SIZE. gcc/lto/ 2009-01-30 H.J. Lu hongjiu...@intel.com PR lto/38995 * lto-elf.c (init_shdr##BITS): Set the sh_addralign field to POINTER_SIZE. Modified: branches/lto/gcc/ChangeLog.lto branches/lto/gcc/langhooks.c branches/lto/gcc/lto/ChangeLog branches/lto/gcc/lto/lto-elf.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38995
[Bug lto/39042] New: [LTO] LTO tests don't cleanup temporary files
I have 10GB free space in /tmp. But it isn't enough to run make check because LTO tests don't cleanup after run. It leads to many false alarms and make my machine unusable. -- Summary: [LTO] LTO tests don't cleanup temporary files Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: lto AssignedTo: dnovillo at google dot com ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39042
[Bug c++/38928] infinite loop on error message in C++ only
--- Comment #5 from bangerth at gmail dot com 2009-01-30 15:00 --- (In reply to comment #4) However, I'm still analyzing whether we really want to reject. As data points, ICC doesn't, even in strict mode; on the other hand Comeau rejects the identifier family already... Does it reject the code because this form of member initializer (where you name individual members) is really a C99 thing, not C++98? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38928
[Bug c++/33465] Broken diagnostic: 'fix_trunc_expr' and 'float_expr' not supported by dump_expr
--- Comment #2 from paolo at gcc dot gnu dot org 2009-01-30 15:03 ---
Subject: Bug 33465
Author: paolo
Date: Fri Jan 30 15:03:10 2009
New Revision: 143790
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143790
Log:
/cp
2009-01-30 Paolo Carlini paolo.carl...@oracle.com
PR c++/33465
* error.c (dump_expr): Handle FIX_TRUNC_EXPR and FLOAT_EXPR.
/testsuite
2009-01-30 Paolo Carlini paolo.carl...@oracle.com
PR c++/33465
* g++.dg/parse/error34.C: New.
* g++.dg/parse/error35.C: Likewise.
/cp
2009-01-30 Paolo Carlini paolo.carl...@oracle.com
PR c++/38655
* error.c (dump_type_prefix, dump_type_suffix): Handle
FIXED_POINT_TYPE.
/testsuite
2009-01-30 Paolo Carlini paolo.carl...@oracle.com
PR c++/38655
* g++.dg/cpp0x/decltype-38655.C: New.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/decltype-38655.C (with props)
trunk/gcc/testsuite/g++.dg/parse/error34.C
trunk/gcc/testsuite/g++.dg/parse/error35.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/error.c
trunk/gcc/testsuite/ChangeLog
Propchange: trunk/gcc/testsuite/g++.dg/cpp0x/decltype-38655.C
('svn:mergeinfo' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33465
[Bug c++/38655] Broken diagnostic: 'fixed_point_type' not supported by dump_type_prefix/dump_type_suffix
--- Comment #1 from paolo at gcc dot gnu dot org 2009-01-30 15:03 ---
Subject: Bug 38655
Author: paolo
Date: Fri Jan 30 15:03:10 2009
New Revision: 143790
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143790
Log:
/cp
2009-01-30 Paolo Carlini paolo.carl...@oracle.com
PR c++/33465
* error.c (dump_expr): Handle FIX_TRUNC_EXPR and FLOAT_EXPR.
/testsuite
2009-01-30 Paolo Carlini paolo.carl...@oracle.com
PR c++/33465
* g++.dg/parse/error34.C: New.
* g++.dg/parse/error35.C: Likewise.
/cp
2009-01-30 Paolo Carlini paolo.carl...@oracle.com
PR c++/38655
* error.c (dump_type_prefix, dump_type_suffix): Handle
FIXED_POINT_TYPE.
/testsuite
2009-01-30 Paolo Carlini paolo.carl...@oracle.com
PR c++/38655
* g++.dg/cpp0x/decltype-38655.C: New.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/decltype-38655.C (with props)
trunk/gcc/testsuite/g++.dg/parse/error34.C
trunk/gcc/testsuite/g++.dg/parse/error35.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/error.c
trunk/gcc/testsuite/ChangeLog
Propchange: trunk/gcc/testsuite/g++.dg/cpp0x/decltype-38655.C
('svn:mergeinfo' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38655
[Bug c++/39038] Redeclaration
--- Comment #3 from bangerth at gmail dot com 2009-01-30 15:03 --- This is probably related to PR 2288. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39038
[Bug c++/33465] Broken diagnostic: 'fix_trunc_expr' and 'float_expr' not supported by dump_expr
--- Comment #3 from paolo dot carlini at oracle dot com 2009-01-30 15:05 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33465
[Bug c++/18770] g++ accepts invalid code with scopes on ifs
--- Comment #5 from bangerth at gmail dot com 2009-01-30 15:05 --- *** Bug 39038 has been marked as a duplicate of this bug. *** -- bangerth at gmail dot com changed: What|Removed |Added CC||mahesh dot balasubramanian ||at wipro dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18770
[Bug c++/39038] Redeclaration
--- Comment #4 from bangerth at gmail dot com 2009-01-30 15:05 --- *** This bug has been marked as a duplicate of 18770 *** -- bangerth at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39038
[Bug c++/38655] Broken diagnostic: 'fixed_point_type' not supported by dump_type_prefix/dump_type_suffix
--- Comment #2 from paolo dot carlini at oracle dot com 2009-01-30 15:05 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38655
[Bug c++/38986] comparing lengths of 2 strings reads through both strings completely
--- Comment #1 from bangerth at gmail dot com 2009-01-30 15:13 --- Yes, I think this would be an optimizing compiler could potentially perform. At the same time I think you are expecting too much from the compiler: it would have to have a semantic understanding of what the strlen function does and that the result can be obtained by merging the two calls to strlen, then merging the two loops, and then truncating them. I don't think that this sort of analysis is going to be available in compilers anytime soon. Since you already have the solution, maybe this is the way to go! Best W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38986
[Bug c++/38541] function parameter type T(*)[]
--- Comment #1 from bangerth at gmail dot com 2009-01-30 15:20 ---
Confirmed. The original testcase had a function argument of type
pointer-to-pointer-to-array-of-unknown-size, but this testcase
also fails:
template typename T_
bool f (T_ p);
bool g ()
{ return fint(*)[](0); }
-
--
bangerth at gmail dot com changed:
What|Removed |Added
Known to fail||4.3.1 4.4.0 2.95.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38541
[Bug c++/38541] function parameter type T(*)[]
-- bangerth at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-30 15:20:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38541
[Bug c++/38958] 'unused variable' warning emitted when extending the lifetime of a returned RAII type by holding a reference to const despite delayed destructor side-effects. [dtor]
--- Comment #1 from bangerth at gmail dot com 2009-01-30 15:23 --- Confirmed. -- bangerth at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2009-01-30 15:23:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38958
[Bug c++/38950] [4.3/4.4 regression] ICE: deducing function template arguments for array type.
--- Comment #1 from bangerth at gmail dot com 2009-01-30 15:27 --- Confirmed. This used to work in 4.1 where we got the following error (which does not earn the prize for the prettiest error message ever): g/x /home/bangerth/bin/gcc-4.1.1/bin/c++ -c x.cc x.cc: In function 'int main()': x.cc:7: error: size of array has non-integral type 'T' x.cc:1: error: size of array has non-integral type 'T' x.cc:1: error: size of array has non-integral type 'T' x.cc:7: error: invalid initialization of reference of type 'unsigned int ()[1]' from expression of type 'unsigned int [2]' x.cc:1: error: in passing argument 1 of 'void f(T ()[N]) [with T = unsigned int, T N = ((T)2)]' x.cc: In function 'void f(T ()[N]) [with T = unsigned int, T N = ((T)2)]': x.cc:7: instantiated from here x.cc:1: error: size of array has non-integral type 'T' -- bangerth at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2009-01-30 15:27:16 date|| Summary|ICE: deducing function |[4.3/4.4 regression] ICE: |template arguments for array|deducing function template |type. |arguments for array type. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38950
[Bug c++/38950] [4.3/4.4 regression] ICE: deducing function template arguments for array type.
--- Comment #2 from bangerth at gmail dot com 2009-01-30 15:28 --- Thinking some more about it, I believe that the code is actually valid. icc accepts it, for comparison. W. -- bangerth at gmail dot com changed: What|Removed |Added Keywords|ice-on-invalid-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38950
[Bug c++/38888] [C++0x] badly readable diagnostic output with variadic templates
--- Comment #5 from bangerth at gmail dot com 2009-01-30 15:29 --- I think Jason confirmed this already... -- bangerth at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-30 15:29:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug c++/38828] g++ 4.3.2: -O2 without -fno-inline-small-functions makes some template instantiations disappear
--- Comment #10 from bangerth at gmail dot com 2009-01-30 15:37 ---
(In reply to comment #9)
Following the twisted maze that is BOOST_CLASS_EXPORT() leads me to think that
it is (very) roughly equivalent to this:
void dummy(boost::archive::xml_iarchive ar, A a, B b) {
boost::serialization::serialize(ar, a, 0);
boost::serialization::serialize(ar, b, 0);
}
Indeed, replacing my BOOST_CLASS_EXPORT() calls with this, I get the same
effect (disappearing symbols with -O2).
At this point, my question is: is triggering template instantiations in this
way supposed to be equivalent to explicit instantiations (as in comment #8)
with respect to symbols exposed to the outside? If the answer is no, thank you
very much for your help and sorry for the trouble.
The answer is no. The code requires the *implicit* instantiation of some code
but the compiler only needs to instantiate whatever it needs and is free
to eliminate what it doesn't. In fact, there is no guarantee that any code
visible outside this one object file is generated at all.
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC||bangerth at gmail dot com
Status|WAITING |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38828
[Bug c++/38761] %s substituted with regular word can't be properly translated
--- Comment #3 from bangerth at gmail dot com 2009-01-30 15:45 --- Confirmed. There is no need to convolve error messages like that. W. -- bangerth at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2009-01-30 15:45:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38761
[Bug c++/37093] [4.2/4.3/4.4 Regression] ICE with pointer to member template parameters
--- Comment #16 from bangerth at gmail dot com 2009-01-30 15:49 ---
(In reply to comment #5)
Excuse me, but I do not understand what makes this code invalid. Could anybody
explain? If so, does this apply to all the test cases given (also for bugs
that
are marked as duplicates of this bug)?
In this code:
-
template typename T
int bar(int T::* p)
{
return foop(0);
}
-
'p' is a variable, but only constant expressions can be used as template
arguments for foo.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37093
[Bug c++/37093] [4.2/4.3/4.4 Regression] ICE with pointer to member template parameters
--- Comment #17 from bangerth at gmail dot com 2009-01-30 15:51 --- *** Bug 38681 has been marked as a duplicate of this bug. *** -- bangerth at gmail dot com changed: What|Removed |Added CC||juvvij at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37093
[Bug c++/38681] Internal compiler error. expr.c:6956 [Template instantiation with non-type value of member function ptr]
--- Comment #7 from bangerth at gmail dot com 2009-01-30 15:51 --- (In reply to comment #5) Did I understand this wrong ? Does the correct interpretation of the standard not allow for member-function-pointers as non-type arguments ? It does, but it requires them to be in a constant-expression context -- i.e. informally speaking the compiler needs to know *at compile time* which member function you refer to. You can use a function argument as a template argument. I think this is indeed a duplicate of PR 37093. W. W. *** This bug has been marked as a duplicate of 37093 *** -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38681
[Bug c++/38658] inefficient code on trivial try/catch statement
--- Comment #2 from bangerth at gmail dot com 2009-01-30 15:58 --- The standard details certain side effects of throwing exceptions such as allocating and freeing memory as well as setting expressions that std::uncaught_exception can evaluate. These side effects can not always be omitted. W. -- bangerth at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38658
[Bug c++/38557] dynamic_cast should give a warning/error for non related classes
--- Comment #2 from bangerth at gmail dot com 2009-01-30 16:02 --- Confirmed. Gcc would have to keep track of the actual types of variables. W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-30 16:02:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38557
[Bug c/39026] Gcc accepts invalid code
--- Comment #7 from hjl dot tools at gmail dot com 2009-01-30 16:04 --- I think it is caused by revision 118356: http://gcc.gnu.org/ml/gcc-cvs/2006-11/msg7.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39026
[Bug c/18624] GCC does not detect local variable set but never used
--- Comment #13 from manu at gcc dot gnu dot org 2009-01-30 16:11 --- (In reply to comment #12) For source codes [a-k]*, there where 906 occurrences of the set but not used warning from Intel C/C++. @dcb I think nobody is discussing that we would want such warning (in some form or another) in GCC. We do not need more rationale or evidence supporting it. We need someone to write the patch. Just that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18624
[Bug c++/38986] comparing lengths of 2 strings reads through both strings completely
--- Comment #2 from esigra at gmail dot com 2009-01-30 16:12 --- GCC already understands the semantics of strlen. If one of the operands to is a constant and the other is strlen, it is optimized (such as strlen(str) = 1). It just seems like the case with strlen on both sides is missing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38986
[Bug c++/39028] [4.3/4.4 Regression] C++ front-end rejects __label__ at the beginning of a block after for and while
--- Comment #1 from jakub at gcc dot gnu dot org 2009-01-30 16:17 --- Subject: Bug 39028 Author: jakub Date: Fri Jan 30 16:17:30 2009 New Revision: 143797 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143797 Log: PR c++/39028 * parser.c (cp_parser_already_scoped_statement): Handle __label__ declarations. * g++.dg/ext/label12.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/label12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39028
[Bug c++/39028] [4.3 Regression] C++ front-end rejects __label__ at the beginning of a block after for and while
--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-30 16:18 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4 Regression] C++|[4.3 Regression] C++ front- |front-end rejects |end rejects __label__ at |__label__ at the beginning|the beginning of a block |of a block after for and |after for and while |while | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39028
[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-30 16:35 --- I think this may be due to the use of setjmp and DEF_GCC_BUILTIN(BUILT_IN_SETJMP, setjmp, BT_FN_INT_PTR, ATTR_NULL) missing the fact that setjmp returns twice. Note also the inconsistency in if (is_gimple_call (t) fndecl DECL_BUILT_IN (fndecl) (call_flags ECF_NOTHROW) !(call_flags ECF_NORETURN) !(call_flags ECF_RETURNS_TWICE)) return false; if (is_gimple_call (t) !(call_flags ECF_NORETURN)) return true; wrt ECF_NORETURN. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
[Bug c++/39043] New: C++ compiler doesn't optimize function call for PIE
[...@gnu-6 gcc]$ cat /tmp/i.ii
inline void foo () {}
int
main ()
{
foo ();
return 0;
}
[...@gnu-6 gcc]$ ./xgcc -B./ -fpie /tmp/i.ii -S
[...@gnu-6 gcc]$ grep call i.s | grep foo
call_z3f...@plt
[...@gnu-6 gcc]$
Do we need @PLT for PIE?
--
Summary: C++ compiler doesn't optimize function call for PIE
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39043
[Bug c/39044] New: -Wformat warns on printf() with stringpointer as sole argument
GCC-4.3.3, all previous versions are unaffected.
This snippet:
8 --- 8
#include stdio.h
int main()
{
static const char *s = hello world;
printf(s);
return 0;
}
- 8 -- 8 -
built with -Wformat throws this warning:
test-f.c: In function 'main':
test-f.c:5: warning: format not a string literal and no format arguments
Which is very inconvenient when building linux kernels for certains targets
which enable -Werror.
--
Summary: -Wformat warns on printf() with stringpointer as sole
argument
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mano at roarinelk dot homelinux dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39044
[Bug c/39026] Gcc accepts invalid code
--- Comment #8 from hjl dot tools at gmail dot com 2009-01-30 16:44 --- (In reply to comment #6) It would be a way more local change than changing what binds local (which also affects other languages). My proposal patch will bind undefined functions global, instead of local. It sounds safe to me. We can put it on trunk and wait a while before backporting it to 4.3 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39026
[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback
--- Comment #7 from jakub at gcc dot gnu dot org 2009-01-30 16:54 --- ECF_RETURNS_TWICE is set by special_function_p, doesn't need anything special in builtins.def. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
[Bug middle-end/38937] [4.4 Regression] dereferencing pointer 'anonymous' does break strict-aliasing
--- Comment #3 from paolo dot carlini at oracle dot com 2009-01-30 16:57
---
In the meanwhile the patch for PR38503 has been installed and unfortunately I
have to report that this issue seems indeed different, eg, this testcase is
still not fixed on x86_64-linux:
#include string
#include list
class A;
class B {
public:
void foo(A);
std::string s;
};
class A {
public:
A qaz() {
l.push_back( new A() );
return *l.back();
}
std::listA* l;
};
void bar()
{
A a;
B b;
b.foo(a.qaz());
}
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Last reconfirmed|-00-00 00:00:00 |2009-01-30 16:57:42
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38937
[Bug middle-end/38937] [4.4 Regression] dereferencing pointer 'anonymous' does break strict-aliasing
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2009-01-30 16:57:42 |2009-01-30 16:58:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38937
[Bug middle-end/39015] [4.3/4.4 regression] wrong code building libgsf
--- Comment #17 from jdassen at debian dot org 2009-01-30 17:02 --- Now fixed in libgsf upstream: http://svn.gnome.org/viewvc/libgsf?view=revisionrevision=1039 Thank you very much! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback
--- Comment #8 from matz at gcc dot gnu dot org 2009-01-30 17:12 ---
But special_function_p looks at the name of the function, which is
__builtin_setjmp in case the builtin is used explicitely:
% cat x.c
#include setjmp.h
jmp_buf env;
int f(void){ return __builtin_setjmp(env);}
% gdb --args cc1 x.c
(gdb) b special_function_p
...
474 if (fndecl DECL_NAME (fndecl)
(gdb)
487 const char *name = IDENTIFIER_POINTER (DECL_NAME (fndecl));
(gdb)
488 const char *tname = name;
(gdb) p name
$3 = 0x77f60460 __builtin_setjmp
Up to now, it's only a theory that it might be setjmp related, purely because
it's jobs.c of bash which exhibits the error, and presumably jobs.c deals
with, well, jobs and forks, and possibly setjmps around.
But what we do know is, that its indeed Ben's patch. Reverting it lets
bash build again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
[Bug tree-optimization/38977] [4.4 Regression] bash no longer builds with profile-feedback
--- Comment #9 from jakub at gcc dot gnu dot org 2009-01-30 17:23 ---
Ah, I thought special_function_p would strip off __builtin_ prefix from tname,
but apparently it doesn't. I'd say it should, something like:
--- gcc/calls.c2009-01-28 12:57:50.0 +0100
+++ gcc/calls.c2009-01-30 18:22:26.0 +0100
@@ -498,10 +498,14 @@ special_function_p (const_tree fndecl, i
! strcmp (name, __builtin_alloca
flags |= ECF_MAY_BE_ALLOCA;
- /* Disregard prefix _, __ or __x. */
+ /* Disregard prefix _, __, __x or __builtin_. */
if (name[0] == '_')
{
- if (name[1] == '_' name[2] == 'x')
+ if (name[1] == '_'
+ name[2] == 'b'
+ !strncmp (name + 3, uiltin_, 7))
+tname += 10;
+ else if (name[1] == '_' name[2] == 'x')
tname += 3;
else if (name[1] == '_')
tname += 2;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
[Bug c/39034] Decimal floating-point math done wrong
--- Comment #1 from tydeman at tybor dot com 2009-01-30 17:31 --- My analysis shows that d10=0x2fe3=+3.e-15 So, d10 is not zero, while d2 is zero. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39034
[Bug target/39013] [4.3/4.4 Regression] Missing @PLT when -fpie is used
--- Comment #16 from jakub at gcc dot gnu dot org 2009-01-30 17:31 --- Patch to set DECL_EXTERNAL instead: http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01525.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39013
[Bug tree-optimization/38745] [4.4 Regression] ICE: statement makes a memory store, but has no VDEFS
--- Comment #20 from hjl at gcc dot gnu dot org 2009-01-30 17:32 --- Subject: Bug 38745 Author: hjl Date: Fri Jan 30 17:31:24 2009 New Revision: 143798 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143798 Log: 2009-01-30 H.J. Lu hongjiu...@intel.com 2009-01-27 Richard Guenther rguent...@suse.de PR tree-optimization/38503 * g++.dg/warn/Wstrict-aliasing-bogus-placement-new.C: New testcase. 2009-01-26 Richard Guenther rguent...@suse.de PR tree-optimization/38745 * g++.dg/torture/pr38745.C: New testcase. 2009-01-26 Richard Guenther rguent...@suse.de PR middle-end/38851 * g++.dg/warn/Wuninitialized-1.C: New testcase. 2009-01-20 Andrew Pinski andrew_pin...@playstation.sony.com Richard Guenther rguent...@suse.de PR tree-optimization/38747 PR tree-optimization/38748 * gcc.dg/tree-ssa/struct-aliasing-1.c: New test. * gcc.c-torture/execute/struct-aliasing-1.c: Likewise. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/torture/pr38745.C - copied unchanged from r143797, trunk/gcc/testsuite/g++.dg/torture/pr38745.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-bogus-placement-new.C - copied unchanged from r143797, trunk/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-bogus-placement-new.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/Wuninitialized-1.C - copied unchanged from r143797, trunk/gcc/testsuite/g++.dg/warn/Wuninitialized-1.C branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/struct-aliasing-1.c - copied unchanged from r143797, trunk/gcc/testsuite/gcc.c-torture/execute/struct-aliasing-1.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/tree-ssa/struct-aliasing-1.c - copied unchanged from r143797, trunk/gcc/testsuite/gcc.dg/tree-ssa/struct-aliasing-1.c Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38745
[Bug tree-optimization/38747] [4.4 Regression] Wrong code due to VIEW_CONVERT_EXPR
--- Comment #6 from hjl at gcc dot gnu dot org 2009-01-30 17:32 --- Subject: Bug 38747 Author: hjl Date: Fri Jan 30 17:31:24 2009 New Revision: 143798 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143798 Log: 2009-01-30 H.J. Lu hongjiu...@intel.com 2009-01-27 Richard Guenther rguent...@suse.de PR tree-optimization/38503 * g++.dg/warn/Wstrict-aliasing-bogus-placement-new.C: New testcase. 2009-01-26 Richard Guenther rguent...@suse.de PR tree-optimization/38745 * g++.dg/torture/pr38745.C: New testcase. 2009-01-26 Richard Guenther rguent...@suse.de PR middle-end/38851 * g++.dg/warn/Wuninitialized-1.C: New testcase. 2009-01-20 Andrew Pinski andrew_pin...@playstation.sony.com Richard Guenther rguent...@suse.de PR tree-optimization/38747 PR tree-optimization/38748 * gcc.dg/tree-ssa/struct-aliasing-1.c: New test. * gcc.c-torture/execute/struct-aliasing-1.c: Likewise. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/torture/pr38745.C - copied unchanged from r143797, trunk/gcc/testsuite/g++.dg/torture/pr38745.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-bogus-placement-new.C - copied unchanged from r143797, trunk/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-bogus-placement-new.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/Wuninitialized-1.C - copied unchanged from r143797, trunk/gcc/testsuite/g++.dg/warn/Wuninitialized-1.C branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/struct-aliasing-1.c - copied unchanged from r143797, trunk/gcc/testsuite/gcc.c-torture/execute/struct-aliasing-1.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/tree-ssa/struct-aliasing-1.c - copied unchanged from r143797, trunk/gcc/testsuite/gcc.dg/tree-ssa/struct-aliasing-1.c Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38747
[Bug tree-optimization/38748] [4.4 Regression] Missed FRE because of VIEW_CONVERT_EXPR
--- Comment #10 from hjl at gcc dot gnu dot org 2009-01-30 17:32 --- Subject: Bug 38748 Author: hjl Date: Fri Jan 30 17:31:24 2009 New Revision: 143798 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143798 Log: 2009-01-30 H.J. Lu hongjiu...@intel.com 2009-01-27 Richard Guenther rguent...@suse.de PR tree-optimization/38503 * g++.dg/warn/Wstrict-aliasing-bogus-placement-new.C: New testcase. 2009-01-26 Richard Guenther rguent...@suse.de PR tree-optimization/38745 * g++.dg/torture/pr38745.C: New testcase. 2009-01-26 Richard Guenther rguent...@suse.de PR middle-end/38851 * g++.dg/warn/Wuninitialized-1.C: New testcase. 2009-01-20 Andrew Pinski andrew_pin...@playstation.sony.com Richard Guenther rguent...@suse.de PR tree-optimization/38747 PR tree-optimization/38748 * gcc.dg/tree-ssa/struct-aliasing-1.c: New test. * gcc.c-torture/execute/struct-aliasing-1.c: Likewise. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/torture/pr38745.C - copied unchanged from r143797, trunk/gcc/testsuite/g++.dg/torture/pr38745.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-bogus-placement-new.C - copied unchanged from r143797, trunk/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-bogus-placement-new.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/Wuninitialized-1.C - copied unchanged from r143797, trunk/gcc/testsuite/g++.dg/warn/Wuninitialized-1.C branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/struct-aliasing-1.c - copied unchanged from r143797, trunk/gcc/testsuite/gcc.c-torture/execute/struct-aliasing-1.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/tree-ssa/struct-aliasing-1.c - copied unchanged from r143797, trunk/gcc/testsuite/gcc.dg/tree-ssa/struct-aliasing-1.c Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38748
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #18 from hjl at gcc dot gnu dot org 2009-01-30 17:32 --- Subject: Bug 38503 Author: hjl Date: Fri Jan 30 17:31:24 2009 New Revision: 143798 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143798 Log: 2009-01-30 H.J. Lu hongjiu...@intel.com 2009-01-27 Richard Guenther rguent...@suse.de PR tree-optimization/38503 * g++.dg/warn/Wstrict-aliasing-bogus-placement-new.C: New testcase. 2009-01-26 Richard Guenther rguent...@suse.de PR tree-optimization/38745 * g++.dg/torture/pr38745.C: New testcase. 2009-01-26 Richard Guenther rguent...@suse.de PR middle-end/38851 * g++.dg/warn/Wuninitialized-1.C: New testcase. 2009-01-20 Andrew Pinski andrew_pin...@playstation.sony.com Richard Guenther rguent...@suse.de PR tree-optimization/38747 PR tree-optimization/38748 * gcc.dg/tree-ssa/struct-aliasing-1.c: New test. * gcc.c-torture/execute/struct-aliasing-1.c: Likewise. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/torture/pr38745.C - copied unchanged from r143797, trunk/gcc/testsuite/g++.dg/torture/pr38745.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-bogus-placement-new.C - copied unchanged from r143797, trunk/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-bogus-placement-new.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/Wuninitialized-1.C - copied unchanged from r143797, trunk/gcc/testsuite/g++.dg/warn/Wuninitialized-1.C branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/struct-aliasing-1.c - copied unchanged from r143797, trunk/gcc/testsuite/gcc.c-torture/execute/struct-aliasing-1.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/tree-ssa/struct-aliasing-1.c - copied unchanged from r143797, trunk/gcc/testsuite/gcc.dg/tree-ssa/struct-aliasing-1.c Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug middle-end/38851] [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor
--- Comment #21 from hjl at gcc dot gnu dot org 2009-01-30 17:32 --- Subject: Bug 38851 Author: hjl Date: Fri Jan 30 17:31:24 2009 New Revision: 143798 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143798 Log: 2009-01-30 H.J. Lu hongjiu...@intel.com 2009-01-27 Richard Guenther rguent...@suse.de PR tree-optimization/38503 * g++.dg/warn/Wstrict-aliasing-bogus-placement-new.C: New testcase. 2009-01-26 Richard Guenther rguent...@suse.de PR tree-optimization/38745 * g++.dg/torture/pr38745.C: New testcase. 2009-01-26 Richard Guenther rguent...@suse.de PR middle-end/38851 * g++.dg/warn/Wuninitialized-1.C: New testcase. 2009-01-20 Andrew Pinski andrew_pin...@playstation.sony.com Richard Guenther rguent...@suse.de PR tree-optimization/38747 PR tree-optimization/38748 * gcc.dg/tree-ssa/struct-aliasing-1.c: New test. * gcc.c-torture/execute/struct-aliasing-1.c: Likewise. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/torture/pr38745.C - copied unchanged from r143797, trunk/gcc/testsuite/g++.dg/torture/pr38745.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-bogus-placement-new.C - copied unchanged from r143797, trunk/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-bogus-placement-new.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/Wuninitialized-1.C - copied unchanged from r143797, trunk/gcc/testsuite/g++.dg/warn/Wuninitialized-1.C branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/struct-aliasing-1.c - copied unchanged from r143797, trunk/gcc/testsuite/gcc.c-torture/execute/struct-aliasing-1.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/tree-ssa/struct-aliasing-1.c - copied unchanged from r143797, trunk/gcc/testsuite/gcc.dg/tree-ssa/struct-aliasing-1.c Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38851
[Bug c/39035] if( 0.0DF ) is considered true
--- Comment #2 from tydeman at tybor dot com 2009-01-30 17:34 --- This is NOT a dup of 39034. In this one, the value of the expression is zero. In 39034, the value of d10 is not zero (but should be). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39035
[Bug fortran/34955] transfer_assumed_size_1.f90: Valgrind error: invalid read of size 3
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34955
[Bug tree-optimization/38789] [4.4 Regression] __builtin_constant_p appears to evaluate to true for non-constant arguments.
--- Comment #12 from hjl at gcc dot gnu dot org 2009-01-30 17:47 --- Subject: Bug 38789 Author: hjl Date: Fri Jan 30 17:46:24 2009 New Revision: 143799 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143799 Log: 2009-01-30 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-01-16 Jakub Jelinek ja...@redhat.com PR tree-optimization/38789 * gcc.c-torture/compile/pr38789.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/pr38789.c - copied unchanged from r143798, trunk/gcc/testsuite/gcc.c-torture/compile/pr38789.c Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38789
[Bug lto/38995] lto1 uses unaligned data accesses
--- Comment #7 from hjl dot tools at gmail dot com 2009-01-30 18:30 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38995
[Bug c/39037] FLOAT_CONST_DECIMAL64 pragma not supported
--- Comment #1 from janis at gcc dot gnu dot org 2009-01-30 18:30 --- Is N1312 available online? I had not heard of any version later than N1290. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||bje at gcc dot gnu dot org, ||hjl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39037
[Bug c/39037] FLOAT_CONST_DECIMAL64 pragma not supported
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-30 18:41 --- (In reply to comment #1) Is N1312 available online? I had not heard of any version later than N1290. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1312.pdf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39037
[Bug target/39013] [4.3/4.4 Regression] Missing @PLT when -fpie is used
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-01-29 00:47:37 |2009-01-30 20:32:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39013
[Bug libstdc++/30928] add casts to libc overloads
--- Comment #3 from marc dot glisse at normalesup dot org 2009-01-30 20:38 --- Hello, looking at the two last comments, I think we are speaking of slightly different things, although they are related. I was asking for some const_cast of the return value, in case the const version of wcschr (or other) we are forwarding to (from the non-const overload) has the official C++ prototype. In any case, it can't hurt and makes the code a bit cleaner with respect to the intended behaviour. I was then planning to ask glibc to insert a macro in the declaration: extern MYMACRO void* memchr(const void*,int,size_t); where MYMACRO could be defined as const by a C++ implementation, but apparently an even better fix was adopted, cool :-) The fix mentionned by Jakub is the right way to do things for a well-behaved libc (solaris with __cplusplus=199711L, or apparently a very recent glibc). Hopefully the same thing will be done for the other headers (cstdlib or cmath for instance), although the interaction with C99/C++0X may require 2 macros instead of just one. Bug 33935 asks that g++ ship a string.h that is equivalent to cstring when __CORRECT_ISO_CPP_STRING_H_PROTO is not defined. Obviously it is not that easy because standard headers including each other may end up including the wrappers, but now that glibc and its multiply included headers are out of the way it may be easier (or not). Too bad there is no easy way to distinguish libc headers from other headers. Anyway, I want to thank you both because you did not consider these issues negligible. I'd love to help, I know how to fix most of the bugs I have filed related to solaris headers, but I still haven't managed to get the legal paperwork done (keep changing employers, and the FSF disclaimer is not a paper they have ever signed before). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30928
[Bug c/39034] Decimal floating-point math done wrong
--- Comment #2 from janis at gcc dot gnu dot org 2009-01-30 20:44 --- Created an attachment (id=17214) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17214action=view) expanded testcase I expanded the testcase to test both constant folding and runtime calculations for all three decimal float types. The problem occurs with 4.3.3 but not with mainline. I can track down the patch that fixed it if anyone is interested. Test results for trunk and 4.3 for powerpc64-linux and x86-linux (bid and dpd): elm3b187% uname -m ppc64 elm3b187% /opt/gcc-nightly/trunk/bin/gcc -DDBG -O2 -std=gnu99 39034.c ./a.out elm3b187% /opt/gcc-nightly/4.3/bin/gcc -DDBG -O2 -std=gnu99 39034.c ./a.out line 29: runtime: d32 should be zero line 42: runtime: d64 should be zero line 56: runtime: d128 should be zero Aborted laptop% uname -m i686 laptop% /home/janis/tools/gcc-trunk-bid/bin/gcc -DDBG -O2 -std=gnu99 39034.c ./a.out laptop% /home/janis/tools/gcc-trunk-dpd/bin/gcc -DDBG -O2 -std=gnu99 39034.c ./a.out laptop% /home/janis/tools/gcc-4.3.3-bid/bin/gcc -DDBG -O2 -std=gnu99 39034.c ./a.out line 29: runtime: d32 should be zero line 42: runtime: d64 should be zero line 56: runtime: d128 should be zero Aborted (core dumped) laptop% /home/janis/tools/gcc-4.3.3-dpd/bin/gcc -DDBG -O2 -std=gnu99 39034.c ./a.out line 29: runtime: d32 should be zero line 42: runtime: d64 should be zero line 56: runtime: d128 should be zero Aborted (core dumped) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39034
[Bug c/39034] Decimal floating-point math done wrong
-- janis at gcc dot gnu dot org changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com, bje at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |janis at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-30 20:46:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39034
[Bug c/39035] if( 0.0DF ) is considered true
-- janis at gcc dot gnu dot org changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com, bje at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |janis at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-30 20:46:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39035
[Bug target/39013] [4.3/4.4 Regression] Missing @PLT when -fpie is used
--- Comment #17 from jakub at gcc dot gnu dot org 2009-01-30 20:47 --- Subject: Bug 39013 Author: jakub Date: Fri Jan 30 20:46:32 2009 New Revision: 143803 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143803 Log: PR target/39013 * c-decl.c (pop_scope): Set DECL_EXTERNAL for functions declared inline but never defined. * gcc.target/i386/pr39013-1.c: New test. * gcc.target/i386/pr39013-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr39013-1.c trunk/gcc/testsuite/gcc.target/i386/pr39013-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39013
[Bug c/39035] if( 0.0DF ) is considered true
--- Comment #3 from janis at gcc dot gnu dot org 2009-01-30 20:48 --- Created an attachment (id=17215) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17215action=view) expanded testcase I expanded the testcase to test both constant folding and runtime calculations for all three decimal float types. The problem occurs with 4.3.3 and mainline. Test results for trunk and 4.3 for powerpc64-linux and x86-linux (bid and dpd): elm3b187% uname -m ppc64 elm3b187% /opt/gcc-nightly/trunk/bin/gcc -DDBG -O2 -std=gnu99 39035.c ./a.out line 49: 0.0DF should be zero line 56: 0.0DD should be zero line 63: 0.0DL should be zero Aborted elm3b187% /opt/gcc-nightly/4.3/bin/gcc -DDBG -O2 -std=gnu99 39035.c ./a.out line 49: 0.0DF should be zero line 56: 0.0DD should be zero line 63: 0.0DL should be zero Aborted laptop% uname -m i686 laptop% /home/janis/tools/gcc-trunk-bid/bin/gcc -DDBG -O2 -std=gnu99 39035.c ./a.out line 49: 0.0DF should be zero line 56: 0.0DD should be zero line 63: 0.0DL should be zero Aborted (core dumped) laptop% /home/janis/tools/gcc-trunk-dpd/bin/gcc -DDBG -O2 -std=gnu99 39035.c ./a.out line 49: 0.0DF should be zero line 56: 0.0DD should be zero line 63: 0.0DL should be zero Aborted (core dumped) laptop% /home/janis/tools/gcc-4.3.3-bid/bin/gcc -DDBG -O2 -std=gnu99 39035.c ./a.out line 49: 0.0DF should be zero line 56: 0.0DD should be zero line 63: 0.0DL should be zero Aborted (core dumped) laptop% /home/janis/tools/gcc-4.3.3-dpd/bin/gcc -DDBG -O2 -std=gnu99 39035.c ./a.out line 49: 0.0DF should be zero line 56: 0.0DD should be zero line 63: 0.0DL should be zero Aborted (core dumped) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39035
[Bug target/39013] [4.3 Regression] Missing @PLT when -fpie is used
--- Comment #18 from jakub at gcc dot gnu dot org 2009-01-30 20:50 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.3 4.4.0 |4.3.3 Known to work|4.2.4 |4.2.4 4.4.0 Summary|[4.3/4.4 Regression] Missing|[4.3 Regression] Missing |@PLT when -fpie is used |@PLT when -fpie is used http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39013
[Bug c++/39045] New: Not inited referense.
g++ allows to exist not inited reference in this case:
struct X
{
int x;
};
int main()
{
X* p_x = new X; // now there is not inited reference (p_x-x)
// now we can try to use p_x-x
std::cout p_x-x std::endl; // segmentation fault
return 0;
}
There are no errors or warnings. Compilation is successfull.
I have tested on g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3).
Also it works on g++ 4.3.
--
Summary: Not inited referense.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexey dot veselovsky at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39045
[Bug target/39027] double floating point suffix of 'd' and 'D' not accepted
-- janis at gcc dot gnu dot org changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com AssignedTo|unassigned at gcc dot gnu |janis at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-01-29 21:57:00 |2009-01-30 20:50:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39027
[Bug libstdc++/36022] stl templates exported as weak symbols though visibility hidden is used
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-01-30 20:56 --- Created an attachment (id=17216) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17216action=view) remove visibility attribute with -D_GLIBCXX_VISIBILITY=0, run testuite with it and -fvisibility-hidden -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36022
[Bug c/39031] HUGE_VAL_D32, HUGE_VAL_D64, HUGE_VAL_D128 missing from math.h
--- Comment #3 from janis at gcc dot gnu dot org 2009-01-30 20:57 --- Ryan, would you please provide information about the status of C library decimal float support for powerpc*-linux and s390-linux? HJ, would you please provide information about the status of C library decimal float support for x86*-linux? Any suggestions for how Fred can test the C library support? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39031
[Bug lto/39010] [LTO] Memory corruption on gcc.c-torture/compile/limits-fndefn.c
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-30 21:08 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01533.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||01/msg01533.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39010
[Bug lto/39010] [LTO] Memory corruption on gcc.c-torture/compile/limits-fndefn.c
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-30 21:22 --- The updated patch is at http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01534.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2009- |patches/2009- |01/msg01533.html|01/msg01534.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39010
[Bug c/39036] Decimal floating-point exception flags done wrong
--- Comment #3 from janis at gcc dot gnu dot org 2009-01-30 21:31 --- The bug is a duplicate of 20785 because the pragma is not implemented. From the point of view of GCC it is invalid because fenv.h and the functions it declares are not provided by GCC, but by the C library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39036
[Bug lto/39010] [LTO] Memory corruption on gcc.c-torture/compile/limits-fndefn.c
--- Comment #3 from hjl at gcc dot gnu dot org 2009-01-30 21:55 --- Subject: Bug 39010 Author: hjl Date: Fri Jan 30 21:55:30 2009 New Revision: 143806 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143806 Log: 2009-01-30 H.J. Lu hongjiu...@intel.com PR lto/39010 * lto-function-out.c (output_string): Properly handle the trailing '\0'. (output_tree_flags): Updated. Modified: branches/lto/gcc/ChangeLog.lto branches/lto/gcc/lto-function-out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39010
[Bug lto/39010] [LTO] Memory corruption on gcc.c-torture/compile/limits-fndefn.c
--- Comment #4 from hjl dot tools at gmail dot com 2009-01-30 21:58 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39010
[Bug c++/39046] New: gcc 4.4.0 20090116 loop unrolling causes unaccountable performance degradation
Version info:
$ powerpc-apple-darwin8.11.0-gcc-4.4.0 -v
Using built-in specs.
Target: powerpc-apple-darwin8.11.0
Configured with: ../gcc-4.4-20090116/configure --prefix=/opt/local
--enable-languages=c,c++,objc,obj-c++ --libdir=/opt/local/lib/gcc44
--includedir=/opt/local/include/gcc44 --infodir=/opt/local/share/info
--mandir=/opt/local/share/man --with-local-prefix=/opt/local --with-system-zlib
--disable-nls --program-suffix=-mp-4.4
--with-gxx-include-dir=/opt/local/include/gcc44/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --disable-multilib
Thread model: posix
gcc version 4.4.0 20090116 (experimental) (GCC)
Above is a macports (formerly darwin ports) build of gcc4.4.0 on an
OSX 10.4.11 ppc7450 host.
Following C++ function produces different code depending on the use of
'loop_assignment_ai' vs 'flat_assignment_ai' snippets:
#include stdio.h
inline static void
mmul(
float (c)[4][4],
const float (a)[4][4],
const float (b)[4][4])
{
// iterate by product's rows
for (unsigned i = 0; i 4; i++)
{
register float ai[4][4];
// swizzle each element of the i-th row of A into a full vector
for (unsigned j = 0; j 4; j++)
// flat_assignment_ai:
/* ai[j][0] = ai[j][1] = ai[j][2] = ai[j][3] = a[i][j];
*/
// loop_assignment_ai:
for (unsigned k = 0; k 4; k++)
ai[j][k] = a[i][j];
// multiply the first element of the i-th row of A by the first row of
B
for (unsigned k = 0; k 4; k++)
{
c[i][k] = ai[0][k] * b[0][k];
}
// multiply-add all subsequent elements of the i-th row of A by the
respective rows of B
for (unsigned j = 1; j 4; j++)
{
for (unsigned k = 0; k 4; k++)
{
c[i][k] += ai[j][k] * b[j][k];
}
}
}
}
// function invoked with following parameters (statics)
float a[4][4] __attribute__ ((aligned (16)));
float b[4][4] __attribute__ ((aligned (16)));
float c[4][4] __attribute__ ((aligned (16)));
int main(int argc, char * const argv[])
{
// omitted here is assignment of sample test values to arguments a b
unsigned ndz; // non-deterministic zero
printf(enter a zero: );
if (1 != scanf(%u, ndz)) // user expected to punch in a zero here
return -1;
const unsigned ndf = ndz ? 1 : 0; // non-deterministic const factor: it is
meant to be zero, but the cc does not know that thus it can't declare our loop
'redundant'
unsigned r = 1000;
do
{
mmul(*(c + ndf * r), *(a + ndf * r), *(b + ndf * r));
}
while (--r);
return r;
}
/code
Observed ~10% performance degradation when using 'loop_assignment_ai' instead
of
'direct_assignment_ai'. It appears that the differences in the generated ppc
code are mainly in instruction scheduling.
Following optimization-related compiler options were used for the test:
-fno-exceptions -fno-rtti -faltivec -maltivec -mtune=7450 -O3
-funroll-loops -ffast-math -fstrict-aliasing
-ftree-vectorize -ftree-vectorizer-verbose=3
-fvisibility-inlines-hidden -fno-threadsafe-statics
For the record, the intended vectorization fails, so the resulting code is
entirely scalar.
-martin
--
Summary: gcc 4.4.0 20090116 loop unrolling causes unaccountable
performance degradation
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: blu dot dark at gmail dot com
GCC build triplet: powerpc-apple-darwin8.11.0
GCC host triplet: powerpc-apple-darwin8.11.0
GCC target triplet: powerpc-apple-darwin8.11.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39046
[Bug c/39037] FLOAT_CONST_DECIMAL64 pragma not supported
-- janis at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janis at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-30 22:03:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39037
[Bug c++/39047] New: Segmentation fault in g++
g++ crashes with a segmentation fault trying to compile the attached program -- Summary: Segmentation fault in g++ Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dima at debian dot org GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39047
[Bug tree-optimization/39041] [4.3 Regression] ICE on valid during vrp2
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-30 22:09 --- Subject: Bug 39041 Author: rguenth Date: Fri Jan 30 22:09:15 2009 New Revision: 143808 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143808 Log: 2009-01-30 Richard Guenther rguent...@suse.de PR tree-optimization/39041 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Propagate variable indices only if the types match for this stmt. * gcc.c-torture/compile/pr39041.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr39041.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39041
[Bug c++/39047] Segmentation fault in g++
--- Comment #1 from dima at debian dot org 2009-01-30 22:10 --- Created an attachment (id=17217) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17217action=view) test case which triggers the core dump -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39047
[Bug c++/39047] Segmentation fault in g++
--- Comment #2 from dima at debian dot org 2009-01-30 22:13 --- $ g++ -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu12' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) -- dima at debian dot org changed: What|Removed |Added CC||dima at debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39047
[Bug tree-optimization/39041] [4.3 Regression] ICE on valid during vrp2
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-30 22:14 --- Subject: Bug 39041 Author: rguenth Date: Fri Jan 30 22:14:39 2009 New Revision: 143809 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143809 Log: 2009-01-30 Richard Guenther rguent...@suse.de PR tree-optimization/39041 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Propagate variable indices only if the types match for this stmt. * gcc.c-torture/compile/pr39041.c: New testcase. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/pr39041.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39041
