debugging capabilities on AIX ?
Hello, Working on GCC 4 based GNAT port for AIX 5.[23], our testsuite to evaluate GDB (6.4) debugging capabilities currently yields very unpleasant results compared to what we obtain with a GCC 3.4 based compiler (80+ extra failures out of 1800+ tests). We so far presumed that this is caused by limitations in the XCOFF/STABS debug info format more heavily exposed by the many great compiler improvements between 3.4 and 4.x. I'd appreciate feedback on general questions from these observations: Is it generally known/expected that xcoff/stabs debugging capabilities degrade when moving from 3.4 to 4.x ? If yes, how is that considered by AIX GCC developers ? (how serious the issue, is it fixable, are there plans/attempts to move to DWARF2, ...) Thanks much in advance, With Kind Regards, Olivier
RE: dump after RTL expand
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Paul Brook > Sent: Friday, January 12, 2007 12:34 AM > To: gcc@gcc.gnu.org > Cc: Steven Bosscher; Andrija Radicevic > Subject: Re: dump after RTL expand > > On Thursday 11 January 2007 19:27, Steven Bosscher wrote: > > On 1/11/07, Andrija Radicevic <[EMAIL PROTECTED]> wrote: > > > Hi, > > > how could I find out from which patterns, in the md file, the > 00.expand > > > file was generated (i.e. to map the patterns in the expand file with > the > > > ones in the .md file)? Is there a compiler option/switch which would > tell > > > the compiler mark the patterns in the expand file with the insns names > > > from the md file? > > > > There isn't. > > > > You would have to walk over the insn and make recog assign them an insn > > code. > > That still wouldn't tell you what names were used to generate them. It's > common to have a named expander that generates other (possibly anonymous > insns). > Does that mean that the expand file isn't the dump after the initial rtl generation phase? According to internals manual, only the named define_insn and define_expand are used during rtl generation phase. Regards Andrija
Re: dump after RTL expand
On 1/12/07, Andrija Radicevic <[EMAIL PROTECTED]> wrote: > On Thursday 11 January 2007 19:27, Steven Bosscher wrote: > > On 1/11/07, Andrija Radicevic <[EMAIL PROTECTED]> wrote: > > > Hi, > > > how could I find out from which patterns, in the md file, the > 00.expand > > > file was generated (i.e. to map the patterns in the expand file with > the > > > ones in the .md file)? Is there a compiler option/switch which would > tell > > > the compiler mark the patterns in the expand file with the insns names > > > from the md file? > > > > There isn't. > > > > You would have to walk over the insn and make recog assign them an insn > > code. > > That still wouldn't tell you what names were used to generate them. It's > common to have a named expander that generates other (possibly anonymous > insns). > Does that mean that the expand file isn't the dump after the initial rtl generation phase? According to internals manual, only the named define_insn and define_expand are used during rtl generation phase. The manual is correct, but the define_expands can produce the anonymous insns. If you recog an insn that isn't a named pattern, you still get the "name" of the define_insn (with the "*" in front of it) or just "" if the insn doesn't have a name. You always get at least the insn code. Gr. Steven
RFC: Extending --help
Hi Guys,
Last month I submitted a patch to add a new switch to gcc:
--print-optimizers. The idea of this switch was that it would only
display those switches that controlled optimizations, and that it
would show their current status (activated/not activated). Mark
Mitchell suggested that it would be better to integrate this feature
into the current --help switch, so here is my proposal:
I would like to extend the --help switch so that, optionally, it
takes a parameter describing what type of information is required:
--help Does exactly the same as before.
--help=target Displays target specific switches only.
--target-help now becomes an alias for this
switch.
--help=warningsDisplays switches that control warnings.
Displays switch status as described below.
--help=optimizers Displays switches that control optimizations.
Display switch status as described below.
--help={tool} Displays the --help output of the specified
tool (cpp, cc1, cc1plus, as, collect-ld, ld).
--help=pre-processor-symbols Displays all the symbols predefined
by the pre-processor. (Not sure if this option
will be popular. I like it because I can never
remember the magic incantation to get this
information emitted into the .i file, and
besides I do not want the information in a .i
file, I want it listed to stdout).
For the --help=warnings and --help=optimizers switch extra
information is also displayed about each switch. If the -Q switch
has been enabled earlier on the command line, then the descriptive
help text for each of the switches is displayed alongside the
switch. Otherwise the help text is omitted and instead an
indication is given as to whether the switch is currently enabled or
disabled. This information is sensitive to the position of the
--help=... switch on the command line, so that it is possible for
example to use:
gcc -O2 --help=optimizers
to find out which optimizations are active at -O2, or even:
gcc -O3 --help=optimizers > /tmp/O3-opts
gcc -O2 --help=optimizers > /tmp/O2-opts
diff /tmp/O2-opts /tmp/O3-opts | grep enabled
to find out which extra optimizations are enabled by the -O3 switch.
This enabled/disabled output will also be in a well defined format,
making it machine parsable. This is helpful for another project we
are working on - the automatic selection of the most effective
optimization options to compile any given particular application.
For switches which are not binary in nature, the current state of
the switch would be displayed.
What do you think ?
Cheers
Nick
Re: bug management: WAITING bugs that have timed out
Peter Barada <[EMAIL PROTECTED]> writes: > Saddest is that is that in a batch of various related bug closings, the > blanket comment "M68k/ColdFire is not a primary platform - CLOSED". That should not happen, they should only get their target milestone bumped. I cannot remember having seen any case of a bug being _closed_ just because the platform is not a primary one. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: bug management: WAITING bugs that have timed out
> > Saddest is that is that in a batch of various related bug closings, the > > blanket comment "M68k/ColdFire is not a primary platform - CLOSED". > > That should not happen, they should only get their target milestone > bumped. I cannot remember having seen any case of a bug being _closed_ > just because the platform is not a primary one. Neither can I. -- Eric Botcazou
Re: PATCH: Build shared libraries with -Bsymbolic-functions
H. J. Lu writes: > On Thu, Jan 11, 2007 at 07:33:21PM +0100, Paolo Bonzini wrote: > > > > >config/ > > > > > >2007-01-10 H.J. Lu <[EMAIL PROTECTED]> > > > > > > * ld-symbolic.m4: New. > > > > Please name the macro AC_LIB_PROG_LD_GNU_SYMBOLIC, or > > ACX_PROG_LD_GNU_SYMBOLIC. > > > > >libgfortran/ > > > > > >2007-01-10 H.J. Lu <[EMAIL PROTECTED]> > > > > > > * aclocal.m4: Include ../config/lib-ld.m4 and > > > ../config/ld-symbolic.m4. > > > > Also, aclocal.m4 is automatically generated with "aclocal -I ../config" > > except in libjava. > > > > > * configure.ac: Use PROG_LD_GNU_SYMBOLIC. Set > > > libgcj_ld_symbolic to $SYMBOLIC_LDFLAGS if it isn't set. > > > > Please check if libgcj_ld_symbolic is now obsolete in > > libjava/configure.host. > > libjava will use -Bsymbolic on Linux, which is more aggresive than > -Bsymbol-functions. libjava doesn't use -Bsymbolic for all of its libraries, just for libgij, libjvm, and libawt. I'd use -Bsymbolic for libgcj as well, but (because of copy relocs) we'd have to compile all gcj executables -fpic. I presume your patch doesn't change this behaviour. Andrew.
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: Mis-handled ColdFire submission?
Nathan Sidwell writes: > 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. Ah, that explains it all. Thank you. Andrew.
error when porting from g++ for hp-ux to g++ for linux
Hi,
here's a little sample code, which could be compiled with g++ 3.01 under
hp-ux, but when compiled with g++ 3.4.6 under linux, following error
occured:
sample.c: In member function 'T C2::PROC(T)':
sample.c:19: error: 'c1i' was not declared in this scope
Compilation was executed with "g++ sample.c" without any further
options. Other compiler versions are not existing.
Does anyone know why the compilation doesn't work? I have used a similar
code under g++ hp-ux which works well.
Many thanks in advance
Oliver
sample.c
--
#include
#include
#include
using namespace std;
template class C1 {
public:
T c1i;
C1() { c1i = 1.0; };
~C1() { };
};
template class C2 : public C1 {
public:
T c2i;
C2() { c2i = 1; };
~C2() { };
T PROC(T x) { c1i = c2i; };
};
int main(int argc, char **argv)
{
C1 c1;
C2 c2;
return EXIT_SUCCESS;
}
Re: PATCH: Build shared libraries with -Bsymbolic-functions
On Fri, Jan 12, 2007 at 08:57:42AM +0100, Paolo Bonzini wrote: > > >libjava will use -Bsymbolic on Linux, which is more aggresive than > >-Bsymbol-functions. It will bind global data references locally in > >additon to global function references. My patch will keep -Bsymbolic > >for libjava if it is set by libjava/configure.host. > > > >Here is an updated patch. > > The configury logic is fine by me, but please wait for approval at least > from the libjava and libstdc++ maintainers since I don't understand > fully the consequences of the -Bsymbolic stuff. Could it be considered > an ABI change, in that programs previously overriding some symbols will > break? (Sorry if the question is dumb). My change should allow programs to override functions which are overridable as specified in language standards. That is why I build libstdc++.so with --dynamic-list-cpp-new so that programs can override C++ operator new/delete. Programs depending on overriding function symbols, which aren't overridable in language standards, are broken. In theory, you can have a huge .o file containing all library functions which aren't overridable in language standard. You won't be able to override any of those functions when that .o file is linked in statically. Since I used -Bsymbolic-functions, it has no effect on data symbols. H.J.
Re: PATCH: Build shared libraries with -Bsymbolic-functions
On Fri, Jan 12, 2007 at 12:13:11PM +, Andrew Haley wrote: > H. J. Lu writes: > > On Thu, Jan 11, 2007 at 07:33:21PM +0100, Paolo Bonzini wrote: > > > > > > >config/ > > > > > > > >2007-01-10 H.J. Lu <[EMAIL PROTECTED]> > > > > > > > >* ld-symbolic.m4: New. > > > > > > Please name the macro AC_LIB_PROG_LD_GNU_SYMBOLIC, or > > > ACX_PROG_LD_GNU_SYMBOLIC. > > > > > > >libgfortran/ > > > > > > > >2007-01-10 H.J. Lu <[EMAIL PROTECTED]> > > > > > > > >* aclocal.m4: Include ../config/lib-ld.m4 and > > > >../config/ld-symbolic.m4. > > > > > > Also, aclocal.m4 is automatically generated with "aclocal -I ../config" > > > except in libjava. > > > > > > >* configure.ac: Use PROG_LD_GNU_SYMBOLIC. Set > > > >libgcj_ld_symbolic to $SYMBOLIC_LDFLAGS if it isn't set. > > > > > > Please check if libgcj_ld_symbolic is now obsolete in > > > libjava/configure.host. > > > > libjava will use -Bsymbolic on Linux, which is more aggresive than > > -Bsymbol-functions. > > libjava doesn't use -Bsymbolic for all of its libraries, just for > libgij, libjvm, and libawt. I'd use -Bsymbolic for libgcj as well, > but (because of copy relocs) we'd have to compile all gcj executables > -fpic. > > I presume your patch doesn't change this behaviour. I didn't realized that. I will update my patch to build libgcj with -Bsymbol-functions. You don't need to compile any gcj executables with -fpic. H.J.
Re: debugging capabilities on AIX ?
> Olivier Hainque writes: Olivier> Working on GCC 4 based GNAT port for AIX 5.[23], our testsuite to Olivier> evaluate GDB (6.4) debugging capabilities currently yields very Olivier> unpleasant results compared to what we obtain with a GCC 3.4 based Olivier> compiler (80+ extra failures out of 1800+ tests). Olivier> We so far presumed that this is caused by limitations in the Olivier> XCOFF/STABS debug info format more heavily exposed by the many great Olivier> compiler improvements between 3.4 and 4.x. Olivier> I'd appreciate feedback on general questions from these observations: Olivier> Is it generally known/expected that xcoff/stabs debugging capabilities Olivier> degrade when moving from 3.4 to 4.x ? Yes. I recompile files without optimization for debugging to disable the transformations that confuse debugging. Olivier> If yes, how is that considered by AIX GCC developers ? (how serious the Olivier> issue, is it fixable, are there plans/attempts to move to DWARF2, ...) The reaction varies with developer. AIX continues to use xcoff/stabs. The feedback of AIX users to IBM sales representatives and executives will determine the response. David
Re: error when porting from g++ for hp-ux to g++ for linux
"Puetz, Oliver P11M22" <[EMAIL PROTECTED]> writes:
> here's a little sample code, which could be compiled with g++ 3.01 under
> hp-ux, but when compiled with g++ 3.4.6 under linux, following error
> occured:
>
> sample.c: In member function 'T C2::PROC(T)':
> sample.c:19: error: 'c1i' was not declared in this scope
The question is not appropriate for the gcc@gcc.gnu.org mailing list.
It would be appropriate on the [EMAIL PROTECTED] mailing list.
The actual problem is happening because g++ 3.4.6 does a better job of
implementating the standard C++ language. You are falling afoul of
the two-phase lookup rule. The easiest fix is to change the line to
T PROC(T x) { this->c1i = c2i; };
Further questions on this topic should be taken to a C++ standard FAQ.
Ian
Re: Serious SPEC CPU 2006 FP performance regressions on IA32
On Thu, Jan 11, 2007 at 08:06:31PM -0500, Daniel Berlin wrote: > On 1/11/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote: > >Menezes, Evandro wrote: > >> Though not as pronounced, definitely significant. > >> > > > >Using binary search I've detected that 30% performance regression of > >cpu2006/437.leslie3d benchmark is caused by revision 117891. > > > >http://gcc.gnu.org/viewcvs?view=rev&revision=117891 > > > >I assume same commit causes regression of all other benchmarks from > >cpu2k6 suite (running others to confirm). > > This only affects 4.2, and the only solution would be to try to > backport some of the 4.3 aliasing stuff to 4.2, which i'm not sure is > a great idea. > If this serious performance in gcc 4.2 isn't addressed, it may make gcc 4.2 less attractive since it may generate much slower executables. H.J.
Re: bug management: WAITING bugs that have timed out
On Fri, Jan 12, 2007 at 12:41:08PM +0100, Eric Botcazou wrote: > > > Saddest is that is that in a batch of various related bug closings, the > > > blanket comment "M68k/ColdFire is not a primary platform - CLOSED". > > > > That should not happen, they should only get their target milestone > > bumped. I cannot remember having seen any case of a bug being _closed_ > > just because the platform is not a primary one. > > Neither can I. Whoever closed bugs because a platform was not primary was wrong.
GCC trunk revision 120704 failed to build spec cpu2k/gcc
Hi! GCC trunk revision 120704 failed to build SPEC cpu2000/gcc on -O1 and higher optimization level at x86_64-redhat-linux. reload1.c: In function 'reload': reload1.c:449: error: address taken, but ADDRESSABLE bit not set bad_spill_regs reload1.c:449: error: address taken, but ADDRESSABLE bit not set bad_spill_regs reload1.c:449: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Does anybody see the same? - Grigory
Re: GCC trunk revision 120704 failed to build spec cpu2k/gcc
On Fri, Jan 12, 2007 at 09:30:27PM +0300, Grigory Zagorodnev wrote: > Hi! > GCC trunk revision 120704 failed to build SPEC cpu2000/gcc on -O1 and > higher optimization level at x86_64-redhat-linux. > > reload1.c: In function 'reload': > reload1.c:449: error: address taken, but ADDRESSABLE bit not set > bad_spill_regs > > reload1.c:449: error: address taken, but ADDRESSABLE bit not set > bad_spill_regs > > reload1.c:449: internal compiler error: verify_stmts failed > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > > Does anybody see the same? Revision 120685 can compile gcc in SPEC CPU 2006. Grigory, can you back out revision 120695: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00970.html to see if it fixes the regression. H.J.
Re: PATCH: Build shared libraries with -Bsymbolic-functions
On Fri, Jan 12, 2007 at 06:38:56AM -0800, H. J. Lu wrote: > On Fri, Jan 12, 2007 at 08:57:42AM +0100, Paolo Bonzini wrote: > > > > >libjava will use -Bsymbolic on Linux, which is more aggresive than > > >-Bsymbol-functions. It will bind global data references locally in > > >additon to global function references. My patch will keep -Bsymbolic > > >for libjava if it is set by libjava/configure.host. > > > > > >Here is an updated patch. > > > > The configury logic is fine by me, but please wait for approval at least > > from the libjava and libstdc++ maintainers since I don't understand > > fully the consequences of the -Bsymbolic stuff. Could it be considered > > an ABI change, in that programs previously overriding some symbols will > > break? (Sorry if the question is dumb). > > My change should allow programs to override functions which are > overridable as specified in language standards. That is why I build > libstdc++.so with --dynamic-list-cpp-new so that programs can override > C++ operator new/delete. Programs depending on overriding function > symbols, which aren't overridable in language standards, are broken. > In theory, you can have a huge .o file containing all library > functions which aren't overridable in language standard. You > won't be able to override any of those functions when that .o file > is linked in statically. > > Since I used -Bsymbolic-functions, it has no effect on data symbols. > I extended -Bsymbolic-functions to libffi, libjava, libmudflap, libssp and libgcc. There are no regressions: http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00511.html http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00510.html http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00509.html If we apply -Bsymbolic-functions to all shared libraries on a system, it will improve application startup time and overall runtime performance. H.J. config/ 2007-01-12 H.J. Lu <[EMAIL PROTECTED]> * ld-symbolic.m4: New. libffi/ 2007-01-12 H.J. Lu <[EMAIL PROTECTED]> * Makefile.am (ACLOCAL_AMFLAGS): Add -I ../config. (libffi_la_LDFLAGS): Add $(extra_ldflags_libffi) * Makefile.in: Regenerated. * configure.ac: Use ACX_PROG_LD_GNU_SYMBOLIC. Set extra_ldflags_libffi to $SYMBOLIC_LDFLAGS. Substitute extra_ldflags_libffi. * configure: Regenerated. * aclocal.m4: Likewise. libgcc/ 2007-01-12 H.J. Lu <[EMAIL PROTECTED]> * Makefile.in (extra_ldflags_libgcc): New. (SHLIB_LINK): Add $(extra_ldflags_libgcc). * configure.ac: Include ../config/lib-ld.m4 and ../config/ld-symbolic.m4. Usde ACX_PROG_LD_GNU_SYMBOLIC. Set extra_ldflags_libgcc to $SYMBOLIC_LDFLAGS. Substitute extra_ldflags_libgcc. * configure: Regenerated. libgfortran/ 2007-01-12 H.J. Lu <[EMAIL PROTECTED]> * configure.ac: Use ACX_PROG_LD_GNU_SYMBOLIC. Set extra_ldflags_libgfortran to $SYMBOLIC_LDFLAGS if it isn't set. * configure: Regenerated. * aclocal.m4: Likewise. * Makefile.in: Likewise. libgomp/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * configure.ac: Use ACX_PROG_LD_GNU_SYMBOLIC. Add $SYMBOLIC_LDFLAGS to OPT_LDFLAGS. * configure: Regenerated. * aclocal.m4: Likewise. * Makefile.in: Likewise. libjava/ 2007-01-12 H.J. Lu <[EMAIL PROTECTED]> * Makefile.am (libgcj_la_LDFLAGS): Add $(LIBGCJ_LD_SYMBOLIC_FUNCTIONS). (libgcj_tools_la_LDFLAGS): Likewise. (libgcj_bc_la_LDFLAGS): Likewise. * Makefile.in: Regenerated. * configure.ac: Use ACX_PROG_LD_GNU_SYMBOLIC. Set LIBGCJ_LD_SYMBOLIC_FUNCTIONS to $SYMBOLIC_LDFLAGS. Set libgcj_ld_symbolic to $SYMBOLIC_LDFLAGS if it isn't set. Substitute LIBGCJ_LD_SYMBOLIC_FUNCTIONS. * configure: Regenerated. * aclocal.m4: Likewise. * gcj/Makefile.in: Likewise. * include/Makefile.in: Likewise. * testsuite/Makefile.in: Likewise. libmudflap/ 2007-01-12 H.J. Lu <[EMAIL PROTECTED]> * Makefile.am (libmudflap_la_LDFLAGS): Add $(extra_ldflags_libmudflap). (libmudflapth_la_LDFLAGS): Likewise. * Makefile.in: Regenerated. * configure.ac: Use ACX_PROG_LD_GNU_SYMBOLIC. Set extra_ldflags_libmudflap to $SYMBOLIC_LDFLAGS. Substitute extra_ldflags_libmudflap. * configure: Regenerated. * aclocal.m4: Likewise. libobjc/ 2007-01-12 H.J. Lu <[EMAIL PROTECTED]> * configure.ac: Use ACX_PROG_LD_GNU_SYMBOLIC. Set extra_ldflags_libobjc to $SYMBOLIC_LDFLAGS if it isn't set. * configure: Regenerated. * aclocal.m4: Likewise. libssp/ 2007-01-12 H.J. Lu <[EMAIL PROTECTED]> * Makefile.am (libssp_la_LDFLAGS): Add $(extra_ldflags_libssp). * Makefile.in: Regenerated. * configure.ac: Use ACX_PROG_LD_GNU_SYMBOLIC. Set extra_ldflags_libssp to $SYMBOLIC_
Re: Serious SPEC CPU 2006 FP performance regressions on IA32
On 1/12/07, H. J. Lu <[EMAIL PROTECTED]> wrote: On Thu, Jan 11, 2007 at 08:06:31PM -0500, Daniel Berlin wrote: > On 1/11/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote: > >Menezes, Evandro wrote: > >> Though not as pronounced, definitely significant. > >> > > > >Using binary search I've detected that 30% performance regression of > >cpu2006/437.leslie3d benchmark is caused by revision 117891. > > > >http://gcc.gnu.org/viewcvs?view=rev&revision=117891 > > > >I assume same commit causes regression of all other benchmarks from > >cpu2k6 suite (running others to confirm). > > This only affects 4.2, and the only solution would be to try to > backport some of the 4.3 aliasing stuff to 4.2, which i'm not sure is > a great idea. > If this serious performance in gcc 4.2 isn't addressed, it may make gcc 4.2 less attractive since it may generate much slower executables. I'm happy to backport it, but it's going to introduce other possible problems in 4.2. H.J.
Re: Mis-handled ColdFire submission?
On Jan 12, 2007, at 4:35 AM, Nathan Sidwell wrote: 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. Yeah, spending large amounts of time in stage2 and 3 does have disadvantages. I'd rather have people that have regressions spend a year at a time in stage2-3... :-( Maybe we should have trunk be stage1, and then snap over to a stage2 branch when the stage1 compiler is ready to begin stage2, and likewise, when the stage2 compiler is ready to go to stage3, it then snaps to the release branch. This gives a place for the preintegration of stage1 level work when ever that work is ready, without having to delay it for months at a time. Another possibility is to use the next unreleased major release branch as stage 2, and the current major release branch as essentially stage3, with trunk remaining stage1. Then the work doesn't need to wait for the right stage, rather, the work is Oked for the stage it is suitable for. I've not spent much time thinking about this, this is just off the cuff, but, I thought I would post it as 9 months in stage2-3 seems like a long time to me.
Re: debugging capabilities on AIX ?
On Jan 12, 2007, at 12:56 AM, Olivier Hainque wrote: Working on GCC 4 based GNAT port for AIX 5.[23], our testsuite to evaluate GDB (6.4) debugging capabilities currently yields very unpleasant results compared to what we obtain with a GCC 3.4 based compiler (80+ extra failures out of 1800+ tests). Could you please let us know if this is -O0 or not. For -O0, I'd like to think that the debugging experience shouldn't be worse. If it is at -O0, I'd encourage bug reports for all the problems.
Re: GCC trunk revision 120704 failed to build spec cpu2k/gcc
Hello, > > GCC trunk revision 120704 failed to build SPEC cpu2000/gcc on -O1 and > > higher optimization level at x86_64-redhat-linux. > > > > reload1.c: In function 'reload': > > reload1.c:449: error: address taken, but ADDRESSABLE bit not set > > bad_spill_regs > > > > reload1.c:449: error: address taken, but ADDRESSABLE bit not set > > bad_spill_regs > > > > reload1.c:449: internal compiler error: verify_stmts failed > > Please submit a full bug report, > > with preprocessed source if appropriate. > > See http://gcc.gnu.org/bugs.html> for instructions. > > > > Does anybody see the same? I can reproduce this on i686. I will check what the problem is, Zdenek
Re: bug management: WAITING bugs that have timed out
On Jan 11, 2007, at 10:47 PM, Joe Buck wrote: The description of WORKSFORME sounds closest: we don't know how to reproduce the bug. Should that be used? No, not generally. This should only be used if someone says, I compile foo on platform bar and it didn't build and then someone tries building foo on a bar and it does build for them. If the original didn't say which version of foo or bar or gcc they tested with, the person that gets a build out of it should report which version of foo and bar and gcc they used. Another case, is if someone says a virtual call doesn't work with no testcase, and if the tester tests the canonical virtual call test case and it works, then WORKSFORME seems reasonable. INVALID (we don't know that), A valid bug is one that is reproducible and shows a problem with conformance to a language standard, or a desired direction of the compiler. Everything that fails to meet that standard is invalid by this definition. Now, if the bug people wanted to add an insufficient state, that would be better. Around here, we use verify/insufficient information. The user can then respond, or, eventually if they don't it then goes to closed/insufficient information.
Re: Serious SPEC CPU 2006 FP performance regressions on IA32
On Fri, Jan 12, 2007 at 02:06:48PM -0500, Daniel Berlin wrote: > On 1/12/07, H. J. Lu <[EMAIL PROTECTED]> wrote: > >On Thu, Jan 11, 2007 at 08:06:31PM -0500, Daniel Berlin wrote: > >> On 1/11/07, Grigory Zagorodnev <[EMAIL PROTECTED]> > >wrote: > >> >Menezes, Evandro wrote: > >> >> Though not as pronounced, definitely significant. > >> >> > >> > > >> >Using binary search I've detected that 30% performance regression of > >> >cpu2006/437.leslie3d benchmark is caused by revision 117891. > >> > > >> >http://gcc.gnu.org/viewcvs?view=rev&revision=117891 > >> > > >> >I assume same commit causes regression of all other benchmarks from > >> >cpu2k6 suite (running others to confirm). > >> > >> This only affects 4.2, and the only solution would be to try to > >> backport some of the 4.3 aliasing stuff to 4.2, which i'm not sure is > >> a great idea. > >> > > > >If this serious performance in gcc 4.2 isn't addressed, it may > >make gcc 4.2 less attractive since it may generate much slower > >executables. > > I'm happy to backport it, but it's going to introduce other possible > problems in 4.2. > It isn't my call. Mark, can you comment on this? Thanks. H.J.
Re: GCC trunk revision 120704 failed to build spec cpu2k/gcc
Hello, > > > GCC trunk revision 120704 failed to build SPEC cpu2000/gcc on -O1 and > > > higher optimization level at x86_64-redhat-linux. > > > > > > reload1.c: In function 'reload': > > > reload1.c:449: error: address taken, but ADDRESSABLE bit not set > > > bad_spill_regs > > > > > > reload1.c:449: error: address taken, but ADDRESSABLE bit not set > > > bad_spill_regs > > > > > > reload1.c:449: internal compiler error: verify_stmts failed > > > Please submit a full bug report, > > > with preprocessed source if appropriate. > > > See http://gcc.gnu.org/bugs.html> for instructions. > > > > > > Does anybody see the same? > > I can reproduce this on i686. I will check what the problem is, this is probably due to some of the recent IPA changes. ipa-reference.c:analyze_function does not traverse phi nodes, and thus misses that the address of bad_spill_regs is taken inside the phi node (and clears the addressable flag from it, causing an ICE later). I am working on the patch. Zdenek
RE: RFC: Add BID as a configure time option for DFP
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of H. > J. Lu > Sent: Wednesday, January 10, 2007 5:35 PM > To: Janis Johnson > Cc: gcc@gcc.gnu.org; [EMAIL PROTECTED]; Menezes, Evandro; > [EMAIL PROTECTED] > Subject: Re: RFC: Add BID as a configure time option for DFP > > On Wed, Jan 10, 2007 at 02:10:58PM -0800, Janis Johnson wrote: > > On Wed, Jan 10, 2007 at 11:40:46AM -0800, H. J. Lu wrote: > > > Both AMD and Intel like to have BID as a configure time option > > > for DFP. Intel is planning to contribute a complete BID runtime > > > library, which can be used by executables generate by gcc. > > > > > > As the first step, we'd like to contribute a BID<->DPD library so that > > > BID can be used with libdecnumber by executables generate by gcc > > > before the complete BID runtime library is ready. > > > > > > Any comments? > > > > libdecnumber doesn't use DPD (densely packed decimal), it uses the > > decNumber format. Functions in libgcc convert from DPD to decNumber, > > call into libdecnumber to do computations, and then convert the result > > back to DPD. It's all parameterized in dfp-bit.[ch], so replacing > > conversions between decNumber structs and DPD with conversions between > > decNumber structs and BID (binary integer decimal) should be > > straightforward; I don't think there's any need to convert between BID > > and DPD to use libdecnumber. > > libdecnumber is used by both gcc and DFP executables. We only want > to use BID for DFP executables. That means we will need BID<->decNumber > for gcc to generate DFP executables which use the BID library. > > Since the real BID library won't be ready for a while and in the > meantime, we like to enable BID for gcc now, that is why we > propose the BID<->DPD<->libdecnumber approach as a stopgap > measure. We can plug in the real BID library later. > > > > > If all x86* targets will use BID then there's no need for a configure > > option. Initial support using DPD for x86* was a proof of concept, I > > doubt that anyone would care if you replace it with BID support. > > Glad to hear that. We can make it BID only for x86. I've been looking into doing this, and now have some time cleared up on my schedule that I can look at implementing it. What I would like to do is: 1) Update --enable-decimal-float to take an option of which format to use 2) Set the defaults for x86_64/i386 to use BID 3) Add converter functions to libdecnumber that convert from/to BID to the internal libdecnumber format. 4) I'm of two minds what to call the functions. On one hand, it is convenient to use the same names for the functions, but over the years, I have seen many problems from using the same names for things that take different formatted inputs, so I will likely make using BID functions use different names. This will also allow us to generate testing compilers that use that alternate format. 5) Hopefully the Intel library will use the same names as the BID functions in libdecnumber, so that it can be linked in. We obviously need names for each of the standard math support functions (ie, add/sub/mul/div for _Decimal32/_Decimal64/_Decimal128 types). 6) Add a macro to libdec.h that says which format is being used. -- Michael Meissner AMD, MS 83-29 90 Central Street Boxborough, MA 01719
gcc-4.3-20070112 is now available
Snapshot gcc-4.3-20070112 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070112/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 120735 You'll find: gcc-4.3-20070112.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070112.tar.bz2 C front end and core compiler gcc-ada-4.3-20070112.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070112.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070112.tar.bz2 C++ front end and runtime gcc-java-4.3-20070112.tar.bz2 Java front end and runtime gcc-objc-4.3-20070112.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070112.tar.bz2The GCC testsuite Diffs from 4.3-20070105 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
RE: Autoconf manual's coverage of signed integer overflow & portability
> -Original Message- > I would like to say the one thing I have not heard through this > discussion is the real reason why the C standards comittee decided > signed overflow as being undefined. All I can think of is they were > thinking of target that do saturation for plus/minus but wrapping for > multiplications/divide or even targets that trap for some overflow cases > (like x86) but not others. I was on the original C standards committee from its inception through the ANSI standard in 1989 and the ISO standard in 1990, representing first Data General, and then the Open Software Foundation. When the standard was being produced, we had vendors with one's complement machines (Univac, and possibly CDC), signed magnitude machines (Burroughs), word based machines (Univac, Burroughs, Data General, PR1ME, and a university doing a DEC-10 port). While these machines are uncommon now, we did have to keep them in mind while writing the standard. Because of the diversity of actual hardware, the only thing we could say was "don't do that", just like with shifts where the shift value is not in the proper range (and this bit gcc when I was doing the early 88k port).
Re: GCC trunk revision 120704 failed to build spec cpu2k/gcc
> Hello, > > > > > GCC trunk revision 120704 failed to build SPEC cpu2000/gcc on -O1 and > > > > higher optimization level at x86_64-redhat-linux. > > > > > > > > reload1.c: In function 'reload': > > > > reload1.c:449: error: address taken, but ADDRESSABLE bit not set > > > > bad_spill_regs > > > > > > > > reload1.c:449: error: address taken, but ADDRESSABLE bit not set > > > > bad_spill_regs > > > > > > > > reload1.c:449: internal compiler error: verify_stmts failed > > > > Please submit a full bug report, > > > > with preprocessed source if appropriate. > > > > See http://gcc.gnu.org/bugs.html> for instructions. > > > > > > > > Does anybody see the same? > > > > I can reproduce this on i686. I will check what the problem is, > > this is probably due to some of the recent IPA changes. > ipa-reference.c:analyze_function does not traverse phi nodes, > and thus misses that the address of bad_spill_regs is taken inside the > phi node (and clears the addressable flag from it, causing an ICE > later). I am working on the patch. Thanks for looking into that. THe problem seems to be that ipa-reference and early optimization was more or less tested each independently, so I never noticed this problem (it does not reproduce on IPA branch that has both changes in however). Proper fix is probably to make ipa-reference and symmetrically also the other IPA pass use PHI operands infrastructure as suggested by comments earlier. Honza > > Zdenek
Running GCC tests on installed compiler
Can someone one with some deja-knowledge help me figure out how to run the GCC tests on an installed compiler and without having to do a GCC build? I started with runtest -tool gcc --srcdir /proj/opensrc/nightly/src/trunk/gcc/testsuite and that ran the tests, but it ran them with whatever gcc command it found in PATH. I tried setting and exporting CC before running runtest and putting "CC=" on the runtest command line but neither of those methods seemed to affect what gcc was run by runtest. So then I tried to create a site.exp file and use that on the command line, in site.exp I put: set CC "/proj/opensrc/be/ia64-hp-hpux11.23/bin/gcc" set srcdir "/proj/opensrc/nightly/src/trunk/gcc/testsuite" I also tried using the site.exp file that I got from building GCC and various combinations of the two but all these attempts ended with no tests runs and the following lines in my log file: Running target unix Using /proj/opensrc/be/ia64-debian-linux-gnu/share/dejagnu/baseboards/unix.exp as board description file for target. Using /proj/opensrc/be/ia64-debian-linux-gnu/share/dejagnu/config/unix.exp as generic interface file for target. WARNING: Couldn't find tool config file for unix, using default. When testing my just built GCC I was seeing: Running target unix Using /proj/opensrc/be/ia64-debian-linux-gnu/share/dejagnu/baseboards/unix.exp as board description file for target. Using /proj/opensrc/be/ia64-debian-linux-gnu/share/dejagnu/config/unix.exp as generic interface file for target. Using /proj/opensrc/nightly/src/trunk/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /proj/opensrc/nightly/src/trunk/gcc/testsuite/gcc.c-torture/compile/compile.exp ... The built GCC seems to be picking up an extra .exp file (default.exp) but I am not sure why or how to fix it so that my non-built compiler runs the same way. Can someone help me out here? Steve Ellcey [EMAIL PROTECTED]
Re: Running GCC tests on installed compiler
On Jan 12, 2007, at 3:55 PM, Steve Ellcey wrote:
Can someone one with some deja-knowledge help me figure out how to run
the GCC tests on an installed compiler and without having to do a GCC
build?
You must be new around here:
http://gcc.gnu.org/ml/gcc-announce/1997-1998/msg0.html
:-) Which is the I feel lucky google("site:gcc.gnu.org how to run
installed GCC_UNDER_TEST") result.
Invariant division
Hi Does gcc do an divison by constant optimization for any 16 bit architecture. Can anyone point me to where it does that ? thanks dz
Re: Running GCC tests on installed compiler
On Fri, Jan 12, 2007 at 06:05:49PM -0800, Mike Stump wrote:
> On Jan 12, 2007, at 3:55 PM, Steve Ellcey wrote:
> >Can someone one with some deja-knowledge help me figure out how to run
> >the GCC tests on an installed compiler and without having to do a GCC
> >build?
>
> You must be new around here:
>
> http://gcc.gnu.org/ml/gcc-announce/1997-1998/msg0.html
>
> :-) Which is the I feel lucky google("site:gcc.gnu.org how to run
> installed GCC_UNDER_TEST") result.
For the less old-school inclined, try contrib/test_installed.
--
Daniel Jacobowitz
CodeSourcery
Re: debugging capabilities on AIX ?
> On Jan 12, 2007, at 12:56 AM, Olivier Hainque wrote: > >Working on GCC 4 based GNAT port for AIX 5.[23], our testsuite to > >evaluate GDB (6.4) debugging capabilities currently yields very > >unpleasant results compared to what we obtain with a GCC 3.4 based > >compiler (80+ extra failures out of 1800+ tests). > > Could you please let us know if this is -O0 or not. For -O0, I'd > like to think that the debugging experience shouldn't be worse. If > it is at -O0, I'd encourage bug reports for all the problems. It is indeed at -O0 (for probably 99% of our testcases). -- Joel
RFC: Walways-true considered harmful
The option Walways-true is described as: Warn about comparisons which are always true such as testing if unsigned values are greater than or equal to zero. This warning is enabled by -Wall. In the description of warnings emitted by -Wextra we can find: An unsigned value is compared against zero with < or >=. GCC also emits an unconditional and unnamed warning that says: "comparison is always true/false due to limited range of data type" In this mail I will argue AGAINST adding the two latter warnings to Walways-true. The origins of Walways-true can be traced to a mail from Andrew Morton [1]. Kernel devs hit a bug where a function's name has been used in a test instead of actually calling the function. C++ front-end had a warning for this with the following message "the address of `function', will always be `true'". The warning was added to the C front-end without an option to control it [2]. Much later, the warning was given a name, Walways-true [3], since the warning message said explicitly that something will always be true. However, Andrew Morton didn't want to get a warning just because the expression was always true. He wanted to be warned of using the address of a function where it makes more sense to call the function. This seems also to be the original intent of the warning in the C++ front-end, as evidenced by the comment that accompanied it: /* Common Ada/Pascal programmer's mistake. We always warn about this since it is so bad. */ The common mistake is that in Ada/Pascal you can call a function just by using its name (without parenthesis), while in C/C++ the name of a function is its address. Yes, "if (func)" is always true and "if (func == NULL)" is always false but that is not why Andrew Morton wants to get the warning. Simply because a warning indicates that something is bad coding, we should not put it under -Wbad-code. Not understanding what GCC users really want [*] has led to the current situation. The present. We want to give a name to the warnings above. From its description, Walways-true, which seems to be useful for kernel devs and it is enabled by -Wall, seems appropriate. On the other hand, the -Wextra warning is in -Wextra for a reason: it is hard to avoid for macros and templates. Moreover, it is one of the reasons why the kernel is not built with -Wextra [4]. The other warning is equally hard to avoid for macros and templates. We have two bug reports about this [5][6]. Enabling those warnings with -Wall doesn't seem to me to be a good idea. But, for the reasons exposed above, moving Walways-true to Wextra and adding the warnings to it would also be a mistake from my point of view. Instead, I grouped both unnamed warnings under a different new option, Wcomparison-fixed, which is only enabled by Wextra. The patch is available at http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01120.html Sincerely, Manuel. [*] I don't say it is easy and I don't say I am right. I haven't spoken with Andrew. Perhaps we should simply ask in linux-kernel. I am just trying to raise awareness about a potential problem. The lazy and easy way would be for me to add the warnings to Walways-true and get the patch accepted. [1] http://gcc.gnu.org/ml/gcc/2003-10/msg00414.html [2] http://gcc.gnu.org/ml/gcc/2003-10/msg00419.html [3] http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00972.html [4] http://lkml.org/lkml/2006/11/28/206 [5] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963 [6] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
Re: RFC: Wextra digest (fixing PR7651)
On 11 Jan 2007 17:29:10 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> On 11 Jan 2007 15:48:36 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> > > * A function can return either with or without a value.
> >
> > I give up.
>
> :-) None said it was going to be easy. We have a warning similar to this:
>
> -Wreturn-type
>warn about any "return" statement with no return-value in a
> function whose return-type is not "void".
>
> However, this is enabled by Wall and the one from Wextra surely
> produces false positives (I guess that is the reason it is in Wextra).
> -Wreturn-type-may ?
I tend to think that having some returns with a value and some without
is an error. Maybe grouping them in -Wreturn-type makes sense,
although the name is not quite right.
Behold! The example in the manual is:
foo (a)
{
if (a > 0)
return a;
}
But actually this doesn't fly: there is no special warning with
-Wextra, and -Wreturn-type says "control reaches end of non-void
function"
So I tried another testcase from the testsuite of Wextra:
int bar (void)
{
if( i ) return;
elsereturn 1;
} /* { dg-warning "may return with or without a value" } */
But this is warned already by Wreturn-type: "'return' with no value,
in function returning non-void".
I wasn't able to come up with a testcase that is warned by Wextra but
not by Wreturn-type.
I vote for removal if nobody can come up with a testcase.
> > > * An unsigned value is compared against zero with < or >=.
> > > Walways-true claims to warn for this but it doesn't. There is also an
> > > unconditional warning for expressions that are always true or false
> > > due to the range of types.
> >
> > -Walways-true should warn for this.
>
> No, I think it shouldn't but let's leave this for now, please. I need
> to do a bit more of research and archive archaeology to properly
> justify why I think that this is a Really Bad Idea (TM). Or we could
> just drop the idea @ kernel.org and see what happens. Any brave
> volunteer?
-Wunsigned-compare?
See http://gcc.gnu.org/ml/gcc/2007-01/msg00480.html for why not Walways-true.
We have another warning for comparisons that are always true due to
the range of data types. We even have a PR about this inconsistency.
(see PR23587). Thus, Wunsigned-compare is not an apt name.
Joseph Myers proposed Wcomparison-fixed a very long time ago, so I
made a patch for it
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01120.html but I need
help to come up with portable testcases.
Thanks.
Manuel.
Re: Invariant division
"drizzle drizzle" <[EMAIL PROTECTED]> writes: > Does gcc do an divison by constant optimization for any 16 bit > architecture. Can anyone point me to where it does that ? expand_divmod in expmed.c. Ian
Re: Running GCC tests on installed compiler
On Fri, Jan 12, 2007 at 09:17:07PM -0500, Daniel Jacobowitz wrote:
> On Fri, Jan 12, 2007 at 06:05:49PM -0800, Mike Stump wrote:
> > On Jan 12, 2007, at 3:55 PM, Steve Ellcey wrote:
> > >Can someone one with some deja-knowledge help me figure out how to run
> > >the GCC tests on an installed compiler and without having to do a GCC
> > >build?
> >
> > You must be new around here:
> >
> > http://gcc.gnu.org/ml/gcc-announce/1997-1998/msg0.html
> >
> > :-) Which is the I feel lucky google("site:gcc.gnu.org how to run
> > installed GCC_UNDER_TEST") result.
>
> For the less old-school inclined, try contrib/test_installed.
This kind of thing reveals a problem with using Google for help with free
software. Often the top link points to a sometimes-hairy procedure that
represents the first successful solution to a problem, while the later
work by upstream and the distros to find much similar solutions ends up
with much later Google rank. That's because everyone links to the first
solution, and those links persist.
BTW, anyone who does use the message Mike linked to, please read it
carefully and don't just cut-and-paste the first set of commands, or
your report will claim to be from hppa1.1-hp-hpux10.20, regardles of what
they really run.
So please use contrib/test_installed !
