Re: Allocating some Loop allocno in memory
On Sun, Jan 11, 2015 at 4:45 PM, Ajit Kumar Agarwal wrote: > > > -Original Message- > From: Richard Biener [mailto:richard.guent...@gmail.com] > Sent: Sunday, January 11, 2015 8:05 PM > To: Ajit Kumar Agarwal; vmaka...@redhat.com; l...@redhat.com; gcc@gcc.gnu.org > Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala > Subject: Re: Allocating some Loop allocno in memory > > On January 11, 2015 5:25:23 AM CET, Ajit Kumar Agarwal > wrote: >> >>I was thinking of some of the opportunities with respect to reducing >>spills inside the Loop. If the Live range(allocno) spans through the >>Loop and Live out at the exit of the Loop and there are no references >>or not being touched upon inside the Loop, assign the allocno to the >>memory. This increase the chances of getting the register for other >>allocno which spans through the Loop and have reference inside the Loop >>if the interference graph is not colorable. >> >>Since allocno don't have references inside the Loop there won't be any >>load instructions with respect to restore inside the loops. There will >>be a store instruction with respect to spill which will be outside the >>Loop. This will reduce the conflicting edges of some of the allocno >>increasing the chances of making colorable of the Interference graph >>and reduces the spills and restore inside the Loop. >> >>This heuristics looks reasonable. This heuristics goes side by side >>with the Live range splitting across the Loop boundary. >>On top of this heuristics, after the Live range splitting across the >>Loop boundary there interference graph is not colorable then we can >>assign some of the splitted live ranges in the memory giving chances >>of registers for the Live ranges(allocno) that spans the Loop and have >>reference inside the Loop. >> >>We can change the cost of allocno in memory based on the above >>heuristics and take the above factor into consideration for the cost >>calculation. >> >>Thoughts Please? > >>>How can this result in better allocations if you only ever spill at >>>life-range split points? The life-range covering the loop should already be >>>assigned to >>memory if required. > > If the live range covering the loop assigned to memory, and there are > references inside the Loops then there are chances > of spills inside the loop which degrades the performance. If live range > covering the loops and there are no references inside > the Loop, then assigning to memory make reasonable as there are no > references. Since there are no references or not > touched inside the Loop, there won't be load instruction to restore which are > required if there are any references. The store > which requires for the def of the Live range will be outside the Loops. This > helps in not degrading the performances as there > are no load and store required for spill and restore inside the Loops. > > The above heuristics can also be accompanied with heuristics of the number of > use points in the Live range. Considering both > the heuristics will lead to better allocation if ever spill at the live > range split points and there are chances of getting colorable > the Interference graph without degrading the performance. Also if the Live > range is splitted at the Loop boundary then the spill > at the split points of loop boundary and registers is assigned to this live > range will make it reasonable if there are no references > inside the Loops. But if we split the life-range of not used in-loop-body pseudos at the loop boundary the allocator should do the assignment to memory. There is no need to add another heuristic here. Or do you say we don't split the life-range of such pseudos at loop boundary? Richard. > Thanks & Regards > Ajit > > Richard. > >>Thanks & Regards >>Ajit > >
RE: Allocating some Loop allocno in memory
-Original Message- From: Richard Biener [mailto:richard.guent...@gmail.com] Sent: Monday, January 12, 2015 2:33 PM To: Ajit Kumar Agarwal Cc: vmaka...@redhat.com; l...@redhat.com; gcc@gcc.gnu.org; Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala Subject: Re: Allocating some Loop allocno in memory On Sun, Jan 11, 2015 at 4:45 PM, Ajit Kumar Agarwal wrote: > > > -Original Message- > From: Richard Biener [mailto:richard.guent...@gmail.com] > Sent: Sunday, January 11, 2015 8:05 PM > To: Ajit Kumar Agarwal; vmaka...@redhat.com; l...@redhat.com; > gcc@gcc.gnu.org > Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju > Mekala > Subject: Re: Allocating some Loop allocno in memory > > On January 11, 2015 5:25:23 AM CET, Ajit Kumar Agarwal > wrote: >> >>I was thinking of some of the opportunities with respect to reducing >>spills inside the Loop. If the Live range(allocno) spans through the >>Loop and Live out at the exit of the Loop and there are no references >>or not being touched upon inside the Loop, assign the allocno to the >>memory. This increase the chances of getting the register for other >>allocno which spans through the Loop and have reference inside the >>Loop if the interference graph is not colorable. >> >>Since allocno don't have references inside the Loop there won't be any >>load instructions with respect to restore inside the loops. There will >>be a store instruction with respect to spill which will be outside >>the Loop. This will reduce the conflicting edges of some of the >>allocno increasing the chances of making colorable of the Interference >>graph and reduces the spills and restore inside the Loop. >> >>This heuristics looks reasonable. This heuristics goes side by side >>with the Live range splitting across the Loop boundary. >>On top of this heuristics, after the Live range splitting across the >>Loop boundary there interference graph is not colorable then we can >>assign some of the splitted live ranges in the memory giving chances >>of registers for the Live ranges(allocno) that spans the Loop and >>have reference inside the Loop. >> >>We can change the cost of allocno in memory based on the above >>heuristics and take the above factor into consideration for the cost >>calculation. >> >>Thoughts Please? > >>>How can this result in better allocations if you only ever spill at >>>life-range split points? The life-range covering the loop should already be >>>assigned to >>memory if required. > > If the live range covering the loop assigned to memory, and there are > references inside the Loops then there are chances of spills inside > the loop which degrades the performance. If live range covering the > loops and there are no references inside the Loop, then assigning to > memory make reasonable as there are no references. Since there are no > references or not touched inside the Loop, there won't be load instruction to > restore which are required if there are any references. The store which > requires for the def of the Live range will be outside the Loops. This helps > in not degrading the performances as there are no load and store required for > spill and restore inside the Loops. > > The above heuristics can also be accompanied with heuristics of the > number of use points in the Live range. Considering both the > heuristics will lead to better allocation if ever spill at the live > range split points and there are chances of getting colorable the > Interference graph without degrading the performance. Also if the Live range > is splitted at the Loop boundary then the spill at the split points of loop > boundary and registers is assigned to this live range will make it reasonable > if there are no references inside the Loops. >>But if we split the life-range of not used in-loop-body pseudos at the loop >>boundary the allocator should do the assignment to memory. >>There is no need to add another heuristic here. Or do you say we don't split >>the life-range of such pseudos at loop boundary? In spill_cost calculations we are seeing the function ira_loop_edge_freq triggered with the Live ranges that are live at the exit of the Loop but are not referenced inside the Loops. We are still considering frequency in the updation of spill cost for such live ranges . We have made a change not to consider the freq of such live ranges in the updation of spill cost, thus reducing the cost of such live ranges making it a chance to be in memory giving the conflicting allocno the chances of getting the register. There are chances , the conflicting allocno with respect to loops which have references and will have more edge on getting the registers. The changes are made in the following. https://gcc.gnu.org/ml/gcc/2015-01/msg00033.html Thanks & Regards Ajit Richard. > Thanks & Regards > Ajit > > Richard. > >>Thanks & Regards >>Ajit > >
RTEMS FORTRAN Pattern Failures
Hi RTEMS has pretty good FORTRAN test results on SPARC and PowerPC but a number fail in pattern matching. It appears to be a CR/LF issue. I have attached the output of f77-edit-x-out (out.txt) and the associated fragment (run.txt) from the test run log which shows the pattern not matching. Based on breaking at the device driver, there is definitely a \r and \n at the end of each line printed and it is intentional from RTEMS' perspective. Is there some magic testsuite setting to tell DejaGNU about this? Some other suggestion to make the output pattern matching work. Tobias and I have taken a couple of swings at this in the past but never gotten a solution. I am hoping we are luckier this time. :) Thanks. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 1 2 3 1 2 3 *** EXIT code 0 Executing on host: /home2/joel/build/b-sparc-fortran/gcc/testsuite/gfortran/../../gfortran -B/home2/joel/build/b-sparc-fortran/gcc/testsuite/gfortran/../../ -B/home2/joel/build/b-sparc-fortran/sparc-rtems4.11/./libgfortran/ /users/joel/test-gcc/gcc-4.9-branch/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f gfortran_tg.o -fno-diagnostics-show-caret -fdiagnostics-color=never -Os -pedantic-errors -B/users/joel/test-gcc/install-4.9-branch/sparc-rtems4.11/sis/lib/ -specs bsp_specs -qrtems -mcpu=cypress /home2/joel/build/b-sparc-fortran/rtems_gcc_main.o -B/home2/joel/build/b-sparc-fortran/sparc-rtems4.11/./libgfortran/.libs -L/home2/joel/build/b-sparc-fortran/sparc-rtems4.11/./libgfortran/.libs -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o ./f77-edit-x-out.exe(timeout = 300) spawn -ignore SIGHUP /home2/joel/build/b-sparc-fortran/gcc/testsuite/gfortran/../../gfortran -B/home2/joel/build/b-sparc-fortran/gcc/testsuite/gfortran/../../ -B/home2/joel/build/b-sparc-fortran/sparc-rtems4.11/./libgfortran/ /users/joel/test-gcc/gcc-4.9-branch/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f gfortran_tg.o -fno-diagnostics-show-caret -fdiagnostics-color=never -Os -pedantic-errors -B/users/joel/test-gcc/install-4.9-branch/sparc-rtems4.11/sis/lib/ -specs bsp_specs -qrtems -mcpu=cypress /home2/joel/build/b-sparc-fortran/rtems_gcc_main.o -B/home2/joel/build/b-sparc-fortran/sparc-rtems4.11/./libgfortran/.libs -L/home2/joel/build/b-sparc-fortran/sparc-rtems4.11/./libgfortran/.libs -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o ./f77-edit-x-out.exe PASS: gfortran.dg/g77/f77-edit-x-out.f -Os (test for excess errors) spawn sis -i ./f77-edit-x-out.exe 1 2 3 1 2 3 *** EXIT code 0 PASS: gfortran.dg/g77/f77-edit-x-out.f -Os execution test FAIL: gfortran.dg/g77/f77-edit-x-out.f -Os output pattern test, is 1 2 3 1 2 3 , should match ^1 2 3( | | )1 2 3( | | )$
Re: RTEMS FORTRAN Pattern Failures
Joel Sherrill writes: > FAIL: gfortran.dg/g77/f77-edit-x-out.f -Os output pattern test, is 1 2 3 > 1 2 3 > > , should match ^1 2 3( > | > |)1 2 3( > | > |)$ Where is the \r gone? The pattern has (\n|\r\n|\r). Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: gcc Digest 26 Dec 2014 16:51:42 -0000 Issue 7953
On Mon, Jan 12, 2015 at 07:38:10PM +0300, Andrew Senkevich wrote: > > during work on addition vector math functions to Glibc and discussions > > with community was found an issue with meaning of “#pragma omp declare > > simd” (which will appear in math.h). > > > > Issue is there are no working way to specify ISA of vector function > > in GCC 5.0, and hence no way to determine exact vector function name. > > > > Here is description of exact meaning of “#pragma omp declare simd” for > > x86_64. > > > > This is proposed as agreement between compilers supporting OpenMP. > > > > *** OpenMP vector function ABI for x86_64 *** > > > > Name of vector math function is based on Intel Vector Function ABI > > (http://www.cilkplus.org/sites/default/files/open_specifications/Intel-ABI-Vector-Function-2012-v0.9.5.pdf) > > with a little difference in part of name specifying ISA – namely > > letters b, c, d instead of x, y, Y. > > > > #pragma omp declare simd notinbranch simdlen(2) for some function > > “func” means what the name of vector version is: > > > > _ZGVbN2v_func (it is SSE4 implementation). > > > > #pragma omp declare simd notinbranch simdlen(4) for some function > > “func” means what the following names are available: > > > > _ZGVcN4v_func (it is AVX implementation) > > and > > _ZGVdN4v_func (it is AVX2 implementation). > > > > Every vector function should be provided by math library for each > > supported ISA (currently SSE4, AVX and AVX2). > > Semantics of those pragmas are independent of the processor for which > > code is being generated. > > Those pragmas must not be interpreted as meaning version of other ISA > > of functions are available even if code is being built for a processor > > with such ISA support. > > Any future ABI extension that defines additional vector function > > versions will also define a different pragma to declare their > > availability. > > > > * > > > > Any feedback? > > is this agreement OK? > > Consensus is required to commit x86_64 vector math functions by Glibc > maintainer. With the difference that b stands for SSE2, not SSE4, and the fact that those functions do not use the __regcall calling conventions, but normal psABI calling conventions after replacing the arguments/return values with the vectors documented in the 0.9.5 pdf (and/or adding the vector mask arg) it describes what has been implemented, yes. Jakub
Re: Allocating some Loop allocno in memory
On 2015-01-12 6:33 AM, Ajit Kumar Agarwal wrote: -Original Message- From: Richard Biener [mailto:richard.guent...@gmail.com] Sent: Monday, January 12, 2015 2:33 PM To: Ajit Kumar Agarwal Cc: vmaka...@redhat.com; l...@redhat.com; gcc@gcc.gnu.org; Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala Subject: Re: Allocating some Loop allocno in memory On Sun, Jan 11, 2015 at 4:45 PM, Ajit Kumar Agarwal wrote: -Original Message- From: Richard Biener [mailto:richard.guent...@gmail.com] Sent: Sunday, January 11, 2015 8:05 PM To: Ajit Kumar Agarwal; vmaka...@redhat.com; l...@redhat.com; gcc@gcc.gnu.org Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala Subject: Re: Allocating some Loop allocno in memory On January 11, 2015 5:25:23 AM CET, Ajit Kumar Agarwal wrote: I was thinking of some of the opportunities with respect to reducing spills inside the Loop. If the Live range(allocno) spans through the Loop and Live out at the exit of the Loop and there are no references or not being touched upon inside the Loop, assign the allocno to the memory. This increase the chances of getting the register for other allocno which spans through the Loop and have reference inside the Loop if the interference graph is not colorable. Since allocno don't have references inside the Loop there won't be any load instructions with respect to restore inside the loops. There will be a store instruction with respect to spill which will be outside the Loop. This will reduce the conflicting edges of some of the allocno increasing the chances of making colorable of the Interference graph and reduces the spills and restore inside the Loop. This heuristics looks reasonable. This heuristics goes side by side with the Live range splitting across the Loop boundary. On top of this heuristics, after the Live range splitting across the Loop boundary there interference graph is not colorable then we can assign some of the splitted live ranges in the memory giving chances of registers for the Live ranges(allocno) that spans the Loop and have reference inside the Loop. We can change the cost of allocno in memory based on the above heuristics and take the above factor into consideration for the cost calculation. Thoughts Please? How can this result in better allocations if you only ever spill at life-range split points? The life-range covering the loop should already be assigned to >>memory if required. If the live range covering the loop assigned to memory, and there are references inside the Loops then there are chances of spills inside the loop which degrades the performance. If live range covering the loops and there are no references inside the Loop, then assigning to memory make reasonable as there are no references. Since there are no references or not touched inside the Loop, there won't be load instruction to restore which are required if there are any references. The store which requires for the def of the Live range will be outside the Loops. This helps in not degrading the performances as there are no load and store required for spill and restore inside the Loops. The above heuristics can also be accompanied with heuristics of the number of use points in the Live range. Considering both the heuristics will lead to better allocation if ever spill at the live range split points and there are chances of getting colorable the Interference graph without degrading the performance. Also if the Live range is splitted at the Loop boundary then the spill at the split points of loop boundary and registers is assigned to this live range will make it reasonable if there are no references inside the Loops. But if we split the life-range of not used in-loop-body pseudos at the loop boundary the allocator should do the assignment to memory. There is no need to add another heuristic here. Or do you say we don't split the life-range of such pseudos at loop boundary? In spill_cost calculations we are seeing the function ira_loop_edge_freq triggered with the Live ranges that are live at the exit of the Loop but are not referenced inside the Loops. We are still considering frequency in the updation of spill cost for such live ranges . We have made a change not to consider the freq of such live ranges in the updation of spill cost, thus reducing the cost of such live ranges making it a chance to be in memory giving the conflicting allocno the chances of getting the register. There are chances , the conflicting allocno with respect to loops which have references and will have more edge on getting the registers. The changes are made in the following. https://gcc.gnu.org/ml/gcc/2015-01/msg00033.html I have some doubts that your changes will improve performance. The edge_freq is used in top-bottom loop allocation. If we spilled allocno for given regno in the parent loop, the cost of memory for allocno in the current loop for given regno is
Re: gcc Digest 26 Dec 2014 16:51:42 -0000 Issue 7953
> From: Andrew Senkevich > To: GCC Mailing List , > openmp-...@dcs-maillist2.engr.illinois.edu, libc-alpha > > Cc: > Date: Fri, 26 Dec 2014 19:51:05 +0300 > Subject: OpenMP vector function ABI for x86_64 > Hi, > > during work on addition vector math functions to Glibc and discussions > with community was found an issue with meaning of “#pragma omp declare > simd” (which will appear in math.h). > > Issue is there are no working way to specify ISA of vector function > in GCC 5.0, and hence no way to determine exact vector function name. > > Here is description of exact meaning of “#pragma omp declare simd” for x86_64. > > This is proposed as agreement between compilers supporting OpenMP. > > *** OpenMP vector function ABI for x86_64 *** > > Name of vector math function is based on Intel Vector Function ABI > (http://www.cilkplus.org/sites/default/files/open_specifications/Intel-ABI-Vector-Function-2012-v0.9.5.pdf) > with a little difference in part of name specifying ISA – namely > letters b, c, d instead of x, y, Y. > > #pragma omp declare simd notinbranch simdlen(2) for some function > “func” means what the name of vector version is: > > _ZGVbN2v_func (it is SSE4 implementation). > > #pragma omp declare simd notinbranch simdlen(4) for some function > “func” means what the following names are available: > > _ZGVcN4v_func (it is AVX implementation) > and > _ZGVdN4v_func (it is AVX2 implementation). > > Every vector function should be provided by math library for each > supported ISA (currently SSE4, AVX and AVX2). > Semantics of those pragmas are independent of the processor for which > code is being generated. > Those pragmas must not be interpreted as meaning version of other ISA > of functions are available even if code is being built for a processor > with such ISA support. > Any future ABI extension that defines additional vector function > versions will also define a different pragma to declare their > availability. > > * > > Any feedback? Hi, Jakub, is this agreement OK? Consensus is required to commit x86_64 vector math functions by Glibc maintainer. -- WBR, Andrew
Re: RTEMS FORTRAN Pattern Failures
On 1/12/2015 10:30 AM, Andreas Schwab wrote: > Joel Sherrill writes: > >> FAIL: gfortran.dg/g77/f77-edit-x-out.f -Os output pattern test, is 1 2 3 >> 1 2 3 >> >> , should match ^1 2 3( >> | >> |)1 2 3( >> | >> |)$ > Where is the \r gone? The pattern has (\n|\r\n|\r). I am not exactly sure what you mean but when I run the test by itself from the command and redirect the output to a file, this is what the output looks like: 0002031203233200a0d2031203233200a0d 000 1 2 3 \r \n 1 2 3 \r \n 0100a0d2a2a202a584554496320646f2065 010 \r \n * * * E X I T c o d e 0200d30000a 020 0 \r \n 023 It looks like we have \r\n at the end of each line. Is it possible it is not CR/LF but the EXIT code message confusing the pattern? > Andreas. > -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: Cross compiling and multiple sysroot question
On Thu, 2015-01-08 at 22:12 +, Joseph Myers wrote:
> On Thu, 8 Jan 2015, Steve Ellcey wrote:
>
> > So I set these macros and SPECs:
> > # m32 and be are defaults
> > MULTILIB_OPTIONS = m64 mel # In makefile fragment
> > MULTILIB_DIRNAMES = 64 el # In makefile fragment
> > MULTILIB_OSDIRNAMES = m64=../lib64 # In makefile fragment
>
> In my experience, for such cases it's best to list all multilibs
> explicitly in MULTILIB_OSDIRNAMES, and then to specify
> STARTFILE_PREFIX_SPEC as well along the lines of:
>
> #define STARTFILE_PREFIX_SPEC \
> "%{mabi=32: /usr/local/lib/ /lib/ /usr/lib/} \
>%{mabi=n32: /usr/local/lib32/ /lib32/ /usr/lib32/} \
>%{mabi=64: /usr/local/lib64/ /lib64/ /usr/lib64/}"
Thanks for the help Joseph, this combination worked and I was able to
build a working GCC using this setup.
> GCC never installs anything inside the sysroot (it could be a read-only
> mount of the target's root filesystem, for example). Listing all
> multilibs explicitly (multilib=dir or multilib=!dir) in
> MULTILIB_OSDIRNAMES allows you to ensure they don't overwrite each other.
GCC never installs anything inside sysroot's but some tools that people
have developed to build cross compiler toolchains copy the shared libgcc
libraries (libgcc_s, libstdc++, etc) from the GCC install area into
sysroot as part of the build of a cross compiler toolchain.
I was wondering if I could use the explicit list of MULTILIB_OSDIRNAMES
entries to layout those libraries in a way that would make it easy to
copy them into a sysroot if I wanted to. The only thing I am not sure
about if there is a way to specify where I want the default (no option)
libraries to go.
I.e. I can use:
MULTILIB_OSDIRNAMES += mips64r2=mipsr2/lib32
MULTILIB_OSDIRNAMES += mips64r2/mabi.64=mipsr2/lib64
To create a mipsr2/lib32 and mipsr2/lib64 directory under /lib
for libgcc_s but I would like the default libraries in
/lib/mipsr2/lib instead of directly in /lib. That way I
could use a single copy to put all of /lib/mipsr2 into my
sysroot. Do you know if either of these would work:
MULTILIB_OSDIRNAMES += mips32r2=mipsr2/lib
MULTILIB_OSDIRNAMES += .=mipsr2/lib
I don't think the first one would work because -mips32r2 is the default
architecture and is not explicitly listed in MULTILIB_OPTIONS and I
don't think the second form is supported at all, but maybe there is some
other way to specify the location of the default libraries?
Steve Ellcey
sell...@imgtec.com
Re: RTEMS FORTRAN Pattern Failures
Joel Sherrill writes: > On 1/12/2015 10:30 AM, Andreas Schwab wrote: >> Joel Sherrill writes: >> >>> FAIL: gfortran.dg/g77/f77-edit-x-out.f -Os output pattern test, is 1 2 3 >>> 1 2 3 >>> >>> , should match ^1 2 3( >>> | >>> |)1 2 3( >>> | >>> |)$ >> Where is the \r gone? The pattern has (\n|\r\n|\r). > I am not exactly sure what you mean but when I run the test There is a \r missing inside the paren subexpressions of the pattern as written in the log file, so that it can no longer match \r\n from the output. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Cross compiling and multiple sysroot question
On Mon, 12 Jan 2015, Steve Ellcey wrote: > MULTILIB_OSDIRNAMES += mips32r2=mipsr2/lib > MULTILIB_OSDIRNAMES += .=mipsr2/lib > > I don't think the first one would work because -mips32r2 is the default > architecture and is not explicitly listed in MULTILIB_OPTIONS and I > don't think the second form is supported at all, but maybe there is some > other way to specify the location of the default libraries? The default libraries for x86_64-linux-gnu go in ../lib64, so it's clearly possible by doing something sufficiently similar to how it's done for x86_64. -- Joseph S. Myers jos...@codesourcery.com
Re: RTEMS FORTRAN Pattern Failures
Joel Sherrill wrote: On 1/12/2015 10:30 AM, Andreas Schwab wrote: Joel Sherrill writes: FAIL: gfortran.dg/g77/f77-edit-x-out.f -Os output pattern test, is 1 2 3 1 2 3 , should match ^1 2 3( | |)1 2 3( | |)$ Where is the \r gone? The pattern has (\n|\r\n|\r). I am not exactly sure what you mean but when I run the test by itself from the command and redirect the output to a file, this is what the output looks like: 0002031203233200a0d2031203233200a0d 000 1 2 3 \r \n 1 2 3 \r \n 0100a0d2a2a202a584554496320646f2065 010 \r \n * * * E X I T c o d e 0200d30000a 020 0 \r \n 023 It looks like we have \r\n at the end of each line. Is it possible it is not CR/LF but the EXIT code message confusing the pattern? Contrary to Andreas, I do see \r in run.txt – at least when I look at the file when saved from Thunderbird. Namely, the output is (sp = space, nl = \n, cr = \r): 1 sp 2 sp sp 3 cr cr nl 1 sp 2 sp sp 3 cr cr nl cr cr nl *** EXIT code 0 cr cr nl Namely: I do not see CR-NL but CR-CR-NL. That looks rather odd and does not match what you get when you manually run the program. Looing at other lines like "spawn sis -i ./f77-edit-x-out.exe", they have a CR-NL, i.e. only a single CR. Thus, the question is what inserts an additional "\r" into the output. Additionally, I think you are right that the "*** EXIT code 0" also causes problems with the pattern. Can you try the following: a) Replace the pattern by "1 2 3(\n|\r\r\n|\r)" (twice), note the duplicated "\r" b) Remove the "dg-output "\$" line [Best would be if you could try them also separately.] My bet would be that doing (a) and (b) will succeed, while only (a) and (b) will fail. If using (a) [alone or together with (b)] works, you should really find out what inserts the "\r", especially as it does not appear if you manually run the program. "\r\r\n" is definitely not a pattern I would like to see in the test file. If (b) works [alone or together with (a)]: Any chance that you silence the "\r\r\n*** EXIT code 0\r\r\n" output? I think it could potentially confuse other test cases and it doesn't belong there. – I am also inclined not to remove the '\$', unless there are very compelling reasons to do so. Tobias
Re: IRA : Changes in the cost of putting allocno into memory.
On 01/08/15 04:00, Ajit Kumar Agarwal wrote: Hello Vladimir: We have made the changes in the ira-color.c in ira_loop_edge_freq and move_spill_restore. The main motivation behind the change is to reduce the memory instruction with respect to the Loops. The changes are done to not to consider the back edge frequency if there are no references of the allocno inside the loop even though the allocno are live out at the exit of the Loop and Live In at the entry of the Loop. This will reduce the calculation of the cost of putting allocno into memory. If we reduce the cost of putting allocno into memory, then there are chances of getting color in the simplification phase of the gcc IRA register allocator. Enabling this, there are chances of putting the allocno in the register and the splitting phase will split the live range across the Loop boundary. This will beneficial with respect to reducing memory instruction inside the Loop. Other changes is done to enable some of the allocno to allocate in memory if the cost is less than equal to zero. This is the first phase of the change in the IRA core register module, I would like to get your feedbacks on this change based on this the actual patch is sent. The changes are accompanied with the patch created for the change which will be easier for you to review the change. We have tested the changes for Microblaze target for MIBENCH and EEMBC benchmarks and there are no degradation in the Geomean and some of the Mibench and EEMBC benchmarks is benefitted with this change. Please review the changes and let me know your feedbacks and other steps needs to be done to incorporate the changes in the Upstream". We would like to get this change for Microblaze, Please also let us know if the changes are required to be enabled with any switch flag. There's a lot of similarities between this and one aspect of Morgan's register pressure reduction schemes. I believe he refers to objects of this nature as transparent across the loop (value is live across the loop, but neither set nor referenced in the loop -- ie, it's just holding a resource across the loop). If a loop has high register pressure, then homing these kind of objects in memory across the loop will reduce the register pressure in the loop and presumably allow some other objects with more value to live in a register inside the loop. Of course, if there is little pressure in the loop, then homing to memory is a waste. Your approach of ignoring backedge frequency for cost calculation of these objects is interesting in that it tries to capture the benefits of Morgan-esque pressure reduction without regressing in cases where the pressure is not high. If you've got data which does this does not regress on a more mainstream target and that it bootstrapps and regression tests on a mainstream target (x86_64 is by far the most popular), then I'd seriously consider approving this. Jeff
Re: IRA : Changes in the cost of putting allocno into memory.
On 2015-01-12 2:25 PM, Jeff Law wrote: On 01/08/15 04:00, Ajit Kumar Agarwal wrote: Hello Vladimir: We have made the changes in the ira-color.c in ira_loop_edge_freq and move_spill_restore. The main motivation behind the change is to reduce the memory instruction with respect to the Loops. The changes are done to not to consider the back edge frequency if there are no references of the allocno inside the loop even though the allocno are live out at the exit of the Loop and Live In at the entry of the Loop. This will reduce the calculation of the cost of putting allocno into memory. If we reduce the cost of putting allocno into memory, then there are chances of getting color in the simplification phase of the gcc IRA register allocator. Enabling this, there are chances of putting the allocno in the register and the splitting phase will split the live range across the Loop boundary. This will beneficial with respect to reducing memory instruction inside the Loop. Other changes is done to enable some of the allocno to allocate in memory if the cost is less than equal to zero. This is the first phase of the change in the IRA core register module, I would like to get your feedbacks on this change based on this the actual patch is sent. The changes are accompanied with the patch created for the change which will be easier for you to review the change. We have tested the changes for Microblaze target for MIBENCH and EEMBC benchmarks and there are no degradation in the Geomean and some of the Mibench and EEMBC benchmarks is benefitted with this change. Please review the changes and let me know your feedbacks and other steps needs to be done to incorporate the changes in the Upstream". We would like to get this change for Microblaze, Please also let us know if the changes are required to be enabled with any switch flag. There's a lot of similarities between this and one aspect of Morgan's register pressure reduction schemes. I believe he refers to objects of this nature as transparent across the loop (value is live across the loop, but neither set nor referenced in the loop -- ie, it's just holding a resource across the loop). If a loop has high register pressure, then homing these kind of objects in memory across the loop will reduce the register pressure in the loop and presumably allow some other objects with more value to live in a register inside the loop. Of course, if there is little pressure in the loop, then homing to memory is a waste. Your approach of ignoring backedge frequency for cost calculation of these objects is interesting in that it tries to capture the benefits of Morgan-esque pressure reduction without regressing in cases where the pressure is not high. Ignoring loop back-edges is a right idea but it is already implemented in IRA from the start. On enter we already ignore back edge to the loop header with condition: e->src == loop_node->loop->latch on exit we consider edges only get_loop_exit_edges (loop_node->loop) The patch does not exclude back edges (they are already excluded), it excludes all edges from the consideration for the transparent pseudos. In other words, the patch ignores any allocation in the parent loop. IMO it should not do this, with this patch we can spill pseudo even if the pseudo is allocated to hard reg and there are enough regs to keep the transparent pseudo in the register. If you've got data which does this does not regress on a more mainstream target and that it bootstrapps and regression tests on a mainstream target (x86_64 is by far the most popular), then I'd seriously consider approving this. I've just got results of the patch for the SPEC2000: The patch worsens the code on x86-64 SPEC2000 (5094 vs 5104 on SPECInt and 7125 vs 7137 on SPECFP). The patch also results in slightly bigger average code (0.003% and 0.03% correspondingly for Int and FP benchmarks) So I believe the patch is no go.
RE: Cross compiling and multiple sysroot question
> On Mon, 12 Jan 2015, Steve Ellcey wrote: > > > MULTILIB_OSDIRNAMES += mips32r2=mipsr2/lib MULTILIB_OSDIRNAMES += > > .=mipsr2/lib > > > > I don't think the first one would work because -mips32r2 is the > > default architecture and is not explicitly listed in MULTILIB_OPTIONS > > and I don't think the second form is supported at all, but maybe there > > is some other way to specify the location of the default libraries? > > The default libraries for x86_64-linux-gnu go in ../lib64, so it's > clearly possible by doing something sufficiently similar to how it's > done for x86_64. MIPS does this too for mips64-linux-gnu as it has n32 for the default multilib which gets placed in lib32. I don't honestly know how the multilib spec doesn't end up building 4 multilibs though. I'm assuming the fact that the default ABI is added to the DRIVER_SELF_SPECS may be the reason. t-linux64: MULTILIB_OPTIONS = mabi=n32/mabi=32/mabi=64 MULTILIB_DIRNAMES = n32 32 64 MIPS_EL = $(if $(filter %el, $(firstword $(subst -, ,$(target,el) MIPS_SOFT = $(if $(strip $(filter MASK_SOFT_FLOAT_ABI, $(target_cpu_default)) $(filter soft, $(with_float))),soft) MULTILIB_OSDIRNAMES = \ ../lib32$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \ ../lib$(call if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \ ../lib64$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT)) Matthew
Re: RTEMS FORTRAN Pattern Failures
On 1/12/2015 1:14 PM, Tobias Burnus wrote:
> Joel Sherrill wrote:
>> On 1/12/2015 10:30 AM, Andreas Schwab wrote:
>>> Joel Sherrill writes:
>>>
FAIL: gfortran.dg/g77/f77-edit-x-out.f -Os output pattern test, is 1 2 3
1 2 3
, should match ^1 2 3(
|
|)1 2 3(
|
|)$
>>> Where is the \r gone? The pattern has (\n|\r\n|\r).
>> I am not exactly sure what you mean but when I run the test
>> by itself from the command and redirect the output to a file,
>> this is what the output looks like:
>>
>> 0002031203233200a0d2031203233200a0d
>> 000 1 2 3 \r \n 1 2 3 \r \n
>> 0100a0d2a2a202a584554496320646f2065
>> 010 \r \n * * * E X I T c o d e
>> 0200d30000a
>> 020 0 \r \n
>> 023
>>
>> It looks like we have \r\n at the end of each line.
>>
>> Is it possible it is not CR/LF but the EXIT code message confusing the
>> pattern?
> Contrary to Andreas, I do see \r in run.txt – at least when I look at
> the file when saved from Thunderbird. Namely, the output is (sp = space,
> nl = \n, cr = \r):
>
> 1 sp 2 sp sp 3 cr cr nl
> 1 sp 2 sp sp 3 cr cr nl
> cr cr nl
> *** EXIT code 0 cr cr nl
run.txt is the cut and paste of the log file which reflects DejaGNU's
view of the
run. I think that means we are looking at output from the verbose command
invoked here in remote.exp around line 1030:
verbose -log "Executed $prog, status $status" 2
if {![string match "" $output]} {
verbose -log -- "$output" 2
}
> Namely: I do not see CR-NL but CR-CR-NL. That looks rather odd and does
> not match what you get when you manually run the program. Looing at
> other lines like "spawn sis -i ./f77-edit-x-out.exe", they have a CR-NL,
> i.e. only a single CR. Thus, the question is what inserts an additional
> "\r" into the output.
I think it is the verbose procedure in runtest.exp. It sets "newline" to 1
and prints all messages including "Executing on host:..." with a newline.
Double check me on that.
>
> Additionally, I think you are right that the "*** EXIT code 0" also
> causes problems with the pattern.
Details below but this is standard DejaGNU output when the target
doesn't return
an exit code.
> Can you try the following:
>
> a) Replace the pattern by "1 2 3(\n|\r\r\n|\r)" (twice), note the
> duplicated "\r"
> b) Remove the "dg-output "\$" line
>
> [Best would be if you could try them also separately.] My bet would be
> that doing (a) and (b) will succeed, while only (a) and (b) will fail.
>
>
> If using (a) [alone or together with (b)] works, you should really find
> out what inserts the "\r", especially as it does not appear if you
> manually run the program. "\r\r\n" is definitely not a pattern I would
> like to see in the test file.
I assume the file in question is
gcc/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f
(a) alone didn't make it pass.
(b) alone didn't make it pass.
(a) and (b) together did not make it pass
Does this file get copied or something else during the process that
would eliminate
edits having an impact?
> If (b) works [alone or together with (a)]: Any chance that you silence
> the "\r\r\n*** EXIT code 0\r\r\n" output? I think it could potentially
> confuse other test cases and it doesn't belong there. – I am also
> inclined not to remove the '\$', unless there are very compelling
> reasons to do so.
The "***EXIT code ..." message is the standard DejaGNU message which is used
on targets which do not directly return an exit code. This is in testglue.c
in the DejaGNU installation. Look in the body of ORIG_EXIT. It is
/usr/share/dejagnu/testglue.c on the computer I am here.
If it is the ***EXIT line and the compare really doesn't see the \r,
what would be
needed to try that?
Is there an easy way to take out.txt and just force it against this .exp
pattern?
>
> Tobias
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Re: RTEMS FORTRAN Pattern Failures
Joel Sherrill wrote:
run.txt is the cut and paste of the log file which reflects DejaGNU's
view of the run.
Which means that it hopefully matches every bit of the original output
and that no editor interferes by adding or removing line breaks.
Additionally, I think you are right that the "*** EXIT code 0" also
causes problems with the pattern.
Details below but this is standard DejaGNU output when the target
doesn't return
an exit code.
Good to know. If the pattern is known, one can add it to the pattern.
Can you try the following:
a) Replace the pattern by "1 2 3(\n|\r\r\n|\r)" (twice), note the
duplicated "\r"
b) Remove the "dg-output "\$" line
[Best would be if you could try them also separately.] My bet would be
that doing (a) and (b) will succeed, while only (a) and (b) will fail.
If using (a) [alone or together with (b)] works, you should really find
out what inserts the "\r", especially as it does not appear if you
manually run the program. "\r\r\n" is definitely not a pattern I would
like to see in the test file.
I assume the file in question is
gcc/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f
Yes.
(a) alone didn't make it pass.
(b) alone didn't make it pass.
(a) and (b) together did not make it pass
Does this file get copied or something else during the process that
would eliminate edits having an impact?
I don't think so. Too bad that it didn't seem to help.
Is there an easy way to take out.txt and just force it against this
.exp pattern?
Well, you could try whether PERL is able to match it, i.e. something
like "cat file | perl ..." if you manage to get the exact output into a
file (esp. with the right number of \r and \n, including the last line).
I don't know whether that's really identical but it should come close to
how DejaGNU matches the pattern.
Example - I use printf instead of a file:
printf '1 2 3\n1 2 3\n\n*** EXIT code 0' \
| perl -e '$in = join("", ); if ($in =~ m/^1 2 3(\n|\r\n|\r)1
2 3(\n|\r\n|\r)((\n|\r\n|\r)\*\*\* EXIT code 0)?$/s) { print
"matched\n" } else { print "not matched\n" };'
Tobias
RE: Cross compiling and multiple sysroot question
On Mon, 12 Jan 2015, Matthew Fortune wrote: > MIPS does this too for mips64-linux-gnu as it has n32 for the default > multilib which gets placed in lib32. I don't honestly know how the multilib > spec doesn't end up building 4 multilibs though. I'm assuming the fact > that the default ABI is added to the DRIVER_SELF_SPECS may be the reason. I suspect MULTILIB_DEFAULTS is relevant. -- Joseph S. Myers jos...@codesourcery.com
Re: RTEMS FORTRAN Pattern Failures
On 1/12/2015 2:49 PM, Tobias Burnus wrote:
> Joel Sherrill wrote:
>> run.txt is the cut and paste of the log file which reflects DejaGNU's
>> view of the run.
> Which means that it hopefully matches every bit of the original output
> and that no editor interferes by adding or removing line breaks.
>
>
>> Additionally, I think you are right that the "*** EXIT code 0" also
>> causes problems with the pattern.
>> Details below but this is standard DejaGNU output when the target
>> doesn't return
>> an exit code.
> Good to know. If the pattern is known, one can add it to the pattern.
>
>
>>> Can you try the following:
>>>
>>> a) Replace the pattern by "1 2 3(\n|\r\r\n|\r)" (twice), note the
>>> duplicated "\r"
>>> b) Remove the "dg-output "\$" line
>>>
>>> [Best would be if you could try them also separately.] My bet would be
>>> that doing (a) and (b) will succeed, while only (a) and (b) will fail.
>>>
>>>
>>> If using (a) [alone or together with (b)] works, you should really find
>>> out what inserts the "\r", especially as it does not appear if you
>>> manually run the program. "\r\r\n" is definitely not a pattern I would
>>> like to see in the test file.
>> I assume the file in question is
>> gcc/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f
> Yes.
>
>> (a) alone didn't make it pass.
>> (b) alone didn't make it pass.
>> (a) and (b) together did not make it pass
>>
>> Does this file get copied or something else during the process that
>> would eliminate edits having an impact?
> I don't think so. Too bad that it didn't seem to help.
>
>> Is there an easy way to take out.txt and just force it against this
>> .exp pattern?
> Well, you could try whether PERL is able to match it, i.e. something
> like "cat file | perl ..." if you manage to get the exact output into a
> file (esp. with the right number of \r and \n, including the last line).
> I don't know whether that's really identical but it should come close to
> how DejaGNU matches the pattern.
>
> Example - I use printf instead of a file:
>
> printf '1 2 3\n1 2 3\n\n*** EXIT code 0' \
>| perl -e '$in = join("", ); if ($in =~ m/^1 2 3(\n|\r\n|\r)1
> 2 3(\n|\r\n|\r)((\n|\r\n|\r)\*\*\* EXIT code 0)?$/s) { print
> "matched\n" } else { print "not matched\n" };'
That was very close.
cat out.txt | \
perl -e '$in = join("", ); if ($in =~ m/^1 2 3(\n|\r\n|\r)1 2
3(\n|\r\n|\r)((\n|\r\n|\r)\*\*\* EXIT code 0)(\n|\r\n|\r)?$/s) { print
"matched\n" } else { print "not matched\n" };'
I think I mainly fixed the first line to have two spaces between the 2 and 3
and added another the EOL pattern at the end.
That just leaves translating that back into DejaGNU/Expect. :)
> Tobias
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Re: RTEMS FORTRAN Pattern Failures
Hi Joel,
Am 12.01.2015 um 22:04 schrieb Joel Sherrill:
That was very close.
cat out.txt | \
perl -e '$in = join("", ); if ($in =~ m/^1 2 3(\n|\r\n|\r)1 2
3(\n|\r\n|\r)((\n|\r\n|\r)\*\*\* EXIT code 0)(\n|\r\n|\r)?$/s) { print
"matched\n" } else { print "not matched\n" };'
That won't work on systems which don't print EXIT. You have to move the
")" from after the "0" to before the "?" to make the whole part as
optional (the ? applies to the preceding token).
I think I mainly fixed the first line to have two spaces between the 2 and 3
and added another the EOL pattern at the end.
The former was a bug (feature) of Thunderbird, which ate the second
space, the second, I forgot.
That just leaves translating that back into DejaGNU/Expect. :)
Well, that's simple: Either remove all "dg-output" from the test case
and add the string between "m/" and "/s" instead of ... in
C { dg-output "..." }
You additionally have to change "\*" to "\\*" and "$" to "\$".
Or, alternatively, only modify the last "dg-output" by replacing "\$" by
the string starting with "((" and ending with "$". (Again, you have to
replace \* by \\* and $ by \$.)
That should be all. I wonder whether that now works or still fails.
Can you try whether this works (see attachment)?
Tobias
diff --git a/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f b/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f
index 13a9d7a..4aacd4d 100644
--- a/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f
+++ b/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f
@@ -8,5 +8,5 @@ C { dg-output "^" }
write(*,'(I1,1X,I1,2X,I1)') 1,2,3! { dg-output "1 2 3(\n|\r\n|\r)" }
C Section 13.5.3 explains why there are no trailing blanks
write(*,'(I1,1X,I1,2X,I1,3X)') 1,2,3 ! { dg-output "1 2 3(\n|\r\n|\r)" }
-C { dg-output "\$" }
+C { dg-output "((\n|\r\n|\r)\\*\\*\\* EXIT code 0(\n|\r\n|\r))?\$" }
end
RE: Cross compiling and multiple sysroot question
On Mon, 2015-01-12 at 20:58 +, Joseph Myers wrote:
> On Mon, 12 Jan 2015, Matthew Fortune wrote:
>
> > MIPS does this too for mips64-linux-gnu as it has n32 for the default
> > multilib which gets placed in lib32. I don't honestly know how the multilib
> > spec doesn't end up building 4 multilibs though. I'm assuming the fact
> > that the default ABI is added to the DRIVER_SELF_SPECS may be the reason.
>
> I suspect MULTILIB_DEFAULTS is relevant.
The problem I ran into with MULTILIB_DEFAULTS is that if you have:
MULTILIB_DEFAULTS = { mips32r2 }
MULTILIB_OPTIONS = mips32r2/mips64r2 mabi=64 EL
If you try to use:
MULTILIB_EXCEPTIONS = mips32r2/mabi=64*
It doesn't work. The mips32r2 option seems to be stripped off before
MULTILIB_EXCEPTIONS is applied. You need to use this instead:
MULTILIB_EXCEPTIONS = mabi=64*
Which is the same as you would use if you didn't specify mips32r2 in
MULTILIB_OPTIONS at all. I expect MULTILIB_OSDIRNAMES to work the same
way and ignore any mapping entries with the mips32r2 option but maybe I
am wrong (I'm still testing it out).
Steve Ellcey
sell...@imgtec.com
Re: RTEMS FORTRAN Pattern Failures
On 1/12/2015 3:18 PM, Tobias Burnus wrote:
> Hi Joel,
>
> Am 12.01.2015 um 22:04 schrieb Joel Sherrill:
>> That was very close.
>>
>> cat out.txt | \
>>perl -e '$in = join("", ); if ($in =~ m/^1 2 3(\n|\r\n|\r)1 2
>> 3(\n|\r\n|\r)((\n|\r\n|\r)\*\*\* EXIT code 0)(\n|\r\n|\r)?$/s) { print
>> "matched\n" } else { print "not matched\n" };'
> That won't work on systems which don't print EXIT. You have to move the
> ")" from after the "0" to before the "?" to make the whole part as
> optional (the ? applies to the preceding token).
That should be this:
cat out.txt | \
perl -e '$in = join("", ); if ($in =~ m/^1 2 3(\n|\r\n|\r)1 2
3(\n|\r\n|\r)((\n|\r\n|\r)\*\*\* EXIT code 0(\n|\r\n|\r))?$/s) { print
"matched\n" } else { print "not matched\n" };'
>> I think I mainly fixed the first line to have two spaces between the 2 and 3
>> and added another the EOL pattern at the end.
> The former was a bug (feature) of Thunderbird, which ate the second
> space, the second, I forgot.
:) I wondered about that when I started this thread. I almost compressed the
files I attached to avoid mailer issues.
>> That just leaves translating that back into DejaGNU/Expect. :)
> Well, that's simple: Either remove all "dg-output" from the test case
> and add the string between "m/" and "/s" instead of ... in
>
> C { dg-output "..." }
>
> You additionally have to change "\*" to "\\*" and "$" to "\$".
>
> Or, alternatively, only modify the last "dg-output" by replacing "\$" by
> the string starting with "((" and ending with "$". (Again, you have to
> replace \* by \\* and $ by \$.)
>
> That should be all. I wonder whether that now works or still fails.
>
> Can you try whether this works (see attachment)?
I tried it and it didn't work. :(
> Tobias
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Announcing Marek Polacek as C front-end reviewer
I'm pleased to announce that Marek Polacek has been appointed as a reviewer for the C front-end. Marek, please add yourself as a reviewer for the C front end in the MAINTAINERS file. Jeff
Announcing Iain Sandoe as Objective-C/C++ maintainer
I'm pleased to announce that Iain Sandoe has been appointed as a maintainer for the Objective-C and Objective-C++ front-ends. Iain, please add yourself as a maintainer for those front-ends in the MAINTAINERS file. Jeff
