Ralf Corsepius <[EMAIL PROTECTED]> writes:
> On Sun, 2005-05-08 at 21:34 -0700, Zack Weinberg wrote:
>> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>>
>> > FWIW: IMO, NO_IMPLICIT_EXTERN_C actually is an OS/libc feature ("Your
>> > system headers are c++ aware"), therefore it is hardly possible or
On Sun, 2005-05-08 at 21:34 -0700, Zack Weinberg wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> > FWIW: IMO, NO_IMPLICIT_EXTERN_C actually is an OS/libc feature ("Your
> > system headers are c++ aware"), therefore it is hardly possible or
> > useful to ever use "#define NO_IMPLICIT_EXTERN
Ralf Corsepius <[EMAIL PROTECTED]> writes:
> FWIW: IMO, NO_IMPLICIT_EXTERN_C actually is an OS/libc feature ("Your
> system headers are c++ aware"), therefore it is hardly possible or
> useful to ever use "#define NO_IMPLICIT_EXTERN_C" on "generic" targets
> (*-elf, *-coff etc.).
I'm going to ask
Hi Andi,
Splitting up libgcj.so probably makes sense even for the Linux distro
case (the one I am most concerned with at the moment), just so that
apps that don't use AWT or Swing don't really pay for it. The
The only reason to split it out would be to allow a libgcj
installation that is not
On Sun, 2005-05-08 at 23:34 +, Joseph S. Myers wrote:
> The following targets (based on wildcarded entries from config.gcc) do
> *not* appear to define NO_IMPLICIT_EXTERN_C, i.e. GCC is configured to
> suppose their headers are not C++-aware and to add an implicit extern
> "C" around them. Are
On Mon, 2005-05-09 at 03:03 +0100, Paul Brook wrote:
> On Monday 09 May 2005 02:26, Matt Kraai wrote:
> > Howdy,
> >
> > The rules for c-objc-common.o, loop-unroll.o, and tree-inline.o
> > include $(VARRAY_H), which is never defined, in their dependency
> > lists. The rest of the targets that depe
On Sun, May 08, 2005 at 07:31:38PM -0700, Matt Kraai wrote:
> On Mon, May 09, 2005 at 03:03:23AM +0100, Paul Brook wrote:
> > On Monday 09 May 2005 02:26, Matt Kraai wrote:
> > > Howdy,
> > >
> > > The rules for c-objc-common.o, loop-unroll.o, and tree-inline.o
> > > include $(VARRAY_H), which is n
On Sun, 2005-05-08 at 14:24 -0700, Richard Henderson wrote:
> On Sun, May 08, 2005 at 10:26:19PM +0200, Steven Bosscher wrote:
> > Oops. Not a modified tree, non-standard command line options:
> > -O -fgcse --param max-cse-path-length=1
>
> Ah, I see. Well, I think this is a misfeature of gcse i
On Monday 09 May 2005 02:26, Matt Kraai wrote:
> Howdy,
>
> The rules for c-objc-common.o, loop-unroll.o, and tree-inline.o
> include $(VARRAY_H), which is never defined, in their dependency
> lists. The rest of the targets that depend on varray.h include
> varray.h in their dependency list.
>
> v
> Joseph S Myers writes:
Joseph> Are there any in this list which should not be,
Joseph> i.e. which should be presumed to have C++-aware headers? Conversely,
Joseph> are there any in this list whose maintainers can confirm that the
Joseph> headers are not C++-aware and so the current configur
Howdy,
The rules for c-objc-common.o, loop-unroll.o, and tree-inline.o
include $(VARRAY_H), which is never defined, in their dependency
lists. The rest of the targets that depend on varray.h include
varray.h in their dependency list.
varray.h includes machmode.h, system.h, coretypes.h, and tm.h,
On Sun, May 08, 2005 at 04:40:00PM -0700, Gary Funck wrote:
>
>
> configuration: i386-redhat-linux (Redhat 9.2), gcc 3.3.6 ("make bootstrap"
> from
> the sources), and gdb "(5.3post-0.20021129.18rh)" as well as gdb 6.3 (latest)
> built from sources.
>
> I'm working on some changes to GCC 3.4.3,
On May 8, 2005, at 7:34 PM, Joseph S. Myers wrote:
In particular, I'm surprised at the Darwin configurations apparently
not defining NO_IMPLICIT_EXTERN_C, and at most OpenBSD configurations
not doing so (but alpha-openbsd gets it from alpha/alpha.h); VxWorks
configurations are also inconsistent in
The following targets (based on wildcarded entries from config.gcc) do
*not* appear to define NO_IMPLICIT_EXTERN_C, i.e. GCC is configured to
suppose their headers are not C++-aware and to add an implicit extern
"C" around them. Are there any in this list which should not be,
i.e. which should be
configuration: i386-redhat-linux (Redhat 9.2), gcc 3.3.6 ("make bootstrap" from
the sources), and gdb "(5.3post-0.20021129.18rh)" as well as gdb 6.3 (latest)
built from sources.
I'm working on some changes to GCC 3.4.3, which I've built using gcc 3.3.6.
The GCC (3.4.3) that I'm debugging is comp
[EMAIL PROTECTED] (Bob Proulx) writes:
> However if you are working in some port environment you may be
> trying to bootstrap these things along and may want/need gcc to get
> other components bootstrapped. You may not have a working system to
> begin with.
This is true, and we could improve the
Zack Weinberg wrote:
> Bernard Leak <[EMAIL PROTECTED]> writes:
> > Fine - but then it tells me (actually, the docs said this already)
> > that I need "the Mail program" in my path. Not wanting to be
> > obstructive or anything, but ... wot?
>
> This program should have been included with your op
Bernard Leak <[EMAIL PROTECTED]> writes:
> To submit the output of a gcc test run to the relevant mailing list,
> I'm enjoined to run an obfuscated script and pipe the output to sh.
> Fine - but then it tells me (actually, the docs said this already)
> that I need "the Mail program" in my path. N
Dear List,
apologies if this duplicates something, but *you*
try searching for
"Mail" in the mail archive...
To submit the output of a gcc test run to the relevant mailing list, I'm
enjoined
to run an obfuscated script and pipe the output to sh. Fine - but then
it tells me
(
On Sun, May 08, 2005 at 07:27:46PM +0200, Herman ten Brugge wrote:
> So here the sizeof(s) is also 1. This looks wrong to me as well.
It's correct.
> I can not find any refence in the gcc.info file about the sizeof an
> initialized structures with zero length arrays.
See ISO C99 6.7.2.1 paragra
On Sun, May 08, 2005 at 10:26:19PM +0200, Steven Bosscher wrote:
> Oops. Not a modified tree, non-standard command line options:
> -O -fgcse --param max-cse-path-length=1
Ah, I see. Well, I think this is a misfeature of gcse in how
it decides how to update expressions. With a bit more thought
w
> Kazu Hirata writes:
>
>> Nathan writes:
>> this is untrue. the elements hold the qualification.
>
> Then how do I know that an array is declared with const (or static
> const)? When I looked at the CONSTRUCTOR stored in the DECL_INITIAL
> of an array, I saw it with the TREE_STATIC flag set regar
On Sunday 08 May 2005 21:00, Richard Henderson wrote:
> On Sun, May 08, 2005 at 04:33:28PM +0200, Steven Bosscher wrote:
> > Can we expose this kind of address arithmetic to the tree
> > optimizers? Should we?
>
> No and no.
Clear enough :-)
> I've always believed that we'd be keeping an rtl gcs
On Sun, May 08, 2005 at 10:06:04PM +0200, Steven Bosscher wrote:
> A test case that shows what is going on is this:
>
> extern char *x;
> void
> foo (char *a, char *b)
> {
> if (!x)
> x = a;
> else
> x = b;
> }
This test case doesn't show anything. .04.cse merges all the high parts
o
On Sunday 08 May 2005 22:19, Richard Henderson wrote:
> On Sun, May 08, 2005 at 10:06:04PM +0200, Steven Bosscher wrote:
> > A test case that shows what is going on is this:
> >
> > extern char *x;
> > void
> > foo (char *a, char *b)
> > {
> > if (!x)
> > x = a;
> > else
> > x = b;
> >
On Sun, May 08, 2005 at 04:33:28PM +0200, Steven Bosscher wrote:
> Can we expose this kind of address arithmetic to the tree
> optimizers? Should we?
No and no. I've always believed that we'd be keeping an rtl gcse
pass exactly for the reason of address arithmetic.
r~
Snapshot gcc-4.1-20050508 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050508/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 CVS branch
with the following options: -D2005-05-08 17:43 UTC
You'll
I have a question about structures with zero length arrays. Lets start
with the example code:
struct {
char a;
char b[];
} s = {
'a',
"bc"
};
char a[] = { 'a', 'b', 'c' };
int
main(void)
{
printf("%d %d\n",sizeof(s),sizeof(a));
return 0;
}
When compiled with gcc the result is 1 3. I expecte
Nathan Sidwell schrieb:
Stefan Strasser wrote:
I don't know anything about fold but in general a c++ array in the
frontend is cv-qualified, not its elements.
this is untrue. the elements hold the qualification.
right
I have been processing large source codes including STL, boost and
custom code
On Sunday 08 May 2005 16:47, Nathan Sidwell wrote:
> Kazu,
>
> > Then how do I know that an array is declared with const (or static
> > const)? When I looked at the CONSTRUCTOR stored in the DECL_INITIAL
> > of an array, I saw it with the TREE_STATIC flag set regardless of
> > whether the array is
Kazu,
> Then how do I know that an array is declared with const (or static
> const)? When I looked at the CONSTRUCTOR stored in the DECL_INITIAL
> of an array, I saw it with the TREE_STATIC flag set regardless of
> whether the array is declared with const, so that's not useful to
> determine wheth
Hi,
This is another case where GCSE CPROP propagates a global constant
that we don't have exposed in the tree optimizers:
---
typedef enum
{
SUCCESS = 1,
FAILURE
} try;
typedef struct
{
unsigned entry:1;
unsigned use_assoc:1;
}
symbol_attribute;
extern try check_
Hi Nathan,
> this is untrue. the elements hold the qualification.
Then how do I know that an array is declared with const (or static
const)? When I looked at the CONSTRUCTOR stored in the DECL_INITIAL
of an array, I saw it with the TREE_STATIC flag set regardless of
whether the array is declared
Hi,
I have looked at the GCSE CPROP passes with CSE path following
disabled ("-O1 -fgcse --param max-cse-path-length=1"). The input
code are the cc1-i files from 20040726 (with checking enabled).
Maybe not really a surprise: Roughly 2/3 of the constants that
GCSE CPROP propagates are symbol_refs
Stefan Strasser wrote:
> I don't know anything about fold but in general a c++ array in the
> frontend is cv-qualified, not its elements.
this is untrue. the elements hold the qualification.
> I have been processing large source codes including STL, boost and
> custom code including function bod
Kazu Hirata schrieb:
I am trying to fold array[7] into 2. It turns out that if T is an
ARRAY_REF,
TREE_READONLY (TREE_OPERAND (T, 0))
is 0. Why?
I don't know anything about fold but in general a c++ array in the
frontend is cv-qualified, not its elements.
Another question. How is a RANGE_E
> Mike Stump <[EMAIL PROTECTED]>:
> On Thursday, May 5, 2005, at 02:53 PM, Andi Vajda wrote:
>> I wish the same were possible on Linux and Mac OS X but I have not
>> been able to create a shared library that is statically linked
>> against libgcj.a
> Should just work, though, you don't want
On Sunday 08 May 2005 06:11, Kazu Hirata wrote:
> I created an array with more than one thousand elements. I still did
> not see a RANGE_EXPR in the array's CONSTRUCTOR. How do I get a
> RANGE_EXPR in a CONSTRUCTOR?
IIRC G++ only builds RANGE_EXPRs for all-zero constructors.
Gr.
Steven
38 matches
Mail list logo
