--- Comment #41 from davek at gcc dot gnu dot org 2010-04-13 06:01 ---
Thanks everyone for all the help with testing and validation :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
$ gcc-4.4 -c -D_GNU_SOURCE -D_REENTRANT -Wall -g -O2 -fPIC -DPIC db4.8-x.c
../dist/../lock/lock_deadlock.c: In function '__lock_detect':
../dist/../lock/lock_deadlock.c:123: warning: 'idmap' may be used uninitialized
in this function
../dist/../lock/lock_deadlock.c:124: warning: 'bitmap' may be
--- Comment #1 from iwamatsu at nigauri dot org 2010-04-13 06:12 ---
Created an attachment (id=20376)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20376action=view)
source code that can reproduce problem
This is the source code that can reproduce a problem.
--
--- Comment #2 from kkojima at gcc dot gnu dot org 2010-04-13 06:34 ---
Confirmd.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kkojima at gcc dot gnu dot org 2010-04-13 06:56 ---
Looks that Christian's patch pic-cp.patch
http://gcc.gnu.org/bugzilla/attachment.cgi?id=19794
in PR target/42841 can fix the problem. Could you
please try it?
--
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-13 06:59 ---
The patch of comment #1 is not the right thing to do. What it means, is that
recog_data finds an operand for which the insn has no df_ref.
Caused by http://gcc.gnu.org/viewcvs?view=revisionrevision=158187
--
--- Comment #7 from liranuna at gmail dot com 2010-04-13 07:43 ---
Mikael's patch seems to do that trick as well as producing very nice assembly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43722
--- Comment #4 from iwamatsu at nigauri dot org 2010-04-13 08:09 ---
Hi,
(In reply to comment #3)
Looks that Christian's patch pic-cp.patch
http://gcc.gnu.org/bugzilla/attachment.cgi?id=19794
in PR target/42841 can fix the problem. Could you
please try it?
I confirmed that
On AVR target g++ generates code which copies object#8217;s VTABLES from FLASH
to SRAM wasting the memory. Due to the Harvard architecture of AVR processors
the solution is not trivial. This behavior can be observed in any c++ program
which has object with virtual method, e.g:
Class test
{
-fmerge-all-constants and #8211;fmerge-constants don#8217;t work at AVR
target.
Example:
const char text1[] PROGMEM=#8221;Test#8221;;
const char text2[] PROGMEM=#8221;Test#8221;;
will still produce duplicated #8220;Test#8221; string in generated code.
--
Summary: -fmerge-constants
--- Comment #1 from j at uriah dot heep dot sax dot de 2010-04-13 08:31
---
I think this is essentially a duplicate of bug #21018.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43746
--
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
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-13 09:02 ---
Micha - compared to 4.4 we arrive with
(gdb) call debug_rtx (target)
(mem/c/i:SI (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -4 [0xfffc])) [0 result+0 S4 A32])
instead of
(gdb) call
--- Comment #3 from bernds at codesourcery dot com 2010-04-13 09:09 ---
Created an attachment (id=20377)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20377action=view)
A patch to fix the problem
This seems to be due to a pattern that uses a + constraint in an input-only
operand.
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-13 09:11 ---
Confirmed.
I think the testcase is broken. We now force always-inline functions to
be inlined during early inlining (which you can't turn off completely
now, similar to IPA inlining before the patch). So we hit
--- Comment #18 from redi at gcc dot gnu dot org 2010-04-13 09:21 ---
Instead I've decided to use --with-arch=nocona --with-tune=core2, since that
avoids having to deploy a new binutils to every server where I want to deploy
gcc
--
redi at gcc dot gnu dot org changed:
--- Comment #19 from burnus at gcc dot gnu dot org 2010-04-13 10:12 ---
This looks like a bug in binutils 2.15
Can we thus close the bug? Or remains there something to do in libgfortran?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-13 10:29 ---
*** This bug has been marked as a duplicate of 42841 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #37 from rguenth at gcc dot gnu dot org 2010-04-13 10:29
---
*** Bug 43744 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43742
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-13 10:37 ---
Can you bisect the few commits that happened inbetween? Like reverting
the fixes for PRs 43679 and/or 43661, 43642?
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||ro at gcc dot gnu dot org
Summary|FAIL: gcc.dg/pr43643.c
--- Comment #6 from aflyhorse at foxmail dot com 2010-04-13 10:58 ---
(In reply to comment #5)
I don't get why you closed this bug. Anyways if you have a patch, post it to
gcc-patc...@.
Sorry, I see nobody concerns this, and I'm more anxious about how to port the
libgcj (especially
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-13 11:20 ---
Well. There is
pretmp.2458_440 = c[2]{lb: 0 sz: 8};
...
c[2] = D.84046_29;
in a possibly dead code region dominated by
if (pretmp.2460_55 16)
goto bb 54;
else
goto bb 57;
where pretmp.2460_55
--- Comment #20 from redi at gcc dot gnu dot org 2010-04-13 11:21 ---
oops - I didn't mean to set the component back to libfortran, that must have
happened when I refreshed the page and my browser helpfully kept that
selected. I've reverted it to bootstrap
I don't think it should be
--- Comment #2 from jamborm at gcc dot gnu dot org 2010-04-13 11:31 ---
(In reply to comment #1)
Confirmed.
I think the testcase is broken. We now force always-inline functions to
be inlined during early inlining (which you can't turn off completely
now, similar to IPA inlining
--- Comment #19 from iains at gcc dot gnu dot org 2010-04-13 11:37 ---
Subject: Bug 31400
Author: iains
Date: Tue Apr 13 11:37:34 2010
New Revision: 158262
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158262
Log:
gcc/fortran:
2010-04-13 Iain Sandoe ia...@gcc.gnu.org
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-13 11:51 ---
Subject: Bug 43735
Author: rguenth
Date: Tue Apr 13 11:50:54 2010
New Revision: 158263
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158263
Log:
2010-04-13 Richard Guenther rguent...@suse.de
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-13 11:51 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from matz at gcc dot gnu dot org 2010-04-13 11:59 ---
No, we shouldn't unconditionally create REGs if the target isn't one, but
rather only if it doesn't match the predicate. Like so, which I'm testing
right now:
Index: builtins.c
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-13 12:23 ---
Subject: Bug 43737
Author: rguenth
Date: Tue Apr 13 12:23:17 2010
New Revision: 158264
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158264
Log:
2010-04-13 Richard Guenther rguent...@suse.de
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-13 12:23 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|---
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-13 12:24 ---
really
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #21 from redi at gcc dot gnu dot org 2010-04-13 12:26 ---
more accurate summary
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-13 12:34 ---
I can reproduce it.
/tmp g++ -Os -shared -o libhello.so -Wl,-z,defs -fPIC hello.c -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64-suse-linux/4.5/lto-wrapper
Target:
--- Comment #7 from jakub at gcc dot gnu dot org 2010-04-13 12:43 ---
Is the libgcc_s.so the link finds a linker script?
You can use -Wl,-M,--verbose to see what is going on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43727
--- Comment #5 from matz at gcc dot gnu dot org 2010-04-13 13:35 ---
Subject: Bug 43730
Author: matz
Date: Tue Apr 13 13:35:30 2010
New Revision: 158268
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158268
Log:
PR middle-end/43730
* builtins.c
--- Comment #6 from matz at gcc dot gnu dot org 2010-04-13 13:47 ---
Subject: Bug 43730
Author: matz
Date: Tue Apr 13 13:47:11 2010
New Revision: 158270
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158270
Log:
PR middle-end/43730
* builtins.c
--- Comment #7 from matz at gcc dot gnu dot org 2010-04-13 13:54 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from marcus at jet dot franken dot de 2010-04-13 14:08
---
$ file /usr/lib/gcc/powerpc64-suse-linux/4.5/libgcc_s.so
/usr/lib/gcc/powerpc64-suse-linux/4.5/libgcc_s.so: symbolic link to
`/lib/libgcc_s.so.1'
$ file /lib/libgcc_s.so.1
/lib/libgcc_s.so.1: ELF 32-bit MSB
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-13 14:09 ---
A few additional notes:
(1) with revision 158105 reverted, the test gcc.dg/tree-ssa/reassoc-19.c fails
with -m32, but passes with -m64.
(2) revision 158265 with/without revision 158105 reverted (after some surgery
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-04-13 14:10 ---
(In reply to comment #7)
Is the libgcc_s.so the link finds a linker script?
You can use -Wl,-M,--verbose to see what is going on.
No, it doesn't seem to.
START GROUP
LOAD /lib/libc.so.6
LOAD
After the merge from fortran-exp to trunk the following tests
[macbook] f90/bug% cat pr19925_1.f90
INTEGER, PARAMETER :: N=10
INTEGER, PARAMETER :: I(N)=(/(MOD(K,2),K=1,N)/)
INTEGER, PARAMETER :: M(N)=I(N:1:-1)
END
[macbook] f90/bug% cat pr19925_1_db.f90
INTEGER, PARAMETER :: N=10
--- Comment #10 from jakub at gcc dot gnu dot org 2010-04-13 14:18 ---
Yes, we sometimes install linker scripts, sometimes symbolic links.
E.g. on powerpc64-linux, 32-bit libgcc_s.so is a linker script, while 64-bit
libgcc_s.so is a symlink.
If you after install overwrite it with a
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-04-13 14:30
---
So, my fault.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2010-04-13 15:48
---
Subject: Bug 32628
Author: ebotcazou
Date: Tue Apr 13 15:47:38 2010
New Revision: 158274
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158274
Log:
PR middle-end/32628
* c-common.c
--- Comment #44 from howarth at nitro dot med dot uc dot edu 2010-04-13
16:01 ---
From a discussion with the clang programmers, I have this response...
The FIXME comment in the clang sources caught my eye because,
at first glance, it appears to be hinting that this usage
of
--- Comment #45 from howarth at nitro dot med dot uc dot edu 2010-04-13
16:06 ---
Did anyone ever file a radar bug report on the inaccurate complex math from
http://compiler-rt.llvm.org/?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
--- Comment #46 from dominiq at lps dot ens dot fr 2010-04-13 16:29 ---
Did anyone ever file a radar bug report on the inaccurate complex math from
http://compiler-rt.llvm.org/?
I did not see anything along this line in their bugzilla. However there is
comment #25
I've filed
--- Comment #35 from aph at gcc dot gnu dot org 2010-04-13 16:36 ---
I've been trying this on gcc trunk, and it doesn't have the problem.
It seems that merging is not done.
I get
...
0x8684 f2: @0x8808
Compact model 1
0xb1 0x08 pop {r3}
0x84 0x00 pop {r14}
0xb0 finish
--- Comment #47 from howarth at nitro dot med dot uc dot edu 2010-04-13
16:48 ---
Not good news...according to another Apple programmer...
--
Mike Stump filed the radar:
rdar://problem/7457013 ___divdc3 slightly wrong
Since fixing it did not appear to positively impact our
--- Comment #36 from mikpe at it dot uu dot se 2010-04-13 16:51 ---
(In reply to comment #35)
I've been trying this on gcc trunk, and it doesn't have the problem.
It seems that merging is not done.
I get
...
0x8684 f2: @0x8808
Compact model 1
0xb1 0x08 pop {r3}
0x84
--- Comment #48 from iains at gcc dot gnu dot org 2010-04-13 16:52 ---
give me a day or two guys...
and I'll post a composite patch that
(a) cleans up some of the nits in config{,/*}/darwin*.h
(b) gets rid of -lgcc [well, moves it to the only places it's still needed]
(c) sorts out
The current build machinery in FSF gcc doesn't appear to provide a mechanism to
install target specific .def files when install-plugin installs the header
files. In particular, after applying...
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00610.html
...and building gcc trunk or gcc-4_5-branch
--- Comment #49 from howarth at nitro dot med dot uc dot edu 2010-04-13
16:59 ---
(In reply to comment #48)
(d) temporarily patches darwin10.h to include the static lib first and
therefore work around this bug until the radar is done.
From what I was told (Comment 47), the radar bug
--- Comment #37 from aph at redhat dot com 2010-04-13 17:02 ---
Subject: Re: [4.4/4.5/4.6 regression] regressions in libjava
testsuite on arm-linux
On 04/13/2010 05:52 PM, mikpe at it dot uu dot se wrote:
Is it maybe the case that Compact model 1 unwinder data isn't yet being
--- Comment #38 from aph at gcc dot gnu dot org 2010-04-13 17:25 ---
I think I can fairly easily add an option to the linker to suppress table
merging when linking Java libraries, and that will completely solve the
problem, at least from my point of view. To that end, it would not be
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-04-13 19:03
---
I don't see the failure on linux-x86-64. I am building on Cygwin to see whta
shows up there. I seem to recall a patch that changed a fatal error to a
non-fatal somewhere. I will have a look tonight.
--
--- Comment #13 from mkuvyrkov at gcc dot gnu dot org 2010-04-13 19:32
---
The SIGSEGV is due to -funsafe-math-optimizations being used with code like:
==
Re = eps*debm*DIAhy/(vis*sec)
reo = Re
IF ( Re.LT.1000. ) THEN
i1 = INT(Re/200.) + 1
ELSEIF (
--- Comment #5 from ubizjak at gmail dot com 2010-04-13 19:46 ---
(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.
How about:
Index: expr.c
--- Comment #14 from mkuvyrkov at gcc dot gnu dot org 2010-04-13 20:01
---
(In reply to comment #10)
- D.1850_209 = -alt_90;
- D.2093_151 = -alb_86;
- D.1849_208 = D.1848_207 - alb_86;
+ D.2093_151 = -alt_90;
+ D.1849_208 = D.1848_207 - alt_90;
D.1851_210 = D.1849_208 +
When building a compiler with --prefix=/some/dir and
--exec-prefix=/some/dir/subdir, the installed gnat cannot find the installed
libraries in /some/dir/subdir/lib/gcc/...
I believe that sdefault.adb should be generated with
S0 : constant String := \$(exec_prefix)/\;
not
S0 : constant String :=
--- Comment #15 from dominiq at lps dot ens dot fr 2010-04-13 20:45 ---
(In reply to comment #13)
Here we have index `i1' calculated from fp values and then casted to int.
Segmentation fault occurs in `y1 = y(i1)' with i1 equal to
0x800c.
This is in function S00061 in
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-13 20:56 ---
(In reply to comment #1)
I don't see the failure on linux-x86-64. I am building on Cygwin to see whta
shows up there. I seem to recall a patch that changed a fatal error to a
non-fatal somewhere. I will have a
--- Comment #5 from steven at gcc dot gnu dot org 2010-04-13 21:23 ---
Matz, can you at least attach the patch to this PR, so that someone else can
polish it if you're not going to do it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42963
--- Comment #2 from gcc at cohi dot at 2010-04-13 21:26 ---
(In reply to comment #1)
Most likely related to PR 43277. I want to say Darwin10's unwinder is broken
...
Can this be confirmed?
The information in PR 43277, and the ones linked from there, seemed
inconclusive...
(I can
--- Comment #13 from manu at gcc dot gnu dot org 2010-04-13 23:48 ---
I have a patch that prints this:
/home/manuel/src/pr9335.C:2:36: error: template instantiation depth exceeds
maximum of 1024 (use -ftemplate-depth= to increase the maximum) instantiating
struct
--- Comment #4 from kkojima at gcc dot gnu dot org 2010-04-14 00:55 ---
(In reply to comment #3)
This seems to be due to a pattern that uses a + constraint in an input-only
operand. The attached patch seems to fix it for me; please confirm.
[I'd like to add Christian to the cc
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-04-14 01:32
---
OK, I see it now. This is a little different from our previous encounters with
overly big constructors. In fact, the code we had in place is still there, so
we have whacked something. The test case does not
--- Comment #14 from jason at gcc dot gnu dot org 2010-04-14 01:41 ---
That sounds like another case where trying to recover from an error by changing
a problematic type to 'int' doesn't actually improve matters.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9335
--- Comment #5 from kkojima at gcc dot gnu dot org 2010-04-14 04:52 ---
It looks that simply removing the problematic constraint from
doloop_end_split restores build with no performance regressions.
* config/sh/sh.md (doloop_end_split): Remove +r constraint
in an
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-04-14 05:08
---
Easier then I thought. Patch submitted for approval.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43747
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-04-14 05:17
---
Subject: Bug 43747
Author: jvdelisle
Date: Wed Apr 14 05:16:59 2010
New Revision: 158290
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158290
Log:
2010-04-14 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-04-14 05:27
---
Subject: Bug 43747
Author: jvdelisle
Date: Wed Apr 14 05:27:29 2010
New Revision: 158291
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158291
Log:
2010-04-14 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #20 from burnus at gcc dot gnu dot org 2010-04-14 05:43 ---
Subject: Bug 18918
Author: burnus
Date: Wed Apr 14 05:43:30 2010
New Revision: 158292
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158292
Log:
2010-04-14 Tobias Burnus bur...@net-b.de
PR
75 matches
Mail list logo
