Re: Mis-handled ColdFire submission?
Rask Ingemann Lambertsen wrote: My only critisism is that surely, all these improvements weren't carried out just last week. I.e. some of them could have been submitted earlier, thereby making them available to users earlier as well as preventing duplicate work. An example is PR target/28181, which was reported half a year ago and at least three people worked on fixing. So once your patches are ready, go ahead and submit them. We (well, Richard mainly) fixed several bugs that were also in mainline during the redevelopment of this coldfire port, and those did go into mainline. In preparing the patch set for submission, Richard found and fixed several additional bugs and made several improvements (such as RTL thunks) -- and that work was done just last month. It may be that 28181 was one that could have been submitted earlier, or perhaps Richard's fix relied on some piece of the reworking that isn't in mainline, or perhaps Richard fixed it during the merge (I don't recall). The major chunk of this reworking has been blocked from going into mainline because GCC was in stages 2 & 3 for much of this year. When it was in stage 1, we weren't in a position to add things coherently. We've not deliberately been holding back on patches that could have gone in earlier. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: PATCH RFA: Use years for ChangeLog names
Hans-Peter Nilsson wrote: On Sun, 6 Mar 2005, Ian Lance Taylor wrote: When I proposed this a couple of months ago, Hans-Peter objected: http://gcc.gnu.org/ml/gcc/2005-01/msg00640.html I honestly didn't understand the objection. Hans-Peter, let me know if you want to try again to explain it. Nope. If you feel strongly enough to rename and fiddle with the old files, go ahead. I still feel the change is unnecessary (and as such should only apply to new splits) but I don't feel strongly about it. I think this would be excellent. Many times I have had to go and do some gcc archeology to find some patch to backport to some old version of the compiler. The disconnect between changelog file names and dates is just one more thing that makes it an annoying process. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Bug 20375 - ia64 varadic regression
Bug 20375 is logged as a C++ bug, but it is a middle end
bug that cannot be expressed in C. Here's a reduced testcase
union U
{
void *m[7];
};
struct C;
void f(struct C *c, float f, union U, ...)
{ }
Notice that the last specified argument 'union U' has no name. when
compiled for ia64-hp-hpux11.23 with -mlp64 this ICEs because of this
bit of code in assign_parm_find_data_types
/* Set LAST_NAMED if this is last named arg before last anonymous args. */
if (current_function_stdarg)
{
tree tem;
for (tem = TREE_CHAIN (parm); tem; tem = TREE_CHAIN (tem))
if (DECL_NAME (tem))
break;
if (tem == 0)
data->last_named = true;
}
That triggers on the float argument, not union. Naming the union
makes it trigger on the union, and compilation succeeds. This is
clearly wrong.
The comment doesn't make sense, arguments with and without names can
be freely intermixed (in C++), and should not affect the ABI. As this
is to do with varadic parameters, is this really talking about the
last typed argument before the varadic ones? If that's so, why isn't
the test just to see if TREE_CHAIN (parm) is NULL? Later comments in
function.c mention that LAST_NAMED is misnamed. I'm confused about what
this is really testing for.
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Bug 20375 - ia64 varadic regression
Dave Korn wrote: There was under varargs, which didn't require to pass a named argument to va_start; it's only with stdargs that it would be impossible. I suspect that this is the underlying reason for the code having developed this way: sometimes the first variadic arg is the last named arg (stdargs), sometimes it is the first arg _after_ the last named arg. ah, yes, that explains the later comment /* Handle stdargs. LAST_NAMED is a slight mis-nomer; it's also true for the unnamed dummy argument following the last named argument. See ABI silliness wrt strict_argument_naming and NAMED_ARG. So we only want to do this when we get to the actual last named argument, which will be the first time LAST_NAMED gets set. */ I was trying to work out what the 'unnamed dummy argument' was. As we no longer support varargs, this can be excised. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Bug 20375 - ia64 varadic regression
Mark Mitchell wrote: Zack Weinberg wrote: So, in other words, if (current_function_stdarg) data->last_named = true; Actually, no: data->last_named = !TREE_CHAIN (parm); (This is the last "named" parameter iff it's the last parameter.) yes, this is essentially the patch I am testing. AFAICT Jim's comments were again about the confusing name of NAMED_PARM, and really is talking about non-varadic/varadic. At the moment I don't see how fixing this bug for ia64 breaks anything else (that wasn't already broken). nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: advice needed regarding c++ name mangling
Razya Ladelsky wrote: Hi, My case is this: I version the operator<< function and name it operator<<.number (creating an identifier which is not valid in the source code). The assembly name created for the versioned function is the same as the tree identifier, which is not valid for the assembler. I tried creating an assembly name into DECL_ASSEMBER_NAME (using decl_assembler_name()) as soon as a version is created. It didn't work. I guess there's something I am missing. I'd appreciate some advice :) could you step back and explain the big picture? nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: [Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary
Mark Mitchell wrote: Jason Merrill wrote: On Mon, 07 Mar 2005 11:49:05 -0800, Mark Mitchell <[EMAIL PROTECTED]> wrote: IMO, if these are C++-only, it's relatively easy to deprecate these extension -- but I'd like to hear from Jason and Nathan, and also the user community before we do that. Of all the extensions we've had, this one really hasn't been that problematic. I agree it hasn't been problematic. I suspect that part of the reason for that is that it hasn't been used. I would not object to deprecating the syntax extension. Nathan, what say you? I think that if you're in agreement, we can go ahead and deprecate this extension. I suspect it's not used much -- I remember being surprised when I realized we had it at the syntax level. I don't find '?' to be particularly mnemonic. Using nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Merging calls to `abort'
Richard Stallman wrote: Otherwise, we need to consider the merits of disabling an optimization to make debugging easier. Optimizing calls to `abort' doesn't offer much benefit, so I think in this particular case it is worth disabling cross-jumping. This is a difficult choice to make, but at -O2, I'd prefer that we optimize, and suggest other debugging techniques intead of relying on the line numbers of abort calls. The sole purpose of optimization is to satisfy users more. If the 'abort: core dumped' is not a good user experience. If code is being shipped with naked aborts in it, that is where the problem lies. If cross jumping makes debugging harder, tough -- debugging is hard, debugging optimized programs is harder. Using abort, rather than assert is not sensible. I wonder what the size tradeoff is between using non-cross jumped aborts and using asserts ... nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
PR 20505
Bug 20505 is an ICE with -ggdb2. We have the following member definition, const int b::d = ((int)(&((b*)1)->c) - 1); whose initializer used to be folded during construction to an INT_CST, but now it doesn't -- fold cannot fold the complete expression. As the PR says, this was changed by, 2004-08-30 Richard Henderson <[EMAIL PROTECTED]> * class.c (build_base_path): Use build_address directly. * typeck.c (build_unary_op): Don't lower &a.b to pointer arithmetic directly. * typeck2.c (store_init_value): Don't assume !TREE_CONSTANT means !initializer_constant_valid_p. The dwarf outputter fails when outputting the constant value of that decl, because it expects an INT_CST. I was puzzled as to why we don't get the same failure for a similar struct without a virtual function. The answer is in that case we don't defer outputting the debug info when the class is complete. And at that point the static member has no initializer. We defer in the virtual case in an effort to reduce debug data. My inclination is to simply add an additional check in the dwarf outputter, verifying that the initializer is indeed an INT_CST. Am I missing something? nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Profile-directed feedback and remote testing
Joe Buck wrote: That wouldn't have saved me in the case described above, as the pathnames are already set in the executable. A *runtime* way of altering the locations of the .gcda files would be nice to have. For example, we could have something like GCDA_PATH_PREFIX which, if set, would be prepended to the pathnames of the .gcda files. We could even arrange to create needed directories on demand when creating new .gcda files when this option is set. I've had contact with a user who had exactly this (and other) issues, and had worked up some pre 3.4 patches. He was going to work out something along Joe's suggestion for the current sources. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel
Denis Vlasenko wrote: Disassembly of section .text: e: e8 fc ff ff ff call f f: R_386_PC32 memcpy #define memcpy(t, f, n) \ (__builtin_constant_p(n) ? \ __constant_memcpy((t),(f),(n)) : \ __memcpy((t),(f),(n))) given this #define, how can 'memcpy' appear in the object file? It appears that something odd is happening with preprocessing. Check the .i files are as you expect. -dD and -E options will be helpful to you. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: symbol_ref constants
Sanjiv Kumar Gupta wrote: add symbol_ref + const_int, r1 The relocation entry generated for this insn look like symbol + addend. The resultant value is beoyond the relocation size, and results into relocation overflow. I guess CSE will not do this if I exclude constants like symobol_ref + const_int from the insn pattern. Currently I allow "nonmemory_operand" for this insn. If your add instructions cannot take symbol refs, then you need a different predicate -- const_int_operand would probably be correct. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: PR 20505
James E Wilson wrote:
Nathan Sidwell wrote:
My inclination is to simply add an additional check in the dwarf
outputter,
verifying that the initializer is indeed an INT_CST.
That is a simple solution, but it causes us to lose debug info.
correct -- but we also don't output such info for out-of-class definitions
of such constants (i.e. we're already somewhat deficient).
TREE_INT_CST_{LOW,HIGH}. That should be safe. On mainline, I think we
should try supporting everything here and see what happens.
Makes sense.
Being conservative I'd go for my patch on 4.0 and yours (if verified) on
mainline.
thanks for your comments.
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: symbol_ref constants
Sanjiv Kumar Gupta wrote: Thanks for a prompt reply, Nathan. The add insn can take a symbol_ref, which is converted to const_int during relocation. But I don't want to allow expressions like (const:SI (plus:SI symbol_ref:SI) (const_int)) in the insn. How should I do that, do I need to implement LEGITIMATE_CONST_P () accordingly? you could do that, but I don't understand why symref+const is not allowed. After all, you could have a different plain symref whose value was the original symbol+const. I.e. why is add r1,foo+10 not allowed, but add r1,baz allowed. When linking baz could be defined as 'foo+10'. so what's going on? nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: symbol_ref constants
Sanjiv Kumar Gupta wrote: calculated by linker. Now add r1, foo add r1, 10 add r1, -10 are okay but add r1, foo + 10 add r1, -10 are not, since (foo + 10) may overflow during relocation, so the value (foo + 10) && 0xff inserted by linker is not correct. What is stopping the value of 'foo' itself being > 255? nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: PR 20505
James E Wilson wrote:
Nathan Sidwell wrote:
Being conservative I'd go for my patch on 4.0 and yours (if verified) on
mainline.
I'm fine with that. Have you actually written a patch yet? I don't see
one in the bug report or in gcc-patches.
My mistake. I'd forgotten the post-to-list part :)
Here it is, ok?
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
2005-04-01 Nathan Sidwell <[EMAIL PROTECTED]>
PR debug/20505
* dwarf2out.c (tree_add_const_value_attribute): Only add if it's
an INT_CST.
Index: dwarf2out.c
===
RCS file: /cvs/gcc/gcc/gcc/dwarf2out.c,v
retrieving revision 1.572
diff -c -3 -p -r1.572 dwarf2out.c
*** dwarf2out.c 19 Mar 2005 03:06:51 - 1.572
--- dwarf2out.c 23 Mar 2005 12:13:23 -
*** tree_add_const_value_attribute (dw_die_r
*** 10156,10181
tree init = DECL_INITIAL (decl);
tree type = TREE_TYPE (decl);
! if (TREE_READONLY (decl) && ! TREE_THIS_VOLATILE (decl) && init
! && initializer_constant_valid_p (init, type) == null_pointer_node)
! /* OK */;
! else
return;
!
! switch (TREE_CODE (type))
! {
! case INTEGER_TYPE:
! if (host_integerp (init, 0))
! add_AT_unsigned (var_die, DW_AT_const_value,
!tree_low_cst (init, 0));
! else
! add_AT_long_long (var_die, DW_AT_const_value,
! TREE_INT_CST_HIGH (init),
! TREE_INT_CST_LOW (init));
! break;
!
! default:;
! }
}
/* Generate a DW_AT_name attribute given some string value to be included as
--- 10156,10177
tree init = DECL_INITIAL (decl);
tree type = TREE_TYPE (decl);
! if (!init)
return;
! if (!TREE_READONLY (decl) || TREE_THIS_VOLATILE (decl))
! return;
! if (TREE_CODE (type) != INTEGER_TYPE)
! return;
! if (TREE_CODE (init) != INTEGER_CST)
! return;
!
! if (host_integerp (init, 0))
! add_AT_unsigned (var_die, DW_AT_const_value,
!tree_low_cst (init, 0));
! else
! add_AT_long_long (var_die, DW_AT_const_value,
! TREE_INT_CST_HIGH (init),
! TREE_INT_CST_LOW (init));
}
/* Generate a DW_AT_name attribute given some string value to be included as
// Copyright (C) 2005 Free Software Foundation, Inc.
// Contributed by Nathan Sidwell 1 Apr 2005 <[EMAIL PROTECTED]>
// { dg-options "-ggdb2" }
// Origin: ivan <[EMAIL PROTECTED]>
// [EMAIL PROTECTED]
// Bug 20505: ICE with -ggdb2
struct b
{
static const int d;
virtual bool IsEmpty() const=0;
int e,c;
};
const int b::d = ((int)(&((b*)1)->c) - 1);
Re: PR 20505
James E Wilson wrote: The testcase is not portable, as I pointed out in the PR. Trying this on an x86_64-linux system, I get 27 "excess errors" failures. All of them are error: cast from 'int*' to 'int' loses precision Using long works better than int, but is still not fool proof, as there are targets where longs are smaller than pointers. Maybe we can rely on something like ptrdiff_t? IIRC there's an available cpp #define. I will find it an amend as appropriate. thanks for the review. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Use Bohem's GC for compiler proper in 4.1?
Zack Weinberg wrote: Robert Dewar <[EMAIL PROTECTED]> writes: Zack Weinberg wrote: Last year CodeSourcery had a contract to speed up the C++ front end at -O0, and we found that small linear reductions in memory usage corresponded directly to small linear reductions in time usage, at about a 2:1 ratio (so 1% less memory -> 0.5% less time). That wouldn't be worth bothering with except that there are *lots* of places where such reductions are available. We eventually got something like a 40% overall speedup just from this. (Sorry, I haven't got exact numbers.) Right I am aware of that work, but we are talking now, so the question is do similar opportunities still exist? Absolutely. Most of the memory-saving potential discussed in my and Nathan Sidwell's paper from last GCC summit, for instance, remains unrealized. It's unclear whether Robert means 'similar small linear' opportunities, or 'any memory reduction' opportunities. IMO most of the former opportunities have been got for unoptimized generation. Towards the end of the speedup work Zack mentions, we ran into more and more non-local connections and other such entanglements. The more ambituous stuff Zack and my paper talked about are rather non-local and would need coordinated effort to realize (and a more fully baked design :). nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: PR 20505
James E Wilson wrote:
The testcase is not portable, as I pointed out in the PR. Trying this
on an x86_64-linux system, I get 27 "excess errors" failures. All of
them are
error: cast from 'int*' to 'int' loses precision
Using long works better than int, but is still not fool proof, as there
are targets where longs are smaller than pointers. Maybe we can rely on
something like ptrdiff_t?
Here's the testcase I installed. I also put it on mainline, as I couldn't
see one that you'd installed.
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
2005-04-04 Nathan Sidwell <[EMAIL PROTECTED]>
PR debug/20505
* g++.dg/debug/const2.C: New.
Index: testsuite/g++.dg/debug/const2.C
===
RCS file: testsuite/g++.dg/debug/const2.C
diff -N testsuite/g++.dg/debug/const2.C
*** /dev/null 1 Jan 1970 00:00:00 -
--- testsuite/g++.dg/debug/const2.C 4 Apr 2005 09:29:12 -
***
*** 0
--- 1,15
+ // Copyright (C) 2005 Free Software Foundation, Inc.
+ // Contributed by Nathan Sidwell 1 Apr 2005 <[EMAIL PROTECTED]>
+
+ // { dg-options "-ggdb2" }
+ // Origin: ivan <[EMAIL PROTECTED]>
+ // [EMAIL PROTECTED]
+ // Bug 20505: ICE with -ggdb2
+
+ struct b
+ {
+ static const int d;
+ virtual bool IsEmpty() const=0;
+ int e,c;
+ };
+ const int b::d = ((__SIZE_TYPE__)(&((b*)1)->c) - 1);
Re: gcc4, namespace and template specialization problem
tbp wrote:
Hello,
i'm a bit puzzled by the behaviour of gcc4 (old 4.0 & recent 4.1
snapshots) regarding how template specialization should be qualified
wrt namespace:
It has to be written this way:
namespace dummy {
template<> void dummy::foo::f<666>() {}
or
template<> void foo::f<666>() {}
}
correct.
Am i missing something obvious?
well, not 'obvious', but that is what [14.7.3]/2 says.
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: gcc4, namespace and template specialization problem
tbp wrote:
On Apr 4, 2005 11:54 AM, Nathan Sidwell <[EMAIL PROTECTED]> wrote:
Am i missing something obvious?
well, not 'obvious', but that is what [14.7.3]/2 says.
I especially don't quite get why specialization have to be defined
that way when non specialized version don't have to, ie that is legit:
namespace dummy {
struct foo {
template void f();
};
}
template void dummy::foo::f() { }
That's not a declaration, it's a definition of an already declared fn.
the case you had was a definition that was _also_ a declaration.
You can write
namespace dummy {
template<> void foo::f<666>(); // declaration
}
template<> void dummy:foo::f<666>() {} // definition
See the difference?
Although it is kind of quirky that you can declare member function
specializations
outside of the class, but not outside of the namespace.
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: gcc4, namespace and template specialization problem
tbp wrote: Sorry for the noise, but i don't own a copy of that byzantine standard. np. to paraphrase another thread 'here's 18$, go get yourself one'[1] nathan [1] available electronically from ansi or iso or some web site. -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]
Andrew Haley wrote: Might it still be possible for a front end to force all pending code to be generated, even with -fno-unit-at-a-time gone? I think this is a bad idea. You're essentially asking for the backend to retain all the functionality of -fno-unit-at-a-time. Might I refer you to Mike Stump's answer regarding swap :) nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]
Andrew Haley wrote: Nathan Sidwell writes: > Andrew Haley wrote: > > > Might it still be possible for a front end to force all pending code > > to be generated, even with -fno-unit-at-a-time gone? > > I think this is a bad idea. You're essentially asking for the backend > to retain all the functionality of -fno-unit-at-a-time. OK. So, what else? As steven asked, I'd like to understand why this is not a problem for the C++ community. There are several alternatives 1) The C++ programs are smaller than the java programs 2) the c++ representation is denser 3) the c++ users have more memory 4) The ones the C++ community *has* complained about are seen as pathelogical cases or acknowledged IR deficiencies 5) The c++ community are too timid to complain > Might I refer you to Mike Stump's answer regarding swap :) I haven't seen it. It was basically 'get more memory'. I'd like to understand if you're really talking about 'when I compile this humungous source, I need a lot of memory', or if it's 'when I compile this source, I use more memory than is reasonable'. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]
Andrew Haley wrote: Nathan Sidwell writes: > 1) The C++ programs are smaller than the java programs That's my guess. Usually, C++ users compile one source file at a time, whereas Java users find it convenient to compile a whole archive. ok, thanks. This sounds like you're really in an IMA mode :) If I understand java archives correctly, they're really a set of concatenated TUs, so could be compiled individually and then having a final link. That would more naturally match other language's uses of the toolchain. you'd like the backend to handle the breaking appart bit (by preserving no-unit-at-a-time). I think that's merely pushing the complexity out of the java FE and into the backend. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
RFC:Updated VEC API
Hi, I promised to fix up the vector api, and there's a design decision which needs to be made (incidentally, if we were in C++ land, we wouldn't have to chose, as the right thing just happens). The old API keyed the allocation strategy off the type name. This led to the lovely typedef tree tree_on_heap; so we could have heap allocated vectors of trees (as well as the default gc allocated ones). We want to separate this, so you'd now say something like DEF_VEC(tree,heap); DEF_VEC(tree,gc); ... VEC(tree,heap) *on_heap; VEC(tree,gc) *in_gc; Now, certain vector accessors need to know the allocation mechanism (appending for instance), and others don't (indexing, for instance). We also need to obey the one definition rule. option1) Require the allocation mechanism to be mentioned in *all* vector API calls. So you'd have 'VEC_append (tree,gc,v,t)', but you'd also have 'VEC_length (tree,gc,v)', which is kind of annoying. option2) Split the DEF_VEC operation into DEF_VEC and DEF_VEC_ALLOC parts. The former would define all the non-allocation sensitive routines, and the latter defines all the allocation specific ones. So now when defining a vector type you'd have DEF_VEC(tree); // define the common tree routines DEF_VEC_ALLOC(tree,gc); // define the gc tree routines DEF_VEC_ALLOC(tree,heap); // define the heap tree routines But you can now say 'VEC_length (tree,v)', without caring whether it's a gc'd or heap allocated vector. Unfortunately, now there must be *exactly* one invocation of DEF_VEC(tree), regardless of where the DEF_VEC_ALLOC calls are, which is also annoying. Option1 is more easy to implement. Option2 requires a little nested structure jiggery pokery to retain type safety. So which has the more annoying downside, or alternatively, the more satisfactory upside? Another option, is whether the type and allocation parameters of the API calls are themselves parenthesized into a single macro argument, as in VEC_append ((tree,gc),v,t) Would this be a suitable visual aid to make those stand out as 'not expressions'? (In C++ land, you'd write it as 'VEC_append (v,t)', if you really wanted a template-id-expr. Mostly you'd just let template deduction DTRT and have a plain 'VEC_append (v,t)') comments? nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Heads-up: volatile and C++
Jason Merrill wrote:
The C++ committee (well, a subgroup represented at this meeting by Hans
Boehm) is working on a memory model that supports threaded programs. One
proposed change is to the semantics of volatile. Currently, volatile
semantics are constrained by:
6 The observable behavior of the abstract machine is its sequence of
reads and writes to volatile data and calls to library I/O
functions.6)
7 Accessing an object designated by a volatile lvalue (_basic.lval_),
modifying an object, calling a library I/O function, or calling a
function that does any of those operations are all side effects, which
are changes in the state of the execution environment. Evaluation of
an expression might produce side effects. At certain specified points
in the execution sequence called sequence points, all side effects of
previous evaluations shall be complete and no side effects of
subsequent evaluations shall have taken place.7)
My reading of this is that currently, a volatile read or write should act
as a barrier to other writes ("modifying an object"), because generally
there will be a sequence point between those writes and the volatile
access.
Could you clarify whether 'other writes' means 'other _volatile_ writes',
or '_any_ other writes'? Since non-volatile writes are not visible
outside of the abstract machine, how can they be ordered wrt volatiles?
It seems to me that threads require barriers _within_ the abstract machine,
and currently there is no mechanism to specify just that. Volatile is all
we have, and AFAICT those are only ordered WRT other volatile accesses
separated by a sequence point.
It appears to me that the proposal is providing more restrictions
on volatile and other accesses, not fewer -- and cursorily that seems
sane.
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Questions on CC
Timothy Bowers wrote: I am trying to install gcc on RedHat Enterprise Linux 3. I do not have a compiler installed on the system. I see that gcc requires a ISO C90 compiler. Where can I get one? Also, when I try to configure gcc for install, I get an error that states that I need to set cc environmental variable to a working compiler. I think this will be taken care of when I install a ISO C90 compiler. Any help you can give me would be great. you should install the gcc package from RedHat. Then you can use that directly, or build your own (updated?) version from source. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Heads-up: volatile and C++
Jason Merrill wrote: On Thu, 14 Apr 2005 17:11:58 +0100, Nathan Sidwell <[EMAIL PROTECTED]> wrote: Could you clarify whether 'other writes' means 'other _volatile_ writes', or '_any_ other writes'? Since non-volatile writes are not visible outside of the abstract machine, how can they be ordered wrt volatiles? Any others. I was basing that on the requirement that the side-effects of those writes are required to be complete, though I suppose you could argue that they aren't required to be visible outside the current thread. Can you clarify whether threads are being considered as a) parts of a single abstract machine (which will therefore need extending in the std) b) separate abstract machines. It's not clear to me which is the best approach. (b) allows threads to be supported via copious uses of volatile (but probably introduces pessimizations), whereas (a) forces the thread interactions to be compiler visible (but shows more promise for optimizations). nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: What's the fate of VARRAY_*?
Kazu, Now that you've checked in your new VEC API, I think that's strictly more powerful than VARRAY. Should we start converting uses of VARRAY to VEC? I'd be happy to help out here. I think it would be an excellent idea! I'm still going through assertifying things. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: tcc_statement vs. tcc_expression in the C++ frontend
Ian Lance Taylor wrote: The description of tcc_statement in tree.h says "A statement expression, which have side effects but usually no interesting value." There are a number of entries in cp/cp-tree.def which are marked as tcc_expression, although they seem to me to be better described as tcc_statement, to wit: In a quick look at the C++ front end, I can only find one bit of code which cares whether it is looking at a tcc_expression or a tcc_statement: value_dependent_expression_p in pt.c. That function will always return false for a statement. For all of the tree codes listed above, currently class tcc_expression, the function will call itself recursively on expression operands. I haven't tried to track all the calls to see whether any of the above codes can be passed to value_dependent_expression_p, but it doesn't seem likely. None of the statement nodes you mention can be value dependent. If that's the only place that cares, they should be tcc_statement. Anyhow, I'm testing the obvious patch to use tcc_statement instead of tcc_expression in cp-tree.def, and I will submit it to gcc-patches if it works. At the moment I'm curious as to whether anybody has a reason why these codes should be tcc_expression rather than tcc_statement. I cannot think of any. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Is there a way to specify profile data file directory?
H. J. Lu wrote: When -fprofile-arcs is used, the directory of profile data is fixed to the build directory. If I want to run the binary on a different machine, I have to create the same directory, which may not be very easy. Is this intentional? Can we have have an option to specify the different dirctory or to use the current dirctory at the run-time? this has come several times recently. The consensus is some environment variable to be prepended to paths inside libgcov. Not a command line switch at compile time. would that suit you too? nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Is there a way to specify profile data file directory?
H. J. Lu wrote: Yes, that will work. Is anyone working on this? If not, we can take a look. I have not heard anything back from the original enquirer/volunteer over a month ago. I suggest GCOV_PREFIX as the variable name and simply concatenate it to the absolute paths in the object file. I'm not sure about whether mkdir calls should be automatically performed, probably yes. You might want or need to get cleverer and have some way of indicating how many initial directory names to strip off the hardwired absolute paths. Maybe this should be done by string matching or level counting. Perhaps GCOV_PREFIX_STRIP would be a suitable name. Use alloca rather than malloc, if at all possible please. Thanks for taking this up. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Register allocation in GCC 4
Jon Beniston wrote: Hi, I'm updating a GCC port to 4.0.0. I am seeing a problem whereby registers that are set to 1 in fixed_regs are being used. The problem is occuring quite early on in the compiler, as the registers appear in the 00.expand dump. The problem seems to occur for a DCmode value that is being allocated to several registers. The first 4 of these registers are not in fixed_regs, but the last 4 are (regs are 16-bit). I have made sure HARD_REGNO_MODE_OK for all these registers returns 0, but that hasn't had an effect. Can anyone suggest where I need to be looking to track this down? If I understand correctly the DCmode value occupies 8 registers, the last 4 of which are fixed regs. HARD_REGNO_MODE_OK should return 0 for the first 4 too. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Register allocation in GCC 4
Nathan Sidwell wrote: Jon Beniston wrote: Hi, I'm updating a GCC port to 4.0.0. I am seeing a problem whereby registers that are set to 1 in fixed_regs are being used. The problem is occuring quite early on in the compiler, as the registers appear in the 00.expand dump. The problem seems to occur for a DCmode value that is being allocated to several registers. The first 4 of these registers are not in fixed_regs, but the last 4 are (regs are 16-bit). I have made sure HARD_REGNO_MODE_OK for all these registers returns 0, but that hasn't had an effect. Can anyone suggest where I need to be looking to track this down? If I understand correctly the DCmode value occupies 8 registers, the last 4 of which are fixed regs. HARD_REGNO_MODE_OK should return 0 for the first 4 too. oh, sorry you said that :) stick a breakpoint where that rtl is being created. I guess it must be to do with function calling or some target machine thingy, as those are the only places hard regs get mentioned before register allocation. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Side-effect latency in DFA scheduler
Jon, How is the latency of instructions that have side effects modeled in the DFA scheduler. For example, define_insn_reservation only has one latency value, yet instructions such as loads with post increment addressing have two outputs, possibly with different latencies. Do both outputs get the same latency? you should set the latency to the larger of those two values. You can then insert bypasses for the shorter one. Look at the arm schedulers, which have instances of that going on. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Store scheduling with DFA scheduler
Jon, (define_insn_reservation "arith" 1 (eq_attr "type" "arith") "x") (define_insn_reservation "loads" 2 (eq_attr "type" "load") "x,m") (define_insn_reservation "stores" 3 (eq_attr "type" "store") "x,m*2") Stores don't really have a 'result', why have you set the cycle count to 3? Shouldn't it be '1'? (then you won't need store bypasses for autoincrements) nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Regression involving COMMON(?)
Paul Thomas wrote: Andrew, You were right: I think this is caused by: 2005-04-25 Nathan Sidwell <[EMAIL PROTECTED]> * tree-ssa-alias.c (fieldoff_t): Remove. (fieldoff_s): typedef the structure itself. Create a vector of objects. (push_fields_onto_fieldstack): Return count of fields pushed. Remove peeling of first field. Adjust. (fieldoff_compare): Adjust. (create_overlap_variables_for): Adjust. by the way Paul, what is the error? For every each one of the FAILs - internal compiler error: in push_fields_onto_fieldstack, at tree-ssa-alias.c:2834 I am looking at it. -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Store scheduling with DFA scheduler
Jon Beniston wrote: Jon, (define_insn_reservation "arith" 1 (eq_attr "type" "arith") "x") (define_insn_reservation "loads" 2 (eq_attr "type" "load") "x,m") (define_insn_reservation "stores" 3 (eq_attr "type" "store") "x,m*2") Stores don't really have a 'result', why have you set the cycle count to 3? Shouldn't it be '1'? (then you won't need store bypasses for autoincrements) Primilary because that's how it appears to be coded in the ARM port (e.g store_wbuf in arm-generic.md). I had tried both ways though, and for this particular problem, changing this value appears to have no effect. I can see that it would for autoinc though. ah, the arm1026ejs and arm1136jfs don't do that. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Store scheduling with DFA scheduler
David Edelsohn wrote: Nathan Sidwell writes: (define_insn_reservation "arith" 1 (eq_attr "type" "arith") "x") (define_insn_reservation "loads" 2 (eq_attr "type" "load") "x,m") (define_insn_reservation "stores" 3 (eq_attr "type" "store") "x,m*2") Nathan> Stores don't really have a 'result', why have you set the cycle Nathan> count to 3? Shouldn't it be '1'? (then you won't need store bypasses Nathan> for autoincrements) Stores do have results: memory. If one does not have a store bypass in the processor, one needs to model the delay for the result to appear in the cache and be available for a subsequent load. Is that modelled by that bit of the scheduler? I thought the cycle count in define_insn_reservation was for a register output that would be available to a subsequent instruction. The RAW contention you describe would need to be modelled separately (as I've done in at least one port), because you could start the load insn before the store had completed -- provided the load was processed in the memory unit after the store has sufficiently completed. an absense_set would be the way to model stalling a load whilst a store was being processed. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Struggle with FOR_EACH_EDGE
Kazu Hirata wrote: To see what kind of code GCC generates for FOR_EACH_EDGE, I wrote a simple dummy function. Kazu, I hope I have time to look in detail at your investigation, however one thing that might be causing a problem is that FOR_EACH_EDGE is an iterator that works for a non-constant VEC. This means there's an extra level of indirection that the optimizer cannot remove, unless it completely inlines the body of the loop (there might be some cases it can do it without inlining, but I suspect not). I wonder if it is worthwhile implementing FOR_EACH_EDGE and FOR_EACH_EDGE_VOLATILE (I want the default, shorter name, to be the constant iterator, so that you have to chose to use the non-constant one). Even with a constant iterator, it might be necessary to help the optimizer by copying the vector length to somewhere local that the optimizer can see cannot be changed by the body of the loop. Hmm, I guess that does mean you need a proper iterator object, rather than the integer index that VEC_iterate employs. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: volatile semantics
Mike Stump wrote:
int avail;
int main() {
while (*(volatile int *)&avail == 0)
continue;
return 0;
}
Ok, so, the question is, should gcc produce code that infinitely loops,
or should it be obligated to actually fetch from memory? Hint, 3.3
fetched.
I beleive the compiler is so licensed. [5.1.2.3/2] talks about accessing
a volatile object. If the compiled can determine the actual object
being accessed through a series of pointer and volatile cast conversions,
then I see nothing in the std saying it must behave as-if the object
were volatile when it is not.
This, of course, might not be useful to users :)
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: volatile semantics
Dale Johannesen wrote:
However, as a QOI issue, I believe the compiler should treat the
reference as
volatile if either the object or the lvalue is volatile. That is
obviously the
user's intent.
I'm not disagreeing with you, but I wonder at gcc's ability to make
good on such a promise. A cast introducing a volatile qualifier
will be a NOP_EXPR, and gcc tends to strip those at every opportunity.
Also, I wonder about the following example
int const avail =
int main() {
while (*(int *)&avail == Foo ())
do_something();
return 0;
}
Seeing through the const-stripping cast is a useful optimization. We'd
have to have one rule for adding volatile and a different one for removing
const.
A further pathelogical case would be,
int main() {
while (*(int *)(volatile int *)&avail)
do_something ();
return 0;
}
What should this do, treat the volatile qualifier as sticky?
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: volatile semantics
Dale Johannesen wrote: On May 3, 2005, at 11:03 AM, Nathan Sidwell wrote: Seeing through the const-stripping cast is a useful optimization. It is? Why would somebody write that? perhaps a function, which returned a non-const reference that happened to be bound to a constant, has been inlined. IMO, no, but surely we don't have to worry about this one. Either way is standard conformant and the user's intent is far from clear, so whatever we do should be OK. If we guarantee one to work and not the other, we need to have a clear specification of how they differ. What if intermediate variables -- either explicit in the program, or implicitly during the optimization -- get introduced? My guess is that the wording of the standard might be the best that could be achieved in this regard. It would be nice to have some clear wording indicating that Mike's example will work, but some other, possibly closely related, example will not. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: volatile semantics
Dale Johannesen wrote: And we don't have to document the behavior at all; it is not documented now. I disagree. It's not documented explicitly in gcc now, because it is doing what the std permits, and so documented there. We should document either a) that current gcc is not breaking the std, and Mike's example is invalid code, if one expects a volatile read. This would be a FAQ like thing. b) amend the compiler to do a volatile read, and document the extension. This should go in extend.texi Documentation for (b) is necessary so that programmers can rely on the extension (and understand why some other compiler might not do what they want) _and_ so that gcc maintainers know about it. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Packing booleans?
Sam Lauber wrote: Would it be possible to have a -fpack-bools option that packs booleans into the smallest form possible (8 booleans -> 1 8-bit reg, etc.) into a register (or memory, as the case may be)? why would you want to do this? Seems to me you might save up to 7 bytes of data memory at a vastly greater expansion of code size and reduction in performance. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Packing booleans?
Mattias Karlsson wrote: On Wed, 4 May 2005, Nathan Sidwell wrote: Sam Lauber wrote: Would it be possible to have a -fpack-bools option that packs booleans into the smallest form possible (8 booleans -> 1 8-bit reg, etc.) into a register (or memory, as the case may be)? why would you want to do this? Seems to me you might save up to 7 bytes of data memory at a vastly greater expansion of code size and reduction in performance. Unless you are using an architecture with btst, bset, bclr instructions. True, they'd have to have memory operands to be a win though. Otherwise it'd be a load bset store or load btst sequence, rather than store or load Of course, one might be able to amortize the load and store over several bit operations, but you'd still end up with at least one extra instruction over not packing, and that will cost you 4 bytes (or thereabouts). If this were being done at the level of register allocation, why would one need a user visible option? 'Just' rearrange the register file to look like a set of single bit registers overlaid on a more conventional register file. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: volatile semantics
Dale Johannesen wrote: Both behaviors are standard-compliant. I don't think anyone's disagreeing with that. The point is that the user *requires* a volatile read, but the std *does not* guarantee it. > Treating a reference as volatile when you don't have to just means > strictly following the rules of the abstract machine; it can never > break anything. ok then, this can be achieved with the -O0 flag :) I doubt that's what is desired though. I see a difference between a documented extension, and quietly choosing from among standard-compliant behaviors the one which is most convenient for users. I see your point, but I think it is wrong. How can the programmer rely on gcc adhering more strictly to the abstract machine than the std requires, unless the behaviour is documented? How can the gcc developers make sure optimizations are not breaking such a promise, unless it is documented? nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Questions about a constant array reference in the C++ front end
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 bodies and I have never seen a > RANGE_EXPR. I suppose it's only used at later stages or only in other > language's frontends. Incorrect. RANGE_EXPRs get generated during processing of an array's initializer -- very early on in the C++ FE. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Questions about a constant array reference in the C++ front end
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 whether the array is declared with const. cp_type_quals (type) & CP_QUAL_CONST > Do you know how to trigger a RANGE_EXPR? I see that in > build_zero_init, so I tried a big array with only zeros in it, but > that didn't help. I can't recall exactly. It might be for default initialization. Something like ptr = new int[100] (); look at build_zero_init in cp/init.c nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Mainline bootstrap broken in varasm.c
Mark Mitchell wrote: Steve Kargl wrote: Julian already sent my a patch, which did not fix the problem. Additionally, I think the patch that caused the problem was committed by Nathan. Julian just happen to commit a patch to varasm.c two commits after Nathan. OK, thanks. I'm sure Nathan will look at it, come morning in the UK. yes. I somehow incorrectly grepped for IN_LIBGCC2 and found only one occurrence, #defining it. I have reverted that miscleanup. I wonder if USED_FOR_TARGET cannot be used here instead -- I'd find it less confusing at least. IN_LIBGCC2 indeed, no, this is crtstuff nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Validating a C++ back-end
Vasanth wrote: Hi, I am working on a fresh C++ port and I am filling in all the machine specific hooks. How do I run the C++ testsuite on my compiler? I am familiar with the GCC torture/execute tests and have my backend passing those tests reasonably well. Now, I am looking for something similar for C++ to test my support for the language's features. Ah, you need a conformance testsuite. There are several conformance ones available, all proprietary AFAIK. Depending on what you want to verify, you might need a language conformance testsuite and/or an ABI conformance testsuite. A C++ specific forum might be able to provide the best info about what's available. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Validating a C++ back-end
Vasanth wrote: > Hi Nathan, > > Thanks for the inputs. Can you tell me if there is a set of tests in > the G++ testsuite for verifying just my implementation of basic > machine dependent C++ hooks? To give examples - verify global > constructor/destructors being invoked correctly, init_priority, > thunks, Vtable stuff etc. Can I just take all those "dg-do run" tests > and run them on my target? All gcc has are the g++.dg and g++-old-deja tests. If they pass, you have a compiler that is probably as functional as any other gcc target. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Proposed resolution to aliasing issue.
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" than it may be
able to figure out that it can't access any other parts, or figure out
which parts it can access, and in that case it can of course use that
information. The interesting case, therefore, is when the body of "g"
is not available, or is insufficient to make a conclusive determination.
I attended a UK C++ panel meeting yesterday, and took the opportunity
to solicit opinions on this. The question I posed was
struct A {
...
T1 a;
T2 b;
};
void g(T1 &a);
void Foo () {
A v;
v.b = 2;
g (v.a);
if (v.b == 2) ...
}
Does the compiler have a right to presume v.b does indeed == 2 in the if
condition? -- assuming T2 is a suitable type for that :)
After I explained the optimization (and the related structure splitting
optimization), the general consensus was 'yes that would be a useful
optimization'. But no one was sufficiently confident of proving it
was allowable. The opinion was expressed that if it was not allowable,
there was a bug in the std.
The observation was made that if A is non-POD, one cannot play offsetof
tricks to get from A::a to A::b, so the optimization is safe on non-PODs.
(Of course one would have to prove the address of 'v' did not escape,
so I guess the ctor and dtor would need to be trivial or visible.)
One of the panel members is looking at C++'s memory model WRT
multithreading. This question has a direct impact there too, as
separate threads might be operating on v.a and v.b. He indicated
he would consider the issue.
I also outlined the approach gcc would take with a compile time
switch and an attribute. The preference was expressed that
the attribute should be of the form
void badfunc (A & __I_AM_BAD__ m);
rather than
void goodfunc (A & __I_AM_GOOD__ m);
because (a) badfuncs are more than likely rare and (b) it would be a useful
aid to the programmer.[1] Mark outlines an __I_AM_GOOD__ attribute, I think
it would be better to have both flavours and then the compiler switch can
specify which way the default goes.
nathan
[1] it was of course noted that that looked stunningly like 'restrict', and
the suggestion that it be spelled 'noalias' was jokingly made :)
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Proposed resolution to aliasing issue.
Mark Mitchell wrote: > Will the UK committee open a DR for this? Or, would you care to send > mail to Steve Adamczyk about it? this can be done. I shall wait until the minutes have been written up. > >> The observation was made that if A is non-POD, one cannot play offsetof >> tricks to get from A::a to A::b, so the optimization is safe on non-PODs. >> (Of course one would have to prove the address of 'v' did not escape, >> so I guess the ctor and dtor would need to be trivial or visible.) > > > I argued last week that this was not in fact true, in that you can do: > > ptrdiff_t x = &v.b - &v.a; > > and then use that instead of "offsetof (Foo, b) - offsetof (Foo, a)". Does not '&v.b - &v.a' cause the address to 'escape', and therefore lock down the structure? If it doesn't, how hard would it be to make that DTRT? nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: How can I get rid of __main ?
Monika Chaddha wrote: When I generate relocatable file (*.o) of (*.s) file then the disassembly of 'jal __main" does not display properly in GDB disassmebler. It displays as "jal 0x0" because __main linked only during linking process. why is this a problem? You'll notice it happens for all function calls, not just one to __main. Why are you looking at an unrelocated object file in gdb? Can I get rid of __main in relocatable file or assembly file? why do you want to do this? You can remove the symbol with objcopy -N __main foo.o newfoo.o but i doubt very much that that is what you really want to do. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Any docs about gcov impl change from 3.3 to 3.4
Fei, Fei wrote: Hi, I am working on investigating some low level coverage tool, including gcov. As I find out, the difference of implementation of gcc in gcov part btw 3.3 and 3.4 is relevant. Can anyone direct me to some document regarding this change? I'm not sure what you mean. The new implementation is documented in gcov.texi and the relevant header files. The old documentation was, er, vague. The ChangeLog will describe the changes and the mail archives will contain the patches. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Question about new warning system
Gabriel Dos Reis wrote:
As pointed out by JSM yesterday, it is not clear whether [1] should be
preferred over [2] or the converse. I think having two ways to
control the same diagnostic is a bit confusing. I think the
I'm inclined to agree it is confusing. especially as in one place one has to
write warn_ and in the other place one writes OPT_W. It'd be nice if
one just wrote
if (warn_foo && frobbed)
warning ("foo is frobbed");
I don't care if it's spelt warn_foo, OPT_Wfoo, warning_p(foo) or whatever, so
long as it's spelt only one way. The 'warning (OPT_Wfoo, ...)' syntax helps
only where there is no conditional before the warning -- how often does that
occur? The way it currently is, one runs the risk of writing
if (warn_c_cast
&& .
&& .
&& .)
warning (OPT_Wconst_cast, ...)
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: In current gcc trunk: warning: dereferencing type-punned pointer will break strict-aliasing rules
Christian Joensson wrote: I'd just like to ask if this is noticed: /usr/local/src/trunk/gcc/gcc/unwind-dw2.c:324: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/local/src/trunk/gcc/gcc/unwind-dw2.c:789: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/local/src/trunk/gcc/gcc/unwind-dw2.c:1005: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/local/src/trunk/gcc/gcc/unwind-dw2-fde.c:1024: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/local/src/trunk/gcc/gcc/unwind-dw2-fde-glibc.c:393: warning: dereferencing type-punned pointer will break strict-aliasing rules I had not noticed this, but looking at the first one it must have been caused by my patch to the type punning warning. It also appears to be a correct warning, in that we are breaking aliasing. I shall look for a solution. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Your rtti.c changes broke some obj-c++ tests
Giovanni Bajo wrote: Nathan, I see some failures in the testsuite which appear to be related by your recent changes to rtti.c (VECification). For instance: FAIL: obj-c++.dg/basic.mm (test for excess errors) Excess errors:/home/rasky/gcc/mainline/gcc/libstdc++-v3/libsupc++/exception:55: internal compiler error: vector VEC(tinfo_s,base) index domain error, in get_tinfo_decl at cp/rtti.c:373 Would you please check and possibly fix this? looking at it. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Your rtti.c changes broke some obj-c++ tests
Giovanni Bajo wrote: Nathan, I see some failures in the testsuite which appear to be related by your recent changes to rtti.c (VECification). For instance: FAIL: obj-c++.dg/basic.mm (test for excess errors) Excess errors:/home/rasky/gcc/mainline/gcc/libstdc++-v3/libsupc++/exception:55: internal compiler error: vector VEC(tinfo_s,base) index domain error, in get_tinfo_decl at cp/rtti.c:373 Would you please check and possibly fix this? for some reason cc1objplus is not walking the gty roots in rtti.c. I cannot figure out what configurey thing makes that happen. I've tried to grep for how cp/decl2.c does it, but to no avail. anyone with any gty-fu? nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
attributes and templates
Paulo, I tried to get attributes and templates to play nice. Even though conceptually it's quite straight forward, our data representations and current instantiation machinery pretty much make it very difficult. It would be several days (maybe a week or two) to get working :( I'm fairly certain implementing __builtin_reflect (...) for the other bits of type traits would be easier (though I've not tried). nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: [RFC] gcov tool, comparing coverage across platforms
[EMAIL PROTECTED] wrote: Current questions include whether this tool needs to be used on platforms for which a bourne shell script is inappropriate and whether this tool needs to be coded in C instead. as you're somewhat deadline bound, write it in whatever language suits your needs. bash would certainly be acceptable, but I wouldn't particularly mind if it was in perl or python, which might be somewhat easier to work with. Also, whether the -a, -b, -c and -f output types from gcov all need to be accounted for or whether only some of these outputs are of types for which cross-platform comparison makes sense. We have little doubt that regular users of gcov Seems a reasonable choice. One other use of such a tool, that I suggested to Janis when she mentioned you all, is to compare gcov results for the same target machine but at different optimization levels. this might or might not change the block structure to a greater extent. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Do C++ signed types have modulo semantics?
Michael Veksler wrote: According to the (very) long discussion on VRP, signed char/short/int/etc do not have modulo semantic, they have an undefined behavior on overflow. However in defines numeric_limits::is_modulo = true. signed types are undefined on overflow. [5/5] and [3.9.1/2,3] 1. Is that a bug in , a bug in the standard, or is just C++ different than C in this respect? a bug in limits, probably 2. Maybe because overflow is undefined then is_modulo maybe considered "unspecified". I don't like this option, because it does not help generic programming. it's also, I believe, wrong, in that some gcc optimizations will not preserve such behaviour. (I guess this is the whole VRP conversation you mention.) 3. Do I understand what is_modulo stands for? yes 4. What should be done (libstdc++ PR, C++ PR, DR, other)? 18.2.1.2/57 claims is_modulo is true 'for signed types on most machines'. Such an assertion is false when optimizations rely the undefinedness of signed overflow. A DR should probably be filed (maybe one is, I'm not at all familiar with library DRs). nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Do C++ signed types have modulo semantics?
Gabriel Dos Reis wrote: But a compiler could define them to be modulo -- that is the whole point. The paragraph does not say they don't "modulo". of course it could do so, but then to be useful it should document it, and it would be an extension. | 18.2.1.2/57 claims is_modulo is true 'for signed types on most | machines'. Such an assertion is false when optimizations rely the | undefinedness of signed overflow. A DR should probably be filed | (maybe one is, I'm not at all familiar with library DRs). Well, undefined behaviour does not mean unconditional hell or evil. It is just behaviour left up to the compiler to whatever it wants. correct. However the std *itself* says in one place 'this is undefined' and in another place 'this is usually modulo'. I find that confusing at best. And all useful programs we write rely on undefined behaviour of one sort or the other, starting with GCC. In the case of They do? I thought they usually relied on implementation defined, documented extensions or were part of the implementation. Now I'm sure you'll prove me wrong in some way or other, but please stick to the point -- do real important programs that must not break and cannot be changed rely on signed modulo behaviour? When RTH helped cleanup the numeric_limits implementation in September 2002, he made a very good point (which I held to be true, since obviously he is The Middle-end and Back-end Guy) http://gcc.gnu.org/ml/libstdc++/2002-09/msg00207.html thanks for that. I was under the impression that some of the loop optimizers relied on the fact that iterating over a signed type did not do odd modulo related things. Indeed this comment in loop.c concerning BIVs leads me to believe we already fail to honor the is_modulo value Note that treating the entire pseudo as a BIV will result in making simple increments to any GIVs based on it. However, if the variable overflows in its declared mode but not its promoted mode, the result will be incorrect. This is acceptable if the variable is signed, since overflows in such cases are undefined, but not if it is unsigned, since those overflows are defined. So we only check for SIGN_EXTEND and not ZERO_EXTEND. Anyway, this doesn't answer Michael's question. He asked whether C and C++ differ in this regard. The answer is the standards are the same, and the implementation is the same (because it is the same backend). So, if whatever optimizations he is turning on change the behaviour rth cited, then limits should change too. I don't particularly care what behaviour is chosen, except that 1) C and C++ implementations should behave the same way 2) we should pick the behaviour that leads to better code generation in real life. 3) if modulo behaviour is chosen, it should be well documented in a place more prominant than type_traits::is_modulo. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Do C++ signed types have modulo semantics?
Gabriel Dos Reis wrote:
Michael Veksler <[EMAIL PROTECTED]> writes:
[...]
| The code is not very simple, and different codes will get optimized
| differently.
| The user will have to learn how to write this piece of code differently for
| each
| processor to have best results.
|
| int wrap_sum(int a, int b)
| {
| if ( (a<0) != (b<0))
| return a+b; // Different sign, no overflow possible.
| unsigned sum = (unsigned) a + b;
| if (sum <= MAX_INT)
| return sum;
| sum -= MIN_INT;
| if (sum > MAX_INT) // can be eliminated for 2's complement
|abort(); // oops
| return (int)sum + MIN_INT;
| }
|
| It does not look too good optimization-wise.
Thanks for providing this example. This is the sort of thing I
faced. With pipeline process, it does harm.
Please explain why
int wrap_sum (int a, int b)
{
return (int) ((unsigned)a + (unsigned)b));
}
is unacceptable (provided we're on the standard 2's complement machine where the
mapping between negative ints and unsigned is *implementation defined* to be the
sane mapping, which I might point out you've already assumed in the wrap_sum I
quoted).
nathan
and whoever silently removed gcc@gcc.gnu.org, shame on you
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Do C++ signed types have modulo semantics?
Gabriel Dos Reis wrote:
Nathan Sidwell <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > Michael Veksler <[EMAIL PROTECTED]> writes:
| > [...]
| > | The code is not very simple, and different codes will get optimized
| > | differently.
| > | The user will have to learn how to write this piece of code differently
for
| > | each
| > | processor to have best results.
| > | | int wrap_sum(int a, int b)
| > | {
| > | if ( (a<0) != (b<0))
| > | return a+b; // Different sign, no overflow possible.
| > | unsigned sum = (unsigned) a + b;
| > | if (sum <= MAX_INT)
| > | return sum;
| > | sum -= MIN_INT;
| > | if (sum > MAX_INT) // can be eliminated for 2's complement
| > |abort(); // oops
| > | return (int)sum + MIN_INT;
| > | }
| > | | It does not look too good optimization-wise.
| > Thanks for providing this example. This is the sort of thing I
| > faced. With pipeline process, it does harm.
|
| Please explain why
| int wrap_sum (int a, int b)
| {
| return (int) ((unsigned)a + (unsigned)b));
| }
| is unacceptable
Notice that in your rendition you're assuming that you can convert any
unsigned value > INT_MAX to a int without invoking undefined behaviour.
Thus the question is whether you're accepting that as documented
behaviour of GCC, and if so, then I'm interested in which ways it
would differs from saying that is_modulo is true. That is useful for
improving over the current situation, may I point out.
I give up.
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Do C++ signed types have modulo semantics?
Michael Veksler wrote:
So what does gcc gives for (int) (MAX_INT+1U)?
Maybe it is constrained such that
(int)(unsigned)a == a
For 1's complement the reverse seems to be incorrect:
unsigned a= 0x; // or was it 0x8000?
assert((unsigned)(int)a == a); // may fail
why are you talking about one's complement in the context of gcc. From
implement-c.texi
@cite{Whether signed integer types are represented using sign and
magnitude,
two's complement, or one's complement, and whether the extraordinary
value
is a trap representation or an ordinary value (C99 6.2.6.2).}
GCC supports only two's complement integer types, and all bit patterns
are ordinary values.
please stop considering non 2's complement stuff.
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Advice needed on GCC port to new (virtual) architecture
[EMAIL PROTECTED] wrote: I am currently working on a VM and would like to port gcc to it in order to simplify the creation of software. The VM simulates a processor with a stack pointer (SP), 16 General Purpose Registers, Accumulator and built-in multitasking. The instruction set is turing complete and implements stack, conditional branching, unconditional branching and console I/O. I would like to generate asm code which can be fed into my own custom assembler and then assembled into flat binary files. Does anyone have advice on a similar platform which i can hack on the gcc source for? do your port from scratch. attempting to morph an existing port into what you want is likely to break in many random bad ways. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Advice needed on GCC port to new (virtual) architecture
Gareth The Great wrote: > The problem is i am not that used to the GCC internals and could benefit a > lot from hacking on some sample code. Is there a simple guide anywhere on > how to produce a new target other than "using and porting gcc"? http://gcc.gnu.org/readings.html lists Porting GCC for Dunces by Hans-Peter Nilsson amongst other things. Be aware that the internals will have changed since Hans-Peter wrote that. You need to refer to the doc/tm.texi% file for the up to date information. nathan % I know this gets built as some ps file or something, but I'm such a luddite I just read the raw texinfo. -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Where does the C standard describe overflow of signed integers?
Nicholas Nethercote wrote: Hi, There was recently a very long thread about the overflow behaviour of signed integers in C. Apparently this is undefined according to the C standard. I searched the standard on this matter, and while I did find some paragraphs that described how unsigned integers must wrap around upon overflow, I couldn't find anything explicit about signed integers. Can someone point me to the relevant part(s) of the standard? c99 6.5 para 5 (overflow is undefined) & 6.3.1.3 (conversions to unsigned type obey modulo laws) c++ 5 para 5 (overflow is undefined, unless otherwise stated) & 3.9.1 para 4 (unsigned types obey modulo laws) I cannot find, in c99, a statement that all unsigned arithmetic obeys modulo laws -- only that integral conversions to them do. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: addsi3 with set condition register
[EMAIL PROTECTED] wrote: (insn 12 11 13 (set (reg:SI 168) (plus:SI (reg/v:SI 166 [ a ]) (reg/v:SI 167 [ b ]))) -1 (nil) (nil)) (insn 13 12 14 (set (reg:CC 33 cr1) (compare:CC (reg:SI 168) (const_int 0 [0x0]))) -1 (nil) (nil)) My pattern is (define_insn "..." [ (set (match_operand:SI 0 "register_operand" "=g") (plus:SI (match_operand:SI 1 "register_operand" "g") (match_operand:SI 2 "register_operand" "g")) ) (set (reg:CC CC_REGNUM) (compare:CC (match_dup 0) (const_int 0)))] your pattern is not equivalent to the two instructions shown. (the pattern is a parallel, the insns are a sequence) nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: volatile semantics
Daniel Berlin wrote:
> How does this reasoning not apply to *((char *)a) = 5 where a was
> originally of a const qualified type?
> Or do you think you can only *add* qualifiers, and not remove them?
>
> Because if you allow casting away, then you can't ever trust const to be
> true either, just like we apparently can't trust the user saying "this
> is not volatile" (which they are doing by not declaring the original
> object volatile).
I don't understand your point. given
void Foo (char const * a) { *(char *)a = 5; }
the compiler generates code to store 5 through the pointer 'a'. It doesn't turn
this into a call to 'abort', because it thinks you're writing to const storage.
So, here it appears the compiler does believe the (char *) cast. Why should it
not believe a (char volatile *) cast -- unless it can determine the static type
of the object pointed to?
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: volatile semantics
Daniel Berlin wrote:
>>> object volatile).
>>
>>
>> I don't understand your point. given
>> void Foo (char const * a) { *(char *)a = 5; }
>> the compiler generates code to store 5 through the pointer 'a'. It
>> doesn't turn
>> this into a call to 'abort', because it thinks you're writing to const
>> storage.
>
>
> Is this *always* the cast, or just in the example above?
I thought we were discussing the case where there is no static information about
what the pointer actually points to. I.e. the case of an incoming pointer
parameter of a function that is not being inlined (or equivalent).
> It appears he was saying that *even if it could determine the static
> type*, the volatile qualifier on the cast *made the object not that type
> anymore*. And i'm not sure why such a thing would apply only to
> volatile, if true.
I could not determine whether that was the case of Hugh Redelmeier's argument --
the example is an incomping pointer parameter.
I agree with you, Daniel, that if the static object can be determined, then its
type qualifiers win.
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
MEMBER_TYPE and CV qualifiers
I'm looking at holding the CV qualifiers of a member function on the MEMBER_TYPE node itself, rather than only on the this pointer argument. this brings up a design issue of what TYPE_MAIN_VARIANT should be of a cv qualified member function. Should it be itself (thereby breaking the invariant that T_M_V is always unqualified), or should it be the cv unqualified member function? Our current behaviour is such that T_M_V of a member function is a self reference. Clearly cp_build_qualified_type should continue to reject cv qualifying a MEMBER_TYPE. We'd need a new cp_build_qualified_member_type to do that, so we can correctly deal with the syntactic differences. thoughts? nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: volatile semantics
Richard Henderson wrote:
> I've got no interest in reading a thread with 250 messages wherein
> language lawyers battle it out in a no-holds-barred grudge match.
yeah, I can understand that :)
> Would someone like to summarize, preferably with a test case that
> one side assumes to be miscompiled?
Issue 1.
void Foo (char *ptr) {
*(volatile char *)ptr;
}
can the read be deleted? GCC 4 deletes it.
IMHO, no it cannot be deleted (when we do not know what object PTR points to).
Issue 2
can we delete the read, when we do determine that PTR points to a non-volatile
object. I.e.
char c;
*(volatile char *)&c; // can this read be deleted?
IMHO, the standard is unclear. It seems to me that deleting the read is not
disallowed.
Issue 3
void Foo (volatile char *ptr) {
*(char *)ptr;
}
Again, is this read deleteable? IMHO, yes.
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: inserting instructions into prologue/epilogue
Gunther Nikl wrote: Hello! I am trying to add instructions into function prologue/epilogue. These instructions shall save and load "fixed" registers to avoid assembly. Register saving in the prologue appears to work. The restore code in the epilogue aborts in flow.c/propagate_one_insn with "Attempt to delete prologue/epilogue insn" unless the stackslot was marked with MEM_VOLATILE_P. I don't think thats the proper fix. you can add a (USE reg) after the restore in the prologue. Then flow considers the register, and the preceding load, to be live at that point. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: inserting instructions into prologue/epilogue
Nathan Sidwell wrote: you can add a (USE reg) after the restore in the prologue. Then flow in the EPILOGUE, of course considers the register, and the preceding load, to be live at that point. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
non canonical tree in java
java is creating a COMPONENT_REF node where the first operand is a RECORD_TYPE, rather than an expresion or DECL node. This is created at java/class.c:1014 prim_class = lookup_class (get_identifier (prim_class_name)); return build3 (COMPONENT_REF, NULL_TREE, prim_class, TYPE_identifier_node, NULL_TREE); here PRIM_CLASS is the RECORD_TYPE of the class. This usage disagrees with the requirements for a COMPONENT_REF in tree.def /* Value is structure or union component. Operand 0 is the structure or union (an expression). Operand 1 is the field (a node of type FIELD_DECL). Operand 2, if present, is the value of DECL_FIELD_OFFSET, measured in units of DECL_OFFSET_ALIGN / BITS_PER_UNIT. */ DEFTREECODE (COMPONENT_REF, "component_ref", tcc_reference, 3) it is interfering with some cleanups I'm trying to do. What would be the best way of making java compliant? Have lookup_class return a suitable VAR_DECL node? I'm not sure where this then gets used ... nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: non canonical tree in java
Andrew Pinski wrote: The java front-end later on replaces prim_class with the correct tree, witness how the type of COMPONENT_REF is NULL. where does this happen? do you happen to know? nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Question about std templates
stefano luceri wrote: hello to all anyone know if is possible to add a member to a template of standard library? you'd have to modify the library source files, and then you'd end up with a non-standard library nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: -fprofile-arcs and gcov: data without exit()
Astroman (sent by Nabble.com) wrote:
I am working on a piece of software that never exits and I am trying to use
-fprofile-arcs and gcov to gather coverage data on it.
The code looks like this:
int main(){
while(1){
foo();
nanosleep(50);
}
}
This is a child process that as you can see will never exit on its own so
eventually it is just signal killed by the parent process. This code could be
changed to exit properly but that is not an option in this case. I am
compiling the code with -fprofile-arcs and -ftest-coverage and I am able to
obtain accurate coverage data for all the files in the project that exit
normally. Is there any way to collect the .da file data before exit? Is it
temporarily stored anywhere or could I alter the gcc library to store this
information more often?
call __gcov_flush
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: -fprofile-arcs and gcov: data without exit()
Joe Buck wrote: On Tue, Oct 11, 2005 at 06:01:07PM +0100, Nathan Sidwell wrote: call __gcov_flush It seems you could just invoke that function from gdb, and not change the program at all, right? that's a neat idea :) nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Warning on C++ catch by value on non primitive types
Mike Stump wrote: Look at the parser (gcc/cp/parser.c:cp_parser_handler) and set a break point there, follow it down into semantic processing, pick a nice place to do the checking, and then add the code to check it. look at finish_handler_parms in semantics.c For it to be accepted, others would have to agree it is a good thing to have, for example, if it were in the Effective C++ book, you can argue that way. yeah, if it were in one of those books it could be added to the -weff-c++ option. It doesn't seem sensible to add a different option for an alternative (set of?) coding rule(s). nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: A question on alias analysis
shreyas krishnan wrote: Hi , I am overwhelmed with the jargon and world of alias analysis and different kinds of it. I was wondering if some one can help me with this simple question. Is deciding if a pointer is pointing to what segment (heap/otherwise) a simpler problem than exactly deciding the points to set? No. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Link-time optimzation
Kenneth Zadeck wrote: The stack machine that we have in mind will be as stripped down as possible. The idea is just to get the trees in and get them back out. When I first read the proposal, I too wondered if a register machine would be better here. I've come to the conclusion that it wouldn't be, and that a stack machine is a fine choice. *) Unlike JVM, we're not producing something that is supposed to be immediately executable. Making hardware stack machines go fast is very hard -- TOS acts as a huge atomic operator. *) I can well imagine more complicated gimple nodes than simple 3 address forms. A stack machine makes this kind of thing easy to extend. As Kenny says, a stack machine is an ideal way to serialize a tree. *) The stack machine decouples the getting and putting of operands from the actual operations. Although this could lead to excessive size, that does depend on the actual encoding chosen -- something that affects both stack and register machines. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Default arguments and FUNCTION_TYPEs
Mark Mitchell wrote: Gabriel Dos Reis wrote: Hi, In the C++ front end, default arguments are recorded in FUNCTION_TYPEs intead of being part of the FUNCTION_DECLs. What are the reasons for that? There used to be an extension that allowed default arguments on function pointer types. We agreed to kill it, although I don't know if it was actually removed. If that's been done, there's no longer any reason. I took it out the back and shot it. The obvious place is on the DECL_INITIAL of the PARM_DECLs, but I don't think they exist until the function is defined. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Default arguments and FUNCTION_TYPEs
Gabriel Dos Reis wrote: Assuming the extension was gone, do you see a reason we not move the default arguments to FUNCTION_DECLs and have FUNCTION_TYPEs use TREE_VEC instead of TREE_LIST to hold the parameter-type list? you could probably use a VEC(tree), which I think would be even better :) nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: How implemented "typeof"
Alexander wrote: Hello! How I can know more about implementation at 'tree' level such extension as 'typeof'? I am not want to explore and change sources now, maybe someone cam help? your two desires conflict. typeof is implemented in cp/rtti.c nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: MS1 backend not listed in backends.html
Aldy Hernandez wrote: On Thu, Dec 01, 2005 at 04:18:20PM +0100, Steven Bosscher wrote: Hi Aldy, The MS1 backend is not listed in http://gcc.gnu.org/backends.html. Could you please add it? This is what I have. Nathan, how does this look to you? I think the line should be + ms1 | S F B p g bd nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: new c++ restrictions?
Jack Howarth wrote: For the last few months, gcc 4.1 has had problems compling the following code in posRMSDPot.cc in xplor-nih... without a full test case we have no clue. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: g++.dg/ext/packed3.C
Jan Beulich wrote: This test contains three invocations of Ref(), but only two of them are considered ill. What I'd like to get an explanation for is why the third (middle) instance is considered correct. After all, the u member of Packed is packed, and hence all the members of Unpacked in that context are, too. Namely, even if the object referenced by p is properly aligned, p.u isn't and hence p.u.i isn't either. I'm asking this because for *-*-netware*, which uses packed structures by default, this test fails with an error message like the ones expected on the other two calls to Ref(). Although Unpacked is a pod type, if it contained non-static member functions, those member functions would expect a this pointer that is correctly aligned. We have two options 1) don't pack fields of structure type 2) don't pack fields of non-pod or non-static member function containing structs #2 means the alignment of your field can change, depending on whether the field's type contains a non-static member or not. C++ has no term for such a class. #1) breaks GNU C compatibility, I think. I'm not sure what the best answer is here. If your system packs structs by default, you should not be getting the warning on any of the uses. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: C++ parser: Should we get rid of cp_parser_declarator_id?
Gabriel Dos Reis wrote: If we make it "static inline", would not we gain the same efficiency and preserve the comments and all that? In general, the methodoly seems to have a function for each non-terminal -- following a long tradition of recursive descent parser -- and maintaining that principle is helpful for code clarity. There's no need to make it inline. The optimizers are now smart enough to inline a static function into its only caller. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: C++ 3.4.5 packed reference warning
Steven L. Zook wrote:
When I compile this using gcc rev 3.4.5 (m68k-elf):
struct A { charB;
unsigned char & C; } __attribute__((packed));
unsigned char D;
A E = { 'F', D };
I get:
testpp.cpp:2: warning: ignoring packed attribute on unpacked non-POD
field `unsigned char&A::C'
sizeof( E ) == 6 (B, a byte of pad since m68k uses 16 bit alignment, and
C).
This construct compiled without warning under 3.3.3 and gave sizeof( E )
== 5.
Is this behavior under 3.4.5 (both the warning and the ignoring of the
packed attribute on the reference member) proper (justified, necessary,
good)?
It is bad to pack non-pod structs, because of alignment assumptions of member
functions thereof. The checking code just checks the non-podness of the type,
as non-pod is a well defined term. This could be relaxed. File a bug report if
needed.
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: g++.dg/ext/packed3.C
Jan Beulich wrote:
And that is precisely the reason why I think binding a reference to the
whole object or any of its members, when the object itself is a member
of a packed object, is illegal, hence requiring a diagnostic (unless,
like for both other cases, the default is to pack structures).
Doing that will break
struct Foo { void operator=(Foo const &);};
struct Baz __attribute__((packed))
{
char c;
Foo m;
}
void Bar (Baz *ptr)
{
ptr->m = something;
}
This is something we need to make work.
If your system packs structs by default, you should not be getting the
warning
on any of the uses.
But I do, and if I use a native Linux compiler with -fpack-struct, I
also get it (along with a second one on one of the two other
instances).
Then I think you have a bug.
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: g++.dg/ext/packed3.C
Jan Beulich wrote: Why? It's broken. You just cannot embed something that requires alignment into something that doesn't guarantee alignment, except that for built-in types, the compiler can synthesize the necessary splitting, but Foo's assignment operator, in your example, may be totally unaware that it might get called with an unaligned object. People write such code and expect it to work. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: C++ 3.4.5 packed reference warning
Steven L. Zook wrote: I guess what I don't understand is why struct A isn't POD. A reference to something is basically just a pointer. It has no alignment restrictions that a pointer wouldn't. a reference type is not a pod type because the language says so. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: g++.dg/ext/packed3.C
Mark Mitchell wrote:
struct Foo { void operator=(Foo const &);};
struct Baz __attribute__((packed))
{
char c;
Foo m;
}
void Bar (Baz *ptr)
{
ptr->m = something;
}
I'm not sure it can be made to work, without making the base class
version of Foo::operator= expect unaligned input, which seems an
unreasonable pessimization. I would expect this code to be invalid, and
either issue a diagnostic, or at least be considered undefined behavior.
It can be made to work by not packing Baz::m, and that is what g++ does (with a
warning%). Issuing an error in this case I don't think is acceptable -- I know
of users who would complain. If the user explicitly packed Baz::m field, rather
than the containing structure, I would be happy with a diagnostic.
(In my idea world, ptr->m has type "packed Foo" in this case, and it's
not permissible to binding a "packed Foo" to a "Foo const&", so this
would be invalid, but I could live with undefined.)
We need to distinguish the meanings of placing the packed attribute on the
structure and on the field itself. I agree with you that when the attribute is
on the field itself, the type should be 'packed Foo' and unbindable. When the
attribute is on the whole struct, I'm not so sure.
% ah, I think that warning should only be given on non-default-packed arches.
Is this your problem Jan?
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: g++.dg/ext/packed3.C
Jan Beulich wrote:
I don't think this is the case. The questionable code (from the test
case) really is
struct Unpacked { int i; };
struct __attribute__ ((packed)) Packed
{
char c;
int i;
Unpacked u;
};
and the test expects that you cannot bind Packed::u to Unpacked& (error
expected), but that you can bind Packed::u::i to int& (not even a
warning expected). No warning is expected on the definition of Packed's
u member.
ok. I think you're right. I think I've remembered why it is the way it is, and
that's because rejecting such a binding broke overload resolution of (the
trivial) Unpacked::operator=. I think that no longer applies.
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Why is this C++ code incorrect?
Jiutao Nie wrote: Hi, Compiling the following code with g++ will report error:`static void A::operator delete(void*)' is protected. It's correct If B is derived from A without "virtual". Why does the "new B" expression need to check the delete operator's accessibility when B is virutally derived from A? 5.3.4 paras 8, 17 and 18 say so. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
