I just had a look at the source code of gcc version 4.5 snapshot 20091126
and I notice the following problem
~/gcc/20091126/src/gcc-4.5-20091126/gcc fgrep note_count ipa-prop.c
int note_count;
note_count++;
lto_output_uleb128_stream (ob-main_stream, note_count);
Please note that
* line
--- Comment #2 from hjl dot tools at gmail dot com 2009-11-28 08:50 ---
It is caused by revision 154561:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00784.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #15 from dodji at gcc dot gnu dot org 2009-11-28 09:22 ---
I didn't look at this issue in a while. I just posted another attempt at
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01564.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408
--- Comment #9 from reichelt at gcc dot gnu dot org 2009-11-28 11:03
---
Just for further reference: This was fixed by the patch for PR 9050.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2009-11-28 12:12 ---
Subject: Bug 42156
Author: jakub
Date: Sat Nov 28 12:12:32 2009
New Revision: 154721
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154721
Log:
PR obj-c++/42156
* objc-act.c (objc_build_struct):
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
Hello I downloaded the gcc-4-4-1, and to my dismay it didn't build. I am on
0x86, slackware 4.10, gcc 3.3.x. I ran in to errors caused by incorrect
filenames. There were some places on the web mentioning this phenomena
dating 2002 and others. I want to know, is this a newbie thing on gcc? I
--- Comment #26 from rearnsha at gcc dot gnu dot org 2009-11-28 14:38
---
(In reply to comment #25)
Further tests show that you're right about the non working kernel.
You should not use -march=iwmmxt (or -mcpu=something equivalent) when
building the linux kernel. The kernel does not
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2009-11-28 15:10
---
Created an attachment (id=19170)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19170action=view)
Third time is a charm
This patch resolves the last remaining regression. Removing the didn't
reduce error
--- Comment #19 from tkoenig at gcc dot gnu dot org 2009-11-28 15:16
---
(In reply to comment #18)
Well, in that case you can as well rely on twos-complement
arithmetic and avoid all the overflow issues?
This is difficult without if statements or MAX_EXPR and MIN_EXPR,
because I
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2009-11-28 15:16
---
With this simply modified case:
program sel
implicit none
integer,parameter :: n=10
integer:: i,j,k,l
real,dimension(n*n*n*n) :: vect
vect(:) = (/ (
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42202
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42205
--- Comment #27 from rearnsha at gcc dot gnu dot org 2009-11-28 15:56
---
Created an attachment (id=19171)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19171action=view)
Proposed patch
I think the attached should be a better patch than the one previously proposed.
I don't have
--- Comment #9 from jakub at gcc dot gnu dot org 2009-11-28 16:27 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #17 from dominiq at lps dot ens dot fr 2009-11-28 16:30 ---
With the patch in comment #15 (gfc, gfc_c without), I see the following for the
test
[macbook] f90/bug% cat pr19925_1_db.f90
INTEGER, PARAMETER :: N=10
INTEGER, PARAMETER :: I(N)=(/(MOD(K,2),K=1,N)/)
INTEGER,
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-28 16:31 ---
Confirmed analysis and fix (initialize it to zero).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-28 16:54 ---
I have a patch, the issue is latent on the branches (the verification is new).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rth at gcc dot gnu dot org 2009-11-28 16:58 ---
CC'ing you, Ira, since this is an SLP problem simply exposed by
enabling permutation support in the target.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2009-11-28 17:14
---
Created an attachment (id=19172)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19172action=view)
Slightly modified charm
This version handles Dominique's test case in comment #17.
--
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2009-11-28 17:52
---
The patch in comment #18 passes all regression tests as well. I hope we are
honing in on this. It does make me wonder why at this point the BT type is
unknown.
--
After a fresh fortran-dev checkout, configure, make, and make install, the
first two modules below compile correctly, while the third produces the the
compile-time errors shown. The two offending lines are the allocate
statement and the subsequent pointer assignment, both in the new_bar
function.
--- Comment #1 from sfilippone at uniroma2 dot it 2009-11-28 18:25 ---
(In reply to comment #0)
After a fresh fortran-dev checkout, configure, make, and make install, the
first two modules below compile correctly, while the third produces the the
Well, for me it works under linux
--- Comment #87 from dominiq at lps dot ens dot fr 2009-11-28 18:40 ---
With the combined proposed patches from comment 85, I do not see anymore
dsymutil failures on (powerpc|i686)-apple-darwin9 and x86_64-apple-darwin10.
From the failures in comment #8, I have noticed that 'gcc -g *'
--- Comment #88 from howarth at nitro dot med dot uc dot edu 2009-11-28
18:45 ---
Do you see this in gcc 4.4.2 as well? I would suggest trying to find
a minimal test case that produces the warning from dsymutil and then
open a new radar with the preprocessed source and the assembly
--- Comment #89 from dominiq at lps dot ens dot fr 2009-11-28 19:04 ---
Do you see this in gcc 4.4.2 as well?
No. A test case is
[ibook-dhum] f90/bug% cat pr34231.f90
MODULE test
TYPE odbase ; INTEGER :: value ; END TYPE
INTERFACE odfname
MODULE PROCEDURE
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-28 19:05
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01568.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34272
--- Comment #90 from howarth at nitro dot med dot uc dot edu 2009-11-28
19:07 ---
Since dsymutil isn't asserting, I wouldn't be so worried unless the test cases
start to fail. Do file a radar though with at least assembly with -dA so that
Apple can review what is happening.
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-11-28 19:11 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-11-28 19:11 ---
Subject: Bug 42183
Author: rguenth
Date: Sat Nov 28 19:11:22 2009
New Revision: 154728
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154728
Log:
2009-11-28 Richard Guenther rguent...@suse.de
PR
While trying to walk through the unwinder under darwin9 in current gcc trunk, I
discovered that we are now linking against multiple libgcc in all of the shared
libraries...
otool -L libffi.4.dylib
libffi.4.dylib:
/sw/lib/gcc4.5/lib/libffi.4.dylib (compatibility version 5.0.0, current
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-11-28
19:53 ---
/sw/src/fink.build/gcc45-4.4.999-20091127/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20091127/darwin_objdir/./gcc/
-B/sw/lib/gcc4.5/x86_64-apple-darwin9.8.0/bin/
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-11-28
20:04 ---
A coarse regression check shows that this problem didn't exist on 20090928 but
did on 20090930.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42208
--- Comment #20 from andreast at gcc dot gnu dot org 2009-11-28 20:14
---
Jack, can you point DYLD_LIBRARY_PATH to your installed libgcc_s.dylib and try
to run a gcj -C testme.java?
I did so with todays trunk and the patch from lxo (Alex), the one you sent me
as well as mine from
--- Comment #2 from dominiq at lps dot ens dot fr 2009-11-28 20:18 ---
On darwin, the errors appear only in 32 bit mode. I am sure that I have already
seen such errors in the past, but I cannot remember where or when!-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42207
--- Comment #21 from howarth at nitro dot med dot uc dot edu 2009-11-28
20:25 ---
Andreas,
Actually we have another issue at the moment. See [Bug target/42208]. It
appears that at some point in late Sept or earlier Oct, darwin starting linking
both the system and the gcc built
--- Comment #22 from andreast at gcc dot gnu dot org 2009-11-28 20:27
---
I follow this one too, that is why I ask!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-11-28
20:28 ---
This is weird. I tested r152433 and r152434 last week to pin down another
regression and neither show the issue. Either I have some misdated builds or
this issue has been latent at times. Will do a
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2009-11-28
20:32 ---
No luck here with setting...
setenv DYLD_LIBRARY_PATH /sw/lib/gcc4.5/lib
I suspect this can randomly pass in some cases
as you have seen before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-11-28
21:09 ---
Doh! I bet this is caused by Iain's libgcc_ext patch.
http://gcc.gnu.org/viewcvs/trunk/libgcc/config/t-slibgcc-darwin?r1=154282r2=154281pathrev=154282
Specifically the section...
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-11-28
21:21 ---
Testing...
Index: libgcc/config/t-slibgcc-darwin
===
--- libgcc/config/t-slibgcc-darwin (revision 154730)
+++
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-11-28
21:41 ---
Iain says this was intended behavior, but I'll rerun it past Mike Stump to make
certain that he fully understood this would happen (as he doesn't actually
build FSF gcc anymore).
--
--- Comment #3 from zsojka at seznam dot cz 2009-11-28 22:46 ---
The problem appears with following flags as well:
-O1 -floop-strip-mine -ffast-math
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42205
--- Comment #16 from dodji at gcc dot gnu dot org 2009-11-28 22:56 ---
Subject: Bug 36408
Author: dodji
Date: Sat Nov 28 22:55:52 2009
New Revision: 154731
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154731
Log:
Fix PR c++/36408
gcc/cp/ChangeLog:
PR c++/36408
--- Comment #17 from dodji at gcc dot gnu dot org 2009-11-28 22:58 ---
Fixed in 4.5
I don't plan to fix it in the branches.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jzwinck at gmail dot com 2009-11-28 22:59 ---
The same bug has recently been raised in Boost's implementation of unordered
containers: https://svn.boost.org/trac/boost/ticket/3693
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2009-11-28
23:01 ---
I figured out for darwin9 that the dual linkage to the system libgcc and the
FSF libgcc from...
http://gcc.gnu.org/viewcvs?view=revisionrevision=154283
--- Comment #28 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-28 23:08 ---
Created an attachment (id=19173)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19173action=view)
arm-linux-gnueabi-gcc -march=iwmmxt -mcpu=iwmmxt -mtune=iwmmxt -std=gnu99 -c
-O2
--- Comment #7 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-28 23:15 ---
ICE has been verified with gcc 4.4.2.
Some analysis have been done in bug #40836 (comments 20 + 21): the WLDRW
operation which would be required for this insn allows only 10 (effective 8)
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-11-28 23:16 ---
An implementation is probably expected to shrink bucket_count when size
shrinks, so the complexity should still be O(size). That would be good
for memory use anyway, so why's that not done?
--
This is not a correctness bug, this is a performance problem.
It appears constant propagation is inconsistent, causing a routine to be
inlined and simplified some places and not others. Code of the form
a(..., ~0x3)
for i=1..n
a(..., ~0)
a(..., 0x0fff)
inlines and simplifies the call
--- Comment #8 from sjackman at gmail dot com 2009-11-29 00:44 ---
I wouldn't depend on the number of buckets shrinking. Shrinking (and growing) a
hash table is an expensive operation that requires rehashing all the elements
in the hash table. Even if the implementation does provide the
When assigning a bool to a single bit of a bitfield located in the
bit-addressable region of memory, better code is produced by
if (flag)
bitfield.bit = true;
else
bitfield.bit = false;
than
bitfield.bit = flag;
I've included a short test and the
--- Comment #9 from sstrasser at systemhaus-gruppe dot de 2009-11-29 02:29
---
(In reply to comment #7)
An implementation is probably expected to shrink bucket_count when size
shrinks, so the complexity should still be O(size). That would be good
for memory use anyway, so why's
--- Comment #3 from damian at rouson dot net 2009-11-29 02:50 ---
(In reply to comment #2)
On darwin, the errors appear only in 32 bit mode. I am sure that I have
already
seen such errors in the past, but I cannot remember where or when!-(
Thanks for all of your help. So how do
--- Comment #18 from hjl dot tools at gmail dot com 2009-11-29 04:08
---
The testcase failed on Linux/ia32:
FAIL: g++.dg/template/stmtexpr2.C (test for errors, line 10)
FAIL: g++.dg/template/stmtexpr2.C (test for errors, line 17)
--
hjl dot tools at gmail dot com changed:
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2009-11-29
07:41 ---
Created an attachment (id=19174)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19174action=view)
gdb walk through w_frame_state_for calls in unwinder
--
--- Comment #26 from howarth at nitro dot med dot uc dot edu 2009-11-29
07:48 ---
I finally managed to sort out the darwin build to get access to the unwinder
debug symbols.
Walking through the testme.java test case using the _Unwind_RaiseException 39
times, I
then used a
58 matches
Mail list logo
