../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value
`ANYF:UNITMODE' for `mode' attribute
../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value
`ANYF:UNITMODE' for `mode' attribute
Sorry,these errors were just my mistake.I mistakenly comminted out the
following line in ABC.md file
kernel coder [EMAIL PROTECTED] writes:
../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value
`ANYF:UNITMODE' for `mode' attribute
../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value
`ANYF:UNITMODE' for `mode' attribute
Sorry,these errors were just my mistake.I mistakenly
According to your proposal, I hereby send my comments referring to your web
pages about downloading gcc. To me, your instructions are absolutely
impossible to understand, they could not be more impossible to understand if
they were written in Hebroe or Mandarin.
I will not recommend you
Gunnar Sjoo wrote:
Better to learn something easier, like solving Einstein's general field
equations.
If that is *really* the case, then probably you should now waste time on
gcc and instead try yourself on quantum gravity or string theory ;) ;)
Paolo.
Gunnar Sjoo wrote:
According to your proposal, I hereby send my comments referring to your web
pages about downloading gcc. To me, your instructions are absolutely
impossible to understand, they could not be more impossible to understand if
they were written in Hebroe or Mandarin.
I
http://gcc.gnu.org/regtest/HEAD/ has a link to logfile showing the
state of the tree since October, 2002. However, the current logfile
starts in July, 2005. Do you have the old data and can you add it to
the file or should the description for the link be updated? This page
doesn't appear to be
On 20 June 2006 10:08, Gunnar Sjoo wrote:
According to your proposal, I hereby send my comments referring to your web
pages about downloading gcc. To me, your instructions are absolutely
impossible to understand, they could not be more impossible to understand if
they were written in Hebroe
Steven Bosscher wrote:
I don't see how I could do the same with the new scheme from the projects
page, which goes like this (quoted from that page):
-
For arithmetic, each hash table elt has the following slots:
* Operation. This is an rtx code.
* Mode.
* Operands
(I am new in the list, so I understand that my opinion should not be
taken as seriously as others.)
Three persons have already given witty replies. I think most of us got
the point with the first one. Is it necessary to spend more time
reading emails about this? If you want to give some reply or
Hello Manuel,
three people may have given witty replies... isn't a smile worth that?
I'm also new to the list, and I respect it as a place for meaningful
discussions. At the same time, I'm not against any genuine and
spontaneous humour that may arise from time to time among such serious
On 20/06/06, Roberto COSTA [EMAIL PROTECTED] wrote:
Hello Manuel,
three people may have given witty replies... isn't a smile worth that?
I'm also new to the list, and I respect it as a place for meaningful
discussions. At the same time, I'm not against any genuine and
spontaneous humour that may
Does using fields of auto variables of union type generate code that
is less efficient than it would be using scalars?
That is, if in C++ I declare my variables as
foo()
{
union
{
int n;
};
...
}
as opposed to simply
foo()
{
int n;
...
}
would gcc generate inferior code?
Andrew Haley wrote:
Does using fields of auto variables of union type generate code that
is less efficient than it would be using scalars?
That is, if in C++ I declare my variables as
foo()
{
union
{
int n;
};
...
}
as opposed to simply
foo()
{
int n;
On 19 Jun 2006 16:45:43 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
I tried recreating this, but I couldn't. I get this:
...
This of course is not ideal, since it unconditionally executes the
rdhwr instruction. But it is not the same as what the OP reported.
I used stock gcc 4.1.1 to
Atsushi Nemoto [EMAIL PROTECTED] writes:
On 19 Jun 2006 16:45:43 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
I tried recreating this, but I couldn't. I get this:
...
This of course is not ideal, since it unconditionally executes the
rdhwr instruction. But it is not the same as what
Hi,
I checked gcc's C99 status page today and noticed that C99 conformance
seems to evolve rather slowly. Most importantly for me, support for
complex data types is marked as broken for several years now.
Is there any hope that this might change in the foreseeable future?
Thanks,
Martin
--
Hi my name is Gyle Yearsley. I am a design engineer at ZiLOG. We are in the
process of releasing a new CPU. I have generated a gcc backend for this
processor. I have read your contributions page and was wondering what the
steps are and how to get permission to add this to the gcc distribution.
Gyle Yearsley [EMAIL PROTECTED] writes:
Hi my name is Gyle Yearsley. I am a design engineer at ZiLOG. We are in the
process of releasing a new CPU. I have generated a gcc backend for this
processor. I have read your contributions page and was wondering what the
steps are and how to get
Support in GCC 4.2 for decimal floating types is based on drafts of
ISO/IEC WDTR 23732, which continues to change. There are some
differences between the most recent draft N1176 and what GCC implements,
and some other things that should probably change or at least be
documented. I'd appreciate
Based purely on context, in the following documentation from:
http://gcc.gnu.org/onlinedocs/gccint/Code-Macros.html#Code-Macros
13.22.2 Code Macros
Code macros operate in a similar way to mode macros. See Mode Macros.
The construct:
(define_code_macro name [(code1 cond1) ... (coden
Based purely on context, in the following documentation from:
http://gcc.gnu.org/onlinedocs/gccint/Code-Macros.html#Code-Macros
13.22.2 Code Macros
Code macros operate in a similar way to mode macros. See Mode Macros.
The construct:
(define_code_macro name [(code1
On 14/06/2006, at 10:47 AM, Mike Stump wrote:
Any suggestions? Does the -isysroot compiler flag fix this sort
of issue? It does not seem to be used in the gcc build.
I'd expect it might. Run with -v and see if isysroot is given to
ld. If not, add -Wl,-isysroot=... to pass it down to
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-06-20 06:04
---
Subject: Bug 27958
Author: fxcoudert
Date: Tue Jun 20 06:04:14 2006
New Revision: 114803
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114803
Log:
2006-06-20 Francois-Xavier Coudert [EMAIL PROTECTED]
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-06-20 06:04
---
Subject: Bug 27784
Author: fxcoudert
Date: Tue Jun 20 06:04:14 2006
New Revision: 114803
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114803
Log:
2006-06-20 Francois-Xavier Coudert [EMAIL PROTECTED]
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2006-06-20 06:04
---
Subject: Bug 27715
Author: fxcoudert
Date: Tue Jun 20 06:04:14 2006
New Revision: 114803
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114803
Log:
2006-06-20 Francois-Xavier Coudert [EMAIL PROTECTED]
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-06-20 06:04
---
Subject: Bug 27895
Author: fxcoudert
Date: Tue Jun 20 06:04:14 2006
New Revision: 114803
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114803
Log:
2006-06-20 Francois-Xavier Coudert [EMAIL PROTECTED]
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-06-20 06:06
---
Subject: Bug 18692
Author: ebotcazou
Date: Tue Jun 20 06:06:50 2006
New Revision: 114804
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114804
Log:
PR ada/18692
* Make-lang.in: Add
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-06-20 06:12
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-06-20 06:13
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2006-06-20 06:14
---
Now also fixed on 4.1.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2006-06-20 06:20
---
Subject: Bug 18692
Author: ebotcazou
Date: Tue Jun 20 06:20:37 2006
New Revision: 114805
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114805
Log:
PR ada/18692
* lib/gnat.exp: New file.
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-06-20 06:24
---
The harness has been installed on mainline.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Hello,
On Mon, 2006-06-19 at 12:31 -0400, Andrew MacLeod wrote:
OK, so I wasn't just wacko last week. Mainline fails to build on Fedora
Core 4 (with all the latest updates, kernel 2111) when built with
checking disabled. Diego verified this on a second FC4 box.
I've narrowed
--- Comment #1 from ayers at gcc dot gnu dot org 2006-06-20 08:45 ---
Subject: Bug 28072
Author: ayers
Date: Tue Jun 20 08:45:08 2006
New Revision: 114808
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114808
Log:
2006-06-20 David Ayers [EMAIL PROTECTED]
PR
--- Comment #2 from ayers at gcc dot gnu dot org 2006-06-20 08:54 ---
Fixed for 4.2.0
--
ayers at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jakub at gcc dot gnu dot org 2006-06-20 09:55 ---
Subject: Bug 26175
Author: jakub
Date: Tue Jun 20 09:55:42 2006
New Revision: 114809
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114809
Log:
PR libgomp/26175
PR libgomp/26477
*
--- Comment #4 from jakub at gcc dot gnu dot org 2006-06-20 09:55 ---
Subject: Bug 26477
Author: jakub
Date: Tue Jun 20 09:55:42 2006
New Revision: 114809
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114809
Log:
PR libgomp/26175
PR libgomp/26477
*
$ cat t.cc
#include cstdio
using namespace std;
namespace ident {
templateclass T void
foo( T*, void* )
{
printf( generic\n );
}
}
using namespace ident;
templateclass T void func( T val )
{
foo( val, (T*)0 );
}
struct Base
{};
struct Deriv : public Base
{};
namespace ident {
--- Comment #13 from rakdver at gcc dot gnu dot org 2006-06-20 10:26
---
Subject: Bug 27331
Author: rakdver
Date: Tue Jun 20 10:26:45 2006
New Revision: 114810
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114810
Log:
PR tree-optimization/27331
* tree-data-ref.c
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-06-20 10:59
---
Confirmed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2006-06-20 11:03
---
I'll take care of that.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
While working on PR 24518, I found the following:
$ cat a.f90
real(kind=10) :: x = 10.0
print *, mod (x,x)
end
$ gfortran a.f90
In file a.f90:3
end
1
Internal Error at (1):
gfc_validate_kind(): Got bad kind
It looks like we're trying to use the integer kind associated with the
--- Comment #15 from tbm at cyrius dot com 2006-06-20 11:56 ---
With this patch applied, I get:
Assembling functions:
Virtual::Virtual()
../../../bug.c: In constructor 'Virtual::Virtual()':
../../../bug.c:1: error: unrecognizable insn:
(insn 8 4 9 2 (set (reg/f:DI 70)
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-06-20 12:22
---
Why exactly aren't we using BUILT_IN_FMOD{F,,L}?
$ cat a.f90
real*8 :: x = 10.0e9
do i = 10, 22
x = 10d0 * x
print '(a,i2,a,g14.8, = ,g14.8)', mod (10**,i,, 1.7_8) = ,
On Tue, 2006-06-20 at 09:48 +0200, Zdenek Dvorak wrote:
Hello,
does this still fail? I have fixed one misscompilation due to this
patch yesterday:
2006-06-19 Zdenek Dvorak [EMAIL PROTECTED]
* tree-ssa-loop-niter.c (implies_ge_p): New function.
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-06-20 13:02
---
Subject: Bug 28052
Author: reichelt
Date: Tue Jun 20 13:02:47 2006
New Revision: 114811
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114811
Log:
PR c++/28052
* init.c (push_base_cleanups):
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-06-20 13:05
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
On Tue, 2006-06-20 at 08:44 -0400, Andrew MacLeod wrote:
On Tue, 2006-06-20 at 09:48 +0200, Zdenek Dvorak wrote:
Hello,
does this still fail? I have fixed one misscompilation due to this
patch yesterday:
2006-06-19 Zdenek Dvorak [EMAIL PROTECTED]
*
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-06-20
13:49 ---
This fixes the problem:
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c (révision 114599)
+++ gcc/fortran/primary.c
--- Comment #16 from rakdver at gcc dot gnu dot org 2006-06-20 14:26
---
Could you please send the .loop2_invariant dump (-dL) ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2006-06-20
14:39 ---
Subject: Re: [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c
execution, -O3 -fomit-frame-pointer -funroll-loops
Attached.
Dave
--- Comment #18 from dave at hiauly1 dot hia dot nrc
We are building cross compiler for sparc-sun-solaris2.9 target.
1) host uname -a is Linux localhost.localdomain 2.6.11-1.14_FC3 #1 Thu Apr 7
19:25:50 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux
2) binutils is configured with ../binutils-2.16.1/configure --target=$TARGET
--prefix=$PREFIX
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c++ |bootstrap
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-20 15:26 ---
*** This bug has been marked as a duplicate of 15082 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-06-20 15:26
---
*** Bug 28097 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from tbm at cyrius dot com 2006-06-20 15:36 ---
Richard, do you think you can take a look since this requires alpha backend
specific knowledge.
--
tbm at cyrius dot com changed:
What|Removed |Added
We are building cross compiler for sparc-sun-solaris2.9 target.
1) host uname -a is Linux localhost.localdomain 2.6.11-1.14_FC3 #1 Thu Apr 7
19:25:50 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux
2) binutils is configured with ../binutils-2.16.1/configure --target=$TARGET
--prefix=$PREFIX
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-20 15:46 ---
*** This bug has been marked as a duplicate of 15082 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-06-20 15:46
---
*** Bug 28098 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15082
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-20 15:57 ---
No, this is invalid, as both Base and Deriv are in the global namespace so the
ident namespace is not looked at again after the parsing of the template. If
either of them were in the ident namespace, GCC will look
1) host uname -a is Linux localhost.localdomain 2.6.11-1.14_FC3 #1 Thu Apr 7
19:25:50 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux
2) binutils is configured with ../binutils-2.16.1/configure --target=$TARGET
--prefix=$PREFIX --disable-nls --with-sysroot=$PREFIX/sysroot
where TARGET is
--- Comment #2 from info at yourkit dot com 2006-06-20 16:38 ---
Actually the problem was solved (in our case) by copying header files from
Solaris machine to $PREFIX/sysroot/usr/include dictory and additing
--with-sysroot=$PREFIX/sysroot to configuration options. Binutils also need
to
--- Comment #2 from jeremy dot gorman at ngc dot com 2006-06-20 16:59
---
Subject: RE: cannot bootstrap x86_64 gcc 4.1.1 from gcc 3.4.5
Thank you,
In this case, which binutil version is required?
Can you refer me to the (fixed) binutil bug that's causing my problem,
please?
-Jeremy
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-20 17:37 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2006-06-20 17:42 ---
Created an attachment (id=11712)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11712action=view)
proposed patch
I've attached a proposed patch.
However, when I use this patch I run into PR 19505.
--
GCC 4.2 on GNU Hurd currently fails to bootstrap with the following error:
cc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-fno-common -DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../sr
c/gcc/.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |target
Keywords||build
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-20 17:50 ---
Why is GNU target including linux.h header at all?
TARGET_C99_FUNCTIONS should be overridden in gnu.h anyways.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--- Comment #19 from jason at gcc dot gnu dot org 2006-06-20 18:12 ---
Changed the summary to clarify, and remove visibility
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
21.3.7.9, p4 requires the operator to set failbit, not badbit, on failure. This
came up while I was gathering background for c++std-lib-17241.
$ cat ~/tmp/t.cpp g++ ~/tmp/t.cpp -static ./a.out
#include cassert
#include cstdio
#include string
#include strstream
int main ()
{
char buf [3];
--- Comment #1 from jason at gcc dot gnu dot org 2006-06-20 18:20 ---
You're telling the compiler that exported_var has default visibility, then
defining a variable called my_exported_var which happens to have the same
symbol. The compiler doesn't unify multiple declarations with the
--- Comment #9 from jason at gcc dot gnu dot org 2006-06-20 18:21 ---
Not a bug; see my earlier comment.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jason at gcc dot gnu dot org 2006-06-20 18:27 ---
This is clearly a bug, since the specialization is not inline and so should not
be affected by -fvisibility-inlines-hidden.
The broader issue here is the question of when #pragma visibility should
override other
--- Comment #1 from tromey at gcc dot gnu dot org 2006-06-20 18:29 ---
Earlier I made a mistake and listed the bugs fixed by ecj
as dependencies; really this PR should block all the fixed-by-ecj
bugs and should depend on bugs that block the merge of the ecj branch.
--
tromey at gcc
sizeof(size_t) on ia32 is 4 thus 2^32 = 4,294,967,296 Byte can be accessed by
unsigned.
real(4), dimension(1025*1024*1024) :: m
can thus not be accessed on ia32. Currently, gfortran does detect this overflow
at compile time.
Expected: The same as ifort:
fortcom: Error: mem.f, line 3: A common
In http://lists.gnu.org/archive/html/bug-tar/2006-06/msg00023.html
Denis Excoffier reports that compiling tar-1.15.91 generates the
following bogus error message on powerpc-apple-darwin8.6.0:
openat.c: In function 'rpl_openat':
openat.c:60: warning: 'mode_t' is promoted to 'int' when passed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-20 19:05 ---
The warning is correct, read the note.
Anyways this is a dup of bug 4210.
*** This bug has been marked as a duplicate of 4210 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-06-20 19:05
---
*** Bug 28106 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from paulthomas2 at wanadoo dot fr 2006-06-20 19:08 ---
Subject: Re: New: Modulo of real(kind=10) variables doesn't
work
fxcoudert at gcc dot gnu dot org wrote:
While working on PR 24518, I found the following:
$ cat a.f90
real(kind=10) :: x = 10.0
print *, mod
--- Comment #1 from pcarlini at suse dot de 2006-06-20 19:09 ---
Thanks Martin.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2006-06-20
19:09 ---
More data: for PR8361 the number of functions in the .gimple dump is 5045, the
number of functions in the cleanup_cfg dump is 1341. The majority of the
functions that are eliminated are small functions,
For the following invalid code snippet
==
struct A
{
union B b;
};
struct B;
==
the C++ frontend generates the following error message:
bug.cc:3: error: field 'b' has incomplete type
bug.cc:6: error: 'struct' tag used in naming 'union B'
While the first
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-20 19:39 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
cse.c:hash_rtx has the same problem as found before in cse.c:cselib_hash_rtx
(PR rtl-optimization/22445). Hence, some optimiztions will only be done
if there is a convenient hash collision.
I.e. the MODE should not be used to calculate the hash value.
--
Summary: Some cse
The following invalid code snippet causes an ICE since GCC 3.4.0:
=
#include typeinfo
struct A;
void foo()
{
A a;
typeid (a);
}
=
bug.cc: In function 'void foo()':
bug.cc:7: error: aggregate 'A a' has incomplete type and
The following invalid code snippet causes an ICE since GCC 4.1.0:
=
templateint struct A {};
templatetypename T struct B
{
templateT I B(AI);
};
Bdouble a=A0();
=
bug.cc: In instantiation of 'Bdouble':
bug.cc:8: instantiated
The following invalid code snippet causes an ICE since at least GCC 2.95.3:
=
templatetypename void foo();
templatetypename T struct A
{
friend void foo(typename T::X);
};
Aint a;
=
bug.cc: In instantiation of 'Aint':
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
The following invalid code snippet causes an ICE since GCC 3.4.0:
===
struct A {} __attribute__((aligned(;)));
===
bug.cc:1: error: expected primary-expression before ';' token
bug.cc:1: error: expected `)'
--- Comment #17 from rth at gcc dot gnu dot org 2006-06-20 20:09 ---
Seems to be bad interactions with the fix for PR26347.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Test g++.dg/ext/altivec-3.C has been failing for mainline on powerpc64-linux
systems without VMX hardware since this patch, a fix for PR20103, was added:
http://gcc.gnu.org/viewcvs?view=revrev=114119
r114119 | mmitchel | 2006-05-25 20:18:26 + (Thu, 25 May 2006)
The test calls a function
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--- Comment #1 from mark at codesourcery dot com 2006-06-20 20:37 ---
Subject: Re: New: vectors initialized in ctors, not at compile
time, cause altivec-3.C failure
janis at gcc dot gnu dot org wrote:
Test g++.dg/ext/altivec-3.C has been failing for mainline on powerpc64-linux
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-20 20:56 ---
(In reply to comment #1)
Ideally, the compiler would recognize that this initialization can be
done statically, but I don't think that the code as written is in any
way guaranteed to do a static initialization.
--
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=28109
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28110
--
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=28112
1 - 100 of 137 matches
Mail list logo
