Mark Mitchell [EMAIL PROTECTED] wrote:
As I've indicated before, I'm not pleased with this situation either.
It was as much a surprise to me as anyone. There is no question that
this change is not in keeping with our branch policy.
[...]
Also, at the time these changes were suggested for
Gerald Pfeiffer wrote:
Personally, and explicitly not speaking for my employer, I fully agree
with Andrew Pinski that this kind of change is not appropriate for GCC
4.1 at this point in the release cycle.
It is clearly against our development model and negatively impacts our
schedule and
On 2/3/06, Perry Smith [EMAIL PROTECTED] wrote:
On Feb 3, 2006, at 1:52 PM, Joe Buck wrote:
On Fri, Feb 03, 2006 at 07:56:23PM +0100, andrzej wrote:
Hello,
I am sorry if this is the wrong address for tihis question, but I
couldn't find any other.
In the manual pages I couldn't find
Giovanni Bajo writes:
Giovanni This is a little unfair, though. So now the burden on enforcing the
policy is
Giovanni not on the maintainers that prepare the patches? The people involved
in this
Giovanni change have been working on GCC much longer than those who (later)
objected.
Giovanni
Couldn't find anything on it in bugzilla, and I don't think it's worth
the effort. IIRC, Herb Sutter and another guy spent 6 months to get it
right in the EDG front end (and Herb originally wanted to throw export
for templates out of the standard alltogether).
--
Tarjei
The
Giovanni Bajo wrote:
This is a little unfair, though. So now the burden on enforcing the policy is
not on the maintainers that prepare the patches?
No, that burden falls on the Release Manager. However, the SC has also
given me considerable latitude to exercise my judgement, which I did. I
Giovanni Bajo writes:
Giovanni This is a little unfair, though. So now the burden on enforcing the
policy is
Giovanni not on the maintainers that prepare the patches? The people
involved in this
Giovanni change have been working on GCC much longer than those who (later)
objected.
Mark Mitchell wrote:
it misses the point that many important resources in GCC are being used in
fixing and testing this new feature, instead of putting GCC in shape for the
release. So the release has been already delayed because of this, and will be
even more. That's something which already
Andrew Pinski writes:
Andrew Your attitude towards Joern's request for help with a regression was
really
Andrew what got my over the board. Your suggestion that a primary target was
more
Andrew important even for an enhancement matter than over a regression was
really
Andrew out of line.
* If GCC 4.1.0 does not support the new ABI, but GCC 4.1.1 does support
that, would it be possible to activate the support on the GLIBC 2.4 branch?
This is not an option. When glibc 2.4 is released, the GLIBC_2.4 version
set will never change again. Each platform will either change by the
Ryan Mansfield [EMAIL PROTECTED] writes:
| Couldn't find anything on it in bugzilla, and I don't think it's worth
| the effort. IIRC, Herb Sutter and another guy spent 6 months to get it
| right in the EDG front end (and Herb originally wanted to throw export
| for templates out of the
Roland McGrath wrote:
* If GCC 4.1.0 does not support the new ABI, but GCC 4.1.1 does support
that, would it be possible to activate the support on the GLIBC 2.4 branch?
This is not an option. When glibc 2.4 is released, the GLIBC_2.4 version
set will never change again. Each platform will
and that paper was debunked when it was presented at the ISO C++
committee in April 2003 at Oxford, UK. EDG is very willing to give
advice (based on their experience) to anyone interested in
implementing export in, say GCC. (They want to see the best
implementation of export for C++.)
--
Ryan Mansfield [EMAIL PROTECTED] writes:
| and that paper was debunked when it was presented at the ISO C++
| committee in April 2003 at Oxford, UK. EDG is very willing to give
| advice (based on their experience) to anyone interested in
| implementing export in, say GCC. (They want to see
Hi,
One of the thing I've learnt over the week-end is that the option
code confusion
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00326.html
is partly caused by a conflicting interests between -fconst-strings
and -Wwrite-strings. The former has been deprecated for a long time
now. I
Joseph S. Myers [EMAIL PROTECTED] writes:
| On Mon, 6 Feb 2006, Gabriel Dos Reis wrote:
|
| Hi,
|
|One of the thing I've learnt over the week-end is that the option
| code confusion
|
| http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00326.html
|
| is partly caused by a
Hi,
I'm wondering whether the precompiled headers tests are ok for
mips-elf-gcc 3.4.4 on cygwin. When I run the testsuite for
mips-elf-gcc on cygwin using such command,
make check-gcc RUNTESTFLAGS=pch.exp
The errors are like these following. It seems that there is no
common-1.h at all.
In
Hi,
I am trying to map an elf section to absolute address. Is there any way
that we can restrain the linker (ld) not to relocate a section and place
it at an absolute address.
I have tried placing the absolute address in the Sh_Addr and updating
the section name as SH_ABS. But it was of no use.
Hi,
I am trying to map an elf section to absolute address. Is there any way
that we can restrain the linker (ld) not to relocate a section and place
it at an absolute address.
I have tried placing the absolute address in the Sh_Addr and updating
the section name as SH_ABS. But it was of no use.
Prior to the 4.* series compilers, the following code :
char tell_endian()
{
unsigned x = 1;
return *(char*)x;
}
... used to produce a simple contant load to a register and return. The 4.x
compilers seem like they can no longer make this optimization. It used to be
very convenient
gcc -o test.bin 2_1.cpp -w
test.bin
echo 127
127
Function main() must return 383, but return 127
cat 2_1.cpp
int main(){
unsigned x = 255, smallest, ripple, ones;
smallest = x -x;
ripple = x + smallest;
ones = x ^ ripple;
ones = (ones 2) / smallest;
return ripple |
there is a bug in avr-gcc (GCC) 3.4.5, that comes with the latest WinAVR
distribution (20060125).
The avr-gcc (GCC) 3.4.3, that comes with WinAVR 20050214 does NOT contain this
bug.
The bug exists with and without optimization (I tried -O0 and -Os)
If you try to copy a structure with
--- Comment #1 from cajus dot hahn at de dot abb dot com 2006-02-06 09:18
---
Created an attachment (id=10783)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10783action=view)
Complete project.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26118
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-02-06 09:34
---
Confirmed.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-02-06 09:40
---
I don't get a segfault, but the error message:
bug.cc:11: internal compiler error: vector VEC(eh_region,base) index domain
error, in can_throw_internal_1 at except.c:2580
Looks like a duplicate of PR 26076 to
--- Comment #1 from falk at debian dot org 2006-02-06 10:04 ---
The return value of main() is interpreted in an implementation-defined way by
the
OS. Your OS (which you failed to mention) probably crops it to 7 bit. So this
is
not a gcc bug.
--
falk at debian dot org changed:
In Mac OSX ver. 10.3, I got following internal compiler error.
$ gfortran --version
GNU Fortran 95 (GCC) 4.2.0 20060129 (experimental)
Copyright (C) 2006 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
The following two build commands yield executables with different mudflap
behavior, which seems like a bug to me:
g++ -c -fmudflap -o hello.o hello.cpp ; g++f4 -o hello hello.o -lmudflap
g++ -fmudflap -o hello hello.cpp -lmudflap
Here's the source for hello.cpp:
#include stdio.h
#include
--- Comment #1 from idht4n at hotmail dot com 2006-02-06 10:22 ---
In my original report, g++f4 is the same as g++ and are both svn 2006-02-03
versions. Sorry for any confusion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26120
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-02-06 10:34 ---
*** Bug 26116 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-02-06 10:34 ---
*** This bug has been marked as a duplicate of 26069 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from martin at mpa-garching dot mpg dot de 2006-02-06 11:15
---
(In reply to comment #3)
I don't get a segfault, but the error message:
bug.cc:11: internal compiler error: vector VEC(eh_region,base) index domain
error, in can_throw_internal_1 at except.c:2580
I
--- Comment #3 from hp at gcc dot gnu dot org 2006-02-06 11:50 ---
Confirmed for mmix-knuth-mmixware, cris-axis-elf and cris-axis-linux-gnu,
passes with 110520, fails with 110613.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hp at gcc dot gnu dot org 2006-02-06 11:51 ---
Confirmed for mmix-knuth-mmixware, cris-axis-elf and cris-axis-linux-gnu,
passes with 110520, fails with 110613.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
The following invalid code snippet is accepted by GCC since at least
GCC 2.95.3:
struct A
{
templateint void foo() = 0;
};
A similar code snippet causes an ICE since GCC 4.0.0:
When compiled with:
g++-4.0 -g -Wall -c -o try.o try.cc
g++-4.0 -g -Wall -c -o foo.o foo.cc
g++-4.0 -g -Wall -o try try.o foo.o
the program below creates a segmentation fault.
UNIX gdb ./try
(gdb) r
Starting program: /data/home/osb/temp/clcpp/try
Program received signal SIGSEGV,
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-06 12:46 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
When compiled with:
g++-4.0 -g -Wall -c -o try.o try.cc
g++-4.0 -g -Wall -c -o foo.o foo.cc
g++-4.0 -g -Wall -o try try.o foo.o
the program below creates a segmentation fault.
UNIX gdb ./try
(gdb) r
Starting program: /data/home/osb/temp/clcpp/try
Program received signal SIGSEGV,
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-06 12:51 ---
*** This bug has been marked as a duplicate of 26123 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-06 12:51 ---
*** Bug 26124 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26123
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-06 12:54 ---
foo.cc has nothing to do with the problem here. It all has to do with the
order of the execution of the initializers.
The following code is enough to reproduce the issue:
int mkCint();
const int cInt = mkCint();
Executing on host: /test/gnu/gcc-4.1/objdir/gcc/testsuite/../g++
-B/test/gnu/gcc
-4.1/objdir/gcc/testsuite/../
/test/gnu/gcc-4.1/gcc/gcc/testsuite/g++.dg/opt/com
plex5.C -nostdinc++
-I/test/gnu/gcc-4.1/objdir/hppa2.0w-hp-hpux11.11/libstdc++-
v3/include/hppa2.0w-hp-hpux11.11
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-06 12:56 ---
Confirmed, though I don't know if this is just undefined code or not. Also the
global initializer between 3.3 and 3.4 (and 4.0/4.1/4.2) did not change so I
don't think this is a front-end bug.
--
pinskia at gcc
--
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-02-06 13:01 ---
It worked in 4.1.0 20051026.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26120
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2006-02-06
13:02 ---
Subject: Re: New: g++.dg/opt/complex5.C:11: ICE: Segmentation fault
The test was ok on 20060203:
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00222.html
Dave
--
--- Comment #4 from pcarlini at suse dot de 2006-02-06 13:10 ---
For some reason, on x86-linux, I can reproduce only with 3.4 and 4.0, not with
mainline and 4.1...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26123
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-06 13:13 ---
Oh, I was using 4.0.2's shared library still when testing, woops.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-06 13:14 ---
Confirmed, I only get the failures on powerpc-darwin and not on
x86_64-linux-gnu for some reason.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pcarlini at suse dot de 2006-02-06 13:16 ---
Ok. mainline is also confirmed fine on ia64-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26123
--- Comment #8 from ghazi at gcc dot gnu dot org 2006-02-06 13:49 ---
Subject: Bug 13906
Author: ghazi
Date: Mon Feb 6 13:49:41 2006
New Revision: 110642
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110642
Log:
include:
Backport:
2006-01-18 DJ Delorie
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-06 13:51 ---
Assigning to Paul based on a request made in a private email.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
There are a couple of minor errors in tr1/hashtable that cause some of the
rarely-instantiated members defined in TR1
(http://open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf) not to compile,
eg:
std::tr1::unordered_set int s;
s.key_eq();// Not declared:
// error: 'class
--- Comment #4 from bonzini at gnu dot org 2006-02-06 14:06 ---
More precisely, combine is attempting to do instruction selection, and in the
case of this bug it cannot.
A similar ARM test case is
int f (int a, int b)
{
int s = a - b;
int t = a b ? a : s;
x = s;
y
--- Comment #9 from ghazi at gcc dot gnu dot org 2006-02-06 14:06 ---
Subject: Bug 13906
Author: ghazi
Date: Mon Feb 6 14:06:55 2006
New Revision: 110643
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110643
Log:
include:
Backport:
2006-01-18 DJ Delorie [EMAIL
--- Comment #10 from ghazi at gcc dot gnu dot org 2006-02-06 14:07 ---
Fix backported to 3.4 and 4.0.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from chris at bubblescope dot net 2006-02-06 14:19 ---
Yep, these both look like fairly obvious errors to me.
--
chris at bubblescope dot net changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-06 14:33 ---
Most of them will be fixed by:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00447.html
(I Had forgot the tree-outof-ssa.c variable when I submitted the patch).
--
pinskia at gcc dot gnu dot org changed:
--
pcarlini at suse dot de changed:
What|Removed |Added
CC||pcarlini at suse dot de
Status|UNCONFIRMED |NEW
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-06 14:33 ---
Most of them will be fixed by:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00447.html
I still have to decide if we want to remove ggc_stats or not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25547
--- Comment #2 from aplatovsky at mail dot ru 2006-02-06 14:41 ---
.
--
aplatovsky at mail dot ru changed:
What|Removed |Added
Status|RESOLVED
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-06 14:51 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00139.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
char a[16] __attribute__((aligned)) = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12,
13, 14, 15, 16};
char b[16] __attribute__((aligned)) = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12,
13, 14, 15, 16};
char c[16] __attribute__((aligned));
int i;
for(i = 0; i16; i++)
{
c[i] = a[i] + b[i];
}
for(i =
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-06 15:00 ---
Actually this is a known regression and a missed optimization regression caused
by fixing up wrong code.
The work around is to use -fwrapv.
--
pinskia at gcc dot gnu dot org changed:
What
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/g++/../../g++
-B/mnt/gn
u/gcc-3.3/objdir/gcc/testsuite/g++/../../
/mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++
.dg/init/ctor4.C -nostdinc++
-I/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/li
bstdc++-v3/include/hppa2.0w-hp-hpux11.11
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-06 15:02 ---
This is a dup of bug 26114.
*** This bug has been marked as a duplicate of 26114 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-06 15:02 ---
*** Bug 26129 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/g++/../../g++
-B/mnt/gn
u/gcc-3.3/objdir/gcc/testsuite/g++/../../
/mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++
.dg/parse/register1.C -nostdinc++
-I/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.
11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
The TR1 specification of insert(iterator, value_type) on unordered associative
containers states that it returns an iterator (as for ordered associative
containers). However the current implementation returns
std::pairiterator,bool instead in the case of unique keys.
Patch to follow.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-06 15:05 ---
*** This bug has been marked as a duplicate of 26115 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-06 15:05 ---
*** Bug 26130 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-02-06 15:07 ---
I think this is undefined. Reduced testcase:
extern C void *malloc(__SIZE_TYPE__ n);
int mkCint();
const int cInt = mkCint();
struct Ptr {
Ptr() { ptr = (int *)malloc(sizeof(int)); }
int *ptr;
};
Ptr p;
int
Attempting to call rehash produces a link error:
std::tr1::unordered_set int s;
s.rehash(42);
// undefined reference to `std::tr1::hashtableint, int, std::allocatorint,
// Internal::identityint, std::equal_toint, std::tr1::hashint,
// Internal::mod_range_hashing, Internal::default_ranged_hash,
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-02-06 15:13 ---
Dom - Jeff.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-02-06 15:14
---
Btw, we also fail to diagnose the following invalid code snippet:
=
templateint struct A
{
void foo() = 0;
};
=
--
--- Comment #1 from pcarlini at suse dot de 2006-02-06 15:16 ---
This is already fixed for mainline and 4.1.0, will not fix in 4_0-branch.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from zak at transversal dot com 2006-02-06 15:18 ---
Sorry, my mistake -- I thought I had checked this on both.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26131
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
unique_copy is overloaded on forward- and output_iterators for the result
iterator; the output_iterator version requires Assignability on the input's
value_type, which isn't required by the resolution to DR #241:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241
I'll attach a
--- Comment #1 from squell at alumina dot nl 2006-02-06 15:36 ---
Created an attachment (id=10784)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10784action=view)
Test case
Test case; the output should be 23.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26133
--- Comment #2 from kargl at gcc dot gnu dot org 2006-02-06 15:54 ---
I've see this on amd64-*-freebsd. A brief debug session
is described here.
http://gcc.gnu.org/ml/fortran/2006-01/msg00413.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26119
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-06 16:17 ---
the load PRE issue has been fixed but DOM does not thread the jump for some
reason.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21417
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-06 16:19 ---
(In reply to comment #2)
We should be able to create a PHI for this case.
Hmm, maybe I don't understand load PRE but for some reason I thought it would
be able to do this case:
This load PRE issue has been
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-02-06
16:22 ---
Subject: Re: [4.1 Regression] g++.dg/opt/complex5.C:11: ICE: Segmentation
fault
Dom - Jeff.
I haven't checked this but it appears from the timing that Jason's
change on 2006-02-03 introduced the
--- Comment #6 from dtemirbulatov at gmail dot com 2006-02-06 16:51 ---
Created an attachment (id=10787)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10787action=view)
proposed patch
Can anybody do a regression hunt on mainline?
I found original fix on the mainline. it is
--- Comment #6 from gianni at mariani dot ws 2006-02-06 16:52 ---
Just another data point.
I tried both the original tell_endian() and the tell_endian_good() functions on
the MS Visual Studio 2003 compiler and both generated:
?tell_endian@@YADXZ:
0: b0 01
I was looking at some code which is mentioned to be in SPEC 2006 (I forgot
where I found the mentioning)
but anyways it has the following in it:
typedef _Complex float COMPLEX_FLOAT;
float real_part(COMPLEX_FLOAT a)
{
return *(float*)(a);
}
This should be converted to:
float
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-06 16:58 ---
I am taking care of this one and the __imag__ part too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-02-06 17:05
---
The testcase also crashes on x86_64-unknown-linux-gnu with -O -m32:
complex5.C: In function 'double __complex__ elt_zero()':
complex5.C:11: error: statement makes a memory store, but has no V_MAY_DEFS nor
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-06 17:07 ---
(In reply to comment #4)
The testcase also crashes on x86_64-unknown-linux-gnu with -O -m32:
That exactly the same ICE at which the testcase was ICE before I fixed it the
first time. I wonder why my fix no longer
--- Comment #7 from tony dot linthicum at amd dot com 2006-02-06 17:13
---
So do I, at least for the original code (i.e. test and test1). I'm curious,
though, if you've tried the example that I listed above (foo). I still get
subregs with that one, though I honestly don't recall at
For (-O2 -fno-tree-dominator-opts -fno-tree-salias -fno-tree-sra)
int foo(int i)
{
struct { int i; int j; } a;
a.i = i;
return a.i;
}
store copyprop does not propagate i to the return stmt.
--
Summary: store copyprop not effective
Product: gcc
Version:
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-02-06 17:36 ---
And I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-06 17:45 ---
This actually does not help the benchmark right away because we have:
static inline float
quantum_real(float _Complex a)
{
float *p = (float *) a;
return p[0];
}
static inline float
quantum_imag(float _Complex
--- Comment #14 from r dot emrich at de dot tecosim dot com 2006-02-06
17:58 ---
Subject: Re: libgfortran build failure on mips-sgi-irix6.5
Okay, I will try!
Is there a preprocessor macro defined, which identifies IRIX?
As I see, there are two macros which are candidates IMHO:
--- Comment #15 from Ralf dot Wildenhues at gmx dot de 2006-02-06 18:24
---
(In reply to comment #8 by H. J. Lu)
See
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02467.html
I don't know how to do --disable-fast-install for gcc.
--enable-fast-install is totally wrong for ELF. It
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-02-06 18:30
---
Here is the backtrace for this bug:
Program received signal SIGSEGV, Segmentation fault.
0x080a4583 in gfc_conv_scalarized_array_ref (se=0xbfaf2924, ar=0x86f5d0c)
at
--- Comment #4 from mckinlay at redhat dot com 2006-02-06 18:38 ---
You might need a multiprocessor or hyper-threaded machine to reproduce it. I
was able to reproduce it with HEAD just now:
$ while (true) do gij GCTest; done
[20]: Success
java.lang.LinkageError: field type
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-02-06 18:39
---
Subject: Bug 23359
Author: pinskia
Date: Mon Feb 6 18:39:30 2006
New Revision: 110657
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110657
Log:
2006-02-06 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #5 from mckinlay at redhat dot com 2006-02-06 18:41 ---
Another example of failure:
[5]: Success
java.lang.NullPointerException
at GCTest.testObjChain (GCTest.java:251)
at GCTest.testObjArray (GCTest.java:191)
at GCTest.run (GCTest.java:104)
at
1 - 100 of 173 matches
Mail list logo
