I get the following ICE with gcc 4.2. This looks suspiciously a lot like
PR26994 but the patch suggested there is Fortran specific whereas my test case
is C++. Maybe there is a more fundamental problem somewhere?
(sid)3300:[EMAIL PROTECTED]: ~/delta/bin] /usr/lib/gcc-snapshot/bin/g++ -c -O
mi
--- Comment #1 from tbm at cyrius dot com 2006-05-31 07:13 ---
Created an attachment (id=11543)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11543&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27830
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-31 07:19 ---
This really unrelated to that fortran bug. Anyways I might take a look soon.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from joerg dot richter at pdv-fs dot de 2006-05-31 07:21
---
I can't see the problem with 4.1.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21264
--- Comment #3 from yuvalk at mainsoft dot com 2006-05-31 07:40 ---
This code passes with GCC 3.4. Apparently it _was_ fixed somehow. I am
interested in patching GCC 3.2 with the fix, if anyone can say how it was
achieved eventually.
--
yuvalk at mainsoft dot com changed:
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-31 07:44 ---
(In reply to comment #3)
> This code passes with GCC 3.4. Apparently it _was_ fixed somehow. I am
> interested in patching GCC 3.2 with the fix, if anyone can say how it was
> achieved eventually.
The last release
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-31 07:53 ---
Confirmed, reduced testcase:
struct gc{};
struct transform:public gc
{
double x, y, z, t;
transform (void){}
};
inline transform f (void)
{
return transform ();
};
void transformed (void)
{
new transf
The generated gcc.1 man page contais a couple of weird texinfo artefacts,
I suppose the problem is in texi2pod.pl in most cases, but am not 100% sure.
1) @anchor{something} doesn't seem to be handled and makes it all the way
through into the man page (should it be just nuked for the man page?)
--- Comment #16 from reichelt at gcc dot gnu dot org 2006-05-31 09:36
---
Fixed.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- 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
--- 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 #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 #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 #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
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 #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
--- 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 #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 #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
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 #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
--- 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 #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 #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 #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
--
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 #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
--- 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 #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 #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
-
(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 #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
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 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
--- 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 #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 #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
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/
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:
--- 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
--- 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 #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
---
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 #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
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 #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:
--- 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: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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
--
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 #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
--- 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 #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 #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 #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 #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 #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 #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
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 #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,
--- 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 #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 #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 #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 #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 #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 #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?
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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/
1 - 100 of 109 matches
Mail list logo
