|
From: Carl E. L. <ce...@us...> - 2015-04-16 18:31:53
|
Florian:
I have investigated the message from the gcc 4.9 compiler that you brought to my attention. The
message is:
test_dfp4.c: In function ‘_test_dtstdgq’:
test_dfp4.c:249:13: note: the ABI of passing aggregates with 16-byte alignment will change in a future GCC release
static void _test_dtstdgq(int BF, int DGM, dfp_val_t val1, dfp_val_t x1 __attribute__((unused)))
I have talked with the IBM compiler team. The warning went into the gcc 4.9 compiler for the PPC64
platform. There will be an ABI change made in the gcc 5.0 with regards to the alignment of 128-bit
arguments to a function. As I understand it, this will only be an issue for code when linking code
that was compiled with different gcc versions. If some of the code was compiled with a pre gcc 5.0
compiler and it is linked with functions with 128-bit arguments that were compiled with a gcc 5.0
or newer compiler,there will be a problem of the arguments not aligning properly.
In my case, all of the code is in the same regression test file. So, as far as the Valgrind regression
tests go this is not an issue.
There is nothing that can be done at the source code level to eliminate the notice from the compiler.
Carl Love
|
|
From: Florian K. <fl...@ei...> - 2015-04-17 09:09:34
|
On 16.04.2015 20:31, Carl E. Love wrote: > The warning went into the gcc 4.9 compiler for the PPC64 > platform. There will be an ABI change made in the gcc 5.0 with regards to the alignment of 128-bit > arguments to a function. As I understand it, this will only be an issue for code when linking code > that was compiled with different gcc versions. If some of the code was compiled with a pre gcc 5.0 > compiler and it is linked with functions with 128-bit arguments that were compiled with a gcc 5.0 > or newer compiler,there will be a problem of the arguments not aligning properly. > OK. Thanks for the clarification. > There is nothing that can be done at the source code level to eliminate the notice from the compiler. > Sigh. Florian |
|
From: Patrick J. L. <lop...@gm...> - 2015-04-17 15:57:24
|
On Thu, Apr 16, 2015 at 11:31 AM, Carl E. Love <ce...@us...> wrote: > > > There is nothing that can be done at the source code level to eliminate the notice from the compiler. Really? Glancing through the GCC source, it looks like: #pragma GCC diagnostic ignored "-Wpsabi" ...should do the trick. Or just pass "-Wno-psabi" on the command line. (Or am I missing something?) Probably should be conditional on GCC version, of course. - Pat |
|
From: Florian K. <fl...@ei...> - 2015-04-18 10:47:29
|
On 17.04.2015 17:57, Patrick J. LoPresti wrote: > On Thu, Apr 16, 2015 at 11:31 AM, Carl E. Love <ce...@us...> wrote: >> >> >> There is nothing that can be done at the source code level to eliminate the notice from the compiler. > > Really? Glancing through the GCC source, it looks like: > > #pragma GCC diagnostic ignored "-Wpsabi" > > ...should do the trick. Or just pass "-Wno-psabi" on the command line. > (Or am I missing something?) > > Probably should be conditional on GCC version, of course. What you describe would work but require additional configury. And that is something I would like to avoid. We already have 3000 lines of it. If will be less work to simply modify the test to not pass these values as function arguments. Perhaps just pass a pointer instead or bundle the function arguments in a struct and pass a pointer to that or ..... Florian |
|
From: Patrick J. L. <lop...@gm...> - 2015-04-19 14:58:04
|
On Sat, Apr 18, 2015 at 3:47 AM, Florian Krohm <fl...@ei...> wrote: > > What you describe would work but require additional configury. And that > is something I would like to avoid. We already have 3000 lines of it. > If will be less work to simply modify the test to not pass these values > as function arguments. Assuming that is possible, I agree. Although even that demands cluttering the source with a long comment if the needed approach is unnatural. When it is impossible or inconvenient to modify the source, the approach I have seen is to place all such warning suppressions in one header file. And then dispatch on the compiler version in that header (not in the configure script). Something like <http://stackoverflow.com/a/18463996/768469>. This approach keeps the source uncluttered, and it adds little to the testing burden since (a) it is simple enough to get right every time and (b) these are just warning suppressions. This is part of the cost of keeping everything "-Wall clean" across multiple platforms. But it is not a large cost compared to the benefits. - Pat |
|
From: Carl E. L. <ce...@us...> - 2015-04-21 15:45:54
|
On Sun, 2015-04-19 at 07:57 -0700, Patrick J. LoPresti wrote: > On Sat, Apr 18, 2015 at 3:47 AM, Florian Krohm <fl...@ei...> wrote: > > > > What you describe would work but require additional configury. And that > > is something I would like to avoid. We already have 3000 lines of it. > > If will be less work to simply modify the test to not pass these values > > as function arguments. > > Assuming that is possible, I agree. Although even that demands > cluttering the source with a long comment if the needed approach is > unnatural. > > When it is impossible or inconvenient to modify the source, the > approach I have seen is to place all such warning suppressions in one > header file. And then dispatch on the compiler version in that header > (not in the configure script). Something like > <http://stackoverflow.com/a/18463996/768469>. > > This approach keeps the source uncluttered, and it adds little to the > testing burden since (a) it is simple enough to get right every time > and (b) these are just warning suppressions. > > This is part of the cost of keeping everything "-Wall clean" across > multiple platforms. But it is not a large cost compared to the > benefits. > > - Pat > The test code follows a basic structure which is used across a wide range of tests. I will take a look at the code and see if I can put the arguments into a struct and pass the struct without adding too much confusion to the code. I think that would be preferable to messing around with the configuration file for the compile. Carl Love |
|
From: Carl E. L. <ce...@us...> - 2015-04-22 20:22:25
|
On Sun, 2015-04-19 at 07:57 -0700, Patrick J. LoPresti wrote: > On Sat, Apr 18, 2015 at 3:47 AM, Florian Krohm <fl...@ei...> wrote: > > > > What you describe would work but require additional configury. And that > > is something I would like to avoid. We already have 3000 lines of it. > > If will be less work to simply modify the test to not pass these values > > as function arguments. > > Assuming that is possible, I agree. Although even that demands > cluttering the source with a long comment if the needed approach is > unnatural. > > When it is impossible or inconvenient to modify the source, the > approach I have seen is to place all such warning suppressions in one > header file. And then dispatch on the compiler version in that header > (not in the configure script). Something like > <http://stackoverflow.com/a/18463996/768469>. > > This approach keeps the source uncluttered, and it adds little to the > testing burden since (a) it is simple enough to get right every time > and (b) these are just warning suppressions. > > This is part of the cost of keeping everything "-Wall clean" across > multiple platforms. But it is not a large cost compared to the > benefits. > > - Pat > The 128-bit function arguments are passed by value. By changing the arguments to pointers we can pass them by reference and thus avoid the compiler issue. The change is simple and doesn't impact the readability of the code. I put in a comment about why it is being passed by reference. I have changed a number of the function calls so far and it seems to take care of the issue. Just working on finishing up the rest. This source code change will fix the issue. Carl Love |