--- Comment #2 from carrot at google dot com 2009-05-01 06:21 ---
Actually gcc has already implemented this optimization, but it doesn't work for
this case.
Reload pass tries to determine the stack frame, so it needs to check the
push/pop lr optimization opportunity. One of the criteria
--- Comment #1 from carrot at google dot com 2009-05-01 06:12 ---
Created an attachment (id=17787)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17787&action=view)
sample code showing the optimization opportunity
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39989
Compiling this code snippet with gcc for arm,
typedef struct node node_t;
typedef struct node *node_p;
struct node
{
int orientation;
node_p pred;
long depth;
};
node_t *primal_iminus(long *delta, node_t *iplus, node_t*jplus)
{
node_t *iminus = 0;
if( iplus->depth < jplu
--- Comment #12 from bonzini at gnu dot org 2009-05-01 05:42 ---
Subject: Re: [4.5 Regression] Bootstrap failure in libjava on
i686-apple-darwin9
-mtune=generic should be eliminated from the ppc build, too (but intel
fails also without it)
--
http://gcc.gnu.org/bugzilla/s
--- Comment #11 from bonzini at gnu dot org 2009-05-01 05:40 ---
Subject: Re: [4.5 Regression] Bootstrap failure in libjava on
i686-apple-darwin9
The file name is really gnuPOA$RefTemplate.class
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
Consider the following test case:
program defallocatable
implicit none
! Demonstrate structure constructors with default initialization
! and allocatable arrays. (Unspecified in F2003, initialized to
! unallocated in F2008.)
type mytype_t
integer, allocatable :: data(:)
end type
ty
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.0 4.3.0 4.2.0
Known to work||4.1
Like PR 37971 but this time Find is a template member function instead of just
a member function.
Testcase:
class foo
{
template
static bool func(const U& x)
{}
public:
template
unsigned int Find(const U& x, bool (*pFunc) (const U&) = func) const
{}
};
class bar {
bool Initialize();
prote
--- Comment #4 from gustcr at yahoo dot com dot ar 2009-05-01 00:10 ---
(In reply to comment #3)
I couldn't find any other gmp or mpfr in the system.
Also tried using the system's ld and as (both version 2.11.2) but the same
error pops up (see below).
Using ps ax I checked that the righ
quot;.data"
.align 2
.type x, @object
.size x, 4
x:
.long 574619666
.ident "GCC: (GNU) 4.5.0 20090430 (experimental) [trunk revision
147009]"
When the same compiler is built to be a 64-bit binary then the result is the
same except for
The warning printed with -Wignored-qualifiers (warning: type qualifiers
ignored on function return type) seems to be lying. The const on a functions
return type is not actually ignored, as can be demonstrated using typeof(). I
think that the warning should be right and the typeof() behavior is
--- Comment #13 from meissner at gcc dot gnu dot org 2009-04-30 22:00
---
Subject: Bug 39955
Author: meissner
Date: Thu Apr 30 21:59:49 2009
New Revision: 147021
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147021
Log:
fix for PR 39955
Modified:
trunk/gcc/ChangeLog
t
--- Comment #10 from dominiq at lps dot ens dot fr 2009-04-30 21:58 ---
> can you try the command-line I posted
I guess it is from comment #6. Using a stupid copy and paste, I get
RefTemplate: Undefined variable.
After some trial and error, I ran
/opt/gcc/gcc4.5w/libexec/gcc/i686-app
--- Comment #4 from sje at gcc dot gnu dot org 2009-04-30 21:43 ---
Subject: Bug 39579
Author: sje
Date: Thu Apr 30 21:43:21 2009
New Revision: 147018
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147018
Log:
PR middle-end/39579
* gcc.dg/vect/vect-35.c: XFAIL fo
Test gcc.dg/vect/ggc-pr37574.c started failing on powerpc64-linux with -m32 or
-m64 with this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=146888
r146888 | rguenth | 2009-04-28 12:16:22 + (Tue, 28 Apr 2009)
with the following options to cc1, which are used in the testsuite:
-D__l
--- Comment #9 from bonzini at gnu dot org 2009-04-30 21:10 ---
Subject: Re: [4.5 Regression] Bootstrap failure in libjava on
i686-apple-darwin9
> I successfully bootstrapped libjava on powerpc-apple-darwin9 at revision
> 146999.
Interesting, can you try the command-line I po
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
Component|target |libgomp
Target Milestone|--- |
--- Comment #8 from dominiq at lps dot ens dot fr 2009-04-30 21:07 ---
I successfully bootstrapped libjava on powerpc-apple-darwin9 at revision
146999.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
--- Comment #10 from dannysmith at users dot sourceforge dot net
2009-04-30 21:07 ---
(In reply to comment #9)
> (In reply to comment #6)
> > (In reply to comment #4)
> > > Your libpthreads is doing something wrong.
> > > Re. comment 5
> > The command was actually
> > gcc -fopemnp test.
no-recursion
Thread model: posix
gcc version 4.5.0 20090430 (experimental) [trunk revision 147009] (GCC)
--
Summary: ICE: type mismatch in address expression
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priori
--- Comment #9 from dannysmith at users dot sourceforge dot net 2009-04-30
20:57 ---
(In reply to comment #6)
> (In reply to comment #4)
> > Your libpthreads is doing something wrong.
> > Re. comment 5
> The command was actually
> gcc -fopemnp test.c -lgomp -o test.exe
>
That command
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-30 20:17 ---
I am not sure if it is related. Revision 146817 miscompiled 465.tonto in
SPEC CPU 2006 on Linux/ia32 with
-O3 -msse2 -mfpmath=sse -ffast-math -funroll-loops -m32
The resulting tonto binary generated the wrong resul
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-30 19:51 ---
:
# crkveuk_lsm.686_3635 = PHI
# cikve_lsm.685_3640 = PHI
# crkveuk_lsm.686_3564 = PHI
Interesting, I wonder if that causes expand SSA to go crazy or do we go into
closed loop form on purpose now.
--
h
--- Comment #1 from danglin at gcc dot gnu dot org 2009-04-30 19:47 ---
Still present in 4.4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
--- Comment #2 from luisgpm at linux dot vnet dot ibm dot com 2009-04-30
19:38 ---
Created an attachment (id=17786)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17786&action=view)
Last tree pass for the bad code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
--- Comment #5 from sergei_lus at yahoo dot com 2009-04-30 19:32 ---
Please close this issue. I think the real problem is in libc, not in the
compiler. (test passes with -fno-threadsafe-statics). Thank you for support.
--
sergei_lus at yahoo dot com changed:
What|Rem
--- Comment #1 from luisgpm at linux dot vnet dot ibm dot com 2009-04-30
19:29 ---
ASM code for the bad loop
.L145:
fmul 10,8,13
fmul 5,8,0
addis 3,4,0xffe5
lfd 22,8(7)
addi 7,4,8
lfd 6,9472(3)
fmadd 10,9,0,10
fmsub 23,9,1
This problem originates in peren_c++. The test (Sec13/3_1_3/P13290.C)
exercising the following clause: ISO/IEC 14882:1998, 13.3.1.3.
(When a user-defined conversion is invoked to convert an
assignment-expression to a type cv T, where T is a class type,
a constructor of T is considered a candidat
--- Comment #4 from navinkumar+bugs at gmail dot com 2009-04-30 19:22
---
Since std::is_empty<_2_emptyB>::value && std::is_empty<_2_emptyA>::value (as
verified by the static assertions), GCC should not treat _2_emptyB differently
from _2_emptyA when computing the structure's layout. Th
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-30 19:01 ---
I think GCC is doing the correct thing here as there is no padding to put
_2_emptyB in. And this is not a zero-size base class optimization but rather
padding filling class optimization.
Have you read the IA64 C++
--- Comment #2 from navinkumar+bugs at gmail dot com 2009-04-30 18:57
---
Tested with 2 versions of GCC, same behavior;
Version #1
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /1123/scratch/gcc4.4.0/src/configure
--prefix=/1123/software/gcc4.4.0 --with-local-
--- Comment #1 from navinkumar+bugs at gmail dot com 2009-04-30 18:54
---
Created an attachment (id=17785)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17785&action=view)
demonstrates scenarios when zero-size base class optimization fails
compile with flag: -std=c++0x
--
ht
Scenario1A: When class X inherits from A, B, and C; and A and C are empty
classes, then gcc properly creates X such that: sizeof(X) == sizeof(B)
Scenario1B: When class X inherits from A and B; and A is an empty class, then
gcc properly creates X such that: sizeof(X) == sizeof(B)
Scenario2A: Whe
--- Comment #3 from jv244 at cam dot ac dot uk 2009-04-30 18:48 ---
a bug in the code that is triggered by the option. closing as invalid.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--
--- Comment #1 from sje at cup dot hp dot com 2009-04-30 18:41 ---
Created an attachment (id=17784)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17784&action=view)
Preprocessed test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39980
I will attach the preprocessed source code. I think the code is valid but I am
not sure of that after using delta to cut it down as far as I could.
x.cc:40: internal compiler error: tree check: accessed elt 3 of tree_vec with 2
elts in tsubst, at cp/pt.c:9249
Please submit a full bug report,
wit
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-30 17:59 ---
Seems related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29209 which seems
like it was worked around in 4.3 and 4.4 but exposed again with the SSA expand
patch.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-30 17:55 ---
Interesting. I Knew about a PIC failure on arm but I the backtrace was
different, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12 .
--
pinskia at gcc dot gnu dot org changed:
What|Remove
--- Comment #5 from janis at gcc dot gnu dot org 2009-04-30 17:53 ---
Subject: Bug 39776
Author: janis
Date: Thu Apr 30 17:53:23 2009
New Revision: 147011
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147011
Log:
PR testsuite/39776
* g++.dg/ext/altivec-15.C: Rem
--- Comment #4 from janis at gcc dot gnu dot org 2009-04-30 17:48 ---
Subject: Bug 39776
Author: janis
Date: Thu Apr 30 17:48:03 2009
New Revision: 147010
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147010
Log:
PR testsuite/39776
* g++.dg/ext/altivec-15.C: Rem
hi,
i'm currently testing gcc-4.4.1-20090427 on my large c++ codebase.
the application uses threads, contains over 100+ shared components
and the tested debug build (-O0 -g2 -fpic) needs over 2GB of disk space,
so creating reduced testcase at this point isn't trivial thing.
i've observed that boo
--- Comment #1 from danglin at gcc dot gnu dot org 2009-04-30 17:27 ---
See the same error on hppa-unknown-linux-gnu:
libtool: compile: /home/dave/gnu/gcc/objdir/./gcc/gfortran
-B/home/dave/gnu/gcc
/objdir/./gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/bin/
-B/home/dave/o
pt/gnu/
if [ x"-fPIC" != x ]; then \
/home/dave/gnu/gcc/objdir/./prev-gcc/xgcc
-B/home/dave/gnu/gcc/objdir/./prev-gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.5.0/arm-none-linux-gnueabi/bin/ -c
-DHAVE_CONFIG_H -g -O2 -I/home/dave/opt/gnu/include -I.
-I../../gcc/libiberty/../include -W -Wall -Wwrite-strin
--- Comment #16 from pault at gcc dot gnu dot org 2009-04-30 17:03 ---
module m
type t
integer :: i,j
end type t
interface assignment (=)
module procedure i_to_t
end interface
contains
elemental subroutine i_to_t (p, q)
type(t), intent(out) :: p
integer, intent
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
The 32 bit PA build broke with version 146817. The failure can be reproduced
by compiling the included test program. The failure is:
x.c: In function '__fixtfdi':
x.c:9: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6825
Please submit a full bug report,
with preprocessed source
--- Comment #3 from kargl at gcc dot gnu dot org 2009-04-30 16:35 ---
(In reply to comment #2)
> (In reply to comment #1)
> > Change Severity to normal. Fortran bugs are never major.
> >
> > AFAIK, there will be no further releases from the gcc-4.1.x branch,
> > so it is highly unlikel
--- Comment #3 from luisgpm at linux dot vnet dot ibm dot com 2009-04-30
16:33 ---
This is already in 4.4, but we would like to add additional checks on 4.5 that
would be risky to have on 4.4 (since it was almost being released). I have the
additional patch and will attach it soon.
Sor
--- Comment #3 from hjl dot tools at gmail dot com 2009-04-30 16:32 ---
Revision 146817 is the cause. It is reproducible with test data, -i test.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #12 from janis at gcc dot gnu dot org 2009-04-30 16:30 ---
In comment #10 I meant that the tests in gcc.c-torture/execute now pass for
powerpc64-linux with -m32 and -m64, and that the 3 tests in gcc.target/powerpc
listed in comment #7 still fail for powerpc64-linux with -m32;
We have a hot spot on sixtrack in a function called thin6d.
Such loop is generated by the old (pre-146817) gcc as a single BB, thus the
only way inside that loop is by executing instructions until we fall into that
code.
The post-146817 gcc breaks that loop in two BB's, such that we can actually
--- Comment #2 from gustcr at yahoo dot com dot ar 2009-04-30 16:24 ---
(In reply to comment #1)
> Change Severity to normal. Fortran bugs are never major.
>
> AFAIK, there will be no further releases from the gcc-4.1.x branch,
> so it is highly unlikely that this bug will be fixed. g
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu
2009-04-30 16:09 ---
Subject: Re: gfortran support for non-standard sind,cosd and friends
intrinsics
On Thu, Apr 30, 2009 at 07:38:31AM -, ruben at tapir dot caltech dot edu
wrote:
>
>
> --- Comment #9 from
;" on:
g++ (GCC) 4.4.0 20090427 (Red Hat 4.4.0-3)
and gives DW_TAG_structure_type DW_AT_name "type27" on:
g++ (GCC) 4.5.0 20090430 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35463
--- Comment #2 from jb at gcc dot gnu dot org 2009-04-30 15:12 ---
Subject: Bug 39667
Author: jb
Date: Thu Apr 30 15:12:37 2009
New Revision: 147004
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147004
Log:
Fix PR libfortran/39667
Modified:
trunk/gcc/testsuite/ChangeLog
--- Comment #7 from bonzini at gnu dot org 2009-04-30 14:56 ---
Ah, I didn't bootstrap so jc1 cannot be miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
--- Comment #6 from bonzini at gnu dot org 2009-04-30 14:56 ---
Fails after PRE.
Reduced testcase requiring just a jc1 executable (assuming gcc is built in a
subdirectory of the toplevel, i.e. ../configure):
./jc1 "../../libjava/classpath/lib/gnu/CORBA/Poa/gnuPOA\$RefTemplate.class"
"-
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #4 from jakub at gcc dot gnu dot org 2009-04-30 13:05 ---
I think this has been fixed by
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146137
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146290
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146897
on the trunk.
--
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-30 13:02 ---
Revision 146817:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html
may be the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-30 13:00 ---
Revision 146817:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html
is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-30 12:46 ---
*** Bug 35462 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35463
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-30 12:46 ---
*** This bug has been marked as a duplicate of 35463 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #12 from dennis dot wassel at googlemail dot com 2009-04-30
12:44 ---
Closing, works with 4.3.3
--
dennis dot wassel at googlemail dot com changed:
What|Removed |Added
---
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29336
--- Comment #2 from ramana at gcc dot gnu dot org 2009-04-30 11:29 ---
gcc 3.4 is no longer supported. Marking this as WONTFIX.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from dominiq at lps dot ens dot fr 2009-04-30 11:25 ---
> Does http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01619.html fix this?
No! Still fails at revision 146999.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-30 10:39 ---
We need more information on what the exact problem is with the code generated.
Could you try with a compiler of more recent vintage and report back ?
--
ramana at gcc dot gnu dot org changed:
What
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-30 10:37 ---
For 4.3 try if -fno-tree-sra fixes the failures.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38696
--- Comment #11 from dennis dot wassel at googlemail dot com 2009-04-30
10:31 ---
It is working with 4.3.3, so it seems to have been silently fixed somewhere.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36689
--- Comment #4 from ramana at gcc dot gnu dot org 2009-04-30 10:30 ---
Not sure if this is related to PR31849 as well.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
---
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target trip
--- Comment #4 from ramana at gcc dot gnu dot org 2009-04-30 10:25 ---
If there is a request to support a big endian default configuration for ARM,
there should be a separate enhancement request for that. Given this, I'd close
this bug as being invalid. I've filed PR39975 for this partic
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
Create a default configuration that honours big endian ARM by default. PR31938
refers to this.
--
Summary: Support big endian ARM by default.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
--- Comment #5 from ramana at gcc dot gnu dot org 2009-04-30 10:18 ---
Can you try with a compiler of more recent vintage and report back ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from ramana at gcc dot gnu dot org 2009-04-30 10:10 ---
Can you try with a compiler of more recent vintage and report back.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from joseph at codesourcery dot com 2009-04-30 10:09 ---
Subject: Re: [4.5 Regression] ./plugin-version.h:11:
error: 'gcc_version' defined but not used
On Thu, 30 Apr 2009, pinskia at gcc dot gnu dot org wrote:
> Really I think plugin support is flawed. There should r
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38571
--- Comment #9 from ramana at gcc dot gnu dot org 2009-04-30 10:05 ---
This is now fixed with r147000
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ramana at gcc dot gnu dot org 2009-04-30 10:05 ---
Subject: Bug 38571
Author: ramana
Date: Thu Apr 30 10:04:52 2009
New Revision: 147000
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147000
Log:
Fix PR target/38571
Modified:
trunk/gcc/ChangeLog
trun
--- Comment #10 from pault at gcc dot gnu dot org 2009-04-30 09:52 ---
(In reply to comment #9)
> (In reply to comment #8)
> > I have remote access to the machine now. Having trouble with gcc build. Not
> > forgotton.
>
> I remember our admin talking about needing an updated ld to be a
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-30 09:27 ---
Seems to work today on gcc50 with gcc 4.4.0 and trunk on the simulator .I don't
see these failures in recent testresults on gcc-testresults@ from the
auto-tester at gcc50.
--
ramana at gcc dot gnu dot org changed:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39974
The following code snippet produces a bogus warning when compiled with
"-O2 -Wall" on trunk:
bug.cc: In function 'void
_Z41__static_initialization_and_destruction_0ii.clone.0()':
bug.cc:3: warning: array subscript is below array bounds
bug.cc:3: warning: array subscript is below array bounds
bug.c
--- Comment #16 from jakub at gcc dot gnu dot org 2009-04-30 09:07 ---
Created an attachment (id=17783)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17783&action=view)
gcc45-pr39942.patch
Patch that attempts to take into account .p2align directives that are emitted
for (some) COD
--- Comment #4 from ramana at gcc dot gnu dot org 2009-04-30 09:02 ---
Can you try with a later version of the compiler (in the set of released
versions) 4.3.4 , 4.4.0 or trunk and report back ?
Don't get this failure with arm-eabi configurations.
--
ramana at gcc dot gnu dot org c
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39972
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39973
--- Comment #4 from espindola at google dot com 2009-04-30 08:07 ---
Probably fixed on 146998.
Andrew Pinski, we cannot use a shared library for this. The idea is for the
plugin to remember what gcc version it was compiled for. A shared library can
change after the fact.
--
http://
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |tree-optimization
--- Comment #2 from jan dot kratochvil at redhat dot com 2009-04-30 07:52
---
Please close it as DUPLICATE of PR debug/35463.
--
jan dot kratochvil at redhat dot com changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2009-04-30 07:51 ---
These functions will *not* be implemented, period.
And even if they would be implemented, they'd internally just return
sin(arg*180/pi) & co. The compiler and the runtime library don't actually
calculate sin/cos the
--- Comment #9 from ruben at tapir dot caltech dot edu 2009-04-30 07:38
---
Someone suggested multiplying or dividing the argument by a factor.
That does not do - the floating point precision achieved would be insufficient.
Someone complains about the names of these functions. I don't
--- Comment #8 from ruben at tapir dot caltech dot edu 2009-04-30 07:33
---
In my considered opinion, the need to support these functions has little to do
with efficiency or with convenience. It has more to do with accuracy and
symmetries; relations such as sind(30)=0.5, cosd(90)=0.0,
96 matches
Mail list logo
