--- Comment #2 from jakub at gcc dot gnu dot org 2006-05-04 06:29 ---
Subject: Bug 27359
Author: jakub
Date: Thu May 4 06:29:16 2006
New Revision: 113513
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113513
Log:
PR c++/27359
* parser.c (cp_parser_omp_for_loop):
--- Comment #3 from jakub at gcc dot gnu dot org 2006-05-04 06:34 ---
Subject: Bug 27388
Author: jakub
Date: Thu May 4 06:34:06 2006
New Revision: 113514
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113514
Log:
PR middle-end/27388
* gimplify.c (omp_is_private):
--- Comment #6 from jakub at gcc dot gnu dot org 2006-05-04 06:40 ---
Subject: Bug 27285
Author: jakub
Date: Thu May 4 06:40:15 2006
New Revision: 113515
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113515
Log:
PR tree-optimization/27285
Backport from
--- Comment #10 from jakub at gcc dot gnu dot org 2006-05-04 06:40 ---
Subject: Bug 25985
Author: jakub
Date: Thu May 4 06:40:15 2006
New Revision: 113515
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113515
Log:
PR tree-optimization/27285
Backport from
--- Comment #7 from jakub at gcc dot gnu dot org 2006-05-04 06:44 ---
Subject: Bug 27285
Author: jakub
Date: Thu May 4 06:43:50 2006
New Revision: 113516
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113516
Log:
PR tree-optimization/27285
*
Hi,
I just pulled from SVN and tried to build for IA64, and it fails with
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
Bootstrap comparison failure!
./varasm.o differs
./gcc.o differs
--- /tmp/gcc-stage2.dump2006-05-04 16:39:19.0 +1000
+++ /tmp/gcc-stage3.dump
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-04 06:52 ---
As I see it, some part of ia64.c (or the stack displacement code) is being
miscompiling giving the different answers in the stack misplacement.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #10 from anlauf at gmx dot de 2006-05-04 07:22 ---
(In reply to comment #9)
Fixed by the additional of -fall-intrinsics option.
Steve,
the -fall-intrinsics option does not work when
in addition -Wall is specified.
The original code the leads to:
In file iargc.f90:4
--- Comment #21 from rguenth at gcc dot gnu dot org 2006-05-04 07:45
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-05-04 07:45
---
Subject: Bug 26447
Author: rguenth
Date: Thu May 4 07:44:37 2006
New Revision: 113517
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113517
Log:
2006-05-04 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #4 from jakub at gcc dot gnu dot org 2006-05-04 09:34 ---
Fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2006-05-04 09:35 ---
Fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from P dot Schaffnit at access dot rwth-aachen dot de
2006-05-04 09:38 ---
Hi!
My (not reduced) code compiles again!
Sorry for the delay, but compiling the whole does take some time...
Thanks a lot!
Philippe
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27392
--- Comment #2 from paolo at gcc dot gnu dot org 2006-05-04 09:38 ---
Subject: Bug 27404
Author: paolo
Date: Thu May 4 09:37:56 2006
New Revision: 113519
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113519
Log:
2006-05-04 Douglas Gregor [EMAIL PROTECTED]
PR
void
foo (void)
{
int i = 0;
#pragma omp parallel
#pragma omp for firstprivate (i)/* { dg-error predetermined iteration
var i must not be firstprivate } */
for (i = 0; i 10; i++)
;
}
void
bar (void)
{
int i = 0;
#pragma omp parallel for firstprivate (i) /* { dg-error
--- Comment #3 from pcarlini at suse dot de 2006-05-04 09:40 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #2 from paul dot thomas at jet dot uk 2006-05-04 09:50 ---
(In reply to comment #1)
Confirmed, this is a front-end issue.
we have:
struct calc_signal_type D.904;
D.904 = (*(struct calc_signal_type[0:] *)
outputs-data)[outputs-dim[0].stride *
void
foo (void)
{
int i = 0, j = 0;
#pragma omp for firstprivate (j)/* { dg-error j is private in outer
context } */
for (i = 0; i 10; i++)
j++;
}
int
bar (void)
{
int i, j;
#pragma omp for lastprivate (j) /* { dg-error j is private in outer
context } */
for (i = 0; i
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-05-04 10:22
---
David, do you plan on proceeding with your suggestion of disabling the power
multilib for 4.1.1? The compiler still cannot be bootstrapped on AIX 5.1.
--
ebotcazou at gcc dot gnu dot org changed:
inline float quickBinaryToFloat( unsigned const in )
{
return reinterpret_cast float const ( in ) ;
}
float foo( unsigned x )
{
unsigned y = ( x * 2 ) + 1;
return quickBinaryToFloat( y );
}
[ wrong-code generated ]
$ i486-gnu-linux-g++ bin2float.cpp -Wall -O2 -c
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-05-04 10:49 ---
Fixed.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-04 11:58 ---
This missed diagnostic is known, as enabling a warning here would cause too
much false positives. But yes, you are violating strict-aliasing rules here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27417
--- Comment #2 from pluto at agmk dot net 2006-05-04 12:08 ---
(In reply to comment #1)
This missed diagnostic is known, as enabling a warning here would cause too
much false positives.
but what about -Wstrict-aliasing=2?
it doesn't report anything, so how can i check possible
-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /USER/philippe/Irix/Gcc_Sources/configure
--prefix=/WORK/philippe/Tools/Gcc --enable-languages=c,fortran
--with-mpfr=/WORK/philippe/Tools/Mpfr --with-gmp=/WORK/philippe/Tools/Gmp
Thread model: posix
gcc version 4.2.0 20060504 (experimental)
PPS
--- Comment #5 from hubicka at gcc dot gnu dot org 2006-05-04 12:43 ---
Subject: Bug 25962
Author: hubicka
Date: Thu May 4 12:42:55 2006
New Revision: 113522
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113522
Log:
PR middle-end/25962
* cgraphunit.c
--- Comment #1 from pluto at agmk dot net 2006-05-04 13:15 ---
(In reply to comment #0)
Hi!
I would be interested in having the gcc libraries statically linked to my
binary, but still use one shared-object (a commercial library for which no
static version is available), so
--- Comment #3 from pluto at agmk dot net 2006-05-04 13:21 ---
(In reply to comment #0)
$ ldd ./libfoo.so
/lib/libNoVersion.so.1 = /lib/libNoVersion.so.1 (0x40003000)
libc.so.6 = /lib/i686/libc.so.6 (0x40015000)
/lib/ld-linux.so.2 =
--- Comment #2 from P dot Schaffnit at access dot rwth-aachen dot de
2006-05-04 13:27 ---
Hi!
Thanks a lot!
That's exactly what I was looking for: I don't seem to be able to do the same
with libgfortran, though... have I missed something, or should request that?
Thanks!
Philippe
--- Comment #12 from dje at gcc dot gnu dot org 2006-05-04 13:52 ---
Subject: Bug 26481
Author: dje
Date: Thu May 4 13:52:45 2006
New Revision: 113525
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113525
Log:
PR target/26481
* config/rs6000/rs6000.md
--- Comment #11 from aph at gcc dot gnu dot org 2006-05-04 13:54 ---
Subject: Bug 26858
Author: aph
Date: Thu May 4 13:54:15 2006
New Revision: 113526
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113526
Log:
2006-05-04 Andrew Haley [EMAIL PROTECTED]
PR java/26858
--- Comment #13 from dje at gcc dot gnu dot org 2006-05-04 13:55 ---
I was waiting for feedback from the original reporter, which never was
supplied. I have committed the patch on mainline to the 4.1 branch. I do not
have access to an AIX 5.1 system and without more details, it is
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-05-04 13:57
---
Subject: Bug 27090
Author: rguenth
Date: Thu May 4 13:56:52 2006
New Revision: 113527
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113527
Log:
2006-05-04 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-05-04 13:57 ---
Subject: Bug 19792
Author: rguenth
Date: Thu May 4 13:56:52 2006
New Revision: 113527
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113527
Log:
2006-05-04 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-04 13:57 ---
Subject: Bug 21608
Author: rguenth
Date: Thu May 4 13:56:52 2006
New Revision: 113527
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113527
Log:
2006-05-04 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-05-04 13:57
---
Subject: Bug 14844
Author: rguenth
Date: Thu May 4 13:56:52 2006
New Revision: 113527
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113527
Log:
2006-05-04 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-05-04 13:57
---
Subject: Bug 14287
Author: rguenth
Date: Thu May 4 13:56:52 2006
New Revision: 113527
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113527
Log:
2006-05-04 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-04 14:00 ---
You cannot. Though you can try extending c-common.c:strict_aliasing_warning
and
cp/typeck.c:build_reinterpret_cast_1 to warn in this case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27417
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-05-04 14:21 ---
Wording of 6.5.6/8 and /9 suggests that array objects larger than the maximum
value that fits in ptrdiff_t (which needs to be signed) invoke undefined
behavior,
not last because of the expression ((Q)+1)-(P) has the
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-04 14:47 ---
Confirmed. The problem is that the C++ frontend emits
unused_tmp = toLocal8Bit();
for the call. At least it has DECL_IGNORED set, so maybe I have a patch for
this.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #9 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-05-04 14:56 ---
Subject: Re: [4.1/4.2 Regression] Unable to determine # of iterations for a
simple loop
Wording of 6.5.6/8 and /9 suggests that array objects larger than the maximum
value that fits in
The C frontend ICEs (since at least GCC 2.95.3) on the following
invalid code snippet:
==
void foo();
void foo(struct A a) {}
==
bug1.c:2: warning: 'struct A' declared inside parameter list
bug1.c:2: warning: its scope is only this
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-05-04 15:01
---
Testcase in comment #4 is fixed, for the original testcase the folding
missed-optimization still holds. But that's for another bug.
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-05-04 15:04 ---
bar is now fixed.
;; Function foo (foo)
Analyzing Edge Insertions.
foo (t)
{
bb 2:
return size_lookup[(int) t] == size_lookup[t];
}
;; Function bar (bar)
Analyzing Edge Insertions.
bar (t)
{
bb 2:
return
The C frontend ICEs on the following invalid code snippet:
==
struct A
{
int i;
void x[1];
};
void foo(struct A a) {}
==
bug.c:4: error: declaration of 'x' as array of voids
bug.c: In function 'foo':
bug.c:7: internal compiler
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-04 15:07 ---
Fixed.
;; Function bar (bar)
Analyzing Edge Insertions.
bar (f)
{
bb 2:
return (int) f;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The C++ frontend ICEs on the following invalid code snippet since GCC 3.0:
==
void foo(void i);
void bar() { foo(0); }
==
bug.cc:1: error: 'i' has incomplete type
bug.cc:1: error: invalid use of 'void'
bug.cc: In function 'void bar()':
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-05-04 15:13
---
Fixed.
after 034.t.fre:
;; Function foo (foo)
foo (a)
{
long int c;
short int b;
short int D.1528;
short int D.1527;
bb 2:
D.1527_2 = (short int) a_1;
b_3 = D.1527_2 3;
c_4 = (long int) b_3;
The C++ frontend accepts the following invalid code snippet since at least
GCC 2.95.3:
==
void foo(void = 0);
void bar() { foo(); }
==
--
Summary: Default argument for void parameter accepted
Product: gcc
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-04 15:21 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-04 15:22 ---
Configure GCC with --disable-shared instead.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from P dot Schaffnit at access dot rwth-aachen dot de
2006-05-04 15:25 ---
I hadn't thought about that...
Thanks a lot for your help!
Philippe
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27419
--- Comment #2 from tromey at gcc dot gnu dot org 2006-05-04 15:25 ---
I'm handling this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-05-04 15:25 ---
The problem with 4.0 is that the CALL_EXPR uses the return slot address to
return, but we don't honour that.
Index: c-common.c
===
*** c-common.c
The C++ frontend rejects the following IMHO valid code snippet since GCC 3.4.0:
==
templatetypename T struct A
{
templatetemplateT class struct B {};
templateT struct C;
BC b;
};
Aint a;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27424
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27421
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27422
The C++ frontend ICEs on the following invalid code snippet since GCC 3.4.0:
==
templateint struct A
{
templatetemplatevoid class struct B {};
templatevoid struct C;
BC b;
};
A0 a;
==
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27425
Expected output on little-endian machines:
DEF05678
Real output with optimization -O2 (where -- is trash):
DEF0
Compilation command: g++ -O2 t.c
Program text:
#include stdio.h
typedef unsigned char uint08_t;
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
typedef
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-04 16:02 ---
*** This bug has been marked as a duplicate of 21920 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following invalid code snippet crashes the C++ frontend sionce GCC 3.4.0:
==
struct A;
templateA void foo();
A a;
void bar()
{
fooa();
}
==
bug.cc:5: error: aggregate 'A a' has incomplete type and cannot be defined
bug.cc:
--- Comment #95 from pinskia at gcc dot gnu dot org 2006-05-04 16:02
---
*** Bug 27426 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sje at cup dot hp dot com 2006-05-04 16:05 ---
My nightly build based on SVN version 113509 bootstrapped fine. What
source/SVN version were you building? I built using a GCC 4.0.2.
--
sje at cup dot hp dot com changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27427
--- Comment #6 from pluto at agmk dot net 2006-05-04 16:15 ---
nobody cares about this bad flags pickup?
(In reply to comment #5)
hmm, CFLAGS_FOR_TARGET picks up CFLAGS.
--- gcc-4.1-20060106/Makefile.in.orig 2005-12-15 15:02:02.0 +0100
+++ gcc-4.1-20060106/Makefile.in
--- Comment #3 from pluto at agmk dot net 2006-05-04 16:18 ---
(In reply to comment #0)
Hi,
I just pulled from SVN and tried to build for IA64, and it fails with
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
Bootstrap comparison failure!
./varasm.o differs
The following invalid code snippet causes a segfault in main_block_label
in tree-cfg.c:
===
void foo()
{
goto L;
if (0..) { L: ; }
}
===
bug.c:4:9: error: too many decimal points in number
bug.c: In function 'foo':
bug.c:5: internal
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27428
The following invalid code snippet causes an ICE since at least GCC 2.95.3:
=
templatevoid[] struct A;
=
bug.cc:1: error: creating array of void
bug.cc:1: internal compiler error: tree check: expected class 'type', have
Bugzilla says:
Comment Too Long
Comments cannot be longer than 65,535 characters.
See: http://thalassa.informatimago.com/gcc-bug.txt
If you ask for *.i files, why don't you provide a upload button in bugzilla?
--
Summary: Internal error compiling qemu-0.8.0
Product: gcc
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-05-04 16:52 ---
G. These phi nodes are all dead, but it still is verifying them anyway.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27093
--- Comment #7 from dberlin at gcc dot gnu dot org 2006-05-04 16:57 ---
Subject: Bug 27093
This should fix it.
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-05-04 16:57 ---
Created an attachment (id=11374)
--
--- Comment #7 from trt at acm dot org 2006-05-04 17:21 ---
For the tree-vrp.c part of this, perhaps VR_VARYING should be deprecated? I
notice there is a single place (set_value_range_to_varying) which assigns
VR_VARYING but a couple dozen places that check it. If instead a type-based
--- Comment #4 from aldot at gcc dot gnu dot org 2006-05-04 17:23 ---
for reference, the backtrace on i686:
Program received signal SIGSEGV, Segmentation fault.
0x0820096f in fold_convert (type=0x0, arg=0xb71527fc)
at ../../../src/gcc-4.2/gcc/fold-const.c:1991
1991 if
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-04 17:24 ---
(In reply to comment #7)
For the tree-vrp.c part of this, perhaps VR_VARYING should be deprecated?
How can something inside the compiler be deprecated? That is all internal and
nobody sees it?
--
Use -march=athlon-xp -O2 -fschedule-insns
or -march=athlon -O2 -fschedule-insns
gcc version where REPRODUCED:
gcc-3.4-20060307
gcc (GCC) 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)
---
NOT REPRODUCED by
gcc-3.3.6
There is one more bug looking much similar but amd64 arch... is better
--- Comment #1 from master_up at post dot cz 2006-05-04 17:29 ---
Created an attachment (id=11375)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11375action=view)
gcc temp .i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27432
--- Comment #2 from master_up at post dot cz 2006-05-04 17:30 ---
Created an attachment (id=11376)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11376action=view)
gcc temp .s file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27432
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-04 17:30 ---
This is the standard x86 vs 1st pass scheduling vs the register allocator bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from aldot at gcc dot gnu dot org 2006-05-04 17:30 ---
(In reply to comment #0)
If you ask for *.i files, why don't you provide a upload button in bugzilla?
There is a Create an attachment link above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27431
--- Comment #3 from tromey at gcc dot gnu dot org 2006-05-04 17:35 ---
Subject: Bug 26861
Author: tromey
Date: Thu May 4 17:35:05 2006
New Revision: 113531
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113531
Log:
PR libgcj/26861:
* interpret.cc (run)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-04 17:41 ---
register struct CPUX86State *env asm(ebp);
# 46 /d5/src/emulators/qemu-0.8.0/target-i386/exec.h
register target_ulong T0 asm(ebx);
register target_ulong T1 asm(esi);
register target_ulong T2 asm(edi);
What does one
--- Comment #4 from tromey at gcc dot gnu dot org 2006-05-04 17:42 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-04 17:42 ---
*** This bug has been marked as a duplicate of 16185 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-05-04 17:42
---
*** Bug 27431 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from brunson at brunson dot com 2006-05-04 17:43 ---
This bug is still present in gcc-3.4.6 on UnixWare (running 7.1.4, but there's
no reason not to suspect all versions).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7979
Testcase:
#define __vector __attribute__((vector_size(16)))
template class A
void f(A, vector A, int);
--
Currently we get:
t1.cc:4: error: invalid vector type for attribute 'vector_size'
Which is poor and does not explain that vectorsize attribute does not apply to
the template arument,
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-04 17:55 ---
The same issue is inside a class which in my mind should work.
#define __vector __attribute__((vector_size(16)))
template class A
struct b
{
__vector A t;
};
--
--- Comment #1 from tromey at gcc dot gnu dot org 2006-05-04 18:10 ---
It isn't clear what exception we ought to throw here.
What is happening is that we've found a .class file for a class
we're searching for, but libgcj is not configured to properly
handle class files.
I'll attach a patch to port the GCC build procedure to hosts (like
mine) whose sort' and 'tail' implementations treat operands with
leading '+' as file names, as POSIX has required since 2001. The
patch doesn't affect the build procedure on traditional hosts that
don't support POSIX syntax. This
--- Comment #1 from eggert at gnu dot org 2006-05-04 18:31 ---
Created an attachment (id=11377)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11377action=view)
Patch to support POSIX 1003.1-2001 sort, tail
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27434
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-04 18:33 ---
*** This bug has been marked as a duplicate of 14251 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-05-04 18:33
---
*** Bug 27434 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from pcarlini at suse dot de 2006-05-04 18:34 ---
To be honest, I dont't think this is, strictly speaking, a *bug*, because this
target is not officially supported.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7979
--- Comment #5 from aph at gcc dot gnu dot org 2006-05-04 18:45 ---
Subject: Bug 27352
Author: aph
Date: Thu May 4 18:44:53 2006
New Revision: 113532
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113532
Log:
2006-05-04 Andrew Haley [EMAIL PROTECTED]
* class.c
Split off of bug 27304
Currently, gfortran only detects that the IO format descriptor contains
insufficient data at run time. It would be great (though of low priority) if it
would find them at compile time. Examples:
write(*,'(abc)') n
write(10,(i7,(' abcd')), err=10) n, n
As of fixing bug
--- Comment #29 from ebotcazou at gcc dot gnu dot org 2006-05-04 19:03
---
Fixed (again), for 4.1.1.
Confirmed for all Solaris versions = 7 on 4.1 branch and mainline, thanks
again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6702
--- Comment #15 from tobias dot burnus at physik dot fu-berlin dot de
2006-05-04 19:09 ---
I probably do something wrong, but with
GNU Fortran 95 (GCC) 4.2.0 20060504 (experimental)
from http://quatramaran.ens.fr/~coudert/gfortran/gfortran-x86_64-linux.tar.gz
I still don't get a run
The new SEE pass is turned on by -O3, which introduces several regressions on
Linux/x86 and probably on Linux/x86-64:
http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg00171.html
shows
FAIL: gcc.c-torture/compile/pr20539-1.c -O3 -fomit-frame-pointer (test for
excess errors)
FAIL:
1 - 100 of 145 matches
Mail list logo
