From jules at codesourcery.com Tue Jan 8 15:42:38 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 08 Jan 2008 10:42:38 -0500 Subject: [patch] Avoid use of posix_memalign with LAM Message-ID: <478399EE.6020208@codesourcery.com> This patch adds back the check to avoid using posix memalign with LAM. Recall that LAM defines its own malloc, free, etc, but does not define posix_memalign. Using LAM free to deallocate memory allocated with system posix_memalign doesn't work so well. This patch also: fixes a bug in the Cell pwarp kernel and fixes the SAL vthresh benchmark to compile when SAL is missing vthrx. Patch applied. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix-memalign.diff URL: From don at codesourcery.com Tue Jan 8 19:49:08 2008 From: don at codesourcery.com (Don McCoy) Date: Tue, 08 Jan 2008 12:49:08 -0700 Subject: [vsipl++] [patch] fix for profiling long processes In-Reply-To: <4720EE65.6010903@codesourcery.com> References: <4720E828.2000907@codesourcery.com> <4720EE65.6010903@codesourcery.com> Message-ID: <4783D3B4.2030808@codesourcery.com> Jules Bergmann wrote: > Don McCoy wrote: > >> When profiling over a long period of time, the raw timestamps observed >> in the profiler output have the potential to be truncated, leading to >> inaccurate results. >> >> > > Hurray! This seems a plausible explanation for the weird roll up (sum > less than the parts) of time values. > > One quick suggestion: can you create a 'tick_type' typedef that is > unsigned long long. That will help us remember not to use a 32-bit type > again. > > Otherwise this looks good, please apply. > > This was overlooked, but is now committed with suggested changes. Regards, -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pt2.diff URL: From jules at codesourcery.com Tue Jan 8 21:39:47 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 08 Jan 2008 16:39:47 -0500 Subject: [patch] Fix sfilt Message-ID: <4783EDA3.4090107@codesourcery.com> This patch fixes a bug in the Separable_filter generic implementation. It was relying on being able to modify values in a view being accessed with an Ext_data object while the Ext_data object was in scope. Fix is to use Persistent_ext_data instead. The patch also adds some missing includes for the diag headers. Patch applied. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix-sfilt.diff URL: From jules at codesourcery.com Wed Jan 9 22:42:22 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 09 Jan 2008 17:42:22 -0500 Subject: [patch] Fix for generic pwarp Message-ID: <47854DCE.4050901@codesourcery.com> Stefan, This patch attempts to fix the generic pwarp impl so that it doesn't access memory past the end of the input image. Can you give a spin on windows to see if it fixes the segfault? -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix-pwarp.diff URL: From stefan at codesourcery.com Thu Jan 10 05:14:40 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Thu, 10 Jan 2008 00:14:40 -0500 Subject: [vsipl++] [patch] Fix for generic pwarp In-Reply-To: <47854DCE.4050901@codesourcery.com> References: <47854DCE.4050901@codesourcery.com> Message-ID: <4785A9C0.60701@codesourcery.com> Jules Bergmann wrote: > Stefan, > > This patch attempts to fix the generic pwarp impl so that it doesn't > access memory past the end of the input image. > > Can you give a spin on windows to see if it fixes the segfault? Unfortunately it still fails. Luckily, though, I have been able to reproduce the failure under Linux, using ElectricFence, and it seems to be the exact same place as on Windows, at least if I trust the debugger(s): pwarp_gen.hpp:237 In line 232: p = p_in + v0*in_stride_0 + u0; becomes p_in + 511 * 512 + 503; (which is still legal, as the block size is 512x512) but then in line 237 we have z11 = *(p + in_stride_0 + 1) which is p + 512 + 1 i.e. we are dereferencing the block at index (v0+1)*in_stride_0 + u0 (i.e. 512*512 + something) which is clearly too big. I don't immediately see where the failure is, and so I'm sending this out without a fix. May be someone beats me to it . Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From stefan at codesourcery.com Thu Jan 10 05:50:24 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Thu, 10 Jan 2008 00:50:24 -0500 Subject: [vsipl++] [patch] Fix for generic pwarp In-Reply-To: <4785A9C0.60701@codesourcery.com> References: <47854DCE.4050901@codesourcery.com> <4785A9C0.60701@codesourcery.com> Message-ID: <4785B220.3090807@codesourcery.com> Stefan Seefeld wrote: > May > be someone beats me to it . As usual, just when you hit the button...: It appears that code interpolates pixels, but the clipping isn't quite correct. The attached patch fixes that, for the pwarp_gen.hpp as well as the ref_pwarp.hpp functions. With that patch, the Windows pwarp test, as well as the Linux one with ElectricFence, pass. Regards, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 -------------- next part -------------- A non-text attachment was scrubbed... Name: pwarp.patch Type: text/x-patch Size: 1079 bytes Desc: not available URL: From jules at codesourcery.com Thu Jan 10 13:36:46 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Thu, 10 Jan 2008 08:36:46 -0500 Subject: [vsipl++] [patch] Fix for generic pwarp In-Reply-To: <4785A9C0.60701@codesourcery.com> References: <47854DCE.4050901@codesourcery.com> <4785A9C0.60701@codesourcery.com> Message-ID: <47861F6E.3020701@codesourcery.com> Stefan Seefeld wrote: > Jules Bergmann wrote: >> Stefan, >> >> This patch attempts to fix the generic pwarp impl so that it doesn't >> access memory past the end of the input image. >> >> Can you give a spin on windows to see if it fixes the segfault? > > Unfortunately it still fails. > Luckily, though, I have been able to reproduce the failure under Linux, > using ElectricFence, and it seems to be the exact same place as on > Windows, at least if I trust the debugger(s): Can you try running the patch through electric fence? In particular, it replaces > z11 = *(p + in_stride_0 + 1) with > + T z11 = *(p + off_11); // in.get(v0+1, u0+1); where > + stride_type off_11 = std::min(in_stride_0 + 1, limit); i.e. the patch attempts to clip off_11 if it results in an address beyond the image. Perhaps I am setting limit incorrectly. The problem with adjusting the clipping - if (u >= 0 && u <= u_clip && v >= 0 && v <= v_clip) + if (u >= 0 && u < u_clip && v >= 0 && v < v_clip) is that u == u_clip is actually valid, since it falls exactly on a pixel and does not require interpolation with u_clip+1. (This is the case mentioned yesterday, where values outside the image may be read, but are not used in computing the result (since they are weighted with 0)). -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From stefan at codesourcery.com Thu Jan 10 14:29:28 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Thu, 10 Jan 2008 09:29:28 -0500 Subject: [vsipl++] [patch] Fix for generic pwarp In-Reply-To: <47861F6E.3020701@codesourcery.com> References: <47854DCE.4050901@codesourcery.com> <4785A9C0.60701@codesourcery.com> <47861F6E.3020701@codesourcery.com> Message-ID: <47862BC8.70906@codesourcery.com> Please find attached a revised patch that works, on Windows / ICC as well as on Linux under ElectricFence. Checked in (not as obvious, but after internal discussion :-) ). Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 -------------- next part -------------- A non-text attachment was scrubbed... Name: pwarp.patch Type: text/x-patch Size: 1813 bytes Desc: not available URL: From jules at codesourcery.com Thu Jan 10 14:45:06 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Thu, 10 Jan 2008 09:45:06 -0500 Subject: [vsipl++] [patch] Fix for generic pwarp In-Reply-To: <47862BC8.70906@codesourcery.com> References: <47854DCE.4050901@codesourcery.com> <4785A9C0.60701@codesourcery.com> <47861F6E.3020701@codesourcery.com> <47862BC8.70906@codesourcery.com> Message-ID: <47862F72.3010105@codesourcery.com> Stefan Seefeld wrote: > Please find attached a revised patch that works, on Windows / ICC as > well as on Linux under ElectricFence. Checked in (not as obvious, but > after internal discussion :-) ). Thanks Stefan for tracking this down! -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From don at codesourcery.com Wed Jan 23 20:57:41 2008 From: don at codesourcery.com (Don McCoy) Date: Wed, 23 Jan 2008 13:57:41 -0700 Subject: [patch] Make configure options more consistent Message-ID: <4797AA45.3010208@codesourcery.com> The attached patch changes a number of instances of --enable-* to use --with-* instead, in order to make such usages more consistent with other options. The general rule is that --enable is used for features and --with is used for specific libraries. The deprecated cases now include error messages to help users building from source update their configure options (rather than follow the default autoconf behavior of silently ignoring unrecognized options). The Quickstart guide has been updated as well. Regards, -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cfg.changes URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cfg.diff URL: From jules at codesourcery.com Wed Jan 23 21:13:15 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 23 Jan 2008 16:13:15 -0500 Subject: [vsipl++] [patch] Make configure options more consistent In-Reply-To: <4797AA45.3010208@codesourcery.com> References: <4797AA45.3010208@codesourcery.com> Message-ID: <4797ADEB.7050206@codesourcery.com> Don McCoy wrote: > The attached patch changes a number of instances of --enable-* to use > --with-* instead, in order to make such usages more consistent with > other options. The general rule is that --enable is used for features > and --with is used for specific libraries. Great! Thanks for pushing this through! Let's capture the naming decision in configure.ac. Something like # Rational for option naming # # The general rule is that --enable is used for features # and --with is used for specific libraries. # # In cases where an option controls both a feature and specifies # an external library, such as --enable-parallel, --enable should # be used. The primary purpose of the option is turning on # the feature, the secondary purpose is specifying which # external code to use to enable that feature. > > The deprecated cases now include error messages to help users building > from source update their configure options (rather than follow the > default autoconf behavior of silently ignoring unrecognized options). > The Quickstart guide has been updated as well. Sorry to create churn, but I agree with Brooks: > I think it might be clearer to phrase this as "is obsolete" or "is no > longer supported" here; that way, when a user runs across this error, > they have an idea why they got it. As the error messages are currently written, "--disable-xyz is not supported; use --without-xyz instead", it leaves the impression that the library is missing some functionality that should be there, and a workaround is being suggested. It would be more clear to say "--disable-xyz is obsolete; use --without-xyz instead" or "--disable-xyz is incorrect; use --without-xyz" instead, since in some cases we're adding checks for options that were never allowed in the first place. Otherwise, I think the patch looks good. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From brooks at codesourcery.com Wed Jan 23 21:25:21 2008 From: brooks at codesourcery.com (Brooks Moses) Date: Wed, 23 Jan 2008 13:25:21 -0800 Subject: [vsipl++] [patch] Make configure options more consistent In-Reply-To: <4797ADEB.7050206@codesourcery.com> References: <4797AA45.3010208@codesourcery.com> <4797ADEB.7050206@codesourcery.com> Message-ID: <4797B0C1.30307@codesourcery.com> Jules Bergmann wrote, at 1/23/2008 1:13 PM: > Let's capture the naming decision in configure.ac. Something like > > # Rational for option naming > # > # The general rule is that --enable is used for features > # and --with is used for specific libraries. > # > # In cases where an option controls both a feature and specifies > # an external library, such as --enable-parallel, --enable should > # be used. The primary purpose of the option is turning on > # the feature, the secondary purpose is specifying which > # external code to use to enable that feature. "Rationale", not "Rational", but otherwise I completely agree with this proposed addition. This should definitely be included to remind our future selves that we did have good reasons for doing it this way, and I think this accurately captures those reasons. - Brooks From don at codesourcery.com Thu Jan 24 00:38:46 2008 From: don at codesourcery.com (Don McCoy) Date: Wed, 23 Jan 2008 17:38:46 -0700 Subject: [vsipl++] [patch] Make configure options more consistent In-Reply-To: <4797ADEB.7050206@codesourcery.com> References: <4797AA45.3010208@codesourcery.com> <4797ADEB.7050206@codesourcery.com> Message-ID: <4797DE16.8000106@codesourcery.com> Jules Bergmann wrote: > Let's capture the naming decision in configure.ac. Something like > ... > Thanks. I added it. > It would be more clear to say > "--disable-xyz is obsolete; use --without-xyz instead" or "--disable-xyz > is incorrect; use --without-xyz" instead, since in some cases we're > adding checks for options that were never allowed in the first place. > > That seems reasonable. I chose "is obsolete". > Otherwise, I think the patch looks good. > Committed as attached. Thanks, -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cfg2.changes URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cfg2.diff URL: From jules at codesourcery.com Mon Jan 28 16:32:40 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Mon, 28 Jan 2008 11:32:40 -0500 Subject: [patch] Fftm diagnostics, misc cleanup & FFTW fix for powerpc-eabi Message-ID: <479E03A8.10109@codesourcery.com> These patches: - Add Fftm diagnostics - Cleanup vendor libs from lib/ directory - Fix fft and fftm benchmarks to compile when double-precision FFTs aren't supported - Add hook to FFTW3 to work around unimplemented gettimeofday/clock functions in the windows powerpc-eabi simulator. Ok to apply? -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: misc.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fftw.diff URL: From stefan at codesourcery.com Mon Jan 28 16:44:41 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Mon, 28 Jan 2008 11:44:41 -0500 Subject: [vsipl++] [patch] Fftm diagnostics, misc cleanup & FFTW fix for powerpc-eabi In-Reply-To: <479E03A8.10109@codesourcery.com> References: <479E03A8.10109@codesourcery.com> Message-ID: <479E0679.8020100@codesourcery.com> Jules Bergmann wrote: > These patches: > - Add Fftm diagnostics > @@ -192,6 +212,32 @@ > } > }; > > + > + > +struct Diagnose_fftm > +{ > + template > + static void diag(std::string name, FftmT const& fftm) I believe it would be better to pass 'name' by (const) reference. I don't think std::string is mandated to be implemented with copy-on-write semantics. (There are other similar cases.) > - Cleanup vendor libs from lib/ directory > @@ -143,6 +146,7 @@ > rm -f vendor/atlas/lib/libcblas.a lib/libcblas.a > rm -f $(vendor_MERGED_LAPACK) lib/liblapack.a > rm -f $(vendor_PRE_LAPACK) > + rm -f lib/libcblas.a lib/libatlas.a lib/liblapack.a I believe only the lib/libatlas.a was missing above. > - Fix fft and fftm benchmarks to compile when double-precision > FFTs aren't supported > - Add hook to FFTW3 to work around unimplemented gettimeofday/clock > functions in the windows powerpc-eabi simulator. > > Ok to apply? Looks good, modulo the above two points. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From jules at codesourcery.com Mon Jan 28 17:08:20 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Mon, 28 Jan 2008 12:08:20 -0500 Subject: [vsipl++] [patch] Fftm diagnostics, misc cleanup & FFTW fix for powerpc-eabi In-Reply-To: <479E0679.8020100@codesourcery.com> References: <479E03A8.10109@codesourcery.com> <479E0679.8020100@codesourcery.com> Message-ID: <479E0C04.50701@codesourcery.com> >> +{ >> + template >> + static void diag(std::string name, FftmT const& fftm) > > I believe it would be better to pass 'name' by (const) reference. I > don't think std::string is mandated to be implemented with copy-on-write > semantics. (There are other similar cases.) Good suggestion. I fixed the other cases in diag/fft.cpp too. > > >> - Cleanup vendor libs from lib/ directory > >> @@ -143,6 +146,7 @@ >> rm -f vendor/atlas/lib/libcblas.a lib/libcblas.a >> rm -f $(vendor_MERGED_LAPACK) lib/liblapack.a >> rm -f $(vendor_PRE_LAPACK) >> + rm -f lib/libcblas.a lib/libatlas.a lib/liblapack.a > > I believe only the lib/libatlas.a was missing above. Oops, none of the additions were necessary for this case! (a little more context would show that libatlas is deleted too). Applied with those suggestions. thanks, -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Tue Jan 29 17:13:16 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 29 Jan 2008 12:13:16 -0500 Subject: [patch] Fix tutorial errors Message-ID: <479F5EAC.4090602@codesourcery.com> This patch fixes a couple of errors in the tutorial: - The old 'Scope_event' profiling class was mentioned instead of 'Scope'. - The read_file example had a typo and a missing using. This also adds tests for a couple of relevant fragments. Patch applied. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: scope.diff URL: From jules at codesourcery.com Tue Jan 29 21:31:15 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 29 Jan 2008 16:31:15 -0500 Subject: [patch] Config update Message-ID: <479F9B23.2010009@codesourcery.com> This patch updates config to - use the new names for configure options - have a Power configuration - use GNU triplets (i686-pc-linux-gnu, powerpc-linux-gnu, powerpc-mcoe, etc) It also updates package.py and release.sh to build binary packages to installed into /opt/sourceryvsipl++-VERSION, and to leave out the /opt from the path in the tarball. Testing on the small-mondo packages is looking OK. After this, I'm going to create the 1.4 branch. Ok to apply? -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cfg.diff URL: From brooks at codesourcery.com Tue Jan 29 21:41:53 2008 From: brooks at codesourcery.com (Brooks Moses) Date: Tue, 29 Jan 2008 13:41:53 -0800 Subject: [vsipl++] [patch] Config update In-Reply-To: <479F9B23.2010009@codesourcery.com> References: <479F9B23.2010009@codesourcery.com> Message-ID: <479F9DA1.5040303@codesourcery.com> Jules Bergmann wrote, at 1/29/2008 1:31 PM: > This patch updates config to > - use the new names for configure options > - have a Power configuration > - use GNU triplets (i686-pc-linux-gnu, powerpc-linux-gnu, powerpc-mcoe, > etc) Note that powerpc-linux-gnu is not in fact a triplet; linux-gnu is a single item. It should be powerpc-unknown-linux-gnu, or have something specific in place of the "unknown" for the system type. Similarly, powerpc-mcoe should be powerpc-unknown-mcoe or powerpc-mercury-mcoe (if mcoe only runs on Mercury systems) or somesuch to be a true triplet. I don't know if this is important for our purposes or not. It might be, if we ever use something that expects to split the triplets into their component parts, but otherwise probably isn't.... (For one example, I suspect that autoconf's cross-compiler handling may expect triplets.) - Brooks From brooks at codesourcery.com Tue Jan 29 21:45:04 2008 From: brooks at codesourcery.com (Brooks Moses) Date: Tue, 29 Jan 2008 13:45:04 -0800 Subject: [vsipl++] [patch] Config update In-Reply-To: <479F9DA1.5040303@codesourcery.com> References: <479F9B23.2010009@codesourcery.com> <479F9DA1.5040303@codesourcery.com> Message-ID: <479F9E60.4090003@codesourcery.com> Brooks Moses wrote, at 1/29/2008 1:41 PM: > Jules Bergmann wrote, at 1/29/2008 1:31 PM: >> This patch updates config to >> - use the new names for configure options >> - have a Power configuration >> - use GNU triplets (i686-pc-linux-gnu, powerpc-linux-gnu, powerpc-mcoe, >> etc) > > Note that powerpc-linux-gnu is not in fact a triplet; linux-gnu is a > single item. It should be powerpc-unknown-linux-gnu, or have something > specific in place of the "unknown" for the system type. > > Similarly, powerpc-mcoe should be powerpc-unknown-mcoe or > powerpc-mercury-mcoe (if mcoe only runs on Mercury systems) or somesuch > to be a true triplet. As an addendum -- for Cell, we settled on powerpc-cell-linux-gnu for the canonical triplet when documenting the --host option; I think it would be good to have this agree with that. - Brooks From stefan at codesourcery.com Tue Jan 29 21:54:20 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Tue, 29 Jan 2008 16:54:20 -0500 Subject: [vsipl++] [patch] Config update In-Reply-To: <479F9B23.2010009@codesourcery.com> References: <479F9B23.2010009@codesourcery.com> Message-ID: <479FA08C.5010900@codesourcery.com> Jules Bergmann wrote: > This patch updates config to > - use the new names for configure options > - have a Power configuration > - use GNU triplets (i686-pc-linux-gnu, powerpc-linux-gnu, powerpc-mcoe, > etc) I had similar changes for the two above points, but was waiting as I wanted to pass them by our buildbot first. I'm sorry I didn't manage to do this in time. > It also updates package.py and release.sh to build binary packages to > installed into /opt/sourceryvsipl++-VERSION, and to leave out the /opt > from the path in the tarball. OK. Please note that the package.py in vpp is not up-to-date, as I have been using the one from the vsiplxx-buildbot module. > Testing on the small-mondo packages is looking OK. After this, I'm > going to create the 1.4 branch. > > Ok to apply? OK. I'll merge the changes to package.py and config into their counterparts in vsiplxx-buildbot, once all is settled. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From jules at codesourcery.com Tue Jan 29 22:04:07 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 29 Jan 2008 17:04:07 -0500 Subject: [vsipl++] [patch] Config update In-Reply-To: <479F9E60.4090003@codesourcery.com> References: <479F9B23.2010009@codesourcery.com> <479F9DA1.5040303@codesourcery.com> <479F9E60.4090003@codesourcery.com> Message-ID: <479FA2D7.3080804@codesourcery.com> Brooks, >>> - use GNU triplets (i686-pc-linux-gnu, powerpc-linux-gnu, powerpc-mcoe, >>> etc) >> Note that powerpc-linux-gnu is not in fact a triplet; linux-gnu is a >> single item. It should be powerpc-unknown-linux-gnu, or have something >> specific in place of the "unknown" for the system type. >> >> Similarly, powerpc-mcoe should be powerpc-unknown-mcoe or >> powerpc-mercury-mcoe (if mcoe only runs on Mercury systems) or somesuch >> to be a true triplet. > I don't know if this is important for our purposes or not. It might be, > if we ever use something that expects to split the triplets into their > component parts, but otherwise probably isn't.... (For one example, I > suspect that autoconf's cross-compiler handling may expect triplets.) The goal is consistency with Sourcery G++. If that means sprinkling in "unknown"s, that's the way it is I suppose :) > > As an addendum -- for Cell, we settled on powerpc-cell-linux-gnu for the > canonical triplet when documenting the --host option; I think it would > be good to have this agree with that. Sounds fine to me. To be sure I understand the triplet format, shouldn't this be 'powerpc-cell-unknown-linux-gnu'? Cell is an architectural variant of power, not a systems vendor, right? -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Tue Jan 29 22:08:49 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 29 Jan 2008 17:08:49 -0500 Subject: [vsipl++] [patch] Config update In-Reply-To: <479FA08C.5010900@codesourcery.com> References: <479F9B23.2010009@codesourcery.com> <479FA08C.5010900@codesourcery.com> Message-ID: <479FA3F1.5080701@codesourcery.com> Stefan, No worries. I'm trying to push 1.4 out so we can start to incorporate the gnu-scripts changes. -- Jules Stefan Seefeld wrote: > Jules Bergmann wrote: >> This patch updates config to >> - use the new names for configure options >> - have a Power configuration >> - use GNU triplets (i686-pc-linux-gnu, powerpc-linux-gnu, powerpc-mcoe, >> etc) > > I had similar changes for the two above points, but was waiting as I > wanted to pass them by our buildbot first. I'm sorry I didn't manage to > do this in time. > >> It also updates package.py and release.sh to build binary packages to >> installed into /opt/sourceryvsipl++-VERSION, and to leave out the /opt >> from the path in the tarball. > > OK. Please note that the package.py in vpp is not up-to-date, as I have > been using the one from the vsiplxx-buildbot module. > >> Testing on the small-mondo packages is looking OK. After this, I'm >> going to create the 1.4 branch. >> >> Ok to apply? > > OK. I'll merge the changes to package.py and config into their > counterparts in vsiplxx-buildbot, once all is settled. -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From brooks at codesourcery.com Tue Jan 29 22:13:24 2008 From: brooks at codesourcery.com (Brooks Moses) Date: Tue, 29 Jan 2008 14:13:24 -0800 Subject: [vsipl++] [patch] Config update In-Reply-To: <479FA2D7.3080804@codesourcery.com> References: <479F9B23.2010009@codesourcery.com> <479F9DA1.5040303@codesourcery.com> <479F9E60.4090003@codesourcery.com> <479FA2D7.3080804@codesourcery.com> Message-ID: <479FA504.1000204@codesourcery.com> Jules Bergmann wrote, at 1/29/2008 2:04 PM: >> As an addendum -- for Cell, we settled on powerpc-cell-linux-gnu for the >> canonical triplet when documenting the --host option; I think it would >> be good to have this agree with that. > > Sounds fine to me. To be sure I understand the triplet format, > shouldn't this be 'powerpc-cell-unknown-linux-gnu'? Cell is an > architectural variant of power, not a systems vendor, right? I'll let Mark comment on this, since it was his suggestion. I think this is one of the cases where the meaning of "system" as the middle triplet entry is somewhat flexible. :) In any case, though, there are a number of things that split the triplets by matching on the first and second hyphen characters, so (to produce correct parsing) only the third entry can contain hyphens, and "powerpc-cell" would not work for an architecture descriptor. - Brooks P.S.: Mark, could you also comment on whether MCOE should get powerpc-mercury-mcoe or powerpc-unknown-mcoe? I'm not very certain about that one at all. From jules at codesourcery.com Wed Jan 30 13:34:29 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 30 Jan 2008 08:34:29 -0500 Subject: [patch] Check config at app build time Message-ID: <47A07CE5.9060707@codesourcery.com> This patch adds a app_config() function that returns a string for the library's configuration at application build time. It is identical in format to library_config(), which is the library's configuration at library build time. By comparing the output of these two functions, you can check whether you're using the same configuration as when the library was originally built. This should be useful for folks using eclipse to make sure they've correctly cut-and-pasted the phalanx of options from the pkg-config file into eclipse. Ok to apply? -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: chk-config.diff URL: From jules at codesourcery.com Wed Jan 30 14:18:43 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 30 Jan 2008 09:18:43 -0500 Subject: [vsipl++] [patch] Check config at app build time In-Reply-To: <47A07CE5.9060707@codesourcery.com> References: <47A07CE5.9060707@codesourcery.com> Message-ID: <47A08743.4050109@codesourcery.com> Along the line of making VSIPL++ easier to use from eclipse, I think we should make --disable-shared-acconfig the default as well. In the common case, users building from source, this will put the -D options in acconfig.hpp, which will make using eclipse easier. The only people who need --enable-shared-acconfig are those building binary packages, something that most users will not do. What do folks think? -- Jules Jules Bergmann wrote: > This patch adds a app_config() function that returns a string for the > library's configuration at application build time. It is identical in > format to library_config(), which is the library's configuration at > library build time. > > By comparing the output of these two functions, you can check whether > you're using the same configuration as when the library was originally > built. This should be useful for folks using eclipse to make sure > they've correctly cut-and-pasted the phalanx of options from the > pkg-config file into eclipse. > > Ok to apply? > > -- Jules > -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Wed Jan 30 15:26:23 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 30 Jan 2008 10:26:23 -0500 Subject: [vsipl++] [patch] Check config at app build time In-Reply-To: <47A08743.4050109@codesourcery.com> References: <47A07CE5.9060707@codesourcery.com> <47A08743.4050109@codesourcery.com> Message-ID: <47A0971F.7090405@codesourcery.com> OK to apply? Jules Bergmann wrote: > Along the line of making VSIPL++ easier to use from eclipse, I think we > should make --disable-shared-acconfig the default as well. > > In the common case, users building from source, this will put the -D > options in acconfig.hpp, which will make using eclipse easier. > > The only people who need --enable-shared-acconfig are those building > binary packages, something that most users will not do. -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: shared-acconfig.diff URL: From stefan at codesourcery.com Wed Jan 30 15:31:54 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Wed, 30 Jan 2008 10:31:54 -0500 Subject: [vsipl++] [patch] Check config at app build time In-Reply-To: <47A07CE5.9060707@codesourcery.com> References: <47A07CE5.9060707@codesourcery.com> Message-ID: <47A0986A.5010307@codesourcery.com> Jules Bergmann wrote: > This patch adds a app_config() function that returns a string for the > library's configuration at application build time. It is identical in > format to library_config(), which is the library's configuration at > library build time. > > By comparing the output of these two functions, you can check whether > you're using the same configuration as when the library was originally > built. This should be useful for folks using eclipse to make sure > they've correctly cut-and-pasted the phalanx of options from the > pkg-config file into eclipse. I think this is a great idea. Why don't you make the content of check_config_body.hpp into a function-like macro (passing the output stream as an argument) ? Then you could treat this as an ordinary header and just 'call' this 'function' at the appropriate place instead. (In that case you presumably wouldn't need the new check_config_body.hpp header at all.) Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From stefan at codesourcery.com Wed Jan 30 15:38:47 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Wed, 30 Jan 2008 10:38:47 -0500 Subject: [vsipl++] [patch] Check config at app build time In-Reply-To: <47A08743.4050109@codesourcery.com> References: <47A07CE5.9060707@codesourcery.com> <47A08743.4050109@codesourcery.com> Message-ID: <47A09A07.6020900@codesourcery.com> Jules Bergmann wrote: > Along the line of making VSIPL++ easier to use from eclipse, I think we > should make --disable-shared-acconfig the default as well. > > In the common case, users building from source, this will put the -D > options in acconfig.hpp, which will make using eclipse easier. > > The only people who need --enable-shared-acconfig are those building > binary packages, something that most users will not do. > > What do folks think? I agree, as I find it much more convenient to store macros in acconfig.h instead of passing it on the command line. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From jules at codesourcery.com Wed Jan 30 16:59:27 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 30 Jan 2008 11:59:27 -0500 Subject: [patch] Fix ATLAS dectection for ubuntu 7.04 Message-ID: <47A0ACEF.5000709@codesourcery.com> This detects ubuntu 7.04's system atlas (such as on verona). Patch applied. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: atlas.diff URL: From brooks at codesourcery.com Wed Jan 30 18:30:34 2008 From: brooks at codesourcery.com (Brooks Moses) Date: Wed, 30 Jan 2008 10:30:34 -0800 Subject: [vsipl++] [patch] Check config at app build time In-Reply-To: <47A09A07.6020900@codesourcery.com> References: <47A07CE5.9060707@codesourcery.com> <47A08743.4050109@codesourcery.com> <47A09A07.6020900@codesourcery.com> Message-ID: <47A0C24A.5000003@codesourcery.com> Stefan Seefeld wrote, at 1/30/2008 7:38 AM: > Jules Bergmann wrote: >> Along the line of making VSIPL++ easier to use from eclipse, I think we >> should make --disable-shared-acconfig the default as well. >> >> In the common case, users building from source, this will put the -D >> options in acconfig.hpp, which will make using eclipse easier. >> >> The only people who need --enable-shared-acconfig are those building >> binary packages, something that most users will not do. >> >> What do folks think? > > I agree, as I find it much more convenient to store macros in acconfig.h > instead of passing it on the command line. This makes sense to me as well. I looked over the documentation change in the patch for this, and it looks good to me. - Brooks From mark at codesourcery.com Wed Jan 30 19:53:47 2008 From: mark at codesourcery.com (Mark Mitchell) Date: Wed, 30 Jan 2008 11:53:47 -0800 Subject: [vsipl++] [patch] Config update In-Reply-To: <479FA504.1000204@codesourcery.com> References: <479F9B23.2010009@codesourcery.com> <479F9DA1.5040303@codesourcery.com> <479F9E60.4090003@codesourcery.com> <479FA2D7.3080804@codesourcery.com> <479FA504.1000204@codesourcery.com> Message-ID: <47A0D5CB.5030606@codesourcery.com> Brooks Moses wrote: > Jules Bergmann wrote, at 1/29/2008 2:04 PM: >>> As an addendum -- for Cell, we settled on powerpc-cell-linux-gnu for the >>> canonical triplet when documenting the --host option; I think it would >>> be good to have this agree with that. >> Sounds fine to me. To be sure I understand the triplet format, >> shouldn't this be 'powerpc-cell-unknown-linux-gnu'? Cell is an >> architectural variant of power, not a systems vendor, right? > > I'll let Mark comment on this, since it was his suggestion. I think > this is one of the cases where the meaning of "system" as the middle > triplet entry is somewhat flexible. :) There's definitely a bikeshed in here... The GNU way is that there are "canonical" triplets and then non-canonical abbreviations. The canonical format is $cpu-$vendor-$os, so "sparc-sun-solaris2.8" if your system is built by Sun, and "sparc-acme-solaris2.8" if your system is built by Acme, but contains a SPARC, and is running Sun's operating system. The world isn't always this simple, and very little software pays attention to the $vendor value. For Sourcery G++, we generally elide $system, and use a non-canonical $cpu-$os format, which is equivalent to $cpu-unknown-$os. So, for example, "powerpc-eabi" is the target triplet for our Power EABI toolchains, even though "powerpc-unknown-eabi" is the canonical triplet. Putting "unknown" into all our file names makes things any easier for users -- and it just looks like we don't know things. :-) The way GNU software is supposed to work is that you take the triplet provided by the user and then run it through config.sub to get a canonnical name. Then, you make all your substantive decisions (optimization, what functionality to include, tec.) based on the canonical name, so that whether the user wrote "powerpc-eabi" or "powerpc-unknown-eabi" makes no difference. AC_CANONICAL_HOST is the autoconf macro that canoicalizes --host=... for you. I guess Joseph is right that the "-" in "powerpc-cell" might be a hazard. I think $cpu should definitely start with "powerpc", since these are Power CPUs, and a lot of things expect to match powerpc*-*-*. It looks like GCC expects you do to "--target=powerpc-eabi" (or whatever) and then ad "--with-cpu=cell" to say that the default CPU is a Cell. So, we could add --with-cpu, and then turn on the Cell bits only if the CPU specified is Cell. That would also give us a mechanism for things like --with-cpu=970 to say "optimize for a 970 CPU". Of course, since we're a library, most of those decisions can be made with "#ifdef __970__" style checks -- but perhaps not all. (Or, we could jut have --enable-cell, which is less general, but perhaps simpler.) So, concretely, here is my revised recommendation: 1. Ensure that our configure scripts are looking at the canonical value of $host, not the non-canonical $host_alias. 2. If reasonably convenient, add --with-cpu=..., and determine that we are using Cell iff (a) $host_cpu matches powerpc*, and (b) $with_cpu matches cell*. (The *s allow people to add version information.) 3. If that's not convenient, recommend "powerpccell-linux-gnu" as the host triplet for Cell GNU/Linux and then determine that we are using Cell iff $host_cpu matches powerpccell*. > P.S.: Mark, could you also comment on whether MCOE should get > powerpc-mercury-mcoe or powerpc-unknown-mcoe? I'm not very certain > about that one at all. Here, I think "powerpc-mcoe" is the obvious choice. We don't care who made the hardware. Again, if we're using the canonical triplet correctly, we should however match $host against powerpc*-*-mcoe* (which means "any version of PowerPC, any system vendor, and any version of MCOE"). -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From mark at codesourcery.com Wed Jan 30 19:59:17 2008 From: mark at codesourcery.com (Mark Mitchell) Date: Wed, 30 Jan 2008 11:59:17 -0800 Subject: [vsipl++] [patch] Config update In-Reply-To: <47A0D5CB.5030606@codesourcery.com> References: <479F9B23.2010009@codesourcery.com> <479F9DA1.5040303@codesourcery.com> <479F9E60.4090003@codesourcery.com> <479FA2D7.3080804@codesourcery.com> <479FA504.1000204@codesourcery.com> <47A0D5CB.5030606@codesourcery.com> Message-ID: <47A0D715.1080100@codesourcery.com> Mark Mitchell wrote: > For Sourcery G++, we generally elide $system, and use a non-canonical > $cpu-$os format, which is equivalent to $cpu-unknown-$os. So, for > example, "powerpc-eabi" is the target triplet for our Power EABI > toolchains, even though "powerpc-unknown-eabi" is the canonical triplet. > Putting "unknown" into all our file names makes things any easier for > users -- and it just looks like we don't know things. :-) Sorry, "does not make things easier". -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From jules at codesourcery.com Wed Jan 30 21:15:40 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 30 Jan 2008 16:15:40 -0500 Subject: [patch] Pool allocation Message-ID: <47A0E8FC.50501@codesourcery.com> Now that 1.4 has been branched ... This allows memory for blocks to be allocated from special pools. The default pool allocates aligned memory (using alloc_align) similar to the status quo. By using a different pool allocator, memory can be allocated from special pools, such as from a pool of huge page memory, or from a pool of special DMA memory, etc. Dense blocks determine their pool from their map, effectively from Local_map. Currently controlling the pool is a bit of hack. When a Local_map is constructed, it captures the current default pool. This allows you to write code like: ... set pool to X // create views using pool X Vector<...> view(...) ... set pool to something else In the future, we could add more elegant ways to set the pool associated with a Local map Local_map loc_aligned(... aligned pool ...); Local_map loc_huge(... use huge pool...) Vector small(4, loc_aligned); Vector big(16384, loc_huge); An immediate impact of this patch is that it allows us to use huge pages with all of then benchmarks, instead of rewriting them to explicitly allocate/use huge pages. Thought? Ok to apply? -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pool.diff URL: From jules at codesourcery.com Thu Jan 31 14:48:35 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Thu, 31 Jan 2008 09:48:35 -0500 Subject: [patch] Config consistency Message-ID: <47A1DFC3.1040106@codesourcery.com> This patch adds some missing configure options for the mondo package. This is necessary (and hopefully sufficient :) to get a consistent acconfig.hpp. Patch applied to trunk and branches/1.4 -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cfg-simd.diff URL: