Re: Analyzer test failures

em as suck? Or are they real failures of the analyzer? see also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113150 Although I xfail'ed the tests on HPUX, I left the bug open. Dave -- John David Anglin dave.ang...@bell.net

Re: gcc-gnat for Linux/MIPS-32bit-be, and HPPA2

On Sun, Jul 22, 2018 at 03:24:48AM +0200, Carlo Pisani wrote:> > On HPPA: > - "gnatgcc" is not existing out of the debian pagkage(1) > - gnat make calls "gcc-4.3" > - the installed gcc (provided by gentoo) can't compile ada-files > - since the compiler was compiled with languages=C,C++,Fortran >

Re: pa indirect_jump instruction

p_insn (CODE_FOR_indirect_jump, 1, ops); emit_barrier (); #endif } but I think testing HAVE_indirect_jump (-> targetm.have_indirect_jump ()) is more correct. Would it be OK to remove the operands[] condition? Or should/could it be a pmode_register_operand instead of a register_operand? Thanks, Richard -- John David Anglin dave.ang...@bell.net

Re: Bootstrap configuration for hppa-linux-gnu ?

ssible to do a 64-bit bootstrap on hppa-linux-gnu since there is no glibc or kernel support for 64-bit runtime. The 64-bit compiler is built as a cross and just used to build 64-bit kernels. 32-bit bootstrap should work fine. "Full" 64-bit support is only available on hpux11.

Re: missing symbols in libstdc++.so.6 built from the 4.9 branch

CC_ATOMIC_INT_LOCK_FREE = 2, etc. Have to see if this works with our library functions :- Dave -- John David Anglindave.ang...@bell.net

Re: missing symbols in libstdc++.so.6 built from the 4.9 branch

David Anglin dave.ang...@bell.net

Re: missing symbols in libstdc++.so.6 built from the 4.9 branch

y define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, etc, in pa-linux.h. I'll experiment with defining ATOMIC_INT_LOCK_FREE there. Thanks, Dave -- John David Anglin dave.ang...@bell.net

Re: [PATCH][RFC] Always require a 64bit HWI

this change as I know this causes support issues. The HP ansi C compiler and aCC have long long. This is not an issue for linux. I believe people can find HP-UX GCC binaries on the net. Dave -- John David Anglin dave.ang...@bell.net

Re: [PATCH][RFC] Always require a 64bit HWI

ber but without ansi support one needs to start with an early 4.X version. Dave -- John David Anglindave.ang...@bell.net

Re: Can -mno-big-switch be removed from the PA port?

On 6-Apr-13, at 3:16 PM, Steven Bosscher wrote: On Sat, Apr 6, 2013 at 7:09 PM, John David Anglin wrote: On 6-Apr-13, at 12:25 PM, Steven Bosscher wrote: Are there any reasons against removing !TARGET_BIG_SWITCH support? It would really help if this code can go away... Yes, branch

Re: Can -mno-big-switch be removed from the PA port?

thrash. This occurs on machines with shared instruction and data TLBs. Would this help? Dave -- John David Anglin dave.ang...@bell.net

Re: Reorg a reorg.c comment

stly in which insn is "in charge". */ + (the RT is the only known exception at this point). */ #include "config.h" #include "system.h" Dave -- John David Anglin dave.ang...@bell.net

Re: Reorg a reorg.c comment

Section I-3 in PA-RISC 2.0 Architecture). ;;- See file "rtl.def" for documentation on define_insn, match_*, et. al. Dave -- John David Anglin dave.ang...@bell.net

