--- Comment #45 from howarth at nitro dot med dot uc dot edu 2009-09-26
05:51 ---
It appears that the build structure required by the patch will prohibit
factoring out the additional ver files. The patch proposed in
r152192-4-5-trunk-patch.diff is as small as I can make it since the ver
--- Comment #48 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-26 04:25 ---
It can be seen from the patch. I don't know how to detect that a structure
contains an array with required SSE align, so I realign the stack for all types
BLKmode with alignment >= 16. That may
--- Comment #3 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-26 04:14 ---
BTW. this bug is in both gcc 4.3 and 4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41475
--- Comment #2 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-26 04:06 ---
Created an attachment (id=18654)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18654&action=view)
the second file
The second file. Compile with gcc -c -Os. Then, link both object files to
--- Comment #1 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-26 04:05 ---
Created an attachment (id=18653)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18653&action=view)
the first file
The first file of a two-file program. Compile with gcc -c -O3 -march=penti
Hi.
When I compile these two sources, one with -O3 -march=pentium3 and the other
with -Os, the linker warns about nonmatching alignments and the program crashes
because of misaligned SSE accesses.
/usr/bin/ld: Warning: alignment 4 of symbol `array' in commonalign2.o is
smaller than 32 in commonal
--- Comment #44 from howarth at nitro dot med dot uc dot edu 2009-09-26
02:55 ---
This isn't tested yet, but I think if we also change...
--- libgcc-ext.patchfink2 2009-09-25 20:17:05.0 -0400
+++ libgcc-ext.patchfink3 2009-09-25 22:53:12.0 -0400
@@ -387,7 +3
--- Comment #9 from matz at gcc dot gnu dot org 2009-09-26 01:35 ---
Mine, have patch. http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01841.html
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #43 from howarth at nitro dot med dot uc dot edu 2009-09-26
00:59 ---
The r152192-4-5-trunk-patch.diff is your 152135-4-5-trunk-patch.diff.txt with
the correction of the...
+EXLIB_64FLAG = .
in libgcc/config/i386/t-darwin64 and the use of -unexported_symbols_list for
EXLIB
--- Comment #42 from howarth at nitro dot med dot uc dot edu 2009-09-26
00:54 ---
Created an attachment (id=18652)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18652&action=view)
patch modified to use unexport on libgcc-ext files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
I've got an ICE with gcc.c-torture/compile/951116-1.c test
on sh64-unknown-linux-gnu and powerpc64-unknown-linux-gnu.
On powerpc64-unknown-linux-gnu, with -O -g -m64
951116-1.c: In function 'f':
951116-1.c:9:1: internal compiler error: in mem_loc_descriptor, at
dwarf2out.c:11279
#1 0x081eb506 in
--- Comment #4 from matz at gcc dot gnu dot org 2009-09-26 00:13 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from rob1weld at aol dot com 2009-09-25 23:58 ---
(In reply to comment #11)
> Fixed.
Thanks,
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39276
--- Comment #3 from matz at gcc dot gnu dot org 2009-09-25 23:57 ---
Subject: Bug 41454
Author: matz
Date: Fri Sep 25 23:57:01 2009
New Revision: 152189
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152189
Log:
PR tree-optimization/41454
* tree-ssa-dom (stmts_to
--- Comment #41 from howarth at nitro dot med dot uc dot edu 2009-09-25
23:51 ---
Iain,
I just puzzled out a solution for keeping the symbols constantly updated for
libgcc-ext*. We make the following changes to your patch...
1) The files gcc/config/rs6000/darwin-libgcc-ext-32B-10.4.
Having killed most of the port-specific testsuite failures for
i386-*-freebsd7.2 on trunk outside of gcc itself, I am now looking at:
FAIL: gcc.c-torture/execute/conversion.c execution, -O[01] [again].
[[ http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02239.html ]]
If I manually compile and ru
--- Comment #67 from dominiq at lps dot ens dot fr 2009-09-25 21:40 ---
I have opened pr41473 to track the remaining issue with dsymutil. Closing this
PR as fixed. Please reopen if you disagree.
--
dominiq at lps dot ens dot fr changed:
What|Removed
I open this PR to keep a record of the minor issue found in pr41405. For some
libraries dsymutil gives for instance on i686-apple-darwin9 r152145:
19259 - libtool: link: dsymutil .libs/libstdc++.6.dylib || :
19260 : Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_util
--- Comment #4 from dgutson at gcc dot gnu dot org 2009-09-25 21:35 ---
I forgot the ChangeLog:
gcc/
* config/arm/neon.md (neon_vshll_n): Checking Bounds
fixed.
gcc/testsuite/
* gcc.target/arm/neon/vfp-shift-a2t2.c: New test case.
--
http://gcc.gnu.org/bugzilla
--- Comment #3 from dgutson at gcc dot gnu dot org 2009-09-25 21:28 ---
Created an attachment (id=18651)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18651&action=view)
Proposed fix
The attached patch attempts to solve the issue, by augmenting the range check
in order to match 0
I'm trying to build the glib-java bindings using gcc-4.4.1. configure dies
with:
configure:20793: gcj -C Test.java
Test.java:1: error: The type java.lang.Object cannot be resolved. It is
indirect
ly referenced from required .class files
/* #line 20788 "configure" */
^
Test.java:2
--- Comment #4 from rth at gcc dot gnu dot org 2009-09-25 20:49 ---
Subject: Bug 41469
Author: rth
Date: Fri Sep 25 20:49:08 2009
New Revision: 152185
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152185
Log:
PR middle-end/41469
* tree-eh.c (lower_resx): Resolve
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-25 20:04 ---
Yep.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-09-25 19:56 ---
I think this is how C99 inline works ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41471
If I compile this test case with -std=c99 and no optimization, I get an
undefined external. It seems to happen on all platforms including x86 Linux.
Removing the -std=c99 or using optimization will make the error go away.
$ cat f.c
inline int foo() { return 123; }
inline int goo() { return foo();
--- Comment #40 from developer at sandoe-acoustics dot co dot uk
2009-09-25 19:25 ---
(In reply to comment #39)
> EXLIB_64FLAG = i386
close ;) -- it should be EXLIB_64FLAG = .
(I think)
build is nearly finished on x86_64-apple-darwin9
i686-apple-darwin10 build completed and is reg-t
--- Comment #39 from howarth at nitro dot med dot uc dot edu 2009-09-25
19:16 ---
Iain,
I believe I see the problem with the x86_64-apple-darwin10 build. The
multilib subdirectory for the 32-bit binaries is named i386. So you need...
EXLIB_64FLAG = i386
instead of...
EXLIB_64FLAG
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2009-09-25 18:24
---
> Eric, in comment #8, did you mean a workaround inside the compiler, or a
> workaround in user code? Because the latter is impractical for Debian which
> contains more than 2 million lines of Ada, with 350k more
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2009-09-25 18:20
---
> Oh, I didn't realize Test_Extension'Alignment was 16, I wonder what causes it
> to be super-aligned, I see no obvious candidate from -gnatR2...
A pointer to unconstrained array forces double-word alignment
--- Comment #12 from ludovic at ludovic-brenta dot org 2009-09-25 18:15
---
Eric, in comment #8, did you mean a workaround inside the compiler, or a
workaround in user code? Because the latter is impractical for Debian which
contains more than 2 million lines of Ada, with 350k more line
--- Comment #33 from ubizjak at gmail dot com 2009-09-25 18:09 ---
(In reply to comment #32)
> Uros, can you please try it now since we have PR 41463 fixed? x86_64
> with release checking now finally bootstraps so perhaps even alpha
> might? :-)
>
> If there are problems, please try t
--- Comment #3 from rth at gcc dot gnu dot org 2009-09-25 17:47 ---
We're generating exception handling code when we previously didn't.
I suspect that the changes to the call location of using_eh_for_cleanups.
--
rth at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from laurent at guerby dot net 2009-09-25 17:44 ---
Oh, I didn't realize Test_Extension'Alignment was 16, I wonder what causes it
to be super-aligned, I see no obvious candidate from -gnatR2...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41100
--- Comment #3 from ubizjak at gmail dot com 2009-09-25 17:33 ---
(In reply to comment #2)
> Even if it thinks the arrays aren't aligned, that doesn't explain the
> completely unnecessarily zeroing of XMM0 or the choice of the load high/low
> instructions over MOVUPS.
This is by design,
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2009-09-25 17:20
---
> Thanks for your analysis! I'm curious at what's going wrong: it looks scary to
> have wrong code in such a simple use case :)
See utils2.c:maybe_wrap_malloc and maybe_wrap_free for the story about the
super-al
--- Comment #2 from nmiell at comcast dot net 2009-09-25 17:12 ---
Even if it thinks the arrays aren't aligned, that doesn't explain the
completely unnecessarily zeroing of XMM0 or the choice of the load high/low
instructions over MOVUPS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #28 from rahul at icerasemi dot com 2009-09-25 17:10 ---
Sorry, I also had changes to move loop header copying before FRE from
http://gcc.gnu.org/ml/gcc/2009-09/msg00434.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
--- Comment #9 from laurent at guerby dot net 2009-09-25 17:03 ---
Thanks for your analysis! I'm curious at what's going wrong: it looks scary to
have wrong code in such a simple use case :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41100
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2009-09-25 16:40
---
OK, that's a known issue, unfortunately not straightforward to solve. We'll
probably need to resort to a workaround for 4.4.x at least.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41100
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-25 15:14 ---
Because we have GIMPLE_RESX which we don't expect here.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-25 15:09 ---
We go to the ICE of PR41469 with
Index: tree-ssa-coalesce.c
===
--- tree-ssa-coalesce.c (revision 152166)
+++ tree-ssa-coalesce.c (working copy)
@@ -13
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-25 15:04 ---
Confirmed. Similar to PR40758 - out-of-SSA with optimize == 0 does not expect
overlapping life-ranges of SSA names.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-25 15:03 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #27 from rguenth at gcc dot gnu dot org 2009-09-25 14:59
---
It also works with 4.4 for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
--- Comment #32 from jamborm at gcc dot gnu dot org 2009-09-25 14:43
---
(In reply to comment #30)
> (In reply to comment #29)
> > Thanks. With the patch fixing the problem described in #24, we get
> > further when compiling with release checking but run into syntax
> > errors when comp
--- Comment #26 from rguenth at gcc dot gnu dot org 2009-09-25 14:39
---
It works for me on the trunk - I don't think this is worth fixing on release
branches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
--- Comment #25 from rahul at icerasemi dot com 2009-09-25 14:26 ---
Do the fixes in comment #11 and #24 alone solve the missed induction variable
problem?
I'm using the 4.4.1 release branch and it doesn't seem to work for me.
After DOM i get
# i_10 = PHI
i_5 = i_10 + 1;
and PHI prop
) 4.5.0 20090925 (experimental)
Expecting it is a duplicate of similar Bug 41469.
--
Summary: -fexceptions ICE in partition_view_bitmap, at tree-ssa-
live.c:331
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity
--- Comment #66 from howarth at nitro dot med dot uc dot edu 2009-09-25
14:04 ---
Dominique,
Can we close this bug as fixed now? The regress server is churning away
again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
void
af (void *a)
{
}
void
bf (void)
{
int i = 1;
char v[i];
af (v);
}
.../xgcc (-B...) -fexceptions -c -o 1.o 1.c
1.c: In function âbfâ:
1.c:6:1: internal compiler error: in expand_gimple_stmt_1, at cfgexpand.c:1947
xgcc (GCC) 4.5.0 20090925 (experimental)
--
Summary
--- Comment #2 from danglin at gcc dot gnu dot org 2009-09-25 13:58 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
GCC 4.4 is supposed to support "SFINAE for expressions" - but the following
piece of code fails hard, without SFINAE
typedef void Ft(int);
struct A { operator Ft*(); };
struct B { operator Ft*(); };
struct C : A, B { };
template decltype(C()(0)) f(int);
template void f(...);
int main()
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-25 12:14 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-25 12:13 ---
Subject: Bug 41463
Author: rguenth
Date: Fri Sep 25 12:12:51 2009
New Revision: 152167
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152167
Log:
2009-09-25 Richard Guenther
PR middle-end/41463
--- Comment #11 from mahatma at eu dot by 2009-09-25 11:03 ---
Created an attachment (id=18650)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18650&action=view)
sse & 32bit -> -mstackrealign (example 2)
Second attempt (while against 4.4.1, sorry). Working with any -march.
For gcc
--- Comment #38 from developer at sandoe-acoustics dot co dot uk
2009-09-25 10:54 ---
(In reply to comment #37)
> I just noticed that I have been neglecting to pass
> --enable-version-specific-runtime-libs to configure. What should be the impact
> of that on the build (since I did get t
--- Comment #37 from howarth at nitro dot med dot uc dot edu 2009-09-25
10:44 ---
I just noticed that I have been neglecting to pass
--enable-version-specific-runtime-libs to configure. What should be the impact
of that on the build (since I did get the expected libgcc-ext.10.4/5 files)
Due to a typo in lto-symtab.c. I have a fix.
--
Summary: ICE in lto_symtab_prevailing_decl, at lto-symtab.c:727
for 483.xalancbmk
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Seve
--- Comment #4 from Knut dot Franke at gmx dot de 2009-09-25 10:34 ---
Subject: Re: segfault when using implicit dynamic allocation
On Friday 25 September 2009 10:55:34 pinskia at gcc dot gnu dot org wrote:
> This is expected as that variable is still on the stack. Increase
> the st
--- Comment #36 from developer at sandoe-acoustics dot co dot uk
2009-09-25 10:07 ---
(In reply to comment #34)
> The build on i686-apple-darwin10 is going better but has a glitch. A no
> time during the different stages of the bootstrap are libgcc_s.10.4.dylib and
> libgcc_s.10.5.d
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-25 09:10 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-25 09:06 ---
The interesting thing is that data-ref analysis sees 128bit alignment but
the vectorizer still produces
vect_var_.24_59 = M*vect_p.20_57{misalignment: 0};
D.2564_12 = *D.2563_11;
vect_var_.25_61 = vect_var_.24
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-09-25 08:55 ---
This is expected as that variable is still on the stack. Increase the stack
limit and you will see that the size which it crashes increases.
--
pinskia at gcc dot gnu dot org changed:
What|Remove
--- Comment #2 from Knut dot Franke at gmx dot de 2009-09-25 08:22 ---
Created an attachment (id=18649)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18649&action=view)
output of "g++ -v -save-temps -Wall"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41466
--- Comment #1 from Knut dot Franke at gmx dot de 2009-09-25 08:21 ---
Created an attachment (id=18648)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18648&action=view)
A minimal test case (C++ source without #includes).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41466
Allocating blocks of memory using a declaration like "double X[n];" leads to
segfaults if n is large enough (something like 110). Also happens when
allocating two smaller chunks, as in "double X[n/2], Y[n/2];". No problems with
explicit dynamic allocation ("double *X = new double[n];").
Bug #1
--- Comment #65 from developer at sandoe-acoustics dot co dot uk
2009-09-25 08:11 ---
(In reply to comment #64)
> Subject: Bug 41405
>
> Author: rth
> Date: Thu Sep 24 17:02:29 2009
> New Revision: 152127
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152127
thanks Richard
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-09-25 08:10 ---
PPC has the same issue with -fno-schedule-insns:
test:
stwu 1,-16(1)
mflr 0
stw 0,20(1)
mr 0,3
mr 5,4
li 3,0
mr 4,0
bl foo
lwz 0,20(1)
a
--- Comment #2 from ubizjak at gmail dot com 2009-09-25 08:04 ---
(In reply to comment #0)
> There are two redundant FPU instructions there. double value is already in FPU
> after fldt. No need to store it and load it back since difference between
> double and long double is only in mem
69 matches
Mail list logo
