On 10/05/06, Aliesha Finkel [EMAIL PROTECTED] wrote:
template typename T
struct foo {
foo(T bar) { if (bar = 0) bar = 1; }
};
If foosigned type is instantiated elsewhere then
this check could still be useful.
My opinion is that since it may be instantiated as an signed type,
then warning
On Tue, 2006-05-09 at 22:16, Richard Kenner wrote:
Can there be two consecutive insns that use cc0 after cc0 is set?
No.
Yes. But only very very late in the compilation, once all normal
re-ordering and optimization has been completed. I think it's probably
final that folds out
Hi! I'm new of Linux and I'm not good.
How can I install Gcc if I don't have any C compiler?
On Wednesday 10 May 2006 12:33, [EMAIL PROTECTED] wrote:
Hi! I'm new of Linux and I'm not good.
How can I install Gcc if I don't have any C compiler?
install rpm package for your distribution, or download gcc in binary form.
this question doesn't belong here, so please ask on SuSE related
Aliesha Finkel [EMAIL PROTECTED] writes:
| Hi, I'm using -Wextra (-W) to compile my code, one
| feature of which is throwing a warning when an
| unsigned type is checked for = 0 since it's always
| true. In general I find this to be very helpful, but
| it throws this error even for templated
I made some modification on GCC 4.0.2 (basically, I added a simple pass) and
compiled it to binary.
But I realized that the GCC I built does not include Fortran frontend. I
think I followed the standard steps
http://gcc.gnu.org/install/configure.html
Could you please guess (based on your
Joe Buck [EMAIL PROTECTED] writes:
| Aliesha Finkel [EMAIL PROTECTED] writes:
| | Hi, I'm using -Wextra (-W) to compile my code, one
| | feature of which is throwing a warning when an
| | unsigned type is checked for = 0 since it's always
| | true. In general I find this to be very helpful,
Joe Buck [EMAIL PROTECTED] writes:
[...]
| class C {
| public:
| int size() const;
many people, including dinosaure C++ users, wish the standard containers
did not have unsigned return type for size().
-- Gaby
Aliesha Finkel [EMAIL PROTECTED] writes:
| Hi, I'm using -Wextra (-W) to compile my code, one
| feature of which is throwing a warning when an
| unsigned type is checked for = 0 since it's always
| true. In general I find this to be very helpful, but
| it throws this error even for
On 10/05/06, Joe Buck [EMAIL PROTECTED] wrote:
But then I just thought of another case:
template typename Container
struct foo {
foo(const Container bar) { if (bar.size() = 0) use(bar); }
};
For any STL-compliant container the test is redundant. But if
we put in a rule saying to suppress
On Wed, May 10, 2006 at 12:30:33PM -0400, Andrew Pinski wrote:
I think that the warning is useful if the comparison is *always* true for
any call of fooanything. But here, whether the test is redundant or not
depends on the type of bar. Possibly there's a way to determine that the
type
What reason is there to have scratch_class be something else?
SECONDARY_RELOAD_CLASS has the option of limiting the reload class.
The mn10300 has a generic SImode reload_in that allows GENERAL_REGS,
but SECONDARY_RELOAD_CLASS specifies a smaller class based on the
registers that need reloading.
On May 8, 2006, at 2:30 PM, Joseph S. Myers wrote:
void foo11(typeof (int (*)(int o[*])) i);
I think that's valid gnu99.
Speaking of typeof, should typeof (vla) follow the same rules as for
sizeof (vla)? vla, evaluate, otherwise, no eval.
On Wed, 10 May 2006, Mike Stump wrote:
On May 8, 2006, at 2:30 PM, Joseph S. Myers wrote:
void foo11(typeof (int (*)(int o[*])) i);
I think that's valid gnu99.
Speaking of typeof, should typeof (vla) follow the same rules as for sizeof
(vla)? vla, evaluate, otherwise, no eval.
Mike Stump [EMAIL PROTECTED] writes:
Speaking of typeof, should typeof (vla) follow the same rules as for
sizeof (vla)? vla, evaluate, otherwise, no eval.
How would typeof be able to eval anything?
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH,
On Wed, 10 May 2006, Andreas Schwab wrote:
Mike Stump [EMAIL PROTECTED] writes:
Speaking of typeof, should typeof (vla) follow the same rules as for
sizeof (vla)? vla, evaluate, otherwise, no eval.
How would typeof be able to eval anything?
If you have typeof ((int (*)[f()])g()),
Joseph S. Myers [EMAIL PROTECTED] writes:
| On Wed, 10 May 2006, Andreas Schwab wrote:
|
| Mike Stump [EMAIL PROTECTED] writes:
|
| Speaking of typeof, should typeof (vla) follow the same rules as for
| sizeof (vla)? vla, evaluate, otherwise, no eval.
|
| How would typeof be able to
What optimisation option is needed to prod arm-elf-gcc -mthumb to
generate a tail call? ARM works as expected.
Please cc me in your reply. Thanks!
Shaun
arm-elf-gcc (GCC) 4.1.0
$ cat EOF tail.c
int tail(void);
int main()
{
return tail();
}
EOF
$ arm-elf-gcc -mthumb -S -O2 tail.c
$ sed
DJ Delorie [EMAIL PROTECTED] writes:
What reason is there to have scratch_class be something else?
SECONDARY_RELOAD_CLASS has the option of limiting the reload class.
The mn10300 has a generic SImode reload_in that allows GENERAL_REGS,
but SECONDARY_RELOAD_CLASS specifies a smaller class
Ian Lance Taylor wrote:
You should run any patch past Joern, though.
I'd hesitate to apply patches to default_secondary_reload. If your port
triggers any of the sanity checks, convert it to the new infrastructure,
as it provides a much better interface.
Bernd
On Wed, May 10, 2006 at 02:38:30PM -0600, Shaun Jackman wrote:
What optimisation option is needed to prod arm-elf-gcc -mthumb to
generate a tail call? ARM works as expected.
It's not yet supported. Remember, bl has a long range but clobbers lr, and
there's no long branch instruction, so you
I'd hesitate to apply patches to default_secondary_reload.
Even if it's wrong?
If your port triggers any of the sanity checks, convert it to the
new infrastructure, as it provides a much better interface.
In my case, I'm just trying to get the am33 port to function, because
I have some
On Wednesday 10 May 2006 21:38, Shaun Jackman wrote:
What optimisation option is needed to prod arm-elf-gcc -mthumb to
generate a tail call? ARM works as expected.
Thumb only has very limited (256 byte) direct branch offsets, so tail calls
aren't possible/useful.
Paul
In http://gcc.gnu.org/ml/gcc/2006-05/msg00254.html, Ian Lance Taylor wrote:
That said, while it makes sense to me that SECONDARY_RELOAD_CLASS and
the reload_{in,out} instruction should be in synch--that was one of
the flaws of the old scheme, really--I can't think of anything that
would go
How about this? Tested under mipsisa64-elf with no regressions. The
other two I found by inspection; they're the only other two that have
.sdata and use -G 0.
2006-05-09 DJ Delorie [EMAIL PROTECTED]
* crtstuff.c: Ensure that __dso_handle is placed in .sdata for
mips, iq2000,
The pages at http://www.gnu.org/software/gcc/ are
several months old, even though the page at
http://gcc.gnu.org/about.html says:
The pages on gcc.gnu.org are updated live (that
is, directly after a change has been made);
www.gnu.org is updated once a day at 4:00 -0700
(PDT).
The pages on
cc -O -pipe -funroll-loops -DIN_GCC -DHAVE_CONFIG_H
-DPREFIX=\/usr/obj/usr/src/tmp/usr\
-I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools
-I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools
-I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc
--- Comment #2 from ajrobb at bigfoot dot com 2006-05-10 09:45 ---
Created an attachment (id=11428)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11428action=view)
multi-word bit shift
This is my loop - using a single index that decrements to zero
I have seen simpler loops
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-10 08:06 ---
Fixed in 4.0.3:
/tmp /space/rguenther/install/gcc-4.0.3/bin/g++ -Wall -S t.C
t.C:11: error: declaration of '~TPoligon' as member of 'TPoints'
--
rguenth at gcc dot gnu dot org changed:
What
Fold does not fold two comparisons in a row if the intermediate type differs
in being a pointer vs. an integer variable. This also is the reason for not
folding (Foo *)(char *)foo with foo being of Foo type (we can fold that to
(Foo *)foo).
There's code to do that I think, but it's just missing
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-10 09:07
---
I can reproduce this ICE with mainline on i686-linux. I propose the following
patch:
Index: parse.c
===
--- parse.c (revision 113603)
+++
--- Comment #2 from christophe dot gengembre at paris dot ensam dot fr
2006-05-10 08:28 ---
Created an attachment (id=11427)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11427action=view)
source that triggered the error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27521
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-10 10:22 ---
Subject: Bug 27302
Author: rguenth
Date: Wed May 10 10:22:39 2006
New Revision: 113670
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113670
Log:
2006-05-10 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-05-10 11:03 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Hello.
We have Client/server socket application (multiple clients and servers).
Servers are multiplatform can be compiled for Windows (MSVC) and for Linux
(GCC).
Recently we detected memory leak in one of kinde of our servers. At the start
it uses only 15m (that is normally). Then it slowly grows
--- Comment #1 from chris at bubblescope dot net 2006-05-10 11:31 ---
Can you provide a complete program which demonstrates this link? I've tried
looking at the code in question myself, and cannot observe a memory leak
myself.
--
chris at bubblescope dot net changed:
--- Comment #1 from P dot Schaffnit at access dot rwth-aachen dot de
2006-05-10 11:34 ---
Sorry, I missed it before, but this could definitly be a dupplicate of 19777.
Philippe
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27524
--- Comment #2 from pcarlini at suse dot de 2006-05-10 12:10 ---
Chris is right. Certainly we are not aware of any problem in that code, in
particular the 3.4.5 version, very close to the original HP/SGI code and very
well tested from that point of view (at least). Please provide a
--- Comment #3 from sebastian dot pop at cri dot ensmp dot fr 2006-05-10
12:26 ---
Created an attachment (id=11429)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11429action=view)
fix
proposed fix. I didn't tested it other than making sure it fixed the bug.
--
--- Comment #5 from sebastian dot pop at cri dot ensmp dot fr 2006-05-10
12:32 ---
Created an attachment (id=11430)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11430action=view)
first shot at fixing this
didn't tested the patch, other than with RUNTESTFLAGS=tree-ssa.exp
and the
--- Comment #3 from ksharenkov at ya dot ru 2006-05-10 12:48 ---
Ok, i will try to create a short program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27530
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-05-10
12:59 ---
I think that it is not correct to emit an ICE on this one. The patch below
emits an error and bails out.
I will submit in the next 24hours.
Paul
Index: gcc/fortran/symbol.c
--- Comment #3 from christophe dot gengembre at paris dot ensam dot fr
2006-05-10 13:49 ---
the bug is trigged in Subroutine RecupValLuesDsCmdLC.
A .f source file with only Subroutine RecupValLuesDsCmdLC code trigger the
error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27521
I get a undefined reference to `.LL226' error when compiling RCS with -O2 on
sparc using gcc 4.2. This problem goes away when I use -O2. The assembler
output shows that .LL226 is referenced but not defined anywhere. I'll attach
the .i file and the .s file with -O1 (works) and -O2 (fails).
--- Comment #1 from tbm at cyrius dot com 2006-05-10 13:51 ---
Created an attachment (id=11431)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11431action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
--- Comment #2 from tbm at cyrius dot com 2006-05-10 13:52 ---
Created an attachment (id=11432)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11432action=view)
assembler with -O1 (works)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
--- Comment #7 from patchapp at dberlin dot org 2006-05-10 13:52 ---
Subject: Bug number PR25514
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/2006-04/msg00958.html
--
--- Comment #3 from tbm at cyrius dot com 2006-05-10 13:52 ---
Created an attachment (id=11433)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11433action=view)
assembler with -O2 (fails) - .LL226 is not defined
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
--- Comment #3 from jjcogliati-r1 at yahoo dot com 2006-05-10 13:54 ---
(In reply to comment #1)
Confirmed. Though sometimes I wonder if this is an over use of printf style
debugging.
rantWell, I have a fortran program. It ran fine for the first 10 and a half
hours. Then it
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #5 from kazu at gcc dot gnu dot org 2006-05-10 14:21 ---
Reduced down to:
extern void bar (int);
int
foo (int a, int b)
{
int c = a == b;
if (c)
bar (c);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27477
Reduced testcase from gcc.dg/builtin-object-size-1.c:
void abort(void);
int main (void)
{
void *b = Labcd;
if (__builtin_object_size (b + 2, 0) != sizeof (Labcd) - 2)
abort ();
return 0;
}
now, CCP propagates the constant Labcd[0] to the addition stmt:
b_1 = a[0];
D.1526_2 = a[0]
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:37
---
This is a duplicate of PR24549 (it's fixed by the same one-line patch).
*** This bug has been marked as a duplicate of 24549 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:37
---
*** Bug 27487 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-10 14:37 ---
CCP produces this tree since forever.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from malitzke at metronets dot com 2006-05-10 14:43 ---
To A Pinski
While I am _not_ a C lawyer, the following seems pertinent:
1 __FUNCTION__ is _not_ a predefined macro. However __func__ a predefined
identifier and I will take this up with the kernel people. However,
The code
inline int almost_equal(float a, float b, int maxUlps = 16) {
int intDiff = *(reinterpret_castint*(a)) -
*(reinterpret_castint*(b));
printf(intDiff %d\n,intDiff);
return intDiff;
}
gives different results when compiled with and without -O2
(yes, floats are
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-10 14:48 ---
Looks more like a typo in tree-object-size.c:plus_expr_object_size
Index: tree-object-size.c
===
*** tree-object-size.c (revision 113669)
---
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:51
---
Subject: Bug 24549
Author: fxcoudert
Date: Wed May 10 14:51:26 2006
New Revision: 113671
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113671
Log:
PR fortran/24549
* parse.c
--- Comment #1 from pluto at agmk dot net 2006-05-10 14:51 ---
you're violating the aliasing rules, so use -fno-strict-aliasing option.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27533
--- Comment #2 from ulrich dot lauther at siemens dot com 2006-05-10 14:53
---
Created an attachment (id=11434)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11434action=view)
Complete tiny example exposing the problem
I submit this version that includes stdio.h for readability,
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-05-10 14:56
---
I have a patch that needs PR27529 fixed first, that needs PR27532 fixed first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
--- Comment #6 from dje at gcc dot gnu dot org 2006-05-10 14:56 ---
The section anchors feature does not like __FUNCTION__ or __func__ as an
inlined asm argument.
Also, some rs6000 work is not very informative or useful.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
--- Comment #3 from ulrich dot lauther at siemens dot com 2006-05-10 14:55
---
Created an attachment (id=11435)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11435action=view)
same as before, but stdio.h expanded
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27533
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-05-10
14:58 ---
(In reply to comment #2)
Very odd; I do nightly builds of mainline on two different systems. On one of
them this failure stopped on 20060430 and on the other it stopped on 20060503,
but failed on
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:58
---
Subject: Bug 20460
Author: fxcoudert
Date: Wed May 10 14:58:48 2006
New Revision: 113672
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113672
Log:
PR fortran/20460
* resolve.c
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-10 14:59
---
As Pawel already pointed out:
Your code is brokan as you are violating the aliasing rules.
Please read about this in the non-bug section of http://gcc.gnu.org/bugs.html :
Casting does not work as expected when
--- Comment #96 from reichelt at gcc dot gnu dot org 2006-05-10 14:59
---
*** Bug 27533 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from kazu at gcc dot gnu dot org 2006-05-10 15:00 ---
The combiner seems to be doing something strange:
(insn 13 12 16 2 (set (reg:HI 21)
(eq:HI (cc0)
(const_int 0 [0x0]))) 237 {*bstzhireg} (nil)
(nil))
(insn 16 13 17 2 (set (cc0)
(reg:HI
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-10 15:06 ---
(In reply to comment #5)
To A Pinski
While I am _not_ a C lawyer, the following seems pertinent:
Why do you think this is related to the C standard?
1 __FUNCTION__ is _not_ a predefined macro. However
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-10 15:10 ---
Just to explain why a[0] + 2B is valid gimple:
a[0] is a gimple invariant and likewise for 2b. Therefor the two sides of
the Plus expression are going to valid for it. Therefor valid gimple.
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||link-failure
Target Milestone|--- |4.2.0
--- Comment #5 from pluto at agmk dot net 2006-05-10 15:26 ---
(In reply to comment #0)
The code
inline int almost_equal(float a, float b, int maxUlps = 16) {
int intDiff = *(reinterpret_castint*(a)) -
*(reinterpret_castint*(b));
if you really need such
Attempting to pass a pointer to a va_list variable to a function expecting such
a pointer causes a warning about passing a pointer of incompatible type.
[EMAIL PROTECTED] ~/work/ffdev $ gcc -v -save-temps -ansi -pedantic -Wall -W -O
-c t.c
Reading specs from
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 15:46 ---
It is an object type. An array is an object type.
*** This bug has been marked as a duplicate of 14557 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-05-10 15:46
---
*** Bug 27534 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 15:47 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #4 from ksharenkov at ya dot ru 2006-05-10 15:58 ---
I have tried to create simple test case (about 200 rows) where I tried to
reproduce key code fragments. In simple test case leak not reproduced. But I
have easy reproduced it with very small application based on main
--- Comment #4 from janis at gcc dot gnu dot org 2006-05-10 16:03 ---
The test passes on both of my nightly builds now, so I'm closing this.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from kazu at gcc dot gnu dot org 2006-05-10 16:49 ---
Assigning to Volker as he posted a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-05-10 16:52
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-05-10 16:55
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kazu at gcc dot gnu dot org 2006-05-10 17:00 ---
Could you submit a preprocessed testcase?
Many of us do not have m68k hardware that can be used for bootstrap.
Thanks,
--
kazu at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from kazu at gcc dot gnu dot org 2006-05-10 17:35 ---
Subject: Bug 24949
Author: kazu
Date: Wed May 10 17:35:24 2006
New Revision: 113675
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113675
Log:
PR target/24949
* config/m68k/m68k.md
--- Comment #2 from kazu at gcc dot gnu dot org 2006-05-10 17:35 ---
Just checked in a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from aph at gcc dot gnu dot org 2006-05-10 17:41 ---
Xref: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191211
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12257
--- Comment #29 from pinskia at gcc dot gnu dot org 2006-05-10 17:48
---
Since Honza's patch to emit static and inline functions at -O0, this now fails
with BOOTCFLAGS as -O0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-05-10 18:27 ---
Subject: Bug 27470
Author: tkoenig
Date: Wed May 10 18:26:51 2006
New Revision: 113680
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113680
Log:
2005-05-10 Thomas Koenig [EMAIL PROTECTED]
PR
/*
ICE using gcc-4.2-20060506 on x86_64-unknown-linux-gnu
Regression from gcc-4.1.0
Source cut down from gmp-4.2.1/tests/refmpf.c
% gcc-4.2-20060506 -O3 -c foo.c
foo.c: In function âfooâ:
foo.c:27: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 19:06 ---
Oh, this is no longer a regression as -fsee is not enabled by default in newer
versions of 4.2 (a day after it was enabled by default for -O3, it was turned
off to fix some regressions at -O3).
--
pinskia at gcc
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-05-10 19:41 ---
Subject: Bug 27532
Author: rguenth
Date: Wed May 10 19:41:46 2006
New Revision: 113682
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113682
Log:
2006-05-10 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-05-10 19:42 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
$ /tmp/cvs/gcc-test-r113398/Build/./gcc/xgcc
-B/tmp/cvs/gcc-test-r113398/Build/./gcc/
-B/tmp/cvs/gcc-test-r113398/Build/root/powerpc64-suse-linux/bin/
-B/tmp/cvs/gcc-test-r113398/Build/root/powerpc64-suse-linux/lib/ -isystem
/tmp/cvs/gcc-test-r113398/Build/root/powerpc64-suse-linux/include
The g++ compiler for i386 target assumes that the stack is aligned by 16 when
storing xmm registers to the stack. However, the stack is not aligned when
compiling with option -Os (or with the Intel compiler). A misaligned memory
operand to an XMM instruction causes a general protection exception.
FAIL: gcc.c-torture/execute/20030128-1.c execution, -O1
FAIL: gcc.c-torture/execute/20030128-1.c execution, -O2
FAIL: gcc.c-torture/execute/20030128-1.c execution, -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/20030128-1.c execution, -O3 -g
FAIL: gcc.c-torture/execute/20030128-1.c
FAIL: gcc.c-torture/execute/941014-2.c execution, -O1
FAIL: gcc.c-torture/execute/941014-2.c execution, -O2
FAIL: gcc.c-torture/execute/941014-2.c execution, -Os
--
Summary: gcc.c-torture/execute/941014-2.c FAILs
Product: gcc
Version: unknown
--- Comment #10 from flash at pobox dot com 2006-05-10 20:08 ---
PalmSource bug #126750.
--
flash at pobox dot com changed:
What|Removed |Added
CC|
--- Comment #8 from malitzke at metronets dot com 2006-05-10 20:17 ---
Well Fellas: Either have the Steering Committee revise the
Invitation to participate in testing; quoted iselectively below.
Or,have a member from the Steering Committe ask me to refrain
from further participation. I,
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 20:39 ---
First so what darwin aligns the stack by default to 16bytes (that is demanded
by their ABI since their ABI is newer than GNU/Linux's). GNU/Linux follows the
SYSV x86 ABI which is documented, maybe you cannot find
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-05-10 20:41 ---
This has nothing to do with the C standard or even standard code. This is
inline-asm constraint which is failing and the inline-asm in the code is wrong.
This is a bug in the code so report it to Linux instead of
1 - 100 of 129 matches
Mail list logo