Re: [Target maintainers]: Please update libjava/sysdep/*/locks.h with new atomic builtins

and user code to link against libatomic. So, I'm not sure this is an improvement. The sync builtins aren't supported on hpux. Dave -- John David Anglindave.ang...@bell.net

Re: Deprecate 32-bits HP-PA for GCC 4.8?

(float:SF (match_dup 2)))] "TARGET_PA_11 && ! TARGET_SOFT_FLOAT" " { if (TARGET_PA_20) { emit_insn (gen_floatunssisf2_pa20 (operands[0], operands[1])); DONE; } operands[2] = gen_reg_rtx (DImode); }") TARGET_PA_20 implies TARGET_PA_11. Dave -- John David Anglindave.ang...@bell.net

Re: Deprecate 32-bits HP-PA for GCC 4.8?

On 5/7/2012 2:29 PM, Jeff Law wrote: On 05/07/2012 12:25 PM, John David Anglin wrote: There is also a 32-bit netbsd port that a limited number of users are still using. Do you know if they're using the open-sourced SOM linker or the 32 bit ELF stuff? ELF. PA linux runs on both PA 1.

Re: Deprecate 32-bits HP-PA for GCC 4.8?

;t think the effort is worth it and would prefer to spend my time working on new features like movmisalign support. Dave -- John David Anglindave.ang...@bell.net

Re: Deprecate 32-bits HP-PA for GCC 4.8?

s. The resulting PA port would support HP-UX11 on 64bits PA-RISC 2.0 (i.e. HP-PA8xxx). It's hard enough to maintain HP-UX11 support on HP-PA. With this cleanup, the job would become a bit simpler. Thoughts/comments? Ciao! Steven Dave -- John David Anglindave.ang...@bell.net

GCC Bugzilla with Firefox 3.6.12

I have experienced a number of problems with the new bugzilla. It seems "Reload current page" doesn't consistently update all fields (e.g., Target Milestone). As a result, entering new comments, etc, can corrupt fields that haven't been updated. I tend to leave bug pages open in tabs. Has anyon

Re: MPC version 0.8 released!

> The platforms still needed for mpc-0.8 release testing are: > > i386-unknown-freebsd (have results for mpc-0.8dev) > > i686-pc-cygwin (have results for mpc-0.8dev) > hppa2.0w-hp-hpux11.11 (have results for mpc-0.8dev) mpc-0.8 builds and all tests pass on: hppa1.1-hp-hpux10.20 hppa2.0w-hp-hpux1

Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)

> Please test this MPC package and report back the results of running > "make check" along with your target triplet, the compiler version you > used, and the versions of gmp/mpfr used to compile it. You do not > necessarily need to bootstrap mainline GCC with this MPC, but if you > have the spare

Re: Not using DECL_VALUE_EXPR for callee-copied parameters?

Hi Martin, > Having said that, if anybody has problems with this patch going in, > please speak out now rather than later. I very much appreciate the work you have done on this problem. However, the patch doesn't work as expected. I get multiple comparison failures with this change on hppa-unkn

Re: hppa testsuite stalls?

> the testsuite on the hppa machine (gcc61 on the compile farm) has > always hanged for me from time to time. However, lately (at least > since I returned from vacation last Monday) it hangs every time. This is likely a kernel problem. There are long standing problems with testsuite timeouts and

Re: Question about creating stdint.h on systems that don't have it

> > I have to define __STDC_EXT__ under all circumstances to get consistency > > of the long long types in the 32-bit runtime. Previously, gcc for hpux > > tried to mirror the behavior of the HP C compiler wrt long long types. > > Rather then define __STDC_EXT__ all the time I was looking at defi

Re: Question about creating stdint.h on systems that don't have it

Attached is my change as it currently stands. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) Index: config.gcc === -

Re: Question about creating stdint.h on systems that don't have it

I have a patch to provide stdint.h on HP-UX that I have been testing. I have resolved the consistency issues with inttypes.h although there are some slightly wierd aspects. For example, I found "signed char" and "char" are inconsistent, yet characters are signed. The specification of some types d

Re: cleanup tests failing on MIPS64

The same tests now fail on hppa. This is PR 39651. I'm fairly certain this was introduced by the following change: 2009-03-28 Jan Hubicka Merge from pretty-ipa: 2009-03-27 Jan Hubicka * cgraph.c (dump_cgraph_node): Add replace output flag by process. ...

Re: GCC 4.4.0 Status Report (2009-01-31)

990-0752 (FAX: 952-6602) 2009-01-31 John David Anglin * config/pa/fptr.c: Revert license to GPL 2. * config/pa/milli64.S: Likewise. Index: config/pa/fptr.c === --- config/pa/fptr.c(revision 143821) +++ config

Re: GCC 4.4.0 Status Report (2009-01-31)

> removed. The 4.4 branch will be created when all the P1 fixes are committed > and the licensing changes (see the GCC Runtime Library Exception thread on > gcc mailing list) land on the trunk. I noticed sometime ago that two files in the PA backend were incorrectly changed from GPL 2 to GPL 3.

Re: GCC 4.3.3 Status Report (2009-01-17), branch frozen for

> If you are fine with these not being in the release-candidate but > only in the final release then I don't mind. That's fine. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)

Re: GCC 4.3.3 Status Report (2009-01-17), branch frozen for release

On Sat, 17 Jan 2009, Richard Guenther wrote: > It's not my turn to send a status report, but as I plan doing a release > candidate for GCC 4.3.3 soon I thought a status report for that would > be in order. Sorry Richard, I didn't see this until too late. I committed three PA changes this morning

Re: Bootstrap failure with uninitialized warnings (on hppa)

> > This doesn't look HPPA specific but I haven't seen anything in the > > mailing lists. HPPA is/was having other problems but this doesn't seem > > to be related to them. Is anyone else seeing these messages? > > This was reported as PR 37380. As a work around, revert this change: 2008-09-03

objc build error

/home/dave/gnu/gcc-4.4/objdir/./prev-gcc/xgcc -B/home/dave/gnu/gcc-4.4/objdir/./prev-gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.4.0/hppa-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-att

Re: Bad code generation on HPPA platform

> If I am reading things right, the use of r8 and r19 in the ldw > instruction are switched around. Yes. If you do an rtl dump, you should be able to see where the REG_POINTER flag gets set and if the operand order gets switched. Sometimes the REG_POINTER flag gets removed by reload, etc. So, th

Re: GCC 4.3 target deprecation proposals

> * parisc*-*-*, alias for hppa*-*-*. Also apparently an unused alias > handled by config.gcc that should move to config.sub if desired. I'm happy to see this go. It's not checked for in the testsuite, etc. > HP-UX is only being tested on hppa, not IA64. I believe that Steve Ellcey is testin

Re: GCC 4.3 target deprecation proposals

> On Tue, Jan 22, 2008 at 10:01:55AM +1100, Ben Elliston wrote: > > My understanding is that NetBSD port to the vax is very much alive and > > maintained. Thus, I expect that those users (eg Matt Thomas) would like > > to see the GCC port retained. > > How can we encourage the NetBSD folks to par

Re: GCC 4.3 target deprecation proposals

> Neither, actually. It's tester base that counts the most. I had a discussion with Jan-Benedict Glaw last night about this. He has been working on a linux port. He said: > The damn thing is that we need a working kernel + userland. Irrelevant > of the actual operating system. Maybe it would b

Re: GCC 4.3 target deprecation proposals

> The following target architectures have seen no test results posted in > the past year: arc, c4x (as listed above), crx, iq2000, mt, pdp11, > score, stormy16, vax. Regarding vax, I don't have the time to maintain it. HPPA has taken all my free time in the past year. I probably should remove my

Re: Status of GCC 4.3 on HPPA (Debian)

> I recently compiled the Debian archive (around 7000 packages that need > to be compiled) on HPPA (PA RISC) using trunk to identify new issues > before GCC 4.3 is released. I compiled the archive with optimization set > to -O3 and found the following ICEs with trunk from 20071212: Thanks Martin

Re: gcc 4.3.0 revision 129794 on hppa2.0w-hp-hpux11.00

> Comments? Should I file a bug report? Yes. It would help to know where the reference to ggc_free in rtl.o comes from (i.e., look at preprocessed source for this file). I don't think this file normally uses ggc_free(). Dave -- J. David Anglin [EMAIL PROTECTED]

Ada bootstrap broken

This change breaks Ada: 2007-09-27 Ollie Wild <[EMAIL PROTECTED]> * varasm.c (compare_constant): Removed call to ... * langhooks-def.h (lhd_return_tree): Removed. (LANG_HOOKS_EXPAND_CONSTANT): Removed. (LANG_HOOKS_INITIALIZER): Removed LANG_HOOKS_EXPAND_C

Re: tgmath.h and newlib

This affects parisc all hpux versions except for possibly 11.31. I've experimented with not including complex.h. With a couple of other testsuite changes (complex -> __complex__), the tgmath tests behave in a semi-reasonable manner if complex arguments are avoided. However, I don't really see an

Re: Another BOOTSTRAP failure on sparc-sun-solaris2.10, stage2 miscompiled

> I succeed past this failure if I revert Zdenek's iv-opts patch (r128272). Same here. The failure also occurs on all hppa targets. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)

bootstrap failure on hppa-unknown-linux-gnu

In stage2, ../../gcc/gcc/tree.c:7694: error: passing argument 1 of 'fixed_zerop' discards qualifiers from pointer target type Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)

Re: GCC 4.2.1 Status Report (2007-07-10)

> The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th. PR 32199 is a regression in behavior from 4.2.0. Although a libjava build regression is probably not sufficient justification to block the scheduled release, the change that triggered this regression has nothing to do the java/libj

Re: [doc,patch] Fortran compiler on Ultrix and clobbered registers

> I noted in the GCC docs (see for example http://gcc.gnu.org/ > onlinedocs/gcc/Interoperation.html) that we have the following text > in the section "Known Causes of Trouble with GCC": > > > On Ultrix, the Fortran compiler expects registers 2 through 5 to be > > saved by function calls. Howe

RE: GCC 4.2.0 Status Report (2007-04-15)

> > Despite the fact that virtually all of the bugs open against 4.2.0 are > > also open against 4.1 or 4.3 -- or both! -- there seems to be little > > interest in fixing them. > > > > Some have suggested that I try to solve this by closing GCC 4.3 > > development until 4.2.0 is done. > > So he

Re: Call to arms: testsuite failures on various targets

> * hppa64-hp-hpux11.11: many failures Most of these are "Type/rank mismatch in argument": FAIL: gfortran.dg/assumed_charlen_function_5.f90 -O (test for excess errors) Excess errors: /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/assumed_charlen_function_5.f90:22: E rror: Type/rank mismatch in arg

Re: Call to arms: testsuite failures on various targets

> * hppa-unknown-linux-gnu: gfortran.dg/cray_pointers_2.f90 Fails due to timeout (slow system?): real5m45.735s user1m33.506s sys 4m11.716s I should note that the compilation time doesn't seem consistent from one run to the next. Here's the detailed breakdown: GNU F95 version 4.3.0

Re: building gcc 4.1.1 on HP-UX 10.20

> > Bug reports should be filed for these two problems. Do you have > > PHCO_20721 and PHCO_26158 installed? Locale might the behavior > > of awk in generating options.h. > > I have PHCO_20721 installed, but not PHCO_26158. And I just wasted > about a half hour of my life trying to *find* it.

Re: building gcc 4.1.1 on HP-UX 10.20

> > Regarding the use of pthreads, that's strange. Without --disable-threads, > > GCC should use DCE threads on hpux10. GCC definitely knows about the > > threads available in HP-UX 10. See for example, gthr-dce.h. > > I have GNU pth installed in /usr/local, and (according to gcc/config.log) >

Re: building gcc 4.1.1 on HP-UX 10.20

> In order to build gcc 4.1.1 on HP-UX 10.20 I had to install GNU awk > and also configure with --disable-threads. The vendor's awk did not > build the options.h file correctly; the exact symptom was duplicated > OPT_d and OPT_w symbols in the enum. Then, the build blew up when it > tried to use

Re: libgcc-math and the gcc 4.2 release

> Richard Guenther <[EMAIL PROTECTED]> writes: > | As far as I understand we (GCC) have to develop our own codes > | independently of glibc unless RMS agrees to have copies/forks of > | glibc code in GCC (this includes license changes to GPL + libgcc exception > | like in this case). What is fin

Re: hang in acats testsuite test cxg2014 on hppa2.0w-hp-hpux11.00

> > Mark, is it ok for Olivier to apply the patch mentioned here on > > 4.1? > > > http://gcc.gnu.org/ml/gcc/2006-02/msg00251.html > > > > It only affects Ada on PA HP-UX. It's obviously correct. > > I'm deferring commits until the set of branches to which I should apply > is settled. As

Re: Ada bootstrap failure for mainline on hppa2.0w-hp-hpux11.00

> cc1: error: unrecognized command line option "-f " I don't see any such option in the last xgcc command. What's your gmake version? I've seen problems using versions earlier than 3.80. The next most likely possibility is that this is another loop invariant bug: http://gcc.gnu.org/ml/gcc-patch

Re: hang in acats testsuite test cxg2014 on hppa2.0w-hp-hpux11.00

> The patch proposed by Olivier applied to 4.1 gives 0 failures for the whole > acats testsuite, as you can see: > > LAST_UPDATED: > === acats tests === > > === acats Summary === > # of expected passes 2316 > # of unexpected failures 0 While not quite as

Re: hang in acats testsuite test cxg2014 on hppa2.0w-hp-hpux11.00

> On Feb 15, 2006, at 11:44, John David Anglin wrote: > > I missed this "new" define and will try it. Perhaps, this should > > take account of the situation when TARGET_SOFT_FLOAT is true. For > > example, > > When emulating all software floating-point,

Re: hang in acats testsuite test cxg2014 on hppa2.0w-hp-hpux11.00

> + /* The widest floating point format supported by the hardware. Note that > +setting this influences some Ada floating point type sizes, currently > +required for GNAT to operate properly. */ > + #define WIDEST_HARDWARE_FP_SIZE 64 I missed this "new" define and will try it. Perhaps,

