Successfull build of gcc-3.3.6 on hppa2.0w-hp-hpux11.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Compiler version: 3.3.6 Platform: hppa2.0w-hp-hpux11.00 configure flags: --host=hppa2.0w-hp-hpux11.00 - --prefix=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install - --with-gnu-as - --with-as=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install/bin/as - --with-ld=/usr/ccs/bin/ld --enable-threads=single --disable-shared - --disable-nls --enable-languages=c,c++,objc,f77 binutils: binutils-2.16.1 Build system: HP-UX c3600-1 B.11.00 A 9000/785 unknown unknown HP-UX cc for building: gcc -mpa-risc-2-0 gcc (GCC) 3.3.6 Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. as for building: GNU assembler 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of \`hppa2.0w-hp-hpux11.00'. ld for building: 92453-07 linker command s800.sgs ld PA64 B.11.43 REL 050124 /usr/ccs/bin/ld: Usage: /usr/ccs/bin/ld [options] [flags] files /usr/ccs/bin/ld: 92453-07 linker linker ld B.11.43 050125 testresults: http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00056.html - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDGAdA3s6elE6CYeURAuhhAKDNNLZkaDc/rkGnbXDr/VGzfnawLwCgj46T HpwtQaXICtoFnF9I6fxQ1N0= =uN/e -END PGP SIGNATURE-
Re: [4.0] libgfortran/io/read.c:230: error: invalid storage class for function 'eat_leading_spaces'
Hi, I see the same failure on s390 and s390x. It is probably caused by one these patches. Bye, -Andreas- > 2005-09-01 Jakub Jelinek <[EMAIL PROTECTED]> > > PR c/23506 > * c-common.c (c_common_nodes_and_builtins): Increase builtin_types > array by one element, initialize the BT_LAST element with NULL. > > PR debug/7241 > * dwarf2out.c (base_type_die): Compare char_type_node with > TYPE_MAIN_VARIANT (type), not type. > > PR rtl-optimization/23478 > * regs.h (reg_info): Add throw_calls_crossed. > (REG_N_THROWING_CALLS_CROSSED): Define. > * flow.c (allocate_reg_life_data): Initialize > REG_N_THROWING_CALLS_CROSSED. > (propagate_one_insn, attempt_auto_inc): Update > REG_N_THROWING_CALLS_CROSSED. > * local-alloc.c (struct qty): Add n_throwing_calls_crossed field. > (alloc_qty): Initialize it. > (update_equiv_regs): Clear REG_N_THROWING_CALLS_CROSSED. > (combine_regs): Combine also n_throwing_calls_crossed fields. > (find_free_reg): Don't attempt to caller-save pseudos crossing > calls that might throw. > * global.c (struct allocno): Add throwing_calls_crossed field. > (global_alloc): Initialize throwing_calls_crossed. > (find_reg): Don't attempt to caller-save pseudos crossing calls that > might throw. > > 2005-08-31 Richard Henderson <[EMAIL PROTECTED]> > > * expr.c (expand_expr_real_1) : Force subregs > into a pseudo before applying gen_lowpart.
Successfull build of gcc-3.3.6 on mips-sgi-irix6.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Compiler version: 3.3.6 Platform: mips-sgi-irix6.5 configure flags: --host=mips-sgi-irix6.5 - --prefix=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install - --with-as=/usr/bin/as --with-ld=/usr/bin/ld --disable-shared - --enable-threads --enable-haifa --enable-libgcj --disable-c-mbchar - --enable-languages=c,c++,objc,f77 binutils: binutils-2.16.1 Build system: IRIX64 octane-3 6.5 10070055 IP30 mips unknown Irix cc for building: gcc gcc (GCC) 3.3.6 Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. as for building: MIPSpro Compilers: Version 7.2.1 ld for building: ld32: INFO 153: Version 7.2.1. ld32: INFO 46: No objects linked. testresults: http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00057.html The target unix/-mabi=32 produces hundreds of failed tests. I deleted the Details for this target, because the message exceeded the the limit of 40 bytes. - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDGAss3s6elE6CYeURAjhFAJ9H/+GIxta/IDPtePiPPlBpmxh8ygCgh4Dh 2HljRVDWZxr4wF6gVwiFvyI= =XKGK -END PGP SIGNATURE-
Re: [mainline/tree-profiling] CFG transparend finish_eh_generation
Jan, the following change of yours is responsible for PR21460. Can you
remember why you wanted to look for NOTE_INSN_BASIC_BLOCK?
I propose using this instead:
for (fn_begin = get_insns (); ; fn_begin = NEXT_INSN (fn_begin))
if (NOTE_P (fn_begin)
&& NOTE_LINE_NUMBER (fn_begin) == NOTE_INSN_FUNCTION_BEG)
break;
insert_insn_on_edge (seq, single_succ_edge (BLOCK_FOR_INSN (fn_begin)));
On Mon, Feb 23, 2004 at 12:00:41AM +0100, Jan Hubicka wrote:
> 2004-02-22 Jan Hubicka <[EMAIL PROTECTED]>
> * basic-block.h (make_eh_edge, break_superblocks): Declare.
> * cfgbuild.c (make_eh_edge): Make global.
> * cfglayout.c (break_superblocks): Likewise; fix memory leak.
> * except.c (build_post_landing_pads, connect_post_landing_pads,
> dw2_build_landing_pads, sjlj_emit_function_enter,
> sjlj_emit_function_exit, sjlj_emit_dispatch_table,
> sjlj_build_landing_pads): Update CFG.
> (finish_eh_generation): Do not rebuild the CFG.
[snip]
> *** sjlj_emit_function_enter (rtx dispatch_l
> *** 2107,2115
>
> for (fn_begin = get_insns (); ; fn_begin = NEXT_INSN (fn_begin))
> if (GET_CODE (fn_begin) == NOTE
> ! && NOTE_LINE_NUMBER (fn_begin) == NOTE_INSN_FUNCTION_BEG)
> break;
> ! emit_insn_after (seq, fn_begin);
> }
>
> /* Call back from expand_function_end to know where we should put
> --- 2146,2164
>
> for (fn_begin = get_insns (); ; fn_begin = NEXT_INSN (fn_begin))
> if (GET_CODE (fn_begin) == NOTE
> ! && (NOTE_LINE_NUMBER (fn_begin) == NOTE_INSN_FUNCTION_BEG
> ! || NOTE_LINE_NUMBER (fn_begin) == NOTE_INSN_BASIC_BLOCK))
> break;
> ! if (NOTE_LINE_NUMBER (fn_begin) == NOTE_INSN_FUNCTION_BEG)
> ! insert_insn_on_edge (seq, ENTRY_BLOCK_PTR->succ);
> ! else
> ! {
> ! for (; ; fn_begin = NEXT_INSN (fn_begin))
> ! if (GET_CODE (fn_begin) == NOTE
> ! && NOTE_LINE_NUMBER (fn_begin) == NOTE_INSN_FUNCTION_BEG)
> ! break;
> ! emit_insn_after (seq, fn_begin);
> ! }
> }
>
> /* Call back from expand_function_end to know where we should put
--
Alan Modra
IBM OzLabs - Linux Technology Centre
Re: -fprofile-generate and -fprofile-use
Hello, > > >you may try adding -fmove-loop-invariants flag, which enables new > > >invariant motion pass. > > > > That cleaned up both my simplified test case, and the code it > > originated from. It also cleaned up a few other cases where I > > was noticing worse performance with FDO enabled. Thanks!! > > > > Perhaps this option should be enabled by default when doing FDO > > to replace the loop invariant motions done by the recently > > disabled loop optimize pass. > > This sounds like sane idea. Zdenek, is -fmove-loop-invariants dangerous > in some way or just disabled because old loop does the same? -fmove-loop-invariants is enabled by default on killloop-branch, and passes bootstrap & regtesting on i686 and x86_64; the branch does not bootstrap for me on ia64 and ppc (but neither does mainline). I am not aware of any correctness/ICE problems with -fmove-loop-invariants, but given that it is disabled by default, this does not say much. Zdenek
Re: [mainline/tree-profiling] CFG transparend finish_eh_generation
On Fri, Sep 02, 2005 at 06:28:08PM +0930, Alan Modra wrote: > I propose using this instead: > > for (fn_begin = get_insns (); ; fn_begin = NEXT_INSN (fn_begin)) > if (NOTE_P (fn_begin) > && NOTE_LINE_NUMBER (fn_begin) == NOTE_INSN_FUNCTION_BEG) > break; > > insert_insn_on_edge (seq, single_succ_edge (BLOCK_FOR_INSN (fn_begin))); Oops, no, that doesn't work. I'll need to dig a bit to see what's happening. -- Alan Modra IBM OzLabs - Linux Technology Centre
Re: Regarding bug 22480, vectorisation of shifts
Hello Paolo!
> Heh, I'm quite at a loss regarding PR22480. I don't know exactly what
> to do because i386 does not support, e.g. { 2, 4 } << { 1, 2 } (which
> would give {4, 16} as a result). There is indeed a back-end problem,
> because ashl3 is supposed to have two operands of the same mode,
> not one vector and one SI!
>
I have changed a bit your proposed patterns:
--cut here--
(define_predicate "vec_shift_operand"
(and (ior (match_code "reg")
(match_code "const_vector"))
(match_test "GET_MODE_CLASS (mode) == MODE_VECTOR_INT"))
{
unsigned elt = GET_MODE_NUNITS (mode) - 1;
HOST_WIDE_INT ref;
if (GET_CODE (op) == CONST_VECTOR)
{
ref = INTVAL (CONST_VECTOR_ELT (op, elt));
while (--elt)
if (INTVAL (CONST_VECTOR_ELT (op, elt)) != ref)
return 0;
}
return 1;
})
(define_expand "ashl3"
[(set (match_operand:SSEMODE248 0 "register_operand" "")
(ashift:SSEMODE248
(match_operand:SSEMODE248 1 "register_operand" "")
(match_operand:SSEMODE248 2 "vec_shift_operand" "")))]
"TARGET_SSE2"
{
if (GET_CODE (operands[2]) == CONST_VECTOR)
operands[2] = CONST_VECTOR_ELT (operands[2], 0);
else
operands[2] = gen_lowpart (SImode, operands[2]);
})
(define_insn "sse_psll3"
[(set (match_operand:SSEMODE248 0 "register_operand" "=x")
(ashift:SSEMODE248
(match_operand:SSEMODE248 1 "register_operand" "0")
(match_operand:SI 2 "nonmemory_operand" "xi")))]
"TARGET_SSE2"
"psll\t{%2, %0|%0, %2}"
[(set_attr "type" "sseishft")
(set_attr "mode" "TI")])
--cut here--
>
> This however will not fix "a << b" shifts, which right now should (my
> guess) ICE with something similar to PR22480.
With above patterns, I tried to solve the a << b shifts. The proposed
solution is to generate a SImode lowpart out of SImode vector, to get
only element[0] value, in the hope that all elements are equal (this
is true for pr22480.c testcases).
For following testcase:
void
test_1 (void)
{
static unsigned bm[16];
int j;
for (j = 0; j < 16; j++)
bm[j] <<= 8;
}
void
test_2 (int a)
{
static unsigned bm[16];
int j;
for (j = 0; j < 16; j++)
bm[j] <<= a;
}
I was able to generate following code (gcc -O2 -msse2 -ftree-vectorize
-fomit-frame-pointer):
test_1:
movl$bm.1591, %eax
movl$bm.1591, %edx
.p2align 4,,15
.L2:
movdqa (%eax), %xmm0
addl$4, %edx
pslld $8, %xmm0
movdqa %xmm0, (%eax)
addl$16, %eax
cmpl$bm.1591+16, %edx
jne .L2
ret
test_2:
subl$28, %esp
movl$bm.1602, %eax
movl$bm.1602, %edx
movd32(%esp), %xmm0
pshufd $0, %xmm0, %xmm0
movdqa %xmm0, (%esp)
.p2align 4,,15
.L9:
movdqa (%eax), %xmm0
movd(%esp), %xmm1
addl$4, %edx
pslld %xmm1, %xmm0
movdqa %xmm0, (%eax)
addl$16, %eax
cmpl$bm.1602+16, %edx
jne .L9
addl$28, %esp
ret
A couple of (unrelated) problems can be also seen with above code.
First one is PR target/22479
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22497, where register is
wasted in a vectorised loop, the other problem is that movd is not
pushed out of the loop.
In this case, gcc should be able to optimize:
movd32(%esp), %xmm0
pshufd $0, %xmm0, %xmm0
movdqa %xmm0, (%esp)
...
movd(%esp), %xmm1
into
movd32(%esp), %xmm1
BTW: This change breaks gcc.dg/i386-sse-6.c, because a
__builtin_ia32_psllwi128 still calls ashl3 with integer
parameter. Otherwise there are no other regressions.
> By the way, it is time to remove the mmx_ prefix from the MMX insns!
Not yet... emms patch depends heavily on optimize_mode_switching
functionality, however o_m_s should be enhanced not to insert
switching insns into the loops.
Uros.
Re: Problem building 3.3.6 (with 3.4.4): xgcc: cannot specify -o with -c or -S and multiple compilations
Thanks for replies. For the sake of closure, I can now report (after a *lot* of work isolating the problem) that this was due to sed crashing randomly and unexpectedly during the gcc build since a kernel upgrade from 2.6.11.12 to 2.6.12.* Go figure; gcc builds fine when running 2.6.11.12 kernel; sed (and sometimes other tools like rm) crashes randomly during build when running newer kernel... (same .config, vanilla untainted kernels) I'm going to chase this down on LKML now. Sorry for the noise Andrew Walrond
gcc-4.1-20050902 is now available
Snapshot gcc-4.1-20050902 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050902/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 CVS branch with the following options: -D2005-09-02 10:43 UTC You'll find: gcc-4.1-20050902.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20050902.tar.bz2 C front end and core compiler gcc-ada-4.1-20050902.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20050902.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20050902.tar.bz2 C++ front end and runtime gcc-java-4.1-20050902.tar.bz2 Java front end and runtime gcc-objc-4.1-20050902.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20050902.tar.bz2The GCC testsuite Diffs from 4.1-20050826 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: MEM_NONTRAP_P and push/pop alias set (Was: Re: [attn port maintainers] fix 23671)
Richard Henderson wrote: As a practical short-term concern, rtx_addr_can_trap_p will not return true for any stack based reference, including push/pop. So for 4.1, nothing need be done. Longer term, the answer to the "what does notrap Actually, the SHcompact save / restores use neither stack nor frame pointer in their MEMs. a specific alias set. We already have gen_const_mem for readonly memory, so maybe that could be gen_pushpop_mem. I agree completely. This should be done before a lot of target code gets uglified. Hmm, I've just found we already have a get_frame_alias_set. So I'm working on a patch to for a new function get_frame_mem, which sets MEM_NOTRAP_P and sets the alias set to get_frame_alias_set (), and to use this in all the places of the target-independent code where get_frame_alias_set is currently used (unless the address looks fishy). There are many more places in the target-specific code, but I can't really test all the targets, so I'll leave patching that code up to the target maintainers.
[GCC 4.2 Project] Support for IA-64 speculation
Hello, I work on GCC for the Institute for System Programming in Russia. Below is a brief summary of the project aiming at adding support for ia64 speculation to the GCC instruction scheduler. I presented the project at the last GCC Summit. This description doesn't have any implementation details, but rather refers to the summit paper. If needed, I'd be happy to provide longer summary on the wiki page. I'll not be able to respond on your comments until next Tuesday. Regards, Andrey --- Support for IA-64 speculation Speculation is one of the features of IA-64 architecture aimed to expose instruction-level parralelism. Using speculation allows for a compiler to overcome the dependencies by moving a load through the ambiguous store or across a branch (with data and control speculation, respectively). This technique helps to hide the latency of memory loads and reduce the execution time. The patch adds support for both data and control speculation to the GCC instruction scheduler. Implementation issues of the patch are described in the paper 'Improving GCC instruction scheduler for IA-64', which can be found in the proceedings of GCC Summit 2005. Personnel Maxim Kuvyrkov, Andrey Belevantsev (Institute for System Programming, Russian Academy of Sciences) Delivery Date This project will be ready during the first stage of GCC 4.2. Benefits The patch improves SPEC FP on 2% (with -O2, as of May 2005). Aggressive inlining and loop unrolling help the patch to produce better results on SPEC INT. Detailed results are given in the abovementioned paper. Dependencies None. Modifications Required Target-independent parts of the patch modify the scheduler source files. A new flag and params are added for enabling and controlling speculation support. Target-dependent part includes new speculative instructions and pipeline descriptions in the ia64 backend, and ia64.c changes.
Re: Selective Mudflap
"Frank Ch. Eigler" <[EMAIL PROTECTED]> writes: > "Jon Levell" <[EMAIL PROTECTED]> writes: > > I'm trying to debug a large C application that (amongst other > > things) starts a JVM and uses Java's JDBC to connect to > > databases via JNI. [..] > > of errors (none from the JVM). I'd also like to use Mudflap however > > running the program with mudflap generates huge numbers of errors > > caused by the (uninstrumented) libjvm.so. [...] > > Do these errors arise from malloc-type operations performed by the > JVM? Or from your code's use of JVM-provided pointers? Sadly, there The errors stem from inside the JVM. I presume when it is using pointers that the C application has provided because it was't compiled with mudflap itself. (I'm new to mudflap but the violations claim to be of type "register"). > is no valgrind-style exclusion facility around. However, if the JVM > interface is used predominantly in one direction (C code calling into > the JVM), it may be possible to programatically turn off mudflap > enforcement when your code is about to jump into the jvm. Maybe There is quite a lot of interaction so for now I'll use a script to post-process the Mudflap report. Because Mudflap is OSS, if someone else doesn't do it first, I might at some point add some simple way to exclude violations but that won't be any time soon - things are hectic here at the moment. Thank you very much for your prompt response and for Mudflap, it seems to be a very clever piece of software. Jon.
Re: Selective Mudflap
Hi - On Fri, Sep 02, 2005 at 03:55:27PM +0100, Jon Levell wrote: > [...] > > Do these errors arise from malloc-type operations performed by the > > JVM? Or from your code's use of JVM-provided pointers? [...] > > The errors stem from inside the JVM. I presume when it is using > pointers that the C application has provided because it was't > compiled with mudflap itself. (I'm new to mudflap but the violations > claim to be of type "register"). [...] "register" operations occur when a new memory-resident object is made known to libmudflap. If it overlaps with another existing object, a "register" type error is indicated. Chances are that it is ordinary memory allocation performed by the JVM that is triggering the problem. Unfortunately, from what I recall, the JVM invocation interface does not include hooks to override the JVM's memory allocation primitives. That, coupled with libmudflap's weaknesses with multithreaded programs, makes this a difficult nut to crack. - FChE pgpbQlXCpPmhc.pgp Description: PGP signature
Re: Running ranlib after installation - okay or not?
ian@airs.com (Ian Lance Taylor) wrote on 01.09.05 in <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] (Kai Henningsen) writes: > > > [EMAIL PROTECTED] (Andrew Pinski) wrote on 31.08.05 in > > <[EMAIL PROTECTED]>: > > > > > If you consider Darwin "modern", then that statement is not correct > > > as moving/copying an archive on darwin, requires ranlib to be run. > > > > Is there a point to this behaviour? It sounds as if someone confused an > > archive with a nethack scorefile ... > > a.out archives used to work this way too, e.g. on SunOS 4. The idea > was that people would often use ar without updating the symbol table. > Thus the symbol table has a timestamp. The linker checks that the > timestamp of the symbol table is not older than the file modification > time of the archive. But then all you have to do is copy the timestamp, too. This sounded more like saving inode numbers and stuff ... I am, of course, accustomed to a cp that can copy timestamps. And I see that my install also has a -p option ... MfG Kai
Re: -fprofile-generate and -fprofile-use
Hi Janis, [EMAIL PROTECTED] (Janis Johnson) wrote on 01.09.05 in <[EMAIL PROTECTED]>: [quoteto.xps] > On Thu, Sep 01, 2005 at 11:45:35PM +0200, Steven Bosscher wrote: > > On Thursday 01 September 2005 23:19, girish vaitheeswaran wrote: > > > Sorry I still did not follow. This is what I > > > understood. During Feedback optimization apart from > > > the -fprofile-generate, one needs to turn on > > > -fmove-loop-invariants. > > > > You don't "need to". It just might help iff you are using a gcc 4.1 > > based compiler. > > > > > However this option is not > > > recognized by the gcc 3.4.4 or 3.4.3 compilers. What > > > am I missing? > > > > You are missing that > > 1) this whole thread does not concern gcc 3.4.x; and > > 2) the option -fmove-loop-invariants does not exist in 3.4.x. > > Girish started this thread about problems he is seeing with GCC 3.4.3 The discussion, maybe. The thread, definitely not - that was started by Peter Steinmetz (new subject, no References:). And it was explicitely about "using mainline": ] There was some discussion a few weeks ago about some apps running slower ] with FDO enabled. ... ] While this doesn't explain all of the degradations discussed (some were ] showing up on older versions of the compiler), it may explain some. MfG Kai
23667: Recent performance regression
Hi, this is just an heads-up: PR libstdc++/23667 is about a time-out, on slower machines of tr1/6_containers/unordered/hashtable/23465.cc. However, If I use together with the library an up to date compiler (either mainline or 4_0-branch), I'm able to appreciate the horrible slow-down of the generated code (1-2 orders of magnitude!) also on x86-linux. I believe a recent correct-ness fix introduced an unintented pessimization. In order to avoid seeing a spurious correctness regression in the logs (the testcase is in the correctness library testsuite, not in the performance one), I simplified the testcase, thus made it much faster, but now I see that the underlying issue is generic and very serious: in, say, 3-4 days, I will revert the change in case the slow-down will be still present. Thanks, Paolo.
Re: Running ranlib after installation - okay or not?
> "Andrew" == Andrew Pinski <[EMAIL PROTECTED]> writes: >> So I think the best way to address this is to not run ranlib. Andrew> If you consider Darwin "modern", then that statement is not correct Andrew> as moving/copying an archive on darwin, requires ranlib to be run. Can't we install the .a without changing its timestamp? E.g., 'install -p'. Tom
Re: Running ranlib after installation - okay or not?
[EMAIL PROTECTED] (Kai Henningsen) writes: > ian@airs.com (Ian Lance Taylor) wrote on 01.09.05 in <[EMAIL PROTECTED]>: > > > a.out archives used to work this way too, e.g. on SunOS 4. The idea > > was that people would often use ar without updating the symbol table. > > Thus the symbol table has a timestamp. The linker checks that the > > timestamp of the symbol table is not older than the file modification > > time of the archive. > > But then all you have to do is copy the timestamp, too. This sounded more > like saving inode numbers and stuff ... > > I am, of course, accustomed to a cp that can copy timestamps. And I see > that my install also has a -p option ... We're talking SunOS 4 here, which was just acting as earlier systems did. Back then the options to cp were -i, -f and -r. And install was a new fangled shell script that most packages didn't use. Ian
Re: Cross Compiler Unix - Windows
On Tue, Aug 30, 2005 at 10:19:36AM +0300, Kai Ruottu wrote: >Dave Korn wrote: >>>What becomes to Cygwin and MinGW, the same attitude as followed with >>>Linux, that "producing any apps for Windoze should happen only on >>>Windoze, or that when one does it on some other host, it still should >>>happen just like on Windoze!", is totally weird to me. >> >>It seems weird to me too. Especially considering that at least one of >>the main cygwin developers builds everything on linux with a >>linux-x-windows toolchain. So perhaps you have misunderstood the >>situation with cygwin; cross-development is certainly possible, and >>_intended_ to be possible. It certainly isn't any kind of policy to >>_deliberately_ make development only possible on native hosts. > >Recommending Cygwin for 'ordinary users' as the preferred place for >building GNU apps for Windoze, sounds weird. Just as doing the same >with MinGW/MSYS. The developers can have Linuces etc. better >platforms available and may require to produce everything for Linux >etc. first and for Windoze too... Only building can be enough, no >very hard testing or debugging in order to get the application to work >is expected... So, you think that when people need to build windows apps, the "recommendation" should be that people should buy a linux box, put their sources on the linux box, figure out where to get or how to build a cross compiler, build the sources, and then figure out how to transfer the sources to the windows platform. The alternative is to install Cygwin or MSYS and then just build your sources without worrying about linux, cross compilers, or how to transfer software to/from windows. Ever heard of Occam's razor? >This is quite the same as recommending people to build their own sport >cars from Volkswagens in garages instead of doing this in car factories >because only real Porches will be built in factories. People keep >their self-built cars there so of course these must be built there. Or >something... I have no idea what this analogy is trying to say but, again, recommending to people that they go out of their way not to build on the platform that they are targetting is clearly not the most straightforward or foolproof plan. >If one wants to produce tens of binutils, GCCs etc. GNU stuff for the >Windoze host, the native Windoze shouldn't be the recommendation. Not >at least when the recommendation comes from Red Hat or from any other >Linux company. If Red Hat delivers the Cygwin tools for only the >Windoze host, what else this is than a recommendation to use Windoze >instead of their own Linux for the Windoze target development? Huh? What does "Red Hat" have to do with anything? "Red Hat" doesn't provide the tools. Cygwin is a volunteer effort. The fact that you can build cross compilers from some other system to windows doesn't mean that Cygwin is at fault for not providing the cross compilers. The whole *point* of Cygwin is to provide a linux-like environment for Windows. The fact that I do build the cygwin release on linux doesn't mean that I'd recommend doing this to every person who wants to compile stuff for Windows. -- Christopher Faylor spammer? -> [EMAIL PROTECTED] Cygwin Co-Project Leader[EMAIL PROTECTED] TimeSys, Inc.
Re: Running ranlib after installation - okay or not?
ian@airs.com (Ian Lance Taylor) wrote on 02.09.05 in <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] (Kai Henningsen) writes: > > > ian@airs.com (Ian Lance Taylor) wrote on 01.09.05 in > > <[EMAIL PROTECTED]>: > > > > > a.out archives used to work this way too, e.g. on SunOS 4. The idea > > > was that people would often use ar without updating the symbol table. > > > Thus the symbol table has a timestamp. The linker checks that the > > > timestamp of the symbol table is not older than the file modification > > > time of the archive. > > > > But then all you have to do is copy the timestamp, too. This sounded more > > like saving inode numbers and stuff ... > > > > I am, of course, accustomed to a cp that can copy timestamps. And I see > > that my install also has a -p option ... > > We're talking SunOS 4 here, which was just acting as earlier systems > did. Back then the options to cp were -i, -f and -r. And install was > a new fangled shell script that most packages didn't use. Darwin isn't SunOS 4. MfG Kai
Language Changes in Bug-fix Releases?
Hi,
Since the creation of the GCC 4.0 branch back in February a number of
minor C++ language changes seem to have slipped in. Let me mention just
two examples:
1) With GCC 4.0.0 this code used to compile:
1 struct foo {
2 friend class bar;
3 void screw(bar&);
4 };
With GCC 4.0.1 it stopped compiling. From a language lawyer point of
view this is okay, since a friend declaration is not a declaration.
2) With GCC 4.0.1 this code used to compile:
1 struct lala {
2 void f() const {}
3 };
4 struct lulu {
5 template lulu(void (T::*)()) {}
6 };
7 lulu froobrazzz(&lala::f);
With current GCC 4.0 snapshot (4.0.2 20050901) it doesn't compile.
Again, the code was probably broken to begin with because the member
function argument in line 7 is a const member function for which the
parameter in the lulu ctor is not a match.
Are you really, really sure such language tightening is appropiate for
bug-fix releases? (Note that the examples above are not regressions since
gcc-3.4.y accept both of them.) This lead to developer irritation because
people expect that what compiled with GCC x.y.z should still compile with
GCC x.y.z+1. At least, that used to be my reading of the GCC Development
Plan [0].
What makes things really annoying is that some distributions use the
latest snapshot from the branch for their toolchain [1] (Hi Matthias!).
This results in packages suddenly refusing to build. Then, the upstream
maintainers get notified about this and are confused because it "works for
them" and it must be the silly distribution's fault...
Would it be insolent to ask you GCC developers to, please, refrain from
making pedantic changes to the language from GCC x.y.z to x.y.z+1 and keep
such changes for the major releases?
Cheers
-richy. (putting his asbestos suit on)
PS: Frankly, I've no idea what patches broke the two examples above.
If the breaking couldn't be avoided because something else had to
be fixed, then forget this email.
[0]
[1] I don't talk about distros that use the latest version from HEAD.
Screw them!
--
Richard B. Kreckel
Re: Cross Compiler Unix - Windows
So, you think that when people need to build windows apps, the "recommendation" should be that people should buy a linux box, put their sources on the linux box, figure out where to get or how to build a cross compiler, build the sources, and then figure out how to transfer the sources to the windows platform. The alternative is to install Cygwin or MSYS and then just build your sources without worrying about linux, cross compilers, or how to transfer software to/from windows. As the person who started this thread over 2 weeks ago, hopefully the thread can end here... The original question was asked because we are mostly a UNIX house and want to use Windows as little as possible... Hence the question "is it possible to build a Windows DLL without Windows at all" ... We currently use Cygwin for this which works just fine... but from our perspective the less Windows the better ... Thanks all for the helpful replies. Ivan
Re: Language Changes in Bug-fix Releases?
Richard B. Kreckel wrote: Hi, Since the creation of the GCC 4.0 branch back in February a number of minor C++ language changes seem to have slipped in. It's certainly not our intent to include such changes for their own sake. However, such changes to occur, usually in the course of fixing a regression of some kind. If the code in question is actually invald, as in your examples, then, no we do not worry about that. Trying to fix regressions while simultaneously preserving buggy, undocumented behavior is simply too hard. If you require the full behavior of a particular GCC release (including both its strengths and its weaknesses), then the only practical choice is to carry around that your release yourself. Regards, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
insv vs one-bit fields
Why are one-bit bitfields not allowed? I'm trying to support a BSET/BCLR pair that *only* support single bit fields, for I/O ports, which are always volatile (and thus you have to use insv, as gcc won't do a "or #1,port5" if port5 is volatile). if (HAVE_insv && GET_MODE (value) != BLKmode && !(bitsize == 1 && GET_CODE (value) == CONST_INT) So... why is it illegal to put a constant into a single bit field?
[RFH] C++ FE question
I've been looking at PR23708, where a non-inline explicitly
specialized template function is inheriting the inline semantics of
the inline member function it specializes, when using pre-compiled
headers (whew). This can be seen in the following example:
template class simple_class {
public:
inline void testfn (T);
};
template <> void simple_class::testfn (int) {} //
incorrectly inheriting 'inline' semantics when using PCH
Where the specialization function ends up in a COMDAT section.
I have some understanding on why this is happening, but could use a
little help in fixing the problem. If I compile the example above
into a precompiled header, the sequence of events is as follows:
simple_class::testfn is generated
simple_class::testfn is assigned to the COMDAT section by
note_decl_for_pch()
simple_class::testfn (implicit instantiation) is generated,
which inherits the COMDAT-ness from simple_class::testfn
simple_class::testfn (explicit specialization) is generated
simple_class::testfn (explicit specialization) is assigned to
the COMDAT section by duplicate_decls(), when it merges the
declarations with the implicit instantiation
When not using precompiled headers, the sequence is this:
simple_class::testfn is generated
simple_class::testfn (implicit) is generated
simple_class::testfn (explicit) is generated
simple_class::testfn is assigned to the COMDAT section
simple_class::testfn (implicit) is assigned to the COMDAT
section
My first approach was to modify duplicate_decls() so it wouldn't copy
the COMDAT-ness into the explicit specialization, the same way that
we avoid copying the DECL_DECLARED_INLINE_P. This worked for my
particular instance, however because COMDAT implementation is host-
dependent, it seems very dangerous.
My second approach is to disable the code in note_decl_for_pch() that
assigns COMDAT-ness early. This works, too, but it would be nice to
not lose the advantage that this code was put in for.
So, my third approach was to modify note_decl_for_pch() to filter out
simple_class::testfn, similarly to how the implicit
declaration is filtered out. However, in order to do so, I need to
detect that simple_class::testfn is a member function of a
template class. But how do I do this? I can detect which class the
function is a member of by looking at DECL_CONTEXT, but I don't see
how to determine if this class is a template class. Is there a way
to find the class type tree from the FUNCTION_DECL? I can get see
the type information I want at DECL_CONTEXT(decl)->common.chain in
the debugger, but I have no reason to believe that this is the
correct way to get it, or that it will work all of the time.
Does anyone have any suggestions on:
a) whether I'm headed in the right direction, and
b) if so, how to determine that simple_class::testfn is a member
of a template class, and not an instantiated class?
Thanks -
Josh
