--- Comment #2 from schwab at suse dot de 2009-01-01 09:14 ---
Probably fixed by http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01025.html.
See also http://gcc.gnu.org/ml/gcc/2008-12/msg00205.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38685
--- Comment #3 from paolo at gcc dot gnu dot org 2009-01-01 10:09 ---
Subject: Bug 38678
Author: paolo
Date: Thu Jan 1 10:08:31 2009
New Revision: 142994
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142994
Log:
2009-01-01 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #4 from paolo dot carlini at oracle dot com 2009-01-01 10:10
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2009-01-01 11:19 ---
arm could just add x-cflags-O1 to host_xmake_file in gcc/config.host,
see what powerpc*-*-linux* host is doing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523
When trying to compile GCC revision 142992 I get an ICE in cfganal.c:1044:
configure:2590: checking for suffix of object files
configure:2611: /home/artem/testing/gcc-build/./gcc/xgcc
-B/home/artem/testing/gcc-build/./gcc/
-B/home/artem/testing/gcc44/i686-pc-linux-gnu/bin/
--- Comment #1 from aanisimov at inbox dot ru 2009-01-01 12:06 ---
(In reply to comment #0)
When compiling this source by hand (probably with environment that differs
from
one created by configure) I get an ICE in tree-ssa-phiopt.c:372.
That was a wrong assumption. One gets ICE
--- Comment #3 from rob1weld at aol dot com 2009-01-01 12:09 ---
(In reply to comment #1)
Can you try 4.3.2?
No, I don't have it, and next I was planning on build-testing the trunk.
The reason for reporting so old a version (_if_ that is the point you are
making Can you try 4.3.2?)
--- Comment #4 from rob1weld at aol dot com 2009-01-01 12:40 ---
(In reply to comment #1)
Can you try 4.3.2?
This person ( http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01766.html ) has
recently built 4.3.2 on my platform; you could ask them.
--
--- Comment #7 from stevenb dot gcc at gmail dot com 2009-01-01 13:42
---
Subject: Re: [4.3/4.4 Regression] Inline heuristics run even at -O0
Note that the compile time at, say, -O1 for 4.3 vs. 4.4 is also a huge
difference for the test case (4.4 much slower, in part due to the
--- Comment #2 from rfm at gnu dot org 2009-01-01 15:02 ---
Created an attachment (id=17020)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17020action=view)
Patch for sendmsg.c to fix this bug
I've been using this patch for a while ... it modifies sendmsg.c to prevent the
bug by
--- Comment #5 from rfm at gnu dot org 2009-01-01 15:08 ---
I just checked up on this again ...
The problem was initially reported two and a half years ago.
I supplied a (very very simple) patch to fix it a month ago.
Could someone please apply the patch so it gets into the next
Example program works with option -O1, but not with -O2
Problem occurs with gcc 4.3.2 and 4.4.0, but not with 4.2.4
Environment:
System: Linux andiunx 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 UTC 2008
i686 GNU/Linux
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target:
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-01 15:53 ---
This code is undefined as you would have an integer overflow which is undefined
by both the C and C++ standards.
You can use -fwrapv for wrapping of signed integers or cast to unsigned before
doing the addition.
I was looking for something like MSVC's InterlockedIncrement in gcc and found
the __sync_lock_test_and_set builtin.
I wrote a small test program:
#include stdio.h
int l;
int main() {
printf(%d\n,__sync_lock_test_and_set(l,1));
}
and when I look at the disassembly I get
xchgl
--- Comment #1 from felix-gcc at fefe dot de 2009-01-01 15:58 ---
All I really want is a way to access lock cmpxchg and lock xadd, really :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38688
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-01 16:01 ---
;; Recall that xchg implicitly sets LOCK#, so adding it again wastes space.
(define_insn sync_lock_test_and_setmode
[(set (match_operand:IMODE 0 register_operand =modeconstraint)
(unspec_volatile:IMODE
--- Comment #2 from felix-gcc at fefe dot de 2009-01-01 16:01 ---
Sorry, I just found out that xchg has an implicit lock. Never mind about this
bug.
--
felix-gcc at fefe dot de changed:
What|Removed |Added
I got
FAIL: objc/execute/forward-1.m execution, -O0 -fgnu-runtime
FAIL: objc/execute/forward-1.m execution, -O1 -fgnu-runtime
FAIL: objc/execute/forward-1.m execution, -O2 -fgnu-runtime
FAIL: objc/execute/forward-1.m execution, -O3 -fomit-frame-pointer
-fgnu-runtime
FAIL:
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-01 16:21 ---
*** Bug 38689 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-01 16:21 ---
It fails on all targets that pass their arguments via registers.
*** This bug has been marked as a duplicate of 36610 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-01 16:23 ---
Confirmed, this is really a __builtin_apply bug. Libobjc either needs to move
to libffi or __builtin_apply needs to be fixed up.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from hjl dot tools at gmail dot com 2009-01-01 16:26 ---
(In reply to comment #4)
Confirmed, this is really a __builtin_apply bug. Libobjc either needs to move
to libffi or __builtin_apply needs to be fixed up.
Is there a __builtin_apply testcase in C?
--
--- Comment #4 from ubizjak at gmail dot com 2009-01-01 17:35 ---
(In reply to comment #3)
Most likely addsi3_carry should accept 0 as one of the operands.
It does:
(define_insn addsi3_carry
[(set (match_operand:SI 0 nonimmediate_operand =rm,r)
(plus:SI (plus:SI
--- Comment #8 from danglin at gcc dot gnu dot org 2009-01-01 17:43 ---
Subject: Bug 38675
Author: danglin
Date: Thu Jan 1 17:42:00 2009
New Revision: 142995
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142995
Log:
PR fortran/38675
Backport from mainline:
--- Comment #11 from danglin at gcc dot gnu dot org 2009-01-01 17:43
---
Subject: Bug 37469
Author: danglin
Date: Thu Jan 1 17:42:00 2009
New Revision: 142995
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142995
Log:
PR fortran/38675
Backport from mainline:
--- Comment #9 from danglin at gcc dot gnu dot org 2009-01-01 17:44 ---
Fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38675
--- Comment #10 from danglin at gcc dot gnu dot org 2009-01-01 17:45
---
Forgot to check button.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tkoenig at gcc dot gnu dot org 2009-01-01 18:38 ---
This is looking promising (and passes regression-test), and I think
that this does the right thing (the symbol in question doesn't need
to be a procedure, correct?)
Paul, could you maybe comment?
$ svn diff
Index:
--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-01 19:41 ---
Subject: Bug 36489
Author: jakub
Date: Thu Jan 1 19:40:03 2009
New Revision: 142998
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142998
Log:
PR c/36489
* c-typeck.c (add_pending_init): Add
--- Comment #6 from jakub at gcc dot gnu dot org 2009-01-01 19:44 ---
Looks very similar to PR37829.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38672
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-01 19:44 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-01 21:12 ---
The segfault has been changed into an error with PR 13506 but that does not
mean with RTL checking turned on.
In fact with RTL checking we get:
t.c: In function 'main':
t.c:13: internal compiler error: RTL check:
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-01 21:22 ---
This is why the PowerOpen ABI is good, it does not require stack based
trampolines.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-01 21:34 ---
Mark,
This has been assigned to you for two years without any progress, are you
actively working on this? If not please unassign this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29571
--- Comment #15 from pinskia at gcc dot gnu dot org 2009-01-01 21:35
---
Ian,
This has been assigned to you for 9 months without any progress, are you
actively working on this? If not please unassign this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31130
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-01 21:48 ---
RTL DSE does this optimization ...
(insn 8 7 11 2 t.c:12 (set (mem/s/c:SI (reg/f:SI 60) [0 u.ii+0 S4 A32])
(const_int 20 [0x14])) 47 {*movsi_1} (expr_list:REG_DEAD (reg/f:SI 60)
(nil)))
(insn 11 8
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-01 21:57 ---
This has been fixed with tuples merge.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-01 22:06 ---
I will test the patch for the invalid INDIRECT_REF issue but the other one
needs a slight rewrite as it no longer applies to tuples.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-01 22:07 ---
Well that and make MODIFY_EXPR invalid for tuples.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30142
Take:
int d;
int f(int a)
{
return d = (a-1)/2;
}
--- CUT ---
With -O2 -fdump-tree-final_cleanup, we get:
d.0 = a + -1 / 2;
This looks like we are missing the optimization of folding the constant -1/2
which is not true as this is really (a + -1) / 2 .
In 4.3.3 we get:
d.0 = (a + -1) / 2;
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-01 23:28 ---
I think this was introduced by the tuple merge.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-01 23:30 ---
I was able to bootstrap with 142964 on i686-linux-gnu with no issues.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38686
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-01 23:32 ---
Plus http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00070.html .
What options are you passing to configure and how are you invoking make?
Also do you have any special environment variables set?
--
pinskia at
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-01-01 23:51 ---
The INDIRECT_REF part was posted at
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00023.html
I have to redo the other part later because of tuples changes,
MODIFY_EXPR/GIMPLE_MODIFY_STMT is lost.
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-02 00:16 ---
Subject: Bug 30142
Author: pinskia
Date: Fri Jan 2 00:14:47 2009
New Revision: 143001
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143001
Log:
2009-01-01 Andrew Pinski pins...@gmail.com
PR
--- Comment #4 from zadeck at naturalbridge dot com 2009-01-02 00:38
---
Subject: Re: [ira] error in start_allocno_priorities,
at ira-color.c:1806
2009-01-01 Kenneth Zadeck zad...@naturalbridge.com
PR rtl-optimization/35805
* df-problems.c (df_lr_finalize): Add recursive
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-01-02
04:19 ---
Hello John,
This patch:
Index: gcc/config/i386/winnt-cxx.c
===
--- gcc/config/i386/winnt-cxx.c (revision 142383)
+++
--- Comment #7 from mmitchel at gcc dot gnu dot org 2009-01-02 04:59
---
I am not working on this.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-01-02 05:53 ---
Fixed a long time ago
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #4 from aanisimov at inbox dot ru 2009-01-02 07:45 ---
(In reply to comment #3)
What options are you passing to configure and how are you invoking make?
Also do you have any special environment variables set?
Sorry, forgot to mention these options in the original
--- Comment #5 from aanisimov at inbox dot ru 2009-01-02 07:48 ---
(In reply to comment #4)
For the moment I found out that revision 136000 compiles fine for me, but
revision 137000 fails (this time in tree-ssa-phiopt.c:371).
I meant revision 138000 instead of 137000.
--
53 matches
Mail list logo