Re: http://gcc.gnu.org/ml/gcc/2006-02/msg00212.html

> acats test cxg2014 hangs forever on hppa2.0w-hp-hpux11.00. This is PR ada/13408. I see that I opened this back in 2003. It probably has something to do with the IEEE quad support. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

> I found the cause for the bootstrap failure. > > Normally I pass "-mpa-risc-2-0" to the boostrap compiler. This bug should now be fixed. See . Dave -- J. David Anglin [EMAIL PROTECTED] National Research Counc

Re: Request for clarification on the 128bit long double requirments

> I would like to understand better why and how this GCC 4.1 requirement > for adding 128bit long double support came about. Although the lack of 128-bit long-double support has been discussed on and off for sometime on the parisc-linux list, I hadn't realized this was now a requirement for GCC 4.

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

> Ok, I did a bootstrap and testsuite run without passing -mpa-risc-2-0 to the > boostrap compiler. Testresults including configure options and environment at > > http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01297.html > > the only acats test that failed: c52103x Your results are better than

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

> Perhaps I have to be more precise. Bootstrapping ada failed! That's not enough! In order for someone else to duplicate the failure and investigate the problem, you need to provide the log of what happened, your configure command, etc. For example, I would have never guessed that you were usin

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

> I found the cause for the bootstrap failure. > > Normally I pass "-mpa-risc-2-0" to the boostrap compiler. This produces > PA-RISC2.0 optimized executables. As you can see: > > file gcc > gcc:PA-RISC2.0 shared executable dynamically linked -not stripped > > This option prevents a s

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

