[Bug rust/114629] New: rust-ast-resolve-expr contains bloated code for funny_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629 Bug ID: 114629 Summary: rust-ast-resolve-expr contains bloated code for funny_error Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rust Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org Target Milestone: --- The file contains funny_error, which unnecessarily bloats the executable in all installations. That's a waste of resources. The identifier funny_error should be removed, including everything that depends on it. (Background: As the German translator of GCC, I strictly oppose against insulting the GCC users, therefore I have translated that message free of any humor. There's enough code bloat already, I consider this one unnecessary.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/114629] New: rust-ast-resolve-expr contains bloated code for funny_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629 Bug ID: 114629 Summary: rust-ast-resolve-expr contains bloated code for funny_error Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rust Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org Target Milestone: --- The file contains funny_error, which unnecessarily bloats the executable in all installations. That's a waste of resources. The identifier funny_error should be removed, including everything that depends on it. (Background: As the German translator of GCC, I strictly oppose against insulting the GCC users, therefore I have translated that message free of any humor. There's enough code bloat already, I consider this one unnecessary.)
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 --- Comment #13 from Roland Illig --- See also bug 114407.
[Bug target/114407] New: Typo 'enabing' in loongarch-opts.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114407 Bug ID: 114407 Summary: Typo 'enabing' in loongarch-opts.cc Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: translation Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- Target: loongarch "enabing %qs promotes %<%s%s%> to %<%s%s%>" Should be "enabling".
[Bug fortran/80012] FIXME in diagnostic "%s procedure at %L is already declared as %s procedure" from symbol.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80012 --- Comment #8 from Roland Illig --- (In reply to Jakub Jelinek from comment #7) > (In reply to Jerry DeLisle from comment #5) > > Another way is to build an error message with snprintf for example and use > > that string in the error message. > > That is translation unfriendly. And the German translator (me) is particularly picky about these topics, so whenever you assemble diagnostics using snprintf, you'll get a new bug report from me; see #114364 for an example.
[Bug c/114364] Untranslatable string 'in intervening code'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114364 --- Comment #3 from Roland Illig --- The diff looks good to me. Untested.
[Bug c/114364] Untranslatable string 'in intervening code'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114364 --- Comment #1 from Roland Illig --- Oops, I misinterpreted the code, as 'in intervening code' is indeed translatable, but 'as loop variable' isn't, so the bug report is still valid.
[Bug c/114364] New: Untranslatable string 'in intervening code'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114364 Bug ID: 114364 Summary: Untranslatable string 'in intervening code' Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- >From c-family/c-omp.cc: > error_at (LOCATION_OR (eloc, loc), > "variable %qD used %s is bound " > "in intervening code", bad, context); As a translator, I have no chance of translating 'in intervening code'. Sentence fragments must not be embedded using %s, as other natural languages differ structurally.
[Bug target/114083] Possible word play on conditional/unconditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083 --- Comment #6 from Roland Illig --- (In reply to Maciej W. Rozycki from comment #4) > The flag enables the use of the conditional-move operations even with > hardware that has no support for such operations, hence unconditionally. Thank you for your explanation, that made the intention much clearer to me. There's a problem with the wording though. On a platform that doesn't support conditional-move operations, it's not possible to _use_ conditional-move operations. Period. It's only possible to _emulate_ the behavior of these operations. I'm not sure how consistently the words 'operation' and 'instruction' are used in the GCC code base and documentation, but I mixed them up in my mind when I tried to translate this option. > if someone has > a better proposal, then please feel free to submit a patch. Or would: > > Enable conditional-move operations unconditionally. > > be preferable? No. Above, you wrote that the branchless instructions would be selected _if_ they are cheaper than the equivalent branch instructions. This is a condition, thus the word 'unconditionally' doesn't fit. What about this? > Prefer branchless move instructions where cheaper.
[Bug target/114083] Possible word play on conditional/unconditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083 --- Comment #2 from Roland Illig --- I don't understand why the word 'unconditionally' is necessary or useful here. Isn't the option -mmovcc by itself already a condition? That would make the word 'unconditionally' wrong.
[Bug driver/114082] Guidelines for options are empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082 --- Comment #1 from Roland Illig --- If you decide to keep the guidelines, here are a few ideas: * Use the simplest English you can, while still being precise. * Don't try to be funny. (See #114083 for a possible case)
[Bug target/114083] New: Possible word play on conditional/unconditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083 Bug ID: 114083 Summary: Possible word play on conditional/unconditional Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- Target: riscv riscv.opts says: > mmovcc > Target Var(TARGET_MOVCC) > Enable conditional moves unconditionally. Is the conditional/unconditional a play of words? As the German translator, I find it more confusing than helpful. Or is there a deeper meaning? In that case, the option description should be longer.
[Bug preprocessor/114082] New: Guidelines for options are empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082 Bug ID: 114082 Summary: Guidelines for options are empty Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- https://gcc.gnu.org/onlinedocs/gccint/Guidelines-for-Options.html The section is empty, and it has been so since its creation in 2018. When I saw that section, I wasn't sure whether this was a technical error on the web server (unlikely but still possible) or in the .texi processing. Since the section has been missing since 2018, it may be better to remove it completely. Or, alternatively, write down the most common consensus, to be amended later.
[Bug target/113324] internal compiler error: in reload_combine_note_use, at postreload.c:1534
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113324 Roland Illig changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #3 from Roland Illig --- (In reply to Mikael Pettersson from comment #2) > I can reproduce with gcc-10.5.0 hosted on x86_64-pc-linux-gnu targeting > vax-netbsdelf, but not with gcc-11.4.0. 12.3.0, or 13.2.0. Thanks for the confirmation, I'll wait until NetBSD updates to GCC 12 then.
[Bug target/113324] New: internal compiler error: in reload_combine_note_use, at postreload.c:1534
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113324 Bug ID: 113324 Summary: internal compiler error: in reload_combine_note_use, at postreload.c:1534 Product: gcc Version: 10.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- Target: vax Created attachment 57035 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57035=edit preprocessed source causing the internal compiler error GCC 10.5.0 on NetBSD/x86_64, cross-built with target NetBSD/vax crashes: vax--netbsdelf-gcc -ftrapv -std=gnu99 -O2 -c cgram.c during RTL pass: postreload cgram.c: In function 'yyparse': cgram.c:218:1: internal compiler error: in reload_combine_note_use, at postreload.c:1534 218 | } | ^ 0xd6fcc3 reload_combine_note_use /home/rillig/proj/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/postreload.c:1534 0xd70052 reload_combine_note_use /home/rillig/proj/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/postreload.c:1596 0xd70052 reload_combine_note_use /home/rillig/proj/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/postreload.c:1596 0xd6f694 reload_combine /home/rillig/proj/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/postreload.c:1383 0xd6c093 reload_cse_regs /home/rillig/proj/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/postreload.c:67 0xd71e8c execute /home/rillig/proj/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/postreload.c:2334 Replacing -O2 with -Os doesn't crash. Removing -ftrapv doesn't crash.
[Bug fortran/109105] Error-prone format string building in resolve.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109105 --- Comment #3 from Roland Illig --- Nothing has changed yet. There is no built-in validation in the translated messages that each '%%L' from the msgid matches a '%%L' from the msgstr. I suggest to replace the label 'bad_op' with a function named 'bad_op', so that the format strings contain '%L' instead of the current '%%L', so that gettext can validate the format strings in the translations.
[Bug target/110772] strange code generated for bit-field access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772 --- Comment #8 from Roland Illig --- When I compile the attached code with "ARM GCC 10.5.0" and "-O2 -fPIE -ftrapv" on godbolt.org, the generated code is correct (you can search for "#327" in the output and then go back one branch). The code generated by godbolt.org "ARM GCC 11.4.0" with "-O2 -fPIE -ftrapv" looks good as well. So it could also be that the NetBSD version of GCC is missing a bug-fix or two.
[Bug target/110772] strange code generated for bit-field access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772 --- Comment #7 from Roland Illig --- Created attachment 55612 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55612=edit Preprocessed source from comment 5
[Bug target/110772] strange code generated for bit-field access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772 Roland Illig changed: What|Removed |Added Attachment #55598|0 |1 is obsolete|| Attachment #55599|0 |1 is obsolete|| --- Comment #6 from Roland Illig --- Created attachment 55611 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55611=edit Precompiled source from comment 5
[Bug target/110772] strange code generated for bit-field access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
--- Comment #5 from Roland Illig ---
Sorry for the confusing description. Let me try again.
NetBSD lint includes a yacc parser for C code. This parser contains the rules
'block_item_list' and 'block_item':
https://github.com/NetBSD/src/blob/7ebcd1679b455e619909ec9c128e8ad7f103ded9/usr.bin/xlint/lint1/cgram.y#L1804
> block_item_list: /* C99 6.8.2 */
> block_item
> | block_item_list block_item {
> if ($1 && !$2)
> /* declarations after statements is a C99 feature */
> c99ism(327);
> $$ = $1 || $2;
> }
The rule 'block_item' remembers in 'y_seen_statement' whether the item was a
statement, so that the parser rule 'block_item_list' can warn in C90 mode.
In another part of the parser, the rule 'gcc_attribute' handles the keyword
'const', by accessing 'y_type_qualifiers.tq_const', which on 2023-07-15 was a
_Bool bit-field member in 'struct type_qualifiers'.
https://github.com/NetBSD/src/blob/7ebcd1679b455e619909ec9c128e8ad7f103ded9/usr.bin/xlint/lint1/cgram.y#L2197
> gcc_attribute:
> | type_qualifier {
> if (!$1.tq_const)
> yyerror("Bad attribute");
> }
On big-endian arm and powerpc, the code that GCC 10.5.0 generates for the
'block_item_list' parser rule depends on whether the 'gcc_attribute' parser
rule accesses a bit-field member or not. This does not make sense to me, as I
expect the parser rules to be independent.
When I compile this parser on arm with -O2 and run lint in C90 mode, it not
only warns about declarations after statements, but also about statements after
statements.
$ gcc -O2 -ftrapv -fPIE -std=gnu99 -S cgram.c -o cgram.casmv -fverbose-asm
The code that is generated for the condition '$1 && !$2' is:
> @ cgram.y:1802: if ($1 && !$2)
> ldr r6, .L580+796
> add r6, pc, r6
> ldr r4, [r6, #20]
> ldrbr3, [r4, #-8] @ $1.y_seen_statement
> cmp r3, #0
> beq .L368
> @ cgram.y:550: $$ = build_unary($2 == INC ? INCAFT : DECAFT, $3, $1);
> ldrbr3, [r4]
> @ cgram.y:1802:
> lsrsr3, r3, #7 @ $2.y_type_qualifiers.tq_const
> beq .L562
(Annotations hand-edited by me.)
Two strange things happen here:
1. The code from cgram.y:550 is completely unrelated, so it should not have
been mentioned here. The 'ldrb' is correct, so maybe it's just the attribution
that is wrong.
2. The expressions '$1' and '$2' both have type _Bool. Nevertheless, the second
bool is accessed as if it were a bit-field. Due to this access, no matter
whether '$2 as bool' is 1 or 0, the the expression '($2 as bit-field) >> 7'
always evaluates to 0, so the condition '$1 && !$2' evaluates to true, which
results in the additional warnings from lint.
Instead of lsrs, GCC should have generated a cmp instruction.
I don't have any other GCC version installed on the machine, so I cannot test
whether GCC 11.4.0 behaves differently.
[Bug c/110772] strange code generated for bit-field access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772 --- Comment #1 from Roland Illig --- Created attachment 55599 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55599=edit precompiled code that works as intended
[Bug c/110772] New: strange code generated for bit-field access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
Bug ID: 110772
Summary: strange code generated for bit-field access
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
Target: arm
Created attachment 55598
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55598=edit
precompiled code that generates unrelated diagnostics
In NetBSD's lint, I changed 'struct type_qualifier' from an enum to a set of
bit-fields. It worked well on x86_64 but not on arm and powerpc.
https://github.com/NetBSD/src/commit/35c652085d26b93b94f55312f715361ee0cd2043
On these two 32-bit platforms, lint generated some unrelated and wrong
diagnostics.
I tracked the difference down to a single line of code, and changing that line
changes unrelated code.
In the attached p5.i, applying the following diff changes not only the code in
cgram.y:529, but also in cgram.y:489.
$ diff -u p5.i p3.i
--- p5.i2023-07-22 00:22:30.748103516 +0200
+++ p3.i2023-07-22 00:22:05.448298739 +0200
@@ -6424,7 +6424,7 @@
case 68:
# 528 "cgram.y"
{
- if (!yystack.l_mark[0].y_type_qualifiers.tq_const)
+ if (!yystack.l_mark[0].y_seen_statement)
yyerror("Bad attribute");
}
# 1 ""
$ gcc --version
gcc (nb2 20230710) 10.5.0
$ uname -mp
evbarm earmv7hfeb
$ gcc -O2 -S p5.i -fverbose-asm
$ gcc -O2 -S p3.i -fverbose-asm
$ gcc -O2 -c p5.i
$ gcc -O2 -c p3.i
$ objdump -dr p5.o > p5.dis
$ objdump -dr p3.o > p3.dis
$ diff -u p5.dis p3.dis
...
- ba8: e1b033a3lsrsr3, r3, #7
+ ba8: e353cmp r3, #0
...
-1010: e1b033a3lsrsr3, r3, #7
+1010: e353cmp r3, #0
The code has changed in two places. Searching for the text "#7" in the p5.s
file shows that the two places where the code has changed are in cgram.y:529
and cgram.y:489.
I doubt that the code invokes undefined behavior, as it is fairly standard yacc
code. Therefore I suspect a compiler error.
Compiling the code with -Os or -O1 instead of -O2 does not show this behavior.
Removing the ':1' from the members in struct type_qualifier does not show this
behavior.
Compiling the code on x86_64 or i386 does not show this behavior.
[Bug tree-optimization/110519] New: Optimize loop that only assigns to a local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110519
Bug ID: 110519
Summary: Optimize loop that only assigns to a local variable
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
~~~c
struct symbol {
struct symbol *next;
};
void f(const struct symbol *sym)
{
for (const struct symbol *s = sym; s != (void *)0; s = s->next)
do { } while (0);
}
~~~
The above code was extracted from
<https://github.com/NetBSD/src/blob/f74666e8d086952b27d76155223a5d497e69f5a8/usr.bin/xlint/lint1/decl.c#L1319>.
Several other compilers know that this loop has no side effects, even at low
optimization levels, see <https://godbolt.org/z/Y85EGcW3d>.
[Bug c/110322] New: Be more helpful when a varargs function is called in a wrong way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110322
Bug ID: 110322
Summary: Be more helpful when a varargs function is called in a
wrong way
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
~~~c
#include
#include
static void __attribute__((__format__(__printf__, 1, 2)))
my_printf(const char *fmt, ...)
{
va_list ap;
va_start(ap, fmt);
fprintf(stderr, fmt, ap);
va_end(ap);
}
int
main(int argc, char **argv)
{
my_printf("%d", 4);
my_printf("%.*s\n", 5, "hello, world");
return 0;
}
~~~
In the above program, I am accidentally trying to call fprintf with a va_list,
instead of the correct vfprintf. GCC warns:
sl.c:10:2: error: format not a string literal, argument types not checked
[-Werror=format-nonliteral]
10 | fprintf(stderr, fmt, ap);
| ^~~
In this situation, where my only mistake was to forget the 'v' from the
function name, GCC should not complain that the format string is not a string
literal, but rather that I'm calling the wrong function.
[Bug c/110318] Unused string literal is retained in assembler file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110318
--- Comment #1 from Roland Illig ---
A variant on the same theme:
~~~c
typedef typeof(sizeof 0) size_t;
int memcmp(const void *, const void *, size_t);
int demo(const char *s) {
if (memcmp(s, "12345678", 8) == 0)
return 8;
if (memcmp(s, "1234567", 7) == 0)
return 7;
if (memcmp(s, "123456", 6) == 0)
return 6;
if (memcmp(s, "12345", 5) == 0)
return 5;
if (memcmp(s, "1234", 4) == 0)
return 4;
if (memcmp(s, "123", 3) == 0)
return 3;
if (memcmp(s, "12", 2) == 0)
return 2;
if (memcmp(s, "1", 1) == 0)
return 1;
return 0;
}
~~~
It looks as if the string literals are retained if their length is not a power
of two.
[Bug c/110318] New: Unused string literal is retained in assembler file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110318
Bug ID: 110318
Summary: Unused string literal is retained in assembler file
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
~~~c
typedef typeof(sizeof 0) size_t;
int memcmp(const void *, const void *, size_t);
int demo(const char *);
int demo(const char *p) {
const char *start = p;
while (*p == 'C')
p++;
if (p - start == 2 && memcmp(start, "if", 2) == 0)
return 2;
if (p - start == 6 && memcmp(start, "ifndef", 6) == 0)
return 6;
return 0;
}
~~~
$ uname -a
NetBSD nbcurr.roland-illig.de 10.99.3 NetBSD 10.99.3 (GENERIC) #0: Fri Apr 21
02:17:32 UTC 2023
$ gcc-12.2.0 -O2 -S code.c
$ grep string code.s
.string "ifndef"
The string "ifndef" is retained, even though it is not used in the code,
because the comparison is inlined. Curiously, the string "if" is removed.
Both strings should be removed, as they are unnecessary.
[Bug c/110259] New: Wrong warning 'conversion to unsigned int' with enum and comma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110259
Bug ID: 110259
Summary: Wrong warning 'conversion to unsigned int' with enum
and comma
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
~~~c
enum e {
e1,
e2,
};
int side_effect(void);
enum e demo(_Bool, enum e);
enum e
demo(_Bool cond, enum e c1)
{
enum e var = cond
?
c1
:
(
side_effect(),
e2
);
return var;
}
~~~
gcc-12.2.0 gcc -O2 -Wconversion -c indent.c
indent.c: In function ‘demo’:
indent.c:16:22: warning: conversion to ‘unsigned int’ from ‘int’ may change the
sign of the result [-Wsign-conversion]
16 | :
| ^
Same result for -ansi, -std=c99, -std=c2x, as well as for GCC 10.4.0.
Removing the 'side_effect(),' makes the warning disappear.
The comma operator has the type of its right operand, therefore I don't see
where the 'unsigned' might come from.
[Bug c/109905] New: Missed misleading indentation with braces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109905
Bug ID: 109905
Summary: Missed misleading indentation with braces
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
https://github.com/NetBSD/src/blob/93dc650849c98c54c31aa9cbbce9affaaf649563/bin/cat/cat.c#L185
has misleading indentation, as the 'else' branch does not start with a '{'.
I tried GCC 10 and GCC 12, which don't detect this. Maybe GCC 14 should.
[Bug modula2/109488] New: typo in lang.opt: libraries maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109488 Bug ID: 109488 Summary: typo in lang.opt: libraries maybe Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- wrong: > libraries maybe correct: > libraries may be
[Bug modula2/109315] New: typo: inconsistant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109315 Bug ID: 109315 Summary: typo: inconsistant Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- m2decl.cc says: > inconsistant That should be 'inconsistent'.
[Bug fortran/109314] New: Typo 'composit' in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109314 Bug ID: 109314 Summary: Typo 'composit' in diagnostic Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- fortran/openmp.cc says: > Invalid combined or composit directive 'composit' should probably be 'composite'. There is no test case for this diagnostic.
[Bug c++/109309] New: Untranslated text in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109309 Bug ID: 109309 Summary: Untranslated text in diagnostic Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- In cp/contracts.cc, check_postcondition_result says: > error_at (loc, "%s does not return a value to test", what); At that point, 'what' contains either 'constructor', 'destructor' or 'function'. These words may require different grammatical forms in non-English languages. To fix this, the variable 'what' should be inlined into the 3 diagnostics.
[Bug gcov-profile/109297] New: typo: subcomand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109297 Bug ID: 109297 Summary: typo: subcomand Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: marxin at gcc dot gnu.org Target Milestone: --- 3 times
[Bug fortran/109105] New: Error-prone format string building in resolve.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109105 Bug ID: 109105 Summary: Error-prone format string building in resolve.cc Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: translation Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- The function resolve_operator constructs a format string and then passes it to gfc_error. This approach is wrong, and if a translator such as me makes a typo in the translation, GCC can crash. Instead of jumping to bad_op, each error must be handled individually, and the messages to be translated must be marked as having format gcc-internal-format or gfc-internal-format, not c-format.
[Bug other/109103] New: Missing function internal_error_at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109103 Bug ID: 109103 Summary: Missing function internal_error_at Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- m2expr.c says: > error_at ( > location, > "internal error: not expecting operand1 to be a constant set"); This should rather be a call to internal_error_at, but that function does not exist yet. For symmetry with the other error reporting functions, it should be added.
[Bug modula2/109102] New: Wrong quotes in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109102 Bug ID: 109102 Summary: Wrong quotes in diagnostic Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- m2builtins.cc says: > %s:%d:assertion of condition `%s' failed The backtick and single quote should be replaced with %< and %>, see <https://gcc.gnu.org/onlinedocs/gccint/Guidelines-for-Diagnostics.html#Quoting>.
[Bug fortran/109101] New: Wrong quotes in OpenMP diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109101 Bug ID: 109101 Summary: Wrong quotes in OpenMP diagnostic Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- scanner.cc says: > Ignoring '!$omx' vendor-extension sentinel at %C The single quotes should be replaced with %< and %>, see <https://gcc.gnu.org/onlinedocs/gccint/Guidelines-for-Diagnostics.html#Quoting>.
[Bug target/109100] Possible typo CRS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109100 --- Comment #1 from Roland Illig --- While here: In that same message, there is a single space between sentences 1 and 2, but 2 spaces between sentences 2 and 3. While here: can not is usually spelled cannot.
[Bug target/109100] New: Possible typo CRS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109100 Bug ID: 109100 Summary: Possible typo CRS Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- Target: riscv riscv.opt says: > Enable the CSR checking for the ISA-dependent CRS and the read-only CSR. Is the CRS a typo and should be CSR? As the German translator, I'm not familiar with either of these abbreviations, that's why I'm asking.
[Bug c/109034] Missing space in diagnostics about '^' and '<<'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109034 --- Comment #1 from Roland Illig --- While here: > "you can silence this warning by using a hexadecimal constant" > " (%wx rather than %wd)", %x requires an unsigned argument, %wd requires a signed argument, so %wd should probably be %wu instead.
[Bug c/109034] New: Missing space in diagnostics about '^' and '<<'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109034 Bug ID: 109034 Summary: Missing space in diagnostics about '^' and '<<' Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- > "result of %<%wu^%wu%> is %wu;" > " did you mean %<1 << %wu%> (%wu)?", Since '^' is a binary operator, it is usually enclosed in spaces. Please confirm that you really want to omit the spaces in this place. If you want to omit the spaces, please document it in a /* TRANSLATORS: */ comment.
[Bug rtl-optimization/109033] Some messages are not understandable by ordinary user
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109033 --- Comment #1 from Roland Illig --- > "%@ %s (fndecl %qD, depth %i)", Why am I supposed to translate this string? It just doesn't make sense to translate this into German, or any other natural language.
[Bug rtl-optimization/109033] New: Some messages are not understandable by ordinary user
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109033
Bug ID: 109033
Summary: Some messages are not understandable by ordinary user
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
> error ("returns_twice call is %s in basic block %d",
This message must not be user-visible, except in a call to internal_error.
In general, the word "basic block" must not occur in user-visible messages.
> misplaced = "not first";
This string must not be embedded directly in a diagnostic, as it is not
translated.
> error ("fallthru edge after a control statement in bb %d",
The abbreviation 'bb' must not be user-visible.
Could we please agree that internal error messages are not to be translated?
[Bug modula2/109032] message 'compiler checks to force' is too complicated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109032 --- Comment #5 from Roland Illig --- While here: > dependancies Typo; should be dependencies.
[Bug modula2/109032] message 'compiler checks to force' is too complicated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109032 --- Comment #4 from Roland Illig --- While here: > (* >BuildDivM2 - build and return ((op2 < 0) : (op1 divtrunc op2) ? (op1 > divfloor op2)) > when -fiso, -fpim4 or -fpositive-mod-floor-div is present else > return op1 div trunc op2 > *) Did you swap the operators '?' and ':' here? I had to look this up because this message was completely unclear to me: > force positive result from MOD and DIV result floor The explanation from gm2.texi is much clearer: > All modulus results are positive and the results from the division are rounded to the floor.
[Bug modula2/109032] message 'compiler checks to force' is too complicated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109032 --- Comment #3 from Roland Illig --- While here: > specify the library order, currently legal entries include: log, min, pim, > iso or their directory name equivalent m2log, m2min, m2pim, m2iso. In what legislation are these entries "legal"? Why the word 'include'? That means that there are others that are not listed here. This message ends with a '.', the other messages don't.
[Bug modula2/109032] message 'compiler checks to force' is too complicated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109032 --- Comment #2 from Roland Illig --- While here: > turns on runtime checking to check whether a floating point number is about > to exceed range What exactly does "is about to" mean, and why didn't you just write "exceeds the range"?
[Bug modula2/109032] message 'compiler checks to force' is too complicated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109032 --- Comment #1 from Roland Illig --- While here: > turns on runtime checking to check whether a CASE statement requires an ELSE > clause when on was not specified Did you mean "when one was not"?
[Bug modula2/109032] New: message 'compiler checks to force' is too complicated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109032 Bug ID: 109032 Summary: message 'compiler checks to force' is too complicated Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- > compiler checks to force definition module procedure parameter names with > their implementation module counterpart This message is not understandable, especially the word 'definition module procedure parameter names' is too long to be understood quickly. I suggest rewording it to: at compile time, ensure that procedure parameter names in the definition module match those in the implementation module
[Bug translation/108890] New: Translation mistakes 2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108890 Bug ID: 108890 Summary: Translation mistakes 2023 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- > %qs is loaded but symbol %qs is not found: %s That string is marked as 'format-c' but should be 'format-gcc-internal'. > to generate dependencies you must specify '-fcpp' Trailing whitespace, wrong quotes. > -frust-crate= Set the crate name for the compilation > -frust-dump-\tDump Rust frontend internal information. The upper is indented using spaces, the lower using a single tab. That's inconsistent. > -frust-max-recursion-depth=integer Placeholders should be enclosed in <>. > -frust-mangling=[legacy|v0] Choose which version to use for name mangling The word 'Choose' is redundant and should be removed. This word occurs in other messages as well. > Flag to enable embeding metadata directly into object files The word 'Flag' is redundant. Typo in 'embeding'. > -frust-compile-until=[ast|attributecheck|expansion|nameresolution|lowering|typecheck|privacy|unsafety|const|copimlation|end] > When to stop in the pipeline when compiling Rust code The word 'until' sounds inclusive, the phrase 'When to stop' sounds exclusive. Typo in 'copimlation'. > inproper usages Typo in 'inproper'. > Enable certain features present drafts of C++ Contracts. Grammar?
[Bug tree-optimization/105295] New: missed optimization with -ftrapv for conditional constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105295
Bug ID: 105295
Summary: missed optimization with -ftrapv for conditional
constants
Product: gcc
Version: 12.0
URL: https://godbolt.org/z/4rojo77a7
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
~~~c
int sum_const(_Bool a, _Bool b)
{
return (a ? 1 : 0 ) + (b ? 1 : 0);
}
int sum_unknown(int a, int b)
{
return a + b;
}
~~~
For both functions, GCC calls __addvsi3, even though in sum_const, it is easy
to see that no overflow can ever happen since the sum is always in the range [0
... 2].
Clang optimizes this code reasonably.
ICC apparently does not care about -ftrapv at all.
[Bug c/105209] New: internal compiler error: in store_data_bypass_p_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105209
Bug ID: 105209
Summary: internal compiler error: in store_data_bypass_p_1
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
Target: alpha
$ cat <<'EOF' > tree.c
typedef struct tnode_t {
struct tnode_t *tn_left, *tn_right;
int v_quad;
} tnode_t;
int constant_addr(const tnode_t *, long *);
int constant_addr(const tnode_t *tn, long *offsp)
{
long offs1 = 0, offs2 = 0;
if (tn->v_quad > 0) {
offs1 = tn->v_quad;
return 0;
} else if (tn->v_quad > -1) {
offs2 = tn->tn_right->v_quad;
if (!constant_addr(tn->tn_left, ))
return 0;
} else {
return 0;
}
*offsp = offs1 + offs2;
return 1;
}
EOF
$ /home/rillig/builds/alpha-tools/bin/alpha--netbsd-gcc -O2 -ftrapv -c tree.c
during RTL pass: sched1
/home/rillig/proj/src/usr.bin/xlint/lint1/tree.c: In function 'constant_addr':
/home/rillig/proj/src/usr.bin/xlint/lint1/tree.c:23:1: internal compiler error:
in store_data_bypass_p_1, at recog.c:3714
23 | }
| ^
$ gcc --version
alpha--netbsd-gcc (NetBSD nb1 20210411) 10.3.0
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 104552, which changed state. Bug 104552 Summary: Mistakes in strings to be translated in GCC 12 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 Roland Illig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #40 from Roland Illig --- I have split all remaining issues from this bug report into separate bug reports: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104896 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104897 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104898 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104899 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104902 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104903 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104904 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104905 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104906 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104907
[Bug c++/104907] New: unclear diagnostic for fatal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104907 Bug ID: 104907 Summary: unclear diagnostic for fatal error Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: egallager at gcc dot gnu.org Target Milestone: --- >From cp/module.cc: > returning to the gate for a mechanical issue This diagnostic is a fatal error. Fatal errors must be actionable. This diagnostic isn't actionable, instead it increases confusion for no reason. As a general rule, don't try to be funny if the GCC user is having a problem right now and is already mad at you.
[Bug c++/104906] New: UTF-8 bytes output in diagnostic regardless of locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104906 Bug ID: 104906 Summary: UTF-8 bytes output in diagnostic regardless of locale Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: egallager at gcc dot gnu.org Target Milestone: --- >From cp/module.cc: inform (loc, "compiler is %sversion %s%s%s", IS_EXPERIMENTAL (my_ver) ? "experimental " : "", my_string, reject_p ? "" : flag_module_version_ignore ? ", be it on your own head!" : ", close enough?", reject_p ? "" : " \xc2\xaf\\_(\xe3\x83\x84)_/\xc2\xaf"); Are you sure that you want to output this UTF-8 sequence in locale "C"? Furthermore, the conditional strings must be translatable. See the GCC diagnostics guidelines for more information. What would happen if this diagnostic were printed in an EBCDIC environment? Might the UTF-8 sequence "\xe3\x83\x84" show up as "Tcd" there?
[Bug c++/104905] New: untranslated word in diagnostic about compiled module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104905 Bug ID: 104905 Summary: untranslated word in diagnostic about compiled module Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: egallager at gcc dot gnu.org Target Milestone: --- >From cp/module.cc: > error_at (loc, "compiled module is %sversion %s", > IS_EXPERIMENTAL (their_ver) ? "experimental " : "", > their_string); The word "experimental" must be translatable into other languages such as German, French, Russian; currently it isn't. Fixing this properly requires to split this message into 2 separate messages since the word "experimental" alone is too ambiguous to translate without further context.
[Bug target/104904] New: misplaced quotes in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104904 Bug ID: 104904 Summary: misplaced quotes in diagnostic Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: egallager at gcc dot gnu.org, msebor at gcc dot gnu.org Target Milestone: --- Target: v850 >From v850-c.cc: > %<#pragma%> GHS end found without previous startXXX > %<#pragma%> GHS endXXX does not match previous startXXX > junk at end of %<#pragma%> ghs section > malformed %<#pragma%> ghs section > and so on Should be %<#pragma GHS endXXX%> (only 3 X, not 4 X), as well as %. Looks like a fallout from enclosing keywords in quotes, missed in the manual review.
[Bug target/104903] New: missing quotes in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104903 Bug ID: 104903 Summary: missing quotes in diagnostic Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: egallager at gcc dot gnu.org Target Milestone: --- Target: rs6000 >From rs6000-c.cc: > passing argument %d of %qE discards const qualifier from pointer target type The word "const" should be in % quotes.
[Bug target/104902] New: missing %q in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104902 Bug ID: 104902 Summary: missing %q in diagnostic Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: egallager at gcc dot gnu.org Target Milestone: --- Target: nvptx >From nvptx.cc: > PTX version (-mptx) needs to be at least %s to support selected -misa (sm_%s) Missing %<...%> around -mptx and -misa.
[Bug c/104899] New: typo "cannott"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104899 Bug ID: 104899 Summary: typo "cannott" Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: egallager at gcc dot gnu.org Target Milestone: --- in bfin.cc and range-op.cc This typo doesn't appear in any tests so it should be trivial to fix.
[Bug target/104898] New: missing %q in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104898 Bug ID: 104898 Summary: missing %q in diagnostic Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: egallager at gcc dot gnu.org, sje at gcc dot gnu.org Target Milestone: --- Target: aarch64 >From aarch64.cc: > invalid feature modifier %s The %s should be %qs, like in the related messages. The parentheses in "(%qs)" look redundant. They are only used 18 times in total, in the whole tree. For comparison, "%qs" is used more than 2700 times in the whole tree. I would remove the parentheses.
[Bug target/104897] New: wrong plural form in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104897 Bug ID: 104897 Summary: wrong plural form in diagnostic Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: egallager at gcc dot gnu.org, rsandifo at gcc dot gnu.org Target Milestone: --- Target: aarch64 >From aarch64-sve-builtins.cc: > error_at (location, "passing single vector %qT to argument %d" > " of %qE, which expects a tuple of %d vectors", > actual, argno + 1, fndecl, num_vectors); "%d vectors" must use the correct plural form, for the benefit of Polish, Russian, Arabic and several more. => Richard Sandiford's string (https://gcc.gnu.org/g:624d0f07) "%d vectors" appears twice in this file.
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 --- Comment #38 from Roland Illig --- (In reply to Roland Illig from comment #7) > From params.opt: > > --param=ranger-debug=[none|trace|gori|cache|tracegori|all] > > Specifies the output mode for debugging ranger. > > Why " " instead of the usual "\t" after the "]"? Everything is OK here, I wrongly thought that the usual separator in that file were a tab. The other similar entries use a space as well. @egallager you can remove Andrew MacLeod from the CC list.
[Bug c/104896] New: Messages use %<%s%> instead of the idiomatic %qs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104896 Bug ID: 104896 Summary: Messages use %<%s%> instead of the idiomatic %qs Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: egallager at gcc dot gnu.org, msebor at gcc dot gnu.org Target Milestone: --- As of 2022-03-12, the GCC tree contains 44 instances of the string "%<%s%>". Please have a look whether they can be replaced with the idiomatic %qs, and if not, document them.
[Bug target/104794] arm: use translation pattern for repetitive messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104794 --- Comment #11 from Roland Illig --- Thank you, looks good now.
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 --- Comment #37 from Roland Illig --- I'm splitting this bug report into multiple bug reports, to clean up the mess that the 36 comments created. It was a bad idea from the beginning. :)
[Bug fortran/104888] diagnostics use non-idiomatic '%s'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104888 --- Comment #5 from Roland Illig --- Related, in trans-openmp.cc: > "specified at %L " The space at the end is too much.
[Bug fortran/104888] diagnostics use non-idiomatic '%s'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104888 --- Comment #4 from Roland Illig --- While here: > requiries typo: should be requires
[Bug fortran/104888] diagnostics use non-idiomatic '%s'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104888 --- Comment #3 from Roland Illig --- While here: > DEPEND clause of depobj Should DEPOBJ be uppercase?
[Bug fortran/104888] diagnostics use non-idiomatic '%s'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104888 --- Comment #2 from Roland Illig --- While here: > "'omp_allocator_handle_kind' kind at %L" Should this be uppercase instead?
[Bug fortran/104888] diagnostics use non-idiomatic '%s'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104888 --- Comment #1 from Roland Illig --- While here: > expected : at %C The quotes around the %<:%> are missing.
[Bug fortran/104888] New: diagnostics use non-idiomatic '%s'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104888 Bug ID: 104888 Summary: diagnostics use non-idiomatic '%s' Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- fortran/openmp.cc says: > selector '%s' not allowed for context selector set '%s' at %C One year ago, the message contained the idiomatic %qs. Why was it changed in ae3c4e521dd0b66db712639298cd08331d62f315?
[Bug d/104878] New: untranslated string in diagnostic "%s %qs instantiated"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104878 Bug ID: 104878 Summary: untranslated string in diagnostic "%s %qs instantiated" Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: roland.illig at gmx dot de Target Milestone: --- d/decl.cc says: > warning (OPT_Wtemplates, "%s %qs instantiated", > ti->kind (), ti->toPrettyChars (false)); In the German translation, using the untranslated ti->kind() leads to English (or D-specific) text in an otherwise German diagnostic. For the benefit of translators, please add a /* TRANSLATORS: ... */ comment above to list some example values for ti->kind(). Depending on the possible values and the user's selected natural language, it may even be possible that this diagnostic cannot be properly translated, due to grammatic cases.
[Bug c++/104877] New: missing standard gnu++20 in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104877 Bug ID: 104877 Summary: missing standard gnu++20 in diagnostic Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- cp/parser.cc says: > use of % in parameter declaration only available with %<-std=c++20%> > or %<-fconcepts%> What about %<-std=gnu++20%>?
[Bug c++/104876] New: untranslated strings in diagnostic about failed mapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104876
Bug ID: 104876
Summary: untranslated strings in diagnostic about failed mapper
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
cp/mapper-client.cc says:
---snip---
...
errmsg = "opening";
...
errmsg = "reading";
...
if (errmsg)
error_at (loc, line ? G_("failed %s mapper %qs line %u")
: G_("failed %s mapper %qs"), errmsg, name.c_str (), line);
---snap---
This means that the German translation includes English words, and as the
German translator, I cannot do anything about it.
To fix this, I suggest to define a local enum for the error causes and then for
each non-zero error cause use a proper complete sentence as the message.
enum cause {
OERR_NONE,
OERR_OPENING,
OERR_READING
};
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 --- Comment #35 from Roland Illig --- (In reply to rsand...@gcc.gnu.org from comment #33) > (In reply to Eric Gallager from comment #28) > > (In reply to Roland Illig from comment #11) > > > From aarch64-sve-builtins.cc: > > > > passing %qT to argument %d of %qE, which expects a scalar integer > > > > > > "scalar integer" sounds redundant, this may be a copy-and-paste mistake > > > from > > > the message directly above, which says "scalar element". > > > > Likewise. > I think it's worth keeping, at least in English. The error could > otherwise end up being something like: > > passing “svint32_t” to argument 2 of foo, which expects an integer > > which IMO isn't as obvious: the crucial scalar vs. vector distinction > is now implicit rather than explicit. Good point, makes perfect sense. I didn't think of vector types, that's why I thought the "scalar" could have been redundant. Thank you for the example.
[Bug c++/104808] unclear diagnostic "MAP %qD TO %qT"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104808 --- Comment #2 from Roland Illig --- (In reply to Andrew Pinski from comment #1) > these are in debug_* functions so they don't need to be translated as they > are not user visible at all. > That is they are only used while debugging GCC. If they do not need to be translated, why are they marked for translation then? If they weren't in gcc.pot, I wouldn't have complained.
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 --- Comment #26 from Roland Illig --- >From cp/module.cc: > returning to the gate for a mechanical issue This diagnostic is a fatal error. Fatal errors must be actionable. This diagnostic isn't actionable, instead it increases confusion for no reason. As a general rule, don't try to be funny if the GCC user is having a problem right now and is already mad at you.
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 --- Comment #25 from Roland Illig --- >From cp/module.cc: inform (loc, "compiler is %sversion %s%s%s", IS_EXPERIMENTAL (my_ver) ? "experimental " : "", my_string, reject_p ? "" : flag_module_version_ignore ? ", be it on your own head!" : ", close enough?", reject_p ? "" : " \xc2\xaf\\_(\xe3\x83\x84)_/\xc2\xaf"); Are you sure that you want to output this UTF-8 sequence in locale "C"? Furthermore, the conditional strings must be translatable. See the GCC diagnostics guidelines for more information.
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 --- Comment #24 from Roland Illig --- >From cp/module.cc: > error_at (loc, "compiled module is %sversion %s", > IS_EXPERIMENTAL (their_ver) ? "experimental " : "", > their_string); The word "experimental" must be translatable into other languages such as German, French, Russian, currently it isn't. Fixing this properly requires to split this message into 2 separate messages since the word "experimental" alone is too ambiguous to translate without further context.
[Bug c++/104810] New: Wrong order of "note: ... this enumerator %qD"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104810
Bug ID: 104810
Summary: Wrong order of "note: ... this enumerator %qD"
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic, testsuite-fail
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
>From cp/module.cc:
> inform (DECL_SOURCE_LOCATION (new_decl),
> "... this enumerator %qD", new_decl);
> inform (DECL_SOURCE_LOCATION (known_decl),
> "enumerator %qD does not match ...", known_decl);
In the source code, these two calls should be swapped, to allow reading the
source code from top to bottom.
The diagnostics in enum-bad-1_b.C are extremely hard to read in their current
form, I had to manually wrap the lines in order to see the order of the
messages. No wonder nobody noticed that the grammar of the diagnostics didn't
make sense.
There must be a way for large dg-regexp annotations to be split into multiple
lines. To understand the diagnostics, I reformatted it to:
> // { dg-regexp {
> // In module [^\n]*enum-bad-1_a.H, imported at [^\n]*enum-bad-1_b.C:8:\n
> // [^\n]*enum-bad-1_a.H:5:6: error: definition of 'enum ONE' does not match\n
> // [^\n]*enum-bad-1_b.C:3:6: note: existing definition 'enum ONE'\n
> // In module [^\n]*enum-bad-1_a.H, imported at [^\n]*enum-bad-1_b.C:8:\n
> // [^\n]*enum-bad-1_a.H:5:11: note: ... this enumerator 'A'\n
> // [^\n]*enum-bad-1_b.C:3:11: note: enumerator 'Q' does not match ...\n
> // [^\n]*enum-bad-1_b.C:15:1: note: during load of binding '::ONE'\n
> // }
> // }
This clearly shows that the two "..." do not match.
Marked as "testsuite-fail" since it is a classical fail of the testsuite to not
provide enough stylistic freedom to make the source code of the tests readable
without manual editing.
[Bug c++/104809] New: Explain ELRoND to translators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104809 Bug ID: 104809 Summary: Explain ELRoND to translators Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- >From cp/module.cc: > not Encapsulated Lazy Records of Named Declarations Is this message trying to be funny? As the German translator, I got the abbreviation, but according to a Google search the GCC source code is the only place where it is used. I don't think that elves and dwarfs only live in Middle Earth, and that the diagnostic thus discriminates elves living in other parts of the world of the universe, whichever is more inclusive. Please add a /* TRANSLATORS */ comment above this message, detailing how close to the words I should translate this message or whether a simple "There are no elfs in this forest" is enough. No, I don't have humor. This is GCC, not an RPG, so I strongly prefer clear, actionable diagnostics.
[Bug c++/104808] New: unclear diagnostic "MAP %qD TO %qT"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104808
Bug ID: 104808
Summary: unclear diagnostic "MAP %qD TO %qT"
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
cp/constraint.cc says:
> if (TYPE_P (parm))
> verbatim ("MAP %qD TO %qT", TEMPLATE_TYPE_DECL (parm), arg);
> else
> verbatim ("MAP %qD TO %qE", TEMPLATE_PARM_DECL (parm), arg);
As the German translator, what am I supposed to translate here?
If "MAP" and "TO" are keywords, there is nothing to translate, in which case
the string should not be marked for translation at all.
If "MAP" and "TO" are part of an English sentence (as the GCC conventions for
diagnostics recommend), I don't understand why they are in uppercase. That
wouldn't make sense in locale "C" either.
Please put a /* TRANSLATORS: explanation */ comment above these two messages,
or at least the upper one.
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 --- Comment #23 from Roland Illig --- >From c-parser.cc and cp/parser.cc: > %<#pragma omp target%> with modifier other than % or %on > % clause Missing space between "%" and "on".
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 --- Comment #22 from Roland Illig --- >From v850-c.cc: > %<#pragma%> GHS end found without previous startXXX > %<#pragma%> GHS endXXX does not match previous startXXX > junk at end of %<#pragma%> ghs section > malformed %<#pragma%> ghs section > and so on Should be %<#pragma GHS endXXX%> (only 3 X, not 4 X), as well as %. Looks like a fallout from enclosing keywords in quotes, missed in the manual review.
[Bug translation/90148] Closing quote in wrong position in plugin.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90148 --- Comment #7 from Roland Illig --- Still reproducible in GCC 12. Any chance of these trivial things getting fixed in the next year?
[Bug target/99297] wrong diagnostic style in rx.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99297 Roland Illig changed: What|Removed |Added Version|11.0|12.0 --- Comment #1 from Roland Illig --- Still reproducible in GCC 12. Is it difficult to fix this?
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 --- Comment #21 from Roland Illig --- >From rs6000-c.cc: > passing argument %d of %qE discards const qualifier from pointer target type The word "const" must be in % quotes.
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 --- Comment #20 from Roland Illig --- >From pru.cc: > register name %<%s%> Please use the canonical %qs instead of the unnecessarily verbose %<%s%>. Everywhere.
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 --- Comment #19 from Roland Illig --- >From nvptx.cc: > PTX version (-mptx) needs to be at least %s to support selected -misa (sm_%s) Missing %<...%> around -mptx and -misa.
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 --- Comment #11 from Roland Illig --- Is there a general plan of fixing these "trivial" nits? Half of my reports from 2019 are still open after 3 years.
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 --- Comment #18 from Roland Illig --- >From nds32.cc: > this built-in function not support on the v3m toolchain "support" should be "supported".
[Bug target/104797] New: too many parentheses in diagnostic for __delay_cycles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104797
Bug ID: 104797
Summary: too many parentheses in diagnostic for __delay_cycles
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
Target: msp430
>From msp430.cc:
> error ("%<__delay_cycles()%> only takes constant arguments");
> error ("%<__delay_cycles%> only takes non-negative cycle counts");
The parentheses in the first message above have recently been added. They are
wrong. It's the function that takes arguments, not the function call. For
consistency the parentheses should be removed again from the diagnostic.
[Bug target/104796] New: ABI change is not mentioned in HTML changelog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104796
Bug ID: 104796
Summary: ABI change is not mentioned in HTML changelog
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
>From i386.c:
const char *url
= CHANGES_ROOT_URL "gcc-12/changes.html#zero_width_bitfields";
inform (input_location,
"the ABI of passing C structures with zero-width bit-fields"
" has changed in GCC %{12.1%}", url);
As of 2022-03-04, https://gcc.gnu.org/gcc-12/changes.html doesn't contain the
anchor "zero_width_bitfields".
[Bug target/104795] New: inconsistent wording in diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104795
Bug ID: 104795
Summary: inconsistent wording in diagnostics
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
>From i386.c:
> %<-m96bit-long-double%> is not compatible with this target
> %<-mpreferred-stack-boundary%> is not supported for this target
Is there a semantic difference in the above messages? If not, please use the
same words for them. For the benefit of translators, please use the following
pattern, so that I as a translator don't have a chance of introducing
copy-and-paste mistakes:
error ("%qs is not supported for this target", "-m96bit-long-double");
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 --- Comment #17 from Roland Illig --- >From bfin.cc: > cannott Should be "cannot".
[Bug target/104794] arm: use translation pattern for repetitive messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104794 --- Comment #5 from Roland Illig --- Same for %'-mstack-protector-guard=tls%' in the same file.
[Bug target/104794] arm: use translation pattern for repetitive messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104794 --- Comment #4 from Roland Illig --- And another thing: > %'-mstack-protector-guard-offset=%qs%' This produces nested quotes. The %qs should rather be a simple %s. Maybe you can write a unit test to see how the end result looks. I didn't find any such test in the test suite, just some tests that specify a valid value for the option.
[Bug target/104794] arm: use translation pattern for repetitive messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104794
--- Comment #3 from Roland Illig ---
While here:
> error ("incompatible options %'-mstack-protector-guard=global%' and"
>"%'-mstack-protector-guard-offset=%qs%'",
The idiomatic way to write quotes is %<...%>, not %'...%'.
