Patch for stricter implicit conversions between vectors

Andrew Pinski
Tue Nov 14 18:36:00 GMT 2006

On Tue, 2006-11-14 at 10:04 -0800, Ian Lance Taylor wrote:
> Andrew Pinski <> writes:
> > On Tue, 2006-11-14 at 12:14 +0000, Mark Shinwell wrote:
> > > - Adds a new flag -flax-vector-conversions to suppress the extra checking
> > >    in the first two points above.
> > 
> > I really really don't want a flag that allows people to create non
> > portable code.  Also this is just a real regression of accepting invalid
> > code, why don't we have a flag for the other cases where we now reject
> > the code?
> We do have such flags.  For example, -fpermissive and
> -ffriend-injection.

Except those are only for C++ and this case is a bit special.

> I feel very strongly that these sorts of flags are required.  Many
> people must compile code which they did not write.  When earlier
> versions of the compiler accepted code, I believe that we must make a
> reasonable effort to help convert their code.  That includes providing
> options to permit their code to compile without requiring them to
> change the code.

Yes and try to compile that code with 3.4.6 (which was released this
year) and it would be rejected right away so the difference here between
the above flags and this case is that we released a GCC which rejected
this code less than a year ago.

> Of course, I don't mean that we should do this in every case.  We
> shouldn't do it when providing the option would be complex, or
> potentially buggy, or would slow down the compiler, or would cause
> other problems.  But in a case like this, adding the option costs
> almost nothing.

Considering a version which was released this year also rejected it is
the reason why this is a bit of a special case and not the normal case.
People are only just moving the 4.x based GCC, in fact some OS's have
not moved yet (OpenBSD for an example) so we are punishing the people
who use older compilers in this case instead of helping them.

> You have to think about the whole range of compiler users, not just
> compiler developers.

I am, think about the people who want to compile the code with 3.4.6
(which was just released this year)?  The code will be fixed because of
those users and not because 4.3.0 rejecting it.

> I also think it is OK to remove these sorts of flags after a few
> releases.  By "a few" I mean more than three.

Wait, so you are saying this case should not matter because the problem
only showed up 2 releases (4.0.0) ago.  See this is the problem, we have
a chance to fix our mistake in 4.2.0 still and people who complain can
be pointed to the fact a compiler released less than a year before, also
rejected the code.  I don't see what the problem is with not having an
option in this case since we are hurting people who use older compilers
instead of helping them (for this one special case).  If it was not a
regression from a version which was released less than a year ago I
would not have a problem with an option as long as it was going to be
supported by the person who wrote the patch and add in when they think
it should be removed and they should add documentation this option is
only temporary (unlike the correct documentation).  Yes this is a lot
but this is to discourage adding options which just stay around for ever
and people don't understand what they do so they get removed.

Also mentioning the option in the warning is incorrect because it just
makes people think they can use the option to fix the problem instead of
fixing the code which needs to be done to compile with 3.4.6 and even
newer compilers.

Andrew Pinski

More information about the Gcc-patches mailing list