--- Comment #5 from pault at gcc dot gnu dot org 2006-06-01 05:58 ---
Fixed on trunk and 4.1.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2006-06-01 05:57 ---
Fixed on trunk and 4.1.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-01 05:56 ---
Subject: Bug 25147
Author: pault
Date: Thu Jun 1 05:56:48 2006
New Revision: 114299
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114299
Log:
2006-06-01 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #5 from pault at gcc dot gnu dot org 2006-06-01 05:56 ---
Subject: Bug 25098
Author: pault
Date: Thu Jun 1 05:56:48 2006
New Revision: 114299
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114299
Log:
2006-06-01 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-01 05:36 ---
Can you try building in a different directory than the source directory and try
using make bootstrap instead of just make?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-01 04:57 ---
fastjar is removed in the mainline sources.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from aoliva at gcc dot gnu dot org 2006-06-01 04:56 ---
Fixed
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from aoliva at gcc dot gnu dot org 2006-06-01 04:55 ---
Subject: Bug 26660
Author: aoliva
Date: Thu Jun 1 04:55:32 2006
New Revision: 114298
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114298
Log:
PR c++/26660
* parser.c (cp_parser_initial_pragma): Read one m
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-01 04:53 ---
--with-headers with a combined build is not really a good thing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2006-06-01 04:35 ---
Subject: Bug 25147
Author: pault
Date: Thu Jun 1 04:35:38 2006
New Revision: 114296
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114296
Log:
2006-06-01 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-01 04:35 ---
Subject: Bug 25098
Author: pault
Date: Thu Jun 1 04:35:38 2006
New Revision: 114296
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114296
Log:
2006-06-01 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-06-01 04:33 ---
if (type$basicType_ == SR.5) goto ; else goto ;
...
short int type$basicType_;
int SR.5;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27826
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-01 04:27 ---
My reduced testcase also fails with 4.0.2 which I was somewhat expecting.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-01 03:47 ---
Another reduced testcase:
extern double R_NaReal;
void z_atan2 (double _Complex * r, double _Complex * ccs)
{
if (*ccs == 0)
__imag__ *r = R_NaReal;
}
--
pinskia at gcc dot gnu dot org changed:
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-06-01 03:47 ---
*** Bug 27841 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-01 03:47 ---
*** This bug has been marked as a duplicate of 27341 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from carlos at gcc dot gnu dot org 2006-06-01 03:43 ---
Subject: Bug 27829
Author: carlos
Date: Thu Jun 1 03:43:00 2006
New Revision: 114294
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114294
Log:
2006-05-31 Carlos O'Donell <[EMAIL PROTECTED]>
Back
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-01 03:39 ---
Reduced testcase:
struct GeometryType
{
int basicType_:16;
bool operator==(const GeometryType& other) const {
return basicType_==other.basicType_;
}
};
struct Geometry {
GeometryType type () const{};
};
void
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-01 02:43 ---
#20 0x00572359 in get_AT (die=0x2b0a86e0, attr_kind=DW_AT_inline)
at /home/pinskia/src/gcc-4.1/gcc/gcc/dwarf2out.c:5235
#21 0x00572359 in get_AT (die=0x2b0a8870, attr_kind=DW_AT_inline)
at /ho
--- Comment #3 from roger at eyesopen dot com 2006-06-01 02:41 ---
This is now fixed on mainline provided the user specifies -ffast-math.
There are some complications where imagpart(z*~z) can be non-zero, if
imagpart(z) is non-finite, such as an Inf or a NaN. It's unclear from
the fortr
--- Comment #1 from flash at pobox dot com 2006-06-01 02:30 ---
Created an attachment (id=11562)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11562&action=view)
Preprocessed Delta-reduced source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27851
The code below causes a checking=yes build of GCC 4.1.1 to report "Internal
error: Segmentation fault (program cc1)" after more than an hour. (Ninety
minutes in the session below; sixty-eight minutes the first time, on a faster
and less loaded machine.) Likewise a checking=all build of GCC 4.1.0.
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2006-06-01
00:21 ---
Geoff,
Then I assume you approve of Andrew Pinski's fix? I have uploaded the
corrected patch
that Andrew sent me which solves this problem in varasm.c. Or did you have a
different
approach in mind?
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2006-06-01
00:05 ---
Created an attachment (id=11561)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11561&action=view)
corrected patch as provided by Andrew
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26427
--- Comment #9 from sabre at nondot dot org 2006-05-31 23:00 ---
Right, clearly issuing good diagnostics is a matter of balancing cases against
each other. While I agree that this is valid:
void f() {
void g();
g();
}
I don't see it used very often, particularly not in C++
--- Comment #8 from mark at codesourcery dot com 2006-05-31 22:56 ---
Subject: Re: [4.0/4.1/4.2 Regression] C++ error recovery regression
sabre at nondot dot org wrote:
> --- Comment #7 from sabre at nondot dot org 2006-05-31 22:17 ---
> Ok, makes sense. The strategy that mad
--- Comment #12 from geoffk at gcc dot gnu dot org 2006-05-31 22:48 ---
The issue here is that Darwin does not support zero-sized objects in the
linker. It just won't work.
So, you need to make sure that the linker never sees them. This is presently
done for Darwin by adding a byte of
--- Comment #11 from mrs at apple dot com 2006-05-31 22:32 ---
I have a patch:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01580.html
that I think fixes this problem. I'd be cusious to hear if it fixes the
Fortran problem for you.
--
mrs at apple dot com changed:
What
--- Comment #7 from eweddington at cso dot atmel dot com 2006-05-31 22:19
---
(In reply to comment #6)
> Thanks a lot, hope it will find the way to WinAVR soon.
Yes, it will.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--
--- Comment #7 from sabre at nondot dot org 2006-05-31 22:17 ---
Ok, makes sense. The strategy that made sense to me was "If I see a definition
for something that obviously has to be at global scope, but is defined inside
of a function, pop all the way out to global scope and continue,
In order to build a gcc for a newlib target with a working libgcov,
you need build from a unified source tree and configure using
--with-headers --with-newlib.
Using current mainline sources, when configuring with:
../srcw/configure --target=sh-elf --with-headers --with-newlib
the compiler fails
--- Comment #14 from mt1 at systella dot fr 2006-05-31 21:54 ---
GMP-4.2
./configure --prefix=/opt --with-gnu-ld --disable-cxx --disable-nails
--disable-mpfr
MPFR-2.2
./configure --enable-mpfr --with-gmp-=/opt --prefix=/opt --with-gmp-lib=/opt
--with-gmp-include=/opt && make -j2
I thi
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2006-05-31
21:47 ---
My guesstimate is that for combine.i about 5-8% of the total number of
expressions
in the gimple dump are due to the gimplification inefficiencies shown in
PRs 27798 27800 27809 27810, so these issues mig
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-05-31 21:25
---
> I have configured gcc with:
> lebegue:[~/gcc-4.1.1/build] > ../configure --prefix=/opt
> --enable-threads=posix
> --enable-languages=c,c++,fortran,java --with-gnu-as --with-gnu-ld
> --with-mpfr=/opt --disable-
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-05-31 21:10 ---
This is a real bug, and not an issue of a missing
test case.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-05-31 20:51 ---
Fixed on trunk and 4.1. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-05-31 20:51 ---
Subject: Bug 23151
Author: tkoenig
Date: Wed May 31 20:50:34 2006
New Revision: 114281
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114281
Log:
2006-05-31 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--- Comment #12 from mt1 at systella dot fr 2006-05-31 20:42 ---
Eric,
I have configured gcc with:
lebegue:[~/gcc-4.1.1/build] > ../configure --prefix=/opt --enable-threads=posix
--enable-languages=c,c++,fortran,java --with-gnu-as --with-gnu-ld
--with-mpfr=/opt --disable-multilib && mak
--- Comment #1 from tbm at cyrius dot com 2006-05-31 20:35 ---
This is fairly new - didn't happen with 20060508.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27804
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-05-31 20:22 ---
This is caught on mainline:
$ gfortran qq.f90
In file qq.f90:3
MODULE PROCEDURE Is_Equal_To_Single
1
Error: User operator procedure 'is_equal_to_single' at (1) must be a
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-05-31 20:12
---
Fixed in 4.1.2, 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-05-31 20:12
---
Fixed in 4.1.2, 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-05-31 20:11
---
Fixed in 4.1.2, 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
A
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-05-31 20:08
---
Subject: Bug 27385
Author: mmitchel
Date: Wed May 31 20:07:35 2006
New Revision: 114280
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114280
Log:
PR c++/27801
* call.c (perform_implicit_co
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-05-31 20:08
---
Subject: Bug 27801
Author: mmitchel
Date: Wed May 31 20:07:35 2006
New Revision: 114280
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114280
Log:
PR c++/27801
* call.c (perform_implicit_co
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-05-31 20:08
---
Subject: Bug 26496
Author: mmitchel
Date: Wed May 31 20:07:35 2006
New Revision: 114280
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114280
Log:
PR c++/27801
* call.c (perform_implicit_co
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-05-31 20:03
---
Subject: Bug 27801
Author: mmitchel
Date: Wed May 31 20:03:27 2006
New Revision: 114279
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114279
Log:
PR c++/27801
* call.c (perform_implicit_co
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-05-31 20:03
---
Subject: Bug 27385
Author: mmitchel
Date: Wed May 31 20:03:27 2006
New Revision: 114279
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114279
Log:
PR c++/27801
* call.c (perform_implicit_co
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-05-31 20:03
---
Subject: Bug 26496
Author: mmitchel
Date: Wed May 31 20:03:27 2006
New Revision: 114279
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114279
Log:
PR c++/27801
* call.c (perform_implicit_co
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-05-31 20:03
---
Subject: Bug 26496
Author: mmitchel
Date: Wed May 31 20:03:12 2006
New Revision: 114278
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114278
Log:
PR c++/27801
* call.c (perform_implicit_co
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-05-31 20:03
---
Subject: Bug 27385
Author: mmitchel
Date: Wed May 31 20:03:12 2006
New Revision: 114278
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114278
Log:
PR c++/27801
* call.c (perform_implicit_co
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-05-31 20:03
---
Subject: Bug 27801
Author: mmitchel
Date: Wed May 31 20:03:12 2006
New Revision: 114278
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114278
Log:
PR c++/27801
* call.c (perform_implicit_co
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-05-31 19:54
---
GCC 3.3 isn't really a very good benchmark, since the parser there didn't
handle much of the language. We'd have to figure out what it actually did for
recovery (how many tokens did it skip, where did it pick thin
--- Comment #6 from familie dot glaser at web dot de 2006-05-31 19:45
---
(In reply to comment #4)
> Yes this was fixed in 4.0.0.
Thanks a lot, hope it will find the way to WinAVR soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27847
--- Comment #5 from familie dot glaser at web dot de 2006-05-31 19:38
---
Created an attachment (id=11559)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11559&action=view)
gcc -save-temps output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27847
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-31 19:37 ---
Yes this was fixed in 4.0.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from familie dot glaser at web dot de 2006-05-31 19:36
---
Created an attachment (id=11558)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11558&action=view)
commented assembler-listing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27847
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-31 19:36 ---
Can you try 4.0.x or 4.1.x, I think this and many other inlining related missed
optimzations were fixed in 4.0.x and above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from familie dot glaser at web dot de 2006-05-31 19:35
---
Created an attachment (id=11557)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11557&action=view)
source (without includes)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27847
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-31 19:34 ---
No, this has nothing to do with global namespace being polluted. In fact this
is the correct behavior. What is happening is you forgot about Argument
dependent lookup.
--
pinskia at gcc dot gnu dot org changed:
In some cases a inlined return of just a byte produce unnecessary treatment of
the high byte, like it should fulfill the ABI calling convention.
The problem with the unoptimized inlined returs seams (after some trials) to
raise (long) after constant assignment in combination with other facts.
The
--- Comment #1 from mbo at intec dot dk 2006-05-31 19:24 ---
Created an attachment (id=11556)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11556&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27846
Problem:
The following code fails to compile. The problem is that call to max is
ambiguous. It seems as if the compiler can also see std::max eventhough I have
not included the global namespace by using "using namespace std;" or by using
"using std::max;". I find this very odd, since the namespace
--- Comment #5 from sabre at nondot dot org 2006-05-31 19:14 ---
... Adding mark so that he will hopefully see the previous comment.
--
sabre at nondot dot org changed:
What|Removed |Added
---
--- Comment #4 from sabre at nondot dot org 2006-05-31 19:13 ---
I guess I don't follow your logic here. I agree that the EDG approach is
inferior to the current GCC implementation, but the current GCC approach is
inferior to the old GCC implementation (thus it's a regression, if not a
--- Comment #1 from lucier at math dot purdue dot edu 2006-05-31 18:44
---
Subject: Re: Can't build 64-bit 4.2.0 with 4.1.1 on darwin-ppc
OK, so you changed it from c to driver. Do you think it should be
reported against 4.1.1 (as I did) or against 4.2.0?
On May 31, 2006, at 1:40
The build compiler:
[lindv2:gcc/mainline/objdir64] lucier% gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8.6.0
Configured with: ../configure --with-gmp=/opt/local/ --with-mpfr=/opt/local/
--prefix=/pkgs/gcc-4.1.1
Thread model: posix
gcc version 4.1.1
The configure and make bootstrap:
For gcc-4.2-20060527(also gcc-4.2-20060520) on alphaev68-dec-osf5.1b
after
configure --enable-languages=c
make bootstrap
make install
'make install' fails with
/home/kate/gcc-4.2-20060527/src/gcc-4.2-20060527/install-sh -c fixinc.sh
/home/kate/gcc-4.2-20060527/alpha-OSF1-V5/libexec/gcc/
--- Comment #18 from hjl at lucon dot org 2006-05-31 17:31 ---
Last time when I tried it on x86 and x86-64 with SPEC CPU 2000, it didn't
do anything useful. I will try it again with SPEC CPU 2000 and 2006.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-31 17:13 ---
What about this, deleting altivec_vspltisw_v4sf and changing all references to
gen_altivec_vspltisw_v4sf
to something like
gen_altivec_vspltisw( gen_lowpart (V4SImode, reg), ...);
That should keep the same code an
--- Comment #2 from uweigand at gcc dot gnu dot org 2006-05-31 16:59
---
I'm not sure (subreg:SF (const_int)) is canonical RTL, I haven't seen
subregs of anything but REG or MEM.
In any case, I don't really see what this would buy us over an UNSPEC -- will
the generic simplifier be ab
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-31 16:50 ---
Maybe:
(define_insn "altivec_vspltisw_v4sf"
[(set (match_operand:V4SF 0 "register_operand" "=v")
(vec_duplicate:V4SF
(subreg:SF (match_operand:QI 1 "s5bit_cint_operand" "i"]
OR something lik
The following test case gets miscompiled and fails when built
with "-O -maltivec -mabi=altivec -include altivec.h" on GCC 4.1:
extern void abort (void);
void test (vector float *p, int n)
{
int i;
for (i = 0; i < n; i++)
p[i] = vec_abs (p[i]);
}
int
main (void)
{
vector float p = (vect
--- Comment #1 from tbm at cyrius dot com 2006-05-31 15:22 ---
Created an attachment (id=11554)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11554&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27841
(sid)3415:[EMAIL PROTECTED]: ~/delta/bin] /usr/lib/gcc-snapshot/bin/gcc -c -O1
mini.c
(sid)3416:[EMAIL PROTECTED]: ~/delta/bin] /usr/lib/gcc-snapshot/bin/gcc -c -O2
mini.c
mini.c: In function 'z_atan2':
mini.c:33: internal compiler error: tree check: expected ssa_name, have
symbol_memory_tag in v
--- Comment #5 from bangerth at dealii dot org 2006-05-31 14:57 ---
Thanks for the feedback. It is apparently fixed then...
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-31 14:38 ---
__asm__ __volatile__(
"lock;xaddl %0, %1"
:"=r"(i)
:"m"(*p), "0"(i));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27836
--- Comment #8 from whaley at cs dot utsa dot edu 2006-05-31 14:12 ---
Subject: Re: gcc 4 produces worse x87 code on all platforms than gcc 3
Uros,
>IMO the fact that gcc 3.x beats 4.x on this code could be attributed to pure
>luck.
As far as understanding from first principles, per
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2006-05-31 14:04
---
Yes, this is fixed. Maybe it's worth enabling -fsee at -O3 on x86?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27829
--- Comment #7 from rearnsha at gcc dot gnu dot org 2006-05-31 13:50
---
patch installed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #6 from rearnsha at gcc dot gnu dot org 2006-05-31 13:41
---
Subject: Bug 27829
Author: rearnsha
Date: Wed May 31 13:41:08 2006
New Revision: 114265
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114265
Log:
PR target/27829
* arm.c (arm_print_operand
--- Comment #98 from schwab at suse dot de 2006-05-31 13:04 ---
*** Bug 27838 has been marked as a duplicate of this bug. ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #1 from schwab at suse dot de 2006-05-31 13:04 ---
You are violating the aliasing rules.
*** This bug has been marked as a duplicate of 21920 ***
--
schwab at suse dot de changed:
What|Removed |Added
---
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-05-31 12:53
---
OK, I got the confirmation that it was a GMP/MPFR miscompilation with mainline
GCC. Downgrading to gcc-3.4.5 gives a working GMP/MPFR combination. I'll upload
new binaries in the next few days.
Longer story: I in
I have enumerated type defined as follows
enum EQUEUEDWRITERFILEERROR
{
QWFE__MIN,
QWFE_REOPEN = QWFE__MIN,
QWFE_WRITE,
QWFE_OVERFLOW,
QWFE__MAX,
};
For it I have prefix increment operator defined with macro
#define DEFINE_ENUM_INC_DEC(EnumType) \
--- Comment #5 from patchapp at dberlin dot org 2006-05-31 12:45 ---
Subject: Bug number PR24558
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-05/msg01548.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from patchapp at dberlin dot org 2006-05-31 12:45 ---
Subject: Bug number PR 27786
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-05/msg01544.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #3 from l_heldt at poczta dot onet dot pl 2006-05-31 11:43
---
Can you tell me how correct asm body should look like?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27836
--- Comment #2 from schwab at suse dot de 2006-05-31 11:20 ---
You are not using %2 in the asm body. There is no requirement that %0 and %2
expand to the same register.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #1 from l_heldt at poczta dot onet dot pl 2006-05-31 11:14
---
Problem does not show up in g++-4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27836
Compiler generates bad assembler code for xaddl __asm__ function when -O3 is
turned on.
Following code will generate bad assembly:
#include
inline int atomicAddReturn(int i, int volatile* p)
{
int __i;
__i = i;
__asm__ __volatile__(
"lock;xaddl %0, %1"
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-05-31 11:13
---
The modified testcase from comment #8 should return 0,
but returns 255 (a.k.a -1) when compiled with -O2.
The bad news is that this also affects the 4.1 branch (4.1.0 and later).
The failure on the 4.1 branch is n
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-05-31 11:07
---
Created an attachment (id=11550)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11550&action=view)
modified testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27768
--- Comment #7 from uros at kss-loka dot si 2006-05-31 10:56 ---
IMO the fact that gcc 3.x beats 4.x on this code could be attributed to pure
luck.
Looking into 3.x RTL, these things can be observed:
Instruction that multiplies pA0 and rB0 is described as:
__.20.combine:
(insn 75 73
--- Comment #5 from rearnsha at gcc dot gnu dot org 2006-05-31 10:13
---
Created an attachment (id=11549)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11549&action=view)
patch in testing
--
rearnsha at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from rearnsha at gcc dot gnu dot org 2006-05-31 10:12
---
Confirmed on trunk.
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 109 matches
Mail list logo
