On 2/3/25 2:49 AM, Richard Sandiford wrote:
Steve Kargl <s...@troutmask.apl.washington.edu> writes:
On Sat, Feb 01, 2025 at 09:49:17PM +0100, Harald Anlauf wrote:
Am 01.02.25 um 21:03 schrieb Steve Kargl:
On Sat, Feb 01, 2025 at 07:25:51PM +0100, Harald Anlauf wrote:
the attached patch downgrades different constant character lengths in an
array constructor from a GNU to a legacy extension, so that users get a
warning with -std=gnu. We continue to generate an error when standard
conformance is requested.
Regtested on x86_64-pc-linux-gnu (found one testcase where this
triggered... :)
OK for mainline?
My vote is 'no'.
This is either a GNU extension or an error. It is certainly
not a legacy issue as array constructors simple cannot appear
old moldy *legacy* codes.
legacy /= moldy.
My intention is to downgrade existing, potentially dangerous
GNU extensions (like this one) carefully to "legacy", but not
with an axe.
I would be in favor of making it a hard error. If you believe
gfortan must be able to compile invalid source, then add an option
such as -fallow-invalid-scalar-character-entities-in-array-constructor.
I don't see why we shall scare users by making code that is currently
accepted silently, because it is a GNU extension, suddenly to a hard
error.
So why must we be so tough?
Because -std=legacy allows a whole bunch of garbage.
Instead of fixing broken code, a user will slap -std=legacy
in a Makefile and move on. Then years from now, you'll see
-std=legacy in a whole bunch of Makefiles whether it is needed
or not. See -maligned-double and -fallow-argument-mismatch as
poster children.
I agree that this is what will happen. But for people running benchmarks,
it's kind-of (kind-of) a feature. Benchmarks tend to include relatively
old code by the time that they're released, and benchmarks continue to be
relevant (or at least widely tested) after they're out of maintenance.
So it has been really useful to have -std=legacy accept old, dangerous code,
since it means that we can continue to test old benchmarks with newer
compilers. Improving the benchmark source to avoid the dangerous constructs
would invalidate the test and make it harder to compare with historical
results.
Again, just my $0.02.
Same here, just wanted to raise the benchmark use case.
Thanks,
Richard
I think we have had good discussion and for sake of the good of the
order I recommend we push this for now. The work has been done.
Regards,
Jerry
