Re: Difficulties compiling under Irix...
On 7/20/07, Philippe Schaffnit <[EMAIL PROTECTED]> wrote: I guess this is more likely to be a general 'Gcc' thing rather than GFortran, but I guess you can put me on the right track... I think so too (crossposting to the gcc list). Lately my builds under Irix have been failing with: rm -f stage_current make[3]: Leaving directory `/USER/philippe/Irix/Compilation/Gcc' Comparing stages 2 and 3 warning: ./cc1-checksum.o differs Bootstrap comparison failure! ./fortran/trans-array.o differs ./build/genattrtab.o differs ./omega.o differs ./tree-cfg.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/USER/philippe/Irix/Compilation/Gcc' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/USER/philippe/Irix/Compilation/Gcc' make: *** [bootstrap] Error 2 Do anyone recognise that as something specific? Should I file a bug? I didn't find anything like that in bugzilla, so I think a bug report is in order (I assume you have tested with a clean checkout etc. to make sure it's not due to some old junk lying around). Or start looking to pinpoint the culprit commit? Given that so few (any?) developers use irix, I think finding the offending commit is your only hope if you want this fixed in a timely manner. -- Janne Blomqvist
Re: Difficulties compiling under Irix...
Hi! Yes, I have cleaned-up my sources and all that. Thanks a lot for your reply! I have start to look for the first revision to fail... Philippe Janne Blomqvist wrote: > > On 7/20/07, Philippe Schaffnit <[EMAIL PROTECTED]> wrote: > > I guess this is more likely to be a general 'Gcc' thing rather than > > GFortran, but I guess you can put me on the right track... > > I think so too (crossposting to the gcc list). > > > Lately my builds under Irix have been failing with: > > > > rm -f stage_current > > make[3]: Leaving directory `/USER/philippe/Irix/Compilation/Gcc' > > Comparing stages 2 and 3 > > warning: ./cc1-checksum.o differs > > Bootstrap comparison failure! > > ./fortran/trans-array.o differs > > ./build/genattrtab.o differs > > ./omega.o differs > > ./tree-cfg.o differs > > make[2]: *** [compare] Error 1 > > make[2]: Leaving directory `/USER/philippe/Irix/Compilation/Gcc' > > make[1]: *** [stage3-bubble] Error 2 > > make[1]: Leaving directory `/USER/philippe/Irix/Compilation/Gcc' > > make: *** [bootstrap] Error 2 > > > > Do anyone recognise that as something specific? Should I file a bug? > > I didn't find anything like that in bugzilla, so I think a bug report > is in order (I assume you have tested with a clean checkout etc. to > make sure it's not due to some old junk lying around). > > > Or > > start looking to pinpoint the culprit commit? > > Given that so few (any?) developers use irix, I think finding the > offending commit is your only hope if you want this fixed in a timely > manner. > > -- > Janne Blomqvist
Re: Installing gcc-3.2
On Fri, 2007-07-20 at 11:35 +0530, Venkatesan Jeevanandam wrote: > I am getting the below error message while compiling, can u please help me. > Is there any problem with gcc in backward compatibility? There are no guarantees about compiling old GCC releases with a more modern version of GCC. After all, we were not able to test this combination when GCC 3.2 was released. If you run into problems like this there are a few options: * try and fix the problems yourself so that you can get through the build * use a less modern version of GCC, like 3.4, and see if that works * if all else fails, you might have to find another system that has gcc <= 3.2 to build 3.2. > This message (including attachment if any) is confidential and may be > privileged. Please do not post messages to a public mailing list if they are confidential. We have a policy about such things: http://gcc.gnu.org/lists.html#policies Thanks, -- Ben Elliston <[EMAIL PROTECTED]> Australia Development Lab, IBM
Re: Difficulties compiling under Irix...
Philippe Schaffnit <[EMAIL PROTECTED]> writes: > Yes, I have cleaned-up my sources and all that. > > Thanks a lot for your reply! I have start to look for the first revision > to fail... MIPS is known to be broken at the moment because of: http://gcc.gnu.org/ml/gcc/2007-07/msg00357.html This is likely a manifestation of the same problem (accessing data outside of an allocated array). Ian's working on a fix, but in the meantime, you can try Adam's patch: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01379.html Richard
Re: Difficulties compiling under Irix...
Hi! Thanks a lot for your reply! I'll try this patch. Cheers! Philippe Richard Sandiford wrote: > > Philippe Schaffnit <[EMAIL PROTECTED]> writes: > > Yes, I have cleaned-up my sources and all that. > > > > Thanks a lot for your reply! I have start to look for the first revision > > to fail... > > MIPS is known to be broken at the moment because of: > > http://gcc.gnu.org/ml/gcc/2007-07/msg00357.html > > This is likely a manifestation of the same problem (accessing data > outside of an allocated array). Ian's working on a fix, but in the > meantime, you can try Adam's patch: > > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01379.html > > Richard
Re: Difficulties compiling under Irix...
Hi! I don't seem to be able to apply this patch to 126797 sources (today): I can wait for now... Thanks a lot! Philippe PS: to be fair I could very well be goofing on my patching... I get: patching file config/mips/mips.md Hunk #1 succeeded at 3314 (offset 2 lines). Hunk #2 succeeded at 3325 (offset 2 lines). patching file config/mips/mips-protos.h patching file config/mips/mips.c Hunk #2 succeeded at 2103 (offset 11 lines). Hunk #3 succeeded at 2121 (offset 11 lines). Hunk #4 succeeded at 2173 (offset 11 lines). Hunk #5 FAILED at 2204. Hunk #6 succeeded at 2345 (offset 11 lines). Hunk #7 succeeded at 2467 (offset 11 lines). Hunk #8 FAILED at 2487. Hunk #9 succeeded at 2513 (offset 11 lines). Hunk #10 succeeded at 2540 (offset 11 lines). Hunk #11 succeeded at 2550 (offset 11 lines). 2 out of 11 hunks FAILED -- saving rejects to file config/mips/mips.c.rej Richard Sandiford wrote: > > Philippe Schaffnit <[EMAIL PROTECTED]> writes: > > Yes, I have cleaned-up my sources and all that. > > > > Thanks a lot for your reply! I have start to look for the first revision > > to fail... > > MIPS is known to be broken at the moment because of: > > http://gcc.gnu.org/ml/gcc/2007-07/msg00357.html > > This is likely a manifestation of the same problem (accessing data > outside of an allocated array). Ian's working on a fix, but in the > meantime, you can try Adam's patch: > > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01379.html > > Richard
ICE: in explow.c:326 while compiling libgfortan
Hi,
I noticed an ICE occuring while libgfortan is build for target
x86_64-pc-mingw32.
/bin/sh ./libtool --mode=compile
/vol/d/source/gcc-rep/gcc/build/./gcc/gfortran
-B/vol/d/source/gcc-rep/gcc/build/./gcc/
-L/vol/d/source/gcc-rep/gcc/build/x86_6
4-pc-mingw32/winsup/mingw
-L/vol/d/source/gcc-rep/gcc/build/x86_64-pc-mingw32/wi
nsup/w32api/lib -isystem /vol/d/source/gcc-rep/gcc/winsup/mingw/include
-isystem
/vol/d/source/gcc-rep/gcc/winsup/w32api/include
-B/usr/local/x86_64-pc-mingw32/
bin/ -B/usr/local/x86_64-pc-mingw32/lib/ -isystem
/usr/local/x86_64-pc-mingw32/i
nclude -isystem /usr/local/x86_64-pc-mingw32/sys-include -I . -Wall
-fno-repack-
arrays -fno-underscoring -fallow-leading-underscore -g -O2 -c -o
selected_real_k
ind.lo `test -f 'intrinsics/selected_real_kind.f90' || echo
'../../../libgfortra
n/'`intrinsics/selected_real_kind.f90
libtool: compile: /vol/d/source/gcc-rep/gcc/build/./gcc/gfortran
-B/vol/d/sourc
e/gcc-rep/gcc/build/./gcc/
-L/vol/d/source/gcc-rep/gcc/build/x86_64-pc-mingw32/w
insup/mingw
-L/vol/d/source/gcc-rep/gcc/build/x86_64-pc-mingw32/winsup/w32api/li
b -isystem /vol/d/source/gcc-rep/gcc/winsup/mingw/include -isystem
/vol/d/source
/gcc-rep/gcc/winsup/w32api/include -B/usr/local/x86_64-pc-mingw32/bin/
-B/usr/lo
cal/x86_64-pc-mingw32/lib/ -isystem /usr/local/x86_64-pc-mingw32/include
-isyste
m /usr/local/x86_64-pc-mingw32/sys-include -I . -Wall -fno-repack-arrays
-fno-un
derscoring -fallow-leading-underscore -g -O2 -c
../../../libgfortran/intrinsics/
selected_real_kind.f90 -DDLL_EXPORT -o .libs/selected_real_kind.o
../../../libgfortran/intrinsics/selected_real_kind.f90: In function
'_gfortran_s
elected_real_kind':
../../../libgfortran/intrinsics/selected_real_kind.f90:22: internal
compiler err
or: in convert_memory_address, at explow.c:326
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [selected_real_kind.lo] Error 1
make[3]: Leaving directory
`/vol/d/source/gcc-rep/gcc/build/x86_64-pc-mingw32/li
bgfortran'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/vol/d/source/gcc-rep/gcc/build/x86_64-pc-mingw32/li
bgfortran'
make[1]: *** [all-target-libgfortran] Error 2
make[1]: Leaving directory `/vol/d/source/gcc-rep/gcc/build'
make: *** [all] Error 2
It seems to be, that somewhere here a pointer is truncated to an 32-bit
type for some reason and pass this SImode to the memory_addres, which
expects for this target a DImode type (I think this happens in the backend
but I am not certain about ).
May somebody can help about this
I used a typical cross-compilation and configured gcc just by
--target=x86_64-pc-mingw32
I used the current trunk version of binutils, gcc 4.3, and the w64 crt
available from mingw.org
Regards,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
--
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
Ulrike Döhler, Manuela Kluger
iit bombay workshop link
Hi, Based on this morning's announcement by David at the Steering commitee panel . Here's the link to the slides online for folks to look at . http://www.cse.iitb.ac.in/~uday/gcc-workshop/?file=downloads -- cheers Ramana -- Ramana Radhakrishnan
Re: Overload resolution compilation error
Ling-hua Tseng escreveu:
Obviously, {1, 2, 4, 5, 6, 7} are not matched.
Maybe you think that the item 3 is matched.
Unfortunately, it stands for the non-template functions.
Are you sure that it doesn't include template functions? Because I think
it makes sense to consider them too (as Visual Studio does). The point
is that non template functions arguments have higher priority than
template functions (as specified in paragraph 4), and IMO there's no
reason to differentiate between template and non-template functions'
argument target, making the latter work and the former not.
Regards,
Rodolfo Lima.
RE: Overload resolution compilation error
On 20 July 2007 14:57, Rodolfo Schulz de Lima wrote:
> Ling-hua Tseng escreveu:
>> Obviously, {1, 2, 4, 5, 6, 7} are not matched.
>> Maybe you think that the item 3 is matched.
>> Unfortunately, it stands for the non-template functions.
>
> Are you sure that it doesn't include template functions?
Guys, why don't you take this to comp.std.c++ to get an authoritative
answer? That's where you'll find the greatest concentration of people who
really know what the standard /actually means/ by what it says...
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: iit bombay workshop link
On 7/20/07 9:39 AM, Ramana Radhakrishnan wrote: > http://www.cse.iitb.ac.in/~uday/gcc-workshop/?file=downloads Thanks. Looks very useful indeed. I've added a link to it from the GCC Wiki (http://gcc.gnu.org/wiki)
Re: Overload resolution compilation error
Guys, why don't you take this to comp.std.c++ to get an authoritative answer? That's where you'll find the greatest concentration of people who really know what the standard /actually means/ by what it says... Alright, thread moved to comp.lang.c++.moderated, subject "Overload resolution with template and non-template functions", and it's waiting for moderator approval. Regards, Rodolfo Lima.
RE: Overload resolution compilation error
On 20 July 2007 16:31, Rodolfo Schulz de Lima wrote: >> Guys, why don't you take this to comp.std.c++ to get an authoritative >> answer? That's where you'll find the greatest concentration of people who >> really know what the standard /actually means/ by what it says... > > Alright, thread moved to comp.lang.c++.moderated, subject "Overload > resolution with template and non-template functions", and it's waiting > for moderator approval. Thanks, and do drop a note back with a summary of what you find out over there when you're done; if there's definitely a bug in gcc's understanding of the resolution rules, obviously we'd like to open a PR and get it fixed. (It's more likely, however, that the behaviour you see with VS is some kind of non-conformance on their part; the MSVC compiler is IIRC notably less rigorous about implementing and enforcing some of the more complex restrictions in the standard.) cheers, DaveK -- Can't think of a witty .sigline today
summary of the loop-optimizations BOF
Please find the summary of the loop optimizations BOF here: http://gcc.gnu.org/wiki/LoopOptimizationsBOF. We've also updated the Vectorizer Todo wiki page (http://gcc.gnu.org/wiki/VectorizationTasks) and the Loop Optimizations wiki page (http://gcc.gnu.org/wiki/LoopOptTasks). Thanks to everyone who attended the BOF! Dorit, Zdenek, Sebastian, Harsha and Ira.
Loop optimizations cheatsheet
Hello, you can find the cheatsheet I used during my loop optimizations tutorial on gccsummit at http://kam.mff.cuni.cz/~rakdver/loopcheat.ps Zdenek
Re: Overload resolution compilation error
Rodolfo Schulz de Lima wrote
> Ling-hua Tseng escreveu:
> > Obviously, {1, 2, 4, 5, 6, 7} are not matched.
> > Maybe you think that the item 3 is matched.
> > Unfortunately, it stands for the non-template functions.
>
> Are you sure that it doesn't include template functions? Because I think
> it makes sense to consider them too (as Visual Studio does). The point
> is that non template functions arguments have higher priority than
> template functions (as specified in paragraph 4), and IMO there's no
> reason to differentiate between template and non-template functions'
> argument target, making the latter work and the former not.
Even if the they are accepted, we still have a problem.
The target type is `F',
and it cannot be deduced by template argument deduction mechanism
since this mechanism need to know the type of `&print' for deducing.
Nevertheless, the overload resoluion mechanism need to know what `F' is.
Of course, the C++ standard didn't allow this infinite loop.
The template argument deduction should be done first (maybe succeeded or
failed).
It's described in paragraph 2 of section 13.4 and section 14.8.8.2.
The template argument deduction is failed in GCC,
since I cannot find the following context in .cxx.003t.original
after removing the two lines `call(&print<5>);' and `call(&print<7,6>);'
from your original example:
==
;; Function void call(F) [with F = void (*)()] (_Z4callIPFvvEEvT_)
;; enabled by -tree-original
<>>
>>;
==
Since the target type cannot be deduced by template argument deduction
mechanism,
the overload resolution mechanism will not able to select any function names.
It's why I said the overload set is empty.
However, I have tested your example by Comeau C++ compiler in strict C++03 mode.
It's passed to compile without any problems,
so I guess that perhaps you're right.
I'll stop discussing the topic after this reply
since it will be moved to comp.std.c++ after moderator approving it.
I hope that we will able to get a good answer there.
RE: Loop optimizations cheatsheet
Zdenek, Can you send out your presentation too? Thanks, Harsha >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of >Zdenek Dvorak >Sent: Friday, July 20, 2007 3:46 PM >To: gcc@gcc.gnu.org >Subject: Loop optimizations cheatsheet > >Hello, > >you can find the cheatsheet I used during my loop optimizations tutorial >on gccsummit at > >http://kam.mff.cuni.cz/~rakdver/loopcheat.ps > >Zdenek >
Re: Loop optimizations cheatsheet
Hello, > Can you send out your presentation too? the slides and the example code are at http://kam.mff.cuni.cz/~rakdver/slides-gcc2007.pdf http://kam.mff.cuni.cz/~rakdver/diff_reverse.diff Zdenek
gcc-4.3-20070720 is now available
Snapshot gcc-4.3-20070720 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070720/ 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 126804 You'll find: gcc-4.3-20070720.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070720.tar.bz2 C front end and core compiler gcc-ada-4.3-20070720.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070720.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070720.tar.bz2 C++ front end and runtime gcc-java-4.3-20070720.tar.bz2 Java front end and runtime gcc-objc-4.3-20070720.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070720.tar.bz2The GCC testsuite Diffs from 4.3-20070713 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.
