https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117793
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117655
--- Comment #4 from Andrew Pinski ---
Created attachment 60560
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60560&action=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96252
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90285
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90285
--- Comment #5 from Andrew Pinski ---
Created attachment 60559
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60559&action=edit
Testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
--- Comment #15 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #14)
> Note removing the definitions of operator new/delete is still not optimized
> even on the trunk I have not checked out why though.
Unless we turn off exce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78399
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46236
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
Chris Wellons changed:
What|Removed |Added
CC||wellons at nullprogram dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117204
Dimitry Andric changed:
What|Removed |Added
CC||dimitry at andric dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118983
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118983
--- Comment #2 from Andrew Pinski ---
Note also GCC 10 is no longer supported upstream. So try GCC 12+ and see if it
fails there.
Plus you didn't give a testcase. Please read https://gcc.gnu.org/bugs/#need
next time.
Also the message from Ub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96935
Andrew Pinski changed:
What|Removed |Added
CC||wzis at hotmail dot com
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118983
Bug ID: 118983
Summary: I'm using the gcc comes from the Ubuntu 20.04, but it
faied to compile a C program
Product: gcc
Version: 9.4.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111589
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118982
Bug ID: 118982
Summary: Documentation for constructor and init_priority should
be refenceing each other
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #13 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #6)
> init_priority attribute should most likely link back to the constructor
> function attribute for the description of the priority .
And the constructor attrib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #14 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to Andrew Pinski from comment #6)
> > init_priority attribute should most likely link back to the constructor
> > function attribute for the descri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14295
--- Comment #14 from Andrew Pinski ---
Note looking into how LLVM implements this is almost exactly the same as I have
implemented. The memset/memcpy -> memset/memset is exactly the same (though it
does work with other things inbetween).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #12 from Andrew Pinski ---
(In reply to Erich Löw from comment #10)
> Envs:
>
> GCCVERSION=15.0.1
> CCFLAGS=-pipe -march=native -O2 -fPIC -fomit-frame-pointer
>
> $GCCVERSION is initialized as this:
> export GCCVERSION=`gcc -dumpfu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #11 from Erich Löw ---
The whole env output:
LS_COLORS=no=00:fi=00:di=01;34:ln=00;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=41;33;01:ex=00;32:*.cmd=00;32:*.exe=01;32:*.com=01;32:*.bat=01;32:*.btm=01;32:*.dll=01;32:*.t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #10 from Erich Löw ---
Envs:
GCCVERSION=15.0.1
CCFLAGS=-pipe -march=native -O2 -fPIC -fomit-frame-pointer
$GCCVERSION is initialized as this:
export GCCVERSION=`gcc -dumpfullversion`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #9 from Andrew Pinski ---
"-march=native -O2" is not normally used when compiling libstdc++.
You must have some env variables set.
Can you provide the output of `env` too?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #8 from Erich Löw ---
I try
1. Version of GCC:
gcc (GCC) 15.0.1 20250219 (experimental)
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #7 from Andrew Pinski ---
Can you provide the following:
the exact version of GCC;
the system type;
the options given when GCC was configured/built;
the complete command line that triggers the bug;
the compiler output (error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #6 from Andrew Pinski ---
(In reply to Erich Löw from comment #5)
> I found in "7.7 C++-Specific Variable, Function, and Type Attributes" that
> the lowest supported cardinal (indicating highest prio) should be 101.
>
> I tried to r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #5 from Erich Löw ---
I found in "7.7 C++-Specific Variable, Function, and Type Attributes" that
the lowest supported cardinal (indicating highest prio) should be 101.
I tried to replace all occurrences of 99 with 101 and LATEST com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #4 from Sam James ---
Ah, thanks. I both missed the 'Parent' but also missed the recent addition so
it didn't ring any alarm bells.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #3 from Jonathan Wakely ---
(In reply to Sam James from comment #2)
> The commit you're referring to is from April 2024, not 2025. It's also been
> backported with zero complaints.
I think they just showed the wrong hash, note "Pare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #21 from Jonathan Wakely ---
(In reply to Peter Dimov from comment #19)
> This should work.
In simple cases, yes. But if we have a mixed C++11 and C++14 (or later)
codebase, it's possible for the std::atomic to be initialized in a C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #2 from Sam James ---
On what platform? Please show us:
* the configure line used to build GCC
* the error in full, including the command before it that failed
* which commit / snapshot of GCC trunk
you're using.
The commit you're r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-02-21
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
Bug ID: 118981
Summary: tzdb.cc contains 3 times in sequence:
[[gnu::init_priority(99)]]
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118980
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118980
Bug ID: 118980
Summary: std::system_error should not be default constructible
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118980
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118979
Bug ID: 118979
Summary: Wrong gettext extraction in c.opt
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116851
--- Comment #3 from Jeffrey A. Law ---
Correct. We aren't able to optimize away the path in question until full jump
threading which is way too late for the NULL warnings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507
Bug 95507 depends on bug 111669, which changed state.
Bug 111669 Summary: bogus -Wnonnull in conditionally executed code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111669
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111669
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78998
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507
Bug 95507 depends on bug 78998, which changed state.
Bug 78998 Summary: missing -Wnonnull for an unconditional call to strlen with a
null argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78998
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118978
--- Comment #2 from Gaius Mulley ---
Created attachment 60557
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60557&action=edit
Proposed fix which detects an incorrect parameter being passed
the ICE occurs when a range test is performed on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507
Bug 95507 depends on bug 78917, which changed state.
Bug 78917 Summary: missing -Wnonnull passing null to a nonnull function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78917
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78917
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118978
Gaius Mulley changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118978
Bug ID: 118978
Summary: ICE when attempting to pass a REAL actual parameter
into an INTEGER formal parameter
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
--- Comment #7 from Luke Robison ---
Andrew,
Perhaps you mean that setting -mcpu=neoverse-v1 overrides
-msve-vector-bits=scalable argument. So I tried with `-march=armv9-a+sve
-msve-vector-bits=scalable`. I still observe the same erroneous ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14295
--- Comment #13 from Andrew Pinski ---
Created attachment 60556
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60556&action=edit
Patch which adds the simplified copy prop for agg
This fixes the testcase and has been bootstrapped and tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118975
John.Bollinger at StJude dot org changed:
What|Removed |Added
CC||John.Bollinger at StJu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116662
--- Comment #12 from Jason Merrill ---
(In reply to Jeffrey A. Law from comment #11)
> I think Jason's position is that while it has ABI implications, that anyone
> using it in a way that exposes those ABI implications is using the feature
> in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118977
--- Comment #3 from Joel Sherrill ---
Sorry. Submitted accidentally while incomplete.
(In reply to Andrew Pinski from comment #1)
> >And our test compiles and links fine on that.
>
> That is because arm has defined __atomic_test_and_set in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118977
--- Comment #2 from Joel Sherrill ---
In reply to Andrew Pinski from comment #1)
> >And our test compiles and links fine on that.
>
> That is because arm has defined in the libgcc.
That symbol is not in the arm-rtems libgcc.a and I do not see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100591
Andrew Pinski changed:
What|Removed |Added
CC||blubban at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
--- Comment #6 from Luke Robison ---
Andrew,
Thanks for taking a look. I actually had not realized that
-msve-vector-bits=scalable is the only option guaranteed to produce correct
execution on machines with other vector sizes. I need to make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118972
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #2 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118972
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118973
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118977
Andrew Pinski changed:
What|Removed |Added
Target||m68k-rtems
--- Comment #1 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118975
--- Comment #3 from Andrew Pinski ---
undef
Driver
; C option, but driver must not handle as "-u ndef".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118975
--- Comment #5 from Andrew Pinski ---
Maybe %
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118975
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114991
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #22 from Sam James ---
I suggest regtesting it on the branches, submitting it, and asking Jeff for
approval. I can't speak for Jeff but I would take the unassignment as "I'm not
going to work on the backport-and-testing" rather than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #21 from Georg-Johann Lay ---
Back then, the patch has been reopened so it won't be forgotten for
backporting.
https://gcc.gnu.org/pipermail/gcc/2024-February/243300.html
As is seems, no backport will happen?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118977
Bug ID: 118977
Summary: m68k mcf5282 undefined symbol __atomic_test_and_set
from atomic_base.h
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118973
--- Comment #2 from Sam James ---
```
int foo() __attribute__((returns_twice));
void a() {
int a;
if(foo()) new int;
&a;
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118973
--- Comment #1 from Sam James ---
```
int _setjmp();
void a() {
int b;
if (_setjmp())
new int;
&b;
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
Sam James changed:
What|Removed |Added
Status|ASSIGNED|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100570
--- Comment #6 from fsmoke ---
I just now tested my sample on gcc 13.3 it seems bug already fixed somehow
>>That's not a system include directory, because you didn't use -isystem
And no... it's not nesessery, because isystem works for all subd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
--- Comment #4 from Luke Robison ---
Apologies I forgot to include compile line and output:
gcc -fno-inline -O3 -Wall -fno-strict-aliasing -mcpu=neoverse-v1 -o final
final.c
gcc:9 gives PASS: got 0x00bb 0x00aa as expected
gcc:10 gives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117263
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
--- Comment #3 from Luke Robison ---
Sam,
No, -fno-strict-aliasing still produces incorrect results.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
--- Comment #2 from Luke Robison ---
In particular I believe the error occurs because of the following sequence of
instructions. Looking at line numbers form the compiler explorer output of
14.2
In the first block line 8:
index z31.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
--- Comment #1 from Sam James ---
Does -fno-strict-aliasing work (the uint32_t* cast)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118837
--- Comment #4 from Tom Tromey ---
(In reply to Jakub Jelinek from comment #3)
> And perhaps we could also try to optimize the DW_FORM_sdata cases if there
> is no ambiguity (e.g. for 8-bit signed contexts with negative value
> DW_FORM_data1 co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
Sam James changed:
What|Removed |Added
Keywords||wrong-code
Summary|Correctness I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
Bug ID: 118976
Summary: Correctness Issue: SVE vectorization results in data
corruption when cpu has 128bit vectors
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114516
--- Comment #1 from Robin Dapp ---
The issue is that we're not considering pattern statements for costing. It's
rather straightforward to include those as well which would fix this PR.
I'm going to test a patch locally.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86802
Jeffrey A. Law changed:
What|Removed |Added
Assignee|law at gcc dot gnu.org |unassigned at gcc dot
gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118975
--- Comment #1 from Nate Eldredge ---
I should have said, credit to StackOverflow user anol for finding this.
https://stackoverflow.com/questions/79457581/gcc-undef-leads-to-cannot-find-entry-symbol-start-defaulting-to-x/79457825#79457825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118975
--- Comment #2 from Sam James ---
A workaround is probably -Wp,-undef but not tried it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118975
Bug ID: 118975
Summary: -undef is passed to the linker
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939
--- Comment #3 from Nicolas Boulenguez ---
The segmentation fault disappears if either -fstack-check or -O1 is removed.
(gdb) run
Starting program: /home/nicolas/runner
[Thread debugging using libthread_db enabled]
Using host libthread_db libr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118974
Tamar Christina changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106531
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118968
--- Comment #2 from Jonathan Wakely ---
(In reply to qurong from comment #0)
> The compiler gcc10.1 accepts this program.
We aren't interested in bugs in GCC 10.1, it stopped being supported five years
ago when GCC 10.2 was released, and all 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118974
Bug ID: 118974
Summary: Use SVE cbranch sequence for Neon modes when
TARGET_SVE
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118973
Sam James changed:
What|Removed |Added
Target Milestone|--- |15.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118972
Bug ID: 118972
Summary: Missing ubsan complaint for double->int cast overflow
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118973
Bug ID: 118973
Summary: [15 regression] ICE when building glog-0.6.0
(single_succ_edge, at basic-block.h:332)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80681
xxie_xd changed:
What|Removed |Added
CC||xxie_xd at 163 dot com
--- Comment #5 from xxi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118967
Richard Biener changed:
What|Removed |Added
Target Milestone|15.0|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
--- Comment #13 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:ee30e2586a3142e63daaf301a561984f1d22d38d
commit r15-7665-gee30e2586a3142e63daaf301a561984f1d22d38d
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59863
--- Comment #14 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #13)
> I have an idea on how to fix this for the case when there is enough values
> that GCC's gimplifier creates a const static variable to copy from. Which
> happens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118971
--- Comment #2 from Jonathan Wakely ---
Also, it's not helpful to say "the compiler gcc accepts this program" and not
mention that actually it gives a warning.
1 - 100 of 142 matches
Mail list logo
