https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93828
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #11 from John Paul Adrian Glaubitz ---
Created attachment 47878
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47878&action=edit
Source and compiler output for string.c with stack-protector disabled
(In reply to Oleg Endo from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93832
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93834
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93833
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93835
Richard Biener changed:
What|Removed |Added
Target Milestone|10.0|9.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Summary|wrong code at -O3 o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93842
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid, diagnostic
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93838
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93842
--- Comment #2 from Martin Liška ---
Confirmed that clang really rejects the code:
$ clang pr93842.cc -Wunused -std=c++14 -c
pr93842.cc:4:20: error: variable 'ch' cannot be implicitly captured in a lambda
with no capture-default specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93841
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93837
Martin Liška changed:
What|Removed |Added
Keywords||easyhack
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93831
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93830
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93844
--- Comment #1 from Richard Biener ---
Guess it's the same bug as with C99 or C++ where you can write
const char *st = "Shall we?";
int main()
{
printf ("%s\n", st);
printf ("%s\n", "Before assignment");
const char *st = "Hello, world!";
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93845
Bug ID: 93845
Summary: [10 regression] ICE in verify_sra_access_forest, at
tree-sra.c:2358
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93835
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93834
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93833
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93832
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93845
--- Comment #1 from Dmitry G. Dyachenko ---
'-Wall -Wextra -O3' free variant
$ cat x.ii
struct g;
struct h {
g *operator->();
};
class i {
void *a;
int b;
public:
template f j() { return *static_cast(this); }
};
struct k : i {};
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #31 from Richard Biener ---
(In reply to Jakub Jelinek from comment #29)
> Passed bootstrap/regtest on all of {x86_64,i686,powerpc64{,le}}-linux now,
> with powerpc64-linux doing both -m32/-m64 testing.
LGTM.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #12 from John Paul Adrian Glaubitz ---
Building with -O1 fixes the problem for me. Now I need to compare the flags for
-O1 and -O2 and check which one breaks the build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93845
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93831
--- Comment #2 from Iain Sandoe ---
you're welcome, of course - if not, hopefully I can get to this and the other
translation comments over the weekend (been out of the office at WG21, and
catching up)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93443
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93443
--- Comment #2 from Iain Sandoe ---
AFAICS, this should be fixed now, yes?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 93443, which changed state.
Bug 93443 Summary: gcc/cp/coroutines.cc:3555:23: runtime error: load of value
255, which is not a valid value for type 'bool'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93443
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93842
--- Comment #3 from kuzniar95 at o2 dot pl ---
@Richard Biener changing it to
char const ch = '='; // NOT OK
doesn't solve the issue. Interestingly dropping constness:
char ch = '='; // OK
works.
So we are onto something - both const and cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #28 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93844
--- Comment #2 from Tom de Vries ---
(In reply to Richard Biener from comment #1)
> Guess it's the same bug as with C99 or C++ where you can write
>
> const char *st = "Shall we?";
> int main()
> {
> printf ("%s\n", st);
> printf ("%s\n", "B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93844
--- Comment #3 from Tom de Vries ---
(In reply to Richard Biener from comment #1)
> and there's a duplicate PR about this.
I found: PR92386 - "gdb issue with variable-shadowing" which sound similar.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93844
--- Comment #4 from Tom de Vries ---
(In reply to Richard Biener from comment #1)
> The only way to capture these may
> be to introduce additional scoping in the FEs whenever new local decls
> are added. Also consider
>
> const char *oldst =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93841
--- Comment #2 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:4a172be3e5e849ef82f07ce034837630e73f025b
commit r10-6755-g4a172be3e5e849ef82f07ce034837630e73f025b
Author: Martin Liska
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93830
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93831
--- Comment #3 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:093bdf2cec611947fb69d8ced21a2d875166cba0
commit r10-6753-g093bdf2cec611947fb69d8ced21a2d875166cba0
Author: Martin Liska
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93838
--- Comment #2 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:6c39d0b79db7f9bf58a64bf987c161ae0b9dcec4
commit r10-6754-g6c39d0b79db7f9bf58a64bf987c161ae0b9dcec4
Author: Martin Liska
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93830
--- Comment #2 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:f40237a37b28a4c9143bfcbf5886fc9a6d3b5cfe
commit r10-6752-gf40237a37b28a4c9143bfcbf5886fc9a6d3b5cfe
Author: Martin Liska
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93831
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93841
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93838
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93656
--- Comment #2 from CVS Commits ---
The releases/gcc-9 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:f55bf4ddbfac3c7360cb00f3200b663c19baf504
commit r9-8259-gf55bf4ddbfac3c7360cb00f3200b663c19baf504
Author: H.J. Lu
Date: Thu Feb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93656
--- Comment #3 from CVS Commits ---
The releases/gcc-8 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:b4edc88453b61d6f3bdb9143cd0486536f95598d
commit r8-10040-gb4edc88453b61d6f3bdb9143cd0486536f95598d
Author: H.J. Lu
Date: Thu Fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93656
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
Bug 81652 depends on bug 93656, which changed state.
Bug 93656 Summary: FAIL: gcc.target/i386/pr67770.c execution test with
-fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93656
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93846
Bug ID: 93846
Summary: libsanitizer compilation error with glibc 2.31
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93709
--- Comment #3 from Jiu Fu Guo ---
This issue may relates to cunroll and cunrollli; after cunroll, for power9 some
special instructions were selected.
In RTL, for power9, 'smax' is generated at ce1 pass;
While for power8, 'smax' is not used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92154
Martin Liška changed:
What|Removed |Added
CC||rezso at rezso dot net
--- Comment #11 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93846
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93709
--- Comment #4 from Jiu Fu Guo ---
This issue can be reproduced with GCC9 "-O2 -funroll-loops -mcpu=power9" or
"-O3 -mcpu=power9".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93844
--- Comment #5 from Richard Biener ---
(In reply to Tom de Vries from comment #4)
> (In reply to Richard Biener from comment #1)
> > The only way to capture these may
> > be to introduce additional scoping in the FEs whenever new local decls
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #191 from dave.anglin at bell dot net ---
On 2020-02-19 9:50 p.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #190 from Peter Bisroev ---
> (In reply to dave.anglin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93826
--- Comment #1 from Tobias Burnus ---
The C code rejects this as follows.
The OpenACC specification talks about "tightly nested loops"; the OpenMP spec
is less clear but for "collapse" contrary to "tile" the implication that
tightly nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #13 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #12)
> Building with -O1 fixes the problem for me. Now I need to compare the flags
> for -O1 and -O2 and check which one breaks the build.
It'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922
Richard Biener changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847
Bug ID: 93847
Summary: Nios II ICE
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93847
--- Comment #1 from Giulio Benetti ---
Here is another test-case:
http://autobuild.buildroot.net/results/e22/e225e62ea2d48660df4110790664f0c3306c1ea9/
Here gcc is built from scratch instead of using Codesourcery one, so it should
be easy for you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #14 from Oleg Endo ---
Created attachment 47879
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47879&action=edit
reduced case
I've reduced the preprocessed file string.c down to the problematic function
'coderange_scan'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #16 from Oleg Endo ---
This seems to be actually valid code?!
switch (e - p)
{
default: __builtin_unreachable();
case 3: if (e[-3]&0x80) return e-3;
case 2: if (e[-2]&0x80) return e-2;
case 1: if (e[-1]&0x80) retu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
Bug ID: 93848
Summary: missing -Warray-bounds warning for array subscript 1
is outside array bounds
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68531
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2016-07-11 00:00:00 |2020-2-20
Summary|incorrect co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90248
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93849
Bug ID: 93849
Summary: 'Segmentation fault' in the special index for an array
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658
--- Comment #11 from CVS Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:b82d426662469ee8b78ec7e8f74abe950485c9d5
commit r10-6760-gb82d426662469ee8b78ec7e8f74abe950485c9d5
Author: Peter Bergner
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93850
Bug ID: 93850
Summary: 'stack smashing detected' in the special index for an
array
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93825
--- Comment #2 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:2c52b2884ba10b1c5050fe066bae651680c8ebae
commit r10-6761-g2c52b2884ba10b1c5050fe066bae651680c8ebae
Author: Tobias Burnus
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658
--- Comment #12 from CVS Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:e6f24f824beb8ba6805702e287bbd6153b472488
commit r10-6762-ge6f24f824beb8ba6805702e287bbd6153b472488
Author: Peter Bergner
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93850
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93850
--- Comment #2 from Andreas Schwab ---
*** Bug 93849 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93849
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93851
Bug ID: 93851
Summary: FAIL: 20_util/integer_comparisons/equal.cc execution
test
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70020
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93852
Bug ID: 93852
Summary: typo: def instead of definition
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
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".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93852
--- Comment #2 from Andrew Pinski ---
These are all diagonstic which normally don't go for normal compilation
including when user has provided invalid code. These are all have an internal
error message after them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93853
Bug ID: 93853
Summary: typo: writing one too many bytes
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93854
Bug ID: 93854
Summary: typo: defined here %qD
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93851
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93853
--- Comment #1 from Andrew Pinski ---
No this is correct english.
It means one or more extra bytes were written.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93853
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93855
Bug ID: 93855
Summary: typo: function argument vs. parameter
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93832
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
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\\)'
>
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 #3 from Andrew Pinski ---
(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. Currently, one file
> uses /* block comments */ wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93856
Bug ID: 93856
Summary: missing test for diagnostic: attribute %qs invalid
positional argument
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #17 from Andrew Pinski ---
In the original code we have:
if ((uintptr_t)p % 4) {
int l = 4 - (uintptr_t)p % 4;
p += l;
switch (l) {
l range should be 0...3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93857
Bug ID: 93857
Summary: missing test for diagnostic: using integer constants
in boolean context
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93828
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
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 -Wex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93828
--- Comment #3 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:f6088573d81d52e8573b704984fdb515e4391b1a
commit r10-6765-gf6088573d81d52e8573b704984fdb515e4391b1a
Author: Uros Bizjak
Date: Thu Fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93828
--- Comment #4 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:d56779b8ae587c599bf46b20587afcd6ee51fcaa
commit r10-6766-gd56779b8ae587c599bf46b20587afcd6ee51fcaa
Author: Uros Bizjak
Date: Thu Fe
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. C
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 thei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93858
Bug ID: 93858
Summary: missing question mark in diagnostic: unknown option
after #pragma GCC diagnostic
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93859
Bug ID: 93859
Summary: missing test for diagnostic: the omitted middle
operand will always be true
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: norm
1 - 100 of 141 matches
Mail list logo