> I tried bootstrapping the latest 4.0 revesion without luck. Suggest that you submit a GCC PR including the precise failure point, configure command, and preprocessed source if applicable. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Ca

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

> > gnat1: out of memory allocating 19028192 bytes after a total of 92324 bytes > > gmake[2]: *** [ada/ada.o] Error 1 My guess is that this is a problem with the bootstrap compiler. There is a known issue with all 3.3 releases that require compiling stage 1 with -O1. I think there's also a probl

Re: Storage for uninitialized objects (PR 24626)

> No, the ISO C standard is clear that the value of an uninitialized > variable is indeterminate. It may be a trap representation, or it may > be an unspecified value. In the latter case it must have the correct > type. But there is no other restriction on it, and the standard > specifically say

Re: [Ada] GCC 4.1 Status Report (2006-01-15)

> http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00833.html > hppa2.0w-hp-hpux11.11 has some cxg problems, but I don't > know if 4.0 worked at all there. A testsuite run with ada for 4.0.3 is here: http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00893.html. The run terminated before completing.

Re: Storage for uninitialized objects (PR 24626)

> > This seems pretty clear. C99 requires that storage be allocated > > > >for uninitialized objects, that an indeterminate value be stored > >in the object when the declarator for the object is reached in the > >block, that the last-stored value be retained for the duration of > >the block. > >

