: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
This is a popular typo that occurs 13 times in the GCC tree. Most of them are
in comments, but one is in intrinsic.texi.
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From darwin-driver.c:
> warning (0, "%qs is not valid for %",
There should be a hyphen in front of the command line option.
For compariso
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From darwin-c.c:
> error ("too many %<#pragma options%> align=reset");
The align=reset should be inside the qu
: 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:
> warning_at (location, OPT_Wparentheses,
> "the omitted middle operand in %
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From c-pragma.c:
> warning_at (loc, OPT_Wpragmas,
> "unknown option after %<#pragma GCC dia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93853
--- Comment #3 from Roland Illig ---
Thanks for the explanation.
Since there are many users of GCC who are not native English speakers, it might
make sense to avoid such complicated grammar. The GCC users should rather
concentrate on fixing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93855
--- Comment #4 from Roland Illig ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Roland Illig from comment #2)
> > While here, the comment style should be made the same in
> > attr-access-read-write.c and attr-access-read-only.c.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93857
--- Comment #1 from Roland Illig ---
I wrote a small example program, which I thought would trigger the diagnostic,
but it didn't do that in GCC 9.2.1.
int main(void) {
if (3 ? 4 : 5) {
return 1;
}
return 0;
}
gcc -Wall
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From c-common.c:
> warning_at (EXPR_LOCATION (expr), OPT_Wint_in_bool_context,
> "% using integer constants
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From c-attribs.c:
> error ("attribute %qs invalid positional argument", attrstr);
This diagnostic is not covered by t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93855
--- Comment #2 from Roland Illig ---
While here, the comment style should be made the same in
attr-access-read-write.c and attr-access-read-only.c. Currently, one file uses
/* block comments */ while the other uses // line-end comments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93855
--- Comment #1 from Roland Illig ---
In addition, I had expected that the %i placeholder were 1-based. From
attr-access-read-only.c:
> int RDONLY (4)
> rdonly_i_i_i_4 (int, int, int);
>// { dg-error "attribute 'access\\(read_only, 4\\)'
>
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From c-attribs.c:
> error ("attribute %qs positional argument %i value %wi exceeds "
>"number of function arguments %u",
The correct t
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From tree-vrp.c:
> inform (DECL_SOURCE_LOCATION (rec), "defined here %qD", rec);
This should probably be "%qD was defined here".
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From tree-ssa-strlen.c:
> writing one too many bytes
The words "one bytes" don't match.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93852
--- Comment #1 from Roland Illig ---
> error ("virtual def operand missing for statement");
Curiously, the diagnostic a few lines above this one uses the correct word
"definition".
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From tree-cfg.c:
> error ("missing % def");
The GCC diagnostics guidelines recomment to use actual words instead of
internal abbreviations.
: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
Duplicate word. Once in or1k.opt, once in invoke.texi.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93840
Roland Illig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93836
--- Comment #2 from Roland Illig ---
Thanks for the explanation. I think it might make sense to have a static
analysis tool for cases like this, to prevent this mistake from the beginning,
or at least be notified quickly, before the translators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93839
Roland Illig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
When GCC installs the translation files, it should install them in the same
place where it later looks them up. In the following
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From fortran/array.c:
> gfc_error ("rank + corank of %qs exceeds %d at %C", sym->name,
The other diagnostics in that file start with an uppercase letter.
: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From cp/parser.c:
> pedwarn (token->location, 0, "C++20 concept definition syntax "
> "is % = %> ");
Isn't there a linter in contrib/ for cases like these?
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
> else if (fndecl_built_in_p (variant)
> && (strncmp (IDENTIFIER_POINTER (DECL_NAME (variant)),
> &qu
: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From pru-pragma.c:
> error ("% index %" HOST_WIDE_INT_PRINT "d"
>" is not valid", i);
This code ends up in gcc.pot as:
: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From darwin.c:
> "%<-mpic-symbol-stubs%> is not required for 64b code (ignored)");
The 64b probably means 64-bit, therefore it sh
: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From avr-common.c:
> "configured %<--with-double={|32|32,64|64,32}%>");
The "{|" looks wrong. In the 64-bit case a few lines above, there is no leading
"|" inside the braces.
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From c-family/c-format.c:
> "unquoted sequence of %i consecutive "
> "punctuation characters %q.*s in format",
> nchars, nchars, for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93797
--- Comment #1 from Roland Illig ---
Another typo: an extra space at the end
>"speculative call sequence ");
Another variable/diagnostic mismatch:
> error ("number of speculative targets %i mismatched with "
>
: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
CC: marxin at gcc dot gnu.org
Target Milestone: ---
In cgraph.c. The corresponding code has speculative_id, without the u.
: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
3 times:
params.opt
ipa-visibility.c
gcc/tree.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93759
--- Comment #2 from Roland Illig ---
(In reply to Andreas Schwab from comment #1)
> Apparently the problem is that "% p" looks like a valid c-format.
Then there's a bug in either gettext or the GCC definitions of where c-format
strings may
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
CC: marxin at gcc dot gnu.org
Target Milestone: ---
From ipa-devirt.c:
> G_("one type needs to be constructed while other not"));
"while other not" is not correct English.
: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From params.opt:
> Set the estimated probability in percentage for builtin expect. The default
> value is 90% probability.
This message is marked as c-format, which is wrong. If it were c-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93747
Roland Illig changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93749
--- Comment #3 from Roland Illig ---
Even though the GCC warnings are suppressed, these strings still show up in the
translatable strings. In the German translation I'm just copying them 1:1,
since that makes sense to me.
I still don't
: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
Found in:
- gcc/config/rx/elf.opt
- libphobos/src/std/algorithm/iteration.d
: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From rs6000.c:
> error ("%qs requires VSX support", "%<-mfloat128%>");
The parameter does not need the % since it is already wrapp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93749
--- Comment #1 from Roland Illig ---
Typo nearby: "not an transparent_alias" should be "not a" instead of "not an"
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From symtab.c:
> error ("node is symver but not alias");
The word "symver" should either be enclosed in % or be spelled out.
The whole diagnosti
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From regcprop.c:
> internal_error ("%qs: [%u] bad % for empty chain (%u)",
__func__, i, vd->e[i].next_regno);
The __func__ is us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93747
--- Comment #1 from Roland Illig ---
Should be:
"ambiguous attribute %qs; could be %qs (via %<%s:%s%>) or %qs (via %<%s:%s%>)"
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From read-rtl.c:
> error_at (loc, "ambiguous attribute '%s'; could be"
> " '%s' (via '%s:%s'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90148
--- Comment #6 from Roland Illig ---
ping? It's one year later, I'm translating GCC 10 right now, and the issues are
still there. :(
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From plugin.c:
> fatal_error (input_location,
> "plugin %s is not licensed under a GPL-compatible license"
> " %s"
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
In cp/parser.c, function cp_parser_required_error, there are more than 20
messages that are essentially the same.
case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93694
--- Comment #3 from Roland Illig ---
> (Obsolete, ld_classic only) -sectcreate segname sectname file
segname, sectname and file should be marked as .
> -segprot max_prot init_prot\tThe protection values are
This like only describes the syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93694
--- Comment #2 from Roland Illig ---
double space:
> dyld will
missing word:
> two-level information
should probably be "two-level namespace information"
> Provided
> (Obsolete after 10.3.9) Set
Shouldn't there be a tab between the words
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93694
--- Comment #1 from Roland Illig ---
double space:
> architecture \"name\"
unnecessarily verbose:
> Specify that the output file should be generated for architecture "name"
Why not simply: Generate output file for the named architecture.
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From darwin.opt:
> Loads all members of archive libraries
> The version of ld64 in use for this toolchain.
> Produce an output file that will bind symbols on load, rather th
Assignee: dmalcolm at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From analyzer.opts:
> fdump-analyzer-callgraph
> Common RejectNegative Var(flag_dump_analyzer_callgraph)
> Dump the analyzer supergraph to a SRCFILE.callgraph.dot file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93657
--- Comment #3 from Roland Illig ---
(In reply to David Malcolm from comment #2)
> Dump various analyzer internals to stderr.
I like these. They are simple and to the point, and I cannot find any ambiguity
anymore. :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93659
--- Comment #5 from Roland Illig ---
Cool, thank you for the quick fix. That makes translating GCC more fun than in
the previous years. :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93659
--- Comment #1 from Roland Illig ---
And another typo, from the same file:
- Warn about code paths in which an initialized value is used.
+ Warn about code paths in which an uninitialized value is used.
Assignee: dmalcolm at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from analyzer.opt:
- call tha would
+ call that would
: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From analyzer.opt:
> Dump internal details about what the analyzer is doing to
> SRCFILE.analyzer.txt.
What is the analyzer doing to the SRCFILE? No harm, I hope.
(I do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93433
--- Comment #7 from Roland Illig ---
(In reply to Martin Liška from comment #6)
> (In reply to Roland Illig from comment #4)
> > Reported as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93433
> >
>
> Hello.
>
> You probably posted a wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93433
--- Comment #4 from Roland Illig ---
Reported as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93433
The description of the Bugzilla component called "sanitizer" should be
corrected. Currently it reads as if I should report any libsanitizer bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93433
--- Comment #2 from Roland Illig ---
But why is there a bug category called sanitizer then, which even mentions
libsanitizer?
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93219
--- Comment #5 from Roland Illig ---
(In reply to Jakub Jelinek from comment #4)
> Change return type from void to int.
Not quite. The return type is now bool, not int.
> Return true if not all characters have been written.
This feels wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93219
--- Comment #1 from Roland Illig ---
In similar bulk builds on NetBSD 8, NetBSD 9, Darwin 10.15, the code either
compiled fine or must have been skipped.
Current pkgsrc bulk build results for various platforms are available from
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
CC: jakub at gcc dot gnu.org
Target Milestone: ---
From a pkgsrc bulk build on RedHat EL 6 on x86_64:
../../../gcc-9.2.0/libgomp/affinity-fmt.c: In function 'gomp_print_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64271
Roland Illig changed:
What|Removed |Added
CC||roland.illig at gmx dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90142
--- Comment #2 from Roland Illig ---
Please just ignore the patch, if that's easier.
Portable shell programs should not use the == operator for test(1).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79632
--- Comment #2 from Roland Illig ---
(In reply to Eric Gallager from comment #1)
> What exactly is the harm of the redundancy? I don't think this is too big of
> an issue...
The harm of redundancy is that there is no single point of truth. When
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90152
--- Comment #3 from Roland Illig ---
(In reply to Martin Sebor from comment #2)
> Just so I'm clear: what exactly needs to be enclosed in _(...) in
> print_z_candidate?
The code:
print_z_candidate (loc, "candidate:", candidates);
should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79869
Roland Illig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Bug 40883 depends on bug 79869, which changed state.
Bug 79869 Summary: i18n: document placeholders for translators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79869
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90176
Roland Illig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
https://www.gnu.org/software/gcc/svnwrite.html says:
> If you already have an account on sourceware.org/gcc.gnu.org, ask
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90251
--- Comment #2 from Roland Illig ---
I posted an updated version of the linter to bug 79618, and I will post further
updates only there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90118
--- Comment #9 from Roland Illig ---
The particular issue has been fixed, the linter has been updated in bug 90176,
therefore I think this bug can be closed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618
--- Comment #7 from Roland Illig ---
Created attachment 46269
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46269=edit
linter for string literals
The attached linter detects:
* multiline string literals that have the space at the start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
--- Comment #10 from Roland Illig ---
(In reply to Richard Biener from comment #9)
> IMHO the error calls in our IL checkers are abusive, they could have been
> simple dumps to stderr for example. It was just "convenient" to use
> a disagnostic
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
cc1 --help produces:
printf (" Known valid arguments for %s option:\n ", option->opt_text);
There's a _(...) missing around the string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
--- Comment #7 from Roland Illig ---
(In reply to Richard Biener from comment #6)
> IMNSHO the IL checker "errors" should continue to use GCC terms since they
> check the GIMPLE intermediate language. They also shouldn't necessarily be
>
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
Created attachment 46246
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46246=edit
linter for string literals
From engtype.c:
printf ("\t -D | --debug "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90117
--- Comment #2 from Roland Illig ---
(In reply to Martin Liška from comment #1)
> Makes sense, I'll integrate that to our linter.
I've already integrated that into the linter, see the latest attachment in bug
90176.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90176
Roland Illig changed:
What|Removed |Added
Attachment #46234|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79183
--- Comment #9 from Roland Illig ---
Is there already someone who wants to fix the remaining messages?
Jakub, you fixed some of them already in
https://gcc.gnu.org/viewcvs?rev=258154=gcc=rev in March 2018.
There are still some messages that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119
--- Comment #7 from Roland Illig ---
I didn't want to sound that harsh in my previous comment.
What I wanted to say is: to make the linter reliable and be able to handle the
full syntax of .po files, it's better to use an exising library that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90176
Roland Illig changed:
What|Removed |Added
Attachment #46212|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119
--- Comment #6 from Roland Illig ---
(In reply to Martin Liška from comment #5)
> Thank you Roland for working on that. Can you please integrate your script
> with:
> contrib/check-internal-format-escaping.py
No, I cannot. Integrating it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90176
Roland Illig changed:
What|Removed |Added
Attachment #46206|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90163
--- Comment #3 from Roland Illig ---
(In reply to Daniel Santos from comment #2)
> Yes, this is mine. Does this only become untranslatable when feature is
> "static call chains"?
In German, this might result in:
%<-mcall-ms2sysv-xlogues%> ist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90183
--- Comment #2 from Roland Illig ---
The same diagnostic also appears for %<-std=c++-17%> and several others, and
these are in the past. Are the options from these standard only available in
that particular version of the standard? I don't guess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90184
--- Comment #2 from Roland Illig ---
(In reply to Jonathan Wakely from comment #1)
> But is it confusing in context when the diagnostic points to a piece of code
> saying [[using gnu: noinline]] ?
Yes, it is. I just had a look at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90148
--- Comment #5 from Roland Illig ---
From fortran/intrinsic.c:
gfc_warning_now (OPT_Wintrinsics_std, "The intrinsic %qs at %L is not "
"included in the selected standard but %s and %qs
will"
mponent: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From cp/parser.c:
parser->type_definition_forbidden_message
= G_("types may not be defined in iterator type");
The term "may not" is ambiguous.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90118
--- Comment #8 from Roland Illig ---
(In reply to Christophe Lyon from comment #7)
> Do you mean something like that?
>
> if p.startswith('-'):
> if len(p) >= 2 and (p[1].isalpha() and p != '-INF'):
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From cp/parser.c:
/* http://cplusplus.github.io/EWG/ewg-active.html#66 */
pedwarn (DECL_SOURCE_LOCATION (decl), OPT
mponent: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From cp/parser.c:
pedwarn (input_location, 0,
"attribute using prefix only available "
"with %<-std=c++17%> or %<-std=gnu++1
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
For example:
pedwarn (cp_lexer_peek_token (parser->lexer)->location,
OPT_Wpedantic, "nested inline namespace definitions only &quo
: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
Fixing this issue for good is being done in bug 79618. That is more complicated
than "trivial".
In this bug I collect the trivial occurrences that shoul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90164
--- Comment #2 from Roland Illig ---
(In reply to Martin Sebor from comment #1)
> Confirmed. There seems to be little consistency between "changes" and "has
> changed" -- it's 11 vs 6.
To me it looks completely consistent.
If something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90180
--- Comment #1 from Roland Illig ---
While here, the two diagnostics in s390_const_operand_ok are very similar. It
would be nice if the first of them had the same text as the second one, passing
the 0 as an argument.
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From s390.c:
error ("constant argument %d for builtin %qF is out of range "
"(0..%wu)", argnum, decl,
(HOST_WIDE_INT_1U <&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90148
--- Comment #4 from Roland Illig ---
From rx.c:
error ("use %<__builtin_rx_mvtc%> (0, ... ) to write arbitrary values to
PSW");
The closing quote should be after the closing parenthesis.
201 - 300 of 532 matches
Mail list logo
