The documentation for -fcx-limited-range states:
@item -fcx-limited-range
@opindex fcx-limited-range
When enabled, this option states that a range reduction step is not
needed when performing complex division. The default is
@option{-fno-cx-limited-range}, but is enabled by @option{-ffast-math}.
--- Comment #3 from lennox at cs dot columbia dot edu 2008-02-11 19:51
---
A discussion on comp.std.c
http://groups.google.com/group/comp.std.c/browse_thread/thread/8118ae4c53a4de60
indicates that this is indeed a constraint violation; the poster thinks that
system headers should be
I am attempting to build 4.2.3 on HP-UX 11.23/IA.
$ bzip2 -dc gcc-4.2.3.tar.bz2 | tar xf -
$ mkdir gcc-4.2.3-objdir
$ cd gcc-4.2.3-objdir
$ /opt/build/china/gcc423/ia64-hp-hpux11.23/bin/as -v
GNU assembler version 2.18 (ia64-hp-hpux11.23) using BFD version (GNU
Binutils) 2.18
$ CC=cc
--- Comment #7 from eric dot weddington at atmel dot com 2008-02-11 22:50
---
You can also try the patch set for binutils 2.18 at the WinAVR project's CVS:
http://winavr.cvs.sourceforge.net/winavr/. Under the patches module.
--
eric dot weddington at atmel dot com changed:
--- Comment #2 from ubizjak at gmail dot com 2008-02-11 21:23 ---
(In reply to comment #1)
I've seem the same error building for arm-elf. Perhaps I need a newer
(experimental) binutils?
Just a wild guess, could this be a typo?
[EMAIL PROTECTED] arm]$ grep do_itt *
ieee754-df.S:
, #0
bne .L3
bx lr
... which seems correct to me. (my build was from svn trunk, current date
20080211, unknow revision number [my build system got rid of .svn subdirs]).
No chance of a 4.2.x backport ? :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35141
Hi,
GCC 4.3 (4.3.0 20080201 (experimental) (GCC)) rejects the code with the
following error:
g++43 -W -Wall -o tt tt.cxx
tt.cxx:28: warning: unused parameter 'argv'
tt.cxx: In member function 'int TestT::set(T) [with T = char]':
tt.cxx:31: instantiated from here
tt.cxx:22: error: 'static void
--- Comment #7 from dgregor at gcc dot gnu dot org 2008-02-11 18:59 ---
Fixed on mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dgregor at gcc dot gnu dot org 2008-02-11 18:59 ---
Subject: Bug 35113
Author: dgregor
Date: Mon Feb 11 18:58:16 2008
New Revision: 132242
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132242
Log:
2008-02-11 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #5 from Rudolf dot Leitgeb at gmx dot at 2008-02-11 17:48
---
Subject: Re: illegal opcode movw for mcu avr3
Please note, that this bug is also apparent in the production
version of gcc 4.2.3. This is the specific reason why I posted
a supposed copy of the original bug
--- Comment #6 from jakub at gcc dot gnu dot org 2008-02-11 23:11 ---
cp_parser_class_name since PR20293 errors unconditionally even during tentative
parse. Mark, is there a way to get a silent tentative parse of the optional
nested name specifier plus typename? Or is trying to parse
--- Comment #3 from manu at gcc dot gnu dot org 2008-02-11 16:44 ---
This seems confirmed
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ktietz at gcc dot gnu dot org 2008-02-11 14:57 ---
It is 4.3.0. I modified the bug report for that.
Cheers, Kai
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-11 14:51 ---
which gcc version?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
--- Comment #16 from joel at gcc dot gnu dot org 2008-02-11 14:43 ---
ACATS Results for various combinations. SPARC and PowerPC are the primary ones
we have tested on for years. This was actually the first full set of automated
runs on i386 using qemu. Suggestions on the high number
--- Comment #28 from victork at gcc dot gnu dot org 2008-02-11 14:21
---
As for the last email, Victor:
1. Using a smaller number of iterations, doesnt help me. This is not what
the
real world code runs.
Looks like in your example the memory subsystem is a performance
--- Comment #26 from victork at gcc dot gnu dot org 2008-02-11 13:41
---
Probably, the small difference between vectorized and non-vectorized versions
can be explained by the fact that big arrays do not fit the memory cache.
Here is the version of the original program which shows that
--- Comment #4 from joel at gcc dot gnu dot org 2008-02-11 21:40 ---
Perhaps Paul could provide some insight. :)
$ svn blame ieee754-df.S ieee754-df.S | grep do_itt
120408 pbrook do_itt eq
120408 pbrook do_itt eq
--
joel at gcc dot gnu dot org changed:
--- Comment #3 from alexandre dot nunes at gmail dot com 2008-02-11 21:34
---
(In reply to comment #2)
(In reply to comment #1)
I've seem the same error building for arm-elf. Perhaps I need a newer
(experimental) binutils?
Just a wild guess, could this be a typo?
[EMAIL
--- Comment #8 from vlad dot sharanhovich at gmail dot com 2008-02-11
22:19 ---
This bug is present in gcc 3.4.3. Was ever fixed or forgotten forever?
--
vlad dot sharanhovich at gmail dot com changed:
What|Removed |Added
--- Comment #17 from jason at gcc dot gnu dot org 2008-02-12 06:44 ---
PR 35065 has a testcase that exhibits this same bug in the current pre-4.3.0
sources.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jason at gcc dot gnu dot org 2008-02-12 06:42 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #17 from jason at gcc dot gnu dot org 2008-02-12 06:41 ---
Fixed for 4.3.0 and 4.2.4.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jason at gcc dot gnu dot org 2008-02-12 06:41 ---
Fixed for 4.2.4 by reverting part of Mark's patch for PR 29039.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2008-02-12 06:26 ---
Not a bug: The name of a member (static or not) without class qualification
can not be used in an address-of expression or decay to a pointer as
desired in the current context:
5.19/2:
Other expressions are
--- Comment #5 from jason at gcc dot gnu dot org 2008-02-12 06:38 ---
Subject: Bug 29039
Author: jason
Date: Tue Feb 12 06:37:34 2008
New Revision: 132254
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132254
Log:
PR c++/34094
* decl2.c
--- Comment #16 from jason at gcc dot gnu dot org 2008-02-12 06:38 ---
Subject: Bug 34094
Author: jason
Date: Tue Feb 12 06:37:34 2008
New Revision: 132254
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132254
Log:
PR c++/34094
* decl2.c
--- Comment #5 from alexandre dot nunes at gmail dot com 2008-02-11 21:31
---
I tested on i686 (-march=athlon-xp -O2) with gcc 4.3 revision 132072 (older
than the one I tried at arm), and it seems to misbehave there.
I'm not sure tought of the implications, since that's a superscalar
--- Comment #6 from Rudolf dot Leitgeb at gmx dot at 2008-02-11 19:25
---
I just tried the suggested patch against binutils 2.18, gcc 4.2.3 still does
not compile. Also, the suggested patch does not apply cleanly against 2.18,
although this only affects a .texi file which is not needed
--- Comment #1 from nightstrike at gmail dot com 2008-02-12 02:39 ---
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00350.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
--- Comment #7 from hunor at cs dot bme dot hu 2008-02-11 17:50 ---
I got the same error on i686-pc-linux-gnu with revision 132237. The -Werror is
indeed the result of --enable-maintainer-mode:
libstdc++-v3/acinclude.m4:
...
if test x$USE_MAINTAINER_MODE = xno; then
WERROR=''
--- Comment #12 from pault at gcc dot gnu dot org 2008-02-11 17:48 ---
(In reply to comment #11)
OK I have a fix, up to a wrinkle that raises a standard question:
alloc_comp_constructor.f90 now compiles and runs OK but aborts because the
bounds are changed by the implicit conversion
--- Comment #4 from corsepiu at gcc dot gnu dot org 2008-02-11 17:17
---
The binutils patch mentioned in comment#2 seems to fix this issue.
Today's gcc-trunk using binutils-2.18 with the patch applied doesn't expose
this breakdown anymore.
= The cause for this breakdown was using
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-02-12 01:37 ---
(In reply to comment #4)
We fixed the mmintrin.h issues by using inline when __GNUC_STDC_INLINE__, and
static inline otherwise in our tree.
The other way is to use the gnu_inline attribute always which case I am
--- Comment #10 from janis at gcc dot gnu dot org 2008-02-12 01:35 ---
I'm still plugging away at this since I keep thinking of more things I might
have broken. I've got some good new tests for the testsuite now that check how
arguments and return values are actually passed for
--- Comment #4 from mrs at apple dot com 2008-02-12 01:28 ---
We fixed the mmintrin.h issues by using inline when __GNUC_STDC_INLINE__, and
static inline otherwise in our tree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
--- Comment #29 from dberlin at gcc dot gnu dot org 2008-02-11 16:29
---
Vectorization is not magic.
I'm also not sure where you got the idea that vectorization = magic speedup
There is no real expected performance gain on memory bound applications
because the processor spends all of
--- Comment #33 from alexandre dot nunes at gmail dot com 2008-02-12 00:32
---
I compiled gcc 4.3 for arm-unknown-elf (today's trunk, not sure about the rev).
Compiling three in three firmware images gave me size regressions with -Os;
with -O2, gcc 4.3 produces smaller code than 4.2.3:
--- Comment #2 from joel at gcc dot gnu dot org 2008-02-11 14:49 ---
Sent privately... wanted to log this .. untested at this point.
Please excuse me, I could not reply earlier.
Use patch for binutils:
http://sourceware.org/ml/binutils/2008-01/msg00037.html
Anatoly.
--
--- Comment #4 from joel at gcc dot gnu dot org 2008-02-11 14:47 ---
Better information on more current version in 35143
*** This bug has been marked as a duplicate of 35143 ***
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from joel at gcc dot gnu dot org 2008-02-11 14:25 ---
ChangeLog entry for gcc-svn-ada-20080211.diff.
2008-02-11 Joel Sherrill [EMAIL PROTECTED]
PR ada/35143
* env.c: Add __rtems__ to if defined.
* s-osinte-rtems.adb: Add To_Target_Priority
--- Comment #3 from jakub at gcc dot gnu dot org 2008-02-11 12:49 ---
Why? When there are multiple output register constraints, that says they must
be allocated in different output registers. The first asm is a silly way to
write the same as =r (d0), =r (d1), =r (d2), as the original
--- Comment #24 from victork at gcc dot gnu dot org 2008-02-11 12:23
---
Hi,
Here are some more of my observations.
1. For some unclear reason there is indeed no much difference between
vectorized and non-vectorized versions for long runs like time ./TestNoVec
92200 8 89720 1000, but
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-11 11:53 ---
Hmm, I think the inline-asm is missing an early clobber too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jv244 at cam dot ac dot uk 2008-02-11 11:25 ---
(In reply to comment #5)
Or are you complaining that we constant fold integer powers as if they were
non-integer powers
Richard,
I think I'm suggesting more a enhancement than a bug fix. Some good quality
compiler
--- Comment #6 from ubizjak at gmail dot com 2008-02-11 22:20 ---
(In reply to comment #5)
I tested on i686 (-march=athlon-xp -O2) with gcc 4.3 revision 132072 (older
than the one I tried at arm), and it seems to misbehave there.
I'm not sure tought of the implications, since
--- Comment #6 from jason at gcc dot gnu dot org 2008-02-12 06:39 ---
I reverted Mark's patch for 4.2.4 because it caused PR 33916. This bug is
fixed in 4.3.0 by the patch for 33916, which seems too complex to risk
backporting.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29039
--- Comment #4 from pcarlini at suse dot de 2008-02-11 09:31 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
test.c:
...
int main() {
signed char a = -30;
/* a == sE2 (-30 signed char) */
signed char b = -31;
/* b == sE1 (-31 signed char) */
int r = a = (unsigned short)b;
/* (unsigned short)b == uFFE1 (65505 unsigned short) */
/*
r
==
a = (unsigned short)b
==
--- Comment #3 from paolo at gcc dot gnu dot org 2008-02-11 09:29 ---
Subject: Bug 35077
Author: paolo
Date: Mon Feb 11 09:28:48 2008
New Revision: 132237
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132237
Log:
cp/
2008-02-11 Paolo Carlini [EMAIL PROTECTED]
PR
I think it is formally valid to have multiple times the same C binding label
(at least for procedures). At least I cannot find anything in the standard
which says otherwise.
Currently, both gfortran and NAG f95 reject the following program while g95 and
ifort accept it.
See also question posted
--- Comment #39 from rguenth at gcc dot gnu dot org 2008-02-11 08:27
---
Subject: Bug 33992
Author: rguenth
Date: Mon Feb 11 08:27:00 2008
New Revision: 132234
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132234
Log:
2008-02-11 Uros Bizjak [EMAIL PROTECTED]
Richard
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #1 from alexandre dot nunes at gmail dot com 2008-02-11 20:12
---
I've seem the same error building for arm-elf. Perhaps I need a newer
(experimental) binutils?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35071
--- Comment #21 from david dot billinghurst at riotinto dot com 2008-02-12
02:48 ---
Subject: RE: Irix6.5 ada bootstrap fail in ada/targparm.adb
I no longer have a mips-sgi-irix server or have any interest in this
bug. I am happy for it to be closed.
NOTICE
This e-mail and any
There is at least one simple case that the value range deduction apparently
fails to cover. The compiler generates a message about control reaching
possibly the end of a non-void function given the source file:
#include string.h
int ns_strcmp(const char *a, const char *b)
{
int i;
i=
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-12 01:36 ---
ld is running at this time so I doubt this is a GCC bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35169
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #6 from schwab at suse dot de 2008-02-11 15:46 ---
The same change is causing an ICE on ia64.
internal compiler error: in rws_insn_set, at config/ia64/ia64.c:5336
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #11 from jason at gcc dot gnu dot org 2008-02-12 06:38 ---
Subject: Bug 33916
Author: jason
Date: Tue Feb 12 06:37:34 2008
New Revision: 132254
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132254
Log:
PR c++/34094
* decl2.c
--- Comment #2 from jason at gcc dot gnu dot org 2008-02-12 06:35 ---
Subject: Bug 35097
Author: jason
Date: Tue Feb 12 06:34:59 2008
New Revision: 132253
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132253
Log:
PR c++/35097
* pt.c (tsubst): Don't look up a
--- Comment #17 from joel at gcc dot gnu dot org 2008-02-11 14:47 ---
*** Bug 34469 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143
--- Comment #14 from joel at gcc dot gnu dot org 2008-02-11 14:24 ---
Created an attachment (id=15130)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15130action=view)
SVN RTEMS Patch
This patch greatly improves the results of the ACATS for SVN on PowerPC and
SPARC. Please apply.
--- Comment #5 from jakub at gcc dot gnu dot org 2008-02-11 14:16 ---
Regression since http://gcc.gnu.org/viewcvs?root=gccview=revrev=128864
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35160
--- Comment #9 from manu at gcc dot gnu dot org 2008-02-11 23:43 ---
(In reply to comment #8)
This bug is present in gcc 3.4.3. Was ever fixed or forgotten forever?
[EMAIL PROTECTED]:~$ ~/132202/build/gcc/cc1plus --version
GNU C++ (GCC) version 4.3.0 20080209 (experimental) [trunk
--- Comment #27 from eyal at geomage dot com 2008-02-11 14:00 ---
Hi,
I am a bit lost and appriciate your guidelines. Up till now, after all those
emails, I still have no clue as to why such a simple test case doesnt work. As
far as I understood the vectorization should have shown
--- Comment #25 from irar at il dot ibm dot com 2008-02-11 13:35 ---
(In reply to comment #21)
(In reply to comment #14)
Giving it another thought, this is not necessary an alias analysis issue,
even
that it fails to tell that the pointers not alias. Since in this case the
--- Comment #1 from v dot haisman at sh dot cvut dot cz 2008-02-11 19:19
---
Created an attachment (id=15131)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15131action=view)
The test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35167
I see massive failures of objc on i686-apple-darwin9:
=== objc Summary for unix ===
# of expected passes2894
# of unexpected failures84
# of expected failures 7
# of unresolved testcases 75
# of unsupported tests 2
===
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|---
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-12 01:54 ---
/tmp/message.c:24: warning: control reaches end of non-void function
this warning happens before VRP anyways.
This is related to PR 14495 (or really the same).
--
pinskia at gcc dot gnu dot org changed:
--- Comment #22 from steven at gcc dot gnu dot org 2008-02-12 07:10 ---
Zap.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #30 from hubicka at gcc dot gnu dot org 2008-02-11 09:23
---
On britten there is also no noticeable effect on SPECfp score.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
--- Comment #18 from ubizjak at gmail dot com 2008-02-11 08:56 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #17 from uros at gcc dot gnu dot org 2008-02-11 08:55 ---
Subject: Bug 35047
Author: uros
Date: Mon Feb 11 08:54:33 2008
New Revision: 132235
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132235
Log:
PR testsuite/35047
* gcc.dg/compat/vector-2_x.c:
--- Comment #40 from ubizjak at gmail dot com 2008-02-11 08:59 ---
Richi, thanks for the fix.
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
On x86_64 with -O1 and higher, 4.3 miscompiles:
extern void abort (void);
void
__attribute__((noinline))
foo (unsigned long *y)
{
unsigned long b[3], c0, c1, c2, d0, d1, d2;
d0 = 0; d1 = 0; d2 = 0; c0 = c1 = c2 = 0;
__asm__ (movl $7, %k0; movl $8, %k1; movl $9, %k2
: +r
--- Comment #1 from jakub at gcc dot gnu dot org 2008-02-11 08:33 ---
Silent miscompilation of nss.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2008-02-11 13:26 ---
BTW, it fails even when all +r's are replaced with +r's, though that
doesn't
make the testcase more valid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35160
--- Comment #1 from steven at gcc dot gnu dot org 2008-02-11 10:44 ---
CCing fold guru.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC|
On x86_64 with -O2 the following testcase ICEs with:
D.11907_556(ab) and D.11907_14(ab)
rh432296.C: In function `void foo(std::vectorBD, std::allocatorBD )':
rh432296.C:52: internal compiler error: SSA corruption
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #7 from alexandre dot nunes at gmail dot com 2008-02-12 00:45
---
It is not what you think it is. ;)
movl%edx, -536821760
means:
(set (mem:SI (const_int -536821760 [0xe000c000]))(reg/v:SI 1 dx))
IOW, put %edx to constant address.
It actually
--- Comment #2 from bugzilla-gcc at thewrittenword dot com 2008-02-12
03:52 ---
(In reply to comment #1)
ld is running at this time so I doubt this is a GCC bug.
The Pid it is referring to (Pid 18929 received a SIGSEGV for stack growth
failure.) is
83 matches
Mail list logo
