Re: Can't build gcc version 4.2.0 20060311 (experimental) on sparc/sparc64 linux
oops, this went to gcc-patches, should have gone here... On 3/23/06, Christian Joensson <[EMAIL PROTECTED]> wrote: > This was on > > Aurora SPARC Linux release 2.0b2 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u: > > binutils-2.15.92.0.2-5.sparc > bison-2.1-1.1.sparc > dejagnu-1.4.4-2.noarch > expect-5.43.0-2.1.sparc > gcc-3.4.2-6.fc3.sparc > package gcc4 is not installed > glibc-2.3.3-99.sparcv9 > glibc-2.3.3-99.sparc64 > glibc-devel-2.3.3-99.sparc > glibc-devel-2.3.3-99.sparc64 > glibc-headers-2.3.3-99.sparc > glibc-kernheaders-2.6-20sparc.sparc > gmp-4.1.4-3sparc.sparc > gmp-4.1.4-3sparc.sparc64 > gmp-devel-4.1.4-3sparc.sparc > gmp-devel-4.1.4-3sparc.sparc64 > kernel-2.6.13-1.1603sp11.sparc64 > package kernel-devel is not installed > package kernel-smp is not installed > libgcc-3.4.2-6.fc3.sparc > libgcc-3.4.2-6.fc3.sparc64 > libstdc++-3.4.2-6.fc3.sparc > libstdc++-3.4.2-6.fc3.sparc64 > libstdc++-devel-3.4.2-6.fc3.sparc > libstdc++-devel-3.4.2-6.fc3.sparc64 > make-3.80-5.sparc > nptl-devel-2.3.3-99.sparcv9 > tcl-8.4.11-1.1.sparc > > and configures like this: > > ./gcc/xgcc -v > Using built-in specs. > Target: sparc64-unknown-linux-gnu > Configured with: ../gcc/configure --enable-__cxa_atexit > --enable-shared --with-cpu=v7 > --enable-languages=c,ada,c++,fortran,java,objc,obj-c++,treelang > Thread model: posix > gcc version 4.2.0 20060311 (experimental) > > taken from the 4.2 snapshot > > /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 -DHAVE_CONFIG_H -I. > -I../../../../gcc/libgomp -I. > -I../../../../gcc/libgomp/config/linux/sparc > -I../../../../gcc/libgomp/config/linux > -I../../../../gcc/libgomp/config/posix -I../../../../gcc/libgomp -Wall > -Werror -pthread -ftls-model=initial-exec -O2 -g -O2 -m64 -MT > fortran.lo -MD -MP -MF .deps/fortran.Tpo -c > ../../../../gcc/libgomp/fortran.c -o fortran.o >/dev/null 2>&1 > /bin/sh ./libtool --mode=link /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 -Wall -Werror > -ftls-model=initial-exec -Wc,-pthread -O2 -g -O2 -m64 > -Wl,-z,nodlopen -Wl,-O1 -m64 -o libgomp.la -rpath > /usr/local/lib/../lib64 -version-info 1:0:0 > -Wl,--version-script,../../../../gcc/libgomp/libgomp.map alloc.lo > barrier.lo critical.lo env.lo error.lo iter.lo loop.lo ordered.lo > parallel.lo sections.lo single.lo team.lo work.lo lock.lo mutex.lo > proc.lo sem.lo bar.lo time.lo fortran.lo -lrt > /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 -m64 -shared > .libs/alloc.o .libs/barrier.o .libs/critical.o .libs/env.o > .libs/error.o .libs/iter.o .libs/loop.o .libs/ordered.o > .libs/parallel.o .libs/sections.o .libs/single.o .libs/team.o > .libs/work.o .libs/lock.o .libs/mutex.o .libs/proc.o .libs/sem.o > .libs/bar.o .libs/time.o .libs/fortran.o -lrt -pthread -Wl,-z > -Wl,nodlopen -Wl,-O1 -Wl,--version-script > -Wl,../../../../gcc/libgomp/libgomp.map -Wl,-soname -Wl,libgomp.so.1 > -o .libs/libgomp.so.1.0.0 > /usr/bin/ld: .libs/barrier.o: check_relocs: unhandled reloc type 0 > .libs/barrier.o: could not read symbols: File format not recognized > collect2: ld returned 1 exit status > > The problem is this: > > file .libs/barrier.o > .libs/barrier.o: ELF 32-bit MSB relocatable, SPARC32PLUS, V8+ > Required, version 1 (SYSV), not stripped > > shouldn't this be ELF 32-bit MSB executable, SPARC, version 1 (SYSV)? > > -- > Cheers, > > /ChJ > -- Cheers, /ChJ
Re: Can't build gcc version 4.2.0 20060311 (experimental) on sparc/sparc64 linux
On 3/23/06, David S. Miller <[EMAIL PROTECTED]> wrote: > From: "Christian Joensson" <[EMAIL PROTECTED]> > Date: Thu, 23 Mar 2006 09:05:54 +0100 > > > The problem is this: > > > > file .libs/barrier.o > > .libs/barrier.o: ELF 32-bit MSB relocatable, SPARC32PLUS, V8+ > > Required, version 1 (SYSV), not stripped > > > > shouldn't this be ELF 32-bit MSB executable, SPARC, version 1 (SYSV)? > > Not if .libc/barrier.o was build -fPIC or -fpic, which it seems > as if it was. sorry, I should have written "shouldn't this be ELF 32-bit MSB relocatable, SPARC, version 1 (SYSV)?"... -- Cheers, /ChJ
Re: Can't build gcc version 4.2.0 20060311 (experimental) on sparc/sparc64 linux
From: "Christian Joensson" <[EMAIL PROTECTED]> Date: Thu, 23 Mar 2006 09:25:43 +0100 > On 3/23/06, David S. Miller <[EMAIL PROTECTED]> wrote: > > From: "Christian Joensson" <[EMAIL PROTECTED]> > > Date: Thu, 23 Mar 2006 09:05:54 +0100 > > > > > The problem is this: > > > > > > file .libs/barrier.o > > > .libs/barrier.o: ELF 32-bit MSB relocatable, SPARC32PLUS, V8+ > > > Required, version 1 (SYSV), not stripped > > > > > > shouldn't this be ELF 32-bit MSB executable, SPARC, version 1 (SYSV)? > > > > Not if .libc/barrier.o was build -fPIC or -fpic, which it seems > > as if it was. > > sorry, I should have written "shouldn't this be ELF 32-bit MSB > relocatable, SPARC, version 1 (SYSV)?"... Your gcc is building v8plus binaries by default aparently. Is the "SPARC32PLUS, V8+ Required" the part you're concerned about? That's completely normal and won't have any influence on relocations. Why not disassemble .libs/barrier.o and see what relocation in there binutils is choking on? It might shed some light.
Re: Ada subtypes and base types
On Tuesday 21 March 2006 21:59, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
>
> > Hi Jeff, on the subject of seeing through typecasts, I was playing around
> > with VRP and noticed that the following "if" statement is not eliminated:
> >
> > int u (unsigned char c) {
> > int i = c;
> >
> > if (i < 0 || i > 255)
> > return -1; /* never taken */
> > else
> > return 0;
> > }
> >
> > Is it supposed to be?
> Fixed thusly. Bootstrapped and regression tested on i686-pc-linux-gnu.
Hi Jeff, this seems to work nicely - thanks again. I still see a bunch
of suboptimal range calculations in the Ada code I'm looking at, but these
now just coming from having everything initialised to VR_VARYING rather than
[TYPE_MIN, TYPE_MAX]. Do you know of any way of getting variables with
non-trivial TYPE_MIN/TYPE_MAX values in C? I ask because I'd rather produce
test cases in C than Ada, since everyone has access to a C compiler :)
All the best,
Duncan.
Re: Ada subtypes and base types
> Hi Jeff, this seems to work nicely - thanks again. Well, this has introduced 3 regressions in the ACATS testsuite on x86/x86-64. -- Eric Botcazou
Re: Ada subtypes and base types
On Thursday 23 March 2006 11:31, Eric Botcazou wrote: > > Hi Jeff, this seems to work nicely - thanks again. > > Well, this has introduced 3 regressions in the ACATS testsuite on x86/x86-64. Which ones? Ciao, Duncan.
Re: Ada subtypes and base types
> Which ones? PR tree-optimization/26797. -- Eric Botcazou
"--param max-cselib-memory-location[s]" misspelled in GCC manual
Hi, I think the optimization parameter "max-cselib-memory-location" documented in the section 3.10 should be called "max-cselib-memory-locations". (The last 's' is missing.) Bye, Philipp Claßen
Re: Ada subtypes and base types
On Thu, 2006-03-23 at 10:40 +0100, Duncan Sands wrote:
> Hi Jeff, this seems to work nicely - thanks again. I still see a bunch
> of suboptimal range calculations in the Ada code I'm looking at, but these
> now just coming from having everything initialised to VR_VARYING rather than
> [TYPE_MIN, TYPE_MAX]. Do you know of any way of getting variables with
> non-trivial TYPE_MIN/TYPE_MAX values in C? I ask because I'd rather produce
> test cases in C than Ada, since everyone has access to a C compiler :)
You can't -- min/max will be extended to cover the type's precision,
even for enumerated types.
enum x
{
RED == 0,
GREEN = 1,
BLUE = 2,
PURPLE = 3,
}
for (color = RED, color <= PURPLE; color++)
{
...
}
Note carefully that for the loop test to terminate that color
will have the value PURPLE+1 (4). If the type min/max were set to
0, 3 respectively then the loop exit test would be optimized away...
Jeff
Re: Ada subtypes and base types
On 3/23/06, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-03-23 at 10:40 +0100, Duncan Sands wrote:
> > Hi Jeff, this seems to work nicely - thanks again. I still see a bunch
> > of suboptimal range calculations in the Ada code I'm looking at, but these
> > now just coming from having everything initialised to VR_VARYING rather than
> > [TYPE_MIN, TYPE_MAX]. Do you know of any way of getting variables with
> > non-trivial TYPE_MIN/TYPE_MAX values in C? I ask because I'd rather produce
> > test cases in C than Ada, since everyone has access to a C compiler :)
> You can't -- min/max will be extended to cover the type's precision,
> even for enumerated types.
>
> enum x
> {
> RED == 0,
> GREEN = 1,
> BLUE = 2,
> PURPLE = 3,
> }
>
> for (color = RED, color <= PURPLE; color++)
> {
>...
> }
>
> Note carefully that for the loop test to terminate that color
> will have the value PURPLE+1 (4). If the type min/max were set to
> 0, 3 respectively then the loop exit test would be optimized away...
Well - we could hack a new type attribute to specify min/max values...
Richard.
Re: Ada subtypes and base types
On Mar 23, 2006, at 11:10 AM, Richard Guenther wrote: Well - we could hack a new type attribute to specify min/max values... Or maybe try to using C++ instead since C++ rules for enums are different than C :). -- Pinski
Cross Compiling Ada to Netware using GNAT
Been so far unsuccessful in doing this, was hoping someone could help. I tried to emulate our current cross compile method (C to NLM) for Ada but something doesn't seem to be working. Currently, we cross compile our C programs using gcc and link everything into an elf32-i386 object file. Then, we use nlmconv to convert this into an NLM. We figured we could link the object file that gnatmake generates together with libgnat.a and libgcc_eh.a then use nlmconv. However, nlmconv errors out with an 'invalid operation' and lists missing symbols related to C, this seems to be from using the wrong header files (using the Linux headers, not the Netware ones), so we're missing 'stdout and stdin' among others. Netware, of course, won't run the generated NLM if we don't link the archives and have 'missing symbols'. I know more specific information would be helpful but I don't want to spam the list if someone has already solved this problem and can offer suggestions on how to cross compile Ada to run on Netware. It seems like all the tools are in place, if I could figure out exactly how to use them. Thanks in advance for any advice/suggestions/solutions.
Re: Ada subtypes and base types
On Thursday 23 March 2006 17:14, Andrew Pinski wrote: > > On Mar 23, 2006, at 11:10 AM, Richard Guenther wrote: > > > > > > Well - we could hack a new type attribute to specify min/max values... > > Or maybe try to using C++ instead since C++ rules for enums are > different > than C :). Well, I like the attribute idea since it gives much more flexibility in making examples. Also, though I guess this only matters to me, in order to produce C++ examples I'd have to build the compiler with C++ support, which I'd rather not do since I have no use for C++ otherwise. Ciao, Duncan.
Working with c
Hello, my name is Laura and I need to know where I could find or download the oldest version of de "C" compiler. I look forward to hearing from you. -- Departamento de Computaciòn Universidad Nacional de Río Cuarto -Córdoba - Argentina
RE: sibcall, sibcall_pop, sibcall_value and sibcall_pop_value named patterns not documented
On 21 March 2006 20:21, Dave Korn wrote: > At least as far as I have been able to find, there's no mention of these > anywhere in any version of the internals manual. > Since I have only deduced the existence of these patterns from stumbling > across HAVE_sibcall etc. in calls.c, I won't immediately volunteer to write > the doco patch. Shall I file a bugzilla, or is there some documentation > about the sibcall patterns somewhere that I missed? Since nobody's gotten back to me with a "It's over >>> thataway ya great eejit" kinda message, I've now filed http://gcc.gnu.org/PR26831. cheers, DaveK -- Can't think of a witty .sigline today
gcc-4.0-20060323 is now available
Snapshot gcc-4.0-20060323 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060323/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 112336 You'll find: gcc-4.0-20060323.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20060323.tar.bz2 C front end and core compiler gcc-ada-4.0-20060323.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20060323.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20060323.tar.bz2 C++ front end and runtime gcc-java-4.0-20060323.tar.bz2 Java front end and runtime gcc-objc-4.0-20060323.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20060323.tar.bz2The GCC testsuite Diffs from 4.0-20060316 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 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.
LLVM copyright?
Chris -- As I just sent in my Gelato abstract (at which you and I will be presenting talks about different approaches to link-time optimization in GCC), I was wondering what the status of the LLVM copyright assignment is. Has there been progress on that front? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: LLVM copyright?
On Mar 23, 2006, at 3:53 PM, Mark Mitchell wrote: As I just sent in my Gelato abstract Oh right, I have to do that too! :) (at which you and I will be presenting talks about different approaches to link-time optimization in GCC), I was wondering what the status of the LLVM copyright assignment is. Has there been progress on that front? There has been some progress: apparently forms have been sent out, but I haven't seen them yet. I've been distracted by too many things, and need to follow up. Thanks for the reminder! -Chris
