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
: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
CC: marxin at gcc dot gnu.org
Target Milestone: ---
3 times
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'.
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.
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' co
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
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
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 NetBS
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
Roland Illig changed:
What|Removed |Added
Attachment #55598|0 |1
is obsolete|
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
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://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
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
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
: 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
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
: 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=e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113324
Roland Illig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
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)
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 uncond
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114364
--- Comment #3 from Roland Illig ---
The diff looks good to me. Untested.
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.
>
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.
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 "
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
--- Comment #13 from Roland Illig ---
See also bug 114407.
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".
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
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
501 - 531 of 531 matches
Mail list logo
