--- Comment #11 from armin at xos dot net 2007-02-16 08:07 ---
Subject: Re: compile error / segmentation fault / 64bit compiler
> Note that you don't need -fno-strict-aliasing with -O, it's the default.
> You don't need -mcpu=v9 -m64 -Wa,-xarch=v9 either, it's also the default.
ok. i
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2007-02-16 08:21
---
> however i used the patches from your referred bug and could compile and
> run the modules without problems.
Thanks for letting us know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30769
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-02-16 08:31
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #7 from bonzini at gnu dot org 2007-02-16 08:54 ---
Subject: Bug 27843
Author: bonzini
Date: Fri Feb 16 08:53:51 2007
New Revision: 122032
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122032
Log:
2007-02-16 Ralf Wildenhues <[EMAIL PROTECTED]>
PR other/27
--- Comment #7 from grigory_zagorodnev at linux dot intel dot com
2007-02-16 08:58 ---
(In reply to comment #6)
> What Ian said is probably right, and the patch below should fix it. I haven't
> tried it yet, though...
I've tried in the given conditions. This patch really solves both h
--- Comment #8 from bonzini at gnu dot org 2007-02-16 09:06 ---
Subject: Bug 27843
Author: bonzini
Date: Fri Feb 16 09:06:05 2007
New Revision: 122033
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122033
Log:
2007-02-16 Ralf Wildenhues <[EMAIL PROTECTED]>
PR other/27
--- Comment #22 from pcarlini at suse dot de 2007-02-16 09:06 ---
Frankly, I think it would make sense to remove completely this XFAIL-ing mess
and just wait for Diego to fix the compiler issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
--- Comment #9 from bonzini at gnu dot org 2007-02-16 09:13 ---
Subject: Bug 27843
Author: bonzini
Date: Fri Feb 16 09:13:47 2007
New Revision: 122035
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122035
Log:
2007-02-16 Ralf Wildenhues <[EMAIL PROTECTED]>
PR other/27
--- Comment #10 from bonzini at gnu dot org 2007-02-16 09:14 ---
committed to all active branches.
--
bonzini at gnu dot org changed:
What|Removed |Added
Stat
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-02-16 09:22
---
> committed to all active branches.
Thanks to Ralf and you!
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #13 from sfilippone at uniroma2 dot it 2007-02-16 09:40 ---
(In reply to comment #3)
> For both test cases, xlf gives:
>
> ** class_mesh === End of Compilation 1 ===
> ** class_field === End of Compilation 2 ===
> .
> (second test case). I don't know if they are rig
--- Comment #12 from manu at gcc dot gnu dot org 2007-02-16 09:53 ---
I get warning for gcc/testsuite/objc.dg/headers.m
/home/manuel/src/trunk/gcc/testsuite/../../libobjc/objc/objc-list.h:144:
warning: 'list_free' defined but not used
What should I do about this?
1) there is no warnin
--- Comment #14 from burnus at gcc dot gnu dot org 2007-02-16 09:55 ---
Subject: Bug 30793
Author: burnus
Date: Fri Feb 16 09:55:20 2007
New Revision: 122037
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122037
Log:
fortran/
2007-02-16 Tobias Burnus <[EMAIL PROTECTED]>
--- Comment #6 from manu at gcc dot gnu dot org 2007-02-16 10:01 ---
A really wild-guess patch. Comments?
Index: gcc/cp/class.c
===
--- gcc/cp/class.c (revision 121953)
+++ gcc/cp/class.c (working copy)
@@ -2377,
the following compiled fine on gcc-3.4.6 but gives error on gcc-4.1.2
error: prototype for 'typename A::B::type A::B::f()' does not match any
in class 'A::B'
error: candidate is: typename A::type A::B::f()
error: template definition of non-template 'typename A::B::type
A::B::f()'
template < type
http://bugs.php.net/bug.php?id=39418
short summary: during the install process of php. php is called and segfaults.
detailed info in the above link.
the php people think its a gcc fault.
i could reproduce the bug (with or without their trim patch).
what's the information you need. how to produc
gcc/fortran/Make-lang.in has:
# These files get warnings from an inline function in GMP saying:
# "control may reach end of non-void function '__gmpz_get_ui' being inlined"
fortran/expr.o-warn = -Wno-error
fortran/resolve.o-warn = -Wno-error
fortran/simplify.o-warn = -Wno-error
fortran/trans-commo
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-02-16 11:08
---
I'll add that before removing the code, one should do a build with minimal
versions of GMP & MPFR (GMP 4.1 and MPFR 2.2.0), and see if the warnings
happen.
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-02-16 11:08
---
It's a variant of a bug you fixed
2005-12-16 Jakub Jelinek <[EMAIL PROTECTED]>
PR rtl-optimization/24899
* loop.c (strength_reduce): Don't reduce giv that is not always
computable and w
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-16 11:25 ---
EDG happily eats this. With mainline the error looks like
t.ii:18: error: prototype for typename A::B::type A::B::f() does not
match any in class A::B
t.ii:13: error: candidate is: typename A::type A::B::f()
t.
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-16 11:29 ---
Try building with -fno-strict-aliasing and/or with -fwrapv. If this fixes it
it is a bug in PHP. Also try 4.1.2 which was released a few days ago.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-02-16 12:06
---
> what's the information you need. how to produce a .i file - of which php
> component?
You have to do half of the work, i.e. find out which part of the code has been
miscompiled. Could you try with 4.1.2 as Ric
the following compiled fine on gcc-3.4.6 but gives error on gcc-4.1.2
error: prototype for 'typename A::B::type A::B::f()' does not match any
in class 'A::B'
error: candidate is: typename A::type A::B::f()
error: template definition of non-template 'typename A::B::type
A::B::f()'
template < type
Hello, in the attached piece of code two pairs of template functions are
defined which differ just in the order of their definitions.
The first pair (for_all_1) is accepted by the compiler (gcc 4.1.1) the second
(for_all_2) is rejected. (The aim of the code is to iterate over a list of
elements of
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-02-16 12:19
---
Subject: Bug 30381
Author: fxcoudert
Date: Fri Feb 16 12:19:01 2007
New Revision: 122039
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122039
Log:
2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]>
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-02-16 12:19
---
Subject: Bug 30389
Author: fxcoudert
Date: Fri Feb 16 12:19:01 2007
New Revision: 122039
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122039
Log:
2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]>
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-02-16 12:19
---
Subject: Bug 30611
Author: fxcoudert
Date: Fri Feb 16 12:19:01 2007
New Revision: 122039
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122039
Log:
2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]>
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-02-16 12:19
---
Subject: Bug 30420
Author: fxcoudert
Date: Fri Feb 16 12:19:01 2007
New Revision: 122039
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122039
Log:
2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]>
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-02-16 12:19
---
Subject: Bug 30720
Author: fxcoudert
Date: Fri Feb 16 12:19:01 2007
New Revision: 122039
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122039
Log:
2007-02-16 Francois-Xavier Coudert <[EMAIL PROTECTED]>
--- Comment #3 from armin at xos dot net 2007-02-16 12:23 ---
Subject: Re: php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
> You have to do half of the work, i.e. find out which part of the code has been
> miscompiled. Could you try with 4.1.2 as Richard suggested?
i used the above cfla
--- Comment #23 from dnovillo at gcc dot gnu dot org 2007-02-16 12:35
---
(In reply to comment #22)
> Frankly, I think it would make sense to remove completely this XFAIL-ing mess
> and just wait for Diego to fix the compiler issue.
>
Agreed. I don't understand why the rush to XFAIL a
--- Comment #4 from tony2001 at php dot net 2007-02-16 12:55 ---
>Try building with -fno-strict-aliasing and/or with -fwrapv.
>If this fixes it it is a bug in PHP.
Any hints on what it might be and why it's reproducible only on SPARC and GCC
4.x ?
--
tony2001 at php dot net chang
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-02-16 13:06
---
> i used the above cflags and it compiled well. and no segmentation faults
> anymore.
I wouldn't personally recommend -fwrapv, this may uncover other problems. On
the contrary, -fno-strict-aliasing is always saf
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-02-16 13:12
---
> Any hints on what it might be and why it's reproducible only on SPARC and GCC
> 4.x ?
If the trigger happens to be -fstrict-aliasing, it's very likely a violation of
the type-based aliasing rules of the C/C++ l
--- Comment #3 from sdack at gmx dot de 2007-02-16 13:17 ---
Subject: Re: top-level BOOT_CFLAGS not being used for
bootstrapping
pinskia at gcc dot gnu dot org schrieb:
> --- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-15 21:28
> ---
> You mentioned BOOT_STRAP in
--- Comment #4 from sdack at gmx dot de 2007-02-16 13:18 ---
Subject: Re: top-level BOOT_CFLAGS not being used for
bootstrapping
pinskia at gcc dot gnu dot org schrieb:
> --- Comment #2 from pinskia at gcc dot gnu dot org 2007-02-16 01:48
> ---
>> I believe this is due to BO
--- Comment #7 from tobi at gcc dot gnu dot org 2007-02-16 13:31 ---
The backtrace ends in mpfr_erf, I couldn't go further up. To overcome this
difficulty, I set a breakpoint on the caller, see below.
For the record as there seems to have been some confusion: this bug doesn't
appear du
--- Comment #8 from tobi at gcc dot gnu dot org 2007-02-16 13:33 ---
Oh, just noticed this by chance: Steve's testcase also fails with optimization
disabled, again the call to mpfr_erf is issued in do_mpfr_arg1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30816
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-16 13:46 ---
*** Bug 30821 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30818
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-16 13:46 ---
*** This bug has been marked as a duplicate of 30818 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from armin at xos dot net 2007-02-16 14:00 ---
(In reply to comment #5)
> > i used the above cflags and it compiled well. and no segmentation faults
> > anymore.
>
> I wouldn't personally recommend -fwrapv, this may uncover other problems. On
> the contrary, -fno-strict-
--- Comment #7 from tony2001 at php dot net 2007-02-16 14:05 ---
Still valid for GCC 4.1.2:
WARNING: `makeinfo' is missing on your system. You should only need it if
you modified a `.texi' or `.texinfo' file, or any other file
indirectly affecting the aspect of the ma
--- Comment #8 from WILLIAMPAUL dot PHILIBERT at telus dot com 2007-02-16
14:11 ---
Subject: RE: [4.1 only] fastjar is asking for makeinfo in gmake bootstrap
I found that installing GNU Textutil prior to compiling GCC fix this issue.
William Paul Philibert
--
http://gcc.gnu.org
--- Comment #12 from burnus at gcc dot gnu dot org 2007-02-16 14:15 ---
Subject: Bug 30512
Author: burnus
Date: Fri Feb 16 14:15:36 2007
New Revision: 122043
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122043
Log:
fortran/
2007-02-16 Tobias Burnus <[EMAIL PROTECTED]>
--- Comment #8 from tony2001 at php dot net 2007-02-16 14:16 ---
(In reply to comment #6)
> If the trigger happens to be -fstrict-aliasing, it's very likely a violation
> of
> the type-based aliasing rules of the C/C++ languages. They are usually
> exposed
> by the scheduler, which is
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.2, 4.1 only] MAXVAL()|[4.1 only] MAXVAL()
|incorrect for zero-size int |in
--- Comment #24 from paolo at gcc dot gnu dot org 2007-02-16 14:26 ---
Subject: Bug 30768
Author: paolo
Date: Fri Feb 16 14:26:21 2007
New Revision: 122044
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122044
Log:
2007-02-16 Paolo Carlini <[EMAIL PROTECTED]>
Revert.
--- Comment #25 from pcarlini at suse dot de 2007-02-16 14:28 ---
Ok, just reverted the XFAILing. I think Andrew Pinski is already working on
reducing the testcase, in case we can also ask Janis to do a binary search.
--
pcarlini at suse dot de changed:
What|Removed
GCC 4.2 fails to compile spec cpu2006/453.povray benchmark sources at -O1 and
above optimization level both on x86_64-redhat-linux and i386-redhat-linux.
Compiler must be configured with '--enable-checking' to see this failure.
messageoutput.cpp: In constructor
'pov_frontend::MessageOutput::Messag
--- Comment #26 from twhitehe at uwo dot ca 2007-02-16 15:04 ---
There is actually two different bugs here.
The original bug is a (rather convoluted) duplicate of 4882. It still remains
unresolved as of gcc-4.1.
The nested_deduction.zip source, which was submitted much later, demonstr
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-16 15:05 ---
Can you attach unreduced preprocessed source?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30823
--- Comment #15 from twhitehe at uwo dot ca 2007-02-16 15:10 ---
This is a duplicate of 4882, however, I don't have the power to mark it as that
(not that that would necessarily be a good thing as this contains more recent
begging and is flagged with a higher priority).
--
twhitehe a
--- Comment #2 from grigory_zagorodnev at linux dot intel dot com
2007-02-16 15:16 ---
Created an attachment (id=13054)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13054&action=view)
Slightly minimized failing source file
run 'g++ -c -O2 messageoutput.i' to reproduce the failur
--- Comment #3 from kevin dot glass at pnl dot gov 2007-02-16 15:29 ---
I ran this on a Pentium III and a Pentium IV using gcc 3.4.5 and gcc 4.01(?).
These produced incorrect results. I also ran them on an itanium using an older
gcc (2.9.2) in these cases, it produced correct results.
--- Comment #10 from manu at gcc dot gnu dot org 2007-02-16 15:33 ---
(In reply to comment #9)
> (In reply to comment #8)
> > I meant that the warning is appropriate but
> > the message is confusing because it is exposing that when doing
> >
> > bool x = ~b;
> >
> > we actually do
>
--- Comment #6 from manu at gcc dot gnu dot org 2007-02-16 15:43 ---
(In reply to comment #5)
> I agree with Manuel. One error should be one error, regardless of the number
> of
> lines it takes to print it.
>
> Two errors should be two errors, etc etc etc.
>
> Seems like a pretty sim
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-16 15:47 ---
// now the order changed and the compiler complains!
I think GCC 4.1.x and above are doing the correct behavior with respect of the
C++ standard. The C++ standard has specific rules about namelookup in
templates wh
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|pending |tree-optimization
Summary|ICE on cpu2006/453.povray |[4.
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-02-16 15:55
---
Fixed on mainline and 4.2. Empty slices are hopelessly broken on 4.1, I think,
so closing.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-02-16 15:55
---
Fixed on 4.2 and mainline. Closing.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-02-16 15:56
---
Fixed on mainline and 4.2. Unless you really want to backport it to 4.1.3, I'm
closing this bug.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-02-16 15:56
---
Fixed on mainline and 4.2. Unless you really want to backport it to 4.1.3, I'm
closing this bug.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-02-16 15:57
---
Fixed on mainline and 4.2. Unless you really want to backport it to 4.1.3, I'm
closing this bug.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
Testcase:
void f(int c)
{
return c;
}
int g(int c)
{
return;
}
~$ gcc -Wreturn-type -c test.c -Werror -Wfatal-errors
cc1: warnings being treated as errors
test.c: In function f:
test.c:3: warning: return with a value, in function returning void
test.c: In function g:
test.c:8: warning:
--- Comment #1 from manu at gcc dot gnu dot org 2007-02-16 15:59 ---
> If should have stopped after the first warning.
I meant "It should have".
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from manu at gcc dot gnu dot org 2007-02-16 16:04 ---
(In reply to comment #12)
> Subject: Re: -Wno-deprecated needed also for C
>
> manu at gcc dot gnu dot org wrote:
> >
> > Wouldn't it be better to remove the dead code? Or is there a policy against
> > touching thin
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-02-16 16:05
---
Harald, if you were to assign copyright of your code (or modified code) to the
FSF by filing a copyright assignment, we could integrate that into gfortran. [I
don't think you have a copyright assignment, do you?]
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||27766
nThis||
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Ke
Hi,
current mainline (revision 122038) produces an ICE in stage 2 when configured
with --with-arch=athlon64:
~/rcs-data/gcc-svn/configure --prefix=$HOME/env/gcc --enable-languages=c
--with-arch=athlon64 && make
...
/home/julian/build/bld.gcc/./gcc/xgcc -B/home/julian/build/bld.gcc/./gcc/
-B/hom
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-02-16 16:15
---
OK, given that we now have a fine memcpy code generation and nobody seems to
have an example, I'm closing this. Please reopen if you think I'm wrong.
--
fxcoudert at gcc dot gnu dot org changed:
Wh
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #2 from Zarathustra at gentlemansclub dot de 2007-02-16 16:35
---
I know the rules for template function name lookup are complicated, and I do
not claim that I understand them completely. But I am pretty sure that the
order of the definitions should not matter. There is a pa
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-02-16 16:44
---
> Do you mean it is some kind of "improvement" in GCC 4.x that makes the result
> binary to segfault in random places when compiled without -fstrict-aliasing ?
No, -fstrict-aliasing is not new, it's there since
--- Comment #26 from hp at gcc dot gnu dot org 2007-02-16 17:01 ---
Paolo Carlini, why did you revert the xfail? That's *not* according to
procedure.
I really resent that, but please discuss the issue on the gcc@ or gcc-patches@
lists, not here. If it was the extra FAIL lines for ICEin
--- Comment #27 from pcarlini at suse dot de 2007-02-16 17:04 ---
(In reply to comment #26)
> Paolo Carlini, why did you revert the xfail? That's *not* according to
> procedure.
You can resent whatever you want, but I'm maintaining the library and both
Benjamin (another maintainer) and
--- Comment #6 from patchapp at dberlin dot org 2007-02-16 17:17 ---
Subject: Bug number PR c++/23689
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00114.html
--
http://gcc.gnu.org/bugzil
--- Comment #10 from tony2001 at php dot net 2007-02-16 17:33 ---
>That's why it would be interesting to try with the 4.1.2 release too.
Well, to do that I need to compile it first.
Still working on that - compiling GCC on Solaris is a big deal.
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #6 from Ralf dot Wildenhues at gmx dot de 2007-02-16 17:40
---
This is a duplicate of 27843 (Solaris and Tru64 /bin/sh share the same issue),
which has been resolved as fixed. :-)
Someone empowered enough please reflect this in the settings, thank you!
--
http://gcc.g
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-02-16 17:41
---
> Still working on that - compiling GCC on Solaris is a big deal.
That depends on what "big deal" means. :-) You just have to unpack the tarball
and follow the instructions at
http://gcc.gnu.org/install/speci
Attached test program dumps core when built with optimization using gcc-4.1.1
on ia64-hp-hpux11.23.
It works without optimization, or when using "-O1 -fno-inline".
It is same both with HP's gcc-4.1.1 as well with self-built gcc-4.1.1, both
using GNU as.
$ /opt/hp-gcc-4.1.1/bin/gcc -v
Using built
--- Comment #1 from michael dot haubenwallner at salomon dot at 2007-02-16
17:50 ---
Created an attachment (id=13055)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13055&action=view)
testcase, extracted from preprocessor output of real application code.
Have looked at assembler o
--- Comment #2 from michael dot haubenwallner at salomon dot at 2007-02-16
17:56 ---
Created an attachment (id=13056)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13056&action=view)
the failing assembler output, created with '-O1'
Have the focus on line 18:
18 adds r8 = 20,
--- Comment #3 from michael dot haubenwallner at salomon dot at 2007-02-16
17:58 ---
Created an attachment (id=13057)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13057&action=view)
assembler output without the bug-trigger, built with '-O1 -DNOTRIGGER'
Again, focus on line 18:
1
--- Comment #13 from mrs at apple dot com 2007-02-16 17:59 ---
Adding inline seems obvious to me, all the other functions are marked inline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
--- Comment #4 from michael dot haubenwallner at salomon dot at 2007-02-16
18:06 ---
Have already debugged inside mallinfo(), where gdb says:
Program received signal SIGBUS, Bus error
si_code: 1 - BUS_ADRALN - Invalid address alignment.
0x20007edb4130:0 in mallinfo+0x180 () from /
--- Comment #12 from tony2001 at php dot net 2007-02-16 18:12 ---
Yes, sounds really easy. But the fact is that Solaris is very useful platform -
if there are any hidden bugs/problems/whatever, you can be sure you'll
encounter them on Solaris.
- native tar fails to unpack the archive (
--- Comment #4 from pault at gcc dot gnu dot org 2007-02-16 18:22 ---
Thanks for the reminder - I had not forgotten. I am trying to work my way
through the list with very limited time. I'll get there though!
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29507
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2007-02-16 18:32
---
> - fastjar compilation requires "makeinfo" (had to patch Makefile to make it
> work); see Bug 27822
Do not build Java.
> - native sed doesn't work (had to install GNU sed);
GNU sed is not required.
> - GNU s
--- Comment #10 from bangerth at dealii dot org 2007-02-16 18:39 ---
This is a duplicate of PR14032, which has more information on the matter
than the present one.
W.
*** This bug has been marked as a duplicate of 14032 ***
--
bangerth at dealii dot org changed:
What
--- Comment #16 from bangerth at dealii dot org 2007-02-16 18:39 ---
*** Bug 4882 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
---
--- Comment #14 from armin at xos dot net 2007-02-16 18:40 ---
Subject: Re: php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
> Use the Sun tools, read the instructions, build only C/C++.
that's how i did it:
CC="cc -xarch=v9" configure --prefix=/usr/local --enable-languages=c,c++
--enabl
--- Comment #17 from bangerth at dealii dot org 2007-02-16 18:47 ---
If anyone ever fixes this, the various duplicates of this bug
have a number of interesting variants that may be worth adding
to the testsuite as well.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
--- Comment #15 from tony2001 at php dot net 2007-02-16 18:53 ---
(In reply to comment #14)
> Subject: Re: php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
>
> > Use the Sun tools
No Sun compilere here.
> read the instructions, build only C/C++.
That's what I did.
> CC="cc -xarch=v9" c
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2007-02-16 19:00
---
> No Sun compiler here.
The Sun tools are /usr/ccs/bin/as and /usr/ccs/bin/ld .
> > read the instructions, build only C/C++.
>
> That's what I did.
Did you set CONFIG_SHELL?
--
http://gcc.gnu.org/bugzill
--- Comment #5 from sdack at gmx dot de 2007-02-16 19:03 ---
What I now did was the following: I set CFLAGS, CXXFLAGS, LIBCFLAGS,
LIBCXXFLAGS and BOOT_CFLAGS on the command line to make to:
"-pipe -march=athlon-xp -msse -mmmx -m3dnow -mfpmath=sse -O3
-mpreferred-stack-boundary=6 -falign
--- Comment #9 from ghazi at gcc dot gnu dot org 2007-02-16 19:13 ---
(In reply to comment #8)
> Oh, just noticed this by chance: Steve's testcase also fails with optimization
> disabled, again the call to mpfr_erf is issued in do_mpfr_arg1.
Do you get a failure with a C testcase equiva
--- Comment #10 from ghazi at gcc dot gnu dot org 2007-02-16 19:23 ---
(In reply to comment #7)
> The backtrace ends in mpfr_erf, I couldn't go further up. To overcome this
> difficulty, I set a breakpoint on the caller, see below.
That's perhaps because mpfr_erf is called from do_mpfr
1 - 100 of 138 matches
Mail list logo
