Side effects on memory access
Hi there. I'm looking at porting GCC to a new architecture which has a quite small instruction set and I'm afraid I can't figure out how to represent unintended side effects on instructions. My current problem is accessing memory. Reading an aligned 32 bit word is simple using LOADACC, (X). Half words and bytes are harder as the only instruction available is a load byte with post increment 'LOADACC, (X+)'. How can I tell GCC that loading a byte also increases the pointer register? My first version reserved one of the pointer registers and threw away the modified value but this is inefficient. I suspect that some type of clobber or define_expand is required but I can't figure it out. Thanks for any help, -- Michael
Re: [m32c] IRA reload failures in libstdc++
Any ideas? This: Reload 0: reload_in (SI) = (reg/f:SI 25 [ __i1$_M_current ]) A_REGS, RELOAD_FOR_OTHER_ADDRESS (opnum = 0) reload_in_reg: (reg/f:SI 25 [ __i1$_M_current ]) cannot be satisfied because there is no A_REGS register acceptable in SImode. I suggest making reload reload the PSImode subreg instead, and make the m32c machine description provide for a tertiary reload so that the value can be loaded truncated. Any thoughts on why gcc has so many problems with this chip? Having BASE_REG_CLASS with only two members is pretty extreme. Likewise for not being able to reload an address in an integral mode. When you labour on keeping this port working, you are on the bleeding edge of reload limitations. I remember when DImode additions caused i386 (elf) PIC reload problems - but compared with m32c, the i386 integer programming model is compiler-friendly ;-)
[lto] Problems with cgraph_state updating
Jan,
I've run into a problem with cgraph_state that illustrates some of the
issues I have with the cgraph machinery. We are currently relying on
pass_all_early_optimizations to move cgraph_state from
CGRAPH_STATE_IPA to CGRAPH_STATE_IPA_SSA:
static unsigned int
execute_early_local_optimizations (void)
{
/* First time we start with early optimization we need to advance
cgraph state so newly inserted functions are also early optimized.
However we execute early local optimizations for lately inserted
functions, in that case don't reset cgraph state back to IPA_SSA. */
if (cgraph_state CGRAPH_STATE_IPA_SSA)
cgraph_state = CGRAPH_STATE_IPA_SSA;
return 0;
}
The problem is that when lto1 is running, we do not execute this pass
because it is not needed (it was already executed during cc1/cc1plus),
so this state transition never takes place.
I think there are two problematic aspects to this. First, the very
existence of cgraph_state as a global variable accessible from
anywhere. This variable is checked during SSA verification, so the
verifiers are context sensitive. We should, at the very least, hide
this variable from outside of the cgraph machinery.
The other problem is that we are relying on an optimization pass to
set properties for the cgraph, this should be something done by the
pass manager itself or the cgraph routines (maybe via a TODO_*). I've
replicated this update inside ipa_passes() but this is sub-optimal.
So, there should be a clear state transition in the cgraph and the
transition should be controlled by cgraph/pass-manager code. Where
could that be?
Thanks. Diego.
Re: For backend maintainers: changes for C++ compatibility
Hi Ian, I would like to ask the maintainers for backends which I did not mention to bootstrap their targets if possible, and/or to build them with a newly built mainline compiler, to see if there are new warnings about C++ compatibility. For the record I have tested the fr30, iq2000, m32r, mcore, v850 and xstormy16 backends and they have no problems. Cheers Nick
[plugins] Branch closed
The only patch remaining to move from the plugins branch are the testsuite changes, which are waiting for review (http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01238.html). I am closing the branch for now. Any new plugin development should be done on mainline. However, we may want to reopen the branch if there is any new development that would not be ready in time for stage1/stage2. Diego.
EH tree is invalid
On gcc-trunk my project fails with the following ICE. Whatever it means... /home/piotr.wyderski/topnotch/vm/test/main.cpp: In function 'int main(int, char**)': /home/piotr.wyderski/topnotch/vm/test/main.cpp:32: error: Wrong prev_try pointer in EH region 123 Eh tree: 100 catch tree_label:L141 may_contain_throw prev: 97 type: 102 must_not_throw tree_label:L143 may_contain_throw 101 cleanup tree_label:L142 may_contain_throw 97 catch tree_label:L137 may_contain_throw prev: 94 next 100 type:struct exception 99 must_not_throw tree_label:L139 may_contain_throw 98 cleanup tree_label:L138 may_contain_throw 94 catch tree_label:L134 may_contain_throw next 97 type:struct rc_ptr 96 must_not_throw tree_label:L136 may_contain_throw 95 cleanup tree_label:L135 may_contain_throw 1 try may_contain_throw catch regions: 94 97 100 93 must_not_throw tree_label:L132 may_contain_throw 2 cleanup tree_label:L131 may_contain_throw prev try:1 92 must_not_throw tree_label:L129 may_contain_throw 3 cleanup tree_label:L128 may_contain_throw prev try:1 91 must_not_throw tree_label:L126 may_contain_throw 4 cleanup tree_label:L125 may_contain_throw prev try:1 90 must_not_throw tree_label:L123 may_contain_throw 5 cleanup tree_label:L122 may_contain_throw prev try:1 89 must_not_throw tree_label:L120 may_contain_throw 6 cleanup tree_label:L119 may_contain_throw prev try:1 88 must_not_throw tree_label:L117 may_contain_throw 7 cleanup tree_label:L116 may_contain_throw prev try:1 87 must_not_throw tree_label:L114 may_contain_throw 8 cleanup tree_label:L113 may_contain_throw prev try:1 86 must_not_throw tree_label:L111 may_contain_throw 9 cleanup tree_label:L110 may_contain_throw prev try:1 85 must_not_throw tree_label:L108 may_contain_throw 10 cleanup tree_label:L107 may_contain_throw prev try:1 84 must_not_throw tree_label:L105 may_contain_throw 11 cleanup tree_label:L104 may_contain_throw prev try:1 83 must_not_throw tree_label:L102 may_contain_throw 34 cleanup tree_label:L101 may_contain_throw prev try:1 82 must_not_throw tree_label:L99 may_contain_throw 37 cleanup tree_label:L98 may_contain_throw prev try:1 81 must_not_throw tree_label:L96 may_contain_throw 40 cleanup tree_label:L95 may_contain_throw prev try:1 80 must_not_throw tree_label:L93 may_contain_throw 43 cleanup tree_label:L92 may_contain_throw prev try:1 79 must_not_throw tree_label:L90 may_contain_throw 46 cleanup tree_label:L89 may_contain_throw prev try:1 78 must_not_throw tree_label:L87 may_contain_throw 49 cleanup tree_label:L86 may_contain_throw prev try:1 77 must_not_throw tree_label:L84 may_contain_throw 52 cleanup tree_label:L83 may_contain_throw prev try:1 76 must_not_throw tree_label:L81 may_contain_throw 55 cleanup tree_label:L80 may_contain_throw prev try:1 75 must_not_throw 56 cleanup tree_label:L78 may_contain_throw prev try:1 74 must_not_throw tree_label:L76 may_contain_throw 57 cleanup tree_label:L75 may_contain_throw prev try:1 73 must_not_throw tree_label:L73 may_contain_throw 58 cleanup tree_label:L72 may_contain_throw prev try:1 72 must_not_throw tree_label:L70 may_contain_throw 59 cleanup tree_label:L69 may_contain_throw prev try:1 71 must_not_throw tree_label:L67 may_contain_throw 60 cleanup tree_label:L66 may_contain_throw prev try:1 70 must_not_throw tree_label:L64 may_contain_throw 61 cleanup tree_label:L63 may_contain_throw prev try:1 69 must_not_throw tree_label:L61 may_contain_throw 62 cleanup tree_label:L60 may_contain_throw prev try:1
Re: EH tree is invalid
On Tue, Apr 21, 2009 at 3:56 PM, Piotr Wyderski piotr.wyder...@gmail.com wrote: On gcc-trunk my project fails with the following ICE. Whatever it means... /home/piotr.wyderski/topnotch/vm/test/main.cpp: In function 'int main(int, char**)': /home/piotr.wyderski/topnotch/vm/test/main.cpp:32: error: Wrong prev_try pointer in EH region 123 Eh tree: 100 catch tree_label:L141 may_contain_throw prev: 97 type: 102 must_not_throw tree_label:L143 may_contain_throw 101 cleanup tree_label:L142 may_contain_throw 97 catch tree_label:L137 may_contain_throw prev: 94 next 100 type:struct exception 99 must_not_throw tree_label:L139 may_contain_throw 98 cleanup tree_label:L138 may_contain_throw 94 catch tree_label:L134 may_contain_throw next 97 type:struct rc_ptr 96 must_not_throw tree_label:L136 may_contain_throw 95 cleanup tree_label:L135 may_contain_throw 1 try may_contain_throw catch regions: 94 97 100 93 must_not_throw tree_label:L132 may_contain_throw 2 cleanup tree_label:L131 may_contain_throw prev try:1 92 must_not_throw tree_label:L129 may_contain_throw 3 cleanup tree_label:L128 may_contain_throw prev try:1 91 must_not_throw tree_label:L126 may_contain_throw 4 cleanup tree_label:L125 may_contain_throw prev try:1 90 must_not_throw tree_label:L123 may_contain_throw 5 cleanup tree_label:L122 may_contain_throw prev try:1 89 must_not_throw tree_label:L120 may_contain_throw 6 cleanup tree_label:L119 may_contain_throw prev try:1 88 must_not_throw tree_label:L117 may_contain_throw 7 cleanup tree_label:L116 may_contain_throw prev try:1 87 must_not_throw tree_label:L114 may_contain_throw 8 cleanup tree_label:L113 may_contain_throw prev try:1 86 must_not_throw tree_label:L111 may_contain_throw 9 cleanup tree_label:L110 may_contain_throw prev try:1 85 must_not_throw tree_label:L108 may_contain_throw 10 cleanup tree_label:L107 may_contain_throw prev try:1 84 must_not_throw tree_label:L105 may_contain_throw 11 cleanup tree_label:L104 may_contain_throw prev try:1 83 must_not_throw tree_label:L102 may_contain_throw 34 cleanup tree_label:L101 may_contain_throw prev try:1 82 must_not_throw tree_label:L99 may_contain_throw 37 cleanup tree_label:L98 may_contain_throw prev try:1 81 must_not_throw tree_label:L96 may_contain_throw 40 cleanup tree_label:L95 may_contain_throw prev try:1 80 must_not_throw tree_label:L93 may_contain_throw 43 cleanup tree_label:L92 may_contain_throw prev try:1 79 must_not_throw tree_label:L90 may_contain_throw 46 cleanup tree_label:L89 may_contain_throw prev try:1 78 must_not_throw tree_label:L87 may_contain_throw 49 cleanup tree_label:L86 may_contain_throw prev try:1 77 must_not_throw tree_label:L84 may_contain_throw 52 cleanup tree_label:L83 may_contain_throw prev try:1 76 must_not_throw tree_label:L81 may_contain_throw 55 cleanup tree_label:L80 may_contain_throw prev try:1 75 must_not_throw 56 cleanup tree_label:L78 may_contain_throw prev try:1 74 must_not_throw tree_label:L76 may_contain_throw 57 cleanup tree_label:L75 may_contain_throw prev try:1 73 must_not_throw tree_label:L73 may_contain_throw 58 cleanup tree_label:L72 may_contain_throw prev try:1 72 must_not_throw tree_label:L70 may_contain_throw 59 cleanup tree_label:L69 may_contain_throw prev try:1 71 must_not_throw tree_label:L67 may_contain_throw 60 cleanup tree_label:L66 may_contain_throw prev try:1 70 must_not_throw tree_label:L64 may_contain_throw 61 cleanup tree_label:L63 may_contain_throw prev try:1 69 must_not_throw tree_label:L61 may_contain_throw
Re: EH tree is invalid
Richard Guenther wrote: Please file a bugreport in bugzilla and attach preprocessed source. Impossible, the source code is proprietary. But perhaps I can try to prepare a simplified testcase though... Best regards Piotr Wyderski
Re: EH tree is invalid
Piotr Wyderski wrote: On gcc-trunk my project fails with the following ICE. Whatever it means... Are you using SJLJ or DW2 exceptions? If SJLJ, does the patch at http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01628.html help the problem? cheers, DaveK
Re: EH tree is invalid
Dave Korn wrote: Are you using SJLJ or DW2 exceptions? SJLJ only -- DW2 doesn't work on Windows if the exception handling scope crosses DLL boundaries. If SJLJ, does the patch at http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01628.html help the problem? Hm, it seems that rev 146517 does not build on Cygwin, so I am unable to check it right now. But I'll try the patch ASAB (as soon as buildable :D) make[3]: Entering directory `/home/piotr.wyderski/build/gcc-trunk/objdir/gcc' /home/piotr.wyderski/build/gcc-trunk/objdir/./prev-gcc/xgcc -B/home/piotr.wyders ki/build/gcc-trunk/objdir/./prev-gcc/ -B/opt/gcc-4.5-trunk/i686-pc-cygwin/bin/ - c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prot otypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribut e -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../in clude -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../../gcc/../ libdecnumber/dpd -I../libdecnumber../../gcc/sdbout.c -o sdbout.o cc1: warnings being treated as errors ../../gcc/sdbout.c: In function 'sdbout_symbol': ../../gcc/sdbout.c:773: error: enum conversion when passing argument 2 of 'elimi nate_regs' is invalid in C++ ../../gcc/reload.h:346: note: expected 'enum machine_mode' but argument is of ty pe 'int' ../../gcc/sdbout.c: In function 'sdbout_parms': ../../gcc/sdbout.c:1274: error: enum conversion when passing argument 2 of 'elim inate_regs' is invalid in C++ ../../gcc/reload.h:346: note: expected 'enum machine_mode' but argument is of ty pe 'int' Best regards Piotr Wyderski
Re: Side effects on memory access
Michael Hope micha...@juju.net.nz writes:
Hi there. I'm looking at porting GCC to a new architecture which has
a quite small instruction set and I'm afraid I can't figure out how to
represent unintended side effects on instructions.
My current problem is accessing memory. Reading an aligned 32 bit
word is simple using LOADACC, (X). Half words and bytes are harder as
the only instruction available is a load byte with post increment
'LOADACC, (X+)'.
Wow.
How can I tell GCC that loading a byte also increases the pointer
register? My first version reserved one of the pointer registers and
threw away the modified value but this is inefficient. I suspect that
some type of clobber or define_expand is required but I can't figure
it out.
Well, you can use a define_expand to generate the move in the first
place. If can_create_pseudo_p() returns true, then you can call
copy_to_reg (addr) to get the address into a register, and you can
generate the post increment.
(define_expand movhi
...
if (can_create_pseudo_p () MEM_P (operands[1]))
{
rtx reg = copy_to_reg (XEXP (operands[1], 0));
emit_insn (gen_movhi_insn (operands[0], reg));
DONE;
}
...
)
(define_insn movhi_insn
[(set (match_operand:HI 0 ...)
(mem:HI (post_inc:P (match_operand:P 1 register_operand ...]
...
)
The difficulties are going to come in reload. Reload will want to load
and store 16-bit values in order to spill registers. You will need a
scratch register to dothis, and that means that you need to implement
TARGET_SECONDARY_RELOAD. This is complicated:read the docs carefully
and look at the existing examples.
Ian
Re: GCC 4.3.2 bug (was: Illegal subtraction in tmp-dive_1.s)
On 2009-04-20 15:17:44 +0200, Vincent Lefevre wrote: On 2009-04-17 12:09:42 -0500, Gabriel Dos Reis wrote: At least, let's get it archived on GCC mailing lists. Is it a bug that has been identified? FYI, this has been fixed in the 4.3 branch in r143494. This was PR tree-optimization/36765. -- Vincent Lefèvre vinc...@vinc17.org - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Re: EH tree is invalid
Piotr Wyderski wrote:
Dave Korn wrote:
Are you using SJLJ or DW2 exceptions?
SJLJ only -- DW2 doesn't work on Windows if the exception
handling scope crosses DLL boundaries.
It does these days as long as you're using shared libraries, but that's a
separate issue.
If SJLJ, does the patch at
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01628.html
help the problem?
Hm, it seems that rev 146517 does not build on Cygwin,
so I am unable to check it right now. But I'll try the patch
ASAB (as soon as buildable :D)
I just ran into this problem as well, try the attached.
cheers,
DaveK
Index: gcc/sdbout.c
===
--- gcc/sdbout.c (revision 146515)
+++ gcc/sdbout.c (working copy)
@@ -771,7 +771,7 @@
return;
SET_DECL_RTL (decl,
- eliminate_regs (DECL_RTL (decl), 0, NULL_RTX));
+ eliminate_regs (DECL_RTL (decl), VOIDmode, NULL_RTX));
#ifdef LEAF_REG_REMAP
if (current_function_uses_only_leaf_regs)
leaf_renumber_regs_insn (DECL_RTL (decl));
@@ -1271,9 +1271,9 @@
/* Perform any necessary register eliminations on the parameter's rtl,
so that the debugging output will be accurate. */
DECL_INCOMING_RTL (parms)
- = eliminate_regs (DECL_INCOMING_RTL (parms), 0, NULL_RTX);
+ = eliminate_regs (DECL_INCOMING_RTL (parms), VOIDmode, NULL_RTX);
SET_DECL_RTL (parms,
- eliminate_regs (DECL_RTL (parms), 0, NULL_RTX));
+ eliminate_regs (DECL_RTL (parms), VOIDmode, NULL_RTX));
if (PARM_PASSED_IN_MEMORY (parms))
{
GCC 4.4.1 Status Report (2009-04-21)
Status == GCC 4.4.0 has been built and uploaded today and 4.4 branch is open under release branch rules for regression and documentation fixes leading to the 4.4.1 release; the release will be announced once time has been allowed for mirrors to pick up the files. It is likely that 4.4.1 will be released in about two months' time. Quality Data Priority # Change from Last Report --- --- P10 +- 0 P2 75 - 2 P39 + 8 --- --- Total84 + 6 Previous Report === http://gcc.gnu.org/ml/gcc/2009-04/msg00406.html The next report for 4.4.1 will be sent by Mark. -- Joseph S. Myers jos...@codesourcery.com
GCC 4.5.0 Status Report (2009-04-21)
Status == Trunk is in Stage 1. It is expected that Stage 1 will last at least four months (so ending no earlier than 27 July) and will be followed by Stage 3 (bug-fix-only mode); whether it ends on 27 July may depend on whether there remain unmerged features at that date that we wish to merge for 4.5 and that seem sufficiently close to being ready to merge to make it worth delaying the end of Stage 1. Branches merged to trunk so far include alias-improvements, c-4_5-branch and plugins. Various changes have merged from gcc-in-cxx and lto that are prerequisites for the main objects of those branches. Quality Data (Figures for changes are relative to today's 4.4 report as there have been no previous 4.5 reports.) Priority # Change from Last Report --- --- P10 +- 0 P2 73 - 2 P3 15 + 6 --- --- Total88 + 4 Previous Report === http://gcc.gnu.org/ml/gcc/2009-04/msg00564.html (4.4 report) The next report for 4.5.0 will be sent by Mark. -- Joseph S. Myers jos...@codesourcery.com
http://gcc.gnu.org/gcc-4.4/changes.html
A couple changes in gcc 4.4.0 were omitted for the darwin target. The gcc 4.4.0 release now supports a full multilib build on the x86_64-apple-darwin9 and x86_64-apple-darwin10 targets. The gfortran compiler is now capable of generating binaries linked against the static libgfortran library using the compiler option -static-libgfortran. FYI. Jack
Enable Ada when there is an Ada compiler? (Was: [PATCH] Simplified switch conversion in simple cases)
Hi, What about enabling Ada build in 4.5 when configure finds out a suitable Ada compiler? Laurent On Tue, 2009-04-21 at 22:28 +0200, Eric Botcazou wrote: This breaks Ada on x86:
Inefficient loads in certain loops depending on data declaration
Dear all,
As I work through handling load multiples and store multiples for my
target architecture, I came in front of this scenario:
int foo(int data[10240])
{
int w0, w1;
int part = 0,i ;
for (i=0; i1;i+=2){
w0 = data[i];
w1 = data[i+1];
part += w0 + w1 ;
}
return part;
}
int bar(void)
{
int w0, w1;
int part = 0,i ;
int data[10240];
fillit (data);
for (i=0; i1;i+=2){
w0 = data[i];
w1 = data[i+1];
part += w0 + w1 ;
}
return part;
}
In the case where data is defined as a parameter, I get two separate
loads with no offsets. GCC handles both loads separately. This means
more register pressure and more instructions in the loop. In essence I
get:
ld r1, (0)r5
ld r2, (0)r6
Instead of :
ld r1, (0)r5
ld r2, (8)r6
which I do get if the array is declared in the function.
I have written the address_cost function to handle this case and tell
the compiler that it is better to use the offsets but in this
scenario, the compiler is not calling the address cost function before
already getting those two different registers. So I don't why it's
already expanding those loads before getting to that call
Any ideas, thanks?
Jc
Re: Reserving a number of consecutive registers
Ok, I've been working at this and have actually made a bit of progress. - I now have a framework that finds the group of loads (let's assume they stay together). - With the DF framework, I'm able to figure out which registers are being used and which are free to be used. - I've pretty much got it to change the registers to the ones I want but there are still some corner cases where it seems to be badly handling that and actually changing the semantics of the program. I'll look into that, thanks, Jc On Mon, Apr 20, 2009 at 3:01 PM, Eric Botcazou ebotca...@adacore.com wrote: Ok, I'll try to look at that. Is there an area where I can see how to initialize the framework and get information about which registers are free? The API is in df.h, see for example ifcvt.c. -- Eric Botcazou
gcc-4.4-20090421 is now available
Snapshot gcc-4.4-20090421 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090421/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 146539 You'll find: gcc-4.4-20090421.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20090421.tar.bz2 C front end and core compiler gcc-ada-4.4-20090421.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20090421.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20090421.tar.bz2 C++ front end and runtime gcc-java-4.4-20090421.tar.bz2 Java front end and runtime gcc-objc-4.4-20090421.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20090421.tar.bz2The GCC testsuite Diffs from 4.4-20090414 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug c/16202] The -Wsequence-point warning misses many important instances
--- Comment #12 from manu at gcc dot gnu dot org 2009-04-21 07:47 --- Subject: Bug 16202 Author: manu Date: Tue Apr 21 07:47:13 2009 New Revision: 146472 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146472 Log: 2009-04-21 Manuel López-Ibáñez m...@gcc.gnu.org PR 16202 * c-typeck.c (lvalue_p): Move declaration ... * c-common.h (lvalue_p): ... to here. * c-common.c (candidate_equal_p): New. (add_tlist): Use it. (merge_tlist): Use it. (warn_for_collisions_1): Likewise. (warning_candidate_p): Accept more candidates. (verify_tree): A warning candidate can be an expression. Use candidate_equal_p. cp/ * tree.c (lvalue_p_1): Use const_tree. Use CONST_CAST_TREE to avoid warning. (lvalue_p): Returns bool, receives const_tree. testsuite/ * gcc.dg/sequence-pt-1.c: Remove XFAILs. * gcc.dg/sequence-pt-2.c: New. * gcc.dg/sequence-pt-3.c: New. * g++.dg/warn/sequence-pt-1.C: Remove XFAILs. * g++.dg/warn/sequence-pt-2.c: New. * g++.dg/warn/sequence-pt-3.c: New. Added: trunk/gcc/testsuite/g++.dg/warn/sequence-pt-2.C trunk/gcc/testsuite/g++.dg/warn/sequence-pt-3.C trunk/gcc/testsuite/gcc.dg/sequence-pt-2.c trunk/gcc/testsuite/gcc.dg/sequence-pt-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-common.h trunk/gcc/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/sequence-pt-1.C trunk/gcc/testsuite/gcc.dg/sequence-pt-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16202
[Bug c/16202] The -Wsequence-point warning misses many important instances
--- Comment #13 from manu at gcc dot gnu dot org 2009-04-21 07:48 --- FIXED in GCC 4.5 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16202
[Bug middle-end/39827] [4.5 Regression] ICE (segfault) when compiling gcc/varasm.c (in notice_global_symbol)
--- Comment #2 from burnus at gcc dot gnu dot org 2009-04-21 07:56 --- Caused by http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01558.html r146425 | rguenth | 2009-04-20 16:01:52 +0200 (Mon, 20 Apr 2009) | 10 lines Changed paths: M /trunk/gcc/ChangeLog M /trunk/gcc/basic-block.h M /trunk/gcc/dominance.c M /trunk/gcc/tree-cfg.c M /trunk/gcc/tree-ssa-phiprop.c 2009-04-20 Richard Guenther rguent...@suse.de * basic-block.h (get_all_dominated_blocks): Declare. * dominance.c (get_all_dominated_blocks): New function. * tree-cfg.c (get_all_dominated_blocks): Remove. (remove_edge_and_dominated_blocks): Adjust. * tree-ssa-phiprop.c (tree_ssa_phiprop_1): Fold in ... (tree_ssa_phiprop): ... here. Use get_all_dominated_blocks instead of recursing. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39827
[Bug target/37121] g++ create global symbol for inline function, which make link failed with multiple definitions
--- Comment #16 from ktietz at gcc dot gnu dot org 2009-04-21 08:27 --- (In reply to comment #15) (In reply to comment #14) or remove the ordinary C library function in lib64_libmingwex_a-wininterlocked.o and just keep the inline function ? That would be my first experiment. What depends on lib64_libmingwex_a-wininterlocked.o Danny we implemented int wininterlocked.c file the common interlocked symbols, because some of them should be inlined for performance reasons. To remove the inline version seems to be the best solution for me here. Because otherwise we would disallow a function pointer reference to it. Possibly we could make als define those symbols in wininterlocked.c as weak, does this help? Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
[Bug tree-optimization/39829] [4.5 Regression] ICE with some code that produces VCE
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-21 08:36 --- Mine. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-21 08:36:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39829
[Bug testsuite/39830] gcc.dg/torture/pr39678.c fails if char type is unsigned
--- Comment #6 from jakub at gcc dot gnu dot org 2009-04-21 08:39 --- I've fixed this: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146470 http://gcc.gnu.org/viewcvs?root=gccview=revrev=146471 (4.4) and only afterwards Andrew Pinski pointed me at this PR. Sorry for not checking bugzilla first. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39830
[Bug c/39834] New: verify_cgraph_node failed with -O3 -Winline
I just tried to compile the Suse Linux package mined-2000.14-88.34 with the GNU gcc version 4.5 snapshot 20090416. The compiler said textfile.c:3154: error: edge EXFILE-bottom_line has no corresponding call_stmt # .MEM = VDEF .MEM bottom_line (1, Already at last file[0], 0B, 0B, 0, [0]); EXFILE/101(101) [0x2b066b8f9400]: availability:available 44 insns (100 after inlining) needed body externally_visible finalized inlinable called by: calls: edit_nth_file/91 (nested in 29 loops) bottom_line/105 (nested in 86 loops) quit_mined/90 (nested in 86 loops) edit_nth_file/91 (nested in 142 loops) quit_mined/90 (0.54 per call) write_text/75 (0.29 per call) textfile.c:3154: internal compiler error: verify_cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flags -O3 -Winline required. -- Summary: verify_cgraph_node failed with -O3 -Winline Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39834
[Bug c/39834] verify_cgraph_node failed with -O3 -Winline
--- Comment #1 from dcb314 at hotmail dot com 2009-04-21 09:46 --- Created an attachment (id=17662) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17662action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39834
[Bug middle-end/39824] [4.5 Regression] ice in fold-const.c
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-21 10:18 ---
Confirmed.
static const double internalEndianMagic = 7.949928895127363e-275;
static const unsigned char ieee_754_mantissa_mask[] = { 0x00, 0x0F, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF };
static inline int
trio_isnan (double number)
{
int has_mantissa = 0;
unsigned int i;
unsigned char current;
for (i = 0; i (unsigned int)sizeof(double); i++)
{
current = ((unsigned char *)number)[(((unsigned char
*)internalEndianMagic)[7-(i)])];
has_mantissa |= (current ieee_754_mantissa_mask[i]);
}
return has_mantissa;
}
void
xmlXPathEqualNodeSetFloat(int nodeNr, double v)
{
int i;
for (i=0; inodeNr; i++)
if (!trio_isnan(v))
break;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to work||4.4.0
Last reconfirmed|-00-00 00:00:00 |2009-04-21 10:18:27
date||
Summary|ice in fold-const.c |[4.5 Regression] ice in
||fold-const.c
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39824
[Bug testsuite/39831] gcc.target/i386/excess-precision-*.c assume the default -mfp-math does not include SSE
--- Comment #1 from joseph at codesourcery dot com 2009-04-21 10:20 --- Subject: Re: New: gcc.target/i386/excess-precision-*.c assume the default -mfp-math does not include SSE Probably all six excess precision tests should have explicit -mfpmath=387. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39831
[Bug bootstrap/12022] arm-coff build is broken: dies on crtstuff.c with #error
--- Comment #7 from jsm28 at gcc dot gnu dot org 2009-04-21 10:23 --- Yes, closing since this target has been removed for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12022
[Bug middle-end/39834] [4.5 Regression] verify_cgraph_node failed with -O3 -Winline
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-21 10:31 ---
Confirmed. The following fails at -O -Winline.
void quit_mined ();
void bottom_line ();
typedef enum { False, True } FLAG;
inline void
nextfile (FLAG exitiflast)
{
if (exitiflast)
quit_mined ();
else
bottom_line ();
nextfile (True);
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Component|c |middle-end
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2009-04-21 10:31:24
date||
Summary|verify_cgraph_node failed |[4.5 Regression]
|with -O3 -Winline |verify_cgraph_node failed
||with -O3 -Winline
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39834
[Bug libstdc++/39835] Bootstrap failure: libstdc++-v3/include/bits/random.h:3630: error: expected �,� or �...� before numeric constant
--- Comment #1 from ubizjak at gmail dot com 2009-04-21 10:33 ---
We have a symbol name clash:
This is from libstdc++:
explicit
param_type(_RealType __alpha = _RealType(1),
_RealType __beta = _RealType(1))
: _M_alpha(__alpha), _M_beta(__beta)
And this from alpha config:
#define TARGET_CPU_CPP_BUILTINS() \
do\
{ \
builtin_define (__alpha); \
builtin_define (__alpha__); \
Can libstdc++ define symbol name to something else instead of __alpha?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39835
[Bug libstdc++/39835] Bootstrap failure: libstdc++-v3/include/bits/random.h:3630: error: expected �,� or �...� before numeric constant
--- Comment #2 from paolo dot carlini at oracle dot com 2009-04-21 11:15 --- Sure, this is an annoying recurring issue, I'll fix it momentarily. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-21 11:15:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39835
[Bug middle-end/39824] ice in fold-const.c
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-21 09:53 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39824
[Bug c/39834] verify_cgraph_node failed with -O3 -Winline
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-21 10:19 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39834
[Bug middle-end/39827] [4.5 Regression] ICE (segfault) when compiling gcc/varasm.c (in notice_global_symbol)
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-21 09:58 --- 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=39827
[Bug libstdc++/39835] Bootstrap failure: libstdc++-v3/include/bits/random.h:3630: error: expected �,� or �...� before numeric constant
--- Comment #3 from paolo at gcc dot gnu dot org 2009-04-21 11:43 --- Subject: Bug 39835 Author: paolo Date: Tue Apr 21 11:42:51 2009 New Revision: 146516 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146516 Log: 2009-04-21 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/39835 * include/bits/random.h: Avoid the badname __alpha (and, for consistency, __beta too). * include/bits/random.tcc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.h trunk/libstdc++-v3/include/bits/random.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39835
[Bug libstdc++/39835] Bootstrap failure: libstdc++-v3/include/bits/random.h:3630: error: expected �,� or �...� before numeric constant
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-21 11:44 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39835
[Bug c++/39823] GCC 4.4.0 produces bad code for libstdc++
--- Comment #5 from d dot g dot gorbachev at gmail dot com 2009-04-21 12:24 --- (In reply to comment #4) Sorry, my mistake. The problem indeed was in the caller because of different compiler flags. -- d dot g dot gorbachev at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39823
[Bug middle-end/39827] [4.5 Regression] ICE (segfault) when compiling gcc/varasm.c (in notice_global_symbol)
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-04-21 09:58 --- Subject: Bug 39827 Author: rguenth Date: Tue Apr 21 09:58:38 2009 New Revision: 146515 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146515 Log: 2009-04-21 Richard Guenther rguent...@suse.de PR tree-optimization/39827 * tree-ssa-phiprop.c (propagate_with_phi): Check SSA_NAME is in range. (tree_ssa_phiprop): Pass the correct array size. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-phiprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39827
[Bug libstdc++/39835] New: Bootstrap failure: libstdc++-v3/include/bits/random.h:3630: error: expected �,� or �...� before numeric constant
Bootstrap on alpha fails in libstdc++ with: /home/uros/gcc-build/./gcc/xgcc -shared-libgcc -B/home/uros/gcc-build/./gcc -nostdinc++ -L/home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/src -L/home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/alphaev56-unknown-linux-gnu/bin/ -B/usr/local/alphaev56-unknown-linux-gnu/lib/ -isystem /usr/local/alphaev56-unknown-linux-gnu/include -isystem /usr/local/alphaev56-unknown-linux-gnu/sys-include -Winvalid-pch -x c++-header -g -O2 -D_GNU_SOURCE -mieee -I/home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include/alphaev56-unknown-linux-gnu -I/home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include -I/home/uros/gcc-svn/gcc/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /home/uros/gcc-svn/gcc/libstdc++-v3/include/precompiled/stdc++.h \ -o alphaev56-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include/random:50, from /home/uros/gcc-svn/gcc/libstdc++-v3/include/precompiled/stdc++.h:102: /home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include/bits/random.h:3630: error: expected â,â or â...â before numeric constant /home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include/bits/random.h:3663: error: expected â,â or â...â before numeric constant /home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include/bits/random.h: In constructor âstd::gamma_distribution_RealType::param_type::param_type(_RealType)â: /home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include/bits/random.h:3632: error: â__betaâ was not declared in this scope /home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include/bits/random.h: In constructor âstd::gamma_distribution_RealType::gamma_distribution(_RealType)â: /home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include/bits/random.h:3665: error: â__betaâ was not declared in this scope In file included from /home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include/random:53, from /home/uros/gcc-svn/gcc/libstdc++-v3/include/precompiled/stdc++.h:102: /home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc: In member function âresult_type std::gamma_distribution_RealType::operator()(_UniformRandomNumberGenerator, const std::gamma_distribution_RealType::param_type)â: /home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:1924: error: expected unqualified-id before numeric constant /home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc: In function âstd::basic_istream_CharT, _Traits std::operator(std::basic_istream_CharT, _Traits, std::gamma_distribution_RealType)â: /home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:2008: error: expected unqualified-id before numeric constant /home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:2009: error: â__betaâ was not declared in this scope make[4]: *** [alphaev56-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch] Erreur 1 make[4]: quittant le répertoire « /home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3/include » make[3]: *** [all-recursive] Erreur 1 make[3]: quittant le répertoire « /home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3 » make[2]: *** [all] Erreur 2 make[2]: quittant le répertoire « /home/uros/gcc-build/alphaev56-unknown-linux-gnu/libstdc++-v3 » make[1]: *** [all-target-libstdc++-v3] Erreur 2 make[1]: quittant le répertoire « /home/uros/gcc-build » make: *** [all] Erreur 2 -- Summary: Bootstrap failure: libstdc++- v3/include/bits/random.h:3630: error: expected â,â or â...â before numeric constant Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ubizjak at gmail dot com GCC build triplet: alphaev56-unknown-linux-gnu GCC host triplet: alphaev56-unknown-linux-gnu GCC target triplet: alphaev56-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39835
[Bug rtl-optimization/39580] [4.5 regression] Revision 145204 caused libgomp.c++/collapse-2.C
--- Comment #3 from abel at gcc dot gnu dot org 2009-04-21 11:47 --- Confirmed. I will take a look. -- abel at gcc dot gnu dot org changed: What|Removed |Added CC||abel at ispras dot ru AssignedTo|unassigned at gcc dot gnu |abel at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-21 11:47:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39580
[Bug tree-optimization/21485] [4.3/4.4/4.5 Regression] missed load PRE, PRE makes i?86 suck
--- Comment #40 from rob1weld at aol dot com 2009-04-21 12:30 --- (In reply to comment #0) I've found a major performance regression in gcc 4.0.0's optimization ... (In reply to comment #11) We need more analysis on these kinds of issues. So, we're doing a worse job on register allocation. Is that because the register allocator got worse, or because we're giving it a harder problem to solve? (In reply to comment #12) It is the latter and the pass which is responsible ... (In reply to comment #13) Tough, there is really not much that can be done about this ... Is this of any use ? Register Allocation by Puzzle Solving http://compilers.cs.ucla.edu/fernando/projects/puzzles/ This project consists in developing a new model for register allocation that has fast compilation time, produces code of good quality, is able to address the many irregularities found in common computer architectures and is intuitive enough to be easily understood. Our implementation produces Pentium code that is of similar quality to the code produced by the slower, state-of-the-art iterated register coalescing algorithm of George and Appel augmented with extensions by Smith, Ramsey, and Holloway. YT, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug tree-optimization/39829] [4.5 Regression] ICE with some code that produces VCE
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-21 12:42 --- Fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39829
[Bug tree-optimization/39829] [4.5 Regression] ICE with some code that produces VCE
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-21 12:42 --- Subject: Bug 39829 Author: rguenth Date: Tue Apr 21 12:42:24 2009 New Revision: 146521 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146521 Log: 2009-04-21 Richard Guenther rguent...@suse.de PR middle-end/39829 * gimple.c (walk_stmt_load_store_addr_ops): Catch addresses inside VIEW_CONVERT_EXPRs. * gcc.dg/torture/pr39829.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr39829.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39829
[Bug middle-end/39825] sigsegv compiling ffmpeg svn
--- Comment #2 from sergio dot roa at dfki dot de 2009-04-21 12:47 --- Created an attachment (id=17663) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17663action=view) preprocessed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39825
[Bug middle-end/39825] sigsegv compiling ffmpeg svn
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-21 12:57 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39825
[Bug middle-end/39825] sigsegv compiling ffmpeg svn
--- Comment #4 from sergio dot roa at dfki dot de 2009-04-21 13:23 --- I compiled again disabling Altivec optimizations and it worked :) $./configure --disable-altivec [...] $make [...] $ ./ffmpeg FFmpeg version SVN-r18634, Copyright (c) 2000-2009 Fabrice Bellard, et al. configuration: --enable-gpl --enable-postproc --enable-pthreads --enable-libfaac --enable-libfaad --enable-libmp3lame --enable-libtheora --enable-libxvid --disable-altivec libavutil 50. 3. 0 / 50. 3. 0 libavcodec52.27. 0 / 52.27. 0 libavformat 52.32. 0 / 52.32. 0 libavdevice 52. 2. 0 / 52. 2. 0 libswscale 0. 7. 1 / 0. 7. 1 libpostproc 51. 2. 0 / 51. 2. 0 built on Apr 21 2009 15:16:50, gcc: 4.3.2 At least one output file must be specified I hope there are not so much optimization issues by using this ffmpeg... Anyway, I guess this bug should be solved... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39825
[Bug tree-optimization/21485] [4.3/4.4/4.5 Regression] missed load PRE, PRE makes i?86 suck
--- Comment #41 from dberlin at gcc dot gnu dot org 2009-04-21 13:24 --- Subject: Re: [4.3/4.4/4.5 Regression] missed load PRE, PRE makes i?86 suck Fernando was an intern of mine, and while his algorithm is a great algorithm, AFAIK he hasn't gotten better code out of it than we get with IRA right now. I'll check with him again and see if this has changed. On Tue, Apr 21, 2009 at 8:31 AM, rob1weld at aol dot com gcc-bugzi...@gcc.gnu.org wrote: Is this of any use ? Register Allocation by Puzzle Solving http://compilers.cs.ucla.edu/fernando/projects/puzzles/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug target/27859] Bug in generation of interrupt function code for ARM processor
--- Comment #2 from ramana at gcc dot gnu dot org 2009-04-21 13:52 --- (In reply to comment #1) Created an attachment (id=14957) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14957action=view) [edit] Patch to fix interrupt handling on entry/exit for ARM The arm backend already decrement the PC by 4 when entering an interrupt routine, so it does not need to have a specific handling for the return of the function, it can be treated as an exception return. The attached patch fixes this Regards Francois This no longer appears on 4.3 , 4.4 or trunk . Hence closing this one out. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27859
[Bug middle-end/39825] sigsegv compiling ffmpeg svn
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-04-21 13:55 --- Reducing very slowly ... which makes it sound like a GC issue. But, confirmed with the original testcase and a cross-compiler. Fails on the 4.3 branch with -O3 -fno-math-errno -maltivec -mabi=altivec -g, works for me on the trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.3.3 Known to work||4.5.0 Last reconfirmed|-00-00 00:00:00 |2009-04-21 13:55:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39825
[Bug rtl-optimization/29294] 4.1, 4.2 (possibly 4.0?) not finding postmodify address mode on ARM
--- Comment #8 from ramana at gcc dot gnu dot org 2009-04-21 14:09 --- Confirmed with trunk. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-21 14:09:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29294
[Bug rtl-optimization/39580] [4.5 regression] Revision 145204 caused libgomp.c++/collapse-2.C
--- Comment #4 from abel at gcc dot gnu dot org 2009-04-21 14:16 ---
What happens in the test is that when pipelining, after several consecutive
substitutions we end up with moving expressions r64=r16-r16 and r64=r16-r51
through r16=r51, after which both expressions become r64=r51-r51, as a result
of substitution. When merging these expressions, we hit an assert in
insert_in_history_vect.
This assert tries to describe the situations when earlier different, and now
same expressions would have similar entries in their history of changes vector,
i.e. somewhere on their way up they were transformed on the same insn. The
main thing in the assert is that both expressions are supposed to be equal
before this transformation was recorded. Now we have a test case when this is
not the case. I presume that we didn't hit this before because the situations
like ' b = c; a = b - c; ' are quite rare.
We have two choices: either to extend the assert to cover this case or to
remove it completely. If we'd extend it, then the assert becomes not very
useful, as it basically says that all variations in the above situation are
possible. So I'm inclined just to remove it. This would not hurt correctness,
only in extreme rare situations like this we'd not be able to find both
expressions to move them up, but only the one, as history vector has a single
entry per uid, and thus we'd be unable to perform unification.
So I will bootstrap/regtest the below patch.
Index: gcc/sel-sched-ir.c
===
*** gcc/sel-sched-ir.c (revision 146520)
--- gcc/sel-sched-ir.c (working copy)
*** insert_in_history_vect (VEC (expr_histor
*** 1512,1525
{
expr_history_def *phist = VEC_index (expr_history_def, vect, ind);
- /* When merging, either old vinsns are the *same* or, if not, both
- old and new vinsns are different pointers. In the latter case,
- though, new vinsns should be equal. */
- gcc_assert (phist-old_expr_vinsn == old_expr_vinsn
- || (phist-new_expr_vinsn != new_expr_vinsn
-(vinsn_equal_p
- (phist-old_expr_vinsn, old_expr_vinsn;
-
/* It is possible that speculation types of expressions that were
propagated through different paths will be different here. In this
case, merge the status to get the correct check later. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39580
[Bug target/33036] LINUX_DYNAMIC_LINKER undefined in gcc-4.2.1/gcc/config/arm/linux-elf.h
--- Comment #1 from ramana at gcc dot gnu dot org 2009-04-21 14:28 --- LINUX_DYNAMIC_LINKER et al are defined in gcc/config/linux.h and the correct definition must reach this case. Looking at the config parameters for --host and --build , I can spot a typo of linuc-gnu instead of linux-gnu. That might be one reason why the build isn't working for you . arm-linux-gnueabi is a standard build and I bootstrap it regularly and many folks use crosstool to build such a cross configuration. You might consider using this for your purposes. Can you check with a 4.3 toolchain or a compiler of recent vintage with the correct parameters to --build , --host . Please also indicate the host platform on which you were trying this. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33036
[Bug target/19599] function pointer prevents tail-call optimization on arm
--- Comment #2 from ramana at gcc dot gnu dot org 2009-04-21 14:29 --- Mine. -- ramana at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ramana at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-01-21 03:09:22 |2009-04-21 14:29:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19599
[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore
--- Comment #8 from doko at ubuntu dot com 2009-04-21 14:36 --- - config/abi/pre/gnu.ver needs the __signbitl symbol mentioned as well. - the patch has an empty #ifdef/#endif at the end with this change the symbol is found in the library. checked with a native build on hppa-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491
[Bug c++/39754] [4.5 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248
--- Comment #6 from dodji at gcc dot gnu dot org 2009-04-21 14:40 --- In this test case (the last one), the short description of the problem is that we fail at getting canonical types of template arguments when said arguments have composed types. Let me give the longer description as well, so that I don't forget :) 1/ During the instantiation of Eint, we try to instantiate the default argument AT of the template B with T=int*. 2/ At that point, lookup_template_class selects the AX* specialization that was first seen in struct D. There, X was a typedef of W, W being a template parameter of struct D. 3/In the context of 1/, we try to tsubst AT with T=int* - actually we try to tsubst the AX* specialization of AT. In tsubst, we then try to reuse the typedef declaration of T, if T is a typedef. A problem arises in 3/ because T is seen as a typedef of W (remember 2/) but W doesn't have any meaning in the context of 1/, hence the crash. Normally, template arguments are converted to their canonical type variant before the stubst-ing process starts. The canonical type variant of a typedef type variant is basically its qualified main type variant. E.g. in typedef const int Foo, the canonical type variant of Foo is const int. The function doing that conversion is canonical_type_variant. The root cause of the problem is that canonical_type_variant doesn't give us canonical variants of composed types. E.g. in typedef int Foo; The canoniacl type variant of Foo* should be int*. The current implementation of canonical_type_variant returns Foo* instead of int* in that case. So I am testing some patches that change the implementation of canonical_type_variant atm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
[Bug target/36209] arm-*-linux-gnueabi-gcc (4.3.0) segment fault during build of procps-3.2.7
--- Comment #6 from ramana at gcc dot gnu dot org 2009-04-21 14:41 --- This is now fixed as per the last comment. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36209
[Bug target/36409] Additional instructions in prologue and epilogue.
--- Comment #2 from ramana at gcc dot gnu dot org 2009-04-21 14:42 --- confirmed. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-21 14:42:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36409
[Bug middle-end/39825] sigsegv compiling ffmpeg svn
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-04-21 14:52 --- Indeed. Fails with --param ggc-min-expand=100 --param ggc-min-heapsize=131072, works with --param ggc-min-expand=100 --param ggc-min-heapsize=0. Didn't we have a ppc GC problem somewhere? With always-collect we get ./cc1 -quiet -o /dev/null bmp.i -O3 -fno-math-errno -maltivec -mabi=altivec -g --param ggc-min-expand=0 --param ggc-min-heapsize=0 libavcodec/bmp.c: In function 'bmp_decode_frame': libavcodec/bmp.c:307: internal compiler error: in tree_node_structure, at tree.c:2241 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. during collecting of #17 0x005b8f9c in gt_ggc_mx_VEC_rtx_gc (x_p=0x736fa000) at gtype-desc.c:786 786 gt_ggc_m_7rtx_def ((*x).base.vec[i0]); -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||GC http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39825
[Bug regression/39836] New: [4.4 regression] unoptimal code generated
Very simple code:
int* func();
int func2(long long);
void test (int unused, int idx, char tag, long long value)
{
int *p = func() + idx;
switch (tag) {
case 1:
*p = (int) value;
case 2:
*p = func2(value);
}
}
is compiled to 46 bytes by GCC 4.3.1 and to 48 bytes by GCC 4.4.0. Bisection
shows that it was changed by
http://gcc.gnu.org/viewcvs?view=revrevision=139949:
Code generated by 139948:
test:
push{r3, r4, r5, r6, r7, lr}
mov r4, r1
mov r5, r2
ldr r6, [sp, #24]
ldr r7, [sp, #28]
bl func
lsl r4, r4, #2
add r4, r0, r4
cmp r5, #1
beq .L3
cmp r5, #2
bne .L5
b .L4
.L3:
str r6, [r4]
.L4:
mov r0, r6
mov r1, r7
bl func2
str r0, [r4]
.L5:
@ sp needed for prologue
pop {r3, r4, r5, r6, r7, pc}
Code generated by 139949:
test:
push{r4, r5, r6, r7, lr}
sub sp, sp, #12
mov r5, r1
ldr r1, [sp, #36]
mov r6, r2
ldr r7, [sp, #32]
str r1, [sp, #4]
bl func
lsl r4, r5, #2
add r4, r0, r4
ldr r1, [sp, #4]
cmp r6, #1
beq .L3
cmp r6, #2
bne .L5
b .L4
.L3:
str r7, [r4]
.L4:
mov r0, r7
bl func2
str r0, [r4]
.L5:
add sp, sp, #12
@ sp needed for prologue
pop {r4, r5, r6, r7, pc}
Temporary variable was spilled on the stack [sp+4].
BTW, this function is compiled by GCC 4.2.1 to 42 (which is event better!).
--
Summary: [4.4 regression] unoptimal code generated
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexvod at google dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39836
[Bug rtl-optimization/39836] [4.4/4.5 regression] unoptimal code generated
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|regression |rtl-optimization Keywords||missed-optimization, ra Summary|[4.4 regression] unoptimal |[4.4/4.5 regression] |code generated |unoptimal code generated Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39836
[Bug target/36851] [4.4/4.5 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125
[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491
[Bug debug/39372] [4.3 Regression] Missing DW_AT_location for constructor static variable
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39372
[Bug libgcj/38251] [4.4/4.5 Regression] tools.zip doesn't build on systems with short command lines
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
[Bug debug/39412] [4.2/4.3 Regression] ICE in gen_tagged_type_instantiation_die
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39412
[Bug middle-end/38934] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:398
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
[Bug testsuite/39807] [4.3/4.4/4.5 Regression] Reporting of testsuite failures are messed up when using -j
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39807
[Bug c++/4926] C++ ABI needs clarification on mangling of complex expressions
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4926
[Bug libstdc++/38678] [DR XXX] istream::read() calls streambuf::sgetn()
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38678
[Bug c++/33979] support for char16_t, char32_t
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33979
[Bug testsuite/39297] [4.4/4.5 Regression] gcc.dg/tree-ssa/loop-31.c
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39297
[Bug tree-optimization/39612] [4.4/4.5 Regression] Incorrect warning issued Re variable *is* used uninitialized in this function
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
[Bug c++/22488] [4.2/4.3/4.4/4.5 Regression] push_fields_onto_fieldstack calculates offset incorrectly
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
[Bug middle-end/36143] [4.4/4.5 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36143
[Bug tree-optimization/38156] gcc.dg/tree-ssa/update-unswitch-1.c fails when compiled with -ftree-parallelize-loops=4
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38156
[Bug c++/33492] [4.2/4.3 regression] Broken diagnostic: 'must_not_throw_expr' not supported by dump_expr
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33492
[Bug fortran/34199] segfault for TRANSFER integer to TYPE(C_PTR)
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34199
[Bug tree-optimization/35629] [4.4/4.5 Regression] gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times profile fails
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35629
[Bug debug/37022] internal compiler error: in compute_barrier_args_size
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022
[Bug middle-end/37165] [4.4/4.5 Regression] FAIL: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times matrix-reorg Flattened 3 dimensions 1
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37165
[Bug middle-end/36201] [4.4 Regression] NVR in the front-end causes missed optimization later on (retval thought to alias arguments)
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36201
[Bug rtl-optimization/37272] [4.4/4.5 Regression] IRA has caused ppc64-double-1.c to fail
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37272
[Bug rtl-optimization/37273] [4.4/4.5 Regression] IRA does not re-materializes addresses (loads from the TOC)
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37273
[Bug bootstrap/37304] [4.4/4.5 Regression]: in-tree-binutils gcc configure tests fail because of unexpanded $(objdir)
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37304
[Bug target/37367] [4.4/4.5 Regression] gcc-4.4/4.5 speed regression
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37367
[Bug ada/37430] [4.4/4.5 Regression] C974013 gives exception
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37430
[Bug rtl-optimization/37534] [4.4/4.5 Regression] IRA causes 17% degradation in 187.facerec benchmark
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37534
[Bug rtl-optimization/37490] [4.4/4.5 Regression] IRA causes FP code to have more spills
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37490
[Bug target/37633] [4.4/4.5 Regression] wrong register use on sh64
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37633
[Bug ada/37440] [4.4/4.5 Regression] GNAT Bug Box a-ngcefu.adb:397
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440
[Bug libfortran/37754] [4.4 Regression] READ I/O Performance regression from 4.3 to 4.4/4.5
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37754
[Bug target/37942] [4.4/4.5 Regression] FAIL: gcc.c-torture/compile/930618-1.c
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37942
[Bug testsuite/38036] [4.4/4.5 Regression][AVR] FAIL: gcc.c-torture/execute/pr37573.c execution
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38036
[Bug target/38134] [4.4/4.5 Regression] speed regression with many loop invariants
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
[Bug middle-end/38059] [4.4/4.5 Regression] Compile time regression for gcc.dg/20020425-1.c
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38059
[Bug target/38293] [4.4/4.5 regression] libgfortran build failure on spu-elf
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38293
