Re: POINTER_PLUS branch status?
On Mon, 2007-05-28 at 15:29 -0700, Mark Mitchell wrote: > Andrew -- > > I'm trying to firm up GCC 4.3 planning a bit. One of the things I'm > considering is whether or not the POINTER_PLUS branch should be merged > as part of 4.3. My understanding from looking at your emails is that > the branch is in pretty good shape. > > Would you please give me a summary of the status? Are there regressions > on major platforms? > > Also, does anyone feel that this representation change is a bad thing? > Are there any objections to merging this branch in principle, assuming > that it's not causing regressions, either in generate code or at compile > time? No objections from me -- I'm just happy someone went through the trouble of fixing all the issues necessary to make PTR_PLUS work. When I looked at what it would take to break out pointer arithmetic from normal arithmetic it looked to be rather ugly. I haven't followed PTR_PLUS development at all -- what specifically spurred you to hack on this Andrew? Jeff
Re: [testsuite gfortran] partial fix for secnds*.f
Rask Ingemann Lambertsen wrote: On Mon, May 28, 2007 at 05:14:51PM +, R. D. Flowers, Chattanooga TN USA wrote: I think we should use parentheses to enforce the order. I could be missing something here, and it is almost separate statements, and might be ugly, but -- comma clauses? foo=term1,foo+=term2,foo+=term3 ... ; http://gcc.gnu.org/bugs.html#nonbugs_c> The link you supplied points to potential problems if there are inadequate sequence points in the presence of side-effects. It doesn't mention comma clauses, does it? I do not see the problem when providing adequate sequence points ( what AFAIK is the sole purpose of comma's in a statement -- comma clauses ), and when the terms are constants or simple expressions (so no side-effects). Am I missing something embarassingly obvious ( comma got removed from the C standard or something )?
Re: Compatibility between object code of gcc versions
Lu
Re: [testsuite gfortran] partial fix for secnds*.f
On Tue, May 29, 2007 at 03:10:57AM +, R. D. Flowers, Chattanooga TN USA wrote: > > Rask Ingemann Lambertsen wrote: > >On Mon, May 28, 2007 at 05:14:51PM +, R. D. Flowers, Chattanooga TN > >USA wrote: > > > >>foo=term1,foo+=term2,foo+=term3 ... ; > > > >http://gcc.gnu.org/bugs.html#nonbugs_c> > Am I missing something embarassingly obvious ( comma got removed from > the C standard or something )? No, I misread your suggested code, I don't think the link applies to this case. -- Rask Ingemann Lambertsen
Different classes for base registers
Hi,
I'm working on a new target port in which there are different base
registers
allowed depending on the offset:
r0-r7 are allowed as base register only when the offset is zero.
r6-r7 are allowed as base register for every offset.
I'm wondering if gcc is prepared for such scenario, examine the code in
find_reloads_address(), for the architecture I'm working on, it seems
the
condition here should be true, because it might not be valid because the
base reg isn't r6-r7, not only because the disp is too large.
Yet it fails because of REG_MODE_OK_FOR_BASE_P (XEXP (ad, 0), mode).
/* If we have address of a stack slot but it's not valid because the
displacement is too large, compute the sum in a register.
Handle all base registers here, not just fp/ap/sp, because on some
targets (namely SH) we can also get too large displacements from
big-endian corrections. */
else if (GET_CODE (ad) == PLUS
&& REG_P (XEXP (ad, 0))
&& REGNO (XEXP (ad, 0)) < FIRST_PSEUDO_REGISTER
&& REG_MODE_OK_FOR_BASE_P (XEXP (ad, 0), mode)
&& GET_CODE (XEXP (ad, 1)) == CONST_INT)
{
/* Unshare the MEM rtx so we can safely alter it. */
if (memrefloc)
{
*memrefloc = copy_rtx (*memrefloc);
loc = &XEXP (*memrefloc, 0);
if (removed_and)
loc = &XEXP (*loc, 0);
}
...
Is there any way to get along by defining r0-r7 as legal base regs and
deal
with r6-r7 in GO_IF_LEGITIMATE_ADDRESS and in the constraint
definitions,
or am I right with my assumption that gcc doesn't support that?
Does someone knows if there's a target with a similar behavior?
Thanks in advance,
Tal Agmon.
Interpreting LSDA information
Hi, LSDA (Language Specific Data Area) is used to store exception handling information at the exception catch site, see http://www.codesourcery.com/cxx-abi/exceptions.pdf. For various kinds of binary analyzers (translators, optimizers) it is useful to be able to interpret the LSDA of a given C++ function. So, once the LSDA extent is identified, are there any tools, scripts, code snippets, that can analyze and interpret this LSDA in a raw byte form and produce a textual interpretation of it? Thanks, --- Yaakov Yaari IBM Haifa Research Lab
Re: Different classes for base registers
On Tue, May 29, 2007 at 03:56:38PM +0300, Tal Agmon wrote: > Hi, > > I'm working on a new target port in which there are different base > registers > allowed depending on the offset: > r0-r7 are allowed as base register only when the offset is zero. > r6-r7 are allowed as base register for every offset. I think a new macro along the lines of MODE_CODE_BASE_REG_CLASS might do the trick. Perhaps this family of macros needs to be cleaned up, so you have: RTX_BASE_REG_CLASS(x) RTX_INDEX_REG_CLASS(x) where x is the address expression as an RTX. -- Rask Ingemann Lambertsen
Re: Target Hook not getting recognized - GCC 4.1.1
"Rohit Arul Raj" <[EMAIL PROTECTED]> writes: > I have defined a target hook TARGET_EXPAND_BUILTIN_SAVEREGS (GCC > 4.1.1) as an alternative to TARGET_SETUP_INCOMING_VARARGS so as to > code ___builtin_saveregs as per my target. But this target hook is not > getting recognized. > > Is there anything else this target hook depends on? What do you mean by "is not getting recognized?" That target hook should always be used for code which calls __builtin_saveregs. It's not clear to me that there is any normal case in which that function will be called. Ian
Re: POINTER_PLUS branch status?
Andrew Pinski wrote: I cleaned up the code today so it basically ready to be merged, some (most?) of the target headers still need to be fixed for the change. The list of targets which need to be changed is: alpha ia64 mips pa s390sparcstormy16xtensa I don't have access to any of those targets (and I have not built a sim based compiler yet). I would like help converting those last 8, the patch should mirror what was done for rs6000, spu or sh. I'm happy to fix up the Xtensa port for this, but I might not get to it right away. Please don't let me hold you up. Go ahead and merge it whenever it's ready and I'll fix up the Xtensa port after the merge. --Bob
Re: Interpreting LSDA information
Yaakov Yaari <[EMAIL PROTECTED]> writes: > LSDA (Language Specific Data Area) is used to store exception handling > information at the exception catch site, see > http://www.codesourcery.com/cxx-abi/exceptions.pdf. > > For various kinds of binary analyzers (translators, optimizers) it is > useful to be able to interpret the LSDA of a given C++ function. So, once > the LSDA extent is identified, are there any tools, scripts, code snippets, > that can analyze and interpret this LSDA in a raw byte form and produce a > textual interpretation of it? It's probably rather more simple minded than you want, but you can get a dump of sorts by using readelf --debug-dump=frames. Ian
Re: Bugzilla wishes (Was: Volunteer for bug summaries?)
On Mon, May 28, 2007 at 07:29:33AM -0400, Daniel Berlin wrote: > On 5/28/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: > >On Wed, May 23, 2007 at 02:06:21PM -0400, Daniel Berlin wrote: > > > >> I have to look into bugzilla 3.0 migration first though. Bugzilla 3.0 > >> introduces a custom fields mechanism, and i'd rather at least store > >> our data using that, than editing the schema wholesale like we do now > >> (which is *much* harder to port between versions of bugzilla, and one > >> of the reason we've had trouble keeping up). > > > > Bug reports have build, host and target fields. Search results show just > >the host field, which is rarely of any use. I think it would be great if > >instead the target field were shown. Build system maintainers might want to > >see the build field instead. > > You can customize what fields are shown on the search results, if you like. > It used to be the target field, but it was requested to change it to > the the host field. The problem is that people don't fill in these fields on a consistent basis, or, for a native compiler, they pick one of the three to fill in and leave the others blank, but they make different choices. I suppose that the form could ask whether it's a native, cross, or Canadian cross, and then expose the extra fields, but that might be too painful and it doesn't fix the existing data.
Re: Fixed-point branch?
Mark Mitchell wrote: Chao-Ying, I'm also interested in whether or not these changes have any impact on C++. With your changes, does GNU C++ now accept any fixed-point constructs? Chao-ying's on vacation this week. AFAIK Chao-ying's code does nothing explicit to support, or not support, C++. The front-end code was based on the Decimal floating point extension, so should currently behave in a similar fashion to that with regards C++. If so, are you aware of any effort to standardize any of this functionality in C++? Annex F (page 96) of the N1169 spec (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf) does give some "guidelines" for C++ usage, but only a very hand-wavy couple of paragraphs. I guess we can ask the committee members if there is any work going on in this area. (I think that my preference, in the short term, would be to disable this functionality in C++ -- although, of course, we will eventually want to turn it on so that GNU C++ is as much as possible a superset of GNU C.) OK Nigel
Re: special keyword for silent wrong-code bugs
> If we segfault for printf("%d\n", 2+2), the bug would not be in this
> category. If we printed 5, it would be.
So what if the printf statement is executed only once every leap year?
What if it segfaults only if you have one out of several thousand
address space randomization patterns?
Your distinction has no practical value when considering miscompilations of
single translation units, since the triggering of the bug depends on the
miscompiled function being called, and being called with just the right
preconditions to trigger the bug.
[tuples] mainline merged into branch
...as of rev 125166. No surprises. Aldy
.eh_frame section
Hello, I read that the eh_frame is for exceptions support, for languages like C++ for instance. I wonder why when I compile standard C programs using "gcc -v simple.c" I can see that the linker adds the "--eh-frame-hdr" parameter ? After all there is no use for the eh section when we don't support exceptions, no ? thank you sfora
Re: Volunteer for bug summaries?
Daniel Berlin wrote: >> 1. Add a field to bugzilla for the SVN revision at which a particular >> regression was introduced. Display that in bugzilla as a link to the >> online SVN history browser so that clicking on a link takes us from the >> PR straight to the checkin. This field value ought to be the most >> recent revision to the GCC trunk such that the bug did not occur in the >> previous revision, but does occur in all subsequent revisions. >> >> Danny B., would you be willing to do this? > > Sure. Thanks! There was some subsequent discussion about exactly what ought to be stored. FWIW, I agree that storing a range might be useful, but I think it's important that we impose enough structure that we can easily run queries without having to do a lot of parsing on the field. Just my two cents, though. > I have to look into bugzilla 3.0 migration first though. Understood. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: .eh_frame section
"sfora dim" <[EMAIL PROTECTED]> writes: > I read that the eh_frame is for exceptions support, > for languages like C++ for instance. Yes. > I wonder why when I compile standard C programs using "gcc -v simple.c" > I can see that the linker adds the "--eh-frame-hdr" parameter ? That option is always used if the linker supports it. > After all there is no use for the eh section when we don't support > exceptions, no ? Ideally the linker would not generate an EH header if there is no exception frame information. It is possible to use gcc to link C++ code, and it is desirable to always create an EH header if there is any exception frame information, so if there is a problem here I think it should be fixed in the linker. Ian
Re: POINTER_PLUS branch status?
On 5/29/07, Jeffrey Law <[EMAIL PROTECTED]> wrote: I haven't followed PTR_PLUS development at all -- what specifically spurred you to hack on this Andrew? For spu-elf, good alignment information is needed for each load/store as each load/store is only done on 128bit alignment. Since we lose a lot of alignment in 4.0 after http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00020.html Which actually mention you were working on this before (but it looks it was dropped by you). The next step is to see if that patch is no longer needed for hppa (well and fixing the hppa back-end). And this improvement alignment information should improve the code size for spu-elf (which is important to me as we are only playing with 256k of memory). Thanks, Andrew Pinski
Re: Bribing a reviewer
On May 25, 2007, at 12:26 PM, Thomas Neumann wrote: Unfortunately reviewing as been, ahem, a bit slow. :-( I'd ask if the SC has had any luck finding suitable reviewers yet... I do think Fortran has about the right number judging from the latency on patch review. They have about 1 reviewer per 26k lines of code. C++ has about 63K per reviewer. And, the rest of the compiler, well, lets just say that if we compare the number of reviewers with the numbers of lines, it goes up from there I bet. If we compare with the number of actual recent reviewers instead of the theoretic maximal number of reviewers, I think the numbers go up even further. I think the SC doesn't want more global people, then, I think we should farm out the bits that are suffering from review bandwidth into new groups that may be easier to find maintainers for.
Re: Bugzilla wishes (Was: Volunteer for bug summaries?)
On 5/29/07, Joe Buck <[EMAIL PROTECTED]> wrote: On Mon, May 28, 2007 at 07:29:33AM -0400, Daniel Berlin wrote: > On 5/28/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: > >On Wed, May 23, 2007 at 02:06:21PM -0400, Daniel Berlin wrote: > > . > > You can customize what fields are shown on the search results, if you like. > It used to be the target field, but it was requested to change it to > the the host field. The problem is that people don't fill in these fields on a consistent basis, or, for a native compiler, they pick one of the three to fill in and leave the others blank, but they make different choices. I suppose that the form could ask whether it's a native, cross, or Canadian cross, and then expose the extra fields, but that might be too painful and it doesn't fix the existing data. We have these fields not because we necessarily decided they were useful, but because they were in gnats. I have no aversion to removing/replacing/whatevering any/all of them with something better. I'm also happy to write converters for our current data into whatever we decide is more useful.
fixinclude, math.h and Darwin???
Can anyone explain exactly how and when the file... gcc/fixincludes/tests/base/architecture/ppc/math.h is used when building gcc on Darwin PPC? I ask because I just noticed that it contains the remapping of the long double math calls to use the appended $LDBL128 suffix. I am wondering if it is possible that our problem with these long double calls in gfortran on Darwin PPC could be as simple as gfortran not using this fixed math header on Darwin PPC. Thanks in advance for any clarifications. Jack
Dorit, Richi and Zdenek appointed Auto-Vectorizer maintainers
I am pleased to announce that the GCC Steering Committee has appointed Dorit Nuzman, Richard Guenther, and Zdenek Dvorak as Auto-Vectorizer maintainers. Please join me in congratulating Dorit, Richard, and Zdenek on their new role. Please update your listings in the MAINTAINERS file. Happy hacking! David
Re: .eh_frame section
On 29 May 2007 15:27:43 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > I wonder why when I compile standard C programs using "gcc -v simple.c" > I can see that the linker adds the "--eh-frame-hdr" parameter ? That option is always used if the linker supports it. > After all there is no use for the eh section when we don't support > exceptions, no ? Ideally the linker would not generate an EH header if there is no exception frame information. It is possible to use gcc to link C++ code, and it is desirable to always create an EH header if there is any exception frame information, so if there is a problem here I think it should be fixed in the linker. I don't know if it is a problem. If it's a pure C program, and we're giving the linker the "--eh-frame-hdr" - does it still generate the EH header ? if so - does it waste memory ? if yes, maybe the gcc driver should pass that parameter to the linker only when there really is exception frame information ? thank you sfora Ian
