--- Comment #3 from ubizjak at gmail dot com 2007-06-03 06:42 ---
(In reply to comment #2)
> #0 build_call_expr (fndecl=0x0, n=4) at ../../trunk/gcc/builtins.c:10379
fndecl is already NULL there.
> #1 0x0068d0bd in expand_complex_libcall (bsi=0x7fbfffed20,
There is a pack
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-03 06:26 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-03 06:26 ---
real8 D.1040;
complex8 D.1050;
D.1050 = D.1040;
This is caused by the predictive commoning optimization.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dcb314 at hotmail dot com 2007-06-03 06:18 ---
Created an attachment (id=13653)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13653&action=view)
Fortran source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32194
I just tried to compile Fortran package LAPACK with the
GNU Fortran compiler version 4.3 snapshot 20070601
The compiler said
/home/dcb/gcc/20070601/results/bin/gfortran -g -O3 -Wall -c zlag2c.f -o
zlag2c.o
zlag2c.f: In function 'zlag2c':
zlag2c.f:85: internal compiler error: in convert_move, at e
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-03 05:37 ---
> Change that to:
> /* #include */
> #include
That is wrong and non portable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32193
Compiled gcc version 4.3.0 20070602 with tzdata 2007b-1 and libc6 2.3.6.ds1-13
everything went well enough and "make -i check" was not too bad ...
Decided to upgrade. Everything compiled fine until the _last_ library (of
course), otherwise it would have worked fine.
wget http://ftp.
--- Comment #5 from kkojima at gcc dot gnu dot org 2007-06-03 04:39 ---
Subject: Bug 32163
Author: kkojima
Date: Sun Jun 3 04:38:52 2007
New Revision: 125292
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125292
Log:
PR target/32163
* config/sh/sh.md (symGOT_loa
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-06-03 03:27
---
The Comment #3 example is not the same as the original report. The attached
example is already preprocessed source with file name information embedded in
lines beginning with '#'
This is handled in scanner.c. T
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-03 02:00 ---
>Could the check in the code be moved futher up so the compiler can see that the
> checking is being done?
Not if glibc is marking the functions as warn_unused_result. Also the
front-end would need some flow analys
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-03 01:55
---
Closing, Did not here any objections.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from mckelvey at maskull dot com 2007-06-03 01:39 ---
Created an attachment (id=13652)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13652&action=view)
ii and s files from compilation in b2zipped tar
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32192
$ g++ -c -g -fno-elide-constructors -DNO_INTL=1 -pedantic-errors -Werror
-ansi -fno-common -Wall -Wold-style-cast -Wsign-promo -Wpointer-arith -Wundef
-Wwrite-strings -Winvalid-pch -Woverloaded-virtual -Wcast-qual -Wextra
-Wredundant-decls -Wshadow -Wcast-align -Wcomment -fstrict-aliasing -Win
--- Comment #3 from robert at linuxfromscratch dot org 2007-06-03 00:50
---
I checked whether it was fixed in trunk, but you're right I should have made a
patch that applies to trunk. Glibc is giving a false positive here, but the
programmer and compiler are the only ones able to know.
--- Comment #2 from igodard at pacbell dot net 2007-06-02 23:40 ---
Either way, it is reporting on the first line after the point of actual error
that contains a use of a template. The space between error and report is thus
arbitrarily large and may cross files, and the flagged line has
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-06-02 23:20
---
Closing. I get an error message that seems OK
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from tromey at gcc dot gnu dot org 2007-06-02 21:52 ---
I see this bug when I compile the test case without -O.
I tried svn trunk and also 4.1.1 20070105 (Red Hat 4.1.1-51)
--
tromey at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #4 from joseph at codesourcery dot com 2007-06-02 21:35 ---
Subject: Re: Complex __float128 is rejected
On Sat, 2 Jun 2007, gdr at cs dot tamu dot edu wrote:
> | Of course, 6.7.2 paragraph 2 does not include _Complex typedef-name in the
> | possible sets of type specifier
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-06-02 21:10
---
(In reply to comment #1)
> typedef _Complex float __attribute__((mode(TC))) c128;
> c128 g(void);
> void foo ()
> {
> c128 x, y;
> x = g();
> }
Nope. That one doesn't ICE. The backtrace for the ICE my code in
--- Comment #20 from patchapp at dberlin dot org 2007-06-02 21:10 ---
Subject: Bug number PR18923
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00111.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-02 21:06 ---
This works for me with powerpc64-linux-gnu which has a TCmode.
I think the reason why it is only triggered with -std=c99/-std=gnu99 is because
__multc3 is only called then. __multc3 returns a TCmode. So you most li
That one is weird, because it's only triggered with -std=c99 (or -std=gnu99):
$ cat foo.c
void foo ()
{
typedef _Complex float __attribute__((mode(TC))) c128;
c128 x, y;
x *= y;
}
$ gcc -c foo.c
$ gcc -c -std=c99 foo.c
foo.c: In function foo:
foo.c:6: internal compil
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|FAIL: gcc.target/i386/sse- |[4.3 Regression] FAIL:
|13.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-02 20:57 ---
On the mainline I just get:
t.cc: In function 'int main()':
t.cc:7: error: template argument 1 is invalid
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
--- Comment #3 from gdr at cs dot tamu dot edu 2007-06-02 20:28 ---
Subject: Re: Complex __float128 is rejected
"joseph at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| Subject: Re: Complex __float128 is rejected
|
| On Sat, 2 Jun 2007, ubizjak at gmail dot com wrote:
|
| > I
--- Comment #2 from joseph at codesourcery dot com 2007-06-02 20:09 ---
Subject: Re: Complex __float128 is rejected
On Sat, 2 Jun 2007, ubizjak at gmail dot com wrote:
> Is this a parser problem? Compilation fails even for generic:
>
> --cut here--
> typedef float DFtype __attribute_
This code:
template class foo{ };
int main() {
foo i;
foo j;
int k;
int l;
foo m;
return 0;
}
gets you:
~/ootbc/sim/sandbox$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:8: error: template argument 1 is invalid
foo.cc:8: error: invalid type in declaration befor
--- Comment #1 from ubizjak at gmail dot com 2007-06-02 19:44 ---
Is this a parser problem? Compilation fails even for generic:
--cut here--
typedef float DFtype __attribute__((mode(DF)));
__complex__ DFtype z;
void test(void) { z = 1.0+2.0i; }
--cut here--
--
http://gcc.gnu.org/
--- Comment #9 from dominiq at lps dot ens dot fr 2007-06-02 19:09 ---
> It also fails on powerpc-linux (32bits).
It also fails on powerpc-apple-darwin7.9.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32124
--- Comment #1 from ubizjak at gmail dot com 2007-06-02 18:38 ---
Fixed by reverting the patch that caused the failure.
--
ubizjak at gmail dot com changed:
What|Removed |Added
---
I cannot compile tiff in my system, FreeBSD ports, with error msg
"internal compiler error: Segmentation fault: 11 Please submit a full
bug report". Details are listed below.
* the exact version of GCC;
GCC 3.4.4
* the system type;
FreeBSD 6.1 release-p17
* the options given wh
I got
bash-3.1$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.target/i386/sse-13.c -O2 -msse4.1
-msse4a -fno-show-column -S -m32 -o sse-13.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/include/smmintr
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-02 16:14 ---
Well considering this was introduced by you (and Michael Meissner and Marius
Cornea). It seems like you should have just fixed it instead of filing a bug
:).
--
pinskia at gcc dot gnu dot org changed:
We have DPD and BID versions of DFP instrinsics. However, libgcc.texi still
documents the old intrinsic names.
--
Summary: DFP instrinic document is out of date
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Prior
--- Comment #16 from hjl at lucon dot org 2007-06-02 14:20 ---
Here are SPEC CPU 2K -O2 -ffast-math differences between revision
125029 and revision 125029 on Intel64 C2D:
(r125030 - r125029)/r125029
164.gzip 0.0706714%
175.vpr
--- Comment #2 from begert at gmail dot com 2007-06-02 13:18 ---
(In reply to comment #1)
> /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or
> direc\
> tory
>
> That means you don't have the 32bit userland installed which means you either
> use --disable-multili
I've been trying to use the complex type associated with __float128, but it's
rejected:
$ cat u.c
int main (void) { __complex__ __float128 z; }
$ gcc u.c
u.c: In function main:
u.c:1: error: expected =, ,, ;, asm or __attribute__ before z
--
Summary: Complex __float128
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-02 12:45 ---
> Wow. Nothing is happening.
You are right that unfortunately not much happened regarding this feature
request during the last two and a half months, however, in total quite a lot
happened:
http://gcc.gnu.org/viewcvs/
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-06-02 11:45
---
It looks like 12.6.2/5-6 specify it enough to make the testcase valid. The
BaseClass is only once initialized by the most derived object initializer
specification.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-06-02 11:35
---
Confirmed. Actually compiling Wrapper.cxx with -fstrict-aliasing is enough to
trigger the failure.
In getItem() the difference is
:
- D.3769 = &_local_result + 4B;
- this = (struct BaseClass *) D.3769;
- thi
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-02 11:32 ---
*** This bug has been marked as a duplicate of 29819 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-02 11:32 ---
*** Bug 30942 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from mralanmorgan at gmail dot com 2007-06-02 09:51 ---
Wow. Nothing is happening.
Glad I bothered raising the bug.
Now I know not to waste time documenting the other ten or so bugs I've found.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31310
--- Comment #1 from scovich at gmail dot com 2007-06-02 09:37 ---
It also appears that 'next' is broken and acts like 'step' (enter all
functions), while 'finish' acts like 'continue' (run to completion, barring a
breakpoint).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32186
Compiling with 'g++ -ggdb' confuses both gdb-6.5 and gdb-6.6 into thinking
they've got corrupted stacks. My programs all seem to execute properly, both
alone and inside gdb -- it's just hard to debug anything. Using 'g++ -g'
instead seems to work fine.
Consider 'g++ -ggdb foo.cpp' with the followi
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-06-02 08:30
---
I have a patch for PR18923 that also appears to fix this. Testing now. I
think this is a duplicate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25252
--- Comment #15 from rakdver at kam dot mff dot cuni dot cz 2007-06-02
07:49 ---
Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop
> > Has anyone measured impact of adding DCE on SPEC CPU 2000/2006 peformance?
>
> Take a look at:
> http://www.suse.de/~gcc
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-06-02 07:37
---
(In reply to comment #2)
> http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/ieee754/?cvsroot=glibc
>
> Look into ldbl-128 directory...
I don't think that's built into glibc on x86_64, is it? And, as far as
49 matches
Mail list logo
