[Bug libstdc++/40518] data races when calling std::string::erase() on empty string
--- Comment #14 from bart dot vanassche at gmail dot com 2010-04-08 06:03 --- (In reply to comment #13) I agree it's probably not worth backporting to a release branch, it wasn't a regression. Haven't affected users written valgrind suppression files by now? :) Since the races on _S_empty_rep_storage are triggered by an inline function many different suppression patterns would have to be added in order to suppress these races. And adding such suppression patterns would suppress several real races. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518
[Bug bootstrap/43681] bootstrap fails with unused var message for an apparently used var.
--- Comment #1 from jakub at gcc dot gnu dot org 2010-04-08 07:00 --- Created an attachment (id=20331) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20331action=view) gcc46-pr43681.patch Untested patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43681
[Bug fortran/43591] PPC: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #15 from dominiq at lps dot ens dot fr 2010-04-08 07:48 --- With the patch in comment #14, the test in comment #1 compiles and gives: evt= 234, flv= 1, col= 2, hel= 3, -0.122E-13 + i* 0.675E-14 ~ 0.267E-02 evt= 234, flv= 1, col= 2, hel= 6, -0.122E-13 + i*-0.675E-14 ~ 0.267E-02 evt= 289, flv= 1, col= 2, hel= 3, -0.161E-12 + i* 0.292E-12 ~ 0.446E-01 evt= 289, flv= 1, col= 2, hel= 6, -0.161E-12 + i*-0.292E-12 ~ 0.446E-01 evt= 380, flv= 1, col= 2, hel= 3, 0.102E-11 + i*-0.568E-13 ~ 0.817E-01 evt= 380, flv= 1, col= 2, hel= 4, -0.383E-12 + i* 0.213E-13 ~ 0.817E-01 evt= 380, flv= 1, col= 2, hel= 5, -0.383E-12 + i*-0.213E-13 ~ 0.817E-01 evt= 380, flv= 1, col= 2, hel= 6, 0.102E-11 + i* 0.568E-13 ~ 0.817E-01 evt= 380, flv= 1, col= 5, hel= 3, -0.108E-11 + i* 0.710E-12 ~ 0.217E+00 evt= 380, flv= 1, col= 5, hel= 6, -0.108E-11 + i*-0.710E-12 ~ 0.217E+00 10 failures in4 attempts STOP 1 Regtested without failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug target/43635] [4.5/4.6 Regression] ICE in s390_emit_call, at config/s390/s390.c:9484
--- Comment #4 from rguenther at suse dot de 2010-04-08 08:11 --- Subject: Re: [4.5/4.6 Regression] ICE in s390_emit_call, at config/s390/s390.c:9484 On Wed, 7 Apr 2010, krebbel at gcc dot gnu dot org wrote: --- Comment #3 from krebbel at gcc dot gnu dot org 2010-04-07 15:56 --- Created an attachment (id=20328) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20328action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20328action=view) Reduced testcase The check for valid sibcalls in the S/390 back-end relies on the decl to be available in the DECL parameter: /* The 31 bit PLT code uses register 12 (GOT pointer - caller saved) which would have to be restored before the sibcall. */ if (!TARGET_64BIT flag_pic decl !targetm.binds_local_p (decl)) return false; The type cast of the function pointer in the testcase introduces a temporary variable on 4.5 which is not linked with the function decl anymore: x_1 = (void (*T244) (float) (*T248) (void *)) d; D.1966_3 = x_1 (p_2(D)); [tail call] return D.1966_3; With 4.4: D.1224 = (void (*T242) (float) (*T246) (void *)) d (p); [tail call] return D.1224; So we probably have to always reject sibcalls if the fndecl is not reachable. The extra cast happens if the function signatures are not compatible (by means of useless_type_conversion_p). I can't deciper the function type from (void (*T244) (float) (*T248) (void *)) right now, but it's early in the morning ;) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43635
[Bug tree-optimization/43679] [4.5/4.6 Regression] ice in gen_lsm_tmp_name, at tree-ssa-loop-im.c:1812
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-08 08:14 --- Mine then. -- 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 Component|c |tree-optimization Keywords||ice-on-valid-code Last reconfirmed|2010-04-07 22:04:29 |2010-04-08 08:14:03 date|| Summary|ice in gen_lsm_tmp_name, at |[4.5/4.6 Regression] ice in |tree-ssa-loop-im.c:1812 |gen_lsm_tmp_name, at tree- ||ssa-loop-im.c:1812 Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43679
[Bug libstdc++/43683] New: libstdc++ profile mode is not working on OpenSolaris (build 134) due to compilation failure
Hello,
I'm using:
ka...@thinkpad:/tmp/gcc-4.5.0-RC-20100406$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.5-rc0-20100412/libexec/gcc/i386-pc-solaris2.11/4.5.0/lto-wrapper
Target: i386-pc-solaris2.11
Configured with: /tmp/gcc-4.5.0-RC-20100406/configure
--prefix=/usr/local/gcc-4.5-rc0-20100412 --with-as=/usr/bin/gas --with-gnu-as
--with-ld=/usr/bin/ld --without-gnu-ld --enable-shared --enable-threads
--enable-languages=c++ --with-gmp-include=/usr/include/gmp
--with-mpfr-include=/usr/include/mpfr --with-mpc=/usr/local/gcc-4.5-reqs/
Thread model: posix
gcc version 4.5.0 20100406 (prerelease) (GCC)
and attempt to use libstdc++ profile mode on test:
#include vector
using namespace std;
int main() {
vectorint v;
for (int k = 0; k 1024; ++k) v.insert(v.begin(), k);
}
The problem is that it's compilation fails with:
In file included from
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_hash_func.h:51:0,
from
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler.h:400,
from
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/base.h:44,
from
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/vector:39,
from
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/vector:77,
from test.cc:1:
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:
In function â__gnu_profile::__mutex_t
__gnu_profile::__get___global_lock()â:
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:81:1:
error: no matching function for call to
â_pthread_mutex::_pthread_mutex(brace-enclosed initializer list)â
/usr/include/sys/types.h:404:31: note: candidates are:
_pthread_mutex::_pthread_mutex()
/usr/include/sys/types.h:404:31: note:
_pthread_mutex::_pthread_mutex(const _pthread_mutex)
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:
In constructor â__gnu_profile::__trace_base__object_info,
__stack_info::__trace_base() [with __object_info =
__gnu_profile::__hashfunc_info, __stack_info =
__gnu_profile::__hashfunc_stack_info]â:
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_hash_func.h:125:60:
instantiated from here
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:307:3:
error: no match for âoperator=â in
â((__gnu_profile::__trace_base__gnu_profile::__hashfunc_info,
__gnu_profile::__hashfunc_stack_info*)this)-__gnu_profile::__trace_base__gnu_profile::__hashfunc_info,
__gnu_profile::__hashfunc_stack_info::__stack_table_lock = {{0, 0, 0, 0,
19800}, {{{0}}}, 0}â
/usr/include/sys/types.h:404:31: note: candidate is: _pthread_mutex
_pthread_mutex::operator=(const _pthread_mutex)
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:
In constructor â__gnu_profile::__trace_base__object_info,
__stack_info::__trace_base() [with __object_info =
__gnu_profile::__container_size_info, __stack_info =
__gnu_profile::__container_size_stack_info]â:
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_container_size.h:190:74:
instantiated from here
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:307:3:
error: no match for âoperator=â in
â((__gnu_profile::__trace_base__gnu_profile::__container_size_info,
__gnu_profile::__container_size_stack_info*)this)-__gnu_profile::__trace_base__gnu_profile::__container_size_info,
__gnu_profile::__container_size_stack_info::__stack_table_lock = {{0, 0, 0, 0,
19800}, {{{0}}}, 0}â
/usr/include/sys/types.h:404:31: note: candidate is: _pthread_mutex
_pthread_mutex::operator=(const _pthread_mutex)
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:
In constructor â__gnu_profile::__trace_base__object_info,
__stack_info::__trace_base() [with __object_info =
__gnu_profile::__map2umap_info, __stack_info =
__gnu_profile::__map2umap_stack_info]â:
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_map_to_unordered_map.h:204:60:
instantiated from here
[Bug libstdc++/43683] libstdc++ profile mode is not working on OpenSolaris (build 134) due to compilation failure
--- Comment #1 from kgardas at objectsecurity dot com 2010-04-08 08:16 --- Created an attachment (id=20332) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20332action=view) preprocessed test.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43683
[Bug middle-end/40815] redundant neg instruction caused by loop-invariant
--- Comment #10 from mkuvyrkov at gcc dot gnu dot org 2010-04-08 08:20 --- Subject: Bug 40815 Author: mkuvyrkov Date: Thu Apr 8 08:20:36 2010 New Revision: 158105 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158105 Log: PR middle-end/40815 * tree-ssa-reassoc.c (broken_up_substracts): Rename to plus_negates. (negate_value): Move code to push elements to broken_up_substracts ... (eliminate_plus_minus_pair): ... here. Push operands that have no negative pair to plus_negates. (repropagate_negates, init_reassoc, fini_reassoc): Update. PR middle-end/40815 * gcc.dg/tree-ssa/reassoc-19.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-19.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40815
[Bug middle-end/40815] redundant neg instruction caused by loop-invariant
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2010-04-08 08:31 --- Fixed in the above revision. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40815
[Bug bootstrap/43681] [4.6 Regression] bootstrap fails with unused var message for an apparently used var.
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org Summary|bootstrap fails with|[4.6 Regression] bootstrap |unused var message for an |fails with unused var |apparently used var.|message for an apparently ||used var. Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43681
[Bug c++/43680] G++ is too aggressive in optimizing away bounds checking with enums
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-08 08:39 --- The middle-end trusts the C++ frontends TYPE_MIN/MAX_VALUE which is according to the C++ standard the range for an (unsigned) integer type with a precision just as wide as to represent all values in the enum. I did want to remove that optimization at some point but people complained that it was highly useful (the C++ FE can still set TYPE_PRECISION accordingly if it wants to, but TYPE_MIN/MAX_VALUE cannot really be trusted in the middle-end as conversions between integer types of same precision but different TYPE_MIN/MAX_VALUE are 1) useless and 2) do not produce code to truncate the values). It's VRP btw, that does this optimization. If I have your support I'll rip out this optimization from VRP ... (I didn't yet manage to create a wrong-code bug due to the useless conversion thing, but I believe that is possible). I also believe that the TYPE_MIN/MAX_VALUE on enums might be needed for proper debug information. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43680
[Bug c++/43680] G++ is too aggressive in optimizing away bounds checking with enums
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-08 08:40 --- Oh, and actually I don't think this bug is a wrong-code bug but at most a quality of implementation issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43680
[Bug bootstrap/43684] New: multiple 'set but not used' errors.
The following patches are proposed for both i686 and powerpc:
this is reasonably self-evident..
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00338.html
This one is in an area I've worked on - and I've checked that
-static-libgfortran is still doing its job (on i686-apple-darwin9).
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00329.html
This one is needed for both i686/powerpc - I have done the mechanical job of
removing the unused vars but cannot, of course, guarantee that the original
author intended them to be unused.
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00331.html
This one applies to powerpc only - I have done the mechanical job of removing
the unused vars but cannot, of course, guarantee that the original author
intended them to be unused.
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00345.html
PowerPC also needs the resolution to :
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43681
bootstrapped on {i686,powerpc}-apple-darwin9, ia32-pc-linux
(tests are in progress).
--
Summary: multiple 'set but not used' errors.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iains at gcc dot gnu dot org
GCC target triplet: *-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43684
[Bug bootstrap/43681] [4.6 Regression] bootstrap fails with unused var message for an apparently used var.
--- Comment #2 from iains at gcc dot gnu dot org 2010-04-08 08:59 --- (In reply to comment #1) Created an attachment (id=20331) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20331action=view) [edit] gcc46-pr43681.patch Untested patch. yes, thanks that works. - I couldn't see what to do there; see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43684 for the ones I think I can resolve. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43681
[Bug c++/43680] G++ is too aggressive in optimizing away bounds checking with enums
--- Comment #7 from manu at gcc dot gnu dot org 2010-04-08 09:02 --- (In reply to comment #1) Don't we already have a warning that warns about assigning values outside the range of an enum? pr43680.C:14:26: warning: the result of the conversion is unspecified because â5â is outside the range of type âEâ [-Wconversion] Implemented by yours truly in GCC 4.5. (or perhaps already in 4.4.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43680
[Bug tree-optimization/43679] [4.5/4.6 Regression] ice in gen_lsm_tmp_name, at tree-ssa-loop-im.c:1812
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-08 09:11 --- Unfolded *g_7 from PRE. I have a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43679
[Bug debug/43670] [4.5/4.6 Regression] -fcompare-debug failure (length) with -O -ftree-vrp
--- Comment #5 from jakub at gcc dot gnu dot org 2010-04-08 09:16 --- Subject: Bug 43670 Author: jakub Date: Thu Apr 8 09:16:28 2010 New Revision: 158108 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158108 Log: PR debug/43670 * cfgexpand.c (expand_debug_expr): If for non-NULL offset op0 is not a MEM, just return NULL instead of assertion failure. (discover_nonconstant_array_refs): Don't walk debug stmts. * gcc.dg/pr43670.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr43670.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43670
[Bug debug/43670] [4.5/4.6 Regression] -fcompare-debug failure (length) with -O -ftree-vrp
--- Comment #6 from jakub at gcc dot gnu dot org 2010-04-08 09:18 --- Subject: Bug 43670 Author: jakub Date: Thu Apr 8 09:17:52 2010 New Revision: 158109 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158109 Log: PR debug/43670 * cfgexpand.c (expand_debug_expr): If for non-NULL offset op0 is not a MEM, just return NULL instead of assertion failure. (discover_nonconstant_array_refs): Don't walk debug stmts. * gcc.dg/pr43670.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr43670.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/cfgexpand.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43670
[Bug target/43635] [4.5/4.6 Regression] ICE in s390_emit_call, at config/s390/s390.c:9484
--- Comment #5 from krebbel at gcc dot gnu dot org 2010-04-08 09:23 --- (In reply to comment #4) The extra cast happens if the function signatures are not compatible (by means of useless_type_conversion_p). Ok. Do you know why that behavior changed between gcc 4.4 and 4.5? Is there a way to obtain the function decl from D.1966_3 in the 4.5 example or do we really need to reject sibcall optimizations in that case? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43635
[Bug middle-end/41043] [4.4 Regression] virtual memory exhausted: Cannot allocate memory
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-04-08 09:23 --- 43627 is fallout and would need to be backported as well. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||43627 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41043
[Bug target/41653] not optimal result for multiplication with constant when -Os is specified
--- Comment #9 from carrot at gcc dot gnu dot org 2010-04-08 09:27 --- Subject: Bug 41653 Author: carrot Date: Thu Apr 8 09:27:44 2010 New Revision: 158110 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158110 Log: PR target/41653 * config/arm/arm.c (thumb1_size_rtx_costs): New function. (arm_size_rtx_costs): Call the new function when optimized for size. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41653
[Bug target/41653] not optimal result for multiplication with constant when -Os is specified
--- Comment #10 from carrot at google dot com 2010-04-08 09:29 --- Fixed by the above patch. -- carrot at google dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41653
[Bug libstdc++/43683] libstdc++ profile mode is not working on OpenSolaris (build 134) due to compilation failure
--- Comment #2 from paolo dot carlini at oracle dot com 2010-04-08 09:32 --- I don't think anybody is making promises that profile mode works everywhere... Anyway, CC-ing Silvius. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||rus at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43683
[Bug libstdc++/40518] data races when calling std::string::erase() on empty string
--- Comment #15 from paolo dot carlini at oracle dot com 2010-04-08 09:33 --- Re-open to.. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518
[Bug libstdc++/40518] data races when calling std::string::erase() on empty string
--- Comment #16 from paolo dot carlini at oracle dot com 2010-04-08 09:33 --- unassign myself -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518
[Bug libstdc++/40518] data races when calling std::string::erase() on empty string
--- Comment #17 from paolo dot carlini at oracle dot com 2010-04-08 09:34 --- . -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518
[Bug target/43677] #8216;__powitf2#8217;: unrecognizable insn
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-08 09:40 --- I can't seem to be able to reproduce this with r158106. How did you configure? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43677
[Bug libstdc++/35353] C++ wide character locale doesn't work
--- Comment #16 from paolo dot carlini at oracle dot com 2010-04-08 09:44 --- We may make progress on this for 4.6.0, but I don't make promises. If, after having studied the relevant bits of the Standard and the current implementation of these features (I remind you that this is Free Software, thus no mysteries, no need for black-box thinking) I would recommend going ahead and proposing a patch (after having filed the required Copyright Assignment). Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35353
[Bug target/43677] #8216;__powitf2#8217;: unrecognizable insn
--- Comment #2 from schwab at linux-m68k dot org 2010-04-08 09:45 --- configured by ../gcc/configure, generated by GNU Autoconf 2.64, with options '--prefix=/usr' '--build=x86_64-linux' '--enable-shared' '--enable-threads=posix' '--with-system-zlib' '--enable-__cxa_atexit' 'build_alias=x86_64-linux' 'CFLAGS=-O2 -g' 'CXXFLAGS=-O2 -g' '--enable-languages=c,c++,lto' -- schwab at linux-m68k dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-08 09:45:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43677
[Bug target/43635] [4.5/4.6 Regression] ICE in s390_emit_call, at config/s390/s390.c:9484
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-08 10:00 --- (In reply to comment #5) (In reply to comment #4) The extra cast happens if the function signatures are not compatible (by means of useless_type_conversion_p). Ok. Do you know why that behavior changed between gcc 4.4 and 4.5? It changed because of the gimple type system got a verifier. Is there a way to obtain the function decl from D.1966_3 in the 4.5 example or do we really need to reject sibcall optimizations in that case? You can do a lookup in the SSA web (well, but it'll be expanded as an indirect call probably - you have to check). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43635
[Bug bootstrap/43681] [4.6 Regression] bootstrap fails with unused var message for an apparently used var.
--- Comment #3 from jakub at gcc dot gnu dot org 2010-04-08 10:12 --- Subject: Bug 43681 Author: jakub Date: Thu Apr 8 10:12:35 2010 New Revision: 158111 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158111 Log: PR bootstrap/43681 * expr.c (block_move_libcall_safe_for_call_parm): Avoid set but not used variable warning. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43681
[Bug tree-optimization/43679] [4.5/4.6 Regression] ice in gen_lsm_tmp_name, at tree-ssa-loop-im.c:1812
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-08 10:21 --- Subject: Bug 43679 Author: rguenth Date: Thu Apr 8 10:21:23 2010 New Revision: 158112 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158112 Log: 2010-04-08 Richard Guenther rguent...@suse.de PR tree-optimization/43679 * tree-ssa-pre.c (eliminate): Only propagate copies. * gcc.c-torture/compile/pr43679.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr43679.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43679
[Bug target/43677] #8216;__powitf2#8217;: unrecognizable insn
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-08 10:24 --- Works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43677
[Bug tree-optimization/43679] [4.5/4.6 Regression] ice in gen_lsm_tmp_name, at tree-ssa-loop-im.c:1812
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-08 10:26 --- Subject: Bug 43679 Author: rguenth Date: Thu Apr 8 10:25:57 2010 New Revision: 158113 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158113 Log: 2010-04-08 Richard Guenther rguent...@suse.de PR tree-optimization/43679 * tree-ssa-pre.c (eliminate): Only propagate copies. * gcc.c-torture/compile/pr43679.c: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr43679.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43679
[Bug tree-optimization/43679] [4.5/4.6 Regression] ice in gen_lsm_tmp_name, at tree-ssa-loop-im.c:1812
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-08 10:26 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.5.1 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43679
[Bug libstdc++/40518] data races when calling std::string::erase() on empty string
--- Comment #18 from bart dot vanassche at gmail dot com 2010-04-08 10:28 --- (In reply to comment #12) In my opinion it's too late now, I'm not even sure a 4.4.4 will be released any time soon, and 4.5.0 is around the corner. But if Jon would also like to see it in 4.4.4 and wants to backport the patch I do not object. Please keep in mind that this behavior can have a severe negative impact on multithreaded C++ software that uses class std::string intensively because the unnecessary writes to _S_empty_rep_storage will cause unnecessary cache line bouncing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518
[Bug fortran/43685] New: libgfortran: Consider using __int128
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00354.html (review/committal pending) Currently, there is no C type for INTEGER(16); I think some code could be made more readable if one uses __int128 directly. -- Summary: libgfortran: Consider using __int128 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal 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=43685
[Bug libstdc++/40518] data races when calling std::string::erase() on empty string
--- Comment #19 from paolo dot carlini at oracle dot com 2010-04-08 10:33 --- Please keep in mind that nobody complained so far, over the last ~10 years, and 4.4 is close to its end of life. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518
[Bug lto/41588] [4.5 Regression] LTO bugs to be addressed before release
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-08 10:37 --- Supposed to be addressed before release except that they haven't. So let's make it a 4.5 Regression, which it is to some degree. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org Summary|LTO bugs to be addressed|[4.5 Regression] LTO bugs to |before release |be addressed before release http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41588
[Bug lto/41528] LTO needs better internal and user documentation
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-08 10:39 --- No progress since this PR was opened. Ping. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41528
[Bug lto/41576] LTO complains about mismatches in common sections
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-08 10:39 --- What happened to the patch mentioned in comment #1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41576
[Bug lto/43212] [LTO] error: control flow in the middle of basic block
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-08 10:43 --- Should LTO reject function declarations with incompatible attributes? Or should the discovery of the attribute in one translation unit be used to update the control flow graph in the other units (e.g. by writing out summaries for the attributes and have a stage in LTO that merges them)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43212
[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-04-08 10:47 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-04-08 10:47 --- Subject: Bug 43186 Author: rguenth Date: Thu Apr 8 10:46:46 2010 New Revision: 158114 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158114 Log: 2010-04-08 Richard Guenther rguent...@suse.de PR tree-optimization/43186 * params.def (PARAM_MAX_UNROLL_ITERATIONS): New param. * doc/invoke.texi (max-completely-peel-loop-nest-depth): Document. * tree-ssa-loop-ivcanon.c (tree_unroll_loops_completely): Limit unroller iterations. * gcc.c-torture/compile/pr43186.c: New testcase. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr43186.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/doc/invoke.texi branches/gcc-4_4-branch/gcc/params.def branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/tree-ssa-loop-ivcanon.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
[Bug c++/43680] G++ is too aggressive in optimizing away bounds checking with enums
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-04-08 10:48 --- I did want to remove that optimization at some point but people complained that it was highly useful (the C++ FE can still set TYPE_PRECISION accordingly if it wants to, but TYPE_MIN/MAX_VALUE cannot really be trusted in the middle-end as conversions between integer types of same precision but different TYPE_MIN/MAX_VALUE are 1) useless and 2) do not produce code to truncate the values). We had the exact same problem in Ada until 4.4, it has been solved by setting TYPE_MIN/MAX_VALUE to their canonical values... I also believe that the TYPE_MIN/MAX_VALUE on enums might be needed for proper debug information. ...and this one by providing a get_subrange_bounds lang hook. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43680
[Bug lto/41576] LTO complains about mismatches in common sections
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-08 11:01 --- They are still there and don't work completely. There is a more complete and proper solution in my mind but it's not implemented yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41576
[Bug target/43677] #8216;__powitf2#8217;: unrecognizable insn
--- Comment #4 from schwab at linux-m68k dot org 2010-04-08 11:04 --- Sorry, I had a broken experimental change that I forgot to remove. -- schwab at linux-m68k dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43677
[Bug lto/41584] WHOPR doesn't grok empty units
--- Comment #3 from steven at gcc dot gnu dot org 2010-04-08 11:09 --- Interestingly, LTO actually tries to use the original file name: /* Since SET does not need to be processed by LTRANS, use the original file name and mark it with a '*' prefix so that lto_execute_ltrans knows not to process it. */ cgraph_node_set_iterator si = csi_start (set); struct cgraph_node *first = csi_node (si); fname = prefix_name_with_star (first-local.lto_file_data-file_name); But it tries to take the file name from the first node in the call graph. And the reason why we try re-use the original file name, is because the call graph is empty. Strange logic... Maybe WHOPR should give a fatal error if the only set is empty. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-08 11:09:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41584
[Bug lto/43212] [LTO] error: control flow in the middle of basic block
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-08 11:23 --- We do have a fixup pass for this, but somehow it doesnt' work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43212
[Bug tree-optimization/43614] [4.4 Regression] ice in gimple_rhs_has_side_effects, at gimple.c:2248
--- Comment #7 from jakub at gcc dot gnu dot org 2010-04-08 11:28 --- Subject: Bug 43614 Author: jakub Date: Thu Apr 8 11:28:06 2010 New Revision: 158117 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158117 Log: Backport from mainline: 2010-04-01 Richard Guenther rguent...@suse.de PR middle-end/43614 * tree-ssa-address.c (copy_mem_ref_info): Copy TREE_SIDE_EFFECTS and TREE_THIS_VOLATILE. (copy_ref_info): Likewise. * tree-ssa-operands.c (get_tmr_operands): Check TREE_THIS_VOLATILE. * tree.c (build7_stat): Ignore side-effects of all but arg5 for TARGET_MEM_REF. Set TREE_THIS_VOLATILE from arg5 of TARGET_MEM_REF. * gcc.c-torture/compile/pr43614.c: New testcase. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr43614.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/tree-ssa-address.c branches/gcc-4_4-branch/gcc/tree-ssa-loop-ivopts.c branches/gcc-4_4-branch/gcc/tree-ssa-operands.c branches/gcc-4_4-branch/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43614
[Bug tree-optimization/43607] [4.3/4.4 Regression] ICE in gimple_op, at gimple.h:1633 with -fipa-type-escape
--- Comment #5 from jakub at gcc dot gnu dot org 2010-04-08 11:29 --- Subject: Bug 43607 Author: jakub Date: Thu Apr 8 11:29:28 2010 New Revision: 158118 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158118 Log: Backport from mainline: 2010-04-01 Richard Guenther rguent...@suse.de PR tree-optimization/43607 * ipa-type-escape.c (check_call): Do not access non-existing arguments. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/ipa-type-escape.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43607
[Bug tree-optimization/43560] [4.3/4.4 Regression] possible wrong code bug
--- Comment #12 from jakub at gcc dot gnu dot org 2010-04-08 11:31 --- Subject: Bug 43560 Author: jakub Date: Thu Apr 8 11:31:00 2010 New Revision: 158119 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158119 Log: Backport from mainline: 2010-03-29 Richard Guenther rguent...@suse.de PR tree-optimization/43560 * tree-ssa-loop-im.c (ref_always_accessed_p): Add store_p parameter. (can_sm_ref_p): Treat stores to readonly locations as trapping. * gcc.dg/torture/pr43560.c: New testcase. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr43560.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/tree-ssa-loop-im.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43560
[Bug tree-optimization/43614] [4.4 Regression] ice in gimple_rhs_has_side_effects, at gimple.c:2248
--- Comment #8 from jakub at gcc dot gnu dot org 2010-04-08 11:34 --- 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=43614
[Bug tree-optimization/43607] [4.3 Regression] ICE in gimple_op, at gimple.h:1633 with -fipa-type-escape
--- Comment #6 from jakub at gcc dot gnu dot org 2010-04-08 11:34 --- Fixed also for 4.4. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.2.4 4.5.0 |4.2.4 4.5.0 4.4.4 Summary|[4.3/4.4 Regression] ICE in |[4.3 Regression] ICE in |gimple_op, at gimple.h:1633 |gimple_op, at gimple.h:1633 |with -fipa-type-escape |with -fipa-type-escape http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43607
[Bug tree-optimization/43560] [4.3 Regression] possible wrong code bug
--- Comment #13 from jakub at gcc dot gnu dot org 2010-04-08 11:35 --- Fixed also for 4.4. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.4.6 4.5.0 |3.4.6 4.5.0 4.4.4 Summary|[4.3/4.4 Regression]|[4.3 Regression] possible |possible wrong code bug |wrong code bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43560
[Bug debug/43670] [4.5/4.6 Regression] -fcompare-debug failure (length) with -O -ftree-vrp
--- Comment #7 from jakub at gcc dot gnu dot org 2010-04-08 11:41 --- 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=43670
[Bug tree-optimization/42956] [4.4 Regression] internal compiler error: Segmentation fault with -O1
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-04-08 11:47 --- Subject: Bug 42956 Author: rguenth Date: Thu Apr 8 11:47:13 2010 New Revision: 158123 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158123 Log: 2010-04-08 Richard Guenther rguent...@suse.de PR middle-end/42956 * gimplify.c (gimple_fold_indirect_ref): Avoid generating new ARRAY_REFs on variable size element or minimal index arrays. * tree-ssa-loop-ivopts.c (find_interesting_uses_address): Use gimple_fold_indirect_ref. * gcc.c-torture/compile/pr42956.c: New testcase. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42956.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/gimplify.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42956
[Bug tree-optimization/42956] [4.4 Regression] internal compiler error: Segmentation fault with -O1
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-04-08 11:47 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42956
[Bug middle-end/43656] -fcompare-debug failure with -O2 -fschedule-insns -fsched-pressure -funroll-loops -fgraphite-identity
--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-08 11:53 --- Can't reproduce this with r158104. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43656
[Bug libgcj/40860] [4.4/4.5/4.6 regression] regressions in libjava testsuite on arm-linux
--- Comment #33 from mikpe at it dot uu dot se 2010-04-08 12:14 --- Created an attachment (id=20333) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20333action=view) eliminate use of _Unwind_GetRegionStart on ARM, part 1 Here's a preliminary patch to eliminate the functional dependency on _Unwind_GetRegionStart on ARM. There are two key changes: output_function_exception_table outputs a proper @LPStart pointer in each LSDA blob, and every PR's parse_lsda_header sets @Start to @LPstart if @Start is NULL. Without these updates making _Unwind_GetRegionStart return NULL on ARM causes massive regressions in the c++/objc/obj-c++ test suites, and some in the c and libffi test suites. With these updates those regressions are eliminated. There are however two new regressions: 1. There are several orders of magnitude more alignment exceptions during the test suite run, probably in the read_encoded_value calls that now trigger. 2. For initial testing I ran this on i686 with its _Unwind_GetRegionStart made to return NULL too, and while it worked the g++.old-deja/g++.law/weak.C test case failed with a linkage error. It looks like gcc emitted exception table data for a discarded piece of code. On my ARM box the test suite considered that test case UNSUPPORTED so never ran it. The first regression can probably be fixed by avoiding to define unneeded @LPStart pointers and making read_encoded_value mis-alignment safe. The second regression might be fixable by making the @LPStart symbol references weak. More fixes will be needed for libjava's stacktrace mess though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug middle-end/43656] -fcompare-debug failure with -O2 -fschedule-insns -fsched-pressure -funroll-loops -fgraphite-identity
--- Comment #3 from zsojka at seznam dot cz 2010-04-08 12:21 --- Created an attachment (id=20334) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20334action=view) testcase that crashes in r158095 When size of arrays is changed from 64 to 1000, it fails again in r158095 -- zsojka at seznam dot cz changed: What|Removed |Added Attachment #20318|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43656
[Bug c/43686] New: GCC doesn't duplicate computed gotos for functions marked as hot
I've found the bug working on direct threaded interpreter for PHP. Moving from
GCC 4.3 to GCC 4.4 caused a significant performance degradation. Looking into
produced assembler code I realized that GCC 4.4 doesn't replace all jmps to
indirect jmp with indirect jmp itself. The reason is the following new
condition in function duplicate_computed_gotos() bb-reorder.c
if (!optimize_bb_for_size_p (bb))
continue;
I thought I would able to fix the problem using hot attribute, but
according to this condition, in case I mark function with __attribute__((hot))
duplication doesn't work, and in case I mark it with __attribute__((cold)) it
starts work. As result hot function works slower than cold.
You can use the simplified code to verify it. I ran it with 'gcc -O2 -S
direct.c'
direct.c
#define NEXT goto **ip++
#define guard(n) asm(# #n)
__attribute__((cold)) void *emu (void **prog)
{
static void *labels[] =
{next1,next2,next3,next4,next5,next6,next7,next8,next9,loop};
void **ip;
intcount;
if (!prog) {
return labels;
}
ip=prog;
count = 1000;
NEXT;
next1:
guard(1);
NEXT;
next2:
guard(2);
NEXT;
next3:
guard(3);
NEXT;
next4:
guard(4);
NEXT;
next5:
guard(5);
NEXT;
next6:
guard(6);
NEXT;
next7:
guard(7);
NEXT;
next8:
guard(8);
NEXT;
next9:
guard(9);
NEXT;
loop:
if (count0) {
count--;
ip=prog;
NEXT;
}
return 0;
}
int main() {
void *prog[] = {(void*)0,(void*)1,
(void*)0,(void*)2,
(void*)0,(void*)3,
(void*)0,(void*)4,
(void*)0,(void*)9};
void **labels = emu(0);
int i;
for (i=0; i sizeof(prog)/sizeof(prog[0]); i++) {
prog[i] = labels[(int)prog[i]];
}
emu(prog);
return 0;
}
I saw that the check causing the slowdown was removed in trunk, however I can't
check that it was done in a proper way.
--
Summary: GCC doesn't duplicate computed gotos for functions
marked as hot
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dmitry at zend dot com
GCC build triplet: i686-redhat-linux
GCC host triplet: i686-redhat-linux
GCC target triplet: i686-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43686
[Bug lto/41528] LTO needs better internal and user documentation
--- Comment #2 from dnovillo at gcc dot gnu dot org 2010-04-08 12:51 --- (In reply to comment #1) No progress since this PR was opened. Ping. Yes, progress has been impossible until now. I expect to slowly getting some content written in the next little while. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-08 12:51:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41528
[Bug c++/43680] G++ is too aggressive in optimizing away bounds checking with enums
--- Comment #9 from bangerth at gmail dot com 2010-04-08 12:53 --- I'm not saying we *should* apply a mask (in fact, I think that would be silly). But we *could*, and if we did then VRP's actions might lead to faster but not different code. All I want to say is that VRP is a powerful tool. Let's not just throw the baby out with the bath water. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43680
[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends
--- Comment #14 from hubicka at gcc dot gnu dot org 2010-04-08 13:14 --- Adding a simple limit on number of loop nests in recursive inlining is easy thing to do, but I am not quite sure how useful it is (well, overall recursive inlining tends to help only few very special benchmrks). So the problem is that function body after inlinng is resonable but with unrolling it explodes? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-04-08 13:19 --- (In reply to comment #14) Adding a simple limit on number of loop nests in recursive inlining is easy thing to do, but I am not quite sure how useful it is (well, overall recursive inlining tends to help only few very special benchmrks). So the problem is that function body after inlinng is resonable but with unrolling it explodes? The main issue is that we are doing a very poor job in limiting the work we do during complete unrolling (as well as leaving as little work for subsequent passes as possible). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends
--- Comment #16 from hubicka at ucw dot cz 2010-04-08 13:26 --- Subject: Re: [4.4 Regression] A loop in tree_unroll_loops_completely never ends The main issue is that we are doing a very poor job in limiting the work we do during complete unrolling (as well as leaving as little work for subsequent passes as possible). Well, I guess in addition to number of instructions after optimizing we can also estimate number of instruction we actually produce by unrolling and have some cutoff (a lot bigger than for code size estimate growth) on those as well... Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
[Bug driver/43687] New: Unexpected error message for bad command line argument
I meant to use -Wl,--wrap but accidentally just used --wrap. Notice that the error message has turned it into -fwrap. This is confusing. [j...@iceland tmp]$ gcc --wrap -c m.c cc1: error: unrecognized command line option -fwrap [j...@iceland tmp]$ gcc --version gcc (GCC) 4.4.3 20100127 (Red Hat 4.4.3-4) -- Summary: Unexpected error message for bad command line argument Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43687
[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends
--- Comment #17 from rguenther at suse dot de 2010-04-08 13:29 --- Subject: Re: [4.4 Regression] A loop in tree_unroll_loops_completely never ends On Thu, 8 Apr 2010, hubicka at ucw dot cz wrote: --- Comment #16 from hubicka at ucw dot cz 2010-04-08 13:26 --- Subject: Re: [4.4 Regression] A loop in tree_unroll_loops_completely never ends The main issue is that we are doing a very poor job in limiting the work we do during complete unrolling (as well as leaving as little work for subsequent passes as possible). Well, I guess in addition to number of instructions after optimizing we can also estimate number of instruction we actually produce by unrolling and have some cutoff (a lot bigger than for code size estimate growth) on those as well... We do. But it all get's just smaller - but only after optimizing. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
[Bug target/43129] Simplify global variable's address loading with option -fpic
--- Comment #5 from carrot at google dot com 2010-04-08 13:31 --- (In reply to comment #4) I guess you'll have to experiment with your implementation to see what gives the best results on a large body of code. I will experiment on CSiBE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129
[Bug c/43686] GCC doesn't duplicate computed gotos for functions marked as hot
--- Comment #1 from mikpe at it dot uu dot se 2010-04-08 13:32 --- Duplicate of PR42621? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43686
[Bug tree-optimization/43688] New: ICE: in analyze_function, at ipa-reference.c:733 with -fipa-reference
Command line: gfortran -fipa-reference testcase.f90 Tested revisions: r158095 - crash Output: $ /mnt/svn/gcc-trunk/binary-158095-lto-fortran/bin/gfortran -fipa-reference testcase.f90 testcase.f90: In function #8216;sub#8217;: testcase.f90:8:0: internal compiler error: in analyze_function, at ipa-reference.c:733 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE: in analyze_function, at ipa-reference.c:733 with - fipa-reference Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43688
[Bug tree-optimization/43688] ICE: in analyze_function, at ipa-reference.c:733 with -fipa-reference
--- Comment #1 from zsojka at seznam dot cz 2010-04-08 13:38 --- Created an attachment (id=20335) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20335action=view) auto-reduced testcase reduced from gfortran.dg/subref_array_pointer_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43688
[Bug target/43671] [4.4/4.5/4.6 Regression] -fsched2-use-superblocks -m32 produces wrong code with vectorization
--- Comment #5 from matz at gcc dot gnu dot org 2010-04-08 13:40 --- Um, how can r138953 be the reason when (as the original report says) it's still okay with r153685? In any case, my patch just shuffled around the activation/non-activation of the scheduler, so if at all it exposed a latent bug in it, which given that -fsched2-use-superblocks isn't used by default is very likely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43671
[Bug target/43671] [4.4/4.5/4.6 Regression] -fsched2-use-superblocks -m32 produces wrong code with vectorization
--- Comment #6 from zsojka at seznam dot cz 2010-04-08 13:48 --- I am sorry for the confusion. The original testcase from comment #1 doesn't fail in r153685 and 4.4.3. Later I found different testcase (comment #2) that fails there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43671
[Bug libstdc++/40518] data races when calling std::string::erase() on empty string
--- Comment #20 from redi at gcc dot gnu dot org 2010-04-08 13:51 ---
You can still reduce the helgrind output with just one suppression
{
libstdcxx_std_string_race_pr40518
Helgrind:Race
fun:_ZNSs9_M_mutateEmmm
}
I'm not convinced the impact is severe, COW strings already have problems in
multiprocessor systems, I don't think erase() on empty strings is the
bottleneck! It's not been a problem in my own experience, and I'm not aware
of any distros having felt the need to backport the patch to their 4.4
packages.
I'll look into backporting it tonight on condition you cease the hyperbole
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518
[Bug c/43686] GCC doesn't duplicate computed gotos for functions marked as hot
--- Comment #2 from dmitry at zend dot com 2010-04-08 13:54 --- yes. It's definitely the same issue. The only additional note that __attribute__((hot)) doesn't fix the problem (as I would expect tracing down optimize_bb_for_size_p()), but makes an additional slowdown. In opposite, the __attribute__((cold)) solves the issue. It looks very strange. I suppose some condition has to be inverted :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43686
[Bug libstdc++/40518] data races when calling std::string::erase() on empty string
--- Comment #21 from paolo dot carlini at oracle dot com 2010-04-08 14:04 --- I'll look into backporting it tonight on condition you cease the hyperbole ^ That's why (among other reasons) I voted in favor of appointing Jon maintainer ;) Agreed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518
[Bug objc++/43689] New: const-str-5/6 fails
these two tests are failing at both m32 and m64. FAIL: obj-c++.dg/const-str-5.mm -fgnu-runtime (test for excess errors) Excess errors: built-in:0:0: warning: 'MyConstantString' has a field 'MyConstantString::_contents' whose type uses the anonymous namespace -- Summary: const-str-5/6 fails Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: iains at gcc dot gnu dot org GCC target triplet: *-apple-darwin9, ia32-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43689
[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends
--- Comment #18 from hubicka at ucw dot cz 2010-04-08 14:41 --- Subject: Re: [4.4 Regression] A loop in tree_unroll_loops_completely never ends Well, I guess in addition to number of instructions after optimizing we can also estimate number of instruction we actually produce by unrolling and have some cutoff (a lot bigger than for code size estimate growth) on those as well... We do. But it all get's just smaller - but only after optimizing. Yep, we compute what will get optimized out as constant expression after full unrolling. I guess we need to compute both values - one with taking these into account (i.e. estimating effect on the generated code) and one without (i.e. estimating effect on memory and time we will blow on this) and limit both... At least this is my backup plan for inliner if we ever run into case that the heuristic will blow up out of time and space by giving something that optimizes very well subsequently. I can play with this if this seems sane. (as I guess my unrolling estimate improvements are source of this issue) Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
[Bug target/43643] gcc -m64 -pg corrupts %rdx / %rcx register
--- Comment #3 from ro at gcc dot gnu dot org 2010-04-08 14:46 --- Mine. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Known to fail||4.4.4 4.5.0 4.6.0 Last reconfirmed|2010-04-05 10:06:06 |2010-04-08 14:46:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43643
[Bug target/43643] gcc -m64 -pg corrupts %rdx / %rcx register
--- Comment #4 from ro at gcc dot gnu dot org 2010-04-08 14:48 --- Subject: Bug 43643 Author: ro Date: Thu Apr 8 14:48:46 2010 New Revision: 158130 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158130 Log: gcc: PR target/43643 * config/i386/gmon-sol2.c [__x86_64__]: Properly restore %rcx. gcc/testsuite: PR target/43643 * gcc.dg/pr43643.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr43643.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/gmon-sol2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43643
[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends
--- Comment #19 from matz at gcc dot gnu dot org 2010-04-08 14:50 --- This seems rather like a hack for our not-so-capable loop unroller. The estimator already correctly knows that much of it will be optimized away, hence it would make more sense for the code emitter to also not emit useless things that the estimator already knows will be optimized away. It seems backward to have an additional limit on compile time/memory need for a transformation that we know will succeed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
[Bug target/43643] gcc -m64 -pg corrupts %rdx / %rcx register
--- Comment #5 from ro at gcc dot gnu dot org 2010-04-08 14:51 --- Subject: Bug 43643 Author: ro Date: Thu Apr 8 14:50:56 2010 New Revision: 158131 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158131 Log: gcc: PR target/43643 * config/i386/gmon-sol2.c [__x86_64__]: Properly restore %rcx. gcc/testsuite: PR target/43643 * gcc.dg/pr43643.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr43643.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/gmon-sol2.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43643
[Bug c/43690] New: Internal compiler error detected by avr-gcc.
avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib
--infodi--mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib
--libdir=/usr/lib --enabystem-zlib --enable-long-long --enable-nls
--without-included-gettext --disable-checking--build=i486-linux-gnu
--host=i486-linux-gnu --target=avr
Thread model: single
gcc version 4.3.4 (GCC)
Minimal source code causing the bug, removing any token makes the compiler work
OK. No header is to be included into this code to see the bug.
---
void doit( )
{
char *pk=0 ;
for(;;)
{
asm ( nop : :m(pk++) );
asm ( nop : :m(pk++) );
}
}
avr-gcc -Wall -mmcu=atmega128 -O3 -c -o /dev/null
/tmp/present-wddl-both-encrypt.c
/tmp/present-wddl-both-encrypt.c: In function doit:
/tmp/present-wddl-both-encrypt.c:2: internal compiler error: in
copy_reference_ops_from_ref, at tree-ssa-sccvn.c:577
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Note that removing -Wall does not remove the bug but that removing -O3
makes the compiler work OK.
Best regards.
--
Summary: Internal compiler error detected by avr-gcc.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: philippe dot hoogvorst at neuf dot fr
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43690
[Bug bootstrap/43681] [4.6 Regression] bootstrap fails with unused var message for an apparently used var.
--- Comment #4 from iains at gcc dot gnu dot org 2010-04-08 15:07 ---
bootstrapped {powerpc,i686}-apple-darwin9.
this is fixed.
(other 'set but not used' issues at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43684 remain)
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43681
[Bug target/38085] gcc -m64 -pg generates invalid assembler code on Solaris 10/x86
--- Comment #12 from ro at gcc dot gnu dot org 2010-04-08 15:09 --- Subject: Bug 38085 Author: ro Date: Thu Apr 8 15:09:17 2010 New Revision: 158133 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158133 Log: gcc: PR target/43643 * config/i386/gmon-sol2.c [__x86_64__]: Properly restore %rcx. gcc/testsuite: PR target/43643 * gcc.dg/pr43643.c: New test. gcc: Backport from mainline: 2010-03-22 Rainer Orth r...@cebitec.uni-bielefeld.de PR target/38085 * config/i386/i386.c (x86_function_profiler) [!NO_PROFILE_COUNTERS]: Fix typo. * config/i386/gmon-sol2.c (_mcleanup) [__x86_64__]: Use call instead of callq. libgcc: Backport from mainline: 2010-03-22 Rainer Orth r...@cebitec.uni-bielefeld.de PR target/38085 * config/i386/t-sol2 ($(T)gmon.o): Use CFLAGS instead of MULTILIB_CFLAGS. ($(T)gcrt1.o): Likewise. ($(T)crt1.o): Likewise. ($(T)crti.o): Likewise. ($(T)crtn.o): Likewise. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr43643.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/i386/gmon-sol2.c branches/gcc-4_4-branch/gcc/config/i386/i386.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/libgcc/ChangeLog branches/gcc-4_4-branch/libgcc/config/i386/t-sol2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38085
[Bug target/43643] gcc -m64 -pg corrupts %rdx / %rcx register
--- Comment #6 from ro at gcc dot gnu dot org 2010-04-08 15:09 --- Subject: Bug 43643 Author: ro Date: Thu Apr 8 15:09:17 2010 New Revision: 158133 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158133 Log: gcc: PR target/43643 * config/i386/gmon-sol2.c [__x86_64__]: Properly restore %rcx. gcc/testsuite: PR target/43643 * gcc.dg/pr43643.c: New test. gcc: Backport from mainline: 2010-03-22 Rainer Orth r...@cebitec.uni-bielefeld.de PR target/38085 * config/i386/i386.c (x86_function_profiler) [!NO_PROFILE_COUNTERS]: Fix typo. * config/i386/gmon-sol2.c (_mcleanup) [__x86_64__]: Use call instead of callq. libgcc: Backport from mainline: 2010-03-22 Rainer Orth r...@cebitec.uni-bielefeld.de PR target/38085 * config/i386/t-sol2 ($(T)gmon.o): Use CFLAGS instead of MULTILIB_CFLAGS. ($(T)gcrt1.o): Likewise. ($(T)crt1.o): Likewise. ($(T)crti.o): Likewise. ($(T)crtn.o): Likewise. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr43643.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/i386/gmon-sol2.c branches/gcc-4_4-branch/gcc/config/i386/i386.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/libgcc/ChangeLog branches/gcc-4_4-branch/libgcc/config/i386/t-sol2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43643
[Bug middle-end/43690] [4.3/4.4/4.5 Regression] Internal compiler error detected by avr-gcc.
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-08 15:11 ---
Well, we have not properly gimplified the invalid function:
doit ()
{
char * pk;
char * pk.1;
char * pk.0;
bb 2:
pk = 0B;
bb 3:
__asm__ __volatile__(nop::m pk);
pk = pk + 1;
pk.0 = pk;
__asm__ __volatile__(nop::m pk.0);
pk.1 = pk.0 + 1;
pk = pk.1;
goto bb 3;
pk is addressable, so pk + 1 needs to load from pk first.
3.4.x prints
t.i: In function `doit':
t.i:6: warning: use of memory input without lvalue in asm operand 0 is
deprecated
t.i:7: warning: use of memory input without lvalue in asm operand 0 is
deprecated
t.i:6: error: impossible constraint in `asm'
t.i:7: error: impossible constraint in `asm'
so we ICE on the invalid asm.
We also fail to diagnose this with newer compilers (but the gimple verifier
triggers with checking enabled).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |middle-end
Ever Confirmed|0 |1
GCC build triplet|i486-linux-gnu |
GCC host triplet|i486-linux-gnu |
GCC target triplet|avr |
Keywords||diagnostic, ice-on-invalid-
||code
Known to fail||4.1.2 4.3.4 4.4.4 4.5.0
||4.6.0
Known to work||3.4.6
Last reconfirmed|-00-00 00:00:00 |2010-04-08 15:11:43
date||
Summary|Internal compiler error |[4.3/4.4/4.5 Regression]
|detected by avr-gcc.|Internal compiler error
||detected by avr-gcc.
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43690
[Bug target/43643] gcc -m64 -pg corrupts %rdx / %rcx register
--- Comment #7 from ro at gcc dot gnu dot org 2010-04-08 15:12 --- Fixed for 4.4.4, 4.5.0, 4.6.0. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.4.4 4.5.0 4.6.0 | Known to work||4.4.4 4.5.0 4.6.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43643
[Bug target/38085] gcc -m64 -pg generates invalid assembler code on Solaris 10/x86
--- Comment #13 from ro at gcc dot gnu dot org 2010-04-08 15:13 --- Reopen to document backport. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38085
[Bug target/38085] gcc -m64 -pg generates invalid assembler code on Solaris 10/x86
--- Comment #14 from ro at gcc dot gnu dot org 2010-04-08 15:14 --- Fixed for 4.4.4, 4.5.0. -- ro at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||03/msg00609.html Status|REOPENED|RESOLVED Keywords||patch Known to work||4.4.4 4.5.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38085
[Bug tree-optimization/43688] ICE: in analyze_function, at ipa-reference.c:733 with -fipa-reference
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-08 15:18 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2010-04-08 15:18:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43688
[Bug testsuite/43495] gcc.c-torture/execute/20000603-1.c fails with -fpic/-fPIC
--- Comment #5 from zsojka at seznam dot cz 2010-04-08 15:35 --- Created an attachment (id=20336) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20336action=view) testcase with inlined f() Even when the f() is declared as static inline __attribute__((always_inline)) double f(struct s1 *a, struct s2 *b) the testcase still fails with: $ gcc -fschedule-insns -fstrict-aliasing pr43495-2.c ./a.out Aborted -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43495
[Bug testsuite/43495] gcc.c-torture/execute/20000603-1.c fails with -fpic/-fPIC
--- Comment #6 from zsojka at seznam dot cz 2010-04-08 15:38 --- Testcase from comment #5 fails at x86_64-linux, trunk r153685, r158095. It doesn't fail in the 4.4 branch. -- zsojka at seznam dot cz changed: What|Removed |Added CC||zsojka at seznam dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43495
[Bug c++/43680] G++ is too aggressive in optimizing away bounds checking with enums
--- Comment #10 from jason at gcc dot gnu dot org 2010-04-08 15:57 --- @7: But -Wconversion only warns if it knows the constant value, it doesn't warn about converting from an arbitrary int variable such as (importantly) a loop counter. @5: It seems appropriate to me for VRP to optimize based on TYPE_MIN/MAX_VALUE, the problem is that the front end is lying; either we need to apply a mask on conversion to the enum, or we should set TYPE_MIN/MAX_VALUE to the appropriate values for the mode. My preference is for the latter, and it sounds like Ada made the same choice. The debugging backends don't seem to care about TYPE_MIN/MAX_VALUE for enums. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43680
[Bug target/43669] libgcc build fails with Error: cannot represent subtraction with an offset
--- Comment #2 from sterling_augustine at tensilica dot com 2010-04-08 16:05 --- (Removed Bob Wilson who is no longer maintaining the Xtensa port.) This problem was actually a limitation in the gnu assembler, and is fixed there. Unfortunately, this change didn't make it into the binutils 2.20.1 release, so your only option is to apply the patch described in the message here: http://sourceware.org/ml/binutils/2009-09/msg00546.html -- sterling_augustine at tensilica dot com changed: What|Removed |Added CC|bob dot wilson at acm dot | |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43669
[Bug c/43691] New: Code segfault when compiled with -Os, -O2, or -O3
When this testcase, using inline assembly, is compiled with -Os, -O2, or -O3 it segfaults. -O0 and -O1 allow it to run correctly. Moving the inline assembly into a separate file and including it in the compilation allow the program to run correctly at all -O levels. My results are gcc -O0 -mcpu=ev67 -D__FAIL rewritten.S test.c -o test ./test # works gcc -O1 -mcpu=ev67 -D__FAIL rewritten.S test.c -o test ./test # works gcc -Os -mcpu=ev67 -D__FAIL rewritten.S test.c -o test ./test # segfault gcc -O2 -mcpu=ev67 -D__FAIL rewritten.S test.c -o test ./test # segfault gcc -O3 -mcpu=ev67 -D__FAIL rewritten.S test.c -o test ./test # segfault Compiling without -D__FAIL causes the external assembly in rewritten.S to be used. Without -D__FAIL, the program runs correctly at all -O levels. -- Summary: Code segfault when compiled with -Os, -O2, or -O3 Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mattst88 at gmail dot com GCC build triplet: alpha-unknown-linux-gnu GCC host triplet: alpha-unknown-linux-gnu GCC target triplet: alpha-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43691
[Bug c/43691] Code segfault when compiled with -Os, -O2, or -O3
--- Comment #1 from mattst88 at gmail dot com 2010-04-08 16:50 --- Created an attachment (id=20337) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20337action=view) rewritten.S - external assembly -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43691
[Bug c/43691] Code segfault when compiled with -Os, -O2, or -O3
--- Comment #2 from mattst88 at gmail dot com 2010-04-08 16:50 --- Created an attachment (id=20338) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20338action=view) test.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43691
