Found at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e9add97708681397
Please re-check the thread, I have likely missed something.
BESSEL_J0, BESSEL_J1, BESSEL_Y0, and BESSEL_Y1 are elemental, but the manual
says otherwise.http://gcc.gnu.org/onlinedocs/gfortran/Intrinsi
--- Comment #1 from hjl dot tools at gmail dot com 2008-05-01 06:04 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00011.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
bash-3.2$ cat x.c
unsigned long long
foo (unsigned long long x, unsigned long long y)
{
return __builtin_ia32_crc32di (x, y);
}
bash-3.2$ /usr/gcc-4.3/bin/gcc -m32 -msse4 -c x.c
x.c: In function foo:
x.c:5: error: unrecognizable insn:
(insn 6 5 7 3 x.c:4 (set (reg:DI 58 [ D.1635 ])
(un
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-05-01 04:40
---
The unit has not been opened yet when this error occurs so it does not exist in
the unit list yet. In this case we should just show the unit number.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36094
--- Comment #11 from Joey dot ye at intel dot com 2008-05-01 04:31 ---
Tim,
Since it doesn't link, I can only check the .s file. There are a couple of
constructor called Environment, which one is the problemetic function?
grep Environment kernel_build.s|grep glob
...
.globl _ZN4nova11E
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
show_locus is failing to show the error locus because for some reason
filename_from_unit is returning a NULL string for this test case.
character(len=10) :: cc = 'bad'
open(99,file="dd",encoding=cc)
write(*,*) 'HELLO'
end
--
Summary: Runtime error show_locus not working correctly
Hi,
The following code produces incorrect results under -O1 (or higher), but works
fine under -O0 for gcc 4.1.2 and 4.2.3. gcc 3.4.6 produces the correct result
for all optimization levels.
# 1 "t.c"
# 1 ""
# 1 ""
# 1 "t.c"
extern int printf(const char *format, ...);
typedef struct Bar {
c
--- Comment #5 from dje at gcc dot gnu dot org 2008-05-01 02:40 ---
Maybe something like the following patch (untested)?
Index: rs6000.c
===
*** rs6000.c(revision 132964)
--- rs6000.c(working copy)
*** c
--- Comment #4 from dje at gcc dot gnu dot org 2008-05-01 02:32 ---
Is
ld 11,[EMAIL PROTECTED](2)
even valid assembly? Is that a valid relocation?
I suspect that constant_pool_expr_1() needs to be changed so that it does not
allow anything to be added to the toc_label_name.
Occurs while compiling glibc-2.7-20080428 with gcc-4.4-20080411 while building
the shared object for malloc.c. gcc-4.2.3 works with the identical setup.
$ gcc-4.4-20080411 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.4-20080411/configure --prefix=/system/devel
--pr
--- Comment #19 from gnu_andrew at member dot fsf dot org 2008-05-01 00:45
---
Created an attachment (id=15556)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15556&action=view)
Use StringBuilder in the examples
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
--- Comment #18 from gnu_andrew at member dot fsf dot org 2008-05-01 00:44
---
Created an attachment (id=1)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=1&action=view)
Move towards a CPStringBuilder-using code base
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
--- Comment #17 from gnu_andrew at member dot fsf dot org 2008-05-01 00:44
---
Created an attachment (id=15554)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15554&action=view)
Move towards a CPStringBuilder-using code base
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
--- Comment #16 from kargl at gcc dot gnu dot org 2008-04-30 22:37 ---
(In reply to comment #15)
> Un-assigning myself. I can see valgrind errors but have been unable to isolate
> the problem.
>
I may have a further piece to the puzzle. It appears that len(HEX1) is not
being properly
--- Comment #46 from pthaugen at gcc dot gnu dot org 2008-04-30 22:35
---
Just following up with comments posted on irc. The patch does fix the problem
I was seeing. Spec ratio improved from 5.18 to 9.07 with the patch (75%), not
quite the full 100% improvement I was seeing with --par
--- Comment #45 from rguenth at gcc dot gnu dot org 2008-04-30 21:43
---
Subject: Bug 32921
Author: rguenth
Date: Wed Apr 30 21:42:24 2008
New Revision: 134838
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134838
Log:
2008-04-30 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-04-30 21:39 ---
Reopening as this looks related to secureplt.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-30 21:24 ---
The problem is that NONLOCAL has to alias all global symbols but does not:
# x_2 = V_MUST_DEF ;
x = 4;
...
# NONLOCAL.53_13 = V_MAY_DEF ;
*D.2057_3 = D.2060_6;
That is, during flow insensitive alias com
--- Comment #3 from dje at gcc dot gnu dot org 2008-04-30 21:17 ---
Rhyolite: in PR36090, looks like print_operand_address completely
ignores the other operand of MINUS, probably assumes it has to be .LCTOC1
--
dje at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from rsandifo at gcc dot gnu dot org 2008-04-30 21:14
---
Thanks for the report. I'll try to take a look soon.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rsandifo at gcc dot gnu dot org 2008-04-30 21:12
---
Sorry, I don't understand what you think the bug is. You say:
> For some reason the compiler allocates
> memory on the stack by issuing a Addui sp,sp with some negative number,
> however
> the negative number is
--- Comment #9 from hjl dot tools at gmail dot com 2008-04-30 20:55 ---
It turns out that __m64 is aligned to 4 byte in the outgoing
parameter block and 8 byte elsewhere. We want _Decimal64 to be
consistent with __m64, not double/long long.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-04-30 20:47 ---
(In reply to comment #3)
> FAIL: gfortran.dg/array_memset_2.f90 -O0 scan-tree-dump-times original
> "memset" 2
This is due to a false positive because "memset" in the error message
(due to the filename) matches
--- Comment #2 from jakub at gcc dot gnu dot org 2008-04-30 20:38 ---
constant_pool_expr_p and therefore legitimate_constant_pool_address_p and
rs6000_legitimate_address too say this is ok, so fwprop2 isn't doing anything
wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-04-30 20:38 ---
Might as well fix this while I'm digging through
the m4 files.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #44 from rguenth at gcc dot gnu dot org 2008-04-30 20:29
---
We are putting the HEAP tag for D.914_385 and wav in the same partition:
:
# MPT.501_1171 = PHI
# i_25 = PHI <1(197), i_646(199)>
D.1264_629 = i_25 + -1;
# VUSE
D.1265_630 = wav.data;
D.1266_631 = (r
--- Comment #1 from jakub at gcc dot gnu dot org 2008-04-30 20:25 ---
This wierdo addressing was created by fwprop2, which replaced:
In insn 40, replacing
(mem/u/c/i:DI (plus:DI (reg/f:DI 129)
(const_int 8 [0x8])) [2 S8 A64])
with (mem/u/c/i:DI (plus:DI (reg:DI 2 2)
--- Comment #8 from adam at os dot inf dot tu-dresden dot de 2008-04-30
20:22 ---
(In reply to comment #7)
> This is not a regression, however it is a bug, it has to be fixed. Inline
> assembly coupled with templates is very powerful, however because of this bug
> it is unusable :-(
I
--- Comment #5 from sandra at codesourcery dot com 2008-04-30 20:17 ---
Here's another testcase for the same bug, or one closely related to it:
#include
unsigned x = 8;
unsigned *addr()
{
return &x;
}
int main()
{
x = 4;
*addr() = *addr() / 2;
printf ("*addr() = %d, x = %d\n",
Reduced test case from forall_13.f90:
$ cat f1.f90
integer :: p(4)
p = (/3,1,4,2/)
forall (i = 1:4) p(5 - p(i)) = p(5 - i)
if (any (p .ne. (/1,2,3,4/))) call abort ()
end
$ gfortran -fbounds-check f1.f90
$ ./a.out
At line 5 of file f1.f90
Fortran runtime error: Array reference out of b
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.3.1
http://gcc.g
extern void abort (void);
long double __attribute__ ((noinline)) foo (long double x)
{
return __builtin_signbit (x) ? 3.1415926535897932384626433832795029L : 0.0;
}
int
main (void)
{
if (foo (-1.0L) != 3.1415926535897932384626433832795029L)
abort ();
return 0;
}
is miscompiled with -O2
--- Comment #3 from pault at gcc dot gnu dot org 2008-04-30 20:14 ---
Subject: Bug 35997
Author: pault
Date: Wed Apr 30 20:13:21 2008
New Revision: 134836
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134836
Log:
2008-04-30 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/3
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-04-30 20:02 ---
Failures at the moment:
FAIL: gfortran.dg/array_memset_2.f90 -O0 scan-tree-dump-times original
"memset" 2
FAIL: gfortran.dg/array_memset_2.f90 -O1 scan-tree-dump-times original
"memset" 2
FAIL: gfortran.dg/array
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-04-30 20:00
---
(In reply to comment #11)
> Still f4 looks weird (wrong-code?!) as we fold *p = ~*p to *p = (int) *p !=
> -1;
> I'll open a PR for this.
We decided this was the correct thing as we start out with ~((int)*p) != 0
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-04-30 19:26
---
On the trunk we have:
f1 (const _Bool * p)
{
:
return (_Bool) ((int) *p & 1);
f2 (const _Bool * p)
{
:
return *p;
f3 (_Bool * p)
{
:
*p = (_Bool) !*p;
f4 (_Bool * p)
{
:
*p = 1;
where i686 assembly loo
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-30 19:21 ---
On the trunk I have after phiopt1:
;; Function andrew (andrew)
Removing basic block 3
Merging blocks 2 and 4
andrew (struct s * p)
{
_Bool D.1212;
int i;
unsigned int D.1183;
D.1182;
:
D.1182_3 = p_2(D)
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-04-30 19:08
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-04-30 19:06
---
Subject: Bug 21636
Author: rguenth
Date: Wed Apr 30 19:05:12 2008
New Revision: 134834
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134834
Log:
2008-04-30 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #43 from pthaugen at gcc dot gnu dot org 2008-04-30 18:49
---
Created an attachment (id=15553)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15553&action=view)
Testcase
I tried a mainline with the latest patch. While we no longer have problems
with the prior testcase
--- Comment #1 from tromey at gcc dot gnu dot org 2008-04-30 18:48 ---
Confirmed.
I think this is related to PR 36088.
I think the operator precedence code is subtly wrong with ?:
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-04-30 18:19 ---
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #13 from tkoenig at gcc dot gnu dot org 2008-04-30 18:05
---
Fixed on trunk; will backport to 4.3.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from tromey at gcc dot gnu dot org 2008-04-30 17:51 ---
Confirmed.
The bug is that we look at top[-1].value after overwriting it with the
value of the 'true' branch of the condition.
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from tkoenig at gcc dot gnu dot org 2008-04-30 16:56
---
Subject: Bug 35993
Author: tkoenig
Date: Wed Apr 30 16:56:01 2008
New Revision: 134830
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134830
Log:
2008-04-30 Thomas Koenig <[EMAIL PROTECTED]>
PR
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-30 16:54 ---
Also if you change as to be initialized with an equals instead of the C++ style
initialization, it works.
That is change:
const int as(2);
To:
const int as = 2;
Thanks,
Andrew Pinski
--
http://g
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.2/4.3/4.4 Regression]|[4.1/4.2/4.3/4.4 Regression]
|Funny rejects valid w
Testcase:
template
struct a
{
static bool f()
{
const int as(2);
float anArray[as] = { 0.0f, 0.0f };
return (anArray[0] == anArray[1]);
}
};
If we remove the const from the declaration of as, we get an error with
-pedantic-errors that we have a VLA (other
Compile with pedantic-errors, C99 or C90.
extern int x;
#if 1 ? 0: 1 ? 1/0: 1/0
#endif
Code is fine as the divisions by zero are unevaluated.
--
Summary: Unevaluated PP expression rejected
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Se
--- Comment #7 from vincent dot riviere at freesbee dot fr 2008-04-30
15:32 ---
This is not a regression, however it is a bug, it has to be fixed. Inline
assembly coupled with templates is very powerful, however because of this bug
it is unusable :-(
If I remember well, a workaround is
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-30 15:28 ---
Works for me on x86_64. Please try the current 4.2 release 4.2.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36086
Hi all, this is more of a complaint/feature request
for code such as:
int main()
{
int nToProcess=0;
for (int i=0; iTo me it seems the compiler should not warn about code that follows the
ISO standard rules... It would be nice if the compiler warned about the
case that didn't follow the stand
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-30 15:12 ---
A third variant is optimized by the ifcombine pass:
int test__(int a, int b)
{
if (a < b)
return 1;
if (a == b)
return 1;
return 0;
}
in principle ifcombine could handle flow-less combining as well.
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-30 15:12 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-30 15:07 ---
Subject: Bug 14847
Author: rguenth
Date: Wed Apr 30 15:06:16 2008
New Revision: 134825
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134825
Log:
2008-04-30 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-30 15:06 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-30 15:05 ---
Subject: Bug 35986
Author: jakub
Date: Wed Apr 30 15:04:56 2008
New Revision: 134824
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134824
Log:
PR c++/35986
* pt.c (more_specialized_fn): Stop t
--- Comment #2 from jakub at gcc dot gnu dot org 2008-04-30 14:25 ---
Subject: Bug 35986
Author: jakub
Date: Wed Apr 30 14:24:18 2008
New Revision: 134823
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134823
Log:
PR c++/35986
* pt.c (more_specialized_fn): Stop t
--- Comment #1 from dominiq at lps dot ens dot fr 2008-04-30 14:09 ---
After reading again my post, I realized that rev. 134697 deals with i386 only
and should not affect powerpc and I don't see how 134714 can be the cause. All
the other revisions deal with branches or gfortran.
--
Comparing http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg02061.html and
http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg02120.html shows the following
new failures on powerpc-apple-darwin*:
FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times optimized "nasty_local" 0
FAIL: gcc.dg/pr35729.c scan-rtl-du
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-04-30 13:57 ---
4.3.0: 334s 1.6GB
trunk: 62.20s 640MB
trunk with SFTs: 327s 1.2GB
so, fixed for 4.4.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from m dot galante at centrosistemi dot it 2008-04-30 13:41
---
Created an attachment (id=15552)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15552&action=view)
precompiled source that triggers the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36086
My system is IBM AIX 5.3, 64 bit kernel mode. I have installed the GCC
distribution downloaded from:
http://www-03.ibm.com/systems/p/os/aix/linux/toolbox/download.html
The installed packages are:
gcc-4.2.0-3.aix5.3.ppc.rpm
gcc-cplusplus-4.2.0-3.aix5.3.ppc.rpm
libgcc-4.2.0-3.aix5.3.ppc.rpm
libstd
--- Comment #6 from adam at os dot inf dot tu-dresden dot de 2008-04-30
13:34 ---
Even if this is not a regression it would be very helpful if g++ would emit a
warning that the register allocation will be ignored. Those bugs are subtle.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #10 from ubizjak at gmail dot com 2008-04-30 12:31 ---
(In reply to comment #7)
> > -m32?
>
> Better, but a bunch of 45 errors like below remained.
>
> % g++ -g -O3 -march=core2 -mfpmath=sse -msse -ftemplate-depth-4096
> -Wnon-virtual-dtor -fPIC kernel_build.ii > log 2>&1
--- Comment #9 from snes2002 at freenet dot de 2008-04-30 12:26 ---
Subject: Re: gcc optimizations and threads (pthread)
Hello,
I read about mutexes, cond_wait and cond_signal.
When I use these things instead of "busy loop" there is no performance gain at
all for my problem (=generati
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-30 11:50 ---
Can you reduce the testcase so I can try to analyze this with a cross?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
--- Comment #9 from Joey dot ye at intel dot com 2008-04-30 10:56 ---
(In reply to comment #8)
> -m32 doesn't work. You have to use 4.3.0 release branch. Recent mainline
> change
Correction: -m32 is a must, but doesn't fix all. Options I'm using:
g++ -g -O3 -march=core2 -mfpmath=sse -m
--- Comment #8 from Joey dot ye at intel dot com 2008-04-30 10:53 ---
(In reply to comment #6)
> (In reply to comment #4)
> > > have you tried to compile with -march=core2 -mfpmath=sse -msse?
> > Yes, I've compiled it as following:
> > % g++ -g -O3 -march=core2 -mfpmath=sse -msse -ftempl
--- Comment #7 from victork at gcc dot gnu dot org 2008-04-30 10:51 ---
> -m32?
Better, but a bunch of 45 errors like below remained.
% g++ -g -O3 -march=core2 -mfpmath=sse -msse -ftemplate-depth-4096
-Wnon-virtual-dtor -fPIC kernel_build.ii > log 2>&1
/usr/lib/gcc/i486-linux-gnu/4.3
--- Comment #6 from ubizjak at gmail dot com 2008-04-30 10:37 ---
(In reply to comment #4)
> > have you tried to compile with -march=core2 -mfpmath=sse -msse?
> Yes, I've compiled it as following:
> % g++ -g -O3 -march=core2 -mfpmath=sse -msse -ftemplate-depth-4096
> -Wnon-virtual-dtor -
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-30 10:24 ---
g++-4.1 -S t.C
t.C:9: error: scope 'a' before '~' is not a class-name
works for me since 4.1.2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-30 10:22 ---
tree forward propagation should fix this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from nathan at gcc dot gnu dot org 2008-04-30 10:11 ---
2008-04-30 Nathan Sidwell <[EMAIL PROTECTED]>
* gcc.dg/tls/section-2.c: Restrict to vxworks.
--
nathan at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from tim at klingt dot org 2008-04-30 09:58 ---
odd, it compiled fine for me:
[EMAIL PROTECTED]:~/workspace/nova$ g++-4.3 -g -O3 -march=core2 -mfpmath=sse
-msse
-ftemplate-depth-4096 -Wnon-virtual-dtor -fPIC kernel_build.ii -c
[EMAIL PROTECTED]:~/workspace/nova$
[EMAI
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-30 09:45 ---
Note not doing the folding does cause more stack usage than expected also.
Here is an example which shows that:
int f(int c)
{
int i[1024] = { 0, 1, 2, 3, 4, 2, 1001, 10, 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1};
typedef i
--- Comment #4 from victork at gcc dot gnu dot org 2008-04-30 09:44 ---
> have you tried to compile with -march=core2 -mfpmath=sse -msse?
Yes, I've compiled it as following:
% g++ -g -O3 -march=core2 -mfpmath=sse -msse -ftemplate-depth-4096
-Wnon-virtual-dtor -fPIC kernel_build.ii
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36084
Testcase:
int f(int c)
{
int i[] = { 0, 1, 2, 3, 4};
typedef int a[];
a *b = (a*)&i[0];
return (*b)[0];
}
--- CUT ---
We don't fold this into just return 0 with at least the C++ front-end. I found
this while improving PR 26069 and it happens many times with the Fortran
front-end more than
--- Comment #27 from pinskia at gcc dot gnu dot org 2008-04-30 09:25
---
Note I need to add tests, checking to make sure that TREE_SIZE is non zero in
the case where we have an array type who's size is unknown.
That is:
&& TYPE_SIZE (TREE_TYPE (rhs))
&& TYPE_SIZE (TREE_TYPE
--- Comment #3 from tim at klingt dot org 2008-04-30 08:40 ---
have you tried to compile with -march=core2 -mfpmath=sse -msse? i guess, that
is required to compile the preprocessed source file correctly ...
i will try gcc-4.4, when i find the time to compile it ...
--
http://gcc.gn
The compiler exits with segmentation fault for this source file. There are
errors in the syntax but this still should not result in a segfault.
Begin code -
namespace a
{
struct exception_base
{
virtual ~exception_base() throw();
};
}
a::~exception_base() th
83 matches
Mail list logo
