I've posted the results of last night's build of gcc trunk
on my dual G5 using Geoff's TImode patch and changes to
prune.exp to suppress the failures from the ld64 linker
warnings.
Jack
Eric,
Does the following test fail for you under your x86_64 patch set for
Macintel?
Running
/sw/src/fink.build/gcc4-4.1.999-20060828/gcc-4.2-20060828/gcc/testsuite/gcc.misc-tests/linkage.exp
...
Executing on host:
/sw/src/fink.build/gcc4-4.1.999-20060828/darwin_objdir/gcc/xgcc
Geoff,
Isn't the gcc.misc-tests/linkage.c failing just because we don't have
an entry in linkage.exp that defines the native flags for Darwin? Also,
this test look pretty dicey in that it uses...
catch { exec cc -c $native_cflags $srcdir/$subdir/linkage-y.c
/dev/null }
and...
On 29/08/2006, at 5:27 PM, Jack Howarth wrote:
Geoff,
Isn't the gcc.misc-tests/linkage.c failing just because we don't
have
an entry in linkage.exp that defines the native flags for Darwin?
Yes.
Also,
this test look pretty dicey in that it uses...
catch { exec cc -c
Jack Howarth wrote:
Eric,
Does the following test fail for you under your x86_64 patch set for
Macintel?
No, but that's because I have a patch to fix it :)
-eric
--- Comment #10 from uros at kss-loka dot si 2006-08-29 06:12 ---
(In reply to comment #9)
Fixed on the mainline by:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01036.html
Not really, the above patch fixed only one of three problems. The other two
remains, that is:
- ivopts problem
m68k_output_function_epilogue uses leaf_function_p.
Consider using (stack_pointer_delta == 0) instead.
A quick experiment shows improvements like so:
- move.l -8(%fp),%d2
- move.l -4(%fp),%d3
+ move.l (%sp)+,%d2
+ move.l (%sp)+,%d3
unlk %fp
rts
Note that
Currently, the m68k port only defines A0_REG and SP_REG.
We could define more macros like these.
For example, D0_REG would be useful in FUNCTION_VALUE, LIBCALL_VALUE, and
FUNCTION_VALUE_REGNO_P.
--
Summary: Use more register name macros in m68k port
Product: gcc
--- Comment #1 from kazu at gcc dot gnu dot org 2006-08-29 06:54 ---
For cleanliness, we can define STACK_POINTER_REGNUM in terms of SP_REG.
The same would apply to FRAME_POINTER_REGNUM once we define FP_REG in m68k.md.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28882
--- Comment #19 from jason at gcc dot gnu dot org 2006-08-29 06:55 ---
Subject: Bug 26577
Author: jason
Date: Tue Aug 29 06:55:03 2006
New Revision: 116554
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116554
Log:
PR c++/26577
* cvt.c (convert_to_void): Don't
--- Comment #8 from jason at gcc dot gnu dot org 2006-08-29 06:55 ---
Subject: Bug 26670
Author: jason
Date: Tue Aug 29 06:55:35 2006
New Revision: 116555
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116555
Log:
PR c++/26670
* class.c (check_field_decls): Unset
--- Comment #9 from jason at gcc dot gnu dot org 2006-08-29 07:10 ---
Subject: Bug 26670
Author: jason
Date: Tue Aug 29 07:10:38 2006
New Revision: 116556
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116556
Log:
PR c++/26670
* class.c (check_field_decls): Unset
--
Summary: TARGET_FUNCTION_VALUE not documented
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-08-29
07:55 ---
Harald,
In fixing PR28873, I have fixed this PR. Will
CALL ice(23.0) ! { dg-error no specific subroutine }
1
Error: There is no
Description of the problem:
I create module.cpp; which has a function labeled
__attribute__((constructor)).
If I link module.o directly; the function gets called.
If I make module.o into libmodule.a and then link libmodule.a, the
function does not get called.
Attached is the test
This ICE arises:
bug2.f90: In function MAIN__:
bug2.f90:30: internal compiler error: in gimplify_var_or_parm_decl, at
gimplify.c:1665
when compiling the following code:
module modA
implicit none
private
public :: sub
interface sub
module procedure subA
module procedure
--- Comment #8 from aph at gcc dot gnu dot org 2006-08-29 10:08 ---
OK, I'm working on this. It looks like a regression from 4.1.1 - 4.1.2.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-08-29
10:22 ---
I have just posted the fix to the fortran list.
Thanks for the report.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28873
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-08-29 10:36 ---
More info.
I was able to take mainline libstdc++ sources, modify limits,
--disable-visibility and then run check-compile on the same machine/os/sources
with both 4_1-branch and mainline (20060827).
The time just to
--- Comment #9 from aph at gcc dot gnu dot org 2006-08-29 10:37 ---
OK, here it is:
old:
14: invokevirtual Method
org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage
(char[],int)org.eclipse.jdt.internal.compiler.lookup.Binding
17: checkcast Class
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-08-29 10:44 ---
Actually, this is -S, so not just compile only. Hmm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28871
The following IMHO valid testcase is rejected on mainline and the 4.1
branch since a couple of days:
templatetypename struct A;
templatetypename T, int N struct AT[N] {};
templatetypename T, int N struct Aconst T[N] {};
Aconst int[1]
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28886
Alleged bug goes away if ommitting -fprefetch-loop-arrays.
Trying to compile binutils-2.17.50.0.3 (gdb-6.4 also exhibits this alleged bug)
with gcc-trunk from 20060828, i get errors of the form:
make[3]: Entering directory
`/root/src/buildroot/build_x86_64/binutils-2.17.50.0.3-target/libiberty'
--- Comment #1 from aldot at gcc dot gnu dot org 2006-08-29 12:46 ---
Created an attachment (id=12147)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12147action=view)
original unreduced testcase
Initial args used for unreduced testcase were:
gcc -O2 -fPIC -ftree-loop-optimize
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-08-29
13:05 ---
(In reply to comment #0)
Drew,
You are really uncovering them! A simplified version of your testcase that
produces the same fault is:
program test
type t
integer :: i
integer :: j
end type
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-08-29
13:09 ---
Created an attachment (id=12148)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12148action=view)
Provisional fix for the problem
This is regtesting as I write but I have little doubt that this is
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-08-29
13:12 ---
(In reply to comment #2)
Created an attachment (id=12148)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12148action=view) [edit]
Provisional fix for the problem
This is regtesting as I write but
Dnia wtorek, 29 sierpnia 2006 10:37, TongKe Xue napisał:
If I make module.o into libmodule.a and then link libmodule.a, the
function does not get called.
use -Wl,-whole-archive (man ld)
$ make
g++ module.cpp -c -O2
ar cq libmodule.a module.o
g++ test.cpp module.o -o from-object
g++ test.cpp -Wl,--whole-archive libmodule.a -Wl,--no-whole-archive \
-o from-lib
$ ./from-object
Yay life is good.
$ ./from-lib
Yay life is good.
#include module.hpp
#include iostream
using
--- Comment #10 from aph at gcc dot gnu dot org 2006-08-29 14:05 ---
class Psupersuper
{
}
class Psuper extends Psupersuper
{
}
class P extends Psuper
{
Psupersuper barf()
{
return new P();
}
}
class PR28663
{
static Psuper arse ()
{
return (P)new P().barf();
}
}
--
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 #6 from luke dot powell at bjservices dot com 2006-08-29 14:21
---
(In reply to comment #5)
Not reproducible.
I built a m68k-elf toolchain on x86_64-pc-linux-gnu and compiled the testcase.
No ICE was observed.
I am also seeing this bug with v4.1.1. My configure line
--- Comment #9 from amylaar at gcc dot gnu dot org 2006-08-29 14:34 ---
Subject: Bug 28139
Author: amylaar
Date: Tue Aug 29 14:34:36 2006
New Revision: 116561
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116561
Log:
cp:
PR c++/28139
* except.c
--- Comment #4 from jakub at gcc dot gnu dot org 2006-08-29 14:35 ---
Playing with fold_builtin_mem*.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-08-29 14:41
---
The only reason for keeping the old predication-based code is that it can
handle an important case that the generic code cannot. Specifically, it can
conditionally skip a call to a function: this is not normally
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-08-29 14:43 ---
I cannot reproduce the problem with neither of the testcases, neither on i686
nor from x86_64 crosscompiler. Could you please check whether it did not get
fixed in the meantime?
--
--- Comment #3 from anlauf at gmx dot de 2006-08-29 14:46 ---
(In reply to comment #2)
Error: There is no specific subroutine for the generic 'ice' at (1)
The new error message is rather terse but OK.
-Harald
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20067
--- Comment #7 from tbm at cyrius dot com 2006-08-29 14:53 ---
Yes, seems so - fails with 4.2.0 20060721, works with 4.2.0 20060819 on x86_64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27474
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-08-29 14:59 ---
SCCVN comes up with
Value numbers:
d_2 = c_1
c_7 = b_6
d_8 = b_6
c_10 = a_9
d_11 = a_9
where
# PRED: 3 (fallthru,exec) 4 (fallthru,exec)
# dD.1526_2 = PHI dD.1526_11(3), dD.1526_8(4);
# cD.1525_1 = PHI
--- Comment #10 from amylaar at gcc dot gnu dot org 2006-08-29 15:02
---
Fixed on mainline; however, the problem was already present in 4.1, so we need
to decide if we want the patch in the 4.1 branch.
--
amylaar at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from aph at gcc dot gnu dot org 2006-08-29 15:06 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01085.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28663
I get a tree check error with -ftree-vectorize. It works with 4.0 but fails
with 4.1 and 4.2.
(sid)345:[EMAIL PROTECTED]: ~] x86_64-unknown-linux-gnu-gcc -ftree-vectorize
-Os -c
oo2c-allocate.c
oo2c-allocate.c: In function 'Allocate__WriteStats':
oo2c-allocate.c:4: internal compiler error: tree
--- Comment #1 from tbm at cyrius dot com 2006-08-29 15:11 ---
Created an attachment (id=12149)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12149action=view)
test case
Testcase from application oo2c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #15 from amylaar at gcc dot gnu dot org 2006-08-29 15:30
---
(In reply to comment #14)
This works for me with a cross (and sysroot) to powerpc-linux-gnu from a
i686-linux-gnu.
Is that a unified tree build with newlib?
--
--- Comment #4 from pault at gcc dot gnu dot org 2006-08-29 15:49 ---
Since I just posted a patch for it, I might as well assign it to myself!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pault at gcc dot gnu dot org 2006-08-29 15:50 ---
I believe that does it.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from hosking at cs dot purdue dot edu 2006-08-29 15:52
---
Sorry, my information was in error last time. It seems I got the src/dest
information wrong for the edge being split. The edge is between blocks 32 and
33 in the dump below:
;; Function TrestleGoo__PutProp
--- Comment #28 from amylaar at gcc dot gnu dot org 2006-08-29 15:53
---
Subject: Bug 17506
Author: amylaar
Date: Tue Aug 29 15:52:54 2006
New Revision: 116564
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116564
Log:
gcc:
2006-08-29 Nathan Sidwell [EMAIL PROTECTED]
The current implementation of -fstack-check-register doesn't work on m68k.
With -fstack-check-register=N, the m68k inserts stack checking code like
cmp.l %dN,%sp
trapcs
However, %dN isn't reserved in FIXED_REGISTER.
So the compiler would use %dN as an available regiter elsewhere.
--- Comment #6 from pault at gcc dot gnu dot org 2006-08-29 16:29 ---
All the issues with dot product have been sorted, as far as I know.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
Compiler blows up on this function.
$ cat test.f
integer*4 function test(charr, charrlen)
character (len=*) :: charr
integer*4 charrlen, i
do i=1, charrlen
write (*,*) i, charr(i)
end do
end
$ gfortran -c test.f
test.f: In function 'test':
test.f:5:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|x86_64-linux-gnu|
GCC host triplet|x86_64-linux-gnu|
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-08-29 17:04 ---
*** This bug has been marked as a duplicate of 26197 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from pinskia at gcc dot gnu dot org 2006-08-29 17:04
---
*** Bug 27474 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
seen with current trunk and on the redhat/gcc-4_1-branch; works with the
gcc-4_1-branch. The files are rather large, please find them at
http://people.debian.org/~doko/tmp/help.tar.bz2
The code is taken from OOo 2.0.3.
Matthias
$ make
HelpCompiler.java HelpLinker.java
--- Comment #29 from nathan at gcc dot gnu dot org 2006-08-29 17:20 ---
(In reply to comment #28)
2006-08-29 Nathan Sidwell [EMAIL PROTECTED]
Jorn Rennecke [EMAIL PROTECTED]
PR tree-optimization/17506
* tree-ssa.c (warn_uninit): If warning about a
--- Comment #12 from tromey at gcc dot gnu dot org 2006-08-29 17:27 ---
PR 28067 blocks this -- when merging the gcj-eclipse branch to trunk,
we should remove the workaround patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Currently we error out if there is an assignment to a static final field
(in a .class file) which is not in the class' static initializer.
This constraint is apparently not enforced by the JDK -- meaning that
we reject class files which run on the JDK. Class files like this are
generated by
--
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 #2 from aldot at gcc dot gnu dot org 2006-08-29 18:11 ---
Also fails for native i686-linux-gnu with
gcc-4.2-20060829 -march=i686 -msse -O1 -fprefetch-loop-arrays
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from jason at gcc dot gnu dot org 2006-08-29 18:15 ---
Subject: Bug 26577
Author: jason
Date: Tue Aug 29 18:15:20 2006
New Revision: 116568
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116568
Log:
PR c++/26577
* cvt.c (convert_to_void): Don't
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-29 19:02
---
This doesn't ICE for me with current mainline - I get the following error
messages:
bug.cc:1: error: 'void' is not a valid type for a template constant parameter
bug.cc:6: error: type/value mismatch at argument
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-08-29 19:07
---
This doesn't ICE for me with current mainline:
bug.cc:1: error: 'void' is not a valid type for a template constant parameter
void bar()
bug.cc:2: error: no matching function for call to 'foo()'
Can anyone else
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-29 19:11
---
This doesn't ICE for me on current mainline:
bug.cc:1: error: 'void' is not a valid type for a template constant parameter
bug.cc:3: error: templates may not be 'virtual'
bug.cc:7: error: 'type error' is not a
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #21 from guenter at roeck-us dot net 2006-08-29 19:12 ---
This bug fix causes severe problems with all e500 double precision floating
point code. It generates code such as :
...
evldd 9,104(31)
stw 9,112(31)
stw 10,116(31)
...
i.e.,
--- Comment #22 from dje at watson dot ibm dot com 2006-08-29 19:26 ---
Subject: Re: [4.1 Regression] returning constant double
One of the patterns probably needs a r-m case as well, but we
need a testcase to figure out which one.
--
--- Comment #3 from kargl at gcc dot gnu dot org 2006-08-29 19:47 ---
Subject: Bug 28866
Author: kargl
Date: Tue Aug 29 19:47:31 2006
New Revision: 116570
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116570
Log:
2006-08-29 Steven G. Kargl [EMAIL PROTECTED]
PR
--- Comment #4 from kargl at gcc dot gnu dot org 2006-08-29 19:49 ---
Patch committed.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2006-08-29 19:52 ---
I seem to have accepted this bug instead of confirming it. That wasn't my
intention.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
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 #23 from guenter at roeck-us dot net 2006-08-29 20:23 ---
Here is a test case:
double calc(double val, double *result)
{
double f = val - (double)((int)val);
*result = val - f;
if (!val)
return val - *result;
else
--
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 #24 from dje at gcc dot gnu dot org 2006-08-29 20:49 ---
new codegen problem
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from pinskia at gcc dot gnu dot org 2006-08-29 20:51
---
(In reply to comment #23)
Here is a test case:
Thanks for the small testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from dje at gcc dot gnu dot org 2006-08-29 21:09 ---
The RTL looks like:
(code_label 34 33 35 2 [0 uses])
(note 35 34 0 NOTE_INSN_BASIC_BLOCK)
;; return val
(insn 36 35 37 (set (subreg:DF (reg:DI 136) 0)
(reg:DF 122 [ val ])) -1 (nil)
(nil))
(insn 37 36
--- Comment #1 from pault at gcc dot gnu dot org 2006-08-29 21:26 ---
Confirmed: changing the substring reference to the unambiguous
write (*,*) i, charr(i:i)
gets rid of the problem. Apparently, vene though charr is scalar, the
reference is being interpreted as an array
--- Comment #3 from kargl at gcc dot gnu dot org 2006-08-29 21:39 ---
We no longer get an ICE with
GNU F95 version 4.2.0 20060828 (experimental) (x86_64-unknown-freebsd7.0)
gfortran -o z ji.f90
In file ji.f90:6
MODULE PROCEDURE sreal, schar, sint = sreal
internal compiler error: in ix86_secondary_memory_needed, at
config/i386/i386.c:15963
is triggered by my (invalid) attempt at x86-64 inline assembly:
static inline void* CMPXCHG_PTR( void* volatile * dest,
void* newValue, void* comp ) {
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-08-29 21:58
---
*** Bug 28893 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-29 21:58 ---
It is the same as PR 26655, the a is causing it.
*** This bug has been marked as a duplicate of 26655 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Attached code file is compiled.
Here is the critical passage:
inline void taskSignal(void)
{
unsigned char i;
PORTB |= _BV(PB4);
PORTB |= _BV(PB5);
PORTB |= _BV(PB6);
i=0;
do
{
i+=2;
}
while( i245 );
i=0;
do
{
i+=3;
}
while( i245 );
--- Comment #1 from ralf-engels at gmx dot de 2006-08-29 22:30 ---
Created an attachment (id=12150)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12150action=view)
source code which is compiled strangely.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28894
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|tree-optimization |target
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-29 22:34 ---
264: 8a 5f subir24, 0xFA ; 250
That looks fine for me since it is r24 = r24 - -2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28894
template typename T
class final
{
struct workaround { typedef T type; };
friend class workaround::type;
final() { };
final( final const ) { };
};
struct Foo : virtual public finalFoo {};
void test() { Foo foo; }
$7.1.5.3/2 prohibits such code and Comeau compiler reports an error:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-29 23:21 ---
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1520.pdf
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28895
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-29 23:22 ---
Related to PR 22047.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28895
--- Comment #3 from fang at csl dot cornell dot edu 2006-08-29 23:23
---
Hi, see PR 21498.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28895
--- Comment #21 from jason at gcc dot gnu dot org 2006-08-30 02:59 ---
Subject: Bug 26577
Author: jason
Date: Wed Aug 30 02:59:14 2006
New Revision: 116576
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116576
Log:
PR c++/26577
* cvt.c (convert_to_void): Don't
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-08-30 03:28 ---
Devang,
Why did you remove your self, you caused this regression.
Yes you might not work on GCC any more for Apple but that does not take you
away from fixing the regression you caused. I am a bit upset at this
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-08-30 03:32
---
(In reply to comment #15)
(In reply to comment #14)
This works for me with a cross (and sysroot) to powerpc-linux-gnu from a
i686-linux-gnu.
Is that a unified tree build with newlib?
No it is not, it is a
--- Comment #30 from pinskia at gcc dot gnu dot org 2006-08-30 03:33
---
I will file tomorrow the bug reports about the cases I mentioned to the patches
list.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-30 03:36 ---
Seems like you should also be doing -ffixed-reg=N. Maybe that should be
mentioned in the docs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28889
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-30 03:38 ---
Been fixed since at least 4.2.0 20060826.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-30 03:39 ---
Been fixed since at least 4.2.0 20060826.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28641
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-30 03:41 ---
Fixed since at least 4.2.0 20060826.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 132 matches
Mail list logo
