RE: exposing SH's fpscr support
On 01 May 2006 20:55, DJ Delorie wrote:
> At this point, I would like some feedback about the API and how to
> cleanly (namespace-wise) add it to libgcc.a.
Um, I know it's a bit bikeshedcolour, and sorry about that, but wouldn't a
target-dependent builtin be a better fit to this kind of problem? A
subroutine call just to fetch/modify a cpu register seems a bit heavy. Maybe
at -Os, given that this is an embedded target, but even so.
Otherwise this sort of thing should live in the main C lib, the way
fpu_control.h and feset/getround/etc. do, shouldn't it?
> #define FR 0x0020
> #define SZ 0x0010
> #define PR 0x0008
> #define DN 0x0004
> #define RN 0x0003
> #define RN_N 0
> #define RN_Z 1
A name like 'SZ' is highly likely to collide with a lot of applications if
its in the same namespace, isn't it?
> extern int __fpscr_values[2];
> void
> change_fpscr(int off, int on)
> {
> int b = get_fpscr();
> off = ~off;
> off |= 0x0018;
> on &= ~ 0x0018;
:) Shouldn't that be (SZ | PR) since you went to the effort of defining
them anyway?
> b &= off;
> b |= on;
> put_fpscr(b);
See, this is all nice simple stuff that would optimise beautifully if it was
emitted as inline rtl.
> __fpscr_values[0] &= off;
> __fpscr_values[0] |= on;
> __fpscr_values[1] &= off;
> __fpscr_values[1] |= on;
Ok, I'll bite. Why are there two of them?!
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: gcc-3.4.6 and pdp11
On 01 May 2006 19:43, Bill Cunningham wrote: > I would like to know who supports pdp11 for 3.4.6 or even the latest 4.x > version of gcc? Is it still being maintained ? I'm trying to cross compile a > pdp11 on my i686 and I'm having problems. If I can talk to the maintainer(s) > I can get some help and maybe even get involved in pdp11 support. According to the MAINTAINERS file, you're doing the right thing by posting to the main list here: "This file contains information about people who are permitted to make changes to various parts of the compiler and associated libraries. Please do not contact the people in this file directly to report problems in GCC. For general information about GCC, please visit: http://gcc.gnu.org To report problems in GCC, please visit: http://gcc.gnu.org/bugs.html"; It also lists Paul Koning as current maintainer of the pdp11 port. As per the request, there's no need to contact him directly, but if you have a solid bug report, file it in bugzilla and he will surely see it. If you suspect you're just having trouble with the cross-compile procedure but haven't identified an actual bug in gcc, general advice and help can be had from the crossgcc list. cheers, DaveK -- Can't think of a witty .sigline today
Dynamically generated code and DWARF exception handling
Hi We have an application compiled with gcc written in C++. This application generates dynamically code and executes it, using a JIT, a Just In time Compiler. Everything is working OK until the C++ code generates a throw. To get to the corresponding catch, the runtime should skip through the intermediate frames in assembler generated by the JIT. We would like to know how should be the interface with gcc to do this. We thought for a moment that using sjlj_exceptions it would work, but we fear that this is no longer being maintained. 1) Is this true? 2) Can we use sjlj exception under linux safely? Otherwise, would it be possible to generate the DWARF Tables and add those tables dynamically to the running program? Under windows, Microsoft provides an API for JITs that does exactly that. Is there an equivalent API for linux? Thanks in advancefor any information about this. jacob
Signedness of fortran size_type_node
Hello, I have just noticed that size_type_node is signed in fortran frontend (it caused an ice for me because unsigned_type_for returns it for pointers, and I inserted an assert that the result of unsigned_type_for is unsigned). According to the comment in tree.h, size_type_node should correspond to "The C type `size_t'", and standard specifies that size_t is unsigned. Is this a bug in fortran frontend, or is size_type_node intentionally set in a different way? Zdenek
Re: Signedness of fortran size_type_node
On 5/2/06, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: Hello, I have just noticed that size_type_node is signed in fortran frontend (it caused an ice for me because unsigned_type_for returns it for pointers, and I inserted an assert that the result of unsigned_type_for is unsigned). According to the comment in tree.h, size_type_node should correspond to "The C type `size_t'", and standard specifies that size_t is unsigned. Is this a bug in fortran frontend, or is size_type_node intentionally set in a different way? Nothing uses size_type_node in the fortran frontend, so it's surely a bug there. Also there is the (the bogus) 2003-08-19 Diego Novillo <[EMAIL PROTECTED]> * trans-types.c (gfc_init_types): Initialize signed_size_type_node with size_type_node. Richard.
Re: Signedness of fortran size_type_node
On 5/2/06, Richard Guenther <[EMAIL PROTECTED]> wrote: On 5/2/06, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: > Hello, > > I have just noticed that size_type_node is signed in fortran frontend > (it caused an ice for me because unsigned_type_for returns it for > pointers, and I inserted an assert that the result of unsigned_type_for > is unsigned). > > According to the comment in tree.h, size_type_node should correspond to > "The C type `size_t'", and standard specifies that size_t is unsigned. > > Is this a bug in fortran frontend, or is size_type_node intentionally > set in a different way? Nothing uses size_type_node in the fortran frontend, so it's surely a bug there. Also there is the (the bogus) 2003-08-19 Diego Novillo <[EMAIL PROTECTED]> * trans-types.c (gfc_init_types): Initialize signed_size_type_node with size_type_node. Same problem for Ada: /* In Ada, we use a signed type for SIZETYPE. Use the signed type corresponding to the size of Pmode. In most cases when ptr_mode and Pmode differ, C will use the width of ptr_mode as sizetype. But we get far better code using the width of Pmode. Make this here since we need this before we can expand the GNAT types. */ size_type_node = gnat_type_for_size (GET_MODE_BITSIZE (Pmode), 0); set_sizetype (size_type_node); though there it seems to be intentional!? Richard.
libiberty
Everytime I compile gcc I see that libiberty is being compiled. Is this a needed library and if not how can I switch it off? I'm using glibc-2.1 and I'd like to figure out compiling 2.3 and I've done it before so I just have to remember how. I want to cut down on all that compile time. Bill
RE: libiberty
On 02 May 2006 14:09, Bill Cunningham wrote: > Everytime I compile gcc I see that libiberty is being compiled. Is this > a needed library Yes. Gcc uses the support functions it provides. It's compiled and statically linked in to the new gcc. > I'm using glibc-2.1 and > I'd like to figure out compiling 2.3 and I've done it before so I just have > to remember how. You've lost me there. I thought you said you were compiling gcc? Or do you mean you're doing it as part of a combined-tree-build? In any case, libiberty is vital. And small and quick to build. 'fraid I don't have much useful advice on how to cut down your build times except maybe to use a --disable-checking compiler. cheers, DaveK -- Can't think of a witty .sigline today
Fwd: Problem with OpenMP Reduction Clause
FYI. Begin forwarded message: From: "Benjamin Réveillé" <[EMAIL PROTECTED]> Date: May 2, 2006 7:44:38 AM PDT To: [EMAIL PROTECTED] Subject: Problem with OpenMP Reduction Clause Hello I've stumbled onto a problem with the OpenMP REDUCTION clause Here is the reduced code array_reduction.f90 ## program array_reduction implicit none integer, parameter :: n=10,m=1000 integer :: i integer, dimension(n) :: sumarray ! call foo(n,m,sumarray) do i=1,n print*,sumarray(i) end do end program array_reduction subroutine foo(n,m,sumarray) use omp_lib, only : omp_get_thread_num implicit none integer, intent(in) :: n,m integer, dimension(n), intent(out) :: sumarray ! integer :: i,j ! sumarray(:)=0 !$OMP PARALLEL DEFAULT(shared) print*,'hello from thread ',omp_get_thread_num() !$OMP DO PRIVATE(j,i), REDUCTION(+:sumarray) do j=1,m do i=1,n sumarray(i)=sumarray(i)+i end do end do !$OMP END DO !$OMP END PARALLEL end subroutine foo ## pgi 6.1 and xlf10.1 both compile and execute with the following correct output: hello from thread 1 hello from thread 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 1 Intel 9.1 compiles but [Abort]s on execution. gfortran Using built-in specs. Target: i386-linux Configured with: ../gcc/configure --prefix=/cosmic/coudert/tmp/gfortran-20060502/irun --enable-languages=c,fortran --host=i386-linux --with-gmp=/cosmic/coudert/tmp/gfortran-20060502/gfortran_libs Thread model: posix gcc version 4.2.0 20060502 (experimental) gfortran segfault on compile (gfortran -fopenmp array_reduction.f90) with the following message: arrayreduction.f90: In function 'foo': arrayreduction.f90:14: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. My understanding (from following the mailing list) is that the segfault itself is a gfortran bug... Should I therefore file one ? My 2nd question is is the coding valid ??? From reading page 83 of the OpenMP 2.5 Specifications (http://www.openmp.org/drupal/mp-documents/spec25.pdf) I tend to think that sumarray is a valid array for the REDUCTION clause. I wonder still since INTEL compilers seem to have a problem with it too. Thanks for your help
Ada
Are there any special switches or options needed to compile the ada package with the core gcc? I add the C++ libraries and they compile right along with the core. I've tried --enable-languages=c,c++,ada too and that doesn't do the ada libraries. Bill
GCC FAIL WITH BASIC STL EXAMPLE
Hello Guys,
I am developing some applications that extensively uses STL. I plan to use
the
traits -> iterator_traits to get information about which type do I need to
return.
Unfortunately, I've been experienced some problems to use such
functionality.
This simple test code was extracted from the SGI-STL website, but oddly
enough it doesn't compile:
#include
#include
#include
#include
template
std::iterator_traits::value_type
last_value(InputIterator first, InputIterator last) {
std::iterator_traits::value_type result = *first;
for (++first; first != last; ++first)
result = *first;
return result;
}
using namespace std;
int main()
{
std::vector teste(10);
fill_n(teste.begin(),10,1.2);
double result = last_value(teste.begin(),teste.end());
return 0;
}
The error response is:
argdeduction.cpp:8: error: expected constructor, destructor, or type
conversion before ‘last_value’
argdeduction.cpp: In function ‘int main()’:
argdeduction.cpp:21: error: ‘last_value’ was not declared in this scope
Hopefully,
Trincheira
--
View this message in context:
http://www.nabble.com/GCC-FAIL-WITH-BASIC-STL-EXAMPLE-t1539516.html#a4182424
Sent from the gcc - Dev forum at Nabble.com.
GCC FAIL WITH BASIC STL EXAMPLE
Hello Guys,
I am developing some applications that extensively uses STL. I plan to use
the
traits -> iterator_traits to get information about which type do I need to
return.
Unfortunately, I've been experienced some problems to use such
functionality.
This simple test code was extracted from the SGI-STL website, but oddly
enough it doesn't compile:
#include
#include
#include
#include
template
std::iterator_traits::value_type
last_value(InputIterator first, InputIterator last) {
std::iterator_traits::value_type result = *first;
for (++first; first != last; ++first)
result = *first;
return result;
}
using namespace std;
int main()
{
std::vector teste(10);
fill_n(teste.begin(),10,1.2);
double result = last_value(teste.begin(),teste.end());
return 0;
}
The error response is:
argdeduction.cpp:8: error: expected constructor, destructor, or type
conversion before ‘last_value’
argdeduction.cpp: In function ‘int main()’:
argdeduction.cpp:21: error: ‘last_value’ was not declared in this scope
Hopefully,
Trincheira
--
View this message in context:
http://www.nabble.com/GCC-FAIL-WITH-BASIC-STL-EXAMPLE-t1539517.html#a4182425
Sent from the gcc - Dev forum at Nabble.com.
Re: GCC FAIL WITH BASIC STL EXAMPLE
On Tue, 2006-05-02 at 08:26 -0700, trincheira wrote:
> Hello Guys,
>
> I am developing some applications that extensively uses STL. I plan to use
> the
> traits -> iterator_traits to get information about which type do I need to
> return.
> Unfortunately, I've been experienced some problems to use such
> functionality.
>
> This simple test code was extracted from the SGI-STL website, but oddly
> enough it doesn't compile:
> #include
> #include
> #include
> #include
>
> template
> std::iterator_traits::value_type
> last_value(InputIterator first, InputIterator last) {
> std::iterator_traits::value_type result = *first;
> for (++first; first != last; ++first)
> result = *first;
> return result;
> }
>
> using namespace std;
>
> int main()
> {
> std::vector teste(10);
> fill_n(teste.begin(),10,1.2);
> double result = last_value(teste.begin(),teste.end());
> return 0;
> }
I looks like one of your copy paste did not work correctly. There are
bunch of <> that are missing from your program. If it is just in the
email that those parts are missing try inserting a typename before
std::iterator_traits::value_type each time this construction appears...
Re: Fwd: Problem with OpenMP Reduction Clause
On Tue, May 02, 2006 at 08:09:28AM -0700, Andrew Pinski wrote: > >I've stumbled onto a problem with the OpenMP REDUCTION clause > > > >gfortran segfault on compile (gfortran -fopenmp array_reduction.f90) > >with the following message: > >arrayreduction.f90: In function 'foo': > >arrayreduction.f90:14: internal compiler error: Segmentation fault > >Please submit a full bug report, > >with preprocessed source if appropriate. > >See http://gcc.gnu.org/bugs.html> for instructions. > > > >My understanding (from following the mailing list) is that the > >segfault itself is a gfortran bug... > >Should I therefore file one ? Of course. Make sure to add openmp to Keywords in the bugreport. > >My 2nd question is is the coding valid ??? From reading page 83 of the > >OpenMP 2.5 Specifications > >(http://www.openmp.org/drupal/mp-documents/spec25.pdf) I tend to think > >that sumarray is a valid array for the REDUCTION clause. I wonder > >still since INTEL compilers seem to have a problem with it too. I believe it is valid. Jakub
Re: Bug in gen_addr_rtx() in gcc4.1?
> > On a system which supports 64-bit implementation but with TARGET_ILP32 > ABI, like HPUX on ia64, the gcc-4.1 compiler generates incorrect code > for the dejagnu test gcc.dg/tree-ssa/pr23386.c. The problem seems > because that the gen_addr_rtx() in tree-ssa-address.c always returns > Pmode rtx. On a TARGET_64BIT machine, Pmode is DImode. I do not see this failing on ia64-hpux (with -milp32). http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg00080.html http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg00045.html Are you sure that you are not doing something funny with your port? -- Pinski
RE: GCC FAIL WITH BASIC STL EXAMPLE
On 02 May 2006 16:26, trincheira wrote: Ok, it's hard to see what's going on, because somebody somewhere has mistaken everything between angle-braces for borked HTML tags and stripped them, which is /really/ not good for a template example of all things (!), but I'm going to try a bit of a guess here anyway: > > This simple test code was extracted from the SGI-STL website, but oddly > enough it doesn't compile: Tell SGI to fix their buggy code. http://gcc.gnu.org/gcc-3.4/changes.html#cplusplus Well, ok, tell them to bring it up to scratch with the current version of the C++ language spec, anyway! cheers, DaveK -- Can't think of a witty .sigline today
Re: svn problems
On May 1, 2006, at 8:48 PM, Ben Elliston wrote: It amazes me that svn can't do a merge. That's patently inaccurate. Ok, try this out: mrs $ mkdir svn-repo mrs $ svnadmin create svn-repo mrs $ svn co file:///Volumes/mrs4/svn-repo svn Checked out revision 0. mrs $ cd svn mrs $ svn mkdir trunk A trunk mrs $ svn mkdir branches A branches mrs $ cat > trunk/file1 file1 mrs $ svn ci . Adding branches Adding trunk Committed revision 1. mrs $ svn add trunk/file1 A trunk/file1 mrs $ svn ci . Adding trunk/file1 Transmitting file data . Committed revision 2. mrs $ svn cp file:///Volumes/mrs4/svn-repo/trunk file:///Volumes/mrs4/ svn-repo/branches/rel Committed revision 4. cat > trunk/file1 mrs $ ls branchessvn-commit.2.tmp.~2~svn- commit.tmp.~1~ svn-commit.tmp.~3~ svn-commit.2.tmp.~1~svn-commit.tmp svn- commit.tmp.~2~ trunk mrs $ pwd /Volumes/mrs4/svn mrs $ cd .. mrs $ svn co file:///Volumes/mrs4/svn-repo/branches/rel rel Arel/file1 Checked out revision 4. mrs $ cd rel mrs $ cat >file2 file2 mrs $ cat >file3 file3_rel mrs $ svn add file2 file3 A file2 A file3 mrs $ svn ci . Adding file2 Adding file3 Transmitting file data .. Committed revision 5. mrs $ pwd /Volumes/mrs4/rel mrs $ cd ../ mrs $ svn co file:///Volumes/mrs4/svn-repo/trunk trunk Atrunk/file1 Checked out revision 5. mrs $ cd trunk/ mrs $ ls file1 mrs $ cat >file2 file2 mrs $ cat >file3 file3_trunk mrs $ svn add file2 file3 A file2 A file3 mrs $ svn ci . Adding file2 Adding file3 Transmitting file data .. Committed revision 6. mrs $ pwd /Volumes/mrs4/trunk mrs $ cd mrs $ cd ../rel mrs $ svn merge mrs $ svn merge -r4:6 file:///Volumes/mrs4/svn-repo/trunk Afile2 Afile3 mrs $ svn ci svn: Commit failed (details follow): svn: Aborting commit: '/Volumes/mrs4/rel/file3' remains in conflict mrs $ svn status -u ? file3.merge-right.r6 ? file3.working C 5 file3 ? file3.merge-left.r0 Status against revision: 6 mrs $ emacs file3 mrs $ svn resolved file3 Resolved conflicted state of 'file3' mrs $ svn ci mrs $ cd ../trunk mrs $ svn rm file3 D file3 mrs $ svn ci . Deleting file3 Committed revision 7. mrs $ cat >file3 new_file3 mrs $ svn add file3 A file3 mrs $ svn ci . Adding file3 Transmitting file data . Committed revision 8. mrs $ cd ../rel mrs $ svn merge -r6:8 file:///Volumes/mrs4/svn-repo/trunk Dfile3 Afile3 mrs $ svn status -u svn: Working copy path 'file3' does not exist in repository mrs $ svn status R + file3 mrs $ cd ../trunk mrs $ cd - /Volumes/mrs4/rel mrs $ svn ci . Replacing file3 svn: Commit failed (details follow): svn: Out of date: '/branches/rel/file3' in transaction '8-1' svn: Your commit message was left in a temporary file: svn:'/Volumes/mrs4/rel/svn-commit.tmp' mrs $ svn status -u svn: Working copy path 'file3' does not exist in repository mrs $ svn status -u file3 R + *- file3 Status against revision: 8 mrs $ svn up svn: Working copy path 'file3' does not exist in repository mrs $ svn status -u file3 R + *- file3 Status against revision: 8 mrs $ svn up file3 svn: Failed to add file 'file3': object of the same name already exists mrs $ svn status -u file3 R + *- file3 Status against revision: 8 and let me know if you see the same behavior. If so, explain how you qualify that as working? If not, what version of svn are you running? Now, for fun, try that with cvs, notice that it actually works. Have you tried using the svnmerge script that uses SVN properties to remember which changesets you have (and haven't) merged? Not yet, feel free to try this with that script if you can reproduce the failure and let me know if it works. For completeness, I'm using: mrs $ svn --version svn, version 1.3.0 (r17949) compiled Jan 4 2006, 12:42:53
Re: svn problems
On May 1, 2006, at 8:58 PM, Steven Bosscher wrote: On 5/2/06, Mike Stump <[EMAIL PROTECTED]> wrote: It amazes me that svn can't do a merge. Just because you can't do it, doesn't mean svn can't do it. Let me know if you can reproduce what I see with your version of svn. Feel free to answer the questions I put to Ben.
Re: Bug in gen_addr_rtx() in gcc4.1?
Yes. I know it doesn't fail on IA64-HPUX. The reason is that the dereferencing expression has been transformed as: tmpvar = index+offset; *tmpvar; during induction variable optimization, Where tmpvar has SImode. PPC has different costs to compute induction variables as on IA64-HPUX. Charles On 5/2/06, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > On a system which supports 64-bit implementation but with TARGET_ILP32 > ABI, like HPUX on ia64, the gcc-4.1 compiler generates incorrect code > for the dejagnu test gcc.dg/tree-ssa/pr23386.c. The problem seems > because that the gen_addr_rtx() in tree-ssa-address.c always returns > Pmode rtx. On a TARGET_64BIT machine, Pmode is DImode. I do not see this failing on ia64-hpux (with -milp32). http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg00080.html http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg00045.html Are you sure that you are not doing something funny with your port? -- Pinski
Re: svn problems
On May 1, 2006, at 9:17 PM, Diego Novillo wrote: It amazes me that svn can't do a merge. You obviously have not read the documentation nor browsed the GCC wiki. Doing merges with svn is amazingly simple. I look forward to your answer I put to Ben.
Summer of Code project discussion
Hello everybody, I'd like to participate in SoC, but first of all to get your feedback about project choice before submitting a proposal. I've done some GCC work a few years ago: I was involved with the DJGPP port, also done several minor bugfixes outside that in the infrastructure. So I have some beforehand knowledge of GCC internals and programming tools involved, although my knowledge of RTL is at beginner's level (of other intermediate data structures virtually nonexistent). However at the university I have opted in for compiler courses, wrote my undergrad thesis about loop optimizations, so I have quite good knowledge of common compiler principles for a student. Having that in mind, also because I actually like doing infrastructural projects, cleaning up, speeding up things instead of implementing new features, I think I have found a suitable area for my project: garbage collection. I was looking for a compiler speed-up project yet avoid sinking into tree/RTL internals, as I doubt I would learn them effectively in time. I haven't worked out the precise details yet, but my proposed project would be along the following lines: - Investigate possibility of Boehm GC usage for compiler proper. Project page mentions inconclusive previous results here. I tried to google them in mailing list archives to no avail. Could somebody provide pointers to the previous investigation? - Assuming that Boehm GC turns out to be unusable for the compiler, finish the zone collector. Again, searching mailing list about what's unfinished was not very fruitful. - Assuming zone collector is done well before deadline, tune the collector by creating special zones for data with special lifetime. This list is by no means final. I hope to receive some feedback (at very least confirming that GC work would be helpful for the GCC project) and work out clear measureable outcome and details of the SoC project proposal. More about me: I was involved with the DJGPP project from my late high school years up to 2nd university year. Last year I've finished Computer Science undergrad studies at Vilnius University, Lithuania. At present I'm employed at and study in at Aalborg University, Denmark, studying for master's degree in Data Engineering. After DJGPP, my involvement in free software has moved to local issues: LaTeX localization for Lithuanian language, Lithuanian localization of Gaim. Additionaly I have about two year of industrial experience, having worked as a software engineer on several enterprise software products. Looking forward to your feedback and thanks in advance. (Please CC on replies) -- Laurynas
bugzilla confused?
Hi, I tried to add myself to the CC list of a PR (27397), but get the following error message: "You tried to change the Keywords field from ice-on-invalid-code, error-recovery, monitored to error-recovery, ice-on-invalid-code, monitored, but only the assignee or reporter of the bug, or a sufficiently empowered user may change that field." I did not, however, attempt to change any fields. The error message is strange in that it claims I reordered the first two keywords. This problem however does not occur with other PRs. Any clues? Fang
Re: GCC FAIL WITH BASIC STL EXAMPLE
Guys, The proposed solution WORKS! I inserted the typename keyword as recomended and the program compiled perfectly. I feel sorry for the two messages. When I first tried to send a message, the browser got frozen and I did a refresh. I would like to thanks and I will report this flaw to SGI. Trincheira -- View this message in context: http://www.nabble.com/GCC-FAIL-WITH-BASIC-STL-EXAMPLE-t1539517.html#a4198201 Sent from the gcc - Dev forum at Nabble.com.
Re: FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_{x,y}_tst.o compile on sparc/sparc64 linux...
> FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_y_tst.o compile I cannot reproduce on Solaris as of today, neither with the 64-bit compiler nor with the 32-bit multiarch one. -- Eric Botcazou
Re: svn problems
> mrs $ svn ci . > Adding trunk/file1 > Transmitting file data . > Committed revision 2. > mrs $ svn cp file:///Volumes/mrs4/svn-repo/trunk file:///Volumes/mrs4/ > svn-repo/branches/rel > Committed revision 4. What happened to rev3? Also, with svn 1.4 dev (all i have on this machine), i get, at the end where you get a problem: [EMAIL PROTECTED]:~/rel> svn merge -r6:8 file:///home/dberlin/svn-repo/trunk Dfile3 Afile3 [EMAIL PROTECTED]:~/rel> svn status -u R +- file3 Status against revision: 8 [EMAIL PROTECTED]:~/rel> vsn ci . bash: vsn: command not found [EMAIL PROTECTED]:~/rel> svn ci . Replacing file3 Committed revision 9. [EMAIL PROTECTED]:~/rel>
Re: Summer of Code project discussion
On Tue, May 02, 2006 at 09:07:19PM +0200, Laurynas Biveinis wrote: > Having that in mind, also because I actually like doing > infrastructural projects, cleaning up, speeding up things instead of > implementing new features, I think I have found a suitable area for my > project: garbage collection. I was looking for a compiler speed-up > project yet avoid sinking into tree/RTL internals, as I doubt I would > learn them effectively in time. Hi Laurynas, I wrote a lot of the current zone collector. Before that, Daniel Berlin did a lot of work on it. I really don't think I have time to mentor an SoC project (Daniel, do you, maybe?), but I'd be glad to talk to you about possible plans. > - Investigate possibility of Boehm GC usage for compiler proper. > Project page mentions inconclusive previous results here. I tried to > google them in mailing list archives to no avail. Could somebody > provide pointers to the previous investigation? I don't know of any offhand (which doesn't mean there isn't any). > - Assuming that Boehm GC turns out to be unusable for the compiler, > finish the zone collector. Again, searching mailing list about what's > unfinished was not very fruitful. What's there works. I don't remember if it is sufficiently portable to e.g. systems without mmap to use as the default; and it needs some performance tuning still, probably, although I did a lot. > - Assuming zone collector is done well before deadline, tune the > collector by creating special zones for data with special lifetime. This turned out not to make a huge amount of difference; the problem is that the lifetimes of things are unclear in GCC and often long. I wrote a collector which could separate out data only referenced by a single function into its own zones; less than 30% of all data in a GCC run is specific to a function, because things like types and constants are not. I think it was even less. I don't have the statistics handy. The copying part of the collector worked well. The partitioning was less useful. My plan was to eventually enable generational GC; i.e. to be able to collect more frequently and assert that data for other functions had not changed since the last collection, since we optimize one function at a time. You could even mprotect the other zones read-only under --enable-checking to verify that we didn't clobber other functions. The problem was that the global zone was so large that collection time was still high. On March 13th 2005 I posted the copying collector to gcc-patches; you can find it in the archives. That was good for a performance boost by itself of a few percent, but used a lot of RAM; something cleverer might be doable that would use less RAM; I don't really know. I don't think I ever posted the automatic partitioning code; that computer is off right now, but I can dig out the code if you want to see it. -- Daniel Jacobowitz CodeSourcery
Re: exposing SH's fpscr support
> > __fpscr_values[0] &= off; > > __fpscr_values[0] |= on; > > __fpscr_values[1] &= off; > > __fpscr_values[1] |= on; > > Ok, I'll bite. Why are there two of them?! Well, this is the real reason why we need an API and not just a simple builtin. GCC uses that table of values to quickly switch the FPU modes between single and double precision. However, it discards all the other fpscr bits at that time, unless the table is also updated. So, if you want to set a specific bit in fpscr, you have to not only set the actual $fpscr, but also all the entries in that table - however many there may be at the moment. There are currently two. The fact that we have to update a table defined and used by GCC is my main reason for wanting to add a well-defined APi to *libgcc* to interface with those. Higher-level control (such as in ) would be added on top of this API, to ease compatibility between versions.
Re: svn problems
On May 2, 2006, at 6:05 PM, Daniel Berlin wrote: What happened to rev3? I did a svn mkdir brnaches && svn mv brnaches branches, but didn't want to fess up to it. Also, with svn 1.4 dev (all i have on this machine) Cool, fixed in 1.4 dev. Now I'm curious if it is fixed in 1.3.x. I really want to update, but, the fortunes of a large company with lots of revenue are predicated on this stuff actually working. :-) Can I rely, given that, on 1.4 dev if it isn't fixed in 1.3.x?
Re: Summer of Code project discussion
> I wrote a lot of the current zone collector. Before that, Daniel > Berlin did a lot of work on it. I really don't think I have time to > mentor an SoC project (Daniel, do you, maybe?), I do, in fact, have time to mentor such a project, and would be happy to mentor it if you submit it and it is accepted. My thoughts are along the lines of Daniel's. I originally believed that the better data layout of lifetime and object specific pools would help, but it only helps about 10% in the extreme. GC work is most certainly helpful. Exploring generational collection (even if it turned out to be a complete wash) would be a great project as well if you wanted to attempt that. though trying boehm-gc is a good project too.
Re: svn problems
On May 2, 2006, at 6:34 PM, Mike Stump wrote: Also, with svn 1.4 dev (all i have on this machine) Cool, fixed in 1.4 dev. Now I'm curious if it is fixed in 1.3.x. I really want to update, but, the fortunes of a large company with lots of revenue are predicated on this stuff actually working. :-) Can I rely, given that, on 1.4 dev if it isn't fixed in 1.3.x? I even tried following your directions and it worked for me without conflicts. I had to replace 4:6 with 3:5 but other than that it worked. And this was with 1.3.0. -- Pinski
Re: svn problems
On May 2, 2006, at 6:38 PM, Andrew Pinski wrote: I even tried following your directions and it worked for me without conflicts. I had to replace 4:6 with 3:5 but other than that it worked. And this was with 1.3.0. Hum... :-( Thanks for the data point. Might just be me, with a codegen bug or something along those line...
Re: Dynamically generated code and DWARF exception handling
On May 2, 2006, at 4:23 AM, jacob navia wrote: To get to the corresponding catch, the runtime should skip through the intermediate frames in assembler generated by the JIT. We would like to know how should be the interface with gcc to do this. The C++ abi spec and dwarf specs are good background reading materials. We thought for a moment that using sjlj_exceptions it would work, but we fear that this is no longer being maintained. While one could do that, I'd recommend just doing up the dwarf style EH information for the JIT code. 1) Is this true? Not exactly. 2) Can we use sjlj exception under linux safely? I'd expect so. Though, you have to understand this this would mean that you'd have to recompile all the code on the system, possibly including the C library, gcc and the like, as well as application code and library code. When faced with that, you might determine it is impossible. Otherwise, would it be possible to generate the DWARF Tables and add those tables dynamically to the running program? Yes (could require OS changes). Under windows, Microsoft provides an API for JITs that does exactly that. Is there an equivalent API for linux? Don't think so.
Re: libiberty
On May 2, 2006, at 6:08 AM, Bill Cunningham wrote: Everytime I compile gcc I see that libiberty is being compiled. Is this a needed library and if not how can I switch it off? I'm using glibc-2.1 and I'd like to figure out compiling 2.3 and I've done it before so I just have to remember how. I want to cut down on all that compile time. cd gcc && make doesn't rebuild libiberty. I use that to avoid recompiles.
Re: Dynamically generated code and DWARF exception handling
On Tue, May 02, 2006 at 07:21:24PM -0700, Mike Stump wrote: > >Otherwise, would it be possible to generate the DWARF Tables and > >add those tables dynamically to the running program? > > Yes (could require OS changes). > > >Under windows, Microsoft provides an API for JITs that does exactly > >that. Is there an equivalent API for linux? > > Don't think so. There isn't really. But I know that other JITs have managed to do this - I just don't know how. They may use a nasty hack somewhere. -- Daniel Jacobowitz CodeSourcery
Status of SEE and Autovectorization patches?
I'm trying to figure out whether we can get the SEE and Autovectorization improvements into 4.2. I'd like to get these changes in because they will deliver some noticeable improvements in performance, and because the submitters seem to have tried hard to get them included. Roger, I know that you reviewed the SEE patches. Is there anything more than needs to be done to get them committed, in your view? Richard, do you think you'll have a chance to look at the autovectorization work soon? If not, is there someone else you might suggest to review it? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
