https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89392
--- Comment #6 from rguenther at suse dot de ---
On Tue, 19 Feb 2019, ctice at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89392
>
> --- Comment #5 from ctice at gcc dot gnu.org ---
> I have been unable to reproduce th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091
--- Comment #3 from David Binderman ---
for gcc/testsuite/gcc.dg/pr89037.c, valgrind says:
./gcc.dg/pr89037.c:9:9: warning: missing braces around initializer
[-Wmissing-braces]
9 | T a[] = { 1, 1, 0x12345, 0xff01, 1ULL << 63, (__int1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091
--- Comment #4 from Arseny Solokha ---
(In reply to David Binderman from comment #3)
> for gcc/testsuite/gcc.dg/pr89037.c, valgrind says:
That's where I've minimized my testcase from.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #4 from Jonny Grant ---
There's another related issue, can it be covered on this ticket?
GCC does not show the part of the output below I marked with after commenting
out line 4 <-
#1 with x86-64 gcc (trunk)
: In function 'main'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89413
Bug ID: 89413
Summary: [8/9 Regression] ICE in resolve_fl_derived, at
fortran/resolve.c:14392
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-inv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89408
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412
Matthias Klose changed:
What|Removed |Added
Summary|[8 Regression] bootstrap|[8/9 Regression] gcc ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89413
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |7.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89406
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89404
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89403
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89402
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412
--- Comment #3 from Uroš Bizjak ---
Middle-end wants to create a subreg of BLKmode:
#3 0x00cd5899 in simplify_gen_subreg
(outermode=outermode@entry=E_DCmode, op=op@entry=0x7fffea778240,
innermode=E_BLKmode, byte=byte@entry=...)
at .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89347
--- Comment #3 from Maninder Singh ---
But its not mentioned in gc-section or data-section manual pages, either that
needs updation or it need to be handled by -fdata-section flag only.
https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Optimize-Opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89413
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87924
--- Comment #4 from Chung-Lin Tang ---
Author: cltang
Date: Wed Feb 20 10:09:53 2019
New Revision: 269036
URL: https://gcc.gnu.org/viewcvs?rev=269036&root=gcc&view=rev
Log:
Correction of ChangeLog entry, Thomas provided the code for this change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89365
--- Comment #3 from Bader at lrz dot de ---
I agree with Harald's assessment. The test case as delivered by me is indeed
incorrectly written for the POINTER and ALLOCATABLE cases, in both of which I
believe the bounds should be taken from the act
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262
--- Comment #20 from Egeyar Bagcioglu ---
This issue is fixed in gold for binutils 2.33:
https://sourceware.org/bugzilla/show_bug.cgi?id=23870
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89365
--- Comment #4 from Dominique d'Humieres ---
> I agree with Harald's assessment. The test case as delivered by me
> is indeed incorrectly written for the POINTER and ALLOCATABLE cases,
> in both of which I believe the bounds should be taken from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89365
--- Comment #5 from Bader at lrz dot de ---
The corrected test case passes all tests, so the PR can be closed. Sorry for
the noise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84536
--- Comment #3 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Wed Feb 20 10:47:02 2019
New Revision: 269037
URL: https://gcc.gnu.org/viewcvs?rev=269037&root=gcc&view=rev
Log:
/cp
2019-02-20 Paolo Carlini
PR c++/84536
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
--- Comment #6 from Martin Liška ---
(In reply to Bruce Korb from comment #5)
> (In reply to Martin Sebor from comment #4)
>
> > canonicalize_pathname.c: In function ‘canonicalize_pathname’:
> > canonicalize_pathname.c:61:2: warning: ‘strcpy’ ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
--- Comment #7 from Martin Liška ---
(In reply to Martin Sebor from comment #4)
> I've created a test case using the canonicalize_pathname function showing
> that it does, in fact, cause an overlap to take place. The following line
> in the outp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89414
Bug ID: 89414
Summary: wrong code with -Og -fno-forward-propagate
-fno-tree-fre
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89409
--- Comment #4 from H.J. Lu ---
A patch is posted at
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01645.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415
Bug ID: 89415
Summary: gcc.dg/sinatan-1.c FAILs
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415
--- Comment #2 from Christophe Lyon ---
I'm not sure it's worth opening another regression report, but that same commit
creates regressions in fortran on arm:
FAIL: gfortran.dg/integer_exponentiation_3.F90 -O0 (test for warnings, line
173)
FA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89405
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89385
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89348
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487
--- Comment #12 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Wed Feb 20 14:11:43 2019
New Revision: 269039
URL: https://gcc.gnu.org/viewcvs?rev=269039&root=gcc&view=rev
Log:
[GCC] PR target/86487: fix the way 'uses_hard_regs_p' handl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46496
--- Comment #5 from Dominique d'Humieres ---
b) -Wno-c-binding-type silences the warnings related to C binding.
It remains in this PR the missed warnings in d) and e).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89414
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Summary|gcc.dg/sinatan-1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366
--- Comment #2 from Bader at lrz dot de ---
Fortran 2018 FDIS section 18.3.6, para 2, item 5, bullet 2:
(5) any dummy argument without the VALUE attribute corresponds to a formal
parameter of the prototype that is of a pointer type, and either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89414
--- Comment #2 from Jakub Jelinek ---
-march=armv7-a -mfpu=vfpv4 -mfloat-abi=hard -Og -fno-forward-propagate
-fno-tree-fre is what I've been using for options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366
--- Comment #3 from Bader at lrz dot de ---
Created attachment 45771
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45771&action=edit
C code to be called
Added the C side function call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89416
Bug ID: 89416
Summary: [regression] std::vector::push_back no longer builds.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366
--- Comment #4 from Dominique d'Humieres ---
> Fortran 2018 FDIS section 18.3.6, para 2, item 5, bullet 2:
On my draft it is probably
18.3.7 Interoperability of procedures and procedure interfaces
For
character(kind=c_char,len=:), allocat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412
--- Comment #4 from Jakub Jelinek ---
Started with r237429. Don't know why this has anything to do with libgfortran
powerpc64le-linux bootstrap, that worked for me just fine in 8.3-rc1.
Slightly adjusted testcase:
struct S { double a, b; } d;
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412
--- Comment #5 from Matthias Klose ---
bug title was a cut and paste error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #5 from Jonny Grant ---
What appears to be a related issue. the "line number out of supported range"
does not show, even when gcc outputs a negative line number. Three test cases
below
I believe that the #line that pushes beyond 2^31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89397
--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Feb 20 15:23:47 2019
New Revision: 269040
URL: https://gcc.gnu.org/viewcvs?rev=269040&root=gcc&view=rev
Log:
Revert:
PR target/89397
* config/i386/i386.c (ix86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|dmalcolm at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091
--- Comment #6 from David Malcolm ---
Created attachment 45774
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45774&action=edit
Patch
I came up with this patch; it survives bootstrap®rtesting, but am not sure
if it's correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #6 from Jonny Grant ---
Could this show the offending number in the "line number out of range" message?
And even the origin of the LINE1 macro too?
Actual:
#1 with x86-64 gcc (trunk)
: In function 'main':
:4:7: warning: line number o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89366
--- Comment #5 from Bader at lrz dot de ---
No. The dummy argument of the procedure process_string is declared
character(kind=c_char,len=*), intent(in) :: this
there is no POINTER or ALLOCATABLE attribute there.
Regards
Reinhold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88347
Segher Boessenkool changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87844
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091
--- Comment #8 from Jakub Jelinek ---
Comment on attachment 45774
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45774
Patch
Well, for the decode_field_reference, I think it is essential not to change
*exp_ if returning NULL, because the c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89397
--- Comment #6 from Uroš Bizjak ---
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 269040)
+++ config/i386/i386.c (working copy)
@@ -50689,7 +50689,7 @@
static voi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055
Segher Boessenkool changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #7 from Jonny Grant ---
(In reply to Jonny Grant from comment #6)
> Could this show the offending number in the "line number out of range"
> message? And even the origin of the LINE1 macro too?
clang shows the origin of the offending
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80505
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
--- Comment #8 from Martin Sebor ---
The Asan warning is much clearer because it's based on actually observed
values. This instance of the -Wrestrict warning is based on a heuristic: "we
think the copy may overlap because it is within the same o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52130
Eric Gallager changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89270
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89409
--- Comment #5 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Wed Feb 20 16:20:50 2019
New Revision: 269042
URL: https://gcc.gnu.org/viewcvs?rev=269042&root=gcc&view=rev
Log:
libsanitizer: Restore internal_readlink for x32
Cherry-pick compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |SUSPENDED
--- Comment #9 from Seghe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
Bug ID: 89417
Summary: helgrind detects a lock order violation inside
std::scoped_lock
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35592
--- Comment #8 from Eric Gallager ---
Created attachment 45777
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45777&action=edit
testcase
(In reply to felix-gcc from comment #6)
> Sure. For example:
>
> char* c=malloc(lseek(somefd,0,SEEK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #8 from Segher Boessenkool ---
The C standard does not allow the line number (in a #line directive) to be
smaller than 1 or bigger than 0x7fff. It says nothing about actually
having this many lines, or overflowing the line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86395
Eric Gallager changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #7 from Eric Gallage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53063
Eric Gallager changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #12 from Eric Gallag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889
Eric Gallager changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #15 from Eric Gallag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89418
Bug ID: 89418
Summary: D test cases fail on powerpc64le
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80204
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89418
seurer at gcc dot gnu.org changed:
What|Removed |Added
Target||powerpc64le-unknown-linux-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88294
--- Comment #6 from Marek Polacek ---
A similar test crashes:
bool b;
template struct A
{
void g () noexcept (b) { }
};
int main ()
{
A a;
a.g ();
}
but that's PR88987.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89357
Martin Sebor changed:
What|Removed |Added
Keywords|accepts-invalid |rejects-valid
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #9 from Jonny Grant ---
(In reply to Segher Boessenkool from comment #8)
> The C standard does not allow the line number (in a #line directive) to be
> smaller than 1 or bigger than 0x7fff. It says nothing about actually
> having
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #10 from David Malcolm ---
(In reply to Jonny Grant from comment #4)
> There's another related issue, can it be covered on this ticket?
>
> GCC does not show the part of the output below I marked with after
> commenting out line 4 <-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
Will Wray changed:
What|Removed |Added
Attachment #45683|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89385
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89419
Bug ID: 89419
Summary: [8/9 Regression] ICE in is_normal_capture_proxy
starting with r253601
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89419
Jakub Jelinek changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89420
Bug ID: 89420
Summary: [9 Regression] ICE: unexpected expression 'int()' of
kind cast_expr
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89421
Bug ID: 89421
Summary: [9 Regression] ICE in retrieve_specialization, at
cp/pt.c:1245
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89420
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89420
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89422
Bug ID: 89422
Summary: [8/9 Regression] ICE in field_byte_offset, at
dwarf2out.c:19086
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89403
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
--- Comment #25 from Wilco ---
(In reply to Steve Ellcey from comment #24)
> See email strings at:
>
> https://gcc.gnu.org/ml/fortran/2019-01/msg00276.html
> https://gcc.gnu.org/ml/fortran/2019-02/msg00057.html
>
> For more discussion.
Sure, i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89423
Bug ID: 89423
Summary: -fvtable-verify does not work properly with -flto
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89423
ctice at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80408
--- Comment #4 from Raphael Monod ---
Thank you for your answer. But I don't understand why adding -lpthread option
change the behavior if I do not use any thread. Moreover, if I refer to this
page ( https://docs.oracle.com/cd/E19455-01/806-5257/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89400
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89421
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89400
Jakub Jelinek changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #11 from Segher Boessenkool ---
(In reply to Jonny Grant from comment #9)
> Maybe zero could be disallowed too.
Yes, but maybe we need that for historical reasons.
> Not sure what is best here, I'm not knowledgeable of GCC, but mayb
1 - 100 of 153 matches
Mail list logo
