Re: SMS in gcc4.0
Steven Bosscher <[EMAIL PROTECTED]> wrote on 22/04/2005 09:39:09: > > Thanks! > For the record, this refers to a patch I sent to Mostafa and Canqun to > do what Mostafa suggested last month to make SMS work for ia64, see > http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02848.html. I have tested the patch on powerpc-apple-darwin and there are some tests that started failing. So I am going to debug it to see what causes the failures. Mostafa. > > Gr. > Steven > >
Re: Targets using implicit extern "C"
On Sun, 2005-05-08 at 22:54 -0700, Zack Weinberg wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> > On Sun, 2005-05-08 at 21:34 -0700, Zack Weinberg wrote:
> >> Ralf Corsepius <[EMAIL PROTECTED]> writes:
> >>
> >> > FWIW: IMO, NO_IMPLICIT_EXTERN_C actually is an OS/libc feature ("Your
> >> > system headers are c++ aware"), therefore it is hardly possible or
> >> > useful to ever use "#define NO_IMPLICIT_EXTERN_C" on "generic" targets
> >> > (*-elf, *-coff etc.).
> >>
> >> I'm going to ask you to think again about that assessment, because
> >> 'implicit extern C' mode is actually trouble if the headers *are* C++
> >> aware
> >
> > The point is: You don't know, because you don't know which kind of
> > headers/libc is using a user is going to build gcc against.
>
> This is true. The question in my mind is which failure mode is worse,
> and honestly I don't know.
Neither do I.
My template answer to such kind of problems is
* Try to detect it with autoconf magic (Probably difficult to implement
for "multi-staged builds", may-be impossible for "one-tree builds")
* In cases detection isn't possible, fall back to "reasonable
defaults" (e.g. --with-newlib, *-rtems*, *-linux* could imply
-DNO_IMPLICIT_EXTERN_C)
* Additionally provide a configure option to enable users to override
autoconf-provided results.
Ralf
Re: Constant propagation and address arithmetic
On 5/8/05, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> Hi,
Hello,
> I have looked at the GCSE CPROP passes with CSE path following
> disabled ("-O1 -fgcse --param max-cse-path-length=1"). The input
> code are the cc1-i files from 20040726 (with checking enabled).
While that discussion flies way above my head, it seems to be about
gcse and i have enough grievance about it to jump in.
I've just pinged PR19680 (because it's still there) and just for the
sake of it i've tried the newly reported PR21463 with -fno-gcse and
it's quite interesting.
as reported, with gcse:
00400610 ::bar_ref(float, float)>:
400610: ucomiss 0x4(%rdi),%xmm1
400614: lea0x4(%rdi),%rax
400618: lea0xfff8(%rsp),%rdx
40061d: movss %xmm0,0xfffc(%rsp)
400623: movss %xmm1,0xfff8(%rsp)
400629: movaps %xmm1,%xmm2
40062c: cmova %rdx,%rax
400630: movss (%rax),%xmm1
400634: ucomiss %xmm1,%xmm0
400637: ja 400641 ::bar_ref(float, float)+0x31>
400639: lea0xfffc(%rsp),%rax
40063e: movaps %xmm0,%xmm1
400641: ucomiss (%rdi),%xmm2
400644: cmova %rdi,%rdx
400648: movss (%rdx),%xmm0
40064c: ucomiss %xmm0,%xmm1
40064f: jbe400655 ::bar_ref(float, float)+0x45>
400651: movss (%rax),%xmm0
400655: repz retq
without:
00400610 ::bar_ref(float, float)>:
400610: movss %xmm0,0xfffc(%rsp)
400616: lea0xfff8(%rsp),%rcx
40061b: lea0x4(%rdi),%rax
40061f: movss %xmm1,0xfff8(%rsp)
400625: lea0xfffc(%rsp),%rdx
40062a: ucomiss 0x4(%rdi),%xmm1
40062e: cmova %rcx,%rax
400632: ucomiss (%rax),%xmm0
400635: cmovbe %rdx,%rax
400639: ucomiss (%rdi),%xmm1
40063c: movss (%rax),%xmm0
400640: cmovbe %rcx,%rdi
400644: ucomiss (%rdi),%xmm0
400647: cmova %rax,%rdi
40064b: movss (%rdi),%xmm0
40064f: retq
Again, sorry for hijacking that thread, but gcse is a convenient
scapegoat for most of my performance/codegen problems and i'd like to
know if there's mid-term hope.
Regards,
Thierry.
Re: Targets using implicit extern "C"
On Mon, 9 May 2005, Ralf Corsepius wrote:
> FWIW: IMO, NO_IMPLICIT_EXTERN_C actually is an OS/libc feature ("Your
> system headers are c++ aware"), therefore it is hardly possible or
> useful to ever use "#define NO_IMPLICIT_EXTERN_C" on "generic" targets
> (*-elf, *-coff etc.).
You could apply that argument the other way round - adding implicit extern
"C" is a workaround of an OS misfeature and you can hardly say that
generic targets are for systems with that misfeature.
I'd argue that on a generic target the user takes responsibility for
ensuring the headers and libc are suitable for GCC, and if the user is
using C++ then this responsibility includes making sure the headers are
C++-aware.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)
RE: Targets using implicit extern "C"
Original Message
>From: Ralf Corsepius
>Sent: 09 May 2005 09:27
> On Sun, 2005-05-08 at 22:54 -0700, Zack Weinberg wrote:
>> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>>
>>> On Sun, 2005-05-08 at 21:34 -0700, Zack Weinberg wrote:
Ralf Corsepius <[EMAIL PROTECTED]> writes:
> FWIW: IMO, NO_IMPLICIT_EXTERN_C actually is an OS/libc feature ("Your
> system headers are c++ aware"), therefore it is hardly possible or
> useful to ever use "#define NO_IMPLICIT_EXTERN_C" on "generic" targets
> (*-elf, *-coff etc.).
I'm going to ask you to think again about that assessment, because
'implicit extern C' mode is actually trouble if the headers *are* C++
aware
>>>
>>> The point is: You don't know, because you don't know which kind of
>>> headers/libc is using a user is going to build gcc against.
>>
>> This is true. The question in my mind is which failure mode is worse,
>> and honestly I don't know.
> Neither do I.
>
> My template answer to such kind of problems is
> * Try to detect it with autoconf magic (Probably difficult to implement
> for "multi-staged builds", may-be impossible for "one-tree builds")
> * In cases detection isn't possible, fall back to "reasonable
> defaults" (e.g. --with-newlib, *-rtems*, *-linux* could imply
> -DNO_IMPLICIT_EXTERN_C)
> * Additionally provide a configure option to enable users to override
> autoconf-provided results.
>
> Ralf
Perhaps we could try and detect #ifdef _cplusplus guards at compiletime,
the same way we currently detect multiple include guards? i.e. For any
system header file that would be affected by NO_IMPLICIT_EXTERN_C being
undefined, we detect a sequence of lines that is exactly (modulo stripping
comments/whitespace)
#ifdef _cplusplus
extern "C" {
#endif
and turn off the effects of (!NO_IMPLICIT_EXTERN_C) for that file?
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: GCC 4.1: Buildable on GHz machines only?
On Sat, 2005-05-07 at 13:58, Andi Kleen wrote: > Tom Tromey <[EMAIL PROTECTED]> writes: > > > > Splitting up libgcj.so probably makes sense even for the Linux distro > > case (the one I am most concerned with at the moment), just so that > > apps that don't use AWT or Swing don't really pay for it. The > > Hmm? Unless you initialize AWT/swing in all programs that code > should never be paged in for non GUI programs. Ok in theory > if you use a random build order then a lot of pages could > contain GUI and non GUI code together, but that is probably > unlikely. > > The only reason to split it out would be to allow a libgcj > installation that is not dependent on the X11 libraries on the > RPM/dpkg/etc. level for small setups, but I am not sure how useful > that is anymore for most distributions. > > And perhaps to make the linking steps in the gcc build a bit > faster, but just for that it seems like a lot of work. Don't forget that the dynamic linker still has to do some relocation at load time. Not all platforms support pre-linking to mitigate this, and even those that do don't necessarily have it done on all shared libraries. The size of libgcj is such that it has non-trivial amounts of start up linking to do. If you then add in redundant X libraries that it pulls in for apps that don't need the graphics the overall effect can be significant. R.
Re: How can I write an empty conversion instruction
On Sat, 2005-05-07 at 04:14, Richard Henderson wrote: > On Fri, May 06, 2005 at 01:59:06PM -0700, Steve Ellcey wrote: > > I was wondering if anyone could tell me how to write an (empty) > > instruction pattern that does a truncate/extend conversion on a register > > 'in place'. > > > > All the conversions I see are like this one in ia64/ia64.md: > > > > (define_insn "extendsfdf2" > > [(set (match_operand:DF 0 "fr_register_operand" "=f") > > (float_extend:DF (match_operand:SF 1 "fr_register_operand" "f")))] > > "" > > "fnorm.d %0 = %1" > > [(set_attr "itanium_class" "fmac")]) > > > > Where the source and the destination may or may not be the same > > register. > > The best way is to have a post-reload splitter that splits the insn > into nothing at all. Is that really valid? I would have thought it would break the data flow. R.
unexpected speedup from gcc-4.1-20050508
Hello, after setting up the latest snapshot, i was caught off guard as all my numbers were off (and usually it's better than a swiss clock). So, i've double checked, stripped some cruft from compiler command line and pitted various snapshots (20050410, 20050424, 20050501) vs 20050508 in my app. Now i can say without doubt that on x86-64 linux, on a k8, i reliably get between >3% (rendering path, mostly vectorized SSE) and >5% (kd-tree compiler, branchy & memory heavy code) performance boost. Without touching a single line of code. I don't know, yet, who's the unsung hero i should thank or what he/she did, or if that result can be correlated in any other benchmark, but that won't stop me to send my warmest kudos his/her way. Feel free to fill in the blanks :) Regards.
GCSE considers read only memory clobbered by function calls.
It appears that GCSE considers "read only memory" as call clobbered, which
is not the case in CSE. I have took the test for read-only memory from CSE
and add it to GCSE where we compute the transparency. Here is a patch that
does so. This patch makes gcse eliminate redundant loads after stores for
the following example. The difference is seen when we compile with the
options:
"-O3 --param max-gcse-passes=3" with/without "-fgcse-las" (on a
powerpc-linux target). If this looks a reasonable change I will
regression-test and bootstrap the patch and ask for commit.
Example:
#define CALL_FPTR(fptr) (*fptr)
#define MY_FOO_CHECK() if (my_foo_var) my_foo_func()
int my_foo_var;
struct my_foo_struct {
int my_dummy_field;
int *(*ppaddr)(int);
};
struct my_foo_struct *my_foo_record;
int my_main_foo(int n)
{
while ((my_foo_record = CALL_FPTR(my_foo_record->ppaddr)(n))) {
MY_FOO_CHECK();
}
return 0;
}
The patch:
2005-05-09 Mostafa Hagog <[EMAIL PROTECTED]>
* gcse.c (compute_transp): use MEM_READONLY_P in case of MEM.
Index: gcse.c
===
RCS file: /cvs/gcc/gcc/gcc/gcse.c,v
retrieving revision 1.340
diff -c -p -r1.340 gcse.c
*** gcse.c 23 Apr 2005 21:27:44 - 1.340
--- gcse.c 5 May 2005 12:54:04 -
*** compute_transp (rtx x, int indx, sbitmap
*** 2470,2479
do any list walking for them. */
EXECUTE_IF_SET_IN_BITMAP (blocks_with_calls, 0, bb_index, bi)
{
! if (set_p)
! SET_BIT (bmap[bb_index], indx);
! else
! RESET_BIT (bmap[bb_index], indx);
}
/* Now iterate over the blocks which have memory modifications
--- 2470,2482
do any list walking for them. */
EXECUTE_IF_SET_IN_BITMAP (blocks_with_calls, 0, bb_index, bi)
{
! if (! MEM_READONLY_P (x))
! {
! if (set_p)
! SET_BIT (bmap[bb_index], indx);
! else
! RESET_BIT (bmap[bb_index], indx);
! }
}
Re: Use $(VARRAY_H) in dependencies?
On Monday 09 May 2005 03:55, Matt Kraai wrote: > On Sun, May 08, 2005 at 07:31:38PM -0700, Matt Kraai wrote: > > On Mon, May 09, 2005 at 03:03:23AM +0100, Paul Brook wrote: > > > On Monday 09 May 2005 02:26, Matt Kraai wrote: > > > > Howdy, > > > > > > > > The rules for c-objc-common.o, loop-unroll.o, and tree-inline.o > > > > include $(VARRAY_H), which is never defined, in their dependency > > > > lists. The rest of the targets that depend on varray.h include > > > > varray.h in their dependency list. > > > > > > > > varray.h includes machmode.h, system.h, coretypes.h, and tm.h, so > > > > Makefile.in should define and use VARRAY_H, right? > > > > > > Already one step ahead of you :-) > > > > > > 2005-05-07 Paul Brook <[EMAIL PROTECTED]> > > > > > > * Makefile.in: Fix dependencies. > > > (GCOV_IO_H, VARRAY_H): Set. > > > > Great. > > The dependencies for the rules for build/genautomata.o, > build/varray.o, and gtype-desc.o still include varray.h instead of > $(VARRAY_H). Is this on purpose? If so, why? That's a oversight. My dependency checking script obviously doesn't check those entries. Paul
compiling cross-compiler
Hi there, I'm to compile an x86->powerpc cross-gcc (using uclibc). I have the following error message: | In file included from /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/powerpc-linux-uclibc/nof/libstdc++-v3/include/bits/codecvt.h:475, | from /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/powerpc-linux-uclibc/nof/libstdc++-v3/include/bits/locale_facets.h:1537, | from /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/powerpc-linux-uclibc/nof/libstdc++-v3/include/locale:46, | from /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/libstdc++-v3/src/codecvt.cc:30: /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/powerpc-linux-uclibc/nof/libstdc++-v3/include/powerpc-linux-uclibc/bits/codecvt_specializations.h:52: error: `iconv_t' does not name a type (see a fuller log below) I had a somewhat older source and it did not have this problem. In that source codecvt_specializations.h is an almost empty file. Is this change a recent modification of gcc code? What does it aim? Character code conversion? And, of course: is there any workaround to compile gcc-cross? Should this go to gcc-bugs? - Gergely | /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/gcc/xgcc -shared-libgcc -B/opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/gcc/ -nostdinc++ -L/opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/powerpc-linux-uclibc/nof/libstdc++-v3/src -L/opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/powerpc-linux-uclibc/nof/libstdc++-v3/src/.libs -B/opt/oe2/powerpc-tmp/cross/powerpc-linux-uclibc/bin/ -B/opt/oe2/powerpc-tmp/cross/powerpc-linux-uclibc/lib/ -isystem /opt/oe2/powerpc-tmp/cross/powerpc-linux-uclibc/include -isystem /opt/oe2/powerpc-tmp/cross/powerpc-linux-uclibc/sys-include -msoft-float -fPIC -mstrict-align -I/opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/powerpc-linux-uclibc/nof/libstdc++-v3/include/powerpc-linux-uclibc -I/opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/powerpc-linux-uclibc/nof/libstdc++-v3/include -I/opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/libstdc++-v3/libsupc++ -g -Os -g -Os -msoft-float -fPIC -mstrict-align -fno-implicit-templates -Wall -W -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -c /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/libstdc++-v3/src/codecvt.cc -fPIC -DPIC -o .libs/codecvt.o | In file included from /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/powerpc-linux-uclibc/nof/libstdc++-v3/include/bits/codecvt.h:475, | from /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/powerpc-linux-uclibc/nof/libstdc++-v3/include/bits/locale_facets.h:1537, | from /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/powerpc-linux-uclibc/nof/libstdc++-v3/include/locale:46, | from /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/libstdc++-v3/src/codecvt.cc:30: | /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/powerpc-linux-uclibc/nof/libstdc++-v3/include/powerpc-linux-uclibc/bits/codecvt_specializations.h:52: error: `iconv_t' does not name a type | /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/powerpc-linux-uclibc/nof/libstdc++-v3/include/powerpc-linux-uclibc/bits/codecvt_specializations.h:64: error: `__desc_type' does not name a type | /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/powerpc-linux-uclibc/nof/libstdc++-v3/include/powerpc-linux-uclibc/bits/codecvt_specializations.h:66: error: `__desc_type' does not name a type | /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/powerpc-linux-uclibc/nof/libstdc++-v3/include/powerpc-linux-uclibc/bits/codecvt_specializations.h:170: error: expected `;' before '*' token | /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/powerpc-linux-uclibc/nof/libstdc++-v3/include/powerpc-linux-uclibc/bits/codecvt_specializations.h:174: error: expected `;' before "const" | /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-linux.powerpc-linux-uclibc/powerpc-linux-uclibc/nof/libstdc++-v3/include/powerpc-linux-uclibc/bits/codecvt_specializations.h:174: error: expected `;' before '*' token | /opt/oe2/powerpc-tmp/work/gcc-cross-3.4.3-r10/gcc-3.4.3/build.i686-lin
Full comparison in 'cbranchsi4' leads to error in gcc 4.0
Hi, I am porting gcc (version 4.0) to a CPU supporting conditional jumps, which does not have a CC register. I have combined the comparision and jump operation in the definition of "cbranchsi4" as show at the end of this message. This works fine on gcc 3.4, however on gcc 4.0 it creates an error during optimization. According to my investigation, the error occurs when there is a division by a constant power of 2 which needs to be transformed into shifting. The error generated is: internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:3599 The definition of cbranchsi4 in the machine-description: (define_insn "cbranchsi4" [(set (pc) (if_then_else (match_operator 0 "comparison_operator" [(match_operand:SI 1 "register_operand" "r") (match_operand:SI 2 "nonmemory_operand" "r")]) (label_ref (match_operand 3 "" "")) (pc)))] "" "c%C0jump %1 %2 %3" [(set_attr "type" "branch") (set_attr "length" "1")] ) Regards, Sami Khawam The University of Edinburgh http://www.see.ed.ac.uk/~sxk
Re: gcc-4.0 non-local variable uses anonymous type warning
James E Wilson wrote:
William S Fulton wrote:
test.cxx:15: warning: non-local variable ‘::
::Instance’ uses anonymous type
Just grepping the sources for the warning, I find this comment
/* [basic.link]: A name with no linkage (notably, the name of a class
or enumeration declared in a local scope) shall not be used to
declare an entity with linkage.
Only check this for public decls for now. */
Also this:
/* DRs 132, 319 and 389 seem to indicate types with
no linkage can only be used to declare extern "C"
entities. Since it's not always an error in the
ISO C++ 90 Standard, we only issue a warning. */
static enum { foo, bar = 10 } Instance;
The "public decls" comment above means that we deliberately don't emit
the warning for static variables, but it is possible this may change in
the future. It may depend on how the defect reports get resolved.
I'm not a C++ expert, and don't have a copy of the C++ standard, so I
can't comment further.
Interesting, thanks James. Indeed, the warning disappears when the enum
declaration is made extern "C" and that is good enough for me :)
William
Re: GCSE considers read only memory clobbered by function calls.
On Mon, 2005-05-09 at 17:45 +0300, Mostafa Hagog wrote: > > > > It appears that GCSE considers "read only memory" as call clobbered, which > is not the case in CSE. I have took the test for read-only memory from CSE > and add it to GCSE where we compute the transparency. Here is a patch that > does so. This patch makes gcse eliminate redundant loads after stores for > the following example. The difference is seen when we compile with the > options: > "-O3 --param max-gcse-passes=3" with/without "-fgcse-las" (on a > powerpc-linux target). If this looks a reasonable change I will > regression-test and bootstrap the patch and ask for commit. > [ ... ] Yes, it looks quite reasonable. Please go ahead with the full testing cycle and consider the patch pre-approved once complete. jeff
Re: GCSE considers read only memory clobbered by function calls.
It appears that GCSE considers "read only memory" as call clobbered, which is not the case in CSE. I have took the test for read-only memory from CSE and add it to GCSE where we compute the transparency. My wild guess is that this was not possible when MEM_READONLY_P was RTX_UNCHANGING_P, and now it is. Paolo
Re: building gcc 4.0.0 on Solaris
Hi, As far as I can understand, it's not possible to build gcc 4.0.0 and gcc 3.4.* using GNU binutils with current release 2.15 of GNU binutils. One has to use the CVS sources or at least one file. FYI binutils-2.16 has just been released. You might want to try that. I have installed binutils-2.16. Things work better in the sense that I get much farther into building the Java libraries. I still hit a problem: [...] ar rc .libs/libgcj0_convenience.a [... around 100.000 characters ...] internal error: error_message(58) [...] Is this a known issue? I guess I should be using GNU's ar instead of Sun's /usr/ccs/bin/ar which is probably as much an antique as my version as/ld. It's not the first time I see Sun tools choke on very long command lines, so that may be the problem here, that or running out of memory: $ ar -V ar: Software Generation Utilities (SGU) Solaris-ELF (4.0) [...] $ Is there any way to tell the build process to use GNU ar instead of /usr/ccs/bin/ar? Would having /usr/ccs/bin in the PATH *after* GNU binutils actually be enough? -- Dimitri Papadopoulos
Re: Mail. Mail! Mail?
References: <427E8378.1010309 at brenda-arkle dot demon dot co dot uk><873bsxbclc.fsf at codesourcery dot com><20050508225133.GA2890 at dementia dot proulx dot com><87r7gh9tmq.fsf at codesourcery dot com> Apologies if this has lost its "References" field - it shouldn't have done, but off-hand I can't work out how to verify it. Hence the line above (with mildly obfuscated addresses) My system has developed, for hysterical reasons, as a minimal installation of GNU/Linux on a P4. Minimal really was minimal - no networking, no X... Everything else has been added on demand. I managed to get my networking running with no problems without ever encountering mail, Mail, mailx, or any version of sendmail. Don't blame the distribution - but surely I'm not alone in my position? Nice as it is to know that "mailx" is what I wanted, and it is easily available, the docs didn't say "mailx", they said "Mail". "Mail" was unhelpful (I wasn't helped), and "mail" would not have been better. And, yes, I was misconstruing "sendmail" as referring to the Configuration Monster from Hell. Doubtless "an experienced Unix person" would not have been in this position, but that's not a great deal of help to me. Zack and Bob, however, *have* been helpful (thanks to both of you!), and in my darker and more cynical moments I suspect them of being experienced Unix persons themselves. The mere absence of Mail/sendmail wasn't the essence of my problem. A solution "by hand" was still possible. When feeding the script output to `sh' failed, I could (and did) spool it to a file instead, from which I could extract the inline data. The difficulty was rather that I couldn't find what executables I was expected to be using. This in turn introduced an unnecessary element of guesswork into the solution "by hand", which was bothering me. I didn't want to be sending junk to the mailing list. Now I know what I'm supposed to have been doing, the rest is relatively straightforward. Special system restrictions may make it impracticable to install the expected tools, but this is really a red herring. Can something be done to make the problem less obstructive? It's not obvious that the script should try to be too clever and work out which name to use. Mail looks as useful as any name it can have hard-coded. However, a comment could be added to the script *output*; something like if ! [ -x "`which Mail`" ]; then echo Modify the script, or set up a symlink, to use \`mailx\' echo if \`Mail\' doesn\'t exist: mailx and \`Mail\' should be echo synonyms. If neither is present, \`mail\' might work. echo mail from GNU mailtools should work. exit fi if ! [ -x /usr/sbin/sendmail ]; then echo This script may fail if \`/usr/sbin/sendmail\' is not available, echo depending on the version of \`Mail\' being used. echo This is NOT the very large MTA whose home is at echo http://www.sendmail.org. echo You may need to set up a symlink to an equivalent program. echo mail.remote from GNU mailtools should work. fi and it can be mentioned in the docs: something like You must have Mail in your path: Mail is (or can be made to be) an alias for mailx, which you should have. This requires /usr/sbin/sendmail, which is NOT the huge MTA from http://www.sendmail.org but something much smaller. GNU mailutils include versions of both, which will need to be renamed/linked. -- "Before they made me, they broke the mould" Bernard Leak
Re: How can I write an empty conversion instruction
On Mon, May 09, 2005 at 12:40:48PM +0100, Richard Earnshaw wrote: > > The best way is to have a post-reload splitter that splits the insn > > into nothing at all. > > Is that really valid? I would have thought it would break the data flow. Obviously you only split to nothing when the registers match. But we don't have mode correspondence between successive register apperances after reload. r~
Re: How can I write an empty conversion instruction
On Mon, 2005-05-09 at 17:11, Richard Henderson wrote: > On Mon, May 09, 2005 at 12:40:48PM +0100, Richard Earnshaw wrote: > > > The best way is to have a post-reload splitter that splits the insn > > > into nothing at all. > > > > Is that really valid? I would have thought it would break the data flow. > > Obviously you only split to nothing when the registers match. > But we don't have mode correspondence between successive register > apperances after reload. > > > r~ So do we fully recreate *all* the flow information before a scheduling pass?
Re: GCSE considers read only memory clobbered by function calls.
On Mon, May 09, 2005 at 05:45:24PM +0300, Mostafa Hagog wrote:
> EXECUTE_IF_SET_IN_BITMAP (blocks_with_calls, 0, bb_index, bi)
> {
> ! if (! MEM_READONLY_P (x))
Looks like you should push this check here:
case MEM:
if (!MEM_READONLY_P (x))
{
...
}
x = XEXP (x, 0);
goto repeat;
r~
Re: How can I write an empty conversion instruction
On Mon, May 09, 2005 at 05:26:10PM +0100, Richard Earnshaw wrote: > So do we fully recreate *all* the flow information before a scheduling > pass? Yes. r~
gcc 4.0.0 build on RH Enterprise 4
i686-pc-linux-gnu Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0.0/configure --prefix=/opt/gcc-4.0.0 Thread model: posix gcc version 4.0.0 Red Hat Enterprise Linux ES release 4 (Nahant) Linux snoopdog 2.6.9-5.0.3.EL #1 Mon Feb 14 09:52:18 EST 2005 i686 i686 i386 GNU/Linux glibc-2.3.4-2
Re: Mail. Mail! Mail?
Bernard Leak wrote: [in reply to why by default an MTA should be installed in order to be able to send reports in the usual way] Special system restrictions may make it impracticable to install the expected tools, but this is really a red herring. Hmm... Installing an MTA, whatever its size may be, has the potential of introducing more work, more open ports, more firewall building, more following the associated securitiy advisories absent a firewall or not absent a firewall, more ... The optimistic (wrt opennes of the network) default installation settings of GNU/Linux distributions for example do not always reflect the default installation policy in every network. But typical mail sending programs can speak SMTP themselves, without the help of a local MTA. As much as I like to assume that GNUnix comes with (send)mail, an installation might thus have left them out for good reasons. In this case a hint like "c&p the report into a plain text message" or somesuch might really be helpful. Or a WWW report collector with a file upload input field? -- Georg
Re: Mail. Mail! Mail?
Georg Bauhaus <[EMAIL PROTECTED]> writes: > Installing an MTA, whatever its size may be, has the potential > of introducing more work, more open ports, more firewall building, > more following the associated securitiy advisories absent a firewall > or not absent a firewall, more ... Not at all. All modern MTAs can be configured, quite easily, in a 'dumb client' mode where they accept mail only from the local host -- they don't even open a network socket -- and forward all that mail to a designated 'smart hub'. (Terminology varies.) There are even programs, such as sSMTP and nullmailer, which have *only* this functionality. zw
Re: Mail. Mail! Mail?
Bernard Leak <[EMAIL PROTECTED]> writes: > My system has developed, for hysterical reasons, as a minimal > installation of GNU/Linux on a P4. Minimal really was minimal - no > networking, no X... Everything else has been added on demand. I > managed to get my networking running with no problems without ever > encountering mail, Mail, mailx, or any version of sendmail. Don't > blame the distribution - but surely I'm not alone in my position? Interesting. I would have expected you to have trouble with cron, which likes sending mail - or maybe you skipped it, too? > Zack and Bob, however, *have* been helpful (thanks to both of you!), > and in my darker and more cynical moments I suspect them of being > experienced Unix persons themselves. Aheh, yes, you could say that. > Can something be done to make the problem less obstructive? > It's not obvious that the script should try to be too clever and > work out which name to use. Mail looks as useful as any name > it can have hard-coded. However, a comment could be added > to the script *output* [... more useful suggestions ...] This is where I quietly mention that patches are welcome. zw
Re: Mail. Mail! Mail?
Zack Weinberg wrote: All modern MTAs can be configured, quite easily, in a 'dumb client' mode where they accept mail only from the local host -- Well, "easily" is arguable if you aren't a Unix sysadmin, and depending on the MTA... There are even programs, such as sSMTP which, not a month ago had bugs causing overflow vulnerability. ;-) and nullmailer, which have *only* this functionality. Good Thing, and improving. However, be sure to add a procedure to your network monitoring setup to inform you of risky bugs in network related software. And this is where work starts to be caused by the assumption that e.g. a GCC shell script can send reports using the Mail program using an MTA possibly involving inetd, ... -- Georg
Re: Mail. Mail! Mail?
Zack Weinberg wrote: > The gcc test result script (via Mail) expects the /usr/sbin/sendmail > interface, but not Allman's implementation. You can install whatever > mail transport agent you prefer. > Again, not having an MTA installed indicates a monumental error in the > packaging or installation of your OS. There is at least one serious distribution which has considered having no /usr/sbin/sendmail (or mailx) in a default installation: http://lists.ubuntu.com/archives/ubuntu-devel/2005-February/004207.html -M-
Re: Mail. Mail! Mail?
Matthew Woodcraft <[EMAIL PROTECTED]> writes: > There is at least one serious distribution which has considered having no > /usr/sbin/sendmail (or mailx) in a default installation: > > http://lists.ubuntu.com/archives/ubuntu-devel/2005-February/004207.html What a horrible idea. It's not just about LSB compliance - programs shouldn't have to implement their own SMTP senders, they should be able to rely on /usr/sbin/sendmail. (I personally go even farther, and consider any program [other than a dedicated MTA] which contains its own SMTP sender, rather than relying on /usr/sbin/sendmail, to be buggy.) This is no longer on-topic for gcc@, though. zw
Mainline bootstrap broken in varasm.c
Mainline bootstrapped fine on 6 May 05. It is broken today with ./xgcc -B./ -B/usr/home/sgk/work/41/amd64-unknown-freebsd6.0/bin/ -isystem /usr/home/sgk/work/41/amd64-unknown-freebsd6.0/include -isystem /usr/home/sgk/work/41/amd64-unknown-freebsd6.0/sys-include -L/usr/home/sgk/gcc/obj41/gcc/../ld -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc41/gcc -I../../gcc41/gcc/. -I../../gcc41/gcc/../include -I./../intl -I../../gcc41/gcc/../libcpp/include -I/usr/local/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time \ -c ../../gcc41/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o ../../gcc41/gcc/crtstuff.c:332: internal compiler error: in named_section_real, at varasm.c:425 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. I suspect the problem arose with this commit 2005-05-08 Julian Brown <[EMAIL PROTECTED]> H.J. Lu <[EMAIL PROTECTED]> Paul Brook <[EMAIL PROTECTED]> -- Steve
Re: Mail. Mail! Mail?
Georg Bauhaus <[EMAIL PROTECTED]> writes: > Good Thing, and improving. However, be sure to add a procedure > to your network monitoring setup to inform you of risky bugs in network > related software. And this is where work starts to be caused by > the assumption that e.g. a GCC shell script can send reports > using the Mail program using an MTA possibly involving inetd, ... If you prefer you can do telnet relay smtp instead. :-) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
GCC 4.0.0 Performance Regressions?
Is anybody collecting information on performance regressions in 4.0.0 (vs.
3.4.3)? I've got some results on POVRAY and BYTEmark, and BYTEmark saw some
performance regression, particularly with profiled optimization
(-fprofile-{generate,use}):
http://forums.gentoo.org/viewtopic-t-329765.html
I looked at the Bugzilla bug posting guidelines, but I don't know how to
boil this down to a tight testcase that fits those guidelines... and most of
what I saw in Bugzilla pertained to actual breakage anyway.
I'm willing to help out with this if I can get some pointers on what would
be useful to you--and if I can get the time away from my Real Work(TM) to
fiddle with this...
Jason B.
--
"My interest is in the future; I am going to spend the rest of my life
there."
-- Charles Kettering
Re: Mainline bootstrap broken in varasm.c
Steve Kargl wrote: Mainline bootstrapped fine on 6 May 05. It is broken today with ./xgcc -B./ -B/usr/home/sgk/work/41/amd64-unknown-freebsd6.0/bin/ -isystem /usr/home/sgk/work/41/amd64-unknown-freebsd6.0/include -isystem /usr/home/sgk/work/41/amd64-unknown-freebsd6.0/sys-include -L/usr/home/sgk/gcc/obj41/gcc/../ld -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc41/gcc -I../../gcc41/gcc/. -I../../gcc41/gcc/../include -I./../intl -I../../gcc41/gcc/../libcpp/include -I/usr/local/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time \ -c ../../gcc41/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o ../../gcc41/gcc/crtstuff.c:332: internal compiler error: in named_section_real, at varasm.c:425 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. I suspect the problem arose with this commit 2005-05-08 Julian Brown <[EMAIL PROTECTED]> H.J. Lu <[EMAIL PROTECTED]> Paul Brook <[EMAIL PROTECTED]> Probably; so, if you submit preprocessed source, etc., that will probably help. I'm pretty sure that patch was bootstraped on x86_64-unknown-linux-gnu, so it's probably something freebsd-ish. I can volunteer Julian to look into it, once you file a full report. :-) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: GCC 4.0.0 Performance Regressions?
Jason Bucata <[EMAIL PROTECTED]> wrote:
> Is anybody collecting information on performance regressions in 4.0.0
> (vs.
> 3.4.3)? I've got some results on POVRAY and BYTEmark, and BYTEmark
> saw some performance regression, particularly with profiled
> optimization (-fprofile-{generate,use}):
> http://forums.gentoo.org/viewtopic-t-329765.html
You should try and isolate a single BYTEmark test which shows the biggest
regression. It's better if you manage to pack the whole test as a single
preprocessed source file. Theoretically, this file should be compilable and
linkable, and the resulting binary should run for a while doing computations.
With this kind of help, we can analyze the regression and see why it's slower
with 4.0.0.
Giovanni Bajo
Re: Questions about a constant array reference in the C++ front end
Kazu Hirata wrote:
Hi,
I have two questions about the C++ front end.
Consider a C++ program
static const int array[] = { 0, 0, 0, 1, 1, 1, 2, 2, 2 };
int
foo (int a)
{
return array[7];
}
I am trying to fold array[7] into 2. It turns out that if T is an
ARRAY_REF,
TREE_READONLY (TREE_OPERAND (T, 0))
is 0. Why? This would be 1 if the program is fed into the C front
end, which is needed to safely fold a constant array reference.
That's a bug, or, rather, a place where the C++ front-end is failing to
give full information to the optimizer. It should be TREE_READONLY.
There are some tricky bits, in that if we're doing a dynamic
initialization, we presently cannot mark it TREE_READONLY, but this is a
static initialization, so it should be fine. Isn't TREE_OPERAND (T, 0)
the VAR_DECL for array itself? If so, waht's probably going wrong is
that it's not being marked TREE_READONLY because we're afraid of the
dynamic initialization case. We're missing a call to
c_apply_quals_to_decl (sp?) somewhere.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Re: Questions about a constant array reference in the C++ front end
> Mark Mitchell writes:
>> Kazu Hirata wrote:
>> ...
>> static const int array[] = { 0, 0, 0, 1, 1, 1, 2, 2, 2 };
>>
>> int
>> foo (int a)
>> {
>> return array[7];
>> }
>>
>> I am trying to fold array[7] into 2. It turns out that if T is an
>> ARRAY_REF,
>>
>> TREE_READONLY (TREE_OPERAND (T, 0))
>>
>> is 0. Why? This would be 1 if the program is fed into the C front
>> end, which is needed to safely fold a constant array reference.
>
> That's a bug, or, rather, a place where the C++ front-end is failing to give
> full information to the optimizer. It should be TREE_READONLY. There are some
> tricky bits, in that if we're doing a dynamic initialization, we presently
> cannot mark it TREE_READONLY, but this is a static initialization, so it
> should be fine. Isn't TREE_OPERAND (T, 0) the VAR_DECL for array itself? If
> so, waht's probably going wrong is that it's not being marked TREE_READONLY
> because we're afraid of the dynamic initialization case. We're missing a call
> to c_apply_quals_to_decl (sp?) somewhere.
- ??? no such thing, you can't "dynamically" initialize a "static const",
as then it's not a "static const", but rather simply a global "const"
(as a "static const" object is logically equivalent to a named/addressable
literal, yes?)
Re: Questions about a constant array reference in the C++ front end
Paul Schlie wrote: - ??? no such thing, you can't "dynamically" initialize a "static const", as then it's not a "static const", but rather simply a global "const" (as a "static const" object is logically equivalent to a named/addressable literal, yes?) No, it's not. static const int i = f(); -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Mainline bootstrap broken in varasm.c
On Mon, May 09, 2005 at 05:03:23PM -0700, Mark Mitchell wrote: > Steve Kargl wrote: > > > >I suspect the problem arose with this commit > > > >2005-05-08 Julian Brown <[EMAIL PROTECTED]> > >H.J. Lu <[EMAIL PROTECTED]> > >Paul Brook <[EMAIL PROTECTED]> > > Probably; so, if you submit preprocessed source, etc., that will > probably help. I'm pretty sure that patch was bootstraped on > x86_64-unknown-linux-gnu, so it's probably something freebsd-ish. > > I can volunteer Julian to look into it, once you file a full report. :-) > Julian already sent my a patch, which did not fix the problem. Additionally, I think the patch that caused the problem was committed by Nathan. Julian just happen to commit a patch to varasm.c two commits after Nathan. See PR bootstrap/21481. -- Steve
Re: Mainline bootstrap broken in varasm.c
Steve Kargl wrote: On Mon, May 09, 2005 at 05:03:23PM -0700, Mark Mitchell wrote: Steve Kargl wrote: I suspect the problem arose with this commit 2005-05-08 Julian Brown <[EMAIL PROTECTED]> H.J. Lu <[EMAIL PROTECTED]> Paul Brook <[EMAIL PROTECTED]> Probably; so, if you submit preprocessed source, etc., that will probably help. I'm pretty sure that patch was bootstraped on x86_64-unknown-linux-gnu, so it's probably something freebsd-ish. I can volunteer Julian to look into it, once you file a full report. :-) Julian already sent my a patch, which did not fix the problem. Additionally, I think the patch that caused the problem was committed by Nathan. Julian just happen to commit a patch to varasm.c two commits after Nathan. See PR bootstrap/21481. OK, thanks. I'm sure Nathan will look at it, come morning in the UK. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Questions about a constant array reference in the C++ front end
> From: Mark Mitchell <[EMAIL PROTECTED]> >> Paul Schlie wrote: >> - ??? no such thing, you can't "dynamically" initialize a "static const", >> as then it's not a "static const", but rather simply a global "const" >> >> (as a "static const" object is logically equivalent to a named/addressable >>literal, yes?) > > No, it's not. > > static const int i = f(); Admittedly didn't think that was legal, as I though all "static const" initializer values needed to be resolvable at compile time, directly or indirectly from literal values by the front-end, or otherwise invalid.
Re: Questions about a constant array reference in the C++ front end
> From: Paul Schlie <[EMAIL PROTECTED]> >> From: Mark Mitchell <[EMAIL PROTECTED]> >>> Paul Schlie wrote: >>> - ??? no such thing, you can't "dynamically" initialize a "static const", >>> as then it's not a "static const", but rather simply a global "const" >>> >>> (as a "static const" object is logically equivalent to a named/addressable >>>literal, yes?) >> >> No, it's not. >> >> static const int i = f(); > > Admittedly didn't think that was legal, as I though all "static const" > initializer values needed to be resolvable at compile time, directly or > indirectly from literal values by the front-end, or otherwise invalid. So then more accurately, MEM_READONLY_P is only "true" for references to: - "static const" objects which are equated to a literal initializer. - or an arbitrary literal value which has not been in-lined into the code, as it's either too large to be done efficiently, or may be referenced indirectly via a pointer. (is this essentially correct?)
Re: Questions about a constant array reference in the C++ front end
Hi Mark, > That's a bug, or, rather, a place where the C++ front-end is failing > to give full information to the optimizer. It should be > TREE_READONLY. There are some tricky bits, in that if we're doing a > dynamic initialization, we presently cannot mark it TREE_READONLY, > but this is a static initialization, so it should be fine. Isn't > TREE_OPERAND (T, 0) the VAR_DECL for array itself? Yes, if T is an ARRAY_REF, TREE_OPERAND (T, 0) is the VAR_DECL for the array itself. > If so, waht's probably going wrong is that it's not being marked > TREE_READONLY because we're afraid of the dynamic initialization > case. We're missing a call to c_apply_quals_to_decl (sp?) > somewhere. Thank you for the function name. I might dig into the C++ front end. Anyway, I filed this "bug" as PR 21454, saying that the contents of a "completely static" array ends up in the .data section, not the .rodata. It turned out to be a regression from 3.x. Kazu Hirata
GCC 3.4.4 near-freeze
I've gone through the GCC 3.4 PRs. I'm going to make a final push tonight to get a few of the C++ PRs fixed, and then I'm going to declare a freeze. If that seems short notice, I previously announced last May 7th as the freeze date, so you've already had more time than you could have expected. :-) So, if you've got 3.4.x patches that you want to get in, work quick. After the freeze, and before the release, I'll likely approve only patches to fix wrong-code bugs. FYI, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Questions about a constant array reference in the C++ front end
Paul Schlie <[EMAIL PROTECTED]> writes: >> From: Mark Mitchell <[EMAIL PROTECTED]> >> static const int i = f(); > > Admittedly didn't think that was legal, as I though all "static const" > initializer values needed to be resolvable at compile time, directly or > indirectly from literal values by the front-end, or otherwise invalid. In C what you say is true; in C++ initializers may execute arbitrary code. zw
Validating a C++ back-end
Hi, I am working on a fresh C++ port and I am filling in all the machine specific hooks. How do I run the C++ testsuite on my compiler? I am familiar with the GCC torture/execute tests and have my backend passing those tests reasonably well. Now, I am looking for something similar for C++ to test my support for the language's features. I am a bit confused by how the Deja Gnu tests are organized. I see that the testsuite contains a lot of different tests of which, some are compile only tests, some are pre-processor tests etc. Aren't the "runnable" tests the main kind that I should be interested in? Given a compiler version of 3.x.x shouldn't I be able to rely on test results run on the generic portions by the GCC maintainers themselves and worry about only the runnable tests? Is there a specific/sufficient list of tests that I need to validate...? Please let me know if I am missing something... thanks, Vasanth
GCC 3.4.4 Froze
GCC 3.4.4 is now slushy. All non-documentation patches require my explicitly approval. 3.4.4 RC1 will be building overnight. FYI, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
