Re: Status of SEE and Autovectorization patches?
> Given that this is more than a bootstrap problem with non-default flags, > but testsuite regressions for gfortran and SPEC failures on a primary > platform, I think this falls under GCC's 48 hour rule. This simply > formalizes your phrase "short time frame" above, and means that it you're > unlikely to come up with a solution to these problems in the next day > or two, that you/we should simply disable -fsee from being turned on by > default at -O3. I will disable -fsee for being turned on by default at -O3. In parallel I will work to see what exactly are the x86 problems. In my opinion the current x86 problems are due to some patterns difficult to figure out on PowerPC, and a few safety tests will suffice to fix then (i.e. to prevent the optimization to be done in these problematic cases). Mirea
Disabling -fsee at -O3
Committed according to http://gcc.gnu.org/ml/gcc/2006-05/msg00185.html Mircea 2006-05-07 Mircea Namolaru <[EMAIL PROTECTED]> * opts.c (flag_see): remove its setting at -O3. Index: opts.c === --- opts.c (revision 113518) +++ opts.c (working copy) @@ -592,7 +592,6 @@ flag_inline_functions = 1; flag_unswitch_loops = 1; flag_gcse_after_reload = 1; - flag_see = 1; } if (optimize < 2 || optimize_size)
GCC 4.1.1/4.2.0 build failure with current binutils (iWMMXt)
I have built an EABI/iWMMXt Gentoo based system. The toolchain I used is
modified to add a Linux/EABI/iWMMXt target. It has been fine until I changed
my binutils from an earlier snapshot to a current version Gentoo 2.16.92,
csl-2_17-branch or CVS trunk. Now when attempting to build GCC (on the host) I
get the following error:
gcc -c -O2 -march=iwmmxt -mcpu=iwmmxt -pipe -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wold-style-definition
-Wmissing-format-attribute-DHAVE_CONFIG_H -I. -Icp
-I/var/tmp/portage/gcc-4.1.1/work/gcc-4.1-20060505/gcc
-I/var/tmp/portage/gcc-4.1.1/work/gcc-4.1-20060505/gcc/cp
-I/var/tmp/portage/gcc-4.1.1/work/gcc-4.1-20060505/gcc/../include
-I/var/tmp/portage/gcc-4.1.1/work/gcc-4.1-20060505/gcc/../libcpp/include
/var/tmp/portage/gcc-4.1.1/work/gcc-4.1-20060505/gcc/cp/typeck2.c -o
cp/typeck2.o
{standard input}: Assembler messages:
{standard input}:2391: Error: iWMMXt control register expected -- `tmcr
wcgr0,r1'
This occurs if I attempt to build GCC trunk or 4.1.1 and I suspect 4.1.0 but I
haven't tested it.
I have attached my patch for the Linux/EABI/iWMMXt target.
Steve
Send instant messages to your online friends http://uk.messenger.yahoo.com diff -urN gcc-4.1-20060407.orig/gcc/config/arm/iwmmxt-linux-elf.h gcc-4.1-20060407/gcc/config/arm/iwmmxt-linux-elf.h
--- gcc-4.1-20060407.orig/gcc/config/arm/iwmmxt-linux-elf.h 1970-01-01 01:00:00.0 +0100
+++ gcc-4.1-20060407/gcc/config/arm/iwmmxt-linux-elf.h 2006-04-12 19:35:18.140744636 +0100
@@ -0,0 +1,140 @@
+/* Definitions for Intel PXA270 running Linux-based GNU systems using ELF
+ Copyright (C) 1993, 1994, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
+ 2005, 2006
+ Free Software Foundation, Inc.
+ Contributed by Philip Blundell <[EMAIL PROTECTED]>
+
+ This file is part of GCC.
+
+ GCC is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published
+ by the Free Software Foundation; either version 2, or (at your
+ option) any later version.
+
+ GCC is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
+ License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; see the file COPYING. If not, write to
+ the Free Software Foundation, 51 Franklin Street, Fifth Floor,
+ Boston, MA 02110-1301, USA. */
+
+/* elfos.h should have already been included. Now just override
+ any conflicting definitions and add any extras. */
+
+/* Run-time Target Specification. */
+#undef TARGET_VERSION
+#define TARGET_VERSION fputs (" (Intel XScale-iWMMXt ARM GNU/Linux with ELF)", stderr);
+
+#undef TARGET_DEFAULT_FLOAT_ABI
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_HARD
+
+#undef TARGET_DEFAULT
+#define TARGET_DEFAULT (0)
+
+#define SUBTARGET_CPU_DEFAULT TARGET_CPU_iwmmxt
+
+#define SUBTARGET_EXTRA_LINK_SPEC " -m armelf_linux -p"
+
+/* Note - there are three possible -mfpu= arguments that can be passed to
+ the assembler:
+
+ -mfpu=softvfp This is the default. It indicates thats doubles are
+ stored in a format compatible with the VFP
+ specification. This is the newer double format, whereby
+ the endian-ness of the doubles matches the endian-ness
+ of the memory architecture.
+
+ -mfpu=fpa This is when -mhard-float is specified.
+ [It is not known if any XScale's have been made with
+ hardware floating point support, but nevertheless this
+ is what happens].
+
+ -mfpu=softfpa This is when -msoft-float is specified.
+ This is the normal behavior of other arm configurations,
+ which for backwards compatibility purposes default to
+ supporting the old FPA format which was always big
+ endian, regardless of the endian-ness of the memory
+ system. */
+
+#undef SUBTARGET_EXTRA_ASM_SPEC
+#define SUBTARGET_EXTRA_ASM_SPEC "%{!mcpu=*:-mcpu=iwmmxt} \
+ %{mhard-float:-mfpu=vfp} \
+ %{!mhard-float: %{msoft-float:-mfpu=softfpa;:-mfpu=softvfp}}"
+
+#undef MULTILIB_DEFAULTS
+#define MULTILIB_DEFAULTS \
+ { "marm", "mlittle-endian", "mhard-float", "mno-thumb-interwork" }
+
+/* Now we define the strings used to build the spec file. */
+#undef LIB_SPEC
+#define LIB_SPEC \
+ "%{pthread:-lpthread} \
+ %{shared:-lc} \
+ %{!shared:%{profile:-lc_p}%{!profile:-lc}}"
+
+/* The native Linux compiler doesn't build if enums are not int sized */
+#undef CC1_SPEC
+#define CC1_SPEC\
+ "%{!fshort-enums:%{!fno-short-enums:-fno-short-enums}} "
+#undef CC1PLUS_SPEC
+#define CC1PLUS_SPEC CC1_SPEC
+
+#define LIBGCC_SPEC "%{msoft-float:-lfloat} %{mfloat-abi=soft*:-lfloat} -l
Re: VLA/VM [*] bug fixes for C
On Sun, 7 May 2006, Neil Booth wrote:
> My front end, and Comeau's oneline compiler, both give a similar
> message:
>
> "/tmp/foo.c", line 10: error: expression must point to a complete type
> int r = (c1()
> ^
>
> which seems reasonable based on my understanding of composite types
> of VLA types: that either satisfies the requirements of, and therefore
> can be taken to be, the composite type.
I think the type's complete: the recursive application of the composite
type rules means that the composite of each [] and [VLA] pair is the
[VLA], yielding a composite type int (*(*(*)[d1()])[d2()])[d3()]; the
trouble being that d1(), d2() and d3() won't all have been evaluated when
the composite type is required.
(My model is that each array size expression initializes an implicit
temporary variable, and my example involves runtime access to those
variables while some are uninitialized.)
I think you only have free choice in composites of VLA types when
compositing [VLA1] and [VLA2], where if at runtime the two are unequal
then you have undefined behavior. (Given that one of [VLA1] and [VLA2]
might not be evaluated, and likewise when compositing [CONSTANT] and
[VLA], problems arise in those cases as well. My best suggested fix was:
6.7.5.2 pargraph 6 at end add "or one of the size specifiers (including
the case of a single size specifier where the other array type does not
include a size specifier) is not an integer constant expression and is not
evaluated during the flow of execution.")
If, instead of embedding the types in the expression, they were previously
defined as typedefs, so all the array size expressions had been evaluated,
I would say the code is well-defined.
int a, b, c, d, e, f;
void *p1(void), *p2(void), *p3(void);
int c1(void), c2(void);
int d1(void), d2(void), d3(void);
int z1(void), z2(void), z3(void);
int
h(void)
{
typedef int (*(*(*T1)[d1()])[])[];
typedef int (*(*(*T2)[])[d2()])[];
typedef int (*(*(*T3)[])[])[d3()];
int r = (c1()
? (z1(), (T1)p1())
: (c2()
? (z2(), (T2)p2())
: (z3(), (T3)p3())
)
)[a][b][c][d][e][f];
return r;
}
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: VLA/VM [*] bug fixes for C
Joseph S. Myers wrote:-
> > which seems reasonable based on my understanding of composite types
> > of VLA types: that either satisfies the requirements of, and therefore
> > can be taken to be, the composite type.
>
> I think the type's complete: the recursive application of the composite
> type rules means that the composite of each [] and [VLA] pair is the
> [VLA], yielding a composite type int (*(*(*)[d1()])[d2()])[d3()]; the
> trouble being that d1(), d2() and d3() won't all have been evaluated when
> the composite type is required.
Unfortunately the expression is a big mess. I hope you'll permit me
to examine the slightly simpler
int
h(void)
{
int r = (0 ? (int (*(*)[d1()])[]) p1(): (int (*(*)[])[d2()]) p2()
)[a][b][c][d];
return r;
}
which I believe is analogous and my front end similarly rejects.
The logic goes like so:
We are parsing a conditional expression. We have the true and false
branches. The branches have types
int (*(*)[d1()])[]
int (*(*)[])[d2()]
namely "pointer to incomplete array of ..." and "pointer to VLA of ...".
The unqualified forms of the pointed-to types are compatible.
The conditional expression therefore has type "pointer to appropriately
qualified form of the composite type" by 6.5.15p6.
For the composite type, 6.2.7p3 dash 1 applies, and the composite is
the VLA type. That VLA type is derived indirectly from an incomplete
type, and hence subscripting that incomplete type falls foul of the
contraint on the subscript operator.
I believe your example is the same, just with an extra level of nesting
from the nested conditional expression.
If you disagree could you point out the error in my reasoning?
Neil.
Re: VLA/VM [*] bug fixes for C
On Sun, 7 May 2006, Neil Booth wrote: > For the composite type, 6.2.7p3 dash 1 applies, and the composite is > the VLA type. That VLA type is derived indirectly from an incomplete > type, and hence subscripting that incomplete type falls foul of the > contraint on the subscript operator. > > I believe your example is the same, just with an extra level of nesting > from the nested conditional expression. > > If you disagree could you point out the error in my reasoning? I believe that "These rules apply recursively to the types from which the two types are derived." means that the composite of T1[variable] and T2[] is not T1[variable] but (composite(T1,T2))[variable]. I do not think interpreting "is that type" to override the recursivity makes sense, because it would yield self-contradictory results for the composite type of two VLA types which are compatible but not the same. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: Google SoC Project proposal: Wcoercion option
On 06/05/06, Mike Stump <[EMAIL PROTECTED]> wrote:
On May 4, 2006, at 4:44 PM, [EMAIL PROTECTED] wrote:
>>struct C : A, B { /* ... */ };
>
> I am sorry to say that I don't understand the definition of struct C.
C is derived from A and B. Only valid of course in C++.
OK. This is multiple inheritance. I must admit I have never used this
feature with structs. Also, my plan was to start with C and from
simple types to more complex ones. Nevertheless, this may be an
opportunity to refresh my C++ and also to learn about the internals of
g++ and how to properly define Wcoercion in the context of classes and
inheritance.
I created the following test program from your example:
#include
using namespace std;
struct A { int i; };
struct B { double i; };
struct C : A,B { long double i; };
void fB(struct B* b);
void fB(struct B* b)
{
cout << sizeof(b) << ", " << b << endl;
return;
}
void fC(struct C* c);
void fC(struct C* c)
{
cout << sizeof(c) << ", " << c << endl;
return;
}
int main(void)
{
struct C c;
cout << sizeof(&c) << ", " << &c << endl;
fB(&c);
fC(&c);
return 0;
}
The output is:
4, 0xbfe8c4f0
4, 0xbfe8c4f4
4, 0xbfe8c4f0
and thus, in the case of fB() there is a coercion that changes a value
that doesn't happen for fC(). However, you can never use b as (C *).
That would produce a compilation error.
Honestly, I see that there is a change of value, however, I don't see
what problems may arise from such change (apart from the situation
where you compare the values of the pointers). Until new arguments are
provided, my provisional decision would be to include this testcase as
one that should not generate a warning.
Gabriel, do you mind if I include your email address in the
description of the testcase for future reference?
Cheers,
Manu.
Re: Summer of Code project discussion
2006/5/4, Mark Mitchell <[EMAIL PROTECTED]>: In the long run, I don't think we really want to be using garbage collection at all. [...] All of the above should not in way be read as an argument against using the zone collector -- it's actually an argument in favor of improving the zone collector! It's going to take a while to do the bits above, and having better GC is going to help us until then. The great thing about the zone collector is that it's a step in the memory pool direction; it's zones can be the things I called pools. Whether we use GC on those pools, or turn the zones into obstacks, or whatever, is a separate step. Thanks for your long-term insights. I've done some quick hacking around the code to clear a thing or two for myself. Below are things I've found out. - Cygwin's mmap() is still buggy. There was a lot of work on it previously, the last message I could find on the subject was http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00521.html . It suggested, that Cygwin's mmap() maybe could be un-blacklisted now. Well, it cannot. Zone collector unearths the problem that munmap(address, some_amount) actually unmaps 64KB when some_amount is e.g. 20KB. I've tested both MMAP_ANON and /dev/zero. If anybody is interested, I can provide the testcases. If nobody is, then maybe someday I'll find time to make testcases directly against Cygwin libc. For GCC it means that any mmap'y collector, if it's to become a single GCC collector, will need additional work here. It is possible to implement a workaround (free only 64KB worth of adjacent free pages) at cost of some memory expense, or use valloc(), or the malloc() code from ggc-page. Of course, only the first option is viable for copying collector. I wonder if cygwin's mprotect() has a set of similar issues. - In other news, I've linked Boehm's GC with GGC, provided implementations for ggc_alloc_stat(), ggc_collect(), and stubbed out everything else. The result works only with disabled collection (i.e. Boehm's GC allocation routines and nothing else is used). Otherwise it collects identifier symbol table almost immediatelly after its creation. A little bit of debugging suggests that there is an issue of Boehm's GC being not aware of all roots. This can be solved either moving data structures living partly in malloc() memory, partly in GC memory to one of them or by registering additional roots with GC. - PCH support. I didn't spend enough time to investigate it, so please correct me if required. It seems that it would require either hacking inside of Boehm's GC, either factoring PCH out of GC with possible duplication of some data structures. It looks like PCH is an argument for keeping a custom collector inside of GCC. Regarding the overall plan, I'm thinking how much my previous plan changes in the face of long-term objectives. Probably not much, as both copying and generational collectors would be improvements of the zone collector, so things could be segregated into zones as GCC sees fit. On the other hand, it probably means, that going with Boehm's GC in less likely. Any comments? Now I'm off to write proposal for Google. -- Laurynas
Re: Summer of Code project discussion
On Sun, May 07, 2006 at 10:26:20PM +0200, Laurynas Biveinis wrote: > - Cygwin's mmap() is still buggy. There was a lot of work on it > previously, the last message I could find on the subject was > http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00521.html . It > suggested, that Cygwin's mmap() maybe could be un-blacklisted now. > Well, it cannot. Zone collector unearths the problem that > munmap(address, some_amount) actually unmaps 64KB when some_amount is > e.g. 20KB. I've tested both MMAP_ANON and /dev/zero. If anybody is > interested, I can provide the testcases. If nobody is, then maybe > someday I'll find time to make testcases directly against Cygwin libc. > > For GCC it means that any mmap'y collector, if it's to become a single > GCC collector, will need additional work here. It is possible to > implement a workaround (free only 64KB worth of adjacent free pages) > at cost of some memory expense, or use valloc(), or the malloc() code > from ggc-page. Of course, only the first option is viable for copying > collector. I wonder if cygwin's mprotect() has a set of similar > issues. Or just use 64K pages on Cygwin. It sounds like that's what's going on. We may be fetching the page size incorrectly from the system. In fact, see how bogus the code currently in ggc-zone.c is for the page size? I suspect Cygwin is blameless here. The runtime page size detection would probably work better (but it's slower). > - In other news, I've linked Boehm's GC with GGC, provided > implementations for ggc_alloc_stat(), ggc_collect(), and stubbed out > everything else. The result works only with disabled collection (i.e. > Boehm's GC allocation routines and nothing else is used). Otherwise it > collects identifier symbol table almost immediatelly after its > creation. A little bit of debugging suggests that there is an issue of > Boehm's GC being not aware of all roots. This can be solved either > moving data structures living partly in malloc() memory, partly in GC > memory to one of them or by registering additional roots with GC. Presumably you'd have to register all the GTY()'d roots... I don't know how that would work out. -- Daniel Jacobowitz CodeSourcery
Re: Summer of Code project discussion
Or just use 64K pages on Cygwin. It sounds like that's what's going on. We may be fetching the page size incorrectly from the system. In fact, see how bogus the code currently in ggc-zone.c is for the page size? Yes... I suspect Cygwin is blameless here. The runtime page size detection would probably work better (but it's slower). How much would be slower that, if it needs to be executed once per invocation? Looks like it's the way to go. -- Laurynas
Re: Summer of Code project discussion
On Sun, May 07, 2006 at 10:50:54PM +0200, Laurynas Biveinis wrote: > >I suspect Cygwin is blameless here. The runtime page size detection > >would probably work better (but it's slower). > > How much would be slower that, if it needs to be executed once per > invocation? Looks like it's the way to go. Calculating the page size is constant overhead; that's ignorable. However, having to load the page size from memory and do e.g. variable shifts on it when processing page-sized chunks of data is a bigger slowdown - IIRC it's the marking and sweeping loops that are the issue. I made the current hack after much profiling. The comments say that GGC_PAGE_SIZE must be no larger than the system's page size. In fact, the code already looks like it tries to handle G.pagesize > GGC_PAGE_SIZE. It looks to me as if the munmap thing you've found is simply something I didn't think about. It would probably need some changes to the free page list handling, but refusing to unmap things in chunks less than G.pagesize would probably not be hard. I think you could just leave them on the free_pages list. The thing to beware of there would be that the code in release_pages reads like it expects the free list to be in some sort of order. But really it's just an optimization to reduce the number of syscalls made. The free pages list is in no particular order. So if we _need_ to coalesce when releasing pages, then we'll have to do something like sort the free list. This only happens once per zone per collection, so sorting the free list before releasing pages probably won't add measurable time. -- Daniel Jacobowitz CodeSourcery
configure eerror, no acceptable cc found in$PATH, please help
dear gcc: when I try to install gcc 4.0 at my apple mac os X , 7.9.0 (by uname -r), when I ./configure it reply error as no acceptable cc found in $PATH if that need c compiler be install, please tell where, (if binary , please indicate the one not through MAC installer)? thanks your help in advance eric
SoC application draft (Re: Summer of Code project discussion)
Now I'm off to write proposal for Google. Application draft can be found at http://www.cs.aau.dk/~lauras/application.txt I haven't submitted it yet, so I can incorporate some corrections, if you have any comments. Thanks, -- Laurynas
Re: [off topic] fallow code removal
> Does anyone know of any tool that can help identify fallow routines? It's not a complete solution, but it is one tool that will contribute to your effort: Andrew Tridgell has written a script called `findstatic.pl' (Google for it) that will tell you which functions can be made static because they are not reference outside of their own object file. Once you do this, GCC will sometimes warn that they are defined but never used -- these can generally be removed. One difficulty with these methods is that condtional compilation will suggest that code is not used, when it may indeed still be used. In the end, you still need to use grep and read the code carefully. Cheers, Ben
Re: SoC application draft (Re: Summer of Code project discussion)
On Mon, May 08, 2006 at 02:52:46AM +0200, Laurynas Biveinis wrote: > >Now I'm off to write proposal for Google. > > Application draft can be found at > http://www.cs.aau.dk/~lauras/application.txt > I haven't submitted it yet, so I can incorporate some corrections, if > you have any comments. It seems fine to me. One note for copying collection; I don't know that you need to solve the local variables problem. What I did during development was support both copying and non-copying collection; there's at least one suitable point (probably more - I did not look very hard) for copying. -- Daniel Jacobowitz CodeSourcery
