[fortran, patch] Fix handling of printf-style position specifiers of the form "%3$d" in error.c (PR29711)
Tobias Burnus
burnus@net-b.de
Thu Dec 7 09:50:00 GMT 2006
Hi,
FX Coudert wrote:
>> PR fortran/29711 <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29711>
> OK, but without the URL in the final ChangeLog :)
Well, I didn't plan to add the URL; I simply copied the changelog from
Bugzilla and modified it; however, I forgot the remove the link, which
Thunderbird duly expanded.
> Sorry for messing this up in the first place,
Errare humanum est.
Brooks Moses wrote:
> Jerry DeLisle wrote:
> > Is there a test case for this condition? Or putting it another
> way, is there
> > a testcase that did not catch the problem that should be fixed?
>
> This particular bit of code, so far as I'm aware, only applies to
> versions of the compiler with translated error messages (since those
> are the only ones that use the "%3$d" form in error messages); it
> doesn't ever get used in the non-translated version.
I think it only gets used for some German and Chinese (zh_TW)
translations [and for C also the Turkish], where the order of arguments
has been changed:
Example:
Error: Symbol '%s' referenced at %L not found in module '%s'
is then in German
Fehler: Bei %2$L referenziertes Symbol »%1$s« nicht im Modul »%3$s«
gefunden
(Error: At %L referenced symbol '%s' not found in module '%s')
That is the first and the second argument have swapped position. As one
is not required to build with native language support, I don't see how
this could be reliably automatically tested.
Sidenote:
Actually, I'm not quite sure whether this should be "referenced" or
"referred"; I think it should be "referred" in this case. At least I get
his error message for "use mod, only: nonexisting" and Richard Main wrote:
"In this particular case, although "referred to" has an awfully similar
root to "referenced", it isn't the same word and the distinction was
intentional. It would have said "referenced" if that's what it meant. I
don't recall why a more clearly different term such as "appears" wasn't
used; maybe there was a reason. Anyway... by the "normal English
meaning", the name in an ONLY is referring to something - that's what
names do."
Cf.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/44aa13e0102ec83d/
> It might be a useful thing to put on the list of regression tests that
> someone should run manually every so often, though, along with the
> very-large-file tests that were mentioned in such a context a month ago.
I think the most reliably regression tests is a large user base, which
also runs nightly builds. And building frequently the programs, one
uses. (I think almost everyone here has a Fortran program which he uses
for production; building not only gfortran but also that program
frequently should make it easier to detect regressions. For instance,
since yesterday the Polyhedron gas_dyn test fails here with
-ftree-vectorize [SEGV; PR30092]. On the other hand, it is also a nice
method to find bugs in other programs.) I currently run Polyhedron and
octopus (tddft.org) nightly.
But if you have a good idea, which non-default regression tests one can
do, go ahead.
Tobias
More information about the Fortran
mailing list