Default -fabi-version=0 for 4.9
Our policy on mangling bugs has been that we don't change the mangling unless users explicitly specify -fabi-version. Over time, this means that quite a few bugs have been found but continue to accumulate. Most of these are C++11-specific, which means that as users use C++11 more frequently, the bugs are more likely to affect code in the wild. For templates, it also seems to me that mangling changes have very little negative impact; in most cases the worst that will happen is that a program ends up with two compatible versions of the same function. And none of the changes affect libstdc++.so. For non-template code, any failures will be at link time, making them straightforward to deal with. The only non-mangling ABI change since version 2 is to argument promotion of C++11 scoped enums, and since we've been telling people that they need to rebuild all their C++11 code with every major release anyway, I don't think that's an obstacle. So, for GCC 4.9 I would like to propose that we switch the default ABI version to 0 so that by default we use the most correct mangling. If people really need backward compatible mangling for some reason they can specify the flag appropriately. Jason
C++ conversion: an observation about minimum compiler version
Hi,
This is just an observation, but maybe there is a potential problem.
I am a happy user of GCC and I have many 4.x versions that I use on
three development Linux boxes. The C++ template code in annex triggers a
compile-time error on 4.2, 4.4, 4.6, but not on 4.7. (I suppose this bug
has been found and tracked before.)
No problem with me, I have done projects with significantly less
reliable development tools in the past. I will either upgrade or use a
work-around in the source code (I chose to upgrade, this is server-side
code where tools are under the project leader control).
The observation is *if* the gcc source code has some C++ depency(ies)
which similarly needs say version>=4.7 and a machine has only gcc 4.4
installed, then migrating to e.g. gcc 5.3 requires installing v.X, (4.7
<= X < first-version-that-can't-be-compiled-without-C++).
My observation further hints that that "X" should be decided, and then
lasting support for version "X" should be planned (I say "should" but
who am I to request anything?)
The potential problem, from a tools user perspective, is that upgrading
from 4.4 to 5.3 might be frustrating because the tools user would not
have been warned about planning for an intermediate version
installation. The potential problem is thus one of migration help file,
no less and no more.
Again, many thanks for these development tools.
Regards
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1
Tel. +1-514-385-5691
===
template class t1
{
public:
int length;
};
template class t2 : public t1
{
public:
void f();
};
template
void t2::f()
{
int &len=(t1::length); // ok
t1::length=100; // ok
unsigned char *val=new unsigned char[t1::length]; // ok
int ln=-(t1::length); // ok
int *ptlen=&(t1::length); // address-of operator in this
// base class template member access
// ==> compiler bug with gcc 4.2 to 4.6
}
void fstatic()
{
t2<1000> obj;
obj.f(); // instantiate ...
}
===
In member function 'void t2::f() [with int SIZE = 1000]':
error: cannot convert 'int t1<1000>::*' to 'int*' in initialization
===
Re: Default -fabi-version=0 for 4.9
On 03/04/2013 11:31 AM, Jason Merrill wrote: Our policy on mangling bugs has been that we don't change the mangling unless users explicitly specify -fabi-version. Over time, this means that quite a few bugs have been found but continue to accumulate. Most of these are C++11-specific, which means that as users use C++11 more frequently, the bugs are more likely to affect code in the wild. For templates, it also seems to me that mangling changes have very little negative impact; in most cases the worst that will happen is that a program ends up with two compatible versions of the same function. And none of the changes affect libstdc++.so. For non-template code, any failures will be at link time, making them straightforward to deal with. The only non-mangling ABI change since version 2 is to argument promotion of C++11 scoped enums, and since we've been telling people that they need to rebuild all their C++11 code with every major release anyway, I don't think that's an obstacle. So, for GCC 4.9 I would like to propose that we switch the default ABI version to 0 so that by default we use the most correct mangling. If people really need backward compatible mangling for some reason they can specify the flag appropriately. Seems reasonable. Presumably -Wabi will warn folks if they're doing something that results in a different mangling? A wiki page we can link to when questions arise (as they always will) which includes your rationale above and any hints (such as -Wabi) users can use to detect problems, -fabi-version= guidance for those who wish to keep old behaviour, etc would be helpful. jeff
Re: Default -fabi-version=0 for 4.9
On 03/04/2013 03:46 PM, Jeff Law wrote: Seems reasonable. Presumably -Wabi will warn folks if they're doing something that results in a different mangling? Currently -Wabi warns about things that will are different in a later version; it would probably make sense to allow people to write something like -Wabi=2 to get warnings about changes from version 2 to the current version. A wiki page we can link to when questions arise (as they always will) which includes your rationale above and any hints (such as -Wabi) users can use to detect problems, -fabi-version= guidance for those who wish to keep old behaviour, etc would be helpful. Absolutely. Jason
Re: C++ conversion: an observation about minimum compiler version
On 4 March 2013 19:59, Thierry Moreau wrote: > > The observation is *if* the gcc source code has some C++ depency(ies) which > similarly needs say version>=4.7 and a machine has only gcc 4.4 installed, > then migrating to e.g. gcc 5.3 requires installing v.X, (4.7 <= X < > first-version-that-can't-be-compiled-without-C++). Currently building GCC doesn't require anything newer than GCC 3.4, which is sufficiently ancient that it shouldn't be a problem for most people. This is documented at http://gcc.gnu.org/install/prerequisites.html
Suppress warning for conversion prototype (that is present) (Bug 6144)
Hi All,
I'm working on Apple, so I'm stuck with some ancient stuff. I'm trying
to compile with -Wall -Wextra -Wconversion, and I'm catching a warning
similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38116.
The 38116 bug defers to Bug 6144
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6614). 6144 basically
tells me that the warning is for passing an argument of a different
type than expected. The bizarre part when its expected: it warns about
what would happen if the prototype were missing.
void func (short);
void short_test (void)
{ short x = 0;
func(x);
}
>From the bug report example above, the warning is telling me there
would be a problem if `void func (short);` was not present since it
would be assumed to be `void func (int)` (if I'm reading things
correctly).
How do I turn off warnings for missing prototype conversions that are
not even present? The bug report does not list a workaround.
-Wno-traditional-conversion was unrecognized. So I'm guessing it would
be similar to -Wno-conversion-prototype, but I don't see it at
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html.
Jeff
Re: Modeling predicate registers with more than one bit
On Thu, 28 Feb 2013, Paulo Matos wrote: > Hello, > > I am looking at how to correctly model in GCC predicate > registers that have more than one bit and the value set into to > the predicate register after a comparison depends on the size > of the comparison. > > I have looked into GCC backends but haven't really found any > backend with a similar constraint. Have I missed a backend that > has similar requirements? Except for CCmodes being dependent on source-modes, I'd sneak peeks at PowerPC. > If not, is there any way to currently > (as of HEAD) model this in GCC? IIUC, this sounds simply like having multiple separate condition-code registers, just with a size-dependent CCmodes twist; for each type of comparison where there'd be a separate CCmode variant, you also need separate CCmodes for each source mode M, all separated in cbranchM4 and cstoreM4. brgds, H-P