Re: Storage for uninitialized objects (PR 24626)

I've looked at the draft version of C99 that I have and it's clear that there are some significant differences between the draft that I have and the final. So, take what I say with a grain of salt ;) > I believe Dave's program results in undefined behavior by implication. > That is, even though C

Storage for uninitialized objects (PR 24626)

I have a question about storage for uninitialized objects. I made the mistake of looking at the code being generated for testcase #2 in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626. I noticed that reload used the same register r3 for the variables "call_result" and "node" after the call to af

Re: weakref miscompiling libgfortran

> > I still support a reverting of the weakref patch as it was put way too > > late > > for 4.1 (stage 3 is not a good idea for a new feature). > > Depends on if you consider it a new feature or a bug fix. >From my perspective, this patch introduced more bugs than it fixed: http://gcc.gnu.org/b

Re: SVN tags, branches and checkouts

> John David Anglin <[EMAIL PROTECTED]> wrote: > > > I find the documentation on checking out branches, particularly > > for branch releases, confusing. It doesn't say you need to use "tags" > > instead of "branches" for releases. > &g

SVN tags, branches and checkouts

I find the documentation on checking out branches, particularly for branch releases, confusing. It doesn't say you need to use "tags" instead of "branches" for releases. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (6

Re: GMP on IA64-HPUX

> On Mon, Dec 05, 2005 at 07:57:43AM -0800, Steve Ellcey wrote: > > > > > So, in short, my questions are: is gmp-4.1.4 supposed to work on > > > > > ia64-hpux? > > > > > > > > > > No, it is not. It might be possible to get either the LP64 or > > > > > the ILP32 ABI to work, but even that requi

Re: weakref and static

> Unfortunately, it can't do that; Mach-O (on Darwin) doesn't support > aliases in the object file at all, and even ELF doesn't support > aliases to symbols outside the current .o. The easiest solution to > this is to require that weakrefs must be 'static', because the name > that they define is n

Re: Successfull gcc-3.4.4 build on hppa1.1-hp-hpux10.20

> Thanks! Do you know if this includes pthreads support in C++? There's support for the older DCE threads in 10.X. This is dropped in 11.X, but there's POSIX thread support. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada

Re: Successfull gcc-3.4.4 build on hppa1.1-hp-hpux10.20

> Used full distribution + make bootstrap. Used egcs-2.91.57 and > binutils-2.11.2 to compile gcc. If you are interested in much improved C++ support, upgrade binutils to 2.16 or later and rebuild GCC with the new binutils. This provides one-only support under HP-UX 10.20. You also need the lat

Re: What systems (if any) have fprintf_unlocked?

> > I'm not going to be able to remember exactly. It might be worth > > looking at various proprietary Unixes to see if they've got > > fprintf_unlocked, but given the date I don't think I was looking at > > one of them. My best guess is that I simply assumed glibc had it, > > since it seeme

Re: GCC 4.0.1 RC3

PA is ok: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00223.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00218.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00186.html The failure of pr21817-1.c on hppa2.0w-hp-hpux11.11 is a minor testsuite issue that is now fixed on the tru

Re: Re: hpux regression vs 4.0.1

> > I have an hpux11.0 box available, and could run tests of your patch > > if you like. > I doubt it would have (or will make) much of a difference at this > point. I don't think anyone could have predicted the muck-up with > the arguments passed to ld and the re-bootstrap that had to run > after

Re: Libstdc++ versioning issues

> AFAICS, there are no problems whatsover, because version 3.4.5 is *new* > in 4.0.1. See . This is also . This is probably a bug in binutils but I don't have a warm fuzzy feeling about th

Re: Problems with collect2 on hpux

> > It's not very nice that the shared library list for libstdc++.sl > > includes libgcc_s.sl in the GCC build directory. I believe that the > > HP dynamic loader first looks for it there. If that doesn't work, > > it strips off the basename of the library and tries the dynamic > > search path. >

Re: Problems with collect2 on hpux

> The strange behaviour I'm seeing is that if I link my shared libraries > with -Wl,+s, then some of them work fine and find all of their libraries > based on the SHLIB_PATH settings. However, some of my libraries find > everything *except* libstdc++.sl from the SHLIB_PATH - these libraries >

Can't bootstrap trunk on hppa

gcc -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite- strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-v ariadic-macros -Wold-style-definition -fno-common -DHAVE_CONFIG_H -o cc1-dumm y c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pr

Re: GCC 3.4.4 RC2

> Please download, build, and test. I've now completed testing on the PA and don't see any major issues. The only easily fixable issue that showed up in testing was the failure of 26_numerics/complex/pow.cc under hpux 10.20. This fails because of a corner case in the 10.20 math library. The pro

Re: Help Required on HP-UX 11.0 & 11.11

> Our application (ebs) is giving this error when we run it on HP-UX . > #ebs > /usr/lib/dld.sl: Can't open shared library: libc.2 This is the wrong list for general HP-UX questions. Your application has not been correctly linked. Read the documentation for chatr and ld. The search path for the

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

> >> : build/genattrtab > >> /home/kate/gcc-4.0.0-20050410/src/gcc-4.0.0-20050410/gcc/config/rs6000/ > >> rs6000.md > tmp-attrtab.c > >> : > >> : out of memory allocating 12016 bytes after a total of 4161654476 bytes > > > > You need to increase the application limits for data on your system. >

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

> : build/genattrtab > /home/kate/gcc-4.0.0-20050410/src/gcc-4.0.0-20050410/gcc/config/rs6000/ > rs6000.md > tmp-attrtab.c > : > : out of memory allocating 12016 bytes after a total of 4161654476 bytes You need to increase the application limits for data on your system. That's what the above ra

Re: Bootstrap failure on i686-pc-linux-gnu since 2005-04-09 20:41UTC

> The patch has just been submitted to gcc-patches for > approval (the tests are nearly done and appear to > be passing so far). I'm travelling today, so I won't be able to test until tomorrow. Thanks, Dave -- J. David Anglin [EMAIL PROTECTED] National Research C

Re: call for testers!

> I guess cc1 does use this file, so comparing the two cc1 executables > would fail too; but does it work if -pipe is used? I added -pipe to t-pa and t-pa64 and this bootstraps successfully on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11, respectively. However, comparison of cc1 fails in both ca

Re: call for testers!

> That's probably a relative of the bug that occurs on Darwin. It ought > to be possible to avoid it by using -pipe in TARGET_LIBGCC2_CFLAGS; > could you try that? (I'd like to think that adding -pipe would always > be safe, but who knows what madness might lurk in the HPUX > assembler...) T

Re: HPUX/HPPA build broken (was Re: call for testers!)

> I didn't even have an old bootstrap of the trunk for HP-UX; I tried to do > one and it died with > > ./xgcc -B./ -B/u/jbuck/cvs.hp/trunk/hppa2.0w-hp-hpux11.00/bin/ -isystem > /u/jbuck/cvs.hp/trunk/hppa2.0w-hp-hpux11.00/include -isystem > /u/jbuck/cvs.hp/trunk/hppa2.0w-hp-hpux11.00/sys-include

Re: call for testers!

> I'd really appreciate it if people on unusual host systems (AIX, HPPA, > cygwin, etc.) could see what the effect of the patch in > is on their > bootstrap. I've gotten no responses at all, and I presume this means > that lots of peopl