Re: [RFC] Removal of loop notes
Hello, I see that flow no longer uses loop_depth when computing REG_N_REFS, That strikes me as wrong. Don't we want to give pseudos that are in loops preference over those that aren't? we have much more reliable heuristic based on profile information for some time now. Zdenek
Re: Erroneous -mt on Solaris i386
[EMAIL PROTECTED] writes: I compiled gcc 3.4.5 on an i386 pc under Solaris 10 with posix threads. When I try to compile certain downloaded tarballs (especially those that use the gtk+ libs) gcc passes -mt to cc1, which chokes with an illegal option error message. The gcc docs say that this option is for the IA64 on HPUX. What can be done to fix this problem? My workaround has been to edit out any reference to -m options in the specs file, but I am hoping there is a way to recompile gcc so that I don't have to do this. Any suggestions would be appreciated. You're wrong to pass -mt to gcc on Solaris (both SPARC and x86) in the first place; right now, this flag is specific to the Sun compilers, although it would be useful to support them in gcc, too, for cc/CC compatibility. Rainer -- - Rainer Orth, Faculty of Technology, Bielefeld University
Help in AST dump
Hi, Can someone tell me what do unql,high,low refer to in the dump generated by gcc using -fdump-tree-original-raw. @10 integer_type name: @20 unql: @21 size: @22 algn: 64 prec: 36 unsigned min : @23 max : @24 @27 integer_cst type: @13 high: -1 low : -2147483648 Darth -- View this message in context: http://www.nabble.com/Help-in-AST-dump-t1252187.html#a3318259 Sent from the gcc - Dev forum at Nabble.com.
Re: Passing va_args...
Kalaky [EMAIL PROTECTED] writes:
I'am looking for some way to pass variable arguments to another
function that receives variable arguments without using va_list.
This is impossible.
what about?
#define DOTS ...
function_1 (int z, ...);
function_2 (int z, ...);
{
return function_1 (z, DOTS);
}
Andreas.
--JYB
Re: Passing va_args...
Kalaky [EMAIL PROTECTED] writes:
I'am looking for some way to pass variable arguments to another
function that receives variable arguments without using va_list.
This is impossible.
what about?
#define DOTS ...
function_1 (int z, ...);
function_2 (int z, ...);
{
return function_1 (z, DOTS);
}
Andreas.
--JYB
RE: Passing va_args...
On 09 March 2006 13:11, Jean-Yves Bitterlich wrote:
Jean, do you know you're replying to an email from October 2005? Ah well, I
see the thread ended without all the information coming out, Andreas said it
was impossible but didn't go into the details so it's worth mentioning the
builtins.
Kalaky [EMAIL PROTECTED] writes:
I'am looking for some way to pass variable arguments to another
function that receives variable arguments without using va_list.
This is impossible.
what about?
#define DOTS ...
function_1 (int z, ...);
function_2 (int z, ...);
{
return function_1 (z, DOTS);
}
Why would substituting a macro for '...' suddenly make the nonsense
statement
return function_1 (z, ...);
mean anything? That won't even compile, let alone do what you want.
It may be impossible in practice, but it is supposed to be possible to do
this, depsite what Andreas Schwab wrote two messages (and five months)
upthread. Gcc has some functions such as __builtin_apply_args,
__builtin_apply and __builtin_return that let you attempt this, but they are
very tricky features to get right and may fail on some platforms or in some
corner cases. See the gcc manual section on constructing function calls, at
http://gcc.gnu.org/onlinedocs/gcc/Constructing-Calls.html#Constructing-Calls
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Passing va_args...
Dave Korn wrote:
On 09 March 2006 13:11, Jean-Yves Bitterlich wrote:
Jean, do you know you're replying to an email from October 2005? Ah well, I
see the thread ended without all the information coming out, Andreas said it
was impossible but didn't go into the details so it's worth mentioning the
builtins.
Kalaky [EMAIL PROTECTED] writes:
I'am looking for some way to pass variable arguments to another
function that receives variable arguments without using va_list.
This is impossible.
what about?
#define DOTS ...
function_1 (int z, ...);
function_2 (int z, ...);
{
return function_1 (z, DOTS);
}
Why would substituting a macro for '...' suddenly make the nonsense
statement
return function_1 (z, ...);
mean anything? That won't even compile, let alone do what you want.
well ... it does compile (2.95.3)
aim is easy to find (function_2 is public method doing a bit known (i.e.
z argument pre-checking), whereas function_1 is internal (of a library
for example)). ... also I have to admit, a macro() is probably the best
choice in most case.
It may be impossible in practice, but it is supposed to be possible to do
this, depsite what Andreas Schwab wrote two messages (and five months)
upthread. Gcc has some functions such as __builtin_apply_args,
__builtin_apply and __builtin_return that let you attempt this, but they are
very tricky features to get right and may fail on some platforms or in some
corner cases. See the gcc manual section on constructing function calls, at
a question concerning the __builtin_* functions: could these functions
help me in finding out whether there are at lease 1 argument passed ?
The background is the following constructs:
function b(q,w,f,va_list a) {
}
function a(x,f,...) {
va_list a;
va_start(a,f);
b(q,w,f,a);
va_end(a)
}
How can check in function b that there is at least 1 parameter ?
i.e. How can I avoid such things like a(x,%s) = b(q,w,%s,a)
cheers,
DaveK
--JYB
Re: RFC: Memory SSA. A redesign of the virtual operand scheme.
On Wed, 2006-03-08 at 15:05 -0500, Andrew Pinski wrote: I notice in your PDF, you have: Since alias analysis results are often conservative, may-alias sets my contain tens and enve hundreds of symbols. Is there a reason why not tune the aliasing anaysis to return more liberal results instead of changing the representation? Because you can't. From looking at Tramp3D, I found (and filed) a case where the aliasing anaysis was too conservative. The analysis you ask for is, in general, impossible. Even if we went the ridiculous route of trying to special case every single situation where we knew we could remove some single thing from an alias set, they would still be too conservative in some places. Also that was the only case I could find and it would reduce the VOPs for this testcase after fixing this issue. I filed this as PR 26609. Removing the vops in this testcase is possible, but a bit tricky, and somewhat irrelevant. I can look at the other testcases you mention and find more cases where aliasing analysis is very conservative and file the bugs for them. This seems like a better plan than just changing the representation to work around the fact the may-alias sets are big. may-alias sets may be big, this is a fact of life. As we get into interprocedural and whole-program analysis, they are going to get bigger, not smaller. Designing a representation that can represent large may-alias sets well is 1. A very good idea 2. Completely orthogonal to improving aliasing set precision. Claiming that we will never need this representation because we can always just increase alias precision is not a good argument to make, because it is provably false.
Would like to use gcc source code to improve compiler development skills
I have C/C++/Java programming skills. I have also studied a couple of books on compiler development. I would like to start with a project that will provide me with the experience of having participated in a real compiler development effort. I am interested in C/C++/Java. Can you tell me which module I should download from your CVS server. I would like to study code for all the major phases including lexical analysis, parsing, semantic analysis, intermediate code generation, optimation, and code generation. Sincerely, Lalit Gidwani __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)
Jeffrey A Law wrote: Presumably there's a reason why enumeral types don't have a base type? They don't in Ada (since there is no issue at the Ada semantic level of out of range intermediate values), but we could certainly introduce such a notion at the implementation level if it helps. I've got no strong opinions on how to fix this, I just wanted to throw out another possible approach. jeff
Re: [RFC] Removal of loop notes
I see that flow no longer uses loop_depth when computing REG_N_REFS, That strikes me as wrong. Don't we want to give pseudos that are in loops preference over those that aren't? On Thu, Mar 09, 2006 at 09:12:35AM +0100, Zdenek Dvorak wrote: we have much more reliable heuristic based on profile information for some time now. Profile information isn't always available.
Re: Would like to use gcc source code to improve compiler development skills
On 3/9/06, Lalit Gidwani [EMAIL PROTECTED] wrote: I have C/C++/Java programming skills. I have also studied a couple of books on compiler development. I would like to start with a project that will provide me with the experience of having participated in a real compiler development effort. I am interested in C/C++/Java. Can you tell me which module I should download from your CVS server. I would like to study code for all the major phases including lexical analysis, parsing, semantic analysis, intermediate code generation, optimation, and code generation. The web page http://gcc.gnu.org/install/ has instructions for downloading the complete GCC sources and building them. This list is generally meant for discussion about active development of GCC. If you find you need help building GCC, you should ask those questions on the gcc-help mailing list; see http://gcc.gnu.org/lists.html.
Re: [RFC] Removal of loop notes
On 3/9/06, Joe Buck [EMAIL PROTECTED] wrote: Profile information isn't always available. On Thu, Mar 09, 2006 at 06:26:27PM +0100, Steven Bosscher wrote: But branch predictions are, and those are still far more reliable than loop notes. The predictions use natural loop discovery and they are exact for loops with a known number of iterations. Agreed.
Crazy ICE from gcc 4.1.0
I've built a generic 4.1.0 for RH7.3 x86 linux (I did a make bootstrap)
Compiling a rather large file, I get
tmp.f_00.cxx:26432: error: unrecognizable insn:
(insn 173 172 174 9 (set (reg:QI 122)
(const_int 128 [0x80])) -1 (nil)
(nil))
tmp.f_00.cxx:26432: internal compiler error: in extract_insn, at
recog.c:2020
Which looks insane, because there's a perfectly good define_insn (cf *movqi_1
in i386.md)
I'm trying to reduce this to a reasonably sized test case (and I'm going to try
debugging this in the recognizer),
but I can't see why this instruction isn't matching the 2nd constraint
alternative and just producing a movb r,#128
(define_insn *movqi_1
[(set (match_operand:QI 0 nonimmediate_operand =q,q ,q ,r,r ,?r,m)
(match_operand:QI 1 general_operand q,qn,qm,q,rn,qm,qn))]
GET_CODE (operands[0]) != MEM || GET_CODE (operands[1]) != MEM
{
switch (get_attr_type (insn))
{
case TYPE_IMOVX:
gcc_assert (ANY_QI_REG_P (operands[1]) || GET_CODE (operands[1]) == MEM);
return movz{bl|x}\t{%1, %k0|%k0, %1};
default:
if (get_attr_mode (insn) == MODE_SI)
return mov{l}\t{%k1, %k0|%k0, %k1};
else
return mov{b}\t{%1, %0|%0, %1};
}
}
AST dump
Hi, Can someone tell me what do unql,high,low refer to in the dump generated by gcc using -fdump-tree-original-raw. @10 integer_type name: @20 unql: @21 size: @22 algn: 64 prec: 36 unsigned min : @23 max : @24 @27 integer_cst type: @13 high: -1 low : -2147483648 Darth -- View this message in context: http://www.nabble.com/AST-dump-t1252187.html#a3318259 Sent from the gcc - Dev forum at Nabble.com.
Re: Crazy ICE from gcc 4.1.0
On Thursday 09 March 2006 18:04, Alan Lehotsky wrote: I've built a generic 4.1.0 for RH7.3 x86 linux (I did a make bootstrap) Compiling a rather large file, I get tmp.f_00.cxx:26432: error: unrecognizable insn: (insn 173 172 174 9 (set (reg:QI 122) (const_int 128 [0x80])) -1 (nil) (nil)) tmp.f_00.cxx:26432: internal compiler error: in extract_insn, at recog.c:2020 Which looks insane, because there's a perfectly good define_insn (cf *movqi_1 in i386.md) It's invalid RTL. The constant isn't properly sign extended. It should be (const int -128 [0xff80]) Paul
Re: gcc-4.2-20060304 is now available
On Mon, 6 Mar 2006, Joseph S. Myers wrote: It is a bit weird that objcp is included in the gcc-core download. It could be included in the gcc-objc download (or in a separate objcp download). But It should go in an objcp download. sourcebuild.texi includes updating the release script as one of the things to do when contributing a new front end. Hmm, do we really want to split of another .tar file? Looking at the current sizes gcc-core-4.2-20060304.tar.bz2 = 15703096 gcc-g++-4.2-20060304.tar.bz2 = 3905138 gcc-objc-4.2-20060304.tar.bz2 = 191280 gcc-fortran-4.2-20060304.tar.bz2 = 793478 gcc-testsuite-4.2-20060304.tar.bz2 = 3606941 I'd really suggest to make this part of gcc-objc instead of adding another one. Gerald
Re: GCC for SPARC Systems
Alexey Starovoytov [EMAIL PROTECTED] writes: We are pleased to announce the availability of GCC for SPARC (R) Systems (GCCfss) at http://cooltools.sunsource.net/gcc/ GCCfss extends GCC to be able to use the optimizing Sun(tm) Code Generator for SPARC systems (SCGfss). A couple of questions: * Would it be possible to use the same technique for Solaris/x86 or Linux/x86, too? Both versions of Studio 11 provide libsunir.so as well. * Maybe it would be possible to perform further development on a vendor branch in the GCC svn repository? I'm not sure if this would require SC buy-in, though. Perhaps the changes might become acceptible for FSF GCC at some point in time; there have been discussions over at opensolaris.org about opening the sources to the Sun compilers. Thanks. Rainer -- - Rainer Orth, Faculty of Technology, Bielefeld University
gcc-4.0-20060309 is now available
Snapshot gcc-4.0-20060309 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060309/ 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 111910 You'll find: gcc-4.0-20060309.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20060309.tar.bz2 C front end and core compiler gcc-ada-4.0-20060309.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20060309.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20060309.tar.bz2 C++ front end and runtime gcc-java-4.0-20060309.tar.bz2 Java front end and runtime gcc-objc-4.0-20060309.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20060309.tar.bz2The GCC testsuite Diffs from 4.0-20060302 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.
regmove.c and call_used_regs[]
I am working on a port with gcc-4.0.2, and I've been getting a
segmentation fault when call_used_regs[] is referenced with a pseudo
register in fixup_match_2() in regmove.c.
if (call_used_regs[REGNO(dst)])
|| find_reg_fusage (p, CLOBBER, dst))
break;
...
}
regmove_optimize() calls fixup_match_2(), and checks that REGNO(dst) is
a pseudo register, or it will skip the piece of code that calls
fixup_match_2().
if (!REG_P (dst)
|| REGNO (dst) FIRST_PSEUDO_REGISTER
|| REG_LIVE_LENGTH (REGNO (dst)) 0
|| GET_MODE (src) != GET_MODE (dst))
continue;
.
if (REGNO (src) FIRST_PSEUDO_REGISTER)
{
if (GET_CODE (SET_SRC (set)) == PLUS
GET_CODE (XEXP (SET_SRC (set), 1)) == CONST_INT
XEXP (SET_SRC (set), 0) == src
fixup_match_2 (insn, dst, src,
XEXP (SET_SRC (set), 1),
regmove_dump_file))
break;
Is there another area within regmove_optimize() that constrains the dst
to be a real register? That would prevent the segmentation fault when
call_used_regs[] is accessed with a pseudo register.
Thanks for your help.
Jeffri
http://www.google.com/url?sa=Dq=http%3A%2F%2Fwww.autospies.com%2Farticle%2Findex.asp%3FarticleId%3D6654%26categoryId%3D
Problem with pex-win32.c
Ian -- The new pex-win32.c code doesn't operate correctly when used for MinGW-hosted tools invoked from a Cygwin window. In particular, process creation (gcc invoking as, say) results in a DOS console window popping up. When invoked from a DOS window, things are fine. The reason for this problem is that the current code uses MSVCRT's spawn to create the process, and that function doesn't provide fine enough control. You have to use CreateProcess to make this work as desired. When invoking CreateProcess, you must set bInheritHandle to TRUE and pass a long a STARTUPINFO structure with dwFlags set to STARTF_USESTDHANDLES, and the various hStd* handle fields set to the values from the calling process. (I'm pretty sure that CodeSourcery posted patches that did that at one point; they were in our 3.4-based toolchains.) You might think that linking with -mwindows would work, and, indeed that avoids the DOS windows popping up in Cygwin -- but they you get no output at all under Windows. I guess I have two questions: (a) do you feel like fixing this, and (b) if not, do you have any objection to using CreateProcess? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
prev_nonnote_insn that follow branches?
Is there a function like prev_nonnote_insn that, when it encounters a label preceeded by a barrier, attempts to determine if there's a single jump to that branch and returns it if so?
Re: GCC for SPARC Systems
On Thu, 9 Mar 2006, Rainer Orth wrote: Alexey Starovoytov [EMAIL PROTECTED] writes: We are pleased to announce the availability of GCC for SPARC (R) Systems (GCCfss) at http://cooltools.sunsource.net/gcc/ GCCfss extends GCC to be able to use the optimizing Sun(tm) Code Generator for SPARC systems (SCGfss). A couple of questions: * Would it be possible to use the same technique for Solaris/x86 or Linux/x86, too? Both versions of Studio 11 provide libsunir.so as well. It is certainly possible, but considered as not desirable. As an engineer I can say that it wouldn't be too difficult to do the x86, but I don't think it will happen any time soon. * Maybe it would be possible to perform further development on a vendor branch in the GCC svn repository? I'm not sure if this would require SC buy-in, though. Perhaps the changes might become acceptible for FSF GCC at some point in time; there have been discussions over at opensolaris.org about opening the sources to the Sun compilers. Personally I'd like to arrange it as a gcc branch or contribute it in some way, but my previous effort of much smaller scale (gcc2c) had quite negative reception, so I don't expect any sort of approval. Also I'd like to emphasize that GCC for SPARC Systems is trying to deliver performance on SPARC cpus to those users who use plain GCC compiler there. That's it. I tried to explain my personal opinion of gcc4ss vs gcc on sparc on my blog: http://blogs.sun.com/roller/page/alexey Please don't hesitate to ask questions. I'll be glad to share the details of implementation and hope that few things may be useful to GCC developers as well. Thank you. Alexey. Thanks. Rainer -- - Rainer Orth, Faculty of Technology, Bielefeld University
Re: GCC for SPARC Systems
* Maybe it would be possible to perform further development on a vendor branch in the GCC svn repository? I'm not sure if this would require SC buy-in, though. Perhaps the changes might become acceptible for FSF GCC at some point in time; there have been discussions over at opensolaris.org about opening the sources to the Sun compilers. Personally I'd like to arrange it as a gcc branch or contribute it in some way, but my previous effort of much smaller scale (gcc2c) had quite negative reception, so I don't expect any sort of approval. Honestly, i doubt you would ever get it. At a bare minimum, i'd expect nobody would even consider it until the sources to Sun's compilers were GPL'd or put under a GPL compatible license[1]. Also I'd like to emphasize that GCC for SPARC Systems is trying to deliver performance on SPARC cpus to those users who use plain GCC compiler there. Right. and instead of taking the route that other companies like IBM, and recently, Intel and HP, have taken, which is to work *with* the GCC community, and improve GCC, Sun apparently has decided to just work around it. It is one thing to say that short term, you need to do something else (like hook up GCC to ORC or something) because GCC won't improve fast enough. But as far as i can tell Sun has absolutely no long term goal to actually attempt to improve GCC so they don't need to do these kinds of things. [1] For the curious, what they are doing is simply taking our IR, and converting it to their IR, and writing it to a file, and then passing the file off to something else. Much like Open64 did.
Re: Problem with pex-win32.c
Mark Mitchell [EMAIL PROTECTED] writes: The new pex-win32.c code doesn't operate correctly when used for MinGW-hosted tools invoked from a Cygwin window. In particular, process creation (gcc invoking as, say) results in a DOS console window popping up. When invoked from a DOS window, things are fine. The reason for this problem is that the current code uses MSVCRT's spawn to create the process, and that function doesn't provide fine enough control. You have to use CreateProcess to make this work as desired. When invoking CreateProcess, you must set bInheritHandle to TRUE and pass a long a STARTUPINFO structure with dwFlags set to STARTF_USESTDHANDLES, and the various hStd* handle fields set to the values from the calling process. (I'm pretty sure that CodeSourcery posted patches that did that at one point; they were in our 3.4-based toolchains.) You might think that linking with -mwindows would work, and, indeed that avoids the DOS windows popping up in Cygwin -- but they you get no output at all under Windows. I guess I have two questions: (a) do you feel like fixing this, and (b) if not, do you have any objection to using CreateProcess? I just copied the use of spawn from the earlier pex-win32 implementation. The pex_win32_exec_child function is basically exactly the same code as before. I certainly have no objection to using CreateProcess instead. I could try a patch, but I can't test it, because I don't have a Windows system. So it might be better if somebody else tackled it. Ian
[Bug c++/26615] New: compute size of static table in compile time rejected.
#include cstdio
template typename T, std::size_t N
char[N] sizer( T (array)[N] ); === gcc error:
expected unqualified-id before #8216;[#8217;
token
int main()
{
int t[15];
printf(%Zd\n, sizeof(sizer(t)));
return 0;
}
--
Summary: compute size of static table in compile time rejected.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: x86-64-linux
GCC host triplet: x86-64-linux
GCC target triplet: x86-64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26615
[Bug c/26616] New: internal compiler error: in fixup_var_refs_1
I get an ICE when compiling net/core/dev.o from the linux kernel 2.6.11.6, this does not happen if I remove the -Os option or when compiling for ARM (not thumb) The dev.i file is 510K, how do I upload it ? output : Reading specs from /cygdrive/c/gccarm/lib/gcc/arm-elf/3.4.0/specs Configured with: /cygdrive/c/Projects/PreProjects/uclinux/2_6/tools/gcc-3.4.0/configure --host=i386-pc-cygwin32 --target=arm-elf --prefix=/cygdrive/c/gccarm --enable-languages=c --enable-multilib --enable-target-optspace --with-gnu-ld --disable-nls --with-float=soft --disable-__cxa_atexit --disable-c99 --disable-clocale --disable-c-mbchar --disable-long-long --enable-threads=posix --enable-cxx-flags=-D_ISOC99_SOURCE -D_BSD_SOURCE Thread model: posix gcc version 3.4.0 /cygdrive/c/gccarm/libexec/gcc/arm-elf/3.4.0/cc1.exe -E -quiet -nostdinc -v -Iinclude -D__ARM_ARCH_4T__ -D__USES_INITFINI__ -D__KERNEL__ -D__linux__ -D__LINUX_ARM_ARCH__=4 -Uarm -DKBUILD_BASENAME=dev -DKBUILD_MODNAME=dev -isystem /cygdrive/c/gccarm/lib/gcc/arm-elf/3.4.0/include -MD net/core/.dev.o.d net/core/dev.c -mapcs -mno-sched-prolog -mbig-endian -mapcs-32 -march=armv4t -mtune=arm7tdmi -malignment-traps -msoft-float -mthumb -mthumb-interwork -Wall -Wstrict-prototypes -Wno-trigraphs -Wdeclaration-after-statement -fno-strict-aliasing -fno-common -ffreestanding -fno-omit-frame-pointer -fno-builtin -fno-omit-frame-pointer -Os -o dev.i #include ... search starts here: #include ... search starts here: include /cygdrive/c/gccarm/lib/gcc/arm-elf/3.4.0/include End of search list. /cygdrive/c/gccarm/libexec/gcc/arm-elf/3.4.0/cc1.exe -fpreprocessed dev.i -quiet -dumpbase dev.c -mapcs -mno-sched-prolog -mbig-endian -mapcs-32 -march=armv4t -mtune=arm7tdmi -malignment-traps -msoft-float -mthumb -mthumb-interwork -auxbase-strip net/core/dev.o -Os -Wall -Wstrict-prototypes -Wno-trigraphs -Wdeclaration-after-statement -version -fno-strict-aliasing -fno-common -ffreestanding -fno-omit-frame-pointer -fno-builtin -fno-omit-frame-pointer -o dev.s GNU C version 3.4.0 (arm-elf) compiled by GNU C version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125). GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64430 net/core/dev.c: In function `dev_ifsioc': net/core/dev.c:2344: warning: comparison of distinct pointer types lacks a cast net/core/dev.c:2365: warning: comparison of distinct pointer types lacks a cast net/core/dev.c: In function `dev_alloc_name': net/core/dev.c:719: internal compiler error: in fixup_var_refs_1, at function.c:1867 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Command line : arm-elf-gcc -Wp,-MD,net/core/.dev.o.d -nostdinc -isystem /cygdrive/c/gccarm/lib/gcc/arm-elf/3.4.0/include -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -fno-omit-frame-pointer -fno-builtin -D__linux__ -fno-omit-frame-pointer -mapcs -mno-sched-prolog -mbig-endian -mapcs-32 -D__LINUX_ARM_ARCH__=4 -march=armv4t -mtune=arm7tdmi -malignment-traps -msoft-float -Uarm -mthumb -mthumb-interwork -Wdeclaration-after-statement -DKBUILD_BASENAME=dev -DKBUILD_MODNAME=dev -c -o net/core/dev.o net/core/dev.c -Os -v -save-temp -- Summary: internal compiler error: in fixup_var_refs_1 Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: orenskl at lipman dot co dot il GCC build triplet: i386-pc-cygwin32 GCC host triplet: i386-pc-cygwin32 GCC target triplet: arm-elf-gcc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26616
[Bug c++/26615] compute size of static table in compile time rejected.
--- Comment #1 from pluto at agmk dot net 2006-03-09 09:43 --- ooops, it's invalid c++ (returning an array) code. the better testcase is: template typename T, std::size_t N char[N] sizer( T (array)[N] ); the `char ()[15]` can be returned by function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26615
[Bug c++/26615] compute size of static table in compile time rejected.
--- Comment #2 from pluto at agmk dot net 2006-03-09 10:10 --- (In reply to comment #1) ooops, it's invalid c++ (returning an array) code. the better testcase is: template typename T, std::size_t N char[N] sizer( T (array)[N] ); the `char ()[15]` can be returned by function. ok, my fault:/ now it works. template typename T, std::size_t N char (sizer( T (array)[N] ))[N]; -- pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26615
[Bug java/26617] New: A class from an unnamed package is visible to classes in named packages
GCJ allows classes in named packages to see classes in unnamed packages.
For example:
./Snafu.java
public class Snafu { }
--
./foo/Bar.java
package foo;
// import Snafu;
public class Bar
{
Snafu junk;
}
Note that GCJ accepts the code in foo/Bar.java with
or without the line commenting out the import declaration.
Both Jikes 1.22 and Sun's JDK 1.5.0_05 reject this
code.
--
Summary: A class from an unnamed package is visible to classes in
named packages
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmathew at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26617
[Bug target/26541] std lib problems at link time
--- Comment #3 from multix at gmail dot com 2006-03-09 10:22 --- If I compile 3.4.5 using --disable-shared the problem goes away, thus it is a problem with the shared library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26541
[Bug tree-optimization/25449] [4.0] endless loop in nbench neural net with -ftree-loop-linear
--- Comment #5 from RonnyPeine at gmx dot de 2006-03-09 10:37 --- (In reply to comment #4) Is there a testcase other than just compile and run nbench with -ftree-loop-linear? Yes, see PR20256: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20256 This is just a duplicate bugreport. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25449
[Bug c/26616] internal compiler error: in fixup_var_refs_1
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-09 10:39 --- Try a more recent release from the 3.4 series first, please. Otherwise, just attach the preprocessed source to the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26616
[Bug c/26616] internal compiler error: in fixup_var_refs_1
--- Comment #2 from orenskl at lipman dot co dot il 2006-03-09 11:17 --- Created an attachment (id=11008) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11008action=view) bug test case Bug happens also on GCC 3.4.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26616
[Bug c/26616] internal compiler error: in fixup_var_refs_1
--- Comment #3 from orenskl at lipman dot co dot il 2006-03-09 11:17 --- Bug happens also on GCC 3.4.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26616
[Bug tree-optimization/25449] [4.0] endless loop in nbench neural net with -ftree-loop-linear
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-09 13:28 --- *** This bug has been marked as a duplicate of 20256 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25449
[Bug tree-optimization/20256] Perfect nest transformation not conservative enough
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-09 13:28 --- *** Bug 25449 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||RonnyPeine at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20256
[Bug middle-end/26616] internal compiler error: in fixup_var_refs_1
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-09 13:32 --- One more thing, 3.4.6 (which has not been announced yet but it is on the ftp server) is the last 3.4.x release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26616
[Bug rtl-optimization/26619] New: Compiler fails to correctly initialize global reg variable
GCC 4.1.0 initializes another register than the one specified in the definition. I'm not sure it this has also something to do with bug 21596. The same testcase built with GCC 3.4.4 is correct. -- Summary: Compiler fails to correctly initialize global reg variable Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave dot mueller at gmx dot ch GCC host triplet: i686-gnu-linux GCC target triplet: arm-linux, powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26619
[Bug rtl-optimization/26619] Compiler fails to correctly initialize global reg variable
--- Comment #1 from dave dot mueller at gmx dot ch 2006-03-09 13:59 --- Created an attachment (id=11009) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11009action=view) PowerPC .i file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26619
[Bug rtl-optimization/26619] Compiler fails to correctly initialize global reg variable
--- Comment #2 from dave dot mueller at gmx dot ch 2006-03-09 14:00 --- Created an attachment (id=11010) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11010action=view) PowerPC .s file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26619
[Bug rtl-optimization/26619] Compiler fails to correctly initialize global reg variable
--- Comment #3 from dave dot mueller at gmx dot ch 2006-03-09 14:01 --- Created an attachment (id=11011) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11011action=view) ARM .s file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26619
[Bug rtl-optimization/26619] Compiler fails to correctly initialize global reg variable
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-09 14:02 --- local register variables don't do what you think they do. Hint they only work with inline-asm. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26619
[Bug rtl-optimization/26619] Compiler fails to correctly initialize global reg variable
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-09 14:03 ---
If you want to use r5 the correct way is to do:
register int *foo asm(r5) = 0;
void t1(void)
{
*foo = 1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26619
[Bug middle-end/26616] internal compiler error: in fixup_var_refs_1
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-09 14:21 ---
Reduced testcase:
int dev_alloc_name()
{
int i = 0;
f(i);
if (__builtin_constant_p(i))
g();
}
--
This is fixed in 4.0.0 and above by the tree-ssa merge and cannot be invoked in
4.0.0 and above because __builtin_constant_p is foldded/simplified early on.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||FIXED
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26616
[Bug c/26613] Corner case causes garbage to be output by -aux-info switch.
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-09 14:22 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|All | GCC host triplet|All | GCC target triplet|All | Last reconfirmed|-00-00 00:00:00 |2006-03-09 14:22:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26613
[Bug middle-end/26561] [4.2 Regression] ACATS failures c34004a, c46033a and cxg2024 at -O0
--- Comment #7 from sayle at gcc dot gnu dot org 2006-03-09 14:54 --- Subject: Bug 26561 Author: sayle Date: Thu Mar 9 14:54:11 2006 New Revision: 111862 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111862 Log: 2006-03-09 Roger Sayle [EMAIL PROTECTED] Eric Botcazou [EMAIL PROTECTED] PR middle-end/26561 * fold-const.c (fold_div_compare): When optimizing X/C1 op C2 as X op C3, consider whether C3 overflows towards +Inf or -Inf. * gcc.c-torture/execute/divcmp-5.c: New test case. Added: trunk/gcc/testsuite/gcc.c-torture/execute/divcmp-5.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26561
[Bug fortran/26509] incorrect behaviour of error-handler for internal read
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-03-09 14:56 --- If you are doing sequential writes, the write truncates the file. So if you write out 8 bytes where there were 4 before, it just overwrites and extends the file length if necessary. All data after the last write goes away. This is normal behavior. If it is DIRECT I/O you are doing, this is a different story and record sizes are fixed length. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509
[Bug fortran/26509] incorrect behaviour of error-handler for internal read
--- Comment #14 from martin at mpa-garching dot mpg dot de 2006-03-09 15:11 --- (In reply to comment #13) If it is DIRECT I/O you are doing, this is a different story and record sizes are fixed length. Yes, that's what I'm talking about. Consider: PROGRAM TESTRECL IMPLICIT NONE OPEN(UNIT = 10, FILE = 'test', FORM = 'UNFORMATTED', : ACCESS = 'DIRECT', RECL = 4, ERR = 101) WRITE(UNIT=10,REC=1,ERR=101) 1d0 PRINT *,no error detected GOTO 102 101 PRINT *,error detected 102 CONTINUE CLOSE(UNIT=10, STATUS='DELETE') END ~/tmpgfortran test3.f ~/tmp./a.out At line 7 of file test3.f Fortran runtime error: End of record All I'm saying is that in this situation there seems to be no way to jump to some label if something goes wrong (because there is no EOR parameter for WRITE). But I agree that this is not gfortran's problem, but rather an inconsistency in the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509
[Bug middle-end/26561] [4.2 Regression] ACATS failures c34004a, c46033a and cxg2024 at -O0
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-03-09 15:32 --- Thanks Roger! -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26561
[Bug c++/26621] New: template Instanciation fails for -O3
On various architectures all the 4.0.X versions of g++ fail to properly instanciate some members of a class template if optimisation is set to -O3. For -O2 everything is fine. A test case will be attached. Versions tested: g++ 4.0.3 20060212 (prerelease) (Debian 4.0.2-9) i686-pc-linux-gnu g++ 4.0.2 x86_64-redhat-linux g++ 4.0.1 (Apple Computer, Inc. build 5247) powerpc-apple-darwin8 Versions known to work: g++ 3.4.X -- Summary: template Instanciation fails for -O3 Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: _talyn_ at web dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26621
[Bug c++/26621] template Instanciation fails for -O3
--- Comment #1 from _talyn_ at web dot de 2006-03-09 16:33 --- Created an attachment (id=11013) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11013action=view) Test case consisting of a Makefile and three source files The makefile runs a compilation and linking with -O2 and -O3, the first succeeds in linking, the latter not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26621
[Bug c++/26621] template Instanciation fails for -O1 -finline-functions
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|minor |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26621
[Bug c++/26621] template Instanciation fails for -O1 -finline-functions
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-09 16:49 --- I don't think this is a bug. We are inlining CVectorWrap::~CVectorWrap into main which causes the reference to TTypeWrapper::~TTypeWrapper and TTypeWrapper::~TTypeWrapper is not used in instance.cc at all so it is not emitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26621
[Bug testsuite/26344] [4.2 Regression] three testsuite failures in gcc.dg/tree-ssa/
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-03-09 17:19 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26344
[Bug c/26004] [4.1/4.2 Regression] gcc errors on valid code [SVO]
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-01-28 15:17:42 |2006-03-09 17:22:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26004
[Bug testsuite/26344] [4.2 Regression] three testsuite failures in gcc.dg/tree-ssa/
--- Comment #14 from law at redhat dot com 2006-03-09 18:02 --- Subject: Re: [4.2 Regression] three testsuite failures in gcc.dg/tree-ssa/ On Thu, 2006-03-09 at 17:19 +, pinskia at gcc dot gnu dot org wrote: --- Comment #13 from pinskia at gcc dot gnu dot org 2006-03-09 17:19 --- Fixed. Only two of the three have been fixed. Please don't close this yet. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26344
[Bug c++/26621] template Instanciation fails for -O1 -finline-functions
--- Comment #3 from _talyn_ at web dot de 2006-03-09 18:06 --- Allocating the CVectorWrap variable dynamically removes the undefined reference to TTypeWrapper::~TTypeWrapper. I guess that's because it is virtual, and a dynamic instance of CVectorWrap will call CVectorWrap::~CVectorWrap via VMT. But this would mean that a copy of TTypeWrapper::~TTypeWrapper is somehow available, just not accessable outside instance.cc. And there are the other link errors: get_type() and getT() are refereced in instance.cc. I guess they are inlined therein, and hence, referencing these functions from wrap_filter fails. (In reply to comment #2) I don't think this is a bug. We are inlining CVectorWrap::~CVectorWrap into main which causes the reference to TTypeWrapper::~TTypeWrapper and TTypeWrapper::~TTypeWrapper is not used in instance.cc at all so it is not emitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26621
[Bug middle-end/26076] ICE in can_throw_internal_1 at except.c:2581
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-09 18:27 --- Confirmed on the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |middle-end Ever Confirmed|0 |1 Known to fail||4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-03-09 18:27:44 date|| Summary|[gomp] ICE in |ICE in can_throw_internal_1 |can_throw_internal_1 at |at except.c:2581 |except.c:2581 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26076
[Bug c++/25952] -fopenmp causes ICE on valid code
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-09 18:31 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25952
[Bug middle-end/26611] [GOMP] openmp gomp ICE at gimplify.c:4257
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-09 18:33 --- Also happens on the mainline now. Reducing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||error-recovery, ice-on- ||invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26611
[Bug middle-end/26611] [GOMP] openmp gomp ICE at gimplify.c:4257
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-09 18:43 ---
Confirmed, reduced testcase:
int t;
void search()
{
#pragma omp parallel for
for (int i = 0; i 1000; ++i) try {
mm::print(t);
}catch(...){}
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-03-09 18:43:30
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26611
[Bug c++/26084] ICE (segfault) on C++ OpenMP code
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-09 18:49 --- PR 26076 has a reducer testcase and I can reduce the testcase in here into that one. *** This bug has been marked as a duplicate of 26076 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE Summary|[gomp-branch] ICE (segfault)|ICE (segfault) on C++ OpenMP |on C++ OpenMP code |code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
[Bug middle-end/26076] ICE in can_throw_internal_1 at except.c:2581
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-09 18:49 --- *** Bug 26084 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||martin at mpa-garching dot ||mpg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26076
[Bug middle-end/26076] ICE in can_throw_internal_1 at except.c:2581
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-09 18:53 ---
A little simplier testcase is:
struct A
{
~A();
};
void foo()
{
#pragma omp parallel
A a, b;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26076
[Bug c++/26084] ICE (segfault) on C++ OpenMP code
--- Comment #8 from dnovillo at gcc dot gnu dot org 2006-03-09 19:01 --- Andrew, please do not close bugs if you do not understand the problem. You obviously have not even tried to understand the problem. This PR is related to 26076 but it is *not* a duplicate. The patch that I developed originally fixes the reduced cases in this PR and 26076, but it DOES NOT fix the unreduced test case. There are more interactions with EH than what my initial patch fixed. Richard is looking at fixing the original, unreduced case in this PR. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org BugsThisDependsOn|26076 | Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
[Bug libgcj/24461] array access in either GZIPInputStream, Inflater, natInflate.cc, or zlib
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-09 19:02 --- Testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-10-24 19:05:27 |2006-03-09 19:02:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24461
[Bug c++/26084] ICE (segfault) on C++ OpenMP code
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-09 19:03 --- (In reply to comment #8) Andrew, please do not close bugs if you do not understand the problem. You obviously have not even tried to understand the problem. This PR is related to 26076 but it is *not* a duplicate. Then there are two issues, one for the reduced testcase which is PR 26076 and another issue. But please don't say I don't understand the issue when the fact is this testcase here actually reduces to the testcase in PR 26076. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
[Bug c++/26084] ICE (segfault) on C++ OpenMP code
--- Comment #10 from dnovillo at redhat dot com 2006-03-09 19:10 --- Subject: Re: ICE (segfault) on C++ OpenMP code On 03/09/06 14:03, pinskia at gcc dot gnu dot org wrote: Then there are two issues, one for the reduced testcase which is PR 26076 and another issue. But please don't say I don't understand the issue when the fact is this testcase here actually reduces to the testcase in PR 26076. The fact that you closed one as a duplicate of the other is a clear indication that you have no idea what the issue is about. Reducing one test case to another one means nothing. The very reduction removes information that hides other bugs, or other aspects of the same bug. If you are so keen on closing PRs, close 26076 as a duplicate of this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
[Bug c++/26084] ICE (segfault) on C++ OpenMP code
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-03-09 19:17 --- (In reply to comment #10) If you are so keen on closing PRs, close 26076 as a duplicate of this one. If you had written a status on this bug before I closed it as a dup, I would not have closed it as a dup because I would have read that it was not fully a dup. Also really a secondary bug should be opened for the other bug you found after fixing the reduced testcase with a new reduced testcase instead of not just agrueeing in this bug. There was no way to know what was going on without status of the bug in the bug comments itself. (Note this applies for all the bug assigned to people). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
[Bug libgcj/23495] java.lang.String.equals is suboptimal
--- Comment #12 from tromey at gcc dot gnu dot org 2006-03-09 19:17 --- Fair enough. I'm handling this. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|WAITING |ASSIGNED Last reconfirmed|2005-08-20 19:41:09 |2006-03-09 19:17:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23495
[Bug c++/26084] ICE (segfault) on C++ OpenMP code
--- Comment #12 from dnovillo at redhat dot com 2006-03-09 19:28 --- Subject: Re: ICE (segfault) on C++ OpenMP code On 03/09/06 14:17, pinskia at gcc dot gnu dot org wrote: If you had written a status on this bug before I closed it as a dup, I would not have closed it as a dup because I would have read that it was not fully a dup. When in doubt, ask. I don't have the time you seem to have to keep a perfectly up-to-date status on the PRs I have in my queue. I understand that you as a bugmaster would like to minimize open PRs and have perfect information on all of them, but such is life. It's an imperfect system and the bugs will not always have all the information you want in them. Unless you are absolutely certain (i.e., you have worked on a patch or debugged the problem in detail), you should ask the developer who was last working on the bug to see what the status is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
[Bug c++/26622] New: ICE in extract_insn, at recog.c:2084
Test case is huge (26KLOC), but only takes a fraction of a second to compile and die. Just compile with g++ -c ice.i I'll append the test case momentarily -- Summary: ICE in extract_insn, at recog.c:2084 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: apl at alum dot mit dot edu GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug c++/26622] ICE in extract_insn, at recog.c:2084
--- Comment #1 from apl at alum dot mit dot edu 2006-03-09 19:43 --- Created an attachment (id=11014) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11014action=view) test causing ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug c++/26622] ICE in extract_insn, at recog.c:2084
--- Comment #2 from apl at alum dot mit dot edu 2006-03-09 19:49 --- /tools/linux/gcc-4.1.0/bin/g++ -c ice.i tmp.f_00.cxx: In member function 'void CarbonDesignSystems__design::c_top::f_$block_selfcycle3_v_L7_253_()': tmp.f_00.cxx:26432: error: unrecognizable insn: (insn 176 175 177 12 (set (reg:QI 119) (const_int 128 [0x80])) -1 (nil) (nil)) tmp.f_00.cxx:26432: internal compiler error: in extract_insn, at recog.c:2084 P I don't understand why the instruction recogizer doesn't match the '*movqi_1' pattern in expectation of generating a 'movb #128,pseudo119' -- apl at alum dot mit dot edu changed: What|Removed |Added Component|target |c++ Known to fail||4.0.2 4.1.0 Known to work||3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug target/26622] ICE in extract_insn, at recog.c:2084
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-09 19:56 --- This works for me on x86_64-linux with -m32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #3 from dnovillo at gcc dot gnu dot org 2006-03-09 20:07 --- Diego, is this still an issue on mainline? I can look into the runtime error, though. Works now. I can live with the LD_LIBRARY_PATH problem. Though I don't remember how we handle other libraries like libgfortran and libstc++ (I do need to set LD_LIBRARY_PATH for fortran, IIRC). -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug target/23301] [4.0/4.1/4.2 Regression] sys/ucontext.h missing on powerpc-*-darwin5.*
--- Comment #6 from geoffk at gcc dot gnu dot org 2006-03-09 20:19 --- darwin5.5 is not a viable host OS for GCC; you need to upgrade. It has, at least, bugs in mmap. I think at this point you probably need Mac OS 10.3/darwin7.0 or later, but it's likely that 10.2 will work fairly well. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23301
[Bug libgcj/24461] array access in either GZIPInputStream, Inflater, natInflate.cc, or zlib
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-09 20:22 --- Subject: Bug 24461 Author: tromey Date: Thu Mar 9 20:21:58 2006 New Revision: 111870 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111870 Log: PR libgcj/24461: * java/util/zip/InflaterInputStream.java (fill): Throw exception if stream is truncated. Modified: trunk/libjava/ChangeLog trunk/libjava/java/util/zip/InflaterInputStream.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24461
[Bug target/26622] ICE in extract_insn, at recog.c:2084
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-09 20:24 --- But I can reproduce it on a real i686 machine. Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug libgcj/24461] array access in either GZIPInputStream, Inflater, natInflate.cc, or zlib
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-09 20:25 --- Subject: Bug 24461 Author: tromey Date: Thu Mar 9 20:25:23 2006 New Revision: 111871 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111871 Log: PR libgcj/24461: * java/util/zip/InflaterInputStream.java (fill): Throw exception if stream is truncated. Modified: branches/gcc-4_1-branch/libjava/ChangeLog branches/gcc-4_1-branch/libjava/java/util/zip/InflaterInputStream.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24461
[Bug libgcj/24461] array access in either GZIPInputStream, Inflater, natInflate.cc, or zlib
--- Comment #7 from tromey at gcc dot gnu dot org 2006-03-09 20:27 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24461
[Bug target/26622] [4.0/4.1/4.2 Regression] ICE in extract_insn, at recog.c:2084
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-09 21:12 ---
Confirmed, reduced testcase:
unsigned char m_in4;
unsigned long long block_selfcycle3_v_L7_253_()
{
return ((long long)((m_in4 0x80) != 0)) 7;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-03-09 21:12:11
date||
Summary|ICE in extract_insn, at |[4.0/4.1/4.2 Regression] ICE
|recog.c:2084|in extract_insn, at
||recog.c:2084
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug target/26622] [4.0/4.1/4.2 Regression] ICE in extract_insn, at recog.c:2084
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-09 21:17 --- This looks like another HWI being 32bit bug :( which is why it works on x86_64 with -m32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26622
[Bug java/26624] New: make install too slow due to CNI header installation
make install in libgcj is currently very slow compared to make install-exec because of the number of CNI headers and how they are installed, that is one install command per header. This should be sped up so that we can simply use make install on rebuilds since this is most likely what the uninitiated will use. -- Summary: make install too slow due to CNI header installation Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fitzsim at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26624
[Bug java/26625] New: libgcj-4.2.0.jar not rebuilt after a source file change
We were modifying libjava/java/lang/Character.java and rebuilding, and libgcj-4.2.0.jar wasn't being rebuilt. I didn't try to figure out why but I thought I'd file the issue since others have seen it too. -- Summary: libgcj-4.2.0.jar not rebuilt after a source file change Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fitzsim at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26625
[Bug awt/22163] scrollbars appear and disappear
--- Comment #3 from langel at redhat dot com 2006-03-09 22:09 --- Fixed. most widgets are fixed accordingly. I will be fixing the rest and creating mauve tests for all AWT widgets. -- langel at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22163
[Bug middle-end/24998] [4.2 Regression] Build failure: undefined symbol __floatunsitf
--- Comment #27 from wilson at specifix dot com 2006-03-09 22:21 --- Subject: Re: [4.2 Regression] Build failure: undefined symbol __floatunsitf fxcoudert at gcc dot gnu dot org wrote: Adding the maintainers of all those in Cc list. I don't know what US_SOFTWARE_GOFAST, but from the last sentence quoted above, it looks like I don't really want to know :) I'll tell you anyways. See http://www.smxinfo.com/ussw/gofast.htm Our support code hasn't been updated in such a long time that I'm skeptical it works with current versions of the gofast library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug tree-optimization/26626] New: ICE in in add_virtual_operand
following testcase ICEs with = -O2 for a few days now:
=== Cut ===
extern int *__errno_location (void) throw () __attribute__ ((__const__));
typedef union {
double d;
unsigned L[2];
} U;
void kjs_strtod()
{
int rv,e1;
unsigned z;
if (e1 308) { ovfl: (*__errno_location ()) = 34; }
((U*)rv)-d *= 1e16;
if ((z = ((U*)rv)-L[1] 0x7ff0) 0x10)
goto ovfl;
}
=== Cut===
#1 0x081f2e1b in add_virtual_operand (var=value optimized out, s_ann=value
optimized out,
flags=value optimized out, full_ref=0xb7d22140, offset=0, size=64,
for_clobber=0 '\0')
at tree-ssa-operands.c:979
#2 0x081f7ecb in get_indirect_ref_operands (stmt=0xb7d1b1d4, expr=0xb7d95b00,
flags=1,
full_ref=0xb7d22140, offset=0, size=64, recurse_on_base=0 '\0') at
tree-ssa-operands.c:1116
#3 0x081f4105 in get_expr_operands (stmt=0xb7d1b1d4, expr_p=0xb7d1b1f0,
flags=3)
at tree-ssa-operands.c:1617
#4 0x081f5380 in parse_ssa_operands (stmt=0xb7d1b1d4) at
tree-ssa-operands.c:1763
#5 0x081f5be4 in build_ssa_operands (stmt=0xb7d1b1d4) at
tree-ssa-operands.c:1825
#6 0x081f6ec1 in update_stmt_operands (stmt=0xb7d1b1d4) at
tree-ssa-operands.c:1867
#7 0x081b5569 in mark_new_vars_to_rename (stmt=0xb7d1b1d4) at
tree-flow-inline.h:280
#8 0x08246a56 in substitute_and_fold (prop_value=0x87cf580, use_ranges_p=0
'\0')
at tree-ssa-propagate.c:1154
#9 0x081ef1be in execute_copy_prop (store_copy_prop=value optimized out,
phis_only=value optimized out) at tree-ssa-copy.c:914
#10 0x081ef34f in do_copy_prop () at tree-ssa-copy.c:1048
#11 0x085023fb in execute_one_pass (pass=0x86f8040) at passes.c:863
#12 0x085025a7 in execute_pass_list (pass=0x86f8040) at passes.c:910
#13 0x085025ba in execute_pass_list (pass=0x86f7d40) at passes.c:911
#14 0x081bf996 in tree_rest_of_compilation (fndecl=0xb7dcbc80) at
tree-optimize.c:418
#15 0x0812a906 in expand_body (fn=0xb7dcbc80) at semantics.c:3009
#16 0x085512b5 in cgraph_expand_function (node=0xb7dcbd00) at cgraphunit.c:1102
#17 0x08553d1b in cgraph_optimize () at cgraphunit.c:1167
#18 0x080d3cf5 in cp_finish_file () at decl2.c:3110
#19 0x0819106f in c_common_parse_file (set_yydebug=0) at c-opts.c:1166
#20 0x084ce803 in toplev_main (argc=14, argv=0xbfae7bb4) at toplev.c:999
#21 0x0819e1b2 in main (argc=0, argv=0xb7dcd508) at main.c:35
--
Summary: ICE in in add_virtual_operand
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mueller at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug tree-optimization/26626] ICE in in add_virtual_operand
--- Comment #1 from mueller at gcc dot gnu dot org 2006-03-09 22:40 --- reduce-min5.ii: In function #8216;void kjs_strtod()#8217;: reduce-min5.ii:12: warning: #8216;e1#8217; is used uninitialized in this function reduce-min5.ii:8: internal compiler error: in add_virtual_operand, at tree-ssa-operands.c:979 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug c++/11159] erroneous warning in copy ctor with virtual inheritance
--- Comment #9 from wotte at dre dot vanderbilt dot edu 2006-03-09 22:44
---
In some cases, this warning can also be impossible to address and may be
buggy/erroneous. Consider the following example:
struct A
{
A ();
};
struct B : virtual A
{
B ();
};
struct C : virtual B
{
C ();
};
template typename Base
struct E : Base
{
E ();
E (E const )
{
};
};
EC foo;
EC bar (foo);
Produces the following diagnostic:
test.cpp: In copy constructor 'EBase::E(const EBase) [with Base = C]':
test.cpp:27: instantiated from here
test.cpp:21: warning: base class 'struct A' should be explicitly initialized in
the copy constructor
test.cpp:21: warning: base class 'struct B' should be explicitly initialized in
the copy constructor
test.cpp:21: warning: base class 'struct C' should be explicitly initialized in
the copy constructor
If I make an immediately obvious fix by explicitly initializing Base:
struct A
{
A ();
};
struct B : virtual A
{
B ();
};
struct C : virtual B
{
C ();
};
template typename Base
struct E : Base
{
E ();
E (E const )
: Base ()
{
};
};
EC foo;
EC bar (foo);
I am presented with the following diagnostic:
test.cpp: In copy constructor 'EBase::E(const EBase) [with Base = C]':
test.cpp:28: instantiated from here
test.cpp:21: warning: base class 'struct A' should be explicitly initialized in
the copy constructor
test.cpp:21: warning: base class 'struct B' should be explicitly initialized in
the copy constructor
In this case, E can't explicitly initialize A or B, because E can't assume that
either is present as a parent of Base. This is also likely erroneous because E
shouldn't have to explicitly initialize the parents of Base... That should be
handled by the copy constructor of Base.
--
wotte at dre dot vanderbilt dot edu changed:
What|Removed |Added
CC||wotte at dre dot vanderbilt
||dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11159
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-09 22:52 --- Removing throw () will also cause the code to be ICE'd and also with the C front-end now too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-03-09 22:52:29 date|| Summary|ICE in in |[4.2 Regression] ICE in in |add_virtual_operand |add_virtual_operand Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-09 22:54 --- The difference between copyprop and before is the following. Before: rv.0_3 = rv.0_2; # VUSE NMT.7_13; D.1900_4 = rv.0_3-d; After: rv.0_3 = rv.0_2; # VUSE SMT.6; D.1900_4 = rv.0_2-d; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
Re: [Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
On Thu, 2006-03-09 at 22:54 +, pinskia at gcc dot gnu dot org wrote: --- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-09 22:54 --- The difference between copyprop and before is the following. Before: rv.0_3 = rv.0_2; # VUSE NMT.7_13; D.1900_4 = rv.0_3-d; After: rv.0_3 = rv.0_2; # VUSE SMT.6; D.1900_4 = rv.0_2-d; This is nonsensical, and very bad.
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-03-09 23:31 --- Subject: Re: [4.2 Regression] ICE in in add_virtual_operand On Thu, 2006-03-09 at 22:54 +, pinskia at gcc dot gnu dot org wrote: --- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-09 22:54 --- The difference between copyprop and before is the following. Before: rv.0_3 = rv.0_2; # VUSE NMT.7_13; D.1900_4 = rv.0_3-d; After: rv.0_3 = rv.0_2; # VUSE SMT.6; D.1900_4 = rv.0_2-d; This is nonsensical, and very bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-09 23:58 --- Forgot to say we also get the following NOTEs in the copyprop dump: NOTE: no flow-sensitive alias info for rv.0_2 in # VUSE NMT.8_14; D.2364_4 = rv.0_2-d; NOTE: no flow-sensitive alias info for rv.0_2 in # VUSE NMT.8_14; D.2364_4 = rv.0_2-d; NOTE: no flow-sensitive alias info for rv.0_2 in # NMT.8_17 = V_MAY_DEF NMT.8_14; rv.0_2-d = D.2365_5; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-03-10 00:39 --- Subject: Re: [4.2 Regression] ICE in in add_virtual_operand On Thu, 2006-03-09 at 23:58 +, pinskia at gcc dot gnu dot org wrote: --- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-09 23:58 --- Forgot to say we also get the following NOTEs in the copyprop dump: NOTE: no flow-sensitive alias info for rv.0_2 in # VUSE NMT.8_14; D.2364_4 = rv.0_2-d; NOTE: no flow-sensitive alias info for rv.0_2 in # VUSE NMT.8_14; D.2364_4 = rv.0_2-d; NOTE: no flow-sensitive alias info for rv.0_2 in # NMT.8_17 = V_MAY_DEF NMT.8_14; rv.0_2-d = D.2365_5; This bare NMT usage is wrong, and indicative of a problem elsewhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug libgcj/23495] java.lang.String.equals is suboptimal
--- Comment #13 from tromey at gcc dot gnu dot org 2006-03-10 00:39 --- Subject: Bug 23495 Author: tromey Date: Fri Mar 10 00:39:49 2006 New Revision: 111919 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111919 Log: PR libgcj/23495: * java/lang/natString.cc (_Jv_NewString): Use memcpy. (equals): Use memcmp. (contentEquals): Likewise. (getChars): Use memcpy. (toCharArray): Likewise. (regionMatches): Use memcmp. (regionMatches): Likewise. (startsWith): Likewise. (concat): Use memcpy. (valueOf): Likewise. Modified: trunk/libjava/ChangeLog trunk/libjava/java/lang/natString.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23495
[Bug libgcj/23495] java.lang.String.equals is suboptimal
--- Comment #14 from tromey at gcc dot gnu dot org 2006-03-10 00:48 --- I checked in a patch using memcpy and memcmp. This didn't yield as dramatic a speedup for me, but did do ok. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23495
[Bug target/26472] Default path for libgcc_s.sl is build directory
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2006-03-10 01:25 --- Subject: Re: Default path for libgcc_s.sl is build directory Attached. The diff is against libtool in binutils as about July 28, 2005. Similar changes have entered both branch-1-5 and HEAD Libtool more than 2 years ago; branch-1-4 is long dead. I can only guess that's why it was ignored. ;-) HPPA support has evolved a bit since. There is BTW a pending patch (both branches): http://article.gmane.org/gmane.comp.gnu.libtool.general/7083 The problem is the new HPPA support isn't in the GCC or Sourceware trees. However, I'm beginning to think the HPPA support for shared libraries is totally wrong (i.e., linking in dependent shared libraries in shared links). First, see the recommendations in http://docs.hp.com/en/1896/pthreads.html. HP libc contains stubs for the pthread stubs. So, for example, when we link libstdc++ against libc, we end up with the following dependencies: -bash-2.05b$ chatr libstdc++.sl libstdc++.sl: shared library shared library dynamic path search: SHLIB_PATH disabled second embedded path enabled first /opt/gnu/gcc/gcc-4.1.0/lib internal name: libstdc++.sl.6 shared library list: dynamic /usr/lib/libm.2 dynamic /test/gnu/gcc-4.1/objdir/./gcc/libgcc_s.sl dynamic /usr/lib/libc.2 So, libstdc++.sl is linked against the pthread stubs in libc instead of the real pthread functions in libpthread. I'm not sure I fully understand how binding affects symbol resolution. The default binding is deferred, and in that case function references are trapped via the linkage table and bound on the first reference. If the first pthread reference comes from libstdc++, I think the application will bind to the pthread stub functions in libc. On the other hand, if the first reference comes from from some other place it may bind against routines in libpthread. Thus, the default binding with the current scheme is likely unpredictable or may change as libraries load. Linking dependent libraries into shared libraries also makes it more likely that multiple incompatible versions would be used in an application. I don't think you will find any HP shared libraries that have similar dependencies. I've recently been trying to get Java working under HP-UX and haven't yet found a version of gdb that can handle backtraces correctly because they all get the shared library locations wrong. This is probably because the dynamic loader is loading multiple versions of a library. I think a better approach would be to not link in any dependent shared libraries in shared links. As far as I can tell, there aren't any issues with undefined symbols (at least in HP-UX 11). Thoughts? Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472
