Re: New option: -fstatic-libgfortran
Philippe Schaffnit wrote: Sorry about the (possibly off) question: would this apply also to GMP/MPFR, if not, wouldn't it make sense? It wouldn't make sense -- GMP and MPFR are never linked into the compiled output at all. (They're only used within the compiler itself, for processing constant values and suchlike, and then the results from that are put in the compiled file.) - Brooks
Re: New option: -fstatic-libgfortran
Oops! Thanks a lot for your reply. Philippe Brooks Moses wrote: > > Philippe Schaffnit wrote: > > Sorry about the (possibly off) question: would this apply also to > > GMP/MPFR, if not, wouldn't it make sense? > > It wouldn't make sense -- GMP and MPFR are never linked into the > compiled output at all. (They're only used within the compiler itself, > for processing constant values and suchlike, and then the results from > that are put in the compiled file.) > > - Brooks
Re: New option: -fstatic-libgfortran
Sorry about the (possibly off) question: would this apply also to GMP/MPFR, if not, wouldn't it make sense? GMP and MPFR are host libraries, so it is actually an independent issue. However, it might be worth having --with-static-gmp and --with-static-mpfr to request static linking of these libraries into the compiler. I think I suggested the idea (maybe even a patch, but I can't find it in the mailing-list archives) when gmp/mpfr was still only used by Fortran. In the end, some people will think it's stretching the configury too much for a specific purpose, and some people will think it's just a good option to have. (I'm in the second group.) Let's wait and see what people think of the idea. FX
Bonsoir
Bonsoir monsieur, je viens par ce mail solliciter votre aide pour l'exécution d'une transaction financière. J'aimerais investir dans l'immobilier ou un domaine prospère dans votre pays que vous pourrez me conseiller. J'ai sept millions cinq cents mille dollars américains ($7,500,000.00 US) que je voudrais investir et je vous donnerai généreusement 15% de toute la somme en contre partie de votre aide en recevant les fonds sur votre compte dans votre pays.Veuillez s'il vous plait me contacter immédiatement à mon adresse email ([EMAIL PROTECTED]) pour davantage d'explications. En attendant votre réponse immédiate. Respectueusement. Mlle Simone ADOU
Re: GCC mini-summit - compiling for a particular architecture
On 4/23/07, Diego Novillo <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote on 04/23/07 14:40: > Any references? Yes, at the last HiPEAC conference Grigori Fursin presented their interactive compilation interface, which could be used for this. http://gcc-ici.sourceforge.net/ That work is part of an European project called MilePost. We will present at the summit a part of this ongoing work, see the abstract: http://www.gccsummit.org/2007/view_abstract.php?content_key=37 Another related presentation at the summit is that of Haiping Wu: http://www.gccsummit.org/2007/view_abstract.php?content_key=9 Sebastian
Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
Hi everyone,
Although I'm seeing this on 3.3.3, it appears to be determined by the
backend, so I think it's still reasonable to ask:
I have some code that calls __builtin_ffs, but entirely on compile-time
constants. When I compile it (using an inhouse custom ELF-target backend)
with -O2, it gets totally optimised away, but the compiler still emits an
undefined symbol reference to the library ffs() function:
--
/tmp $ ${libexecdir}/3.3.3/cc1.exe -O2 - -o -
int foo ()
{
return __builtin_ffs (32);
}
.file ""
foo.global _ffs
.text
.align 2
.proc _foo
.global _foo
.type _foo, @function
_foo:
addir1,r0,0x6
jr r15
.endproc _foo
.size _foo, .-_foo
.ident "GCC: (GNU) 3.3.3 (artimi-1.19)"
--
When I retarget the same gcc at x86/cygwin, no such reference is emitted:
--
/tmp $ /repository/gcc-build/gcc-x86/gcc/cc1.exe-O2 - -o -
int foo ()
{
return __builtin_ffs (32);
}
.file ""
foo.text
.p2align 4,,15
.globl _foo
.def_foo; .scl2; .type 32; .endef
_foo:
pushl %ebp
movl$6, %eax
movl%esp, %ebp
popl%ebp
ret
--
Does anyone know off the top of their head if this is simply a side-effect
of the fact that i386.md supplies an rtl insn for ffs, where my custom target
doesn't? Or is it perhaps an elf-vs-PE difference? I couldn't find anything
to explain this behaviour in the manual.
I can kind-of work around it by tricking the compiler into thinking
__builtin_ffs can be elided (as no body is ever required by a static
inline[*])
--
/tmp $ ./cc1.exe -O2 - -o -
static inline int __builtin_ffs (int);
int foo ()
{
return __builtin_ffs (32);
}
.file ""
foo
.text
.align 2
.proc _foo
.global _foo
.type _foo, @function
_foo:
; 010
; frame size 0: local_vars_size 0 out_args_size 0 pretend_args_size 0
; mul_save_size 0 gpr_save_size 0 lr_save_ 0 iar_save_ 0 fp_save_ 0
addir1,r0,0x20
j ___builtin_ffs ; sibcall_value insn ;
.endproc _foo
.size _foo, .-_foo
?
:1: warning: `__builtin_ffs' used but never defined
.ident "GCC: (GNU) 3.3.3 (artimi-1.19)"
--
but that leaves me with an ugly warning. Does anyone know a better way to
eliminate the undefined reference? (I'm currently just supplying a dummy
version of _ffs() in my source solely in order to satisfy the linker).
cheers,
DaveK
[*] - before the recent changes for C99 compatibility, of course!
--
Can't think of a witty .sigline today
Re: New option: -fstatic-libgfortran
On Tue, Apr 24, 2007 at 10:55:56AM +0200, François-Xavier Coudert wrote: > >Sorry about the (possibly off) question: would this apply also to > >GMP/MPFR, if not, wouldn't it make sense? > > GMP and MPFR are host libraries, so it is actually an independent > issue. However, it might be worth having --with-static-gmp and > --with-static-mpfr to request static linking of these libraries into > the compiler. I think I suggested the idea (maybe even a patch, but I > can't find it in the mailing-list archives) when gmp/mpfr was still > only used by Fortran. > > In the end, some people will think it's stretching the configury too > much for a specific purpose, and some people will think it's just a > good option to have. (I'm in the second group.) Let's wait and see > what people think of the idea. I just keep this local patch. H.J. --- gcc/Makefile.in.gmp 2006-05-19 06:23:09.0 -0700 +++ gcc/Makefile.in 2006-05-19 13:20:17.0 -0700 @@ -295,7 +295,7 @@ ZLIB = @zlibdir@ -lz ZLIBINC = @zlibinc@ # How to find GMP -GMPLIBS = @GMPLIBS@ +GMPLIBS = -Wl,-Bstatic @GMPLIBS@ -Wl,-Bdynamic GMPINC = @GMPINC@ CPPLIB = ../libcpp/libcpp.a
bitfield handling on m68k broken
Hi,
Something broke the bitfield handling recently and before I delve deeper
into it, I'm hoping someone admits guilt. :)
This is taken from execute/20040709-1.c:
struct K { unsigned int k : 6, l : 1, j : 10, i : 15; };
struct K retmeK (struct K x)
{
return x;
}
This produces the following code:
retmeK:
link.w %fp,#0
move.l %d3,-(%sp)
move.l %d2,-(%sp)
clr.l %d0
move.l 8(%fp),%d1
bfextu %d1{#7:#10},%d3
bfextu %d1{#17:#15},%d2
bfins %d2,%d0{#17:#15}
bfins %d3,%d0{#7:#10}
-> moveq #26,%d2
lsr.l %d2,%d1
bfins %d1,%d0{#0:#7}
move.l (%sp)+,%d2
move.l (%sp)+,%d3
unlk %fp
rts
The problem here is that the shift is off by one. The copying of the k/l
field is already wrong when it gets to the RTL phase:
(insn 11 10 13 3 (set (subreg:SI (reg:QI 32 [ x$B0F7 ]) 0)
(zero_extract:SI (reg/v:SI 35 [ x ])
(const_int 7 [0x7])
(const_int 0 [0x0]))) -1 (nil)
(nil))
(insn 15 14 16 3 (set (subreg:SI (reg:QI 36) 0)
(zero_extract:SI (subreg:SI (reg:QI 32 [ x$B0F7 ]) 0)
(const_int 7 [0x7])
(const_int 24 [0x18]))) -1 (nil)
(nil))
(insn 16 15 17 3 (set (zero_extract:SI (reg:SI 33 [ D.1548 ])
(const_int 7 [0x7])
(const_int 0 [0x0]))
(subreg:SI (reg:QI 36) 0)) -1 (nil)
(nil))
The offset of 24 in insn 15 is wrong. I'm not that familiar with the tree
optimizers, so I'm hoping for some help.
Even without this bug gcc usage of bitfield instruction has become a
little insane lately, e.g. 2.95/3.4 produce this code:
retmeK:
link.w %a6,#0
move.l 8(%a6),%d0
unlk %a6
rts
How can I get this back? In general bitfield instructions are a bit more
expensive, they are ok for extracting integer values when needed, but for
simply copying values like this it's overkill, what makes this worse is
that the rtl optimizers can often do as much with this (and in combination
with subreg it's not getting better...)
I'd be willing to look into this, but I need a little help here.
Thanks.
bye, Roman
Re: bitfield handling on m68k broken
Hi, On Tue, 24 Apr 2007, I wrote: > simply copying values like this it's overkill, what makes this worse is > that the rtl optimizers can often do as much with this (and in combination ^ not > with subreg it's not getting better...) This should make more sense... bye, Roman
Difference in DWARF Info generated by GCC 3.4.6 and GCC 4.1.1
Hi all,
I am working with GCC 4.1.1, I need some clarification for the DWARF
information generated by this sample Program,
#include
int fun(const char*, ...);
/* Variadic function */
int fun(const char *raj,...)
{
return 9;
}
int main()
{
fun("Hello world",3,2);
return 0;
}
For the sample program given above, the assembly code generated is:
/*
SP -> Stack Pointer
FP -> Frame Pointer
RP -> Return Address Regnum
*/
.LC0:
.string "Hello world"
_main:
stwd FP, -(SP)
stwd RP, -(SP)
move SP, FP End of Func Prologue >>>
move .LC0, D0 // Location of "Hello World"
saved in D0 for variable 'raj'
move 3, D1
move 2, D2
jump _fun
move 0, D0
ldwd (SP)+, RP
ldwd (SP)+, FP
ret
_fun:
stwd D3, -(SP)
stwd D2, -(SP)
stwd D1, -(SP)
stwd D0, -(SP)// Location of .LC0 - Hello World
stwd FP, -(SP)
move SP, FP End of Func Prologue >>>
move 9, D0
ldwd (SP)+, FP
add 16, SP
ret
The frame base pointer in the DIE entry for _fun is taken as stack
pointer. Looking at the generated assembly for _fun,
stwd D0, -(SP)// Location of .LC0 - Hello World - variable 'raj'
stwd FP, -(SP)
after storing .LC0 (D0) in stack, the SP is decremented and FP is
stored. So the base offset with respect to SP for the variable raj is
4. But when looked at the debug output, the offset is zero.
# Readelf O/P for 4.1.1 ##
1><103>: Abbrev Number: 6 (DW_TAG_subprogram)
DW_AT_sibling : <12e>
DW_AT_external: 1
DW_AT_name: fun
DW_AT_decl_file : 10
DW_AT_decl_line : 7
DW_AT_prototyped : 1
DW_AT_type: <53>
DW_AT_low_pc : 0
DW_AT_high_pc : 0x14
DW_AT_frame_base : 1 byte block: 5f (DW_OP_reg15) [Stack Pointer]
<2><11e>: Abbrev Number: 7 (DW_TAG_formal_parameter)
DW_AT_name: raj
DW_AT_decl_file : 10
DW_AT_decl_line : 6
DW_AT_type:
DW_AT_location: 2 byte block: 91 0 (DW_OP_fbreg: 0)
###
Can any one point out what is going wrong here? The above program is
working properly with GCC 3.4.6.
Regards,
Rohit
On 16 Apr 2007 10:04:25 -0700, Ian Lance Taylor <[EMAIL PROTECTED] > wrote:
"Rohit Arul Raj" <[EMAIL PROTECTED]> writes:
> 1. In DIE for fun, with 3.4.6, the frame base is taken in terms of
> Frame Pointer (DW_OP_reg14), where is in 4.1.1, it is taken in terms
> of Stack Pointer (DW_OP_reg15).
>
> (For my backend, reg-no 14 is Frame Pointer and reg-no 15 is Stack Pointer)
>
> Is this the expected behavior?
It's correct if it matches the generated code. It is possible that
gcc 4.1.1 was able to eliminate the frame pointer in a case where gcc
3.4.6 was not.
> 2. For the variable, const char *raj, the DIE for 3.4.6 has the
> location mentioned as (fbreg + 4 [offset] ) whereas for 4.1.1,
> location is mentioned as (fbreg + 0).
>
> Any specific reason for this behavior in GCC 4.1.1
Again, it is presumably reflecting the generated code.
Ian
Re: bitfield handling on m68k broken
Roman Zippel <[EMAIL PROTECTED]> writes:
> This is taken from execute/20040709-1.c:
>
> struct K { unsigned int k : 6, l : 1, j : 10, i : 15; };
> struct K retmeK (struct K x)
> {
> return x;
> }
>
> This produces the following code:
>
> retmeK:
> link.w %fp,#0
> move.l %d3,-(%sp)
> move.l %d2,-(%sp)
> clr.l %d0
> move.l 8(%fp),%d1
> bfextu %d1{#7:#10},%d3
> bfextu %d1{#17:#15},%d2
> bfins %d2,%d0{#17:#15}
> bfins %d3,%d0{#7:#10}
> -> moveq #26,%d2
> lsr.l %d2,%d1
> bfins %d1,%d0{#0:#7}
> move.l (%sp)+,%d2
> move.l (%sp)+,%d3
> unlk %fp
> rts
The code generated by 4.3.0 20070122 still looks correct.
> Even without this bug gcc usage of bitfield instruction has become a
> little insane lately, e.g. 2.95/3.4 produce this code:
>
> retmeK:
> link.w %a6,#0
> move.l 8(%a6),%d0
> unlk %a6
> rts
FWIW, I get this very code with 4.3.0 20070122 when compiling without
optimisation.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
"Dave Korn" <[EMAIL PROTECTED]> writes:
> Although I'm seeing this on 3.3.3, it appears to be determined by the
> backend, so I think it's still reasonable to ask:
>
> I have some code that calls __builtin_ffs, but entirely on compile-time
> constants. When I compile it (using an inhouse custom ELF-target backend)
> with -O2, it gets totally optimised away, but the compiler still emits an
> undefined symbol reference to the library ffs() function:
>
> --
> /tmp $ ${libexecdir}/3.3.3/cc1.exe -O2 - -o -
>
> int foo ()
> {
> return __builtin_ffs (32);
> }
>
> .file ""
> foo.global _ffs
Is this really a reference? It just looks like a declaration. A
typical ELF assembler will not generate an undefined symbol merely
because it sees a .global pseudo-op.
It looks like this comes from an inappropriate call to
assemble_external. You should find out what is calling that for _ffs.
Ian
Re: What's the status of autovectorization for MMX and 3DNow!?
"Uros Bizjak" <[EMAIL PROTECTED]> дÈëÏûÏ¢ÐÂÎÅ:[EMAIL PROTECTED] > Hello! > >> I'm particularly interested in this patch >> (http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01128.html); pretty > nice for >> users of Pentium 3 and Athlon. Has it been or will it be integrated into >> mainline? > > This patch heavily depends on the functionality of optimize mode > switching pass. Unfortunatelly, there is currently no way to tell > optimize_mode_switching() which modes are exclusive. Due to the way how > the emms switching patch was designed, it expects that either MMX or X87 > mode can be active at once, to properly switch between x87 and MMX > registers. > > PR target/19161 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161) > comment #17 has an example of the control flow that can block both > register sets at once. Otherwise, the patch works as expected. Sorry to dig this old thing old, but will u continue to work on this once the problem you mentioned above gets resolved? And what about 3DNow! support? Just curious:-) -- Zuxy
Re: Where is gstdint.h
[EMAIL PROTECTED] wrote: Tim Prince wrote: [EMAIL PROTECTED] wrote: Where is gstdint.h ? Does it acctually exist ? libdecnumber seems to use it. decimal32|64|128.h's include decNumber.h which includes deccontext.h which includes gstdint.h When you configure libdecnumber (e.g. by running top-level gcc configure), gstdint.h should be created, by modifying . Since you said nothing about the conditions where you had a problem, you can't expect anyone to fix it for you. If you do want it fixed, you should at least file a complete PR. As it is more likely to happen with a poorly supported target, you may have to look into it in more detail than that. When this happened to me, I simply made a copy of stdint.h to get over the hump. This might happen when you run the top level gcc configure in its own directory. You may want to try to make a new directory elsewhere and run configure there. pwd .../my-gcc-source-tree mkdir ../build cd ../build ../my-gcc-source-tree/configure make If you're suggesting trying to build in the top level directory to see if the same problem occurs, I would expect other problems to arise. If it would help diagnose the problem, and the problem persists for a few weeks, I'd be willing to try it. Tim you cleared this one up earlier, the gstdint.h was in the build tree after all. Aaron
RE: Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
On 24 April 2007 15:34, Ian Lance Taylor wrote:
> "Dave Korn" writes:
>
>> Although I'm seeing this on 3.3.3, it appears to be determined by the
>> backend, so I think it's still reasonable to ask:
>>
>> I have some code that calls __builtin_ffs, but entirely on compile-time
>> constants. When I compile it (using an inhouse custom ELF-target backend)
>> with -O2, it gets totally optimised away, but the compiler still emits an
>> undefined symbol reference to the library ffs() function:
>>
>> --
>> /tmp $ ${libexecdir}/3.3.3/cc1.exe -O2 - -o -
>>
>> int foo ()
>> {
>> return __builtin_ffs (32);
>> }
>>
>> .file ""
>> foo.global _ffs
>
> Is this really a reference? It just looks like a declaration. A
> typical ELF assembler will not generate an undefined symbol merely
> because it sees a .global pseudo-op.
It could well be an assembler issue then, but yes, it certainly ends up as a
type 'U' symbol in the output object. (I was fooled by that seeming label
'foo' at the start of the .global line; in fact, that's an artefact of
outputting to the console, it comes from stderr not stdout.)
> It looks like this comes from an inappropriate call to
> assemble_external. You should find out what is calling that for _ffs.
Thanks, I will take a look.
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
> > .file "" > > foo.global _ffs > > Is this really a reference? It just looks like a declaration. A > typical ELF assembler will not generate an undefined symbol merely > because it sees a .global pseudo-op. I think gas 2.17 counts as a "typical ELF assembler". It does create undefined symbols in response to a .global pseudo-op. There was a patch to the c++ frontend recently to avoid a similar problem with EH personality routines. Paul
RE: Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
On 24 April 2007 15:50, Dave Korn wrote:
> On 24 April 2007 15:34, Ian Lance Taylor wrote:
>> It looks like this comes from an inappropriate call to
>> assemble_external. You should find out what is calling that for _ffs.
Heh, surely you mean "You should find out what is calling that, ffs"! ;-)
> Thanks, I will take a look.
Didn't take long, and seems to show immediately what the problem is:
Continuing.
Breakpoint 2, assemble_external (decl=0x7ff08a40) at
/tools/external_source/gnu/gcc-3.3.3/gcc/varasm.c:1712
(gdb) bt
#0 assemble_external (decl=0x7ff08a40) at
/tools/external_source/gnu/gcc-3.3.3/gcc/varasm.c:1712
#1 0x00417828 in build_external_ref (id=0x7ff32800, fun=1) at
/tools/external_source/gnu/gcc-3.3.3/gcc/c-typeck.c:1453
#2 0x00405f24 in yyparse () at c-parse.y:615
#3 0x0040b699 in c_common_parse_file (set_yydebug=0) at
/tools/external_source/gnu/gcc-3.3.3/gcc/c-lex.c:159
#4 0x00449808 in toplev_main (argc=5, argv=0xd38ca8) at
/tools/external_source/gnu/gcc-3.3.3/gcc/toplev.c:2142
#5 0x0044437a in main (argc=5, argv=0xd38ca8) at
/tools/external_source/gnu/gcc-3.3.3/gcc/main.c:35
(gdb) call debug_tree (decl)
unit size
align 32 symtab 0 alias set -1 precision 32 min max
pointer_to_this >
DI
size
unit size
align 32 symtab 0 alias set -1
arg-types
chain >>>
readonly nothrow public external built-in SI file line 0
built-in BUILT_IN_NORMAL:BUILT_IN_FFS attributes
(mem:SI (symbol_ref:SI ("ffs")) [0 S4 A32]) chain >
Looking at the comments:
1700/* Output something to declare an external symbol to the
assembler.
1701 (Most assemblers don't need this, so we normally output
nothing.)
1702 Do nothing if DECL is not external. */
1703
1704void
1705assemble_external (decl)
1706 tree decl ATTRIBUTE_UNUSED;
- 1707{
1708 /* Because most platforms do not define ASM_OUTPUT_EXTERNAL,
the
1709 main body of this code is only rarely exercised. To
provide some
1710 testing, on all platforms, we make sure that the
ASM_OUT_FILE is
1711 open. If it's not, we should not be calling this
function. */
and the internals manual:
`ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME)'
A C statement (sans semicolon) to output to the stdio stream
STREAM any text necessary for declaring the name of an external
symbol named NAME which is referenced in this compilation but not
defined. The value of DECL is the tree node for the declaration.
This macro need not be defined if it does not need to output
anything. The GNU assembler and most Unix assemblers don't
require anything.
I'd say that I've inherited a thinko-fied version of ASM_OUTPUT_EXTERNAL that
is emitting a .global directive when it should be emitting a .extern (or, as
the Fine Manual says, just not bothering at all since I'm using GAS). Thanks
for the well-tuned hint!
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: bitfield handling on m68k broken
Hi,
On Tue, 24 Apr 2007, Andreas Schwab wrote:
> > Even without this bug gcc usage of bitfield instruction has become a
> > little insane lately, e.g. 2.95/3.4 produce this code:
> >
> > retmeK:
> > link.w %a6,#0
> > move.l 8(%a6),%d0
> > unlk %a6
> > rts
>
> FWIW, I get this very code with 4.3.0 20070122 when compiling without
> optimisation.
-fno-tree-sra does the same. I don't know if disabling this is the best
way to go as in some cases it makes sense, the problem is that there is
nothing that undoes this pass later, when needed.
This pass makes more sense with larger structures in memory, but with
small structures in registers it makes things worse, e.g. some C++
structure may look like this:
struct B { bool a, b, c, d; };
and this also produces lots of bitfield instructions...
bye, Roman
RE: Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
On 24 April 2007 15:52, Paul Brook wrote: >>> .file "" >>> foo.global _ffs >> >> Is this really a reference? It just looks like a declaration. A >> typical ELF assembler will not generate an undefined symbol merely >> because it sees a .global pseudo-op. > > I think gas 2.17 counts as a "typical ELF assembler". It does create > undefined symbols in response to a .global pseudo-op. I think that's what it's supposed to do - .global is for exporting a symbol that you intend to define. In my case, the backend is misusing it where it means .extern; this doesn't usually cause code breakage, because .global has all the effects of .extern, but it also emits the symbol - whether or not the symbol is later defined by a label in the assembler source. > There was a patch to the c++ frontend recently to avoid a similar problem > with EH personality routines. Couldn't see what you're referring to in cp/ChangeLog straight away, have you got a pointer/rough date/search term I can use? cheers, DaveK -- Can't think of a witty .sigline today
Re: Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
> > There was a patch to the c++ frontend recently to avoid a similar problem > > with EH personality routines. > > Couldn't see what you're referring to in cp/ChangeLog straight away, have > you got a pointer/rough date/search term I can use? Ah, it wasn't actually the c++ forntend: 2007-03-19 Mark Mitchell <[EMAIL PROTECTED]> * except.c (output_function_exception_table): Do not reference the EH personality routine for functions that do not require an exception table. Paul
What is the right usage of SAVE_EXPR?
What is the policy concerning the usage of SAVE_EXPRs? Who is responsible for inserting them? I thought the respective language front end were responsible to enclose any expressions with side effects this way, so that later parts of GCC know how to treat these expressions right. However, also some of the code translating tree nodes into rtxes like some functions found in builtins.c worry about the re-evaluation of arguments and insert plenty of SAVE_EXPRs. Why is that necessary? With best regards, Wolfgang Gellerich --- Dr. Wolfgang Gellerich IBM Deutschland Entwicklung GmbH Schönaicher Strasse 220 71032 Böblingen, Germany Tel. +49 / 7031 / 162598 [EMAIL PROTECTED] === IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Johann Weihen Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
Re: Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
Paul Brook <[EMAIL PROTECTED]> writes: > > > .file "" > > > foo.global _ffs > > > > Is this really a reference? It just looks like a declaration. A > > typical ELF assembler will not generate an undefined symbol merely > > because it sees a .global pseudo-op. > > I think gas 2.17 counts as a "typical ELF assembler". It does create > undefined > symbols in response to a .global pseudo-op. Whoops, you're right. I tested that, but I goofed the test. Ian
Re: What is the right usage of SAVE_EXPR?
On Apr 24, 2007, at 8:30 AM, Wolfgang Gellerich wrote: What is the policy concerning the usage of SAVE_EXPRs? Roughly, if you do something like: tree foo(a, b) return build (a, b); You don't need any saving. If you do: tree foo(a, b) return build (a, build (a, b)); You need to code this as: tree foo(a, b) a = save_expr (a); return build (a, build (a, b)); The person that does the building, does the saving, as they know they are going to reuse a value and duplicate evaluations would be wrong. I thought the respective language front end were responsible to enclose any expressions with side effects this way No. The first example above needs no saving. Only when a value is used more than once, does it need to be saved. However, also some of the code translating tree nodes into rtxes like some functions found in builtins.c worry about the re-evaluation of arguments and insert plenty of SAVE_EXPRs. Why is that necessary? Because they do as in the second example above.
Re: Does vectorizer support extension?
"H. J. Lu" <[EMAIL PROTECTED]> wrote on 24/04/2007 01:03:25: ... > > There are > > [EMAIL PROTECTED] vect]$ cat pmovzxbw.c > typedef unsigned char vec_t; > typedef unsigned short vecx_t; > > in > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31667 > By the way, this PR says "Integer externsions aren't vectorized" - but I think the testcase you are referring to does get vectorized, only not as efficiently as you would want it to (right?). > > * Also I wonder how the gcc code looks like when complete unrolling is > > applied (did you use -funoll-loops?). (like the point above, this is just > > so that we aompre apples w apples). > > It is similar. I am enclosing it at the end. > thanks > > * I don't entirely follow the code that gcc generates > > what's that for exactly?: > > pxor%xmm2, %xmm2 > > movdqa %xmm2, %xmm1 > > pcmpgtb %xmm0, %xmm1 > > Is this part of the vec_unpack_hi, and if so - I wonder if there's a better > > way to model the vec_unpack_hi using the new sse4 instructions? > > That is for signed extension. I tried to model vec_unpack_hi with SSE4. It > isn't easy to move N/2 high elemenets to N/2 low elemenets. just curious - why is it difficult? (couldn't you use a psrldq? is it too expensive?) dorit > The best way > to do it is to combine > >movdqa x(%rip), %xmm9 > pmovsxbw %xmm9, %xmm11 > > into > >pmovsxbw x(%rip),%xmm11 > > and repeat it for N/2 elements. Of cause, we should only do it if > vec_unpack_lo is a single instructions. > > However, I think we need a more general approach based on the number > of elements in the resulting vector to handle, vec_extend, like, > > V4QI -> V4SI > V2QI -> V2DI > V2HI -> V2DI > > They should be independent of vec_unpack. > > > H.J. > >.file "pmovsxbw.c" >.text >.p2align 4,,15 > .globl foo >.type foo, @function > foo: >pxor %xmm2, %xmm2 >movdqa x(%rip), %xmm9 >movdqa x+16(%rip), %xmm6 >movdqa %xmm2, %xmm10 >movdqa %xmm2, %xmm7 >movdqa x+32(%rip), %xmm3 >movdqa %xmm2, %xmm4 >pmovsxbw %xmm9, %xmm11 >movdqa x+48(%rip), %xmm0 >pcmpgtb %xmm9, %xmm10 >pcmpgtb %xmm6, %xmm7 >pmovsxbw %xmm6, %xmm8 >pcmpgtb %xmm3, %xmm4 >pmovsxbw %xmm3, %xmm5 >pcmpgtb %xmm0, %xmm2 >pmovsxbw %xmm0, %xmm1 >punpckhbw %xmm10, %xmm9 >punpckhbw %xmm7, %xmm6 >punpckhbw %xmm4, %xmm3 >punpckhbw %xmm2, %xmm0 >movdqa %xmm11, y(%rip) >movdqa %xmm9, y+16(%rip) >movdqa %xmm8, y+32(%rip) >movdqa %xmm6, y+48(%rip) >movdqa %xmm5, y+64(%rip) >movdqa %xmm3, y+80(%rip) >movdqa %xmm1, y+96(%rip) >movdqa %xmm0, y+112(%rip) >ret >.size foo, .-foo >.ident "GCC: (GNU) 4.3.0 20070423 (experimental) [trunk revision 124056]" >.section .note.GNU-stack,"",@progbits
Re: Does vectorizer support extension?
On Tue, Apr 24, 2007 at 08:55:24PM +0300, Dorit Nuzman wrote: > "H. J. Lu" <[EMAIL PROTECTED]> wrote on 24/04/2007 01:03:25: > ... > > > > There are > > > > [EMAIL PROTECTED] vect]$ cat pmovzxbw.c > > typedef unsigned char vec_t; > > typedef unsigned short vecx_t; > > > > in > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31667 > > > > By the way, this PR says "Integer externsions aren't vectorized" - but I > think the testcase you are referring to does get vectorized, only not as > efficiently as you would want it to (right?). I was referring to extensions including things like V2QI -> V2DI. > It > > isn't easy to move N/2 high elemenets to N/2 low elemenets. > > just curious - why is it difficult? (couldn't you use a psrldq? is it too > expensive?) It needs more instructions. H.J.
[Announce] C++0x branch in GCC Subversion repository
Hello, I have just created a new branch for development of C++0x-specific features in the GNU C++ front end. The branch is branches/cxx0x-branch in Subversion, and information about this branch is available at http://gcc.gnu.org/projects/cxx0x.html. The intent of this branch is to collect all of the C++0x features into a single place, so that users of this branch can get a better feel for the C++0x language and we can work on handling interactions among C++0x features. Most implementations of C++0x features should still go into mainline, when possible, but on the branch we have a little more freedom to commit partially-implemented features. Jason Merrill and I will maintain this branch. As features on this branch mature, we hope to merge them into the mainline compiler under the "experimental" C++0x mode. Cheers, Doug
Changes to PR prioritization policy
I'd going to make a change to the policy for setting priorities for PRs in Bugzilla, to try to help address two issues that have been raised: 1. There may be vitally important bugs that are not regressions, and therefore do not get visibility before releases. (We have, in past, allowed changes on release branches for things like building the Linux kernel, even though they were not regressions.) 2. There may be regressions that appear more important to me than they really are. (In particular, people have mentioned optimization regressions: some of these may be unaavoidable consequences of improvements.) There's also a meta-issue: I don't want to be a bottleneck, for this or other aspects of GCC development. So, I'm going to make a few adjustments to the prioritization policy, effective immediately: 1. If you think that a PR deserves P1/P2 status (but doesn't have it) and you are a maintainer of the affected part of the compiler, please mark the issue as P3, add a note to the issue explaining why you think it should have higher priority, and CC: me. My default reaction will probably be to deprioritize the issue -- especially if there's no patch -- so make a good case. 2. If you think that a P2 PR should be taken off the radar, and you are a maintainer of the affected part of the compiler, you may downgrade it to P4 at will. 3. If you think that a P1 PR should be downgraded, and you are a maintainer of the affected part of the compiler, please add a note to the issue explaining why, and CC: me. The reason for the "maintainer of the affected part of the compiler" language above is that I will not be able to handle a stream of such requests coming from all over the place. I also want to give authority and responsibility to the various maintainers. So, if you're not a maintainer, but you want to make one of the changes above, lobby a maintainer. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.2.0 Status Report (2007-04-24)
[I apologize to those of you receiving duplicate copies of this mail. I thought so hard about copying people that I forgot to address to the list.] Table of contents: 1. PRs 2. Schedule 3. Rationale If you're in the CC: list, there are possible action items for you below. (Recent feedback was to provide more frequent status reports and to nag more -- I'll do my best!) PRs === At this point, we're very, very close to meeting the (admittedly limited) goal for 4.2.0 of having no P1 regressions from 4.1.x. The remaining PRs are: 1. PR 26792: libstdc++ on Darwin uses functions not present in the system libgcc This PR has apparently been fixed on the mainline. If a Darwin maintainer (Dale, Mike, Geoff) would like to backport this to 4.2, that would be great. 2. PR 30222: crash on gcc.target/i386/vectorize1.c This PR is apparently due to only part of a mainline patch being applied to 4.2. It was so diagnosed in December 2006, but nobody has identified the missing part of the mainline patch. Andrew, as you've diagnosed the problem, would you please identify the solution? 3. PR 30567: Wrong code with -O3 due to aliasing problems Richard G. has analyzed this and proposed a patch. Richard, is this ready to go? If not, do you need help? 4. PR 31360: Missed optimization I don't generally mark missed optimization bugs as P1, but not hoisting loads of zero out of a 4-instruction loop is bad. Zdenek has fixed this on mainline. Andrew says that patch has a bug. So, what's the story here? Schedule I'm not going to consider any of these issues blockers after Sunday, April 29. At that point, I plan to freeze the branch and build a release candidate. Then, about a week later, I plan to release 4.2.0. There has been more than enough time for people to test and fix bugs. Rationale = There are far too many constraints on releases to make everyone happy. All of the following objectives and suggestions have been made by intelligent, knowledgeable people: 1. Release early and often. 2. Take longer between releases so there's more time for major development. 3. Align releases with distributor schedules. 4. Take a feature-driven view: release when a pre-defined set of new features are available. 5. Take a time-driven view: release on a particular date, no matter what. 6. Take a quality-driven view: release when there are no severe bugs. I've gotten a little paralyzed with this release. I've wanted to take some combination of (4), (5), and (6), and I've made a hash of it. I'm going to cut my losses and 4.2.0 out the door. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RE: Builtins-vs-libcalls-vs-optimised-away-vs-still-emitting-an-undefined-symbol-reference
On 24 April 2007 16:00, Dave Korn wrote: > I'd say that I've inherited a thinko-fied version of ASM_OUTPUT_EXTERNAL Wrong, wrong, wrong. I don't have an ASM_OUTPUT_EXTERNAL at all. What I do have, however, is TARGET_ASM_GLOBALIZE_LABEL, which appears to somehow be equated with ASM_OUTPUT_EXTERNAL_LIBCALL. (gdb) bt #0 rtmi_globalize_label (stream=0x611010e8, name=0xd3a988 "ffs") at /tools/external_source/gnu/gcc-3.3.3/gcc/config/rtmi/rtmi.c:158 #1 0x0047c05d in assemble_external_libcall (fun=0x7feb1b80) at /tools/external_source/gnu/gcc-3.3.3/gcc/varasm.c:1742 #2 0x004f37aa in emit_library_call_value_1 (retval=1, orgfun=0x7feb1b80, value=0x0, fn_type=LCT_CONST, outmode=SImode, nargs=1, p=0x23c37c "") at /tools/external_source/gnu/gcc-3.3.3/gcc/calls.c:3820 ...where it says: 3818 /* If this machine requires an external definition for library 3819 functions, write one out. */ - 3820 assemble_external_libcall (fun); Ah, it's elfos.h that does it: /* The standard SVR4 assembler seems to require that certain builtin library routines (e.g. .udiv) be explicitly declared as .globl in each assembly file where they are referenced. */ #define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN) \ (*targetm.asm_out.globalize_label) (FILE, XSTR (FUN, 0)) That comment doesn't apply to me, so I can undef and redefine it in my tm.h to point to something that emits an .extern instead of a .global. As I see a lot of other ports do. Thanks for the help. cheers, DaveK -- Can't think of a witty .sigline today
[Committed] Fix PR30222 for 4.2 [Was: Re: GCC 4.2.0 Status Report (2007-04-24)]
On 4/24/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
2. PR 30222: crash on gcc.target/i386/vectorize1.c
This PR is apparently due to only part of a mainline patch being applied
to 4.2. It was so diagnosed in December 2006, but nobody has identified
the missing part of the mainline patch. Andrew, as you've diagnosed the
problem, would you please identify the solution?
This is what I am checking in to the 4.2 branch. I bootstrapped and
tested on x86-linux-gnu with no regressions and fixes the testcase.
This is a back port of part of:
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00702.html
Which was also part of the orginal patch which was supposed to fix this patch:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00566.html.
Thanks,
Andrew Pinski
2007-04-24 Andrew Pinski <[EMAIL PROTECTED]>
Roger Sayle <[EMAIL PROTECTED]>
PR middle-end/30222
* expmed.c (make_tree): Use the correct type, i.e. the inner
type, when constructing the individual elements of a CONST_VECTOR.
Index: ChangeLog
===
--- ChangeLog (revision 124139)
+++ ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2007-04-24 Andrew Pinski <[EMAIL PROTECTED]>
+Roger Sayle <[EMAIL PROTECTED]>
+
+ PR middle-end/30222
+ * expmed.c (make_tree): Use the correct type, i.e. the inner
+ type, when constructing the individual elements of a CONST_VECTOR.
+
2007-04-24 Ian Lance Taylor <[EMAIL PROTECTED]>
PR tree-optimization/31605
Index: expmed.c
===
--- expmed.c(revision 124139)
+++ expmed.c(working copy)
@@ -4976,17 +4976,17 @@ make_tree (tree type, rtx x)
case CONST_VECTOR:
{
- int i, units;
- rtx elt;
+ int units = CONST_VECTOR_NUNITS (x);
+ tree itype = TREE_TYPE (type);
tree t = NULL_TREE;
+ int i;
- units = CONST_VECTOR_NUNITS (x);
/* Build a tree with vector elements. */
for (i = units - 1; i >= 0; --i)
{
- elt = CONST_VECTOR_ELT (x, i);
- t = tree_cons (NULL_TREE, make_tree (type, elt), t);
+ rtx elt = CONST_VECTOR_ELT (x, i);
+ t = tree_cons (NULL_TREE, make_tree (itype, elt), t);
}
return build_vector (type, t);
