Trunk is now OPEN
Trunk is once again open for commits under stage 3 rules. Diego.
Re: i370 port - constructing compile script
Paul Edwards wrote: > Would you be able to give me the two suggested configure > commands so that I can find out the answer to the above, one > way or another? For step 2 (building the cross-compiler), you'd need something along the lines of .../configure --target=i370-mvs --prefix=... --with-sysroot=... \ --enable-languages=c where prefix points to the directory where the cross-compiler should be installed, and sysroot points to the directory where the MVS libraries and header are installed. Then you need to build and install the cross-compiler (using make and make install). For the subsequent step, you need to make the cross-compiler available in the PATH. For step 3 (cross-building a native compiler), you'd need something along the lines of .../configure --build=i686-linux --host=i370-mvs --target=i370-mvs \ --prefix=... --with-build-sysroot=... --enable-languages=c This configure run will then use the i370-mvs-gcc cross-compiler you built in step 2 in order to detect MVS host properties. > Or does the configure process attempt to run the executables > as well? No, that wouldn't work (the exectuables are for a different architecture than the build system ...). > But it won't be able to correctly determine the stack direction > if it does that. So that is the sort of thing I would need some > intrusive code (out of my 20 lines quota!) to force it to 0 > (unknown stack direction). I don't think GCC needs to know the stack direction of the *host* system. (It does need to know the stack direction of the *target* system, but this is not detected by configure, but determined by target macro settings from the config/i370/*.h files.) Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: i370 port - constructing compile script
Hi,
On Sun, 4 Oct 2009, Paul Edwards wrote:
> With 3.4.6, I have a script called "compile", which looks like this:
>
> call stdcomp alias.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> call stdcomp alloc-pool.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> call stdcomp attribs.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> call stdcomp bb-reorder.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> call stdcomp bitmap.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> call stdcomp bt-load.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> ...
> gcc -s -nostdlib -o gccmvs.exe *.o ../../pdos/pdpclib/pdpwin32.a -lkernel32
>
> I believe that a simple script like above can be *generated* with a few
> lines of changes to an appropriate makefile. That's why I mentioned
> before that I'm after a makefile target that only lists the object code
> that would go into a stage 1 executable.
Ignoring the cross stuff, if this is all you need I would suggest calling
make in the right way to generate this script. We'll use a fake
"compiler" for making cc1 which does nothing else than appending its
command line to your compile script. Hence, create a script
collect-stuff.sh with this content:
snip --
#!/bin/sh
echo stdcomp ${1+"$@"} >> /tmp/compile
snap --
Now we'll call make so that it only tries to make cc1 with this compiler
to collect the commands:
% cd gcc
% make CC=collect-stuff.sh cc1
/tmp/compile will now fill up with the commands to use. If you don't need
the various options, also add "ALL_COMPILERFLAGS= ALL_CPPFLAGS=" to the
make command (might be other variable names in the old 4.x compilers), or
amend the collect-stuff.sh script to not echo them.
Remember to clean the build dir before doing this as otherwise some .o
files aren't remade.
Ciao,
Michael.
Re: i370 port - constructing compile script
.../configure --target=i370-mvs --prefix=... --with-sysroot=... \
--enable-languages=c
Thanks Ulrich. That's very different from the concept I had of
how the build process was meant to work.
Ignoring the cross stuff, if this is all you need I would suggest calling
make in the right way to generate this script. We'll use a fake
"compiler" for making cc1 which does nothing else than appending its
command line to your compile script. Hence, create a script
collect-stuff.sh with this content:
snip --
#!/bin/sh
echo stdcomp ${1+"$@"} >> /tmp/compile
snap --
Now we'll call make so that it only tries to make cc1 with this compiler
to collect the commands:
% cd gcc
% make CC=collect-stuff.sh cc1
Thanks Michael. That's exactly the sort of thing I was after. Just
one thing - I'll need more than cc1. I need the files that normally
go into gcc as well. So a combination of those two sets of source,
so that I can get a single standalone executable. So I'll need to
create a new Makefile target that's a bit bigger than cc1. But
cc1 will come close.
Also, I decided that I'd better go back to gcc 3.4.6 in order to do
this experimentation, because at least with that I know that at
the end of the day, there's no compiler issue, so if it doesn't
work, the fault must lie withe the build process.
I can't say that about 4.4, because I already know a normally
built cross-compiler on 4.4 with a resuscitated i370 will
build, but has a runtime error which wasn't immediately
obvious (ie gdb didn't point to something wrong). After 3.4.6
is working, I'll hopefully have an easier time with 4.4.
Anyway, I'll try it out tomorrow etc, and report back the results.
BFN. Paul.
Re: i370 port - constructing compile script
Hi, On Tue, 6 Oct 2009, Paul Edwards wrote: > Thanks Michael. That's exactly the sort of thing I was after. Just > one thing - I'll need more than cc1. I need the files that normally > go into gcc as well. So a combination of those two sets of source, > so that I can get a single standalone executable. So I'll need to > create a new Makefile target that's a bit bigger than cc1. But > cc1 will come close. Add whatever targets you need: make CC=collect-stuff.sh cc1 xgcc If you also need some libraries that are normally linked into xgcc or cc1 (probably at least libiberty and libcpp) do make CC=collect-stuff.sh -C ../libiberty too (after having configured everything already). You'll figure out the missing stuff :) Ciao, Michael.
Re: How to split 40bit data types load/store?
2009/9/14 Richard Henderson :
> On 09/14/2009 07:24 AM, Mohamed Shafi wrote:
>>
>> Hello all,
>>
>> I am doing a port for a 32bit target in GCC 4.4.0. I have to support a
>> 40bit data (_Accum) in the port. The target has 40bit registers which
>> is a GPR and works as 32bit reg in other modes. The load and store for
>> _Accum happens in two step. The lower 32bit in one instruction and the
>> upper 8bit in the next instruction. I want to split the instruction
>> after reload. I tired to have a pattern (for load) like this:
>>
>> (define_insn "fn_load_ext_sa"
>> [(set (unspec:SA [(match_operand:DA 0 "register_operand" "")]
>> UNSPEC_FN_EXT)
>> (match_operand:SA 1 "memory_operand" ""))]
>>
>> (define_insn "fn_load_sa"
>> [(set (unspec:SA [(match_operand:DA 0 "register_operand" "")]
>> UNSPEC_FN)
>> (match_operand:SA 1 "memory_operand" ""))]
>
> Unspec on the left-hand-side isn't something that's supposed to happen, and
> is more than likely the cause of your problems. Try moving the unspec to
> the right-hand-side like:
>
> (set (reg:SI reg) (mem:SI addr))
>
> (set (reg:SA reg)
> (unspec:SA [(reg:SI reg) (mem:QI addr)]
> UNSPEC_ACCUM_INSERT))
>
> and
>
> (set (mem:SI addr) (reg:SI reg))
>
> (set (mem:QI addr)
> (unspec:QI [(reg:SA reg)]
> UNSPEC_ACCUM_EXTRACT))
>
> Note that after reload it's perfectly acceptable for a hard register to
> appear with the different SI and SAmodes.
>
> It's probably not too hard to define this with zero_extract sequences
> instead of unspecs, but given that these only appear after reload, it may
> not be worth the effort.
>
I was able to implement this with unspecs. But now it seems that i
need to split the pattern before reload also. So i am thinking of
removing this and doing a split before reload. The issue is that there
is no support to for register indirect addressing mode for accessing
the upper eight bits of the 40bit register. The only addressing mode
supported for accessing this section is (SP+offset). So what i thought
was to allow this addressing mode and at the time of reloading, at the
time of secondary reload with the help of a scratch register and a
scratch memory. But it seems that in GCC it is not possible to have
both scratch memory and a scratch register for the same operation. Am
i right?
So what i did was to implement this at the define_expand stage itself.
The idea is to generate the following sequence:
for load (R0), D0 generate
load (R0), D0// 32bit mode , SAmode move
load (R0+4), scratch_reg // 32bit mode, SAmode
store scratch_reg, (SP+off) //32bit mode, SAmode
load.ext (SP+off), D0.u8
and similarly for store.
Here are the patterns that i used for this purpose:
(define_expand "movda"
[(set (match_operand:DA 0 "nonimmediate_operand" "")
(match_operand:DA 1 "nonimmediate_operand" ""))]
""
"{
if (MEM_P (operands[1]) && REG_P (XEXP (operands[1], 0))
&& XEXP (operands[1], 0) != virtual_stack_vars_rtx))
{
rtx lo_half, hi_half;
rtx scratch_mem, scratch_reg, subreg;
gcc_assert (can_create_pseudo_p ());
scratch_reg = gen_reg_rtx (SAmode);
scratch_mem = assign_stack_temp (SAmode, GET_MODE_SIZE (SAmode), 0);\
subreg = gen_rtx_SUBREG (SAmode, operands[0], 0);
lo_half = adjust_address (operands[1], SAmode, 0);
hi_half = adjust_address (operands[1], SAmode, 4);
emit_insn (gen_rtx_SET (SAmode, subreg, lo_half));
emit_insn (gen_rtx_SET (SAmode, scratch_reg, hi_half));
emit_insn (gen_rtx_SET (SAmode, scratch_mem, scratch_reg));
emit_insn (gen_load_reg_ext (operands[0], scratch_mem));
DONE;
}
/* and similarly for store operation */
}"
)
(define_insn "load_reg_ext"
[(set (subreg:SA (zero_extract:DA (match_operand:DA 0 "register_operand" "=d")
(const_int 8)
(const_int 24)) 4)
(match_operand:SA 1 "memory_operand" "Sd3"))]
(define_insn "store_reg_ext"
[(set (match_operand:SA 0 "memory_operand" "=Sd3")
(zero_extract:SA (match_operand:DA 1 "register_operand" "d")
(const_int 8)
(const_int 24)))]
(define_insn "*movsa_internal"
[(set (match_operand:SA 0 "nonimmediate_operand" "=m,d,d")
(match_operand:SA 1 "nonimmediate_operand" "d,m,d"))]
By default -fomit-frame-pointer will passed to the complier. Without
optimization compiler generates the expected output. But with
optimization that is not the case. It seems that the pattern that i
have written above are not proper. For the simple function like the
following
_Accum foo (_Accum *a)
{
_Accum b = *a;
return b;
}
with optimization enabled the complier generates only
load (R0), D0// 32bit mode , SAmode move
the 1st instruction in the expected 4 instruction sequence.
How can i write the patterns properly?
Regards
Shafi
Re: LTO branch merged into trunk - trunk remains CLOSED
Diego Novillo writes: > The LTO branch has been merged into trunk at revision 152434. > [...] Congrats. > [...] That's it. The result should, in principle, execute faster > but our IPA cost models are still not tweaked for LTO. We've seen > speedups as well as slowdowns in benchmarks (see the LTO testers at > http://gcc.opensuse.org/). [...] Would it make sense to keep -flto unemphasized in NEWS etc., until some consistently positive performance results of some sort have been identified? - FChE
[g++-4.5]kudos on O(1) template lookup work
The work in 4.5 on O(1) template instantiation lookup time is already showing benefits: http://article.gmane.org/gmane.comp.lib.boost.devel/194545 http://article.gmane.org/gmane.comp.lib.boost.devel/194538 http://www.boostpro.com/vault/index.php?&directory=variadic_templates in tuple.benchmark.zip Thanks very much for this work! -regards, Larry
Re: Inline assembly operand specification
Zoltán Kócsi writes: > Is there a documentation of the various magic letters that you can > apply to an operand in inline assembly? Unfortunately, no. > The > only place I found some information was going through the > gcc/config//.c file and trying to find the meaning of such > letters in the xxx_print_operand() function. Right, that is the only current documentation there is. > If that is the correct > approach, then I think there's a problem with the arm-elf (I know it is > dead, but still). > > According to the comments in that function, for DI and DF arguments the > Q and R qualifiers supposed to select the least significant and most > significant 32 bits, respectively, of the 64-bit datum. Indeed that's > what they do, for a long long. However, for a double they don't seem to > take into account that on arm-elf the word order of a double is always > big-endian, regardless of the endianness of the rest. Therefore, they > select the wrong half of the datum. On arm-eabi, where the endianness > of doubles matches the rest, they work fine. For a value which is always big-endian you don't need any modifier for the low register, and you can use %H for the high register. Ian
Re: Error when building cross compiler
Denis Onischenko writes: > I am getting the following error when compiling "x86_64 to powerpc64" > cross gcc, as soon as the libgcc_s.so.1 has appeared in obj/gcc > directory. This question would be more appropriate for the mailing list gcc-h...@gcc.gnu.org. Please take any followups there. Thanks. > configure:2572: /a/linux/.powerpc/gcc/obj/./gcc/xgcc > -B/a/linux/.powerpc/gcc/obj/./gcc/ > -B/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/bin/ > -B/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/lib/ > -isystem /a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/include > -isystem /a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/sys-include > -g -O2 conftest.c >&5 > /a/linux/.powerpc/gcc/obj/./gcc/cc1: error while loading shared > libraries: /a/linux/.powerpc/gcc/obj/./gcc/libgcc_s.so.1: ELF file > data encoding not little-endian ... > It seems that host cc1 executable tries to load target libgcc_s.so.1 > from obj/gcc directory, rather than host libgcc_s.so.1 from /lib. The > message "error while loading shared libraries: > /a/linux/.powerpc/gcc/obj/./gcc/libgcc_s.so.1: ELF file data encoding > not little-endian" is from glibc. What version of gcc are you using? Exactly how did you run the configure script? The -B option tells gcc where to find passes, but it does not normally tell the dynamic linker where to find shared libraries. Something is causing the dynamic linker to think that it should use /a/linux/.powerpc/gcc/obj/./gcc/libgcc_s.so.1 rather than /lib/libgcc_s.so.1. Is it possible that you have LD_LIBRARY_PATH set in the environment? Ian
Re: Lattice Mico32 port
"Jon Beniston" writes: > Hi Richard, > >>> Index: gcc/config/lm32/sfp-machine.h >>> Index: gcc/config/lm32/crti.S >>> Index: gcc/config/lm32/lib1funcs.S >>> Index: gcc/config/lm32/crtn.S >>> Index: gcc/config/lm32/arithmetic.c >>> Index: gcc/config/lm32/t-fprules-softfp >>> Index: gcc/config/lm32/t-lm32 >> >>Can you move these to libgcc? > > The rules in libgcc/Makefile.in use $(gcc_srcdir) (E.g. for targets > lib1asmfuncs-o). How would you suggest I do this? You can put assembler files in LIB2ADD. See, e.g., libgcc/config/ia64/t-softfp-compat. I'm not sure the libgcc1 vs. libgcc2 distinction makes much sense any more. Ian
Is this code legal?
Hello all.
I try to compile the following code sample:
(with MinGW gcc version 4.5.0 20090819 (experimental) (GCC))
#include
#include
#include
template
struct Message
{
std::array m_Message;
Message() : m_Message{Chars...} // {*1}
{
std::array msg = {Chars ... };
// {*2}
}
};
int main(int argc, char* argv[])
{
setlocale(LC_ALL, ".OCP");
Message msg;
std::for_each(msg.m_Message.begin(), msg.m_Message.end(), [](wchar_t
c){std::wcout << c;});
return 0;
}
Can anybody explain why line marked with '{*1}' produce this error
message:
hello_programmer.cpp: In constructor 'Message::Message() [with wchar_t
...Chars = 1057u, 32u, 1076u, 1085u, 1105u
, 1084u, 32u, 1087u, 1088u, 1086u, 1075u, 1088u, 1072u, 1084u, 1084u, 1080u,
1089u, 1090u, 1072u, 44u, 32u, 1082u, 1086u
, 1083u, 1083u, 1077u, 1075u, 1080u, 33u, 10u]':
hello_programmer.cpp:48:15: instantiated from here
hello_programmer.cpp:34:35: error: could not convert '{1057u, 32u, 1076u,
1085u, 1105u, 1084u, 32u, 1087u, 1088u, 1086u,
1075u, 1088u, 1072u, 1084u, 1084u, 1080u, 1089u, 1090u, 1072u, 44u, 32u,
1082u, 1086u, 1083u, 1083u, 1077u, 1075u, 1080
u, 33u, 10u}' to 'std::array'
Line marked with '{*2}' is compiled successfully.
Or there is no standard-conforming way to initialize std::array
within constructor initializer list?
-
Best regards, Sergey.
Turning off unrolling to certain loops
Dear all, I was wondering if it was possible to turn off the unrolling to certain loops. Basically, I'd like the compiler not to consider certain loops for unrolling but fail to see how exactly I can achieve that. I've traced the unrolling code to multiple places in the code (I'm working with the 4.3.2 version) and, for the moment, I'm trying to figure out if I can add something in the loop such as a note that I can later find in the FOR_EACH_LOOP loops in order to turn the unrolling for that particular loop off. Have you got any ideas of what I could use like "note" or even a better idea all together? Thanks, Jc
Re: [g++-4.5]kudos on O(1) template lookup work
On 10/05/2009 11:09 AM, Larry Evans wrote: The work in 4.5 on O(1) template instantiation lookup time is already showing benefits: Glad to hear it! Jason
Post-LTO branch merge (tr...@152453) report for i386-*-freebsd7.2
Installed /usr/ports/devel/libelf [0.8.12] on i386-*-freebsd7.2. Explicitly added "--enable-lto --with-libelf=/usr/local" to configure line. (Stock system's /usr/include/libelf.h missing elf_getshdrstrndx().) New failures for i386-*-freebsd7.2 (seems in-line with other port reports): gcc: FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/stpcpy-chk.c execution, -O2 -fwhopr FAIL: gcc.c-torture/execute/builtins/strcpy-chk.c execution, -O2 -fwhopr FAIL: gcc.dg/torture/builtin-math-7.c -O2 -flto -O2 -flto (... x2) FAIL: gcc.dg/torture/builtin-math-7.c -O2 -fwhopr -O2 -fwhopr (... x2) g++: FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O0 -fwhopr FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O2 -fwhopr FAIL: g++.dg/lto/20081123 cp_lto_20081123_0.o-cp_lto_20081123_1.o link FAIL: g++.dg/lto/20090106 cp_lto_20090106_0.o-cp_lto_20090106_0.o link FAIL: g++.dg/lto/20090106 cp_lto_20090106_0.o-cp_lto_20090106_0.o link gfortran: FAIL: gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o execute -O2 -fwhopr FAIL: gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o execute -O2 -flto
Re: COMPONENT_REF problem ?
Richard, > If you are not working on trunk this can happen because the way > MEM_EXPRs are "canonicalized". Thanks. Yes, I am not on trunk and may not be able to move right away. I would appreciate some pointers about where I should look, If I want to fix this ? Thanks, Pranav
Re: OpenMP 3.0 libgomp ABI documentation for TASK construct
That's super! Thank you Antoniu. With the capacity of printing the expanded code, it feels a lot more freedom now when reading the source code of libgomp. Cheers, Tim On Mon, Oct 5, 2009 at 8:29 AM, Antoniu Pop wrote: > Hi Tim, > > >> From gcc online docs (http://gcc.gnu.org/onlinedocs/libgomp/), I found >> documentations for most of OpenMP constructs, except one very >> important construct TASK. > > I cannot answer this. It may be that the documentation was written > before tasks (which were introduced in a latter version of OpenMP) > were added to GCC OpenMP. > >> >> I don't know why it is missing, but I really >> need to find out how TASK get transformed into GOMP_* routines. I >> posted this question before, but haven't got a reply yet. I am very >> grateful if someone can point me to the right track. For example, is >> there a pretty-print feature of the AST after processing the OpenMP >> pragmas? If so, how? Of course, if someone have the expertise, and >> directly show me how TASK get transformed, it would be even better! > > > For the pretty print, just use -fdump-tree-ompexp-all on the compile > line and look for the file *.c.*ompexp that is generated. It contains > the dump just after OpenMP expansion. > > If you need to check out the code generation routines by yourself, > take a look at gcc/omp-low.c > Most of everything happens there. There are two passes, OpenMP > lowerring then expansion. The generation of the GOMP_* routine calls > happens during expansion pass and so you should start from the > "expand_omp_taskreg" function (in gcc/omp-low.c). > > Best, > Antoniu >
Re: How to split 40bit data types load/store?
On 10/05/2009 07:02 AM, Mohamed Shafi wrote: . But now it seems that i need to split the pattern before reload also. Oh? Why? The only addressing mode supported for accessing this section is (SP+offset). Ouch. Is there no general register to high-8bit move either? So you can't do load (R0), D0 load (R0+4), R1 move.ext R1, D0.u8 (define_expand "movda" [(set (match_operand:DA 0 "nonimmediate_operand" "") (match_operand:DA 1 "nonimmediate_operand" ""))] So, DAmode is your 40-bit value. What's SAmode? (define_insn "load_reg_ext" [(set (subreg:SA (zero_extract:DA (match_operand:DA 0 "register_operand" "=d") (const_int 8) (const_int 24)) 4) (match_operand:SA 1 "memory_operand" "Sd3"))] This pattern doesn't look kosher with the subreg outside the zero_extract. I know I mentioned using zero_extract in an earlier message, but that may not actually work with an object larger than word size. You may be better off with an unspec: (set (match_operand:DA 0 "register_operand" "=d") (unspec:DA [(match_operand:DA 1 "register_operand" "0") (match_operand:SA 2 "memory_operand" "Sd3")] UNSPEC_LOAD_REG_EXT)) or whatever you actually need. r~
Re: Turning off unrolling to certain loops
Hi, > I was wondering if it was possible to turn off the unrolling to > certain loops. Basically, I'd like the compiler not to consider > certain loops for unrolling but fail to see how exactly I can achieve > that. > > I've traced the unrolling code to multiple places in the code (I'm > working with the 4.3.2 version) and, for the moment, I'm trying to > figure out if I can add something in the loop such as a note that I > can later find in the FOR_EACH_LOOP loops in order to turn the > unrolling for that particular loop off. > > Have you got any ideas of what I could use like "note" or even a > better idea all together? the normal way of doing this is using a #pragma. For instance, icc implements #pragma nounroll for this purpose. I have some prototype implementation for gcc, I can send it to you if you were interested in finishing it, Zdenek
