> I'm not confident we know what clean results are for all the primary
> platforms, i.e. that anyone has tracked what failures are regressions and
> what aren't (which requires testing the FAILing tests with older
> compilers, not just presuming that a FAILing test not in a previous
> release isn't
Hi,
Between Tuesday and Wednesday (Indian time), something(s)
went into mainline that is showing me a dramatic decrease
in bootstrap times - a c,c++,java bootstrap on i686-pc-linux-gnu
now takes 51m for me compared to 65-66m earlier, which is
around 20% of savings over the course of a single day
Bootstrap works now but the testresults (see
http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01209.html) show that
we still have serious problem:
=== objc Summary for unix ===
# of expected passes418
# of unexpected failures558
# of unresolved testcases
On Wed, 18 May 2005 15:56:27 -0700, Richard Henderson wrote
> On Thu, May 19, 2005 at 06:02:39AM +0800, Ling-hua Tseng wrote:
> > struct gcc_target targetm = TARGET_INITIALIZER;
> > ...
> > #undef TARGET_VECTOR_MODE_SUPPORTED_P
> > #define TARGET_VECTOR_MODE_SUPPORTED_P unicore_vector_mode_suppor
> Mark Mitchell wrote:
> >
> > struct A {...};
> > struct B { ...; struct A a; ...; };
> >
> >
> > void f() {
> >B b;
> >g(&b.a);
> > }
> >
> >
> >does the compiler have to assume that "g" may access the parts of
> >"b" outside of "a". If the compiler can see the body of "g" tha
On Thu, May 19, 2005 at 01:09:28AM +, Joseph S. Myers wrote:
> On Wed, 18 May 2005, Richard Henderson wrote:
>
> > After three days of sequential bootstrap breakage, I'd like to propose
> > that mainline go into slush, wherein all these bootstrap problems, and
> > all the new testsuites failur
On Wed, 18 May 2005, Richard Henderson wrote:
> After three days of sequential bootstrap breakage, I'd like to propose
> that mainline go into slush, wherein all these bootstrap problems, and
> all the new testsuites failures get fixed. No other patches would be
> allowed at all.
>
> We'd unslus
> Richard Henderson writes:
Richard> After three days of sequential bootstrap breakage, I'd like to propose
Richard> that mainline go into slush, wherein all these bootstrap problems, and
Richard> all the new testsuites failures get fixed. No other patches would be
Richard> allowed at all.
R
On Wed, May 18, 2005 at 05:31:29PM -0700, Richard Henderson wrote:
> After three days of sequential bootstrap breakage, I'd like to propose
> that mainline go into slush, wherein all these bootstrap problems, and
> all the new testsuites failures get fixed. No other patches would be
> allowed at
> We'd unslush when the primary platforms have clean test results.
>
> Thoughts?
Aye :)
-eric
After three days of sequential bootstrap breakage, I'd like to propose
that mainline go into slush, wherein all these bootstrap problems, and
all the new testsuites failures get fixed. No other patches would be
allowed at all.
We'd unslush when the primary platforms have clean test results.
Thou
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
| On Wed, 18 May 2005, Joe Buck wrote:
|
| > On Wed, May 18, 2005 at 11:53:13PM -, [EMAIL PROTECTED] wrote:
| > > Snapshot gcc-3.3-20050518 is now available on
| > > ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-2005051
Joe Buck <[EMAIL PROTECTED]> writes:
| On Wed, May 18, 2005 at 11:53:13PM -, [EMAIL PROTECTED] wrote:
| > Snapshot gcc-3.3-20050518 is now available on
| > ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050518/
| > and on various mirrors, see http://gcc.gnu.org/mirrors.html for d
On Wed, 18 May 2005, Joe Buck wrote:
> On Wed, May 18, 2005 at 11:53:13PM -, [EMAIL PROTECTED] wrote:
> > Snapshot gcc-3.3-20050518 is now available on
> > ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050518/
> > and on various mirrors, see http://gcc.gnu.org/mirrors.html
On Wed, May 18, 2005 at 11:53:13PM -, [EMAIL PROTECTED] wrote:
> Snapshot gcc-3.3-20050518 is now available on
> ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050518/
> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
Is there a reason why we are still gener
Snapshot gcc-3.3-20050518 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050518/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.3 CVS branch
with the following options: -rgcc-ss-3_3-20050518
You'll
Ling-hua Tseng wrote:-
> struct gcc_target targetm = TARGET_INITIALIZER;
> ...
> #undef TARGET_VECTOR_MODE_SUPPORTED_P
> #define TARGET_VECTOR_MODE_SUPPORTED_P unicore_vector_mode_supported_p
TARGET_INITIALIZER has already been expanded above, so it's not seen
your macro definition below.
Neil
On Thu, May 19, 2005 at 06:02:39AM +0800, Ling-hua Tseng wrote:
> struct gcc_target targetm = TARGET_INITIALIZER;
> ...
> #undef TARGET_VECTOR_MODE_SUPPORTED_P
> #define TARGET_VECTOR_MODE_SUPPORTED_P unicore_vector_mode_supported_p
This is your bug. The TARGET_INITIALIZER needs to come last.
Mike Hearn <[EMAIL PROTECTED]> writes:
> The reality is that 95% of computers run Windows which is very good at
> supporting developers who distribute binaries in this way.
Does it? I constantly hear horror stories of apps delivering their own
version of system libraries that cause all kinds of
On Wed, 18 May 2005 14:17:59 -0700, Richard Henderson wrote
> On Thu, May 19, 2005 at 04:58:32AM +0800, Ling-hua Tseng wrote:
> > I got 4 lines "SI".
> > (In the ARM's iWMMXt V8QI testing, I got the message: "V8QI")
>
> Then you need to debug your targetm.vector_mode_supported_p.
>
> Starting aro
On Wed, May 18, 2005 at 11:08:30PM +0200, Paolo Carlini wrote:
> Paul Brook wrote:
>
> >In my experience most windows applications work because they're either
> >statically linked, or ship with a copy of every single library they need.
> >
> >
> Well, sorry for contributing to the flame, but I
On Thu, May 19, 2005 at 04:58:32AM +0800, Ling-hua Tseng wrote:
> I got 4 lines "SI".
> (In the ARM's iWMMXt V8QI testing, I got the message: "V8QI")
Then you need to debug your targetm.vector_mode_supported_p.
Starting around stor-layout.c line 1609:
for (; mode != VOIDmode ; mode =
On Wed, May 18, 2005 at 09:33:35PM +0100, Mike Hearn wrote:
> On Wed, 18 May 2005 10:05:34 -0700, Dan Kegel wrote:
> > No hacks needed; you just have to embrace reality.
>
> The reality is that 95% of computers run Windows which is very good at
> supporting developers who distribute binaries in th
mrs bash[73] nm i586-pc-linux-gnu/libobjc/.libs/libobjc.so.1 | grep
gcc_unre
U gcc_unreachable
:-(
This is killing the Objective-C testsuite for me...
On Wed, May 18, 2005 at 09:27:50PM +0100, Mike Hearn wrote:
> The biggest problem really is that this sort of thing is a lot of effort
> for your average evenings-and-weekends open source hacker who wants to
> distribute Linux binaries to his end users. Setting up and maintaining a
> dedicated buil
Paul Brook wrote:
>In my experience most windows applications work because they're either
>statically linked, or ship with a copy of every single library they need.
>
>
Well, sorry for contributing to the flame, but I have the very *same*
feeling. The only reason why I'm publically stating this
> > Jan Hubicka writes:
>
> >> That might be related to the bootstrap failure on AIX as well.
>
> Jan> Hopefully this is fixed now by Jeff's patch.
>
> The libjava failure is fixed, but the patch will not affect the
> AIX libgfortran failure.
>
> I have verified that either the
On Wednesday 18 May 2005 21:33, Mike Hearn wrote:
> On Wed, 18 May 2005 10:05:34 -0700, Dan Kegel wrote:
> > No hacks needed; you just have to embrace reality.
>
> The reality is that 95% of computers run Windows which is very good at
> supporting developers who distribute binaries in this way. On
On Wed, 18 May 2005 12:19:47 -0700, Richard Henderson wrote
> On Wed, May 18, 2005 at 11:10:42PM +0800, Ling-hua Tseng wrote:
> > So I guess that there are some miss-configured in my ports, but I can't
> > find it.
>
> Put a breakpoint at tree-complex.c line 962. Examine the conditions
> leading
> Jan Hubicka writes:
>> That might be related to the bootstrap failure on AIX as well.
Jan> Hopefully this is fixed now by Jeff's patch.
The libjava failure is fixed, but the patch will not affect the
AIX libgfortran failure.
I have verified that either the cgraph inlining
On Wed, 18 May 2005 10:05:34 -0700, Dan Kegel wrote:
> No hacks needed; you just have to embrace reality.
The reality is that 95% of computers run Windows which is very good at
supporting developers who distribute binaries in this way. On Linux
there's all kinds of gotchas you just Have To Know wh
On Wed, 18 May 2005 15:13:41 +0200, Jakub Jelinek wrote:
> Compiler built in presence of dl_iterate_phdr creates binaries and shared
> libraries, that rely on its presence in target glibc, as support code
> for older glibc's is intentionally left out in that case.
Why is that? Is the support code
> That might be related to the bootstrap failure on AIX as well.
Hopefully this is fixed now by Jeff's patch.
>
> Also, the commit modified files not listed in the ChangeLog:
>
> gcc/tree-pass.h
> gcc/cp/method.c
>
> adding function tree_lowering_passes()
Uhm, I apparently cut&paste
On May 17, 2005, at 11:35 PM, Andreas Jaeger wrote:
On x86_64-linux-gnu I get with current CVS the following bootstrap
error:
/cvs/gcc/libobjc/Object.m: In function '-[Object name]':
/cvs/gcc/libobjc/Object.m:101: internal compiler error: in
tree_node_structure,
at tree.c:1815
Please submit a
Hi All,
This is just some quick spam to announce the LLVM 1.5 release:
http://mail.cs.uiuc.edu/pipermail/llvm-announce/2005-May/16.html
http://llvm.cs.uiuc.edu/releases/1.5/docs/ReleaseNotes.html#whatsnew
Among other things, this release adds beta IA64 and Alpha backends,
support for general p
On Wed, May 18, 2005 at 11:10:42PM +0800, Ling-hua Tseng wrote:
> So I guess that there are some miss-configured in my ports, but I can't
> find it.
Put a breakpoint at tree-complex.c line 962. Examine the conditions
leading up to
if ((GET_MODE_CLASS (compute_mode) == MODE_VECTOR_INT
Richard Henderson wrote:
> On Wed, May 18, 2005 at 02:08:02PM +0200, Richard Guenther wrote:
>
>>! vtbl = build_fold_addr_expr (vtbl);
>
>
> No convert.
It will break later if I use convert here - the frontend chokes on
the unexpected NOP_EXPR.
> And I'm pretty sure you never want to use
On Wed, May 18, 2005 at 02:46:33PM +0200, Olivier Hainque wrote:
> A possible way to address that is to have expand_main_function compute the
> distance between the current and aligned values of the stack pointer (without
> touching it), and resort to allocate_dynamic_stack_space to allocate exactl
On Wed, May 18, 2005 at 02:08:02PM +0200, Richard Guenther wrote:
> ! vtbl = build_fold_addr_expr (vtbl);
No convert.
And I'm pretty sure you never want to use convert, as that'll
emit warnings. Use fold_convert.
r~
On Wed, May 18, 2005 at 01:25:05PM +0200, Richard Guenther wrote:
>
> The following snippet
>
> /* Differs from default_conversion by not setting TREE_ADDRESSABLE
> (because calling an inline function does not mean the function
> needs to be separately compiled). */
>
> "Richard" == Richard Henderson <[EMAIL PROTECTED]> writes:
Richard> On Wed, May 18, 2005 at 01:04:15PM -0400, Paul Koning wrote:
>> Fine, but are GCC *users* expected to search the GCC list
>> archives?
Richard> If they want to know the answer to "why", as opposed to
Richard> being sat
On Wed, May 18, 2005 at 01:04:15PM -0400, Paul Koning wrote:
> Fine, but are GCC *users* expected to search the GCC list archives?
If they want to know the answer to "why", as opposed to being
satisfied with "don't do that", then yes.
r~
[EMAIL PROTECTED] wrote:
> [ Things break horribly when I compile them
> with a compiler built against glibc-2.3.x
> and try to run them on a glibc-2.2.x system. ]
This is expected and normal. gcc and glibc have
circular dependencies. A gcc tainted with a newer
glibc is expected to produce bi
On 18 May 2005 12:54:03 -0400, Ian Lance Taylor wrote
> "Ling-hua Tseng" <[EMAIL PROTECTED]> writes:
>
> > I have tried to adjust the constraints to 'r' (general registers) for
> > the "movv4qi" and "addv4qi" insn patterns,
> > but I got the same problem.
>
> What about HARD_REGNO_MODE_OK?
>
>
Paul Schlie <[EMAIL PROTECTED]> writes:
| > From: Gabriel Dos Reis <[EMAIL PROTECTED]>
| > <[EMAIL PROTECTED]>,
| > Subject: Re: Mismatched types in ADDR_EXPR from
c-typeck.c:build_function_call
| >
| > | Thereby all literal values are implied to be qualified as a read-only
| > | 'literal' obje
> "Richard" == Richard Henderson <[EMAIL PROTECTED]> writes:
Richard> On Wed, May 18, 2005 at 11:32:51AM -0400, Paul Koning wrote:
>> What surprises me is that it's normally ok to mix static and
>> shared libs, but not here. And the message is utterly
>> uninformative about what is wrong
"Ling-hua Tseng" <[EMAIL PROTECTED]> writes:
> I have tried to adjust the constraints to 'r' (general registers) for
> the "movv4qi" and "addv4qi" insn patterns,
> but I got the same problem.
What about HARD_REGNO_MODE_OK?
Ian
On Wed, May 18, 2005 at 11:32:51AM -0400, Paul Koning wrote:
> What surprises me is that it's normally ok to mix static and shared
> libs, but not here. And the message is utterly uninformative about
> what is wrong or why the restriction exists.
It's been explained in detail many times before se
That might be related to the bootstrap failure on AIX as well.
Also, the commit modified files not listed in the ChangeLog:
gcc/tree-pass.h
gcc/cp/method.c
adding function tree_lowering_passes()
David
> From: Gabriel Dos Reis <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>,
> Subject: Re: Mismatched types in ADDR_EXPR from c-typeck.c:build_function_call
>
> | Thereby all literal values are implied to be qualified as a read-only
> | 'literal' object/reference, which has the semantics, that it may not
Mainline bootstrap fails on powerpc64-linux with:
/home/gccbuild/gcc_mline_anoncvs/gcc/libjava/jni.cc: In function 'void*
_Jv_LookupJNIMethod(java::lang::Class*, _Jv_Utf8Const*, _Jv_Utf8Const*, int)':
/home/gccbuild/gcc_mline_anoncvs/gcc/libjava/jni.cc:2141: error: Statement
marked for throw, bu
On Wed, 18 May 2005 17:25:35 +0200, Paolo Bonzini wrote
> > Now I'm implementing the V4QI SIMD add operation.
>
> Maybe there is no register that can store a V4QI.
>
> Paolo
Doesn't the register allocation pass perform in the RTL optimization passes?
Could it affect the tree-level optimization pa
> "Sam" == Sam Lauber <[EMAIL PROTECTED]> writes:
>> > The documentation for -fvisibility=hidden suggets that this
>> switch is > useful for shared libraries, to make things smaller
>> and faster. It > doesn't seem to be appropriate for object
>> libraries.
>> It's done *exactly* so tha
> Now I'm implementing the V4QI SIMD add operation.
Maybe there is no register that can store a V4QI.
Paolo
On Wed, May 18, 2005 at 01:36:08PM +0100, Mike Hearn wrote:
> On Wed, 18 May 2005 11:35:30 +0200, Stephan Bergmann wrote:
> > If I build main with C1, and libf.so with C2, and execute the program so
> > that it uses C2's libgcc_s.so.1, it works.
>
> Out of interest, what happens if you build mai
On 2005-05-18, at 14:36, Mike Hearn wrote:
On Wed, 18 May 2005 11:35:30 +0200, Stephan Bergmann wrote:
If I build main with C1, and libf.so with C2, and execute the
program so
that it uses C2's libgcc_s.so.1, it works.
Out of interest, what happens if you build main with C2 and libf
with C1?
T
Hello,
> Don't know how to fix this - nothing obvious. But we create at
>
> *op = build1 (INDIRECT_REF, TREE_TYPE (*op), with);
>
> an INDRECT_REF of the form
>
> type size
> unit size
> align 8 symtab 1075593216 alias set -1 precision 8 min
> max
>
Hello,
> > > So far OK, but with ter, this becomes
> > >
> > > sum1 = 0;
> > > sum2 = 0;
> > > for (i = 0; i < n; i+=4)
> > > {
> > > x_1 = a[i];
> > > y_1 = b[i];
> > > x_2 = a[i+1];
> > > y_2 = b[i+1];
> > > x_3 = a[i+2];
> > > y_3 = b[i+2];
> > > x_4 = a[i+3];
> >
I saw the ARM's porting and knew that ARM have V8QI SIMD operation supporting.
I'm porting another platform, and the platform is also supporting SIMD
operations.
Now I'm implementing the V4QI SIMD add operation.
(with gcc version 4.0.1 20050514)
I did the following steps:
1. added VECTOR_MODES(
Peter Barada wrote:
Perhaps it is that the ELF executables are larger in total size(not
code size) than the corresponding COFF executables, and if stored on
the target, then the footprint increases, causing "larger memory
requirements" of flash, not DRAM.
Possibly, though I am surprised if the diff
Paul Schlie <[EMAIL PROTECTED]> writes:
| > Joseph S. Myers writes:
| >> Richard Guenther wrote:
| >> The following snippet
| >>
| >> /* Differs from default_conversion by not setting TREE_ADDRESSABLE
| >> (because calling an inline function does not mean the function
| >>
On 18 May 2005, Gabriel Dos Reis wrote:
> "Joseph S. Myers" <[EMAIL PROTECTED]> writes:
>
> | On Wed, 18 May 2005, Richard Guenther wrote:
> |
> | > The following snippet
> | >
> | > /* Differs from default_conversion by not setting TREE_ADDRESSABLE
> | > (because calling an inline
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
| On Wed, 18 May 2005, Richard Guenther wrote:
|
| > The following snippet
| >
| > /* Differs from default_conversion by not setting TREE_ADDRESSABLE
| > (because calling an inline function does not mean the function
| > needs
On Wed, 2005-05-18 at 09:23, Steven Bosscher wrote:
> On May 18, 2005 03:06 PM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
>
> > So far OK, but with ter, this becomes
> >
> > sum1 = 0;
> > sum2 = 0;
> > for (i = 0; i < n; i+=4)
> > {
> > x_1 = a[i];
> > y_1 = b[i];
> > x_2 = a[i+1];
>
> Joseph S. Myers writes:
>> Richard Guenther wrote:
>> The following snippet
>>
>> /* Differs from default_conversion by not setting TREE_ADDRESSABLE
>> (because calling an inline function does not mean the function
>> needs to be separately compiled). */
>> fntype
Andreas Krebbel <[EMAIL PROTECTED]> writes:
> mainline bootstrap on s390 currently fails with:
>
> build/genmddeps ../../gcc/config/s390/s390.md > tmp-mddeps
> ../../gcc/config/s390/s390.md:2041: undefined attribute 'DBL' used for
> mode
> ../../gcc/config/s390/s390.md:2041: following context is
Don't know how to fix this - nothing obvious. But we create at
*op = build1 (INDIRECT_REF, TREE_TYPE (*op), with);
an INDRECT_REF of the form
unit size
align 8 symtab 1075593216 alias set -1 precision 8 min
max
pointer_to_this >
arg 0
public uns
>> ATM, I am experiencing objects being generated by GCC to increase in
>> size and forcing us to gradually abandon targets with tight memory
>> requirements. At least one cause of this seems to be GCC abandoning COFF
>> in favor of ELF, which seems to imply larger memory requirements.
>
>I don't
LAST_UPDATED:
Wed May 18 00:10:41 EDT 2005
Wed May 18 04:10:41 UTC 2005
/tmp/powerpc-ibm-aix5.2.0.0-20050518/./gcc/xgcc
-B/tmp/powerpc-ibm-aix5.2.0.0-20050518/./gcc/
-B/farm/dje/install/powerpc-ibm-aix5.2.0.0-20050518/powerpc-ibm-aix5.2.0.0/bin/
-B/farm/dje/install/powerpc-ibm-aix5.2.0.0
Ralf Corsepius wrote:
ATM, I am experiencing objects being generated by GCC to increase in
size and forcing us to gradually abandon targets with tight memory
requirements. At least one cause of this seems to be GCC abandoning COFF
in favor of ELF, which seems to imply larger memory requirements.
I
On 5/18/05, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-05-18 at 12:42 +, Joseph S. Myers wrote:
> > On Wed, 18 May 2005, Richard Guenther wrote:
> >
>
> > (b) You'll probably need to change the code that autodetects const
> > functions to do the same, and if there's any code autod
On May 18, 2005 03:06 PM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> So far OK, but with ter, this becomes
>
> sum1 = 0;
> sum2 = 0;
> for (i = 0; i < n; i+=4)
> {
> x_1 = a[i];
> y_1 = b[i];
> x_2 = a[i+1];
> y_2 = b[i+1];
> x_3 = a[i+2];
> y_3 = b[i+2];
> x_4 = a[i
On Wed, 2005-05-18 at 12:42 +, Joseph S. Myers wrote:
> On Wed, 18 May 2005, Richard Guenther wrote:
>
> (b) You'll probably need to change the code that autodetects const
> functions to do the same, and if there's any code autodetecting noreturn
> functions then likewise. Also any code ge
On Wed, May 18, 2005 at 01:36:08PM +0100, Mike Hearn wrote:
> Could there please at some point be serious discussion of making this a
> supported way of working? In this case dl_iterate_phdr is weak so could
> the decision about whether to use it or not could be made at runtime, not
> build time?
On Wed, 18 May 2005, Richard Earnshaw wrote:
> In my experience, test_summary does the wrong thing if you build and
> test a unified source tree, for example, I run it on a unified arm-elf
> tree and the subject line comes out as:
>
> Results for 6.3.50.20050330-cvs -nx testsuite on arm-unknown-e
Hello,
I am just playing with loop unrolling on trees (for the purposes of
prefetching), and I encountered the following problem. Consider loop
sum1 = 0;
sum2 = 0;
for (i = 0; i < n; i++)
{
x_1 = a[i];
y_1 = b[i];
sum1 += x_1 * y_1;
sum2 += x_1 / y_1;
}
Now after unrolling w
On Wed, 18 May 2005, Richard Sandiford wrote:
> "Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> > For example, "Results for 4.1.020050506(experimental) testsuite on
> > mips64-unknown-elf" with the components of the version number all run
> > together
> > [...]
> > Ensuring your test results
>
Hello,
As mentioned in a previous discussion at
http://gcc.gnu.org/ml/gcc/2005-04/msg01416.html
we have troubles with the expand_main_function code to adjust the stack
pointer to PREFERRED_STACK_BOUNDARY on entry points.
It currently aligns the stack pointer by applying explicit operations on
On Wed, 18 May 2005, Richard Guenther wrote:
> The following snippet
>
> /* Differs from default_conversion by not setting TREE_ADDRESSABLE
> (because calling an inline function does not mean the function
> needs to be separately compiled). */
> fntype = build_type_
On Wed, 18 May 2005 11:35:30 +0200, Stephan Bergmann wrote:
> If I build main with C1, and libf.so with C2, and execute the program so
> that it uses C2's libgcc_s.so.1, it works.
Out of interest, what happens if you build main with C2 and libf with C1?
That would seem to be a more common situati
With this patch we can build the C++ frontend and libraries
with an instrumented build1 that checks ADDR_EXPR types to
match as far as sharing the same TYPE_MAIN_VARIANT.
Comments?
Richard.
2005-05-18 Richard Guenther <[EMAIL PROTECTED]>
* class.c (dfs_accumulate_vtbl_inits): Create
On 5/18/05, Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> The following snippet
>
> /* Differs from default_conversion by not setting TREE_ADDRESSABLE
> (because calling an inline function does not mean the function
> needs to be separately compiled). */
> fntype
If the following ever escapes the C++ frontend (who knows...)
/* Take the address of the function, considering it to be of an
appropriate generic type. */
init = build1 (ADDR_EXPR, vfunc_ptr_type_node, fn);
it'll be not nice.
(gdb) call debug_tree(t)
QI
The following snippet
/* Differs from default_conversion by not setting TREE_ADDRESSABLE
(because calling an inline function does not mean the function
needs to be separately compiled). */
fntype = build_type_variant (TREE_TYPE (function),
On Mon, 16 May 2005, DJ Delorie wrote:
What I have problem understanding is the last sentence of this
paragraph in the light of your claim that it will results in
swapping especially when we consider developers' machines with
512MB/1GB RAM, i.e. machines where memory is not "tight".
Sigh, Linux wo
On Tue, 17 May 2005, Mike Stump wrote:
On May 17, 2005, at 3:16 PM, Karel Gardas wrote:
1) the most expensive seems to be comptypes -- at least from data L2
refill point of view (~17%)
2) comptypes is also the most CPU intensive operation since the most
of time is spent there
I think comptypes
Stephan Bergmann <[EMAIL PROTECTED]> writes:
> If I build main with C1, and libf.so with C2, and execute the program so
> that it uses C1's libgcc_s.so.1, it aborts.
Forward compatibility is never guaranteed. If you want to execute on the
older system you need to build all parts on the older sy
Hi all,
I experience the following problem on Linux x86:
I have one version of GCC, call it C1, compiled on a glibc 2.2 (plain
2.2, that is) machine. (It happens to be GCC 3.4.1, but the exact
version is probably irrelevant.) This build includes a version of
libgcc_s.so.1.
Additionally, I hav
On Tue, 2005-05-17 at 23:33, Joseph S. Myers wrote:
> It's a de facto standard: don't modify your Subject header from that
> test_summary generates; there are plenty of examples on gcc-testresults of
> what the headers should look like. You can rewrite the shell script
> output by test_summary
On Tue, 2005-05-17 at 21:03, Paul Brook wrote:
[building of gfortran]
> It does require gmp/mpfr on the host, but in most cases the host is native,
> and they are dead easy to cross compile anyway.
And it's long been my contention that we shouldn't even be doing that.
I still feel these packag
On Tue, May 17, 2005 at 02:11:24PM -0700, Mark Mitchell wrote:
> Jonathan Wakely wrote:
> >On Mon, May 16, 2005 at 05:41:03PM -0700, Mark Mitchell wrote:
> >
> >
> >>I've very nearly ready to release GCC 3.4.4. If you have objections or
> >>high-priority fixes that you think will be required for
Hi,
mainline bootstrap on s390 currently fails with:
build/genmddeps ../../gcc/config/s390/s390.md > tmp-mddeps
../../gcc/config/s390/s390.md:2041: undefined attribute 'DBL' used for mode
../../gcc/config/s390/s390.md:2041: following context is `'
DBL is a macro attribute defined as:
(define_mo
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> For example, "Results for 4.1.020050506(experimental) testsuite on
> mips64-unknown-elf" with the components of the version number all run
> together
> [...]
> Ensuring your test results
> use the standard Subject header format makes it more likely
Ranjit Mathew <[EMAIL PROTECTED]> writes:
[...]
| PS: Surely this must be one of the longest threads in
| recent times on the GCC list!
:-)
| PPS: I do not see some of the messages, for example, a
| couple of messages from Robert Dewar that seem to be
| referenced in other messages.
same here.
94 matches
Mail list logo
