Subject says it all, I guess.
Jakub
Kaveh R. GHAZI wrote:
Hello,
A prerelease tarball of the upcoming MPC 0.7 is available here:
http://www.multiprecision.org/mpc/download/mpc-0.7-dev.tar.gz
Please help test it for portability and bugs by downloading and compiling
it on systems you have access to.
Fell at the first
Dave Korn wrote:
Fell at the first hurdle for me:
gcc-4 -shared-libgcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D_FORTIFY_SOURCE=2
-p
edantic -Wall -Wextra -Werror -O2 -pipe -MT inp_str.lo -MD -MP -MF
.deps/inp_str
.Tpo -c inp_str.c -DDLL_EXPORT -DPIC -o .libs/inp_str.o
cc1: warnings
Dave Korn wrote:
Attached allowed it to build,
And with that patch:
===
All 45 tests passed
===
cheers,
DaveK
On Wed, Aug 26, 2009 at 03:02:44PM -0400, Bradley Lucier wrote:
On Wed, 2009-08-26 at 20:38 +0200, Paolo Bonzini wrote:
When I worked at AMD, I was starting to suspect that it may be more
beneficial
to re-enable the first schedule insns pass if you were compiling in 64-bit
mode,
Hi,
I'm using gcc version 4.1.2 20080704 (Red Hat 4.1.2-44) for a x86
target. The info page says:
`-mpush-args'
`-mno-push-args'
Use PUSH operations to store outgoing parameters. This method is
shorter and usually equally fast as method using SUB/MOV
operations and is enabled by
Dear all,
I have been also been looking into how to generate a function call for
certain operations. I've looked at various other targets for a similar
problem/solution but have not seen anything. On my target
architecture, we have certain optimized versions of the multiplication
for example.
I
Peter Bergner wrote:
On Mon, 2009-08-24 at 23:56 +, Charles J. Tabony wrote:
I am seeing a performance regression on the port I maintain, and I would
appreciate some pointers.
When I compile the following code
void f(int *x, int *y){
*x = 7;
*y = 4;
}
with GCC 4.3.2, I get the
On 08/31/2009 07:20 PM, Jean Christophe Beyler wrote:
Ok, is it normal to see a ashift with a negative value though or is
this already sign of a (potentially) different problem?
I seem to recall that it's normal. Combine was originally
written in the days of VAX, where negative shifts were
On 08/31/2009 05:06 PM, Richard Henderson wrote:
The following patch appears to work for both. I'll commit
it after a bootstrap and test cycle completes.
Committed with one additional change, to prevent VRP
from crashing.
r~
(vrp_visit_stmt): Be prepared for non-interesting stmts.
Minor correction to my previous email:
On Tue, Sep 1, 2009 at 10:08 AM, Godmar Backgod...@gmail.com wrote:
gb...@setzer [39](~/tmp) cat call.c
void caller(void) {
extern void callee(int);
callee(5);
}
This:
gb...@setzer [40](~/tmp) gcc -mno-push-args -S call.c
should be
Is it required that the same compiler that generated lto objects be used
to read them? I've come across a couple ICEs with the current revision
reading lto objects created by a slightly older version but same
configuration. Is this simply invalid usage of my part?
Regards,
Ryan Mansfield
On Tue, Sep 1, 2009 at 11:42, Ryan Mansfieldrmansfi...@qnx.com wrote:
Is it required that the same compiler that generated lto objects be used to
read them? I've come across a couple ICEs with the current revision reading
lto objects created by a slightly older version but same configuration.
On 08/28/2009 12:38 AM, Adam Nemet wrote:
... To assist the linker we need to annotate the indirect call
with the function symbol.
Since the call is expanded early...
Having experimented with this on Alpha a few years back,
the only thing I can suggest is to not expand them early.
I use a
Godmar Back god...@gmail.com writes:
It appears to me that '-mno-push-args' is the enabled by default (*),
and not '-mpush-args'.
The default varies by processor--it dependson the -mtune option.
Moreover, since -maccumulate-outgoing-args
implies -mno-push-args, it appears that the only way
Jean Christophe Beyler jean.christophe.bey...@gmail.com writes:
I have been also been looking into how to generate a function call for
certain operations. I've looked at various other targets for a similar
problem/solution but have not seen anything. On my target
architecture, we have certain
On 08/19/2009 06:50 AM, Mohamed Shafi wrote:
mov _h,d4
mov _h+4,d5
mov _j,d2
mov _j+4,d3
addd4,d2
adcd5,d3
irrespective of which endian it is.
What could i be missing here? Should i add anything specific for this
in the back-end?
Diego Novillo wrote:
On Tue, Sep 1, 2009 at 11:42, Ryan Mansfieldrmansfi...@qnx.com wrote:
Is it required that the same compiler that generated lto objects be used to
read them? I've come across a couple ICEs with the current revision reading
lto objects created by a slightly older version but
I have looked at how other targest use the
init_builtins/expand_builtins. Of course, I don't understand
everything there but it seems indeed to be more for generating a
series of instructions instead of a function call. I haven't seen
anything resembling what I want to do.
I had also first
Ryan Mansfield rmansfi...@qnx.com writes:
The objects were created with rev 15 and being read using 151271.
No, I can't reproduce the ICE using the same version.
Thanks for confirming this is not expected to work.
Is it the intent that this work properly in the future? It is not
absurd
On Tue, Sep 1, 2009 at 14:32, Frank Ch. Eiglerf...@redhat.com wrote:
Ryan Mansfield rmansfi...@qnx.com writes:
The objects were created with rev 15 and being read using 151271.
No, I can't reproduce the ICE using the same version.
Thanks for confirming this is not expected to work.
Is
On Tue, Sep 1, 2009 at 12:31 PM, Ian Lance Taylori...@google.com wrote:
Godmar Back god...@gmail.com writes:
It appears to me that '-mno-push-args' is the enabled by default (*),
and not '-mpush-args'.
The default varies by processor--it dependson the -mtune option.
I don't know how to find
Status
==
The 4.4 branch is open for commits under the usual release branch
rules.
The timing of the 4.4.2 release (at least two months after the 4.4.1
release, so no sooner than September 22) at a point when there are no
P1 regressions open for the branch) has yet to be determined.
Richard Henderson writes:
On 08/28/2009 12:38 AM, Adam Nemet wrote:
... To assist the linker we need to annotate the indirect call
with the function symbol.
Since the call is expanded early...
Having experimented with this on Alpha a few years back,
the only thing I can suggest is to
On Wed, 2009-08-26 at 17:12 -0500, Peter Bergner wrote:
On Wed, 2009-08-26 at 23:30 +0200, Richard Guenther wrote:
Hmm. I suppose if you conditionalize it on flag_schedule_insns it might be
an overall win. Care to SPEC test that change?
I assume you mean like the change below? Yeah, I
On Tue, 2009-09-01 at 10:38 -0400, Vladimir Makarov wrote:
We could do update_equiv_regs in a separate pass before the 1st insn
scheduling as it was before IRA.
IIRC, update_equiv_regs() was always called as part of local-alloc,
so it was always after sched1 even before IRA. That said, moving
Peter Bergner wrote:
On Tue, 2009-09-01 at 10:38 -0400, Vladimir Makarov wrote:
We could do update_equiv_regs in a separate pass before the 1st insn
scheduling as it was before IRA.
IIRC, update_equiv_regs() was always called as part of local-alloc,
so it was always after sched1 even
On 09/01/2009 12:48 PM, Adam Nemet wrote:
I see. So I guess you're saying that there is little chance to optimize the
loop I had in my previous email ;(.
Not at the rtl level. Gimple-level loop splitting should do it though.
Now suppose we split late, shouldn't we still assume that
Diego Novillo wrote:
On Tue, Sep 1, 2009 at 11:42, Ryan Mansfieldrmansfi...@qnx.com wrote:
Is it required that the same compiler that generated lto objects be used to
read them? I've come across a couple ICEs with the current revision reading
lto objects created by a slightly older version
On Tue, 2009-09-01 at 16:46 -0400, Vladimir Makarov wrote:
Peter Bergner wrote:
Were you going to whip that patch up or did you want me to?
I am going to do it by myself.
Great! I'd like to see how your patch affects POWER6 performance.
Do you have access to a POWER6 box? If not, can you
Richard Henderson writes:
On 09/01/2009 12:48 PM, Adam Nemet wrote:
I see. So I guess you're saying that there is little chance to optimize the
loop I had in my previous email ;(.
Not at the rtl level. Gimple-level loop splitting should do it though.
Now suppose we split late,
Actually, what I've done is probably something in between what you
were suggesting and what I was initially doing. If we consider the
multiplication, I've modified the define_expand for example to:
(define_expand muldi3
[(set (match_operand:DI 0 register_operand )
(mult:DI
Jean Christophe Beyler jean.christophe.bey...@gmail.com writes:
First off: does this seem correct?
Awkward though it is, it may be more reliable to build a small tree here
and pass it to expand_call. This assumes that you want to use the
standard ABI when calling this function.
Then your
I don't think I quite understand what you're meaning. I want to use
the standard ABI, basically I want to transform certain operations
into function calls.
In regard to what you said, do you mean I should build the tree before
the expand pass, by writing a new pass that will work on the trees
Finally, I guess the one thing I can do is simply generate
pseudo_registers and copy all my registers into the pseudos before the
call I make.
Then I do my expand like I showed above.
And finally, move everything back.
Later passes will remove anything that was not needed, anything that
was
Jean Christophe Beyler jean.christophe.bey...@gmail.com writes:
In regard to what you said, do you mean I should build the tree before
the expand pass, by writing a new pass that will work on the trees
instead of rtx?
Oh, sorry, I'm an idiot. I forgot that you only have RTL at this point.
I
--- Comment #14 from jv244 at cam dot ac dot uk 2009-09-01 06:56 ---
I wanted to try Vladimir Makarov's new patch for this testcase, but on an
unpatched trunk I notice a serious runtime regression with '-fschedule-insns'
with respect to 4.3.3
Using as base options (for the attached
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #2 from dodji at gcc dot gnu dot org 2009-09-01 07:01 ---
Created an attachment (id=18459)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18459action=view)
Obvious fix candidate
Could you please test this patch on darwin and see if it fixes bootstrap for
you ?
I am
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-01 08:16 ---
Works for me on a i686 host with current trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41203
--- Comment #3 from dodji at gcc dot gnu dot org 2009-09-01 08:46 ---
Subject: Bug 41205
Author: dodji
Date: Tue Sep 1 08:45:38 2009
New Revision: 151262
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151262
Log:
Fix bootstrap after patch PR debug/30161
gcc/ChangeLog:
--- Comment #10 from dodji at gcc dot gnu dot org 2009-09-01 08:46 ---
Subject: Bug 30161
Author: dodji
Date: Tue Sep 1 08:45:38 2009
New Revision: 151262
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151262
Log:
Fix bootstrap after patch PR debug/30161
gcc/ChangeLog:
--- Comment #15 from bonzini at gnu dot org 2009-09-01 08:54 ---
Please try -O2 and -O2 -funroll-loops too, since -O3 is not always good for
speed. (It would be even better if -O2 is not slower and you can find out what
the culprit is at -O3; this is not necessarily possible though).
--- Comment #4 from dodji at gcc dot gnu dot org 2009-09-01 08:55 ---
Fixed in trunk.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
x86_64-w64-mingw32-g++ produce binary will not run.
Runtime : libqt4_plugin.dll' (%1 is not a valid Win32 application. (error 193))
plugins/libqt4_plugin.dll: file format pei-x86-64
Disassembly of section .text:
68e81000 _pre_c_init:
68e81000: 53 push
In running applications on e500, we got illegal instruction error, finally,
we found it's caused by asm code below:
gcc-4.3.2/boehm-gc/include/private/gc_locks.h
__asm__ __volatile__(lwsync: : : memory);
lwsync is not supported by e500, even though powerpc claims that. There are
similar
--- Comment #16 from jv244 at cam dot ac dot uk 2009-09-01 09:13 ---
(In reply to comment #15)
Please try -O2 and -O2 -funroll-loops too, since -O3 is not always good for
speed. (It would be even better if -O2 is not slower and you can find out
what
the culprit is at -O3; this is
--- Comment #17 from jv244 at cam dot ac dot uk 2009-09-01 09:17 ---
(In reply to comment #16)
All numbers with trunk:
with 4.3 there is no difference between -O2 and -O3
-O2 -march=native -funroll-loops -ffast-math: 4.388
-O2 -march=native -funroll-loops -ffast-math
--- Comment #6 from jakub at gcc dot gnu dot org 2009-09-01 09:28 ---
IMHO either standard options compiled code shouldn't be called from
-mpreferred-stack-boundary=2 code, or it needs to be compiled with
-mincoming-stack-boundary=2. But it should be user's responsibility. Ensuring
by
--- Comment #11 from jakub at gcc dot gnu dot org 2009-09-01 09:32 ---
Mark, I don't think this should be P1, __optimize__ attribute is new in 4.4 (so
considering it regression is already quite weird, though the attribute is
ignored in older releases, so technically it is a regression,
gfortran currently supports only STDCALL, FASTCALL and CDECL as attributes
using
!GCC$ ATTRIBUTE list :: symbol
The attributes are saved as bit in the attr struct. For full attribute support,
one presumably should save the string and convert it later in trans*.c into a
TREE.
The string should
--- Comment #29 from dominiq at lps dot ens dot fr 2009-09-01 09:37 ---
Does anyone understand why commenting a write can change crtl-maybe_hot_insn_p
from 1 to 0?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
gcc.target/powerpc/vsx-builtin-7.c
testcase ICEs with -m32 -fstack-protector or -m64:
./cc1 -I include/ -O2 -m32 -fstack-protector -mcpu=power7 vsx-builtin-7.c
(insn 19 31 22 2 vsx-builtin-7.c:21 (set (reg/i:V2DF 3 3)
(mem/c/i:V2DF (plus:SI (reg:SI 9 9)
(reg:SI 0 0 [135]))
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-01 10:34 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-01 10:34 ---
Subject: Bug 41199
Author: rguenth
Date: Tue Sep 1 10:34:17 2009
New Revision: 151265
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151265
Log:
2009-09-01 Richard Guenther rguent...@suse.de
PR
--- Comment #1 from ramana at gcc dot gnu dot org 2009-09-01 11:13 ---
Also occurs with trunk.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
I built an x86_64-w64-mingw32 cross compiler under x86_64 linux using latest
gcc SVN code,
then use this cross compiler to build sqlite3
The compile failed with the following message :
E:\code\sqlite3_sepmake
gcc -pipe -Wall -g -O2 -save-temps -c -o alter.o alter.c
gcc: warning: -pipe ignored
--- Comment #1 from drangon dot mail at gmail dot com 2009-09-01 11:22
---
Created an attachment (id=18460)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18460action=view)
gzip of alter.i, -save-temps output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41211
--- Comment #2 from drangon dot mail at gmail dot com 2009-09-01 11:25
---
Created an attachment (id=18461)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18461action=view)
alter.s, -save-temps output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41211
The program below is miscompiled using
gfortran -O2 -o m m.f90; ./m
gives:
y= 0.60653065945526063 2*y= 2.
(the second of the printed numbers should equal twice the first). Using
gfortran -fno-inline -O2 -o m m.f90
works OK.
The compiler is:
Using built-in specs.
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-09-01 11:49 ---
It turns out, that the PRODUCT is already simplified to EXPR_CONST
before is is checked in expr.c (check_init_expr).
To be more specific, in resolve.c (resolve_unknown_f) the simplification is
implied via
--- Comment #29 from ubizjak at gmail dot com 2009-09-01 12:00 ---
(In reply to comment #28)
This may be related to PR 37144.
No, it was assembler bug with 2.19.1 in my case.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from ramana at gcc dot gnu dot org 2009-09-01 12:03 ---
This sounds correct to me . Adding one of the libjava maintainers to comment on
this. Patches should be submitted to the correct mailing list.
--
ramana at gcc dot gnu dot org changed:
What
--- Comment #17 from ubizjak at gmail dot com 2009-09-01 12:08 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2009-09/msg3.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
The program below is miscompiled using
gfortran -O2 -o m m.f90; ./m
gives:
y= 0.60653065945526063 2*y= 2.
(the second of the printed numbers should equal twice the first). Using
gfortran -fno-inline -O2 -o m m.f90
works OK.
The compiler is:
Using built-in specs.
--- Comment #30 from paolo dot carlini at oracle dot com 2009-09-01 12:12
---
Even if the bug is fixed, I think it would be nice to have it properly
categorization: I can see only a C++ front-end patch in the trail, thus I'm
changing the category to C++. If I'm wrong, please improve
GCC 4.5.0 20090827
When I run any program which throws an exception, I get a segfault:
__cxa_throw . libstdc++-v3/libsupc++/eh_throw.cc:78
_Unwind_RaiseException .. gcc/unwind.inc:62
__gxx_personality_v0 libsupc++/eh_personality.cc:706
_Unwind_SetGR ...
--- Comment #1 from jpr at csc dot fi 2009-09-01 12:15 ---
*** Bug 41213 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41212
--- Comment #1 from jpr at csc dot fi 2009-09-01 12:15 ---
Sorry about the duplicate...
*** This bug has been marked as a duplicate of 41212 ***
--
jpr at csc dot fi changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2009-09-01 12:21
---
For sure, this isn't a library issue.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #31 from rguenth at gcc dot gnu dot org 2009-09-01 12:21
---
Let's reopen it as LTO specific. The test still fails on i?86 with the
original multi-file testcase and -flto. There are also other similar pb_ds
fails.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #1 from burnus at gcc dot gnu dot org 2009-09-01 13:29 ---
As fun one can think of supporting also alignment within a TYPE, similarly to
C's:
struct foo { int x[2] __attribute__ ((aligned (8))); };
See http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html for details.
--- Comment #7 from hjl dot tools at gmail dot com 2009-09-01 13:20 ---
Realign the incoming stack for vectorizer has very limited impact
on performance. Here are the differences of -m32 -O3 -msse2
-mfpmath=sse -ffast-math -funroll-loops before and after my patch:
400.perlbench
--- Comment #2 from dominiq at lps dot ens dot fr 2009-09-01 13:37 ---
Confirmed on (powerpc|i686)-apple-darwin9 in 32 bit mode and -O2 or above. This
is a regression: I get 1.21306131891052 with gcc 4.2.4, 4.3.4, and 4.4.1. I
also get 1.21306131891052 with recent revisions of trunk
--- Comment #12 from mmitchel at gcc dot gnu dot org 2009-09-01 13:54
---
I think the question is whether the use of __optimize__ is in a standard Qt
release. If it is, then I'm quite concerned; it's bad if GCC 4.4.2 can't build
Qt/KDE.
(TBH, I'm concerned anyhow; if __optimize__ is
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-09-01 14:01 ---
Indeed. SRA should not trigger here, that would make it too eager in other
cases (thus I'm removing myself from the CC, feel free to add me again if
there's any discussion that might concern me or SRA again).
--
--- Comment #2 from aph at gcc dot gnu dot org 2009-09-01 14:06 ---
Assigning to Tom tromey: this is his area.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
There is currently no GCC option that will turn off discarded qualifiers
warnings, which typically arise from const/non-const mismatches. These
warnings look like this:
warning: assignment discards qualifiers from pointer target type
warning: passing argument 1 of foo discards qualifiers
--- Comment #2 from ramana at gcc dot gnu dot org 2009-09-01 14:51 ---
I'm afraid nothing much can be done without a smaller testcase than this. What
happens if you don't use -fno-omit-frame-pointer ?
--
ramana at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from ramana at gcc dot gnu dot org 2009-09-01 14:56 ---
Does this still occur with trunk ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from siarhei dot siamashka at gmail dot com 2009-09-01
15:08 ---
It works fine if '-fno-omit-frame-pointer' is removed. I agree that this is
quite a large and convoluted function. Unfortunately I did not manage to reduce
it to something smaller that would still result in
--- Comment #3 from Vikas dot Mehta at roguewave dot com 2009-09-01 15:22
---
Subject: RE: floating point optimization
Thanks for looking into this issue.
Target: x86_64-redhat-linux
-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:gcc-bugzi...@gcc.gnu.org]
Platform£º
WinXP SP3 + Eclipse CDT 6.0 + MinGW 5.1.4 + GCC 4.4.1 (TDM's Build)
Bug description:
GCC failed to correctly resolve the template parameters when nestedly calling
friend function templates of class templates.
Sample codes£º
/* TestMinGW.cpp*/
#include iostream
#include vector
/*
--- Comment #1 from yimingli0126 at 163 dot com 2009-09-01 16:16 ---
Created an attachment (id=18462)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18462action=view)
The source file rising the compilation failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41216
--- Comment #19 from ktietz at gcc dot gnu dot org 2009-09-01 16:16 ---
I verified it by myself and it is a duplicate of 41184
*** This bug has been marked as a duplicate of 41184 ***
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-09-01 16:16 ---
*** Bug 39356 has been marked as a duplicate of this bug. ***
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-09-01 16:20 ---
As the initial reason of this bug is solved, I close it. In fact is the
__chkstk function here incompatible to VC version, but this should be part of a
feature request.
--
ktietz at gcc dot gnu dot org changed:
--- Comment #3 from tromey at gcc dot gnu dot org 2009-09-01 16:58 ---
I think it isn't correct to use gcc directly.
You probably have to introduce a new variable.
But, I don't see why we need ecjx.cc at all.
I think it must be to work around some other problem.
Maybe instead we could
--- Comment #2 from paolo dot carlini at oracle dot com 2009-09-01 17:07
---
Seems a problem with the stricter uninitialized_copy we have got since 4.3...
Investigating.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from aph at gcc dot gnu dot org 2009-09-01 17:09 ---
Hmm, I seem to have approved that patch.
I agree with you: I can't see why the specfile change requires ecjx.cc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868
--- Comment #2 from ubizjak at gmail dot com 2009-09-01 17:26 ---
No testcase - no analysis - no solution.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2009-09-01 17:31 ---
Per comment #2.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from burnus at gcc dot gnu dot org 2009-09-01 17:39 ---
Created an attachment (id=18463)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18463action=view)
Draft patch - first steps but incomplete will not work
Draft patch (not really work yet).
TODO:
a) Copy
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-09-01 17:40 ---
*** This bug has been marked as a duplicate of 41184 ***
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-09-01 17:40 ---
*** Bug 39112 has been marked as a duplicate of this bug. ***
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2009-09-01 17:53 ---
Works for me with a crosscompiler from linux to mingw:
Target: x86_64-pc-mingw32
Configured with: ../gcc-svn/trunk/configure --target=x86_64-pc-mingw32
Thread model: win32
gcc version 4.5.0 20090901 (experimental) [trunk
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-09-01 18:26 ---
I can't reproduce this failure. Neither for msys, linux, and linux64, nor for
cygwin. Does it still exists for you?
Which host and build environment you are using?
--
ktietz at gcc dot gnu dot org changed:
--- Comment #16 from ktietz at gcc dot gnu dot org 2009-09-01 18:38 ---
(In reply to comment #15)
GCC 4.5 [Trunk], SVN Revision 149872. Because Win64 testing is so hard to come
by, I took the initiative of deleting the entire tree, re-checking it out, and
building from scratch. I am
4.5.0 20090901 (experimental) [trunk revision 151274] (GCC)
Works for me too. Maybe a duplicate of PR/41184
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41211
$ ./xgcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-languages=c
Thread model: posix
gcc version 4.5.0 20090901 (experimental) [trunk revision 151276] (GCC)
$ ./xgcc -B. -o
Segmentation fault
(gdb) bt
#0 0xb7f43613 in strlen () from /lib/tls/i686
1 - 100 of 124 matches
Mail list logo
