Re: How to grow the Fortran I/O parameter struct and keep ABI compatibility
Suggestion: We should make sure we can accommodate F2003 with 4.2 and 4.3 by increasing the possible number of flags as needed. I'm in favour of that, and I already started writing the necessary patch. But it looks like we'll have to bump the so number a last time, for 4.3, and then make the private part of the structure wider, to accomodate any new flags (for things like extension, or the way we'll really handle asynchronous I/O). FX
Re: Canonical type nodes, or, comptypes considered harmful
Gaby says: > I believe we do care for good diagnostic purposes. Yes. Diagnostics are very important. Please let's not regress on this point. In a perfect world we'd get the diagnostic advantages of concepts with the ability to configure typedefs. Mike says: > As for warning/error messages, I'd hate to regress on that front. Doug, > as a heavy template user, I'm sure you've see plenty of warning/ error > messages... How important is the typedef name in your experience? Very important. In particular, for very heavily templatized code, typedefs are essential. We need more aggressive substitutions, not less. It's hard to decipher multi-paragraph type names without some kind of aliasing to shorter types. For good examples of this look at compile errors in pb_ds, the policy-based containers in libstdc+ +-v3/include/ext. I can come up with nightmare scenarios and suggestions if people are interested in specifics. However, any metaprogramming will also show these issues. My suggestion, which I've not seen here before, is to allow end-users to configure this. I see the need for both kinds of behavior: people who want to see the "real type" of the thing that they are using, and people who need "shorthands" to deal with complex types and the compilation errors that result (and will result, even with concepts.) Maybe: -Wtypedef-as-underlying-type This will also give programmers a way to make tradeoffs that impact compile-time performance. There's no need to hard wire this. -benjamin
Obtaining builtin function list.
How can I get a full list of all GCC C++ built-in functions that may be used on a given platform or GCC build? For example, __cxa_begin_catch(), __cxa_end_catch(), __builtin_memset ... I am currently working with GCC 4.0.1 source base. Thanks, Brendon.
Re: wiki topics wish (configuration related)
Hello Basile, * Basile STARYNKEVITCH wrote on Tue, Nov 07, 2006 at 11:19:16PM CET: > > http://gcc.gnu.org/wiki/AboutGCCConfiguration > > I borrowed a few sentences elsewhere, in particular from the autobook > http://sources.redhat.com/autobook/ by Gary V. Vaughan, Ben Elliston, > Tom Tromey and Ian Lance Taylor (I sent a small email to Gary about this). If you need a verbose introductionary tutorial to Autoconf and Automake that is not more or less outdated: http://www-src.lip6.fr/~Alexandre.Duret-Lutz/autotools.html The first chapter of the Automake 1.10 manual contains an abbreviated overview: http://sources.redhat.com/automake/automake.html#Autotools-Introduction The Autobook and the tutorial page http://inti.sourceforge.net/tutorial/libinti/autotoolsproject.html that is referred to in above wiki page refer to older versions of Autoconf and Automake, and thus omit newer constructs. Hope that helps. Cheers, Ralf
Re: 16 byte alignment hint for sse vectorization
I entirely agree. There definitely should be a PR for this, if there isn't
already.
dorit
"Michael James" <[EMAIL PROTECTED]> wrote on 05/11/2006 22:03:47:
> Hello Dorit,
>
> Thank you for the list of references.
>
> What I gathered from reading this is that alignment attributes applied
> to the base element of an array are causing problems for other
> legitimate uses of this attribute. It is basically stupid to specify
> the base type of an array be aligned because this implies that the
> array elements are scattered in memory. The only examples I can think
> of where you might want to do that is with multidimensional arrays
> where you want the start of each subarray to be aligned. That is
> better solved just by changing the length of the inner array to one
> that yields the desired alignment.
>
> However, specifying pointer alignment (whether this hint is passed
> through the type system or some other way) is an important piece of
> information that a programmer may wish to communicate to the
> optimizer. The obvious semantics for the hint are that the
> log2(alignment) least significant bits of the pointer value are clear.
> The size of the pointer base type would be unaffected so that pointer
> math can still yield unaligned access.
>
> I hope I have not oversimplified the issue at hand here. From the
> point of view of someone passively benefiting from the optimizer, this
> issue does not matter so much. However, someone who is performance
> tuning his code may care very much about getting this information
> through to the vectorizor and without some provision for a hint he is
> stuck either (1) without the optimization or (2) rewriting the code so
> that all aligned arrays are passed as pointer-to-struct with the array
> element in the struct specified with an alignment attribute. I have
> not tested method 2; it seems like a transformation which may work
> despite being unaesthetic.
>
> Regards,
> Michael James
>
> On 11/5/06, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
> > Unfortunately there's no way to specify alignment attribute of pointers
in
> > GCC - the syntax was allowed in the past but not really supported
> > correctly, and then entirely disallowed (by this patch
> > http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02284.html). This issue
was
> > discussed in details in these threads:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
> > http://gcc.gnu.org/ml/gcc/2005-03/msg00483.html
> > (and recently came up again also in
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827#c56).
> > The problem is that
> > "We don't yet implement either attributes on array parameters applying
to
> > the array not the pointer, or attributes inside the [] of the array
> > parameter applying to the pointer. (This is documented in "Attribute
> > Syntax".)" (from the above thread).
> >
> > dorit
> >
> >
> > > Hello,
> > >
> > > I have been playing with gcc's new (to me) auto vectorization
> > > optimizations. I have a particular loop for which I have made
external
> > > provisions to ensure that the data is 16-byte aligned. I have tried
> > > everything I can think of to give gcc the hint that it is operating
on
> > > aligned data, but still the vectorizer warns that it is operating on
> > > unaligned data and generates the less efficient MOVLPS/MOVUPS instead
> > > of MOVAPS.
> > >
> > > The code is like this:
> > >
> > > #define SSE __attribute__((aligned (16)))
> > >
> > > typedef float matrix_t[100][1024];
> > >
> > > matrix_t aa SSE, bb SSE, cc SSE;
> > >
> > > void calc(float *a, float *b, float *c) {
> > > int i, n = 1024;
> > >
> > > for (i=0; i > > a[i] = b[i] / (b[i] + c[i]);
> > > }
> > >
> > > }
> > >
> > > int main(void) {
> > > int i, n = 100;
> > > for (i=0; i > > calc(a[i], b[i], c[i]);
> > > }
> > > }
> > >
> > > gcc rejects if I specify alignment attributes on the formal
parameters
> > > (obviously it was dumb to even try that), and there does not seem to
> > > be a way to get the alignment hint to apply to the object referenced
> > > by the pointer instead of the pointer itself.
> > >
> > > In my application it is important that the function doing the
> > > computations remains abstracted away from the data definitions, as
> > > there is over 1G of data dynamically arranged and the actual
alignment
> > > provisions are made with mmap().
> > >
> > > Does anyone have a suggestion?
> > >
> > > Regards,
> > > Michael James
> >
> >
Re: Canonical type nodes, or, comptypes considered harmful
> My conclusion at the end was, the best speed up possible, isn't to > mess with the callers, but rather, to get types canonicalized, then > all the work that comptypes would normally do, hopefully, just all > goes away. Though, in the long run those quadratic algorithms have to > one day die, even if comptypes is fixed. My confusion here is how can you "canonicalize" types that are different (meaning have different names) without messing up debug information. If you have: Foo xyz; and you display xyz in the debugger, it needs to say it's type "Foo", not some similar-but-differently-named type. Or maybe this is C++-specific and isn't relevant in C, so I'm not going to understand it.
libgomp crash fix
Hi,
Bug #28468 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28468)
causes a crash of nearly every valid program that parallelizes a loop
through OMP when OMP_NUM_THREADS > 1.
The affected systems are probably all Linux/x86 systems on which a glibc
with LinuxThreads and without TLS is installed, and on which binutils
with __thread support were installed afterwards.
The typical gdb stack trace is like this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16386 (LWP 4985)]
gomp_iter_dynamic_next (pstart=0xbf7ffa94, pend=0xbf7ffa98) at
../../../gcc-4.2-20061031/libgomp/iter.c:189
189 start = ws->next;
(gdb) where
#0 gomp_iter_dynamic_next (pstart=0xbf7ffa94, pend=0xbf7ffa98) at
../../../gcc-4.2-20061031/libgomp/iter.c:189
#1 0x4001ca78 in gomp_loop_dynamic_next (istart=0xbf7ffa94, iend=0xbf7ffa98)
at ../../../gcc-4.2-20061031/libgomp/loop.c:248
#2 0x080486ed in main.omp_fn.0 ()
#3 0x4001de5d in gomp_thread_start (xdata=0xbfffe580) at
../../../gcc-4.2-20061031/libgomp/team.c:108
#4 0x4003bfe6 in pthread_start_thread (arg=0xbf7ffbe0) at manager.c:310
#5 0x4003c07f in pthread_start_thread_event (arg=0xbf7ffbe0) at manager.c:334
#6 0x4014e0aa in clone () from /lib/libc.so.6
What happens is that gomp_thread () returns a pointer to a memory area that
consistents entirely of zeroes.
The gomp_thread() definition in libgomp.h:227 is used, making an access to
%gs:0. This is wrong, because the libc in use does not support this %gs stuff.
So, the reason is that HAVE_TLS was defined although only binutils and gcc,
but not glibc, support TLS.
After I changed the GCC_CHECK_TLS macro to also test for libc support of
__thread, rebuilt libcomp/configure, ran "config.status --recheck" and
rebuilt and reinstalled libgomp, the crash went away.
Here is the fix. It tests whether __thread actually works, not only whether
it is syntactically valid for the compiler. I have already submitted
copyright assignment papers for GCC.
2006-11-07 Bruno Haible <[EMAIL PROTECTED]>
* config/tls.m4 (GCC_CHECK_TLS): Also check whether the libc supports
TLS via __thread.
*** config/tls.m4 2006-09-19 03:48:06.0 +0200
--- config/tls.m4.new 2006-11-08 01:47:33.0 +0100
***
*** 11,17
LDFLAGS="-static $LDFLAGS"
AC_RUN_IFELSE([__thread int a; int b; int main() { return a = b; }],
[have_tls=yes], [have_tls=no], [])
! LDFLAGS="$save_LDFLAGS"],
[have_tls=no],
[AC_COMPILE_IFELSE([__thread int foo;], [have_tls=yes], [have_tls=no])]
)])
--- 11,53
LDFLAGS="-static $LDFLAGS"
AC_RUN_IFELSE([__thread int a; int b; int main() { return a = b; }],
[have_tls=yes], [have_tls=no], [])
! LDFLAGS="$save_LDFLAGS"
! if test $have_tls = yes; then
! dnl So far, the binutils and the compiler support TLS.
! dnl Also check whether the libc supports TLS, i.e. whether a variable
! dnl with __thread linkage has a different address in different
threads.
! save_LDFLAGS="$LDFLAGS"
! LDFLAGS="-lpthread $LDFLAGS"
! AC_RUN_IFELSE([
! #include
!
! __thread int a;
! int *mainthread_a;
! int *subthread_a;
!
! void *subthread_func(void *arg)
! {
! subthread_a = &a;
! return 0;
! }
!
! int main()
! {
! pthread_t subthread;
! void *subthread_retval;
!
! mainthread_a = &a;
!
! if (pthread_create (&subthread, NULL, subthread_func, 0) != 0)
! return 2;
! if (pthread_join (subthread, &subthread_retval) != 0)
! return 3;
!
! return (mainthread_a == subthread_a);
! }],
! [have_tls=yes], [have_tls=no], [])
! LDFLAGS="$save_LDFLAGS"
! fi],
[have_tls=no],
[AC_COMPILE_IFELSE([__thread int foo;], [have_tls=yes], [have_tls=no])]
)])
Re: Canonical type nodes, or, comptypes considered harmful
Benjamin Kosnik <[EMAIL PROTECTED]> writes: [...] | My suggestion, which I've not seen here before, is to allow end-users | to configure this. I see the need for both kinds of behavior: people | who want to see the "real type" of the thing that they are using, and | people who need "shorthands" to deal with complex types and the | compilation errors that result (and will result, even with concepts.) | | Maybe: | -Wtypedef-as-underlying-type | | This will also give programmers a way to make tradeoffs that impact | compile-time performance. There's no need to hard wire this. Indeed. We already have -fdiagnostics-show-location=[once|every-line] -fdiagnostics-show-location apparebtly, we are missing -fdiagnostics-show-typedef-name -- gaby
Re: bootstrap on powerpc fails
On Tue, 7 Nov 2006, Mike Stump wrote: > On Nov 7, 2006, at 3:48 PM, Kaveh R. GHAZI wrote: > > Perhaps we could take a second look at this decision? The average > > system has increased in speed many times since then. (Although > > sometimes I feel like bootstrapping time has increased at an even > > greater pace than chip improvements over the years. :-) > > Odd. You must not build java. I *always* build java unless it's broken for some reason. I don't see what that has to do with it. Bootstrap times are increasing for me over the years regardless of whether I include java or not. This happens largely because more code is added to GCC, not always because compile-times get worse. Or e.g. top level bootstrap recompiles all the support libraries at each stage, whereas before it didn't. > I'd rather have one person that tests it occasionally and save the CPU > cycles of all the rest of the folks, more scalable. That doesn't give us the full advantage because (unlike tree checking) RTL checking errors are often very specific to the target implementation. So having a few of us use it doesn't help make sure the other targets also pass. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Abt RTL expression - combining instruction
Hi all, I have used cbranchmode4 instruction to generate combined compare and branch instruction. (define_insn "cbranchmode4" (set (pc) (if_then_else (match_operator:CC 0 "comparison_operator" [ (match_operand:SI 1 "register_operand" "r,r") (match_operand:SI 2 "nonmemory_operand" "O,r")]) (label_ref (match_operand 3 "" "")) (pc)))] This pattern matches if the code is of the form if ( h == 1) p = 0; if the code is of the form if (h), if (h >= 0) p = 0; Then it matches the seperate compare and branch instructions and not cbranch instruction. Can anyone point out where i am going wrong? Regards, Rohit On 06 Nov 2006 23:15:04 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: "Rohit Arul Raj" <[EMAIL PROTECTED]> writes: > I am trying to combine the compare and branch instruction. But my > instructions are not getting generated as my operands are not matched > properly. > > Previously for individual compare instructions, i had > operand 0 - Register operand > operand 1 - Non memory operand. > > For branch instruction, > operator 0 - compare operator > operand 1 - label. > > So when i combined compare and branch, i just superimposed both > statements with same conditions with > operand 0 - Register operand > operand 1 - Non memory operand > operator 2 - comparison operator > operand 3 - label. > > 1. Is it the right way to match operands and operators while combining > instruction? > 2. How to check where my instruction matching goes wrong? When writing an MD file you have to think about what you generate (insns/expanders with standard names) and what you recognize (insns). You have to always generate something which you can recognize. Anyhow, the easier way to generate a combined compare and branch instruction is to use an insn or expander with the cbranchMM4 standard name. See the documentation. Ian
Re: bootstrap on powerpc fails
On Tue, 7 Nov 2006, Mark Mitchell wrote: > > I object. > > Me too. > > I'm a big proponent of testing, but I do think there should be some > bang/buck tradeoff. (For example, we have tests in the GCC testsuite > that take several minutes to run -- but never fail. I doubt these tests > are actually buying us a factor of several hundred more quality quanta > over the average test.) Machine time is cheap, but human time is not, > and I know that for me the testsuite-latency time is a factor in how > many patches I can write, because I'm not great at keeping track of > multiple patches at once. > Mark Mitchell I can sympathize with that, I have a slightly different problem. Right now there are some java test that time-out 10x on solaris2.10. I run four passes of the testsuite with different options each time, so that 40 timeouts. (This is without any extra RTL checking turned on.) At 5 minutes each it adds up fast! http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00294.html Maybe in another six years cpu improvements will outpace gcc bootstrap times enough to reconsider. In the mean time, I would encourage anyone patching middle-end RTL files and especially backend target files to try using RTL checking to validate their patches if they have enough spare cpu and time. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Re: Canonical type nodes, or, comptypes considered harmful
On 11/8/06, Mike Stump <[EMAIL PROTECTED]> wrote:
On Nov 7, 2006, at 7:13 PM, Doug Gregor wrote:
> Now, how much do we worry about the fact that we won't be printing
> typedef names
The only potential language gotcha I can think of is:
5 If the typedef declaration defines an unnamed class (or enum), the
first typedef-name declared by the declaration to be that class
type
(or enum type) is used to denote the class type (or enum type)
for
linkage purposes only (_basic.link_). [Example:
typedef struct { } *ps, S; // S is the class name for linkage
purposes
--end example]
we still gotta get that right. I think this just changes the
underlying type and doesn't have any typedef bits to it.
Right. If we want to remember that the struct { } was originally
anonymous, we could just set a flag on the RECORD_TYPE.
As for warning/error messages, I'd hate to regress on that front.
Doug, as a heavy template user, I'm sure you've see plenty of warning/
error messages... How important is the typedef name in your experience?
As Benjamin said, it's very important, and we're not doing so well on
that front now. std::string is a particularly nasty case, because we
tend to print out the full template name rather than the typedef name.
Users would love us if we got this right :)
I agree, it will complicate things if we want the typedef name
around. I'm thinking of an inverse mapping that takes us from tuple
(context,type) to typedef name. I want to boost the typedef name
out, kinda like a flyweight pattern, but inverted, instead of
boosting the invariant out, I want to raise the variant (the typedef
name) out of the type. Imagine if we had a map (tuple(context, type)
-> typedef name, and when we wanted the possible typedef name, we
take the type and the context in which we got the type and look it up
in the map. If not found, no typedef name. If found, it is the
typedef name we're interested in. The benefit of this scheme would
be that constant time type equality operators remain constant time.
Producing error messages is slow, but we don't care about that.
Interesting idea; the constant time comparison could be win against
the almost-linear time we get with a union-find data structure.
However, this approach could have some odd side effects when there are
multiple mappings within one context. For instance, we could have
something like:
typedef int foo_t;
typedef int bar_t;
foo_t* x = strlen("oops");
The error message that pops out would likely reference "bar_t *"
rather than "foo_t *" or "int *", because bar_t was the last mapping
from "int" that would be in the context. The example above is silly,
but when we're instantiating a template, it's common to have lots of
typedef names that all instantiate to the same type.
This approach wouldn't help with the implementation of concepts,
because we need to be able to take two distinct types (say, template
type parameters T and U) and consider them equivalent in the type
system. We can't literally combine T and U into a single canonical
type node, because they start out as different types. Granted, we
could layer a union-find implementation (that better supports
concepts) on top of this approach.
For reference, here's the union-find implementation: we add a new kind
of _TYPE node that is just a new name for an existing type. This new
type node (let's call it TYPE_ALIAS_TYPE) only contains two things: a
name and a pointer to the underlying type. Now, we use TYPE_ALIAS_TYPE
in the AST, but whenever we need to do some kind of structural check
on the tree node, we need to follow the chain of TYPE_ALIAS_TYPEs to
get to the canonical type node, which I would call the
"representative" of the equivalence class of types. Any code that does
something like:
type = TREE_TYPE (exp);
if (TREE_CODE (type) == REFERENCE_TYPE)
type = TREE_TYPE (type);
would need to be modified to get the representation of "type" before
looking at its TREE_CODE, e.g.,
type = type_representative (TREE_TYPE (exp));
if (TREE_CODE (type) == REFERENCE_TYPE)
type = TREE_TYPE (type);
We could find all of these places by "poisoning" TREE_CODE for
TYPE_ALIAS_TYPE nodes, then patch up the compiler to make the
appropriate type_representative calls. We'd want to save the original
type for diagnostics.
An alternative to poisoning TREE_CODE would be to have TREE_TYPE do
the mapping itself and have another macro to access the original
(named) type:
#define TREE_TYPE(NODE) type_representative ((NODE)->common.type)
#define TREE_ORIGINAL_TYPE(NODE) ((NODE)->common.type)
There are other macros like TREE_TYPE that would also need this
change, but TREE_TYPE should cover most of it.
When implementing concepts, *every* _TYPE node can have a
representative that is different from itself.
> Since we know that type canonicalization is incremental, could we work
> toward type canonicalization in the GCC 4.3 time frame?
If by we you mean you, I don't see why that
Re: Abt RTL expression - combining instruction
"Rohit Arul Raj" <[EMAIL PROTECTED]> writes: > I have used cbranchmode4 instruction to generate combined compare and > branch instruction. > > (define_insn "cbranchmode4" > (set (pc) (if_then_else > (match_operator:CC 0 "comparison_operator" > [ (match_operand:SI 1 "register_operand" "r,r") > (match_operand:SI 2 "nonmemory_operand" "O,r")]) > (label_ref (match_operand 3 "" "")) > (pc)))] > This pattern matches if the code is of the form > > if ( h == 1) > p = 0; > > if the code is of the form > if (h), if (h >= 0) > p = 0; > > Then it matches the seperate compare and branch instructions and not > cbranch instruction. > > Can anyone point out where i am going wrong? If you have a cbranch insn, and you want that one to always be recognized, then why do you also have separate compare and branch insns? Ian
Re: Canonical type nodes, or, comptypes considered harmful
[EMAIL PROTECTED] (Richard Kenner) writes: > > My conclusion at the end was, the best speed up possible, isn't to > > mess with the callers, but rather, to get types canonicalized, then > > all the work that comptypes would normally do, hopefully, just all > > goes away. Though, in the long run those quadratic algorithms have to > > one day die, even if comptypes is fixed. > > My confusion here is how can you "canonicalize" types that are different > (meaning have different names) without messing up debug information. > If you have: > > Foo xyz; > > and you display xyz in the debugger, it needs to say it's type "Foo", not > some similar-but-differently-named type. > > Or maybe this is C++-specific and isn't relevant in C, so I'm not going to > understand it. The way to canonicalize them is to have all equivalent types point to a single canonical type for the equivalence set. The comparison is one memory dereference and one pointer comparison, not the current procedure of checking for structural equivalence. This assumes, of course, that we can build an equivalence set for types. I think that we need to make that work in the middle-end, and force the front-ends to conform. As someone else mentioned, there are horrific cases in C like a[] being compatible with both a[5] and a[10] but a[5] and a[10] not being compatible with each other, and similarly f() is compatible with f(int) and f(float) but the latter two are not compatible with each other. Fortunately C99 6.2.7 paragraph 2 says "all declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined." I think that is as close as C gets to the ODR, and I think it may give us the leeway we need to build an equivalence set for these awful cases. Ian
Re: Volatile operations and PRE
Paolo Bonzini wrote: The following patch fixes it, but it's completely untested. 2006-11-07 Paolo Bonzini <[EMAIL PROTECTED]> * gimplify.c (fold_indirect_ref_rhs): Use STRIP_USELESS_TYPE_CONVERSION rather than STRIP_NOPS. Index: ../../gcc/gimplify.c === --- ../../gcc/gimplify.c(revision 118481) +++ ../../gcc/gimplify.c(working copy) @@ -3207,7 +3207,7 @@ fold_indirect_ref_rhs (tree t) tree sub = t; tree subtype; - STRIP_NOPS (sub); + STRIP_USELESS_TYPE_CONVERSION (sub); subtype = TREE_TYPE (sub); if (!POINTER_TYPE_P (subtype)) return NULL_TREE; If anybody could regtest it, this is a regression from 3.3, likely to be present in all 4.x branches. I have tested it and ran the test suite and it does not seem to introduce problems in gcc or g++. I am using the gcc-4.3-20061104 snapshot and the results from http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00151.html. Best regards, Ricardo.
Re: Obtaining builtin function list.
Brendon Costa <[EMAIL PROTECTED]> writes: > How can I get a full list of all GCC C++ built-in functions that may be > used on a given platform or GCC build? > > For example, __cxa_begin_catch(), __cxa_end_catch(), __builtin_memset ... > > I am currently working with GCC 4.0.1 source base. Well, there is the documentation, e.g.: http://gcc.gnu.org/onlinedocs/gcc-4.0.3/gcc/Other-Builtins.html Or if you want to look at the source code, look at builtins.def and look for calls to add_builtin_function or lang_hooks.builtin_function in config/CPU/*.c. Well, that will tell you about functions like __builtin_memset: functions which are specially recognized and handled by the compiler. __cxa_begin_catch is a different sort of function, it is a support function which is called by the compiler. For the complete set of those functions, look at libgcc*.* and libsupc++.a in the installed tree (generally under lib/gcc/TARGET/VERSION). Those functions generally have no user-level documentation. Ian
Re: libgomp crash fix
On Wed, Nov 08, 2006 at 02:33:08PM +0100, Bruno Haible wrote: > * config/tls.m4 (GCC_CHECK_TLS): Also check whether the libc supports > TLS via __thread. Ok. r~
Re: Volatile operations and PRE
Paolo Bonzini writes:
>
> > At a wild guess, maybe strip_useless_type_conversions() is doing
> > something Bad.
>
> Almost there. It looks like strip_useless_type_conversions is not used,
> and then something Bad happens.
>
> The following patch fixes it, but it's completely untested.
>
> 2006-11-07 Paolo Bonzini <[EMAIL PROTECTED]>
>
> * gimplify.c (fold_indirect_ref_rhs): Use
> STRIP_USELESS_TYPE_CONVERSION rather than STRIP_NOPS.
>
> Index: ../../gcc/gimplify.c
> ===
> --- ../../gcc/gimplify.c(revision 118481)
> +++ ../../gcc/gimplify.c(working copy)
> @@ -3207,7 +3207,7 @@ fold_indirect_ref_rhs (tree t)
> tree sub = t;
> tree subtype;
>
> - STRIP_NOPS (sub);
> + STRIP_USELESS_TYPE_CONVERSION (sub);
> subtype = TREE_TYPE (sub);
> if (!POINTER_TYPE_P (subtype))
> return NULL_TREE;
>
> If anybody could regtest it, this is a regression from 3.3, likely to be
> present in all 4.x branches.
Regtested x86-64-gnu-linux. The only interesting failure was
mayalias-2.c, but that also fails before the patch.
Andrew.
$ /home/aph/gcc/gcc-4_2-branch/x86_64-unknown-linux-gnu/gcc/xgcc
-B/home/aph/gcc/gcc-4_2-branch/x86_64-unknown-linux-gnu/gcc/
/home/aph/gcc/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/mayalias-2.c
-w -O3 -g -fno-show-column -lm -o
/home/aph/gcc/gcc-4_2-branch/x86_64-unknown-linux-gnu/gcc/testsuite/gcc/mayalias-2.x4
/home/aph/gcc/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/mayalias-2.c:2:
internal compiler error: in splice_child_die, at dwarf2out.c:5565
Please submit a full bug report,
with preprocessed source if appropriate.
struct S { short x; };
typedef struct S __attribute__((__may_alias__)) test;
int f() {
int a=10;
test *p=(test *)&a;
p->x = 1;
return a;
}
int main() {
if (f() == 10)
__builtin_abort();
return 0;
}
RE: wiki topics wish (configuration related)
On 08 November 2006 12:25, Ralf Wildenhues wrote: > Hello Basile, > > * Basile STARYNKEVITCH wrote on Tue, Nov 07, 2006 at 11:19:16PM CET: >> >> http://gcc.gnu.org/wiki/AboutGCCConfiguration > If you need a [ ... ] > The first chapter of the Automake 1.10 manual [ ... ] > The Autobook and the tutorial page [ ... ] > Hope that helps. You don't really "get" wiki, do you? ;-) cheers, DaveK -- Can't think of a witty .sigline today
Re: Canonical type nodes, or, comptypes considered harmful
Ian Lance Taylor <[EMAIL PROTECTED]> writes: | [EMAIL PROTECTED] (Richard Kenner) writes: | | > > My conclusion at the end was, the best speed up possible, isn't to | > > mess with the callers, but rather, to get types canonicalized, then | > > all the work that comptypes would normally do, hopefully, just all | > > goes away. Though, in the long run those quadratic algorithms have to | > > one day die, even if comptypes is fixed. | > | > My confusion here is how can you "canonicalize" types that are different | > (meaning have different names) without messing up debug information. | > If you have: | > | > Foo xyz; | > | > and you display xyz in the debugger, it needs to say it's type "Foo", not | > some similar-but-differently-named type. | > | > Or maybe this is C++-specific and isn't relevant in C, so I'm not going to | > understand it. | | The way to canonicalize them is to have all equivalent types point to | a single canonical type for the equivalence set. The comparison is | one memory dereference and one pointer comparison, not the current | procedure of checking for structural equivalence. Yes, exactly. -- Gaby
Re: Canonical type nodes, or, comptypes considered harmful
"Doug Gregor" <[EMAIL PROTECTED]> writes:
| On 11/8/06, Mike Stump <[EMAIL PROTECTED]> wrote:
| > On Nov 7, 2006, at 7:13 PM, Doug Gregor wrote:
| > > Now, how much do we worry about the fact that we won't be printing
| > > typedef names
| >
| > The only potential language gotcha I can think of is:
| >
| > 5 If the typedef declaration defines an unnamed class (or enum), the
| >first typedef-name declared by the declaration to be that class
| > type
| >(or enum type) is used to denote the class type (or enum type)
| > for
| >linkage purposes only (_basic.link_). [Example:
| >typedef struct { } *ps, S; // S is the class name for linkage
| > purposes
| > --end example]
| >
| > we still gotta get that right. I think this just changes the
| > underlying type and doesn't have any typedef bits to it.
|
| Right. If we want to remember that the struct { } was originally
| anonymous, we could just set a flag on the RECORD_TYPE.
In our implementation, each class-type has a canonical type -- the
real class-name in most cases. For the case above, we use the typedef
name as the class-name (as granted by the C++ standard, quoted above).
The canonical type, in our implementation, is the "morally equivalent"
of GCC's RECORD_TYPE or UNION_TYPE.
-- Gaby
Re: Volatile operations and PRE
Andrew Haley <[EMAIL PROTECTED]> writes: > > 2006-11-07 Paolo Bonzini <[EMAIL PROTECTED]> > > > > * gimplify.c (fold_indirect_ref_rhs): Use > > STRIP_USELESS_TYPE_CONVERSION rather than STRIP_NOPS. > > Regtested x86-64-gnu-linux. The only interesting failure was > mayalias-2.c, but that also fails before the patch. This is OK for active branches. Thanks. Ian
Re: Canonical type nodes, or, comptypes considered harmful
* Ian Lance Taylor <[EMAIL PROTECTED]> [061108 16:15]: > This assumes, of course, that we can build an equivalence set for > types. I think that we need to make that work in the middle-end, and > force the front-ends to conform. As someone else mentioned, there are > horrific cases in C like a[] being compatible with both a[5] and a[10] > but a[5] and a[10] not being compatible with each other, and similarly > f() is compatible with f(int) and f(float) but the latter two are not > compatible with each other. Isn't void* and anyothertype* the same case? And how are classes and parent classes made compatible in C++? Is the front end always making a implicit type conversion or are they 'equivalent' in one direction? Hochachtungsvoll, Bernhard R. Link -- "Never contain programs so few bugs, as when no debugging tools are available!" Niklaus Wirth
Re: Canonical type nodes, or, comptypes considered harmful
"Bernhard R. Link" <[EMAIL PROTECTED]> writes: > * Ian Lance Taylor <[EMAIL PROTECTED]> [061108 16:15]: > > This assumes, of course, that we can build an equivalence set for > > types. I think that we need to make that work in the middle-end, and > > force the front-ends to conform. As someone else mentioned, there are > > horrific cases in C like a[] being compatible with both a[5] and a[10] > > but a[5] and a[10] not being compatible with each other, and similarly > > f() is compatible with f(int) and f(float) but the latter two are not > > compatible with each other. > > Isn't void* and anyothertype* the same case? No. What we are asking about here is which types are compatible in the sense that they may be applied to the same object. That is, these two declarations are permitted: int a[]; int a[10]; These two declarations are not permitted: void* p; int* p; This is because int[] and int[10] are compatible types, but that void* and int* are not compatible types. The relationship between int* and void* is that code is permitted to rely on an implicit conversion between the two types (in C; in C++ there is only an implicit conversion to void*, not away from it). > And how are classes and parent classes made compatible in C++? Is the > front end always making a implicit type conversion or are they 'equivalent' > in one direction? Again this is a case of type conversion, not type compatibility or equivalence. Ian
Re: wiki topics wish (configuration related)
* Dave Korn wrote on Wed, Nov 08, 2006 at 04:59:34PM CET: > >> http://gcc.gnu.org/wiki/AboutGCCConfiguration [...] > You don't really "get" wiki, do you? ;-) Oh, I didn't know this wiki was editable by anybody. I mistakenly inferred from notices on other wiki pages that there are restrictions and rules. Cheers, Ralf
Re: libgomp crash fix
On Wed, 2006-11-08 at 14:33 +0100, Bruno Haible wrote: > Hi, > > 2006-11-07 Bruno Haible <[EMAIL PROTECTED]> > > * config/tls.m4 (GCC_CHECK_TLS): Also check whether the libc supports > TLS via __thread. How well does this work with cross compiler? Thanks, Andrew Pinski
Re: Canonical type nodes, or, comptypes considered harmful
"Bernhard R. Link" <[EMAIL PROTECTED]> writes: | * Ian Lance Taylor <[EMAIL PROTECTED]> [061108 16:15]: | > This assumes, of course, that we can build an equivalence set for | > types. I think that we need to make that work in the middle-end, and | > force the front-ends to conform. As someone else mentioned, there are | > horrific cases in C like a[] being compatible with both a[5] and a[10] | > but a[5] and a[10] not being compatible with each other, and similarly | > f() is compatible with f(int) and f(float) but the latter two are not | > compatible with each other. | | Isn't void* and anyothertype* the same case? | And how are classes and parent classes made compatible in C++? For C++, in computing the canonical type, you typicall don't use "compatible." You ultimately use the quintescence of the ODR. void* is a type different from "anyothertype*". Similarly, a class is different from its base classes. | Is the | front end always making a implicit type conversion or are they 'equivalent' | in one direction? There is no implicit conversion. -- Gaby
RE: wiki topics wish (configuration related)
On 08 November 2006 16:19, 'Ralf Wildenhues' wrote: > * Dave Korn wrote on Wed, Nov 08, 2006 at 04:59:34PM CET: http://gcc.gnu.org/wiki/AboutGCCConfiguration > [...] >> You don't really "get" wiki, do you? ;-) > > Oh, I didn't know this wiki was editable by anybody. > I mistakenly inferred from notices on other wiki pages > that there are restrictions and rules. > > Cheers, > Ralf You need to get an account and sign in, but yes, this is an open-source and collaborative wiki, everyone is encouraged to contribute! :) Basile even said "Comments and improvements are welcome", I took the word improvements as meaning that no offense would be caused if someone was to build on and extend what's there. So I think there's no reason you shouldn't add some links to it yourself. cheers, DaveK -- Can't think of a witty .sigline today
Re: libgomp crash fix
Andrew Pinski wrote: > > 2006-11-07 Bruno Haible <[EMAIL PROTECTED]> > > > > * config/tls.m4 (GCC_CHECK_TLS): Also check whether the libc supports > > TLS via __thread. > > How well does this work with cross compiler? The proposed patch changes only the ACTION-IF-TRUE argument of an AC_RUN_IFELSE macro; it therefore has no effect on the situation of cross-compiling. When cross-compiling, only this test is executed: AC_COMPILE_IFELSE([__thread int foo;], [have_tls=yes], [have_tls=no]) You could try to add a check for TLS support in libc also for the cross- compiling case, but I don't know how to write such a check (for both GNU libc and Solaris libc) without relying on undocumented internals. Without such a check, people cross-compiling gcc have to think about --enable-tls or --disable-tls, whereas people doing a native build don't have to. Bruno
RE: How to grow the Fortran I/O parameter struct and keep ABI compatibility
On 08 November 2006 08:13, FX Coudert wrote: >> Suggestion: We should make sure we can accommodate F2003 with >> 4.2 and 4.3 by increasing the possible number of flags as needed. > > I'm in favour of that, and I already started writing the necessary > patch. But it looks like we'll have to bump the so number a last > time, for 4.3, and then make the private part of the structure wider, > to accomodate any new flags (for things like extension, or the way > we'll really handle asynchronous I/O). > > FX What's the problem with just adding a new 'extended private stuff' field to the very end of the struct and allocating one of the remaining flag bits to say if it's present or not? cheers, DaveK -- Can't think of a witty .sigline today
Re: How to grow the Fortran I/O parameter struct and keep ABI compatibility
What's the problem with just adding a new 'extended private stuff' field to the very end of the struct and allocating one of the remaining flag bits to say if it's present or not? That requires to have a version of the library that can work without it, and it's one more requirement on the code we write :) But we can do it, I guess. FX
Re: Obtaining builtin function list.
Thanks for the information. It was very helpful. I have now written some code (Seperate to gcc) that makes use of the builtins.def and associated def files to generate a list of all builtin functions as i require with the full prototypes as would be declared in say a header file. Are there also frontend specific builtins that I will need to handle in addition to those builtins defined in builtins.def? I am using the C++ front end and could not find any def files for C++ frontend builtins but your comment seemed to imply that front-ends could define their own set of builtin functions. As for the libsupc++.a and libgcc*.* libraries. Are they compiled with the newly generated gcc/g++ compilers or are they compiled with the compiler used to build gcc and g++? Thanks, Brendon. Well, there is the documentation, e.g.: http://gcc.gnu.org/onlinedocs/gcc-4.0.3/gcc/Other-Builtins.html Or if you want to look at the source code, look at builtins.def and look for calls to add_builtin_function or lang_hooks.builtin_function in config/CPU/*.c. Well, that will tell you about functions like __builtin_memset: functions which are specially recognized and handled by the compiler. __cxa_begin_catch is a different sort of function, it is a support function which is called by the compiler. For the complete set of those functions, look at libgcc*.* and libsupc++.a in the installed tree (generally under lib/gcc/TARGET/VERSION). Those functions generally have no user-level documentation. Ian
Re: Obtaining builtin function list.
Brendon Costa <[EMAIL PROTECTED]> writes: > Are there also frontend specific > builtins that I will need to handle in addition to those builtins > defined in builtins.def? No. > As for the libsupc++.a and libgcc*.* libraries. Are they compiled with > the newly generated gcc/g++ compilers or are they compiled with the > compiler used to build gcc and g++? They are compiled with the newly generated gcc/g++ compilers. Ian
Re: A weirdness in fortran/lang.opt, c.opt, and "cc1 --help".
On Wed, 2006-11-08 at 21:25 -0800, Brooks Moses wrote: > --- > ffixed-line-length-none > C ObjC > > ffixed-line-length- > C ObjC Joined > --- > > Thus, when one runs "cc1 --help" or "f951 --help", these lines of > documentation show up under the C section, not under the Fortran section. We should be able to remove them from c.opt now after the patch in 2005: 2005-11-04 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR fortran/18452 * c.opt: Add a -lang-fortran option. * c-opts.c: Add a lang_fortran flag. (c_common_init_options): Handling the -lang-fortran option. (c_common_handle_option): Add a case for Fortran options in preprocessing. Remove cases for -ffixed-form and -ffixed-line-length. Add a case for -lang-fortran. Thanks, Andrew Pinski
A weirdness in fortran/lang.opt, c.opt, and "cc1 --help".
There's something weird going on with Fortran's -ffixed-line-length options, and in how the lang.opt files get processed to produce the --help results from cc1 (and cc1plus, f951, etc.). Specifically, the fortran/lang.opt file contains the following lines: --- ffixed-line-length-none Fortran RejectNegative Allow arbitrary character line width in fixed mode ffixed-line-length- Fortran RejectNegative Joined UInteger -ffixed-line-length- Use n as character line width in fixed mode --- These are, so far as I know, quite definitely Fortran-specific concepts, and thus the options only make sense in Fortran. However, there are also the following rather mysterious lines in c.opt: --- ffixed-line-length-none C ObjC ffixed-line-length- C ObjC Joined --- Thus, when one runs "cc1 --help" or "f951 --help", these lines of documentation show up under the C section, not under the Fortran section. As best I can tell, these options are not actually handled in C or ObjC; grepping for OPT_ffixed in the gcc directory only finds the handling of the global "-ffixed-*" option in opts.c. And there's no mention of them in the GCC manual. Thus: Are these lines in c.opt irrelevant, or do they do something meaningful? Should they be there at all? If I introduce some other options starting with "ffixed", do I need to add similar lines for them in c.opt? - Brooks
Obtaining type equivilance in C front end
How do i determine if two type nodes in the C front end are equivilent? In C++ i use same_type_p() but do not see an equivilant for the C front end. Thanks, Brendon.
Re: Obtaining type equivilance in C front end
On Thu, 2006-11-09 at 06:17 +, Brendon Costa wrote: > How do i determine if two type nodes in the C front end are equivilent? > In C++ i use same_type_p() but do not see an equivilant for the C front end. Hi Brendon, Wouldn't the C++ one (mostly) be a superset of the C? Thanks, Sohail
