Jack Howarth [EMAIL PROTECTED] wrote:
What exactly is the implication of having a hundred or more of this in
an application being built with gcc/g++ 4.x at -O3? Does it only risk
random crashes in the generated code or does it also impact the
quality
of the generated code in terms of
J.C. wrote:
*** gcc-4.0-20051124/gcc/config/i386/i386.c Mon Nov 7 18:55:03 2005
--- gcc-4.0-20051201/gcc/config/i386/i386.c Thu Dec 1 01:53:01 2005
! #if defined(HAVE_GAS_HIDDEN) defined(SUPPORTS_ONE_ONLY)
! #if defined(HAVE_GAS_HIDDEN) (SUPPORTS_ONE_ONLY - 0)
Why did he remove
Giovanni,
I'll see what I can do in terms of profiling the xplor-nih code
with Shark on MacOS X. However in the near term, I would strongly
urge the gcc developers to backport the changes necessary to have
-Wstrict-aliasing issue warnings for c++ in gcc 4.1. I rebuilt
xplor-nih under gcc trunk
Shouldn't the compiler behave in the following way, concerning the signedness
of pointer arguments?
void f (long *l, signed long *sl, unsigned long *ul);
// - Make NO assumptions about the signedness of *l and accept long,
//slong and ulong without a warning
// - treat *sl as signed
So, in short, my questions are: is gmp-4.1.4 supposed to work on
ia64-hpux?
No, it is not. It might be possible to get either the LP64 or
the ILP32 ABI to work, but even that requires the workaround you
mention. Don't expect any HP compiler to compile GMP correctly
On Mon, Dec 05, 2005 at 07:57:43AM -0800, Steve Ellcey wrote:
So, in short, my questions are: is gmp-4.1.4 supposed to work on
ia64-hpux?
No, it is not. It might be possible to get either the LP64 or
the ILP32 ABI to work, but even that requires the workaround you
On Mon, Dec 05, 2005 at 03:27:56PM +0100, [EMAIL PROTECTED] wrote:
Shouldn't the compiler behave in the following way, concerning the signedness
of pointer arguments?
void f (long *l, signed long *sl, unsigned long *ul);
long and signed long are the same type. You are confused about how
C
Oh right, what I really meant was 'char' instead of 'long'.
In fact I just took the type from the referenced article. Sorry for that.
So am I right that the compiler should distinguish between char, signed char
and unsigned char in the proposed way?
long and signed long are the same type.
Is there some place where all the existing forms of strict-aliasing
warnings are documented? So far I have only seen the error...
dereferencing type-punned pointer will break strict-aliasing rules
when building c++ code with gcc trunk (4.2). I am wondering how many other
types of warnings
Jack Howarth writes:
My second question is how univeral are the strict-aliasing
rules used by gcc?
They are applicable to every compiler that implements ISO C++. In
other words, code that violates aliasing constrains is not legal C++.
In other words, is it safe to say that by
On Dec 5, 2005, at 12:03 AM, Giovanni Bajo wrote:
Jack Howarth [EMAIL PROTECTED] wrote:
What exactly is the implication of having a hundred or more of this in
an application being built with gcc/g++ 4.x at -O3? Does it only risk
random crashes in the generated code or does it also impact the
Mark Mitchell [EMAIL PROTECTED] writes:
There is one advantage I see in the LTO design over LLVM's design. In
particular, the LTO proposal envisions a file format that is roughly at
the level of GIMPLE. Such a file format could easily be extended to be
at the source-level version of Tree
[EMAIL PROTECTED] (Jack Howarth) writes:
Where exactly are the compiler flags new to gcc 4.1.0 described.
http://gcc.gnu.org/gcc-4.1/changes.html
Ian
On Saturday 03 December 2005 20:43, Mark Mitchell wrote:
There is one advantage I see in the LTO design over LLVM's design. In
particular, the LTO proposal envisions a file format that is roughly at
the level of GIMPLE. Such a file format could easily be extended to be
at the source-level
Steven Bosscher [EMAIL PROTECTED] writes:
| On Saturday 03 December 2005 20:43, Mark Mitchell wrote:
| There is one advantage I see in the LTO design over LLVM's design. In
| particular, the LTO proposal envisions a file format that is roughly at
| the level of GIMPLE. Such a file format
Hi
I have a question. Consider this code:
#include iostream
void global_init();
class A {
public:
int i;
A() : i(10) {
global_init();
}
};
const A obj;
void global_init() {
std::cout obj.i = obj.i std::endl;
}
int main() {
return EXIT_SUCCESS;
}
Here, global_init() is
On Dec 5, 2005, at 11:48 AM, Steven Bosscher wrote:
On Saturday 03 December 2005 20:43, Mark Mitchell wrote:
There is one advantage I see in the LTO design over LLVM's
design. In
particular, the LTO proposal envisions a file format that is
roughly at
the level of GIMPLE. Such a file format
On Dec 4, 2005, at 3:09 PM, Jack Howarth wrote:
I have noticed that there was a significant speed regression in the
c++ code generation between gcc 3.3 and gcc 4.0.x.
Gotta wonder if changing the inlining parameters would help you.
Hello all,
Sorry if this is off-topic; there's not a mailing list described for
this kind of issue.
I have a problem with making an email change for my bugzilla account.
The old email address no longer exists, so bugzilla won't allow me to
update my account to the new email address (because
Mike,
Do you mean using -fno-threadsafe-statics or do you have any other
inlining changes in mind?
Jack
On Mon, Dec 05, 2005 at 07:57:43AM -0800, Steve Ellcey wrote:
So, in short, my questions are: is gmp-4.1.4 supposed to work on
ia64-hpux?
No, it is not. It might be possible to get either the LP64 or
the ILP32 ABI to work, but even that requires the workaround you
On Dec 5, 2005, at 9:53 AM, [EMAIL PROTECTED] wrote:
Oh right, what I really meant was 'char' instead of 'long'.
In fact I just took the type from the referenced article. Sorry for
that.
So am I right that the compiler should distinguish between char,
signed char
and unsigned char in the
On 12/5/05, Chris Lattner [EMAIL PROTECTED] wrote:
That said, having a good representation for source-level exporting is
clearly useful. To be perfectly clear, I am not against a source-
level form, I am just saying that it should be *different* than the
one used for optimization.
Debug
On Mon, 5 Dec 2005, Mike Stump wrote:
On Dec 5, 2005, at 9:53 AM, [EMAIL PROTECTED] wrote:
Oh right, what I really meant was 'char' instead of 'long'.
In fact I just took the type from the referenced article. Sorry for that.
So am I right that the compiler should distinguish between
Has GCC 3.4.5 been officially released? I don't recall seeing an
announcement in gcc@gcc.gnu.org or [EMAIL PROTECTED] and when I
looked on the main GCC page and I see references to GCC 3.4.4 but not
3.4.5. But I do see a 3.4.5 download on the GCC mirror site that I
checked and I see a
Adam Nemet wrote:
Now if I am correct and this last thing is really a bug then the
obvious question is whether it has anything to do with the more
restrictive form for conditional branches on MIPS64? And of course if
I fix it then whether it would be OK to lift the mode restrictions in
the
Mohamed Ghorab wrote:
linux, it tries to compile some files but outputs the following error:
/usr/include/c++/3.2.2/bits/fpos.h:60: 'streamoff' is used as a type,
but is not defined as a type.
This is a more appropriate question for the gcc-help list than the gcc
list. The gcc list is
Eric Weddington wrote:
I have a problem with making an email change for my bugzilla account.
sysadmin requests can be sent to [EMAIL PROTECTED]
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
Steven Bosscher wrote:
On Saturday 03 December 2005 20:43, Mark Mitchell wrote:
There is one advantage I see in the LTO design over LLVM's design. In
particular, the LTO proposal envisions a file format that is roughly at
the level of GIMPLE. Such a file format could easily be extended to be
Shaun Jackman wrote:
The following code snippet produces code that loads a register, r5,
from memory, but never uses the value.
You can report things like this into our bugzilla database, marking them
as enhancement requests. We don't keep track of issues reported to the
gcc list.
I took
Chris Lattner wrote:
I totally agree with Steven on this one. It is *good* for the
representation hosting optimization to be different from the
representation you use to represent a program at source level. The two
have very different goals and uses, and trying to merge them into one
On Dec 5, 2005, at 5:27 PM, Mark Mitchell wrote:
Steven Bosscher wrote:
IMVHO dumping for export and front-end tools and for the optimizers
should not be coupled like this. Iff we decide to dump trees, then I
would hope the dumper would dump GIMPLE only, not the full front end
and middle-end
On Dec 5, 2005, at 5:43 PM, Mark Mitchell wrote:
Chris Lattner wrote:
I totally agree with Steven on this one. It is *good* for the
representation hosting optimization to be different from the
representation you use to represent a program at source level.
The two
have very different goals
Chris Lattner wrote:
[Up-front apology: If this thread continues, I may not be able to reply
for several days, as I'll be travelling. I know it's not good form to
start a discussion and then skip out just when it gets interesting, and
I apologize in advance. If I'd been thinking better, I would
The m32c-elf port uses PSImode for pointers, which, for m32c (vs m16c)
only have 24 bits of precision in a 32 bit word. The address
registers are 24 bit unsigned registers.
The -1 sentinal used for CTOR_LIST is not a representable address,
and the code gcc ends up using compares 0x (the
The -1 sentinal used for CTOR_LIST is not a representable address,
and the code gcc ends up using compares 0x (the -1) with
0x00ff (what ends up in $a0) and it doesn't match.
Suggestions?
Use ELF .init_array/.fini_array
Paul
Steve Ellcey [EMAIL PROTECTED] writes:
| Has GCC 3.4.5 been officially released?
Yes, tarballs are on gcc.gnu.org and ftp.gnu.org since Dec 1st. Only
official announcement is missing.
[...]
| I also notice we have a Releases link under About GCC in the top
| left corner of the main GCC page
Steve Ellcey [EMAIL PROTECTED] writes:
| Has GCC 3.4.5 been officially released?
Yes, tarballs are on gcc.gnu.org and ftp.gnu.org since Dec 1st. Only
official announcement is missing.
What are you waiting for?
--
Kaveh R. Ghazi [EMAIL PROTECTED]
I want to warn at the use of unadorned NULL as sentinel value in C
programs. Why is this option (-Wstrict-null-sentinel) restricted to
C++ programs? Or is there some other way to get this warning?
-chris
(Please 'cc'; not subscribed)
Steven Bosscher wrote:
What makes EDG so great is that it represents C++ far closer to the
actual source code than G++ does.
I know the EDG front-end very well; I first worked with it in 1994, and
I have great respect for both the EDG code and the EDG people.
I disagree with your use of far
hi mark,
On Mon, 2005-12-05 at 21:33 -0800, Mark Mitchell wrote:
I'm not saying that having two different formats is necessarily a bad
thing (we've already got Tree and RTL, so we're really talking about two
levels or three), or that switching to LLVM is a bad idea, but I don't
think there's
--- Comment #7 from jakub at gcc dot gnu dot org 2005-12-05 08:02 ---
Subject: Bug 13384
Author: jakub
Date: Mon Dec 5 08:02:53 2005
New Revision: 108045
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108045
Log:
PR c/13384
* gcc.dg/gomp/atomic-5.c: Adjust.
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2005-12-05 08:10
---
Present on SPARC too.
Dorit, the 3 loops are now vectorized because of versioning despite the target
being vect_no_align. Can we adjust the dg commands?
--
ebotcazou at gcc dot gnu dot org changed:
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
The newly integrated libdecnumber requires a few C99 integer types, thus
causing bootstrap failures on non-C99 platforms like Solaris 2.5.1. The
problem already occured for libfortran and has been addressed by a kludge
there.
It could be deemed desirable to have something along the lines of
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|paolo dot bonzini at lu dot |bonzini at gnu dot org
|unisi dot ch|
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2005-12-05 08:52
---
Explicitly confirmed on SPARC if that matters. We should not segfault though.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from falk at debian dot org 2005-12-05 09:02 ---
(In reply to comment #4)
It is NOT a problem of GCC
OK, let's close it, then.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #1 from bonzini at gnu dot org 2005-12-05 09:09 ---
Created an attachment (id=10406)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10406action=view)
patch sketch
A very experimental (not even built, let alone bootstrapped/regtested) patch
--
Compiling:
templateclass T
class A
{
public:
static const unsigned int n = 1;
void foo ()
{
int i = n;
}
};
extern template class Aint;
int main ()
{
Aint a;
a.foo ();
}
fails with:
foo.cpp: In member function 'void AT::foo() [with T = int]':
foo.cpp:9: instantiated
As mentioned in my http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00035.html
mail, nested function calls in #pragma omp parallel blocks are still broken
(for all of C/C++/Fortran and at least in Fortran they are part of the
standards) and I'm even not sure what the exact semantics should be for them
--- Comment #3 from dorit at il dot ibm dot com 2005-12-05 11:11 ---
Dorit, the 3 loops are now vectorized because of versioning despite the target
being vect_no_align. Can we adjust the dg commands?
yes, that's exactly what the patch I sent in Comment #1 does.
I guess I can commit
--- Comment #21 from jakub at gcc dot gnu dot org 2005-12-05 11:14 ---
Subject: Bug 15809
Author: jakub
Date: Mon Dec 5 11:14:10 2005
New Revision: 108052
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108052
Log:
PR fortran/15809
* trans-decl.c
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2005-12-05 11:20
---
yes, that's exactly what the patch I sent in Comment #1 does.
Oops, sorry!
I guess I can commit it as an obvious fix. I'll go ahead and do that.
Please commit it on both mainline and 4.1 branch. Thanks.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-05 11:23 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Hi!
The test program (below) kills latest gfortran:
[EMAIL PROTECTED] fem]$ gfortran -v test.f90
Driving: gfortran -v test.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc
Using built-in specs.
Target: i386-linux
Configured with: ../gcc/configure --prefix=/tmp/gfortran-20051205/irun
--enable
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-05 11:31 ---
Confirmed, looks very much related to PR 18197.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from thebohemian at gmx dot net 2005-12-05 11:34 ---
aph, this would be your test case right?
class T {
void fail(){
System.out.println(fail-0);
M m = new M();
System.out.println(fail-1);
m.test();
}
}
// Bytecode removed
class M {
void
The following code snippet causes an ICE in the C++ frontend on mainline:
===
int x[1/0];
===
bug.cc:1: warning: division by zero in '1 / 0'
bug.cc:1: error: size of array 'x' is not an integral constant-expression
bug.cc:1: internal compiler error: tree check: expected
--- Comment #26 from thebohemian at gmx dot net 2005-12-05 11:52 ---
Created an attachment (id=10407)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10407action=view)
updated test setup
Added two more tests:
invokeMethodIndirect1
invokeMethodIndirect2
A new class
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from reichelt at gcc dot gnu dot org 2005-12-05 11:54
---
Btw, this is a regression from GCC 4.0.0 to GCC 4.0.1.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-05 11:56 ---
Confirmed, this is a latent bug in the C++ front-end.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Hi!
The following program
program a
character(len=10) :: str
str = '123'
write( str, '(a,i1)' ) trim(str),4
print*,str
end program a
outputs
[EMAIL PROTECTED] fem]$ gfortran -o a a.f90; ./a
4
all other compilers i've tried (sun f90, xlf, g95, ifort) seem to agree the
output
--- Comment #12 from reichelt at gcc dot gnu dot org 2005-12-05 13:09
---
Subject: Bug 23307
Author: reichelt
Date: Mon Dec 5 13:09:17 2005
New Revision: 108054
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108054
Log:
Backport:
2005-10-13 Mark Mitchell
--- Comment #13 from reichelt at gcc dot gnu dot org 2005-12-05 13:12
---
Subject: Bug 22464
Author: reichelt
Date: Mon Dec 5 13:12:29 2005
New Revision: 108055
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108055
Log:
Backport:
2005-10-13 Mark Mitchell
--- Comment #13 from reichelt at gcc dot gnu dot org 2005-12-05 13:14
---
Now also fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from reichelt at gcc dot gnu dot org 2005-12-05 13:14
---
Now also fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #27 from thebohemian at gmx dot net 2005-12-05 13:52 ---
I changed the PR's title to reflect more clearly what it is about.
This is about *missing* classes not about methods and fields which have been
removed, changed or whatever.
--
thebohemian at gmx dot net changed:
Imagine the following situation:
class T {
void test(){
M.staticMethod(); // a
new M().method(); // b
M.staticField = FOO; // c
new M().field = FOO; // d
}
}
class M{
static void staticMethod(){}
void method(){}
static String staticField;
String field;
--- Comment #1 from thebohemian at gmx dot net 2005-12-05 14:03 ---
Created an attachment (id=10408)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10408action=view)
test setup
A test setup for the above mentioned 4 cases. There are three scripts which
runs different interpreters:
--- Comment #3 from dorit at il dot ibm dot com 2005-12-05 14:17 ---
Dorit, is it only a matter of changing the expected error message?
Yes - the error message checks that the vectorizer detected that it's not worth
while to vectorize the loop because all operations in the loop are
On both
gcc (GCC) 3.3.5 (propolice)
and
gcc.exe (GCC) 3.4.2 (mingw-special)
the following code does not work properly.
Its output should be test1nltest2nltest3nl, but the 3rd output gets
malformed.
It seems to me the stack is unwindded too far by sjlj-eh at the entrance of
catch block and the
--- Comment #2 from thebohemian at gmx dot net 2005-12-05 14:37 ---
Created an attachment (id=10409)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10409action=view)
test setup
Same as above but fixed the messages about expected and unexpected Throwables.
--
thebohemian at gmx
Hello,
Consider this code that implements hton and ntoh for float values :
//main.cpp
#include stdio.h
#include netinet/in.h
inline float hton(float x)
{
const size_t nb32 = sizeof(float)/sizeof(uint32_t);
const size_t nb16 = (sizeof(float)/sizeof(uint16_t))%2;
uint32_t* p32 =
--- Comment #1 from pierre dot chatelier at club-internet dot fr
2005-12-05 15:04 ---
please consider *p16 = htons(*p16) instead of *p16 = htonl(*p16), but the
problem remains the same.
--
pierre dot chatelier at club-internet dot fr changed:
What|Removed
long long
foo (long long x, int y)
{
unsigned long long x0 = (unsigned long long) x, x1;
long long a = x0 ((y - 4) 63);
if ((a 8) == 0)
y--;
x1 = x ((24 - y) 63);
return (x1 1);
}
ICEs at -m31 {-O1,-O2,-O3} on s390-linux.
--
Summary: ICE on lshrdi3_31 pattern
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-05 15:23 ---
You are violating C/C++ aliasing rules:
inline float hton(float x)
uint32_t* p32 = (uint32_t*)(x);
You are accessing a float through a uint32_t.
*** This bug has been marked as a duplicate of 21920 ***
--- Comment #79 from pinskia at gcc dot gnu dot org 2005-12-05 15:23
---
*** Bug 25267 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Dear gcc-bugs@gcc.gnu.org,
Your question was not submitted to the helpdesk because of a problem:
You need to register online at http://ccgi.rowley.co.uk/support/ before you
can submit new questions via e-mail.
Why is this? To provide better tracking of user issues and because we need to
--- Comment #3 from danglin at gcc dot gnu dot org 2005-12-05 17:10 ---
Fixed by patch to binutils. See
http://sourceware.org/ml/binutils/2005-12/msg00030.html.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from reichelt at gcc dot gnu dot org 2005-12-05 17:16
---
Taking care of the backport.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from bonzini at gnu dot org 2005-12-05 17:21 ---
Patch applied to mainline. I will ask for 4.1 approval in a few days, most
likely at the beginning of next week.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2005-12-05 18:01 ---
This part is done:
http://gcc.gnu.org/ml/libstdc++/2005-11/msg00240.html
can also go in mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24693
--- Comment #9 from reichelt at gcc dot gnu dot org 2005-12-05 18:01
---
Subject: Bug 22352
Author: reichelt
Date: Mon Dec 5 18:01:05 2005
New Revision: 108066
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108066
Log:
Backport:
2005-10-13 Mark Mitchell [EMAIL
--- Comment #10 from reichelt at gcc dot gnu dot org 2005-12-05 18:01
---
Now also fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|gcc.dg/compat/vector- |[3.4 only]
|[12]_y.c fails to compile
--- Comment #7 from steven at gcc dot gnu dot org 2005-12-05 18:05 ---
Created an attachment (id=10410)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10410action=view)
follow SSA_NAME_VALUE deep
Hmmwell, the attached patch does bootstrap on i686,ia64, and x86-64, and it
passes
--- Comment #8 from law at redhat dot com 2005-12-05 18:18 ---
Subject: Re: [4.1/4.2 Regression] Jump
threading opportunity missed in tree-ssa but caught in jump1
On Mon, 2005-12-05 at 18:05 +, steven at gcc dot gnu dot org wrote:
--- Comment #7 from steven at gcc
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-05 18:23 ---
Hmm, I think we should ignore the -POINTER + 1 case as that would give use the
wrong results sometimes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22524
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-05 18:30 ---
gcc/gcc/testsuite/gcc.c-torture/execute/990604-1.c fails the same way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23166
--- Comment #11 from berndtrog at yahoo dot com 2005-12-05 18:34 ---
Compiling of usart.i still fails:
usart.c: In function 'UsartIOCtl':
usart.c:821: error: unable to find a register to spill in class
'BASE_POINTER_REGS'
usart.c:821: error: this is the insn:
(insn 663 162 163 14 (set
I have not looked into this testcase that much but I may as well file it so
that I don't lose track of it.
Anyways gcc.target/x86_64/abi/test_passing_unions.c fails with:
/home/pinskia/src/types/gcc/gcc/testsuite/gcc.target/x86_64/abi/test_passing_unions.c:
In function 'main':^M
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-05 18:46 ---
gcc.target/x86_64/abi/test_passing_integers.c fails the same way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25269
Filing it here so it does not get lost (I will reduce this later).
The error message is:
/home/pinskia/src/types/gcc/gcc/testsuite/gfortran.dg/array-1.f90: In function
'pack':^M
/home/pinskia/src/types/gcc/gcc/testsuite/gfortran.dg/array-1.f90:23: error:
types mismatch in comparsion^M
int8D.8^M
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2005-12-05 18:53
---
Subject: Bug 24108
Author: ebotcazou
Date: Mon Dec 5 18:53:04 2005
New Revision: 108067
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108067
Log:
PR tree-optimization/24963
*
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2005-12-05 18:53
---
Subject: Bug 18580
Author: ebotcazou
Date: Mon Dec 5 18:53:04 2005
New Revision: 108067
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108067
Log:
PR tree-optimization/24963
*
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2005-12-05 18:53
---
Subject: Bug 24963
Author: ebotcazou
Date: Mon Dec 5 18:53:04 2005
New Revision: 108067
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108067
Log:
PR tree-optimization/24963
*
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-05 18:53 ---
gfortran.dg/array_alloc_2.f90 fails the same way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25270
--- Comment #33 from berndtrog at yahoo dot com 2005-12-05 18:53 ---
Compiling test.c with 4.1.0 20051202 or 4.2.0 20051202 works OK.
Compiling test.c with 4.0.3 20051123 still fails:
test.c: In function 'test':
test.c:46: error: unable to find a register to spill in class
1 - 100 of 142 matches
Mail list logo
