Without a code block around my "default" clause of my switch statement the
compiler can't parse the following instructions.
I'm including the text of a file which, when compiled, will run without a bug
(you will need to delete some of the local dependencies and references to
global variables). If
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-18 06:38 ---
Confirm based on http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01186.html
If PR 26731 gets fixed, this testcase needs to be changed (or removed) as it
will cause the testcase to always fail.
--
pinskia at gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 06:36 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-18 06:34 ---
(In reply to comment #4)
> I can reproduce it with 3.3.4 (Debian 1:3.3.4-9) on alpha-linux. Seems to be
> some kind of memory corruption, trying to reduce the test case fails.
Any news on that reduction?
--
pins
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-18 06:33 ---
PR 26161 might had fixed this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Bug
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-03-18 06:31
---
I know for sure the binaries do not work on Win98. This was reported before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25178
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 06:30 ---
Was this fixed?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 06:25 ---
Since this does not show up in 4.0.0 closing as won't fix as 3.4.6 was the last
release.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-18 06:22 ---
As I mentioned 4.0.0 works for me so closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-18 06:20 ---
crosstools and the crossgcc list is the best place to ask questions like this
really.
Second sysroot can be changed at runtime now. So this is not a bug and closing
as such.
--
pinskia at gcc dot gnu dot org ch
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 06:07 ---
We do not support the binaries. Please use the fortran mailing list for these
binaries. [EMAIL PROTECTED] is the place you should be reporting problems.
Note these binaries work for a lot of people.
--
pinskia
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-18 06:05 ---
Since this worked for me and this is only report of this failure, something
must be up with the source you used. Closing as works for me.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
In testing gfortran's capacity to deal with iso_varying_string, it was found
that the error "Specification function 'len_' at (1) must be PURE" was produced
- see testcase below. This is obviously incorrect because elemental functions
are pure.
The patch and the testcase appear below.
Paul Thoma
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 03:11 ---
Confirmed.
friend void f(T) {} // { dg-error "" } redeclaration
Grrr oh well.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-18 03:09 ---
So who ever fixes this bug, please also fix the testsuite so the testsuite will
show the ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26740
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 03:08 ---
Grrr. Well confirmed. The reason why this does show up in the testresults is
because of the follow:
fmp = &ptr->function_member; // { dg-error "" }
pmf = & pf->f; // { dg-error "" } not a valid pmf expre
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
The following testcases cause ICEs on mainline:
g++.old-deja/g++.bugs/900213_03.C
g++.old-deja/g++.other/pmf2.C
g++.old-deja/g++.other/pmf7.C
They all crash at the same position:
pmf2.C: In function 'void f()':
pmf2.C:17: error: ISO C++ forbids taking the address of a bound member function
to fo
The testcase g++.old-deja/g++.pt/friend36.C ICEs on mainline:
friend36.C: In instantiation of 'S':
friend36.C:12: instantiated from here
friend36.C:9: error: redefinition of 'template void f(T)'
friend36.C:4: error: 'template void f(T)' previously declared here
friend36.C:9: internal compiler er
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2006-03-18 01:59
---
Subject: Bug 26509
Author: jvdelisle
Date: Sat Mar 18 01:59:50 2006
New Revision: 112199
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112199
Log:
2006-03-17 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2006-03-18 01:56
---
Subject: Bug 26509
Author: jvdelisle
Date: Sat Mar 18 01:56:07 2006
New Revision: 112198
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112198
Log:
2006-03-17 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-17 23:57 ---
Confirmed, with a cross compiler.
here is the backtrace:
#1 0x0083e49c in add_forw_dep (to=0x1d1a230, link=0x1db9100) at
../../gcc/sched-deps.c:1644
#2 0x0083e8f4 in compute_forward_dependences (head=0x1d1a640, tai
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-17 23:39 ---
t.c: In function '__negti2':
t.c:4: internal compiler error: in add_forw_dep, at sched-deps.c:1644
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instr
--- Comment #19 from gdr at integrable-solutions dot net 2006-03-17 23:37
---
Subject: Re: g++ miscompiles gcjx
"bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| is this still an active issue, or was it indicative of some temporary or
| transient thing in the gcc sources?
"bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| is this still an active issue, or was it indicative of some temporary or
| transient thing in the gcc sources?
Now, I get a "segmentation fault" -- instead of dead lock.
gcjx is compiled with mainline GCC/g++.
I was trying to compile cla
--- Comment #6 from sje at cup dot hp dot com 2006-03-17 22:34 ---
I applied the patch that Maxim created for PR 26725 but it did not seem to help
this problem. I verified the problem happened on ia64-hp-hpux11.23 in LP64
mode as well as ILP32 mode so that makes it more surprising that
--- Comment #5 from sje at cup dot hp dot com 2006-03-17 21:47 ---
The debugger shows:
(gdb) p debug_rtx(*unused_listp)
(deps_list 34 (nil) 0 [0x0])
(gdb) p debug_rtx(prev_link)
(UnKnown Unknown)
When I print unused_insn_list I get a long RTL that I couldn't capture.
Here is a backt
--- Comment #4 from sje at cup dot hp dot com 2006-03-17 21:25 ---
I already fixed the problem in comment 3 with an 'obvious' checkin to
config/ia64/ia64.opts.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-17 21:20 ---
hmm, I get:
options.c:3863: error: `MASK_ILP32' undeclared here (not in a function)
or was there a fix for this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-17 21:19 ---
Subject: Re: [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX
On Mar 17, 2006, at 4:16 PM, mkuvyrkov at gcc dot gnu dot org wrote:
>
> Unfortunately, I don't have access to HP-UX and the bug doesn't appear
> o
On Mar 17, 2006, at 4:16 PM, mkuvyrkov at gcc dot gnu dot org wrote:
Unfortunately, I don't have access to HP-UX and the bug doesn't appear
on
ia64-linux, so can you please provide some more information for the
failure
like backtrace.
A cross compile will most likely reproduce it.
-- Pins
--- Comment #1 from mkuvyrkov at gcc dot gnu dot org 2006-03-17 21:16
---
(In reply to comment #0)
> The compiler builds but when it tries to build libgcc I get a bunch of ICEs.
> Here is a small test case that will not compile with -O2 on ia64-hp-hpux11.23
> with the ToT compiler:
>
>
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-03-17 21:12 ---
Following the discussion on comp.lang.fortran on this subject,
I'm tempted to mark this WONTFIX. This feature can cause
a lot of headaches to implement and is of questionable
semantics.
Any objections?
--
http
$ cat conv-implied-open.f90
program main
implicit none
integer (kind=8) :: i1, i2, i3
write (10) 1_8
close (10)
open (10,status="old", form="unformatted", access="direct", recl=8)
read (10,rec=1) i1
read (10,rec=2) i2
read (10,rec=3) i3
print '(3Z16,1X)',i1,i2,i3
end program main
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
The compiler builds but when it tries to build libgcc I get a bunch of ICEs.
Here is a small test case that will not compile with -O2 on ia64-hp-hpux11.23
with the ToT compiler:
extern int c;
long long __negti2 () { return (-c); }
I believe the problem is due to the IA64 speculation changes that
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-17 20:02 ---
Confirmed. Though SCEV should be taught to handle this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from joseph at codesourcery dot com 2006-03-17 19:48 ---
Subject: Re: Accepts invalid code at different optimization
levels.
Bug 16876 is a related case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26732
--- Comment #3 from pcarlini at suse dot de 2006-03-17 19:48 ---
(In reply to comment #1)
> On libstdcxx_so_7-branch, there is preliminary support for move semantics.
>
> These patches have some issues:
>
> 1) _GLIBCXX_STD_MOVE not listed in any ChangeLog entry...
> 2) new fails in deb
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-03-17 19:16 ---
Created an attachment (id=11065)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11065&action=view)
patch to test debug mode
This runs the testsuite with -D_GLIBCXX_DEBUG.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #1 from bkoz at gcc dot gnu dot org 2006-03-17 19:15 ---
On libstdcxx_so_7-branch, there is preliminary support for move semantics.
These patches have some issues:
1) _GLIBCXX_STD_MOVE not listed in any ChangeLog entry...
2) new fails in debug mode.
First pointed out here
--
Summary: move semantics vs. debug mode
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz a
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-03-17 19:10 ---
I'm closing this. I cannot reproduce it. In addition, the submitted testcase is
not sufficient: it has a complicated directory structure, makefiles, etc etc.
Also, does not demonstrate the so-called bug...
Please read
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-03-17 19:04 ---
Created an attachment (id=11064)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11064&action=view)
example of how to do testcase
Explicitly use __mt_alloc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2540
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-17 18:47 ---
This is all:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00772.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26732
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-17 18:45 ---
Related to PR 22249.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26732
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-17 18:43 ---
This is invalid code, well undefined at best.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26732
#include
int
bar(baz)
struct { int foo; } baz;
{
return baz.foo;
}
int main (void)
{
struct { int foo; } baz;
baz.foo = 0xdeadbeef;
if (bar(baz) != 0xdeadbeef)
abort();
}
Compiling at O2 results in no error.
compiling at O3 results in the following erro
--- Comment #18 from bkoz at gcc dot gnu dot org 2006-03-17 18:33 ---
is this still an active issue, or was it indicative of some temporary or
transient thing in the gcc sources?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25608
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-03-17 18:31 ---
linking tests are native only, because finding all the support objects needed
for all the various platforms (crt.o, etc.) is hard. At least, this is the
traditional objection.
fixing glibcxx_gnu_ld_version still seems
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-03-17 18:29 ---
Solution is to make
make_exports.pl.in
with NM_FOR_TARGET substition for current uses of 'nm'
This is done with other scripts.
This is low-priority, but this is enough of a hint so that you should be able
to try
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-17 18:06 ---
One potential fix is to call try_builtin_assignconv
in nested_field_access_fix or the like.
I haven't tried this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26720
--- Comment #3 from pault at gcc dot gnu dot org 2006-03-17 18:02 ---
I have a patch that fixes this and regtests OK; I will get it ready for
submission tomorrow.
Index: gcc/fortran/interface.c
===
*** gcc/fortran/interface
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-17 18:01 ---
The bug here is that the code that handles assignments
requiring an accessor method does not understand that
a constant might be subject to a narrowing constant conversion.
Hence it does not (e.g.) convert '0' to '(by
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-17 17:52 ---
It also fails on AIX.
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01132.html
This worked in rev 112118 but failed in 112135.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-03-17 17:39
---
This should be fixed now.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from rguenth at gcc dot gnu dot org 2006-03-17 17:38
---
Subject: Bug 26721
Author: rguenth
Date: Fri Mar 17 17:38:51 2006
New Revision: 112177
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112177
Log:
2006-03-17 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-17 17:32 ---
I almost think this is also the cause for PR 26727.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
Jump threading causes bad interactions with loops:
int f(int t, int a, int x)
{
int n, g;
if (t)
n = a;
else
n = 4;
for (g=0; ghttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=26731
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-17 17:07 ---
Who knows, 3.4.x is dead, I would not doubt it was the merge of the tree-ssa
branch into the mainline which fixed this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from apl at alum dot mit dot edu 2006-03-17 17:04 ---
Any clue as to the specific patch? We build with -Wall -Wextra -Werror, and
won't be able to upgrade to gcc-4.x for at least another couple of months.
--
apl at alum dot mit dot edu changed:
What|Re
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-17 17:00 ---
Fixed in 4.0.0, 3.4.6 was the last release of 3.4.x.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #64 from pinskia at gcc dot gnu dot org 2006-03-17 16:59
---
*** Bug 26730 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-03-17 16:59 ---
pos=&pos->sub[pos->no++];
This is undefined. You assign pos and use it without a sequence point.
*** This bug has been marked as a duplicate of 11751 ***
--
pinskia at gcc dot gnu dot org changed:
I have worked around the problem. The HashTable methods now have __GCC__ code
that detects when the object has not had its constructor called, and
Performs the same initialization on-demand.
>From the lack of responses indicating otherwise, I suppose I will assume this
>is a bug in G++. Shoul
This is not the same as bug 11751 as the variable used with ++ is not reused.
Here the simple code:
sadd.i:
# 1 "sadd.c"
# 1 ""
# 1 ""
# 1 "sadd.c"
typedef struct A A;
struct A {
int no;
A *sub;
};
void main()
{ A sub={0, ((void*)0)};
A root={0, &sub};
A *pos=&ro
--- Comment #1 from apl at alum dot mit dot edu 2006-03-17 16:48 ---
Created an attachment (id=11063)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11063&action=view)
g++ -Wall -Werror -Wextra -O2 ...
(almost) trivial test case...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
trivial function using POD constructors says "comparison is always 0".
If I remove any of the UInt16 constructors, the warning goes away.
This doesn't seem to happen in gcc-4.1.0
typedef unsigned short UInt16;
UInt16 pipe;
UInt16 cmp ()
{
UInt16 answer;
answer =
UInt16((pipe & UInt
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-17 16:11 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01110.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-17 15:41 ---
This is not valid code at all.
The fortran code assumes it is passing to a non varargs function which is
correct.
You should develop a different solution to this issue.
--
pinskia at gcc dot gnu dot org changed:
Since gcc release 4 it is not possible anymore to call from Fortran a C routine
defined for a variable no. of arguments using the ellips notation.
It used to work on all previous gcc 3 releases,
and it still works on 32-bit machines, like e.g. Intel Pentium with
SUSE Linux 10.0 (gcc 4.0.2)
$
On Mar 17, 2006, at 10:33 AM, Michael Tomuschat wrote:
vector >::iterator aIter; // tut nicht
You forgot the typename keyword.
It should be:
typename vector >::iterator aIter;
-- Pinski
--
rmathew at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
Hello,
I've got a problem compiling the following source
[EMAIL PROTECTED]:~/tmp/xxx> g++ -Wall -O2 b.cpp
b.cpp: In member function ‘void bCls::DumpItems()’:
b.cpp:15: error: expected `;' before ‘aIter’
When I compile this code with borland's bcc it compiles without complaining.
So I think it m
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-17 15:20 ---
Confirmed, the problem is:
/* If this expression has side effects, show we don't know it to be a
constant. Likewise if it's a pointer or aggregate type since in
those case we only want literals, since th
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26727
I was looking through my testsuite results and noticed this fails.
We deinitely don't get a do loop at all:
L7:
addic. r0,r0,-1
add r4,r4,r2
addi r2,r2,1
bne- cr0,L7
L5:
..
blr
L6:
add r5,r5,r2
addi r2,r2,1
bdz L5
add r5,r5,
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet||ia64-unknown-linux-gnu
Keywords|
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-03-17 14:32 ---
Forgot to mention - the ia64 build I was seeing this with was built with -g
-fno-inline and checking enabled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21898
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-17 14:29 ---
I see the same on ia64 for trunk.
Program received signal SIGSEGV, Segmentation fault.
0x402ed101 in gimplify_cond_expr (expr_p=0x2070aca8,
pre_p=0x607ffe8dc798, fallback=fb_none) at gimpli
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-03-17 13:31 ---
Subject: Re: -fivopts producing out of bounds
array refs
On Fri, 2006-03-17 at 12:40 +, mueller at gcc dot gnu dot org wrote:
>
> --- Comment #2 from mueller at gcc dot gnu dot org 2006-03-17 12:4
On Fri, 2006-03-17 at 12:40 +, mueller at gcc dot gnu dot org wrote:
>
> --- Comment #2 from mueller at gcc dot gnu dot org 2006-03-17 12:40
> ---
> one possible workaround would be to lower the ARRAY_REF's to indirect mem
> refs,
> which I don't track
>
>
Uh, no.
We are in fact,
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-17 13:17 ---
Simpler testcase:
struct Foo {
Foo() : s(1) {}
int s;
};
void foo(Foo&);
void bar(void)
{
Foo x[4];
foo(x[0]);
}
:
ivtmp.34 = &x[1];
:;
D.1822 = (int *) &x[0];
D.1825 = -&x;
MEM[base: D.1822 + (int
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-17 13:00 ---
Now I noticed IVOPTs generates a TMR with base == &iconlist[1] + ivtmp,
offset -&iconlist[0] and offset -4B (ivtmp being &iconlist[0] initially).
Which boils down to using simply *ivtmp instead of a TMR. Funny.
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-17 12:55 ---
For your warning patch another option is to simply only warn in either the
first or the second VRP pass, not in the third which is the only one run after
loop optimizations. Also you could ignore ADDR_EXPR (ARRAY_RE
--- Comment #2 from mueller at gcc dot gnu dot org 2006-03-17 12:40 ---
one possible workaround would be to lower the ARRAY_REF's to indirect mem refs,
which I don't track
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-17 11:39 ---
Reduced testcase:
struct QValueList {
QValueList() { sh = new int; }
void foo();
int* sh;
};
void queryIconsByContext()
{
QValueList iconlist[8];
iconlist[7].foo();
}
ivopts generates
:
ivtm
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-03-17 11:33
---
> Currently the only C compiler on the box is GCC 3.4.2 which was downloaded
> from Sunfreeware.com Is this the bootstrap compiler?
The bootstrap compiler is the compiler that compiles GCC during stage #1 of the
--- Comment #6 from ccb at dl dot ac dot uk 2006-03-17 11:30 ---
Created an attachment (id=11062)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11062&action=view)
fpu-387.h based fpe control for mactel
The changes are to the SSE elements. It sets a mask as for the local floating
--- Comment #2 from chris dot pitchford at newsint dot co dot uk
2006-03-17 11:18 ---
Currently the only C compiler on the box is GCC 3.4.2 which was downloaded from
Sunfreeware.com Is this the bootstrap compiler? To be honest this project is
the first time I've tried to compile GCC, I'
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-03-17 11:03
---
For the testcase in comment #6 we fall into the
#ifdef CONSTANT_ALIGNMENT
else if (CONSTANT_CLASS_P (exp))
align = CONSTANT_ALIGNMENT (exp, align);
#endif
path and conclude the alignment is
=== Cut ===
struct
QValueList
{
QValueList()
{
sh = new int;
}
QValueList& operator+= ( QValueList&);
int* sh;
};
void
queryIconsByContext()
{
QValueList iconlist[8];
QValueList iconlistResult;
for (int i=0; i<8; i++)
iconlistResult+=iconlist[i];
GCC 4.2 revision 112135 failed to compile SPEC cpu2000/197.parser.
Here is the minimal reproducer:
struct Exp_struct {
char type;
unsigned char cost;
};
extern void foo();
void print_expression(struct Exp_struct * n)
{
int i;
if (n->type == 2)
{
for (i=0; icost; i++) foo();
f
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-03-17 10:33
---
*sigh*, seems like I opened a can of worms.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from ccb at dl dot ac dot uk 2006-03-17 10:13 ---
How do I put this. The apple fenv.h supplied functions "work" by only setting
bits in mxcsr (not cw), and then only setting bits 1-6. Problem is that the
actual working bits are in 7-12 (as in fpu-387.h). So my little te
--- Comment #4 from aszodi at imp dot univie dot ac dot at 2006-03-17
08:53 ---
Andrew: I could build gcc 4.0.2 on my private iBook (OS X 10.4.4 = Darwin
V8.4.0), but not gcc 4.1.0 -- so the problem is most probably not G5-specific.
Fang: I used the nm that came with the system (/usr/b
--- Comment #5 from anlauf at gmx dot de 2006-03-17 08:06 ---
(In reply to comment #4)
> I will, however, suggest that you reconsider using --fast-math with gfortran.
> One of my codes works correctly without --fast-math, but it
> will generate NaN's with it. I have not tracked down the
99 matches
Mail list logo
