SImode and PSImode question
Hi, I'm working on a port in which BITS_PER_UNIT is 16, Therefore HImode represent 32 bits int and SImode is actually long long. I see many references in gcc code to SImode. Isn't this problematic for ports such as this when SImode does not represent the natural int? I would like to define PSImode for 36-bit accumulators. Yet, when I'm using attribute mode to define PSImode variable, gcc Is choosing SImode which is the smallest mode for it defined through wider_mode table. I want to define different behavior for PSImode Variables, how can I make sure this mode is actually attached to a variable? Thanks, Tal.
Re: [RFC] Marking C++ new operator as malloc?
On 9/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> > Well, we have that now:
> >
> > int *q = new int;
> > delete q;
> > int *p = new int;
> > delete p;
> > if (q != p)
> > cout << "different";
> >
> > we cannot optimize the test to be always true. The point is that alias
> > analysis tells us something about accesses to *q and *p, but neither
> > on lifetime of *q and *p nor lifetime of q and p (and thus their value).
>
> That's an interesting example. Thanks for showing it to me. From
> looking at the standard, I think I could be a language lawyer and try to
> argue that the comparison is not defined -- but that would just be
> weaselish; the comparison should be defined. So, yes, I concede that
> you've found a counter-example to my claim that "*p does not alias *q"
> => "p != q". How odd. I would have to revise my claim to require that
> "p" and "q" are valid pointers.
>
> So, for something like:
>
> char *pool;
> void *operator new[] (size_t s) { /* return memory from pool */ }
> ...
> pool = new char[1024];
> char *c = new char[16];
>
> IIUC, your claim is that if pool and c now have the same value, then any
> indirection through pool is invalid (because the object with newest
> lifetime at that location is the 16-byte array), so we can assume *pool
> and *c do not alias? Do you also claim that:
Yes.
> ((char (*)[16])pool)[0] = '\0';
>
> is invalid because it is a pointer "based on" pool?
Yes.
> If you think it's OK to put the "malloc" attribute on operator new, why
> did you say earlier that you can't implement "malloc" in C itself, for
> exactly these kinds of reasons? Isn't the situation exactly analogous?
It looks like, but C doesn't provide us with the notion of dynamic lifetime
of objects at the same memory location. That is, the "newest object"
argument doesn't work in C. In fact this is one reason why we should
not (or can't) put the malloc attribute on obstack_alloc -- it would be
valid to access the obstack memory through the pool pointer.
For C++ we can argue that 'new' starts lifetime of a new object at
the place of the old 'new'ed memory and accesses to the old object
invoke undefined behavior.
> I think I'm getting confused. Perhaps you could sum up in a single
> email the argument for why putting this attribute in our standard
> headers is safe, even in view of possible replacement in user programs?
My argument goes like "We can safely put attribute malloc on all overloads
of new as C++ starts lifetime of a new object in the target and accesses to
old objects at that location invoke undefined behavior". I claim that you
cannot construct a testcase with no undefined behavior that has two
pointers returned from a call to 'new' alias.
Richard.
support for float/complex math in libgcc cross-compiled
(I'm turning this into a thread of it's own, it's really the
continuation of "error compiling libgcc with ported cross-compiler"
from yesterday.)
I am porting GCC to a new target, and got the following error when
cross-compiling libgcc towards the end of the make process:
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1702: error: insn
does not satisfy its constraints:
(insn 1468 1467 1471
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1701 (set
(mem/c/i:SF (plus:SI (mem/f/c:SI (plus:SI (reg/f:SI 29 r29)
(const_int -296 [0xfed8])) [0 D.2393+0 S4 A8])
(const_int 4 [0x4])) [0 +4 S4 A8])
(reg:SF 0 r0 [orig:51 D.2338+4 ] [51])) 8 {movsf} (nil)
(nil))
I had a very similar problem some days ago, in the __powidf2 function,
and then the solution was to define the movsf insn.
This time I'm not sure what to do though. The problem now seems to be
with complex number, but do I really have to define complex
movsc-insns? I haven't found any other ports doing that, so I'm
guessing there's something else I'm missing.
What is really needed in terms of insns or target macros to support
the various types of math of libgcc? Am I missing some insn for moving
from SFmode to SImode?
Re: error compiling libgcc with ported cross-compiler
On Tue, Sep 11, 2007 at 08:52:38AM +0200, Tomas Svensson wrote:
> Thanks a lot for your input, I think I understand some of that code better
> now.
>
> I stumbled upon a solution last night, on realizing that the problem
> was with the DFmode powidf2 and seeing that I had not defined the
> movsf or movdf insns (because I thought I shouldn't need them, having
> no HW floating point support).
You shouldn't define them, they'll only hide the problem.
> Defining them solved the problem, but now I have a very similar one
> with the complex arithmetic __mulsc3 function in libgcc:
>
> /cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1702: error: insn
> does not satisfy its constraints:
> (insn 1468 1467 1471
> /cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1701 (set
> (mem/c/i:SF (plus:SI (mem/f/c:SI (plus:SI (reg/f:SI 29 r29)
> (const_int -296 [0xfed8])) [0 D.2393+0 S4 A8])
> (const_int 4 [0x4])) [0 +4 S4 A8])
> (reg:SF 0 r0 [orig:51 D.2338+4 ] [51])) 8 {movsf} (nil)
> (nil))
This is still the same problem that you had to begin with. Register 29 is
your stack pointer, frame pointer or something like that, isn't it?
To understand why this fails, you should compile that function manually,
adding -fdump-rtl-lreg -fdump-rtl-greg and look at that same insn in the two
dump files produced. In the lreg dump, you had something like
(set (mem (plus (reg x) (const_int 4))
(reg 0))
where x >= FIRST_PSEUDO_REGISTER. The function memory_address_p() (see
below) must accept this address and the function strict_memory_address_p()
must reject it.
The lreg dump file contains the output of the local-alloc pass and the
greg dump file contains the output of the global-alloc and reload passes.
All passes before reload use memory_address_p(). All passes starting with
reload use strict_memory_address_p(). It is reload which turns (reg x) into
(mem (plus (reg r29) (const_int ...)) if x >= FIRST_PSEUDO_REGISTER. That's
why strict_memory_address_p() must reject such registers in memory
addresses. Reload will then figure out how to make strict_memory_address_p()
happy with the address.
The macro GO_IF_LEGITIMATE_ADDRESS is used in two places in GCC:
$ grep -e '^memory_address_p ' -B 1 -A 7 gcc/recog.c
int
memory_address_p (enum machine_mode mode ATTRIBUTE_UNUSED, rtx addr)
{
GO_IF_LEGITIMATE_ADDRESS (mode, addr, win);
return 0;
win:
return 1;
}
$ grep -e '^strict_memory_address_p ' -B 1 -A 7 gcc/reload.c
int
strict_memory_address_p (enum machine_mode mode ATTRIBUTE_UNUSED, rtx addr)
{
GO_IF_LEGITIMATE_ADDRESS (mode, addr, win);
return 0;
win:
return 1;
}
These two functions are supposed to be different! To debug your problem,
maybe you should save the preprocessed source of recog.c and reload.c, grep
the two functions (and probably run them though indent), then compare them.
If that still doesn't help, use a debugger. You can use "call debug_rtx
(addr)" to pretty-print the address.
The way the two fuctions become different is that one has REG_OK_STRICT
defined and the other does not:
$ grep -F -e '#define REG_OK_STRICT' -e '#include "tm.h"' gcc/recog.c
gcc/reload.c
gcc/recog.c:#include "tm.h"
gcc/reload.c:#define REG_OK_STRICT
gcc/reload.c:#include "tm.h"
--
Rask Ingemann Lambertsen
Re: error compiling libgcc with ported cross-compiler
On 9/11/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: > On Tue, Sep 11, 2007 at 08:52:38AM +0200, Tomas Svensson wrote: >You shouldn't define them, they'll only hide the problem. You're right, and getting REG_OK_STRICT right solved the problem! That was probably the best answer I have ever gotten to any question I've asked online, by the way. Thank you very much for taking your time!
Re: [RFC] Marking C++ new operator as malloc?
"Richard Guenther" <[EMAIL PROTECTED]> writes: [...] | > I think I'm getting confused. Perhaps you could sum up in a single | > email the argument for why putting this attribute in our standard | > headers is safe, even in view of possible replacement in user programs? | | My argument goes like "We can safely put attribute malloc on all overloads ^ | of new as C++ starts lifetime of a new object in the target and accesses to | old objects at that location invoke undefined behavior". I claim that you | cannot construct a testcase with no undefined behavior that has two | pointers returned from a call to 'new' alias. I don't think I understand the claim. The C++ does not say anything about all overloads in terms of aliasing. IT makes claims about specific `operator new's. Could you elaborate on why it is OK to annotate all overloads? -- Gaby
Re: [RFC] Marking C++ new operator as malloc?
On 11 Sep 2007 07:24:44 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: > "Richard Guenther" <[EMAIL PROTECTED]> writes: > > [...] > > | > I think I'm getting confused. Perhaps you could sum up in a single > | > email the argument for why putting this attribute in our standard > | > headers is safe, even in view of possible replacement in user programs? > | > | My argument goes like "We can safely put attribute malloc on all overloads > ^ > | of new as C++ starts lifetime of a new object in the target and accesses to > | old objects at that location invoke undefined behavior". I claim that you > | cannot construct a testcase with no undefined behavior that has two > | pointers returned from a call to 'new' alias. > > I don't think I understand the claim. The C++ does not say anything > about all overloads in terms of aliasing. IT makes claims about > specific `operator new's. Could you elaborate on why it is OK to > annotate all overloads? Sorry for the wrong terminology, I think I mean all implementations of void* operator new(std::size_t) throw (std::bad_alloc); void* operator new[](std::size_t) throw (std::bad_alloc); void* operator new(std::size_t, const std::nothrow_t&) throw(); void* operator new[](std::size_t, const std::nothrow_t&) throw(); that is, not only annotating libsupc++ implementation but assuring the attribute is set by changing the C++ frontend. Richard.
Polyhedron test: gas_dyn run-time performance regression compared with yesterday
This is using the Polyhedron Fortran test. http://www.polyhedron.co.uk/MFL6VW74649 Using several options, the gas_dyn test got much slower; however, with some options, the performance remained roughly the same. In terms of the geometric mean, it is a slowdown of around 1%. The run time of the other programs only changed slightly (up/down/const). Result from http://www.suse.de/~gcctest/c++bench/polyhedron/ -ffast-math -funroll-loops -O3 -ftree-vectorize -march= ??? (opteron I think). 14.59s -> 21.06s (44% slower) Result on for my AMD Athlon64 4800+, http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/ Yesterday: 2007-09-10-r128322 Today: 2007-09-11-r128363 gfortran -march=opteron -ffast-math -funroll-loops -ftree-loop-linear -ftree-vectorize -msse3 -O3 11.55s -> 15.95s (40% slower) [geo.mean: 24.34 -> 24.67] gfortran -march=opteron -ffast-math -funroll-loops -ftree-vectorize -ftree-loop-linear -msse3 -fvect-cost-model Unchanged: 11.57s -> 11.54s [geo.mean: 24.27->24.29] gfortran -fprofile-use -march=opteron -ffast-math -funroll-loops -ftree-loop-linear -ftree-vectorize -O3 Unchanged: 11.56s -> 11.17s [geo.mean: 23.78s -> 23.90s] gfortran -m32 -march=opteron -ffast-math -funroll-loops -ftree-loop-linear -ftree-vectorize -O3 13.50s -> 24.11s (78% slower) [geo.mean: 27.30->27.48] gfortran -m32 -march=opteron -ffast-math -funroll-loops -ftree-loop-linear -ftree-vectorize -mfpmath=sse -msse3 -O3 13.29 -> 18.98 (43% slower) [geo.mean: 25.76s->26.25s] Tobias
Recent (middle-end?) regressions in the Fortran testsuite
The last few days have seen a regression in the Fortran testsuite on
i386-linux and x86_64-linux (filed as PR33391). The following code
gives wrong results at -O2 while it works at -O1:
program test
integer(kind=1) :: i
do i = -128, 127
end do
if (i /= -128) call abort
end program test
Also of interest, gfortran.dg/vect/vect-{1,2,4}.f90 have started
failing on ia64 and i386 (but not x86_64 and i686, apparently).
FX
Re: Recent (middle-end?) regressions in the Fortran testsuite
On Tue, Sep 11, 2007 at 03:50:39PM +0100, Fran?ois-Xavier Coudert wrote:
> The last few days have seen a regression in the Fortran testsuite on
> i386-linux and x86_64-linux (filed as PR33391). The following code
> gives wrong results at -O2 while it works at -O1:
>
> program test
> integer(kind=1) :: i
>
> do i = -128, 127
> end do
> if (i /= -128) call abort
> end program test
>
>
> Also of interest, gfortran.dg/vect/vect-{1,2,4}.f90 have started
> failing on ia64 and i386 (but not x86_64 and i686, apparently).
>
See the long thread I started at
http://gcc.gnu.org/ml/gcc/2007-09/msg00043.html
According to honza some inlining changes have broken gfortran
http://gcc.gnu.org/ml/gcc/2007-09/msg00044.html
such that the overflowing of the index i is now detected
and disallowed. I haven't tried to verify nor find the
exact commit that broke gfortran. One can supposely add
-fno-strict-overflow, but I think that this is bogus and
whatever commit is causing the regression should be
reverted.
--
Steve
Re: Polyhedron test: gas_dyn run-time performance regression compared with yesterday
Hello! > This is using the Polyhedron Fortran test. > http://www.polyhedron.co.uk/MFL6VW74649 > Using several options, the gas_dyn test got much slower; however, with > some options, the performance remained roughly the same. > In terms of the geometric mean, it is a slowdown of around 1%. > The run time of the other programs only changed slightly (up/down/const). > Result from http://www.suse.de/~gcctest/c++bench/polyhedron/ > -ffast-math -funroll-loops -O3 -ftree-vectorize -march= ??? (opteron I > think). > 14.59s -> 21.06s (44% slower) > Result on for my AMD Athlon64 4800+, > http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/ > Yesterday: 2007-09-10-r128322 > Today: 2007-09-11-r128363 The problem was introduced by r128353 [1]: 2007-09-10 Harsha Jagasia <[EMAIL PROTECTED]> Jan Sjodin <[EMAIL PROTECTED]> * tree-vect-analyze.c (vect_analyze_operations): Change comparison of loop iterations with threshold to less than or equal to instead of less than. Reduce min_scalar_loop_bound by one. * tree-vect-transform.c (vect_estimate_min_profitable_iters): Change prologue and epilogue iterations estimate to vf/2, when unknown at compile-time. Change versioning guard cost to taken_branch_cost. If peeling for alignment is unknown at compile-time, change peel guard costs to one taken branch and one not-taken branch per peeled loop. If peeling for alignment is known but number of scalar loop iterations is unknown at compile-time, change peel guard costs to one taken branch per peeled loop. Change the cost model equation to consider vector iterations as the loop iterations less the prologue and epilogue iterations. Change outside vector cost check to less than or equal to zero instead of equal to zero. (vect_do_peeling_for_loop_bound): Reduce min_scalar_loop_bound by one. * tree-vectorizer.h: Add TARG_COND_TAKEN_BRANCH_COST and TARG_COND_NOT_TAKEN_BRANCH_COST. ... [1]: http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00347.html Uros.
RE: Polyhedron test: gas_dyn run-time performance regression compared with yesterday
>> Result from http://www.suse.de/~gcctest/c++bench/polyhedron/ >> -ffast-math -funroll-loops -O3 -ftree-vectorize -march= ??? (opteron I >> think). >> 14.59s -> 21.06s (44% slower) > I will look into it right now, but at first glance it does not look like this benchmark is built with the cost model enabled. Thanks, > >> Result on for my AMD Athlon64 4800+, >> http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/ >> Yesterday: 2007-09-10-r128322 >> Today: 2007-09-11-r128363 > >The problem was introduced by r128353 [1]: > >2007-09-10 Harsha Jagasia <[EMAIL PROTECTED]> >Jan Sjodin <[EMAIL PROTECTED]> > >* tree-vect-analyze.c (vect_analyze_operations): Change >comparison of loop iterations with threshold to less than >or equal to instead of less than. Reduce >min_scalar_loop_bound by one. >* tree-vect-transform.c (vect_estimate_min_profitable_iters): >Change prologue and epilogue iterations estimate to vf/2, >when unknown at compile-time. Change versioning guard >cost to taken_branch_cost. If peeling for alignment is >unknown at compile-time, change peel guard costs to one >taken branch and one not-taken branch per peeled loop. >If peeling for alignment is known but number of scalar loop >iterations is unknown at compile-time, change peel guard >costs to one taken branch per peeled loop. Change the cost >model equation to consider vector iterations as the loop >iterations less the prologue and epilogue iterations. >Change outside vector cost check to less than or equal to >zero instead of equal to zero. >(vect_do_peeling_for_loop_bound): Reduce >min_scalar_loop_bound by one. >* tree-vectorizer.h: Add TARG_COND_TAKEN_BRANCH_COST and >TARG_COND_NOT_TAKEN_BRANCH_COST. >... > >[1]: http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00347.html > >Uros. >
RE: Polyhedron test: gas_dyn run-time performance regression compared with yesterday
Hello! > >> This is using the Polyhedron Fortran test. >> http://www.polyhedron.co.uk/MFL6VW74649 > >> Using several options, the gas_dyn test got much slower; however, with >> some options, the performance remained roughly the same. >> In terms of the geometric mean, it is a slowdown of around 1%. >> The run time of the other programs only changed slightly (up/down/const). > > >> Result from http://www.suse.de/~gcctest/c++bench/polyhedron/ >> -ffast-math -funroll-loops -O3 -ftree-vectorize -march= ??? (opteron I >> think). >> 14.59s -> 21.06s (44% slower) > > >> Result on for my AMD Athlon64 4800+, >> http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/ >> Yesterday: 2007-09-10-r128322 >> Today: 2007-09-11-r128363 > >The problem was introduced by r128353 [1]: Sorry, this is fixed by Ira's patch at http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00966.html The new times are: NV V-no-cmV-cm 15.85 11.02 11.14 There is a small regression introduced by the cost model now. This should get fixed as we tune the costs some more in stage 3. Thanks, Harsha
understanding __FUNCTION__ generation
hi list, recently I've encountered a problem in which some removals of (what seems to be unneeded) lines of header files inflicted changes in the resulting binary. further inverstigation showed that the chages were different __FUNCTION__.numbers (in the __FUNCTION__. xxx symbol names). can someone please help me understand what can change those numbers ? how are they generated and what control them ? thank you all sunzir
Re: Does g++ have a intel/msdn __COUNTER__ macro equivalent??
On 9/9/07, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > Ollie, would you mind adding a snippet to htdocs/gcc-4.3/changes.html > in the wwwdocs module of our CVS repository? If you need any help with > that, please let me know. Sent to gcc-patches at http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01017.html. Please review. Also, I recently added a new -fdirectives-only option which improves distcc and ccache performance. Does that merit a release note update as well? Ollie
Re: Does g++ have a intel/msdn __COUNTER__ macro equivalent??
> "Ollie" == Ollie Wild <[EMAIL PROTECTED]> writes: Ollie> Also, I recently added a new -fdirectives-only option which improves Ollie> distcc and ccache performance. Does that merit a release note update Ollie> as well? IMO, yes. Tom
Re: Another BOOTSTRAP failure on sparc-sun-solaris2.10, stage2 miscompiled
2007/9/10, John David Anglin <[EMAIL PROTECTED]>: > > I succeed past this failure if I revert Zdenek's iv-opts patch > (r128272). > > Same here. The failure also occurs on all hppa targets. > > Dave > -- > J. David Anglin [EMAIL PROTECTED] > National Research Council of Canada (613) 990-0752 (FAX: > 952-6602) > here too, on sparc/sparc64 linux systems: checking whether ln -s works... yes checking for sparc64-unknown-linux-gnu-gcc... /usr/local/src/trunk/objdir/./gcc/xgcc -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/sparc64-unknown-linux-gnu/bin/ -B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem /usr/local/sparc64-unknown-linux-gnu/include -isystem /usr/local/sparc64-unknown-linux-gnu/sys-include checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage2-target-libgcc] Error 1 make[2]: Leaving directory `/usr/local/src/trunk/objdir' -- Cheers, /ChJ
Re: Does g++ have a intel/msdn __COUNTER__ macro equivalent??
On Tue, 11 Sep 2007, Tom Tromey wrote: >> Also, I recently added a new -fdirectives-only option which improves >> distcc and ccache performance. Does that merit a release note update > as well? > IMO, yes. Seconded. :-) Gerald
New branch for GC work
Hello, Since mainline is in, or is about to enter very soon, stage 3, I have created a new branch "gc-improv" for GC work and related changes that are not strictly bug fixes. The difference from the old boehm-gc branch is that this one will not contain Boehm's GC integration. As my previous email http://gcc.gnu.org/ml/gcc/2007-09/msg00144.html did not receive any feedback, I assume that the plan there is OK and I will proceed according to it: - Take at least one more allocation site out of GC to pool or obstack; - The "easy" parts of the last week's NEXT_INSN = NULL trainwreck; - Couple more fixes/cleanups. These will be submitted to mainline on stage1/stage2. The interesting parts, already implemented in boehm-gc branch: - gengtype changes to generate separate GC allocators for each used type - convert GCC to use these - add type-tags to objects Then - New GC marker, using type-tags. I will document the gc-improv branch in svn.html shortly. Boehm-gc will stay in the list of active branches until I finish porting over stuff from it. Any comments about the plan are still very welcome :) -- Laurynas
Re: [RFC] Marking C++ new operator as malloc?
Richard Guenther wrote:
>> So, for something like:
>>
>> char *pool;
>> void *operator new[] (size_t s) { /* return memory from pool */ }
>> ...
>> pool = new char[1024];
>> char *c = new char[16];
>>
>> IIUC, your claim is that if pool and c now have the same value, then any
>> indirection through pool is invalid (because the object with newest
>> lifetime at that location is the 16-byte array), so we can assume *pool
>> and *c do not alias? Do you also claim that:
>
> Yes.
>
>> ((char (*)[16])pool)[0] = '\0';
>>
>> is invalid because it is a pointer "based on" pool?
>
> Yes.
Thanks for explaining your argument. It's very well-reasoned.
However, it still leads to weird results. For example, you're now in a
situation where transforming:
if (p == q)
*p = 3;
to:
if (p == q)
*q = 3;
is not valid. I'd imagine most people to be somewhat surprised by that;
it's rather contrary to the idea of equality. Are we sure we want to go
there?
(This issue does not occur with "restrict", because if the pointers were
known not to alias due to use of "restrict", then the comparison is
always false, by hypothesis -- or else the program behavior is already
undefined.)
>> If you think it's OK to put the "malloc" attribute on operator new, why
>> did you say earlier that you can't implement "malloc" in C itself, for
>> exactly these kinds of reasons? Isn't the situation exactly analogous?
>
> It looks like, but C doesn't provide us with the notion of dynamic lifetime
> of objects at the same memory location.
I'm not really confident C++ does either. Or, rather, that even if it
does, we should take advantage of that. I'm concerned that we're going
to break a lot of code.
> My argument goes like "We can safely put attribute malloc on all overloads
> of new as C++ starts lifetime of a new object in the target and accesses to
> old objects at that location invoke undefined behavior". I claim that you
> cannot construct a testcase with no undefined behavior that has two
> pointers returned from a call to 'new' alias.
Actually, the claim for attribute "malloc" must be even stronger -- the
value returned must not alias *any* other pointer. I don't think that
affects your argument, but just for the sake of clarity, that must be
your claim.
I think my point of view on this is that, whether or not the standard
can be read to support your claim, I don't think we should put the
attribute in our standard headers. I'd rather let people who know what
they're doing put that in their own headers if they want to do so. And,
I'd certainly suggest that we ask the ISO committee before doing this.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: Does g++ have a intel/msdn __COUNTER__ macro equivalent??
On 9/11/07, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > On Tue, 11 Sep 2007, Tom Tromey wrote: > >> Also, I recently added a new -fdirectives-only option which improves > >> distcc and ccache performance. Does that merit a release note update > > as well? > > IMO, yes. > > Seconded. :-) OK. I'll add a blurb for -fdirectives-only as well. One quick question. When I updated the gcc info page, Mark Mitchell felt strongly that it shouldn't mention distcc or ccache directly. However, I think it's a good idea to give users some idea what the option is good for. Is it appropriate to mention these applications in the release notes? Ollie
GCC 4.2 Branch Status: Slush
When I sent out the notice about GCC 4.2.2 RC1, I failed to note the GCC 4.2 branch should now be considered slushy; please get my explicit approval before check-in. Obviously, there was no way anyone could have known that, so if things have been checked in since the announcement that's fine; I'll review what's happened and decide what to do. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.3.0: Stage 3
GCC 4.3.0 will enter Stage 3 as of Wednesday, September 12th, at 11:59 PM PDT. (I've pushed this back from the previously announced September 10th date, since I failed to send out a final warning before that point.) I appreciate everyone taking the development guidelines seriously, and the fact that people have been working hard to get their Stage 2 patches submitted in timely fashion. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: understanding __FUNCTION__ generation
Sunzir Deepur wrote:
recently I've encountered a problem in which some removals of
(what seems to be unneeded) lines of header files inflicted changes in
the resulting binary. further inverstigation showed
that the chages were different __FUNCTION__.numbers (in the __FUNCTION__.
xxx symbol names).
This would be clearer if you gave an example. However, I'm guessing
that the issue here is the names for function local statics. The names
for these are unique within a function, but not unique across a file.
The assembler requires unique names for them, so we add the DECL_UID to
make them unique. See lhd_set_decl_assembler_name in langhooks.c. The
DECL_UID changes if you add/delete declarations.
For instance, if I compile this with -O -S for an x86_64-linux target
int *sub (void) { static int i = 10; return &i; }
int *sub2 (void) { static int i = 20; return &i; }
I get variables i.1499 and i.1504. If I add another variable in the
first line
static int y;
then I now have variables i.1500 and i.1505.
This wouldn't happen with functions unless you have nested functions.
You could see a similar problem if compiling multiple files as one unit,
since static functions in different files could have the same name,
which would have to be changed to make them unique. This is probably
handled in a different place in the gcc code, but probably handled the
same way.
Jim
Re: [RFC] Marking C++ new operator as malloc?
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> On 9/9/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> >
> > Which brings back the fact that you cannot implement malloc in C
> > (you certainly remember the discussions about C++ placement new
> > handling wrt aliasing). To re-use the machinery we invented there
> > we would need to place a CHANGE_DYNAMIC_TYPE_EXPR for
> > the pointer assignment resulting from inlining a function with
> > attribute malloc set. As you say, unless we are inlining such functions
> > we are safe in practice.
>
> Actually this looks nice in general. We could implement placement
> new in C this way:
>
> extern inline T * __attribute__((malloc)) placement_new (void *p)
> { return p; }
>
> if we can somehow encode the target type here. Note that only
> type-based aliasing is a problem with this discussion - PTA will
> be obviously fine if new is inlined as it will see that both pointers
> are related and we loose the 'malloc' attribution on the target pointer
> during inlining.
CHANGE_DYNAMIC_TYPE_EXPR has the target type, of course. So perhaps
we need __attribute__ ((change_dynamic_type))?
Or actually of course __attribute__ ((malloc)) is fine but we could
throw in a CHANGE_DYNAMIC_TYPE_EXPR after any call to such a
function. That ought to do the right thing for C malloc
implementations as well, I think.
Ian
Re: SImode and PSImode question
Tal Agmon wrote: I see many references in gcc code to SImode. Isn't this problematic for ports such as this when SImode does not represent the natural int? In the gcc dir, "grep SImode *.[ch] | wc" shows only 67 lines. That isn't a large number relatively speaking. Many of these are in comments, and some are correct because they relate to libgcc functions. It does look like loop-iv.c is broken though. Every simplify_gen_relational call uses SImode. That probably should be word_mode instead. You might want to submit a bug report for that. I would like to define PSImode for 36-bit accumulators. Yet, when I'm using attribute mode to define PSImode variable, gcc Is choosing SImode which is the smallest mode for it defined through wider_mode table. I want to define different behavior for PSImode Variables, how can I make sure this mode is actually attached to a variable? I'm not sure if anyone has ever done this before. The assembler/linker/etc have no support for odd sized variables. Usually the partial int modes were just used internal to gcc. For instance, if you have 24-bit address registers, you would use 32-bit pointers, and convert on input/output to the 24-bit PSImode internally, but no user variable would ever be PSImode. Anyways, I assume you are talking about the code in stor-layout.c in layout_type that calls smallest_mode_for_size. This uses TYPE_PRECISION. Have you defined a built-in type with an appropriate size for your PSImode variables? There is certainly no standard type with odd sizes that will work here.
Re: SImode and PSImode question
Jim Wilson <[EMAIL PROTECTED]> writes: > I'm not sure if anyone has ever done this before. The > assembler/linker/etc have no support for odd sized variables. > Usually the partial int modes were just used internal to gcc. For > instance, if you have 24-bit address registers, you would use 32-bit > pointers, m32c has a 24 bit PSImode. It really does have 24 bit registers. Pointers are 32 bits when stored outside of registers, but the assembler and linker certainly support 24 bit constants, including a .3byte pseudo for setting up some of the chip-specific tables. Note also that gcc has mode_wider[] and mode_2xwider[] to differentiate between those.
Re: gnu c reference manual : c dialects
Trevis Rothwell <[EMAIL PROTECTED]> writes: > Would it be useful to delineate not only between ISO C features and > GNU C extensions, but also to delineate between the C89 and C99 > standards? Yes. Ian
Re: Why is building a cross compiler "out-of-the-box" always broken?
Stephen, I have been working on the x86_64-pc-mingw32 toolchain with Kai Tietz (Kai is the main person, I am doing much more learning than helping). I put together a built script that requires no tweaking whatsoever of any of the projects incorporated in the toolchain. It is very straightforward. You can check it out here: http://mingw-w64.svn.sourceforge.net/viewvc/*checkout*/mingw-w64/experimental/buildsystem/makebuildroot.sh?revision=56 The project itself is here: https://sourceforge.net/projects/mingw-w64 If you make a new directory (like /tmp/rt) and change into it, then run the script with the single argument "build", it will download binutils, gcc, the crt, and the headers, then proceed to compile everything using the most default set of options and create a buildroot starting at the present working directory. The options to binutils are: --prefix=$PF --with-sysroot=$PF --target=x86_64-pc-mingw32 --disable-nls gcc only adds the option --enable-languages=c. The disable-nls option is just there to make the build faster -- it is not needed. with-sysroot has replaced with-headers and with-includes, and it allows for easy creation of buildroots. I set the prefix equal to the same thing because it works and I don't really understand it enough to do differently. The biggest difference between this and normal toolchains is the absence of glibc. Anyway, tell me what you think.
Re: understanding __FUNCTION__ generation
Hi Jim, On 9/12/07, Jim Wilson <[EMAIL PROTECTED]> wrote: > Sunzir Deepur wrote: > > recently I've encountered a problem in which some removals of > > (what seems to be unneeded) lines of header files inflicted changes in > > the resulting binary. further inverstigation showed > > that the chages were different __FUNCTION__.numbers (in the __FUNCTION__. > > xxx symbol names). > > This would be clearer if you gave an example. This is the diff between the old and the new binaries examined under objdump -d -t : 2c2 < old.o: file format elf32-i386 --- > new.o: file format elf32-i386 10c10 < l O .rodata 000f __FUNCTION__.4883 --- > l O .rodata 000f __FUNCTION__.4848 12c12 < 005a l O .rodata 0010 __FUNCTION__.4921 --- > 005a l O .rodata 0010 __FUNCTION__.4886 17c17 < 00d8 l O .rodata 0015 __FUNCTION__.4965 --- > 00d8 l O .rodata 0015 __FUNCTION__.4930 20c20 < 0119 l O .rodata 000e __FUNCTION__.5002 --- > 0119 l O .rodata 000e __FUNCTION__.4967 22c22 < 01a8 l O .rodata 000e __FUNCTION__.5022 --- > 01a8 l O .rodata 000e __FUNCTION__.4987 24c24 < 021b l O .rodata 0010 __FUNCTION__.5051 --- > 021b l O .rodata 0010 __FUNCTION__.5016 > However, I'm guessing > that the issue here is the names for function local statics. The names > for these are unique within a function, but not unique across a file. > The assembler requires unique names for them, so we add the DECL_UID to > make them unique. See lhd_set_decl_assembler_name in langhooks.c. The > DECL_UID changes if you add/delete declarations. Yes ! That is it ! Thanks so much ! I use the __FUNCTION__ macro in my code, and i guess it is translated into a static variable holding the function name, which perfectly fits your explanation ! Thanks!! Sunzir
