--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-06 10:35 ---
(later)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-06 10:10 ---
Actually, CCP propagates the invariant address in
D.1547_2 = /dev/ptyXX[8];
*D.1547_2 ={v} 1;
which we cannot undo easily, so we indeed should fold the stmt to a
trap representation.
--
--- Comment #1 from jakub at gcc dot gnu dot org 2008-03-06 11:20 ---
This is not middle-end thing, all that is needed is change fortran FE to lower
(some forms of ) !$omp workshare constructs into some other standard
worksharing construct than single, particularly into OMP_FOR or
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-06 09:43 ---
Indeed. Maybe we should finally change the default.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-03-06 10:34 ---
Created an attachment (id=15268)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15268action=view)
patch
Like with this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35468
When trying to build some data processing stuff (using an interface for some
median functions in a module), I get an internal compiler error: Segmentation
fault.
This code snippet should *not* compile anyway (there being no median function
taking two arguments) but I think a compiler segfault is a
--- Comment #1 from dominiq at lps dot ens dot fr 2008-03-06 10:57 ---
Confirmed with 4.2.3, fixed at least in 4.3.0 2008021 and trunk (4.4.0):
pr35478.f90:46.9:
data = median(rawData, work)
1
Error: There is no specific function for the generic 'median' at (1)
--
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2008-03-06 12:45
---
Remaining tasks in this PR: taking care of math functions that now accept
complex args (in particular, A{SIN,COS,TAN}{,H}), taking care of the two
arguments form of ATAN, and deal with the 3 args form of
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2008-03-06 12:41
---
Subject: Bug 33197
Author: fxcoudert
Date: Thu Mar 6 12:40:28 2008
New Revision: 132970
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132970
Log:
PR fortran/33197
* intrinsic.c
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2008-03-06 13:15
---
(In reply to comment #14)
I think also missing are:
- Compile-time evaluation of erfc_scaled
Right. A though one.
- Implementation of NORM2
There are quite a few other new F2008 intrinsics, including other
--- Comment #14 from burnus at gcc dot gnu dot org 2008-03-06 13:10 ---
Remaining tasks in this PR: [...]
I think also missing are:
- Compile-time evaluation of erfc_scaled
- Implementation of NORM2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33197
--- Comment #6 from jsm28 at gcc dot gnu dot org 2008-03-06 13:51 ---
Then we should fix this bug by requiring 64-bit HOST_WIDE_INT for x86 targets
rather than by declaring it will never be fixed. It can be closed when we've
switched to 64-bit HOST_WIDE_INT (or as a duplicate if we
--- Comment #16 from burnus at gcc dot gnu dot org 2008-03-06 13:50 ---
(In reply to comment #15)
- Implementation of NORM2
There are quite a few other new F2008 intrinsics, including other
transformational intrinsics, so I think it's better to focus this PR on math
intrinsics.
I
--- Comment #4 from jsm28 at gcc dot gnu dot org 2008-03-06 13:32 ---
Different code for the same target on different hosts is a valid bug, not
INVALID. If a target works with more than one HOST_WIDE_INT setting, the
choice should not affect the code generated; this is separate from
According to the 6.1.3.5 [tr.tuple.rel], there is an implicit dependencies on
the sizes of the tuples being compared, and there should be a compilation
failure if the tuples are not the same size.
However I am not seeing compilation errors in this case. The following example
compiles and runs.
--- Comment #1 from gryan at akoostix dot com 2008-03-06 14:30 ---
Created an attachment (id=15269)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15269action=view)
Preprocessed file
Preprocessed file output using the -save-temps flag.
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-06 13:38 ---
32bit HWI cannot represent 128bit constants. If you are lucky and it works as
far as creating code you should not be surprised that some constants might
be forced to memory. The only chance to generate the same
--- Comment #4 from loki at gcc dot gnu dot org 2008-03-06 15:01 ---
Created an attachment (id=15272)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15272action=view)
Use own COMPUTE_RTX_LENGTH method
The previous patch wasn't a good solution for some targets.
This patch fixes the
file gcc/config/rs6000/aix61.h and gcc/config/rs6000/aix53.h are missing.
gcc/config.gcc doesn't manage aix6.1,
--
Summary: GCC is not ported to AIX 5.3 / AIX 6.1
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
When compiling libjava on AIX 6.1, gcc generates to the assembler symbols with
dollar inside.
But IBM as is not able to manage dollar in symbol names, so the compilation
fails.
--
Summary: GCC on AIX doesn't support dollar in symbols name.
Product: gcc
Version:
--- Comment #2 from Laurent dot Vivier at bull dot net 2008-03-06 14:59
---
Created an attachment (id=15271)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15271action=view)
Add AIX 6.1 detection
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35481
--- Comment #1 from Laurent dot Vivier at bull dot net 2008-03-06 14:58
---
Created an attachment (id=15270)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15270action=view)
Add AIX 5.3 and 6.1 definitions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35481
When compiling libffi on AIX with ppc64 target, libffi fails.
Assembler parts of libffi manage only 32bit AIX.
--
Summary: libffi doesn't support AIX 64bit
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority:
GCC allows to compile gcj but libgcj is not generated.
--
Summary: libjava is disabled by default
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo:
--- Comment #1 from Laurent dot Vivier at bull dot net 2008-03-06 15:28
---
Created an attachment (id=15275)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15275action=view)
enable libjava on AIX
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35485
--- Comment #1 from Laurent dot Vivier at bull dot net 2008-03-06 15:24
---
Created an attachment (id=15274)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15274action=view)
Add AIX 64bit support
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35484
--- Comment #1 from Laurent dot Vivier at bull dot net 2008-03-06 15:14
---
Created an attachment (id=15273)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15273action=view)
This patch learns to gcc how to use IBM as with symbols with dollar inside.
This patch removes '$' from
--- Comment #19 from nightstrike at gmail dot com 2008-03-06 16:08 ---
Ok, compiling the aforementioned Hello, world! program using gfortran
--save-temps hello.f90 results in f951.exe maxing out the CPU forever.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
--- Comment #2 from pcarlini at suse dot de 2008-03-06 16:27 ---
Frankly, I'm not 100% sure we want an error here: I mean, we have a Requires
violation in the case at issue, which, in general, in my reading of the
standard, certainly doesn't mean the code must not compile, means
--- Comment #3 from gryan at akoostix dot com 2008-03-06 16:38 ---
I understand your concern here, which is why I wrote that I thought that it was
implicit.
The standard says where geti(t) == geti(u) is a valid expression only,
however; 6.1.3.4 says that geti(t) is ill formed if I is
--- Comment #4 from pcarlini at suse dot de 2008-03-06 16:53 ---
(In reply to comment #3)
To me, if geti(t) fails to compile under the assumption of ill formed,
then
by the definitions of 6.1.3.5, geti(t) == geti(u) should also fail to
compile. Although it is not explicitly stated
--- Comment #4 from rwild at gcc dot gnu dot org 2008-03-06 17:00 ---
but libjava/classpath/configure was forgotten:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01453.html
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pcarlini at suse dot de 2008-03-06 17:00 ---
By the way, in the meanwhile I checked N2322 and C++0x will simply enforce
EqualityComparableTTypes, UTypes...
We are presently trying to figure out whether in the meanwhile we want to
explicitly enforce sizeof...(TTypes)
This was done for GCC 4.3.0.
Sent from my iPhone
On Mar 6, 2008, at 6:58, Laurent dot Vivier at bull dot net [EMAIL PROTECTED]
wrote:
--- Comment #1 from Laurent dot Vivier at bull dot net
2008-03-06 14:58 ---
Created an attachment (id=15270)
--
--- Comment #3 from pinskia at gmail dot com 2008-03-06 16:40 ---
Subject: Re: GCC is not ported to AIX 5.3 / AIX 6.1
This was done for GCC 4.3.0.
Sent from my iPhone
On Mar 6, 2008, at 6:58, Laurent dot Vivier at bull dot net
[EMAIL PROTECTED]
wrote:
--- Comment #1 from
--- Comment #6 from chris at bubblescope dot net 2008-03-06 17:11 ---
While I agree that this is an issue of implementation detail, I thought there
was code already there to stop this case, except it is broken :(
Looking at the svn copy of tr1/tuple, you can see operator== (and others)
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-03-06 17:18 ---
Fixed so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pcarlini at suse dot de 2008-03-06 17:18 ---
Cool, if everything can be dealt with right now by simply fixing that, then
let's do it! Really, in these times, I dislike the idea of robustify templates
here and there (without a global neat strategy) with old-times
--- Comment #3 from jsm28 at gcc dot gnu dot org 2008-03-06 17:30 ---
Subject: Bug 33963
Author: jsm28
Date: Thu Mar 6 17:29:36 2008
New Revision: 132978
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132978
Log:
PR target/33963
* tree.c (handle_dll_attribute):
--- Comment #4 from jsm28 at gcc dot gnu dot org 2008-03-06 17:31 ---
Fixed in 4.3.1 and 4.4.0.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rwild at gcc dot gnu dot org 2008-03-06 17:03 ---
Never mind, sorry about the noise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35481
--- Comment #3 from paolo at gcc dot gnu dot org 2008-03-06 17:51 ---
Subject: Bug 35323
Author: paolo
Date: Thu Mar 6 17:50:54 2008
New Revision: 132980
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132980
Log:
/cp
2008-03-06 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #4 from paolo at gcc dot gnu dot org 2008-03-06 17:51 ---
Subject: Bug 35333
Author: paolo
Date: Thu Mar 6 17:50:54 2008
New Revision: 132980
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132980
Log:
/cp
2008-03-06 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #4 from paolo at gcc dot gnu dot org 2008-03-06 17:51 ---
Subject: Bug 35338
Author: paolo
Date: Thu Mar 6 17:50:54 2008
New Revision: 132980
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132980
Log:
/cp
2008-03-06 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #5 from pcarlini at suse dot de 2008-03-06 17:52 ---
Fixed for 4.3.1 too.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from pcarlini at suse dot de 2008-03-06 17:53 ---
Fixed for 4.3.1 too.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini
--- Comment #4 from pcarlini at suse dot de 2008-03-06 17:53 ---
Fixed for 4.3.1 too.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #14 from belyshev at depni dot sinp dot msu dot ru 2008-03-06
17:58 ---
It is now broken on trunk on x86_64-linux with -m32 -fPIC:
pr11832.c: In function 'foo':
pr11832.c:30: error: unrecognizable insn:
(insn 216pr11832.c:30: internal compiler error: Segmentation fault
--- Comment #4 from tromey at gcc dot gnu dot org 2008-03-06 18:09 ---
Subject: Bug 35458
Author: tromey
Date: Thu Mar 6 18:08:40 2008
New Revision: 132982
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132982
Log:
libcpp
2008-03-06 Markus Milleder [EMAIL PROTECTED]
PR
--- Comment #5 from tromey at gcc dot gnu dot org 2008-03-06 18:15 ---
I agree with comment #3.
This is an improvement.
Users concerned with real portability should be avoiding # anyhow.
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from dominiq at lps dot ens dot fr 2008-03-06 18:20 ---
Could the patch in comment #4 explain the following regressions?
FAIL: gcc.dg/bf-ms-layout-2.c execution test
FAIL: gcc.dg/bf-ms-layout.c execution test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
--- Comment #10 from burnus at gcc dot gnu dot org 2008-03-06 18:23 ---
It seems things are now worse:
next.c:91: assertion failed: !mpfr_set_exp ((x), (exp + 1))
f951: internal compiler error: Aborted
Works for me with 4.4.0 and 4.3.0 20080131/rev131976 and 4.3.0 (of today) on
--- Comment #2 from belyshev at depni dot sinp dot msu dot ru 2008-03-06
18:34 ---
Both are testsuite bugs, apparently.
ldist-1.f90 scans for:
! { dg-final { scan-tree-dump-times distributed: split to 4 loops 1 ldist }
}
and the dump output is: Loop 1 distributed: split to 5 loops.
--- Comment #8 from paolo at gcc dot gnu dot org 2008-03-06 18:36 ---
Subject: Bug 35480
Author: paolo
Date: Thu Mar 6 18:35:26 2008
New Revision: 132983
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132983
Log:
2008-03-06 Chris Jefferson [EMAIL PROTECTED]
Paolo
--- Comment #10 from pcarlini at suse dot de 2008-03-06 18:37 ---
Fixed for 4.4.0 and 4.3.1.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #9 from paolo at gcc dot gnu dot org 2008-03-06 18:36 ---
Subject: Bug 35480
Author: paolo
Date: Thu Mar 6 18:35:37 2008
New Revision: 132984
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132984
Log:
2008-03-06 Chris Jefferson [EMAIL PROTECTED]
Paolo
--- Comment #2 from burnus at gcc dot gnu dot org 2008-03-06 19:03 ---
Paul, do you have an idea?
The ICE happens when reading the .mod for p-u.wsym.sym-name == i in
free_pi_tree:
if (p-fixup != NULL)
gfc_internal_error (free_pi_tree(): Unresolved fixup);
I got somehow lost in
--- Comment #6 from dominiq at lps dot ens dot fr 2008-03-06 19:18 ---
With the patch from comment #4 I get onpowerpc-apple-darwin9:
[karma] f90/bug% gfc -c -frtl-abstract-sequences
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/pr11832.c
--- Comment #2 from green at redhat dot com 2008-03-06 19:40 ---
Thanks for this patch. If you haven't already done so, please submit it to
[EMAIL PROTECTED] Be sure to include proper ChangeLog entries.
Thanks!
AG
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35484
Hi!
I get this when building gimple-tuples-branch (rev 132972) on x86_64/debian 4:
echo '[c]' tmp-gi.list
echo '/home/mstein/svn/gimple-tuples-branch/gcc/c-lang.c' tmp-gi.list
echo '/home/mstein/svn/gimple-tuples-branch/gcc/c-tree.h' tmp-gi.list
echo
--- Comment #1 from dnovillo at gcc dot gnu dot org 2008-03-06 20:01
---
Thanks. This is known and I'm working on a fix. In the meantime, you can get
a clean build of the branch if you configure with --disable-bootstrap
--disable-libmudflap --disable-libgomp
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-03-06 21:57 ---
Subject: Bug 35402
Author: pinskia
Date: Thu Mar 6 21:56:04 2008
New Revision: 132991
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132991
Log:
2008-03-06 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-03-06 21:59 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from hjl dot tools at gmail dot com 2008-03-06 22:03 ---
This is a known issue with mgrid. The absolute tolerance is too
small. After increasing absolute tolerance from 1.0e-12 to
1.0e-11, the miscomparison is gone.
--
hjl dot tools at gmail dot com changed:
--- Comment #2 from jakub at gcc dot gnu dot org 2008-03-06 22:09 ---
Subject: Bug 34964
Author: jakub
Date: Thu Mar 6 22:08:55 2008
New Revision: 132992
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132992
Log:
* gimplify.c (goa_lhs_expr_p): Allow different ADDR_EXPR
--- Comment #2 from jakub at gcc dot gnu dot org 2008-03-06 22:09 ---
Subject: Bug 35028
Author: jakub
Date: Thu Mar 6 22:08:55 2008
New Revision: 132992
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132992
Log:
* gimplify.c (goa_lhs_expr_p): Allow different ADDR_EXPR
--- Comment #4 from jakub at gcc dot gnu dot org 2008-03-06 22:09 ---
Subject: Bug 35078
Author: jakub
Date: Thu Mar 6 22:08:55 2008
New Revision: 132992
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132992
Log:
* gimplify.c (goa_lhs_expr_p): Allow different ADDR_EXPR
--- Comment #2 from jakub at gcc dot gnu dot org 2008-03-06 22:09 ---
Subject: Bug 35244
Author: jakub
Date: Thu Mar 6 22:08:55 2008
New Revision: 132992
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132992
Log:
* gimplify.c (goa_lhs_expr_p): Allow different ADDR_EXPR
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-06 22:22 ---
Actually this is already fixed with my patch for PR 35402, the code that sets
module_statics_const is dead code which I will remove.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35403
Hi.
I am testing a floating point division algorithm. I had tested several thousand
division cases. In most case, the result was the same with the calculated
result with FPU.
However, I found an error case for double precision floating-point division.
The case is as follows;
n = 1.600228...;
d
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |target
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-06 22:44 ---
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #105 from pinskia at gcc dot gnu dot org 2008-03-06 22:44
---
*** Bug 35488 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from purnnam1 at naver dot com 2008-03-06 23:07 ---
It's not simple floating point related error!
I fully understand that the decimal number can't be converted to the exact
floating point number. so, the result may be different from our expectation.
This problem has no
--- Comment #3 from purnnam1 at naver dot com 2008-03-06 23:09 ---
This problem is not kind of a duplicate of #323.
--
purnnam1 at naver dot com changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-03-06 23:14 ---
The i?86 FPU computes values in 80bit precision by default. Starting with
GCC 4.3 you can use -mpc64 to reduce its precision to 64bits thereby obtaining
the valid IEEE-754 result. Or you can use -mfpmath=sse to
--- Comment #106 from rguenth at gcc dot gnu dot org 2008-03-06 23:14
---
*** Bug 35488 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-03-06 23:15 ---
The division is done and then rounded to 80bits and then rounded again to
64bits.
This is not really a bug. It is just a misunderstanding on how x87 FPU works.
fldl-24(%ebp)
fldl-32(%ebp)
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-03-06 23:18 ---
One more comment about this code, you are violating C/C++ aliasing rules.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35488
I'm not sure whether this is the proper method for reporting errors in
the documentation. However, I believe there is a serious error in the
GCC documentation that needs to be addressed.
The error is at http://gcc.gnu.org/bugs.html#nonbugs_general. This
section refers to inherent limitations of
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-06 23:58 ---
but others are
actual bugs in which the compiler is generating incorrect instructions
(such as #12331);
That is not incorrect instructions. Just different than what you are
expecting. All can be defected by the
--- Comment #107 from pinskia at gcc dot gnu dot org 2008-03-06 23:58
---
*** Bug 35489 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #7 from purnnam1 at naver dot com 2008-03-07 00:05 ---
Although I knew GCC use 80-bit format internally, I thought the result should
be same in 80-bit format.
Due to the very kind explanation about my problem, I can understand that the
result can be changed because the
--- Comment #7 from hjl at gcc dot gnu dot org 2008-03-07 00:08 ---
Subject: Bug 35189
Author: hjl
Date: Fri Mar 7 00:07:36 2008
New Revision: 132994
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132994
Log:
gcc/
2008-03-06 H.J. Lu [EMAIL PROTECTED]
Backport from
--- Comment #2 from adam at irvine dot com 2008-03-07 00:08 ---
(In reply to comment #1)
but others are
actual bugs in which the compiler is generating incorrect instructions
(such as #12331);
That is not incorrect instructions. Just different than what you are
expecting.
I
--- Comment #8 from purnnam1 at naver dot com 2008-03-07 00:37 ---
Actually the 80-bit internal format will be better in converting a decimal
number into the floating point number. In this point, the 80-bit internal
format may be useful.
--
Take the following piece of code:
#define vector __vector
struct data {
vector float v;
};
extern int bar (int a, struct data b, void *c);
int foo (struct data *inp_r3, void *inp_r4)
{
return bar(10, *inp_r3, ((void *) inp_r4));
}
Right now we sibcall with -O2 and the
Take the following code:
#define vector __vector
struct data {
float f; //0 - 3
int i;// 4 - 7
double d; // 8 - 15
vector float v; // 16 - 31
};// __attribute__ ((d64_abi)); //size is 32
extern int bar (int a, struct data b, void *c);
int foo (struct data
--- Comment #9 from brian at dessent dot net 2008-03-07 01:20 ---
Subject: A incorrect result in a simple division, only in
32-bit gcc.
Although I knew GCC use 80-bit format internally, I thought the result should
be same in 80-bit format.
No, it's not that gcc uses 80 bit or 64
With trunk r132993 and gcc-4_3-branch r132992, the following testcase yields,
with -march=v32 -O2:
(const_int -13 [0xfff3])
s2.c: In function 'sk_stream_wait_connect':
s2.c:26: internal compiler error: output_operand: invalid operand for 'p'
modifier
void prepare_to_wait (void *, void
/Users/dave/gnu/gcc/objdir/./prev-gcc/xgcc
-B/Users/dave/gnu/gcc/objdir/./prev-g
cc/ -B/opt/gnu/gcc/gcc-4.4.0/i686-apple-darwin9/bin/ -c -g -O2
-fomit-frame-poin
ter -gnatpg -gnata -nostdinc -I- -I. -Iada -I../../gcc/gcc/ada
../../gcc/gc
c/ada/ada.ads -o ada/ada.o
--- Comment #1 from hp at gcc dot gnu dot org 2008-03-07 03:07 ---
Also with trunk r132670. The ICE points at the somewhat-hairy last alternative
of the *btst pattern for being at fault for not matching for the insn appearing
in 177r.greg:
(insn:QI 12 11 13 3 s2.c:18 (set (cc0)
--- Comment #10 from bergner at gcc dot gnu dot org 2008-03-07 04:15
---
Created an attachment (id=15276)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15276action=view)
Updated patch to disallow TFmode and TDmode from reg+reg addressing
Here is an updated patch that not
--- Comment #8 from hjl dot tools at gmail dot com 2008-03-07 04:24 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2008-03-07 04:26 ---
There is no problem. TARGET_128BIT_LONG_DOUBLE is enabled in 64bit:
/* By default, 64-bit mode uses 128-bit long double. */
#undef TARGET_SUBTARGET64_DEFAULT
#define TARGET_SUBTARGET64_DEFAULT \
--- Comment #2 from eres at il dot ibm dot com 2008-03-07 04:52 ---
(In reply to comment #1)
What happens if you build from a clean directory?
I get the same error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35457
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-07 04:58 ---
I don't usually build in combined tree for spu-elf so I never run into this
issue. I wonder if due to the newer autoconf issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35457
--- Comment #4 from eres at il dot ibm dot com 2008-03-07 05:15 ---
(In reply to comment #3)
I don't usually build in combined tree for spu-elf so I never run into this
issue. I wonder if due to the newer autoconf issue.
It seems to be related to the following change:
2008-02-20
Revision 132991:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00445.html
breaks 483.xalancbmk in SPEC CPU 2006 on Linux/Intel64
with -O2 -ffast-math. I got
Running 483.xalancbmk ref base o2 default
483.xalancbmk: copy #0 non-zero return code (rc=0, signal=6)
bash-2.05b# g++ -maix64 a.cpp
/tmp//ccAIh3XS.o(.pr+0x1c):/tmp//ccveogPZ.c: undefined reference to
`.__register_frame_info_table'
/tmp//ccAIh3XS.o(.pr+0x6c):/tmp//ccveogPZ.c: undefined reference to
`.__deregister_frame_info'
collect2: ld returned 1 exit status
gcc compiler i am using 4.0.0.0.
1 - 100 of 109 matches
Mail list logo
