https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #11 from Jakub Jelinek ---
But what about following:
#include
#include
auto f = static_cast(&std::nexttoward);
This doesn't call std::nexttoward(std::float128_t, long double), just checks if
it is defined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110316
Andrew Pinski changed:
What|Removed |Added
Target Milestone|11.5|14.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #26 from And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102705
--- Comment #6 from Andrew Pinski ---
Hmm:
iftmp.0_10 = (char) _2;
_4 = iftmp.0_10 ^ 1;
_18 = (int) _4;
We have this pattern:
/* In GIMPLE, getting rid of 2 conversions for one new results
in smaller IL. */
(simplify
(convert (b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2022-01-17 00:00:00 |2024-2-20
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108803
--- Comment #9 from Andrew Pinski ---
This looks to be to fixed on the trunk. Maybe r14-4647-gabf5ae4594 fixed
it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108495
--- Comment #14 from Andrew Pinski ---
I think the rest are handled correctly but I have not audited everyone yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108495
--- Comment #13 from Andrew Pinski ---
And __builtin_aarch64_jcvtzs:
```
int
m ()
{
__builtin_aarch64_jcvtzs(1.0);
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108495
--- Comment #12 from Andrew Pinski ---
Likewise for the __builtin_aarch64_fcmla_laneq* builtins:
```
#define vect64 __attribute__((vector_size(8)))
#define vect128 __attribute__((vector_size(16)))
int
m ()
{
unsigned long v;
vect64 float t;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108495
--- Comment #11 from Andrew Pinski ---
The CRC functions need a similar handling, e.g.:
```
int
f ()
{
unsigned long v;
return __builtin_aarch64_crc32b (v, v);
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108495
--- Comment #10 from Andrew Pinski ---
Created attachment 57476
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57476&action=edit
Current patch
The error message needs some tweaking but this is basically the patch. Will
also add a few test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108495
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204
Sam James changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99476
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106998
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105513
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99078
--- Comment #7 from Andrew Pinski ---
Created attachment 57475
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57475&action=edit
testcase
Just making it easier to access the testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98563
--- Comment #13 from Andrew Pinski ---
Looking at this, I see in PRE:
REALPART_EXPR = _25;
IMAGPART_EXPR = _26;
_19 = REALPART_EXPR [(const struct complex
&)&D.72413][_8]._M_value>;
Should _19 be the same as _25 ?
I suspect if this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93930
--- Comment #9 from Andrew Pinski ---
Looks to be fixed in GCC 11+.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204
Andrew Pinski changed:
What|Removed |Added
Known to fail||11.1.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89224
--- Comment #16 from Andrew Pinski ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646115.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114028
--- Comment #1 from Andrew Pinski ---
Works fine on aarch64 with SVE:
```
[apinski@xeond2 upstream-full-cross]$ ./install/bin/aarch64-linux-gnu-gcc -O3
t6.c -static -march=armv9-a+sve2 -fno-vect-cost-model
[apinski@xeond2 upstream-full-cross]$ .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
--- Comment #2 from Andrew Pinski ---
Works fine on aarch64 with SVE:
```
[apinski@xeond2 upstream-full-cross]$ ./install/bin/aarch64-linux-gnu-gcc -O3
t6.c -static -march=armv9-a+sve2
[apinski@xeond2 upstream-full-cross]$ ./install-qemu/bin/qem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114028
Bug ID: 114028
Summary: [14] RISC-V rv64gcv_zvl256b: miscompile at -O3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
--- Comment #1 from Sam James ---
When this is fixed, this is probably worth putting in the general torture test
suite, not just for riscv.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027
Bug ID: 114027
Summary: [14] RISC-V vector: miscompile at -O3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114026
--- Comment #2 from Gaius Mulley ---
Created attachment 57474
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57474&action=edit
Proposed fix
Here is the proposed fix.
$ gm2 forloop.mod
forloop.mod:10:8: error: In procedure ‘init’: type e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #2 from kargl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113999
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94972
Andrew Pinski changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113998
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113999
--- Comment #2 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:0a6a5f8656ccf9a60ac516c68cd4eb40ff4630c4
commit r14-9091-g0a6a5f8656ccf9a60ac516c68cd4eb40ff4630c4
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113998
--- Comment #3 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:79d4c7ddc83e000adc8174b179dff44a88d5a41b
commit r14-9090-g79d4c7ddc83e000adc8174b179dff44a88d5a41b
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91139
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109245
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105134
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81199
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 110051, which changed state.
Bug 110051 Summary: error: writing 1 byte into a region of size 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110051
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110051
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #10 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #8)
> So, do we need to define those and std::unreachable (); in their bodies or
> something similar?
No, it needs to be ill-formed to call them, which is already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #3 from Andrew Pinski ---
The first example (of assembly here) in comment #0 is extra moves due to the RA
not handling subreg that decent for the load/store lane. There are other bug
reports dealing with that. Why the SSA_NAMES being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #2 from Andrew Pinski ---
Note what I had found in the past it is not exactly SSA_NAMEs that cause the
difference but rather the RTL register pesdu # causes differences in register
allocation which was exposed from the different in o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
Andrew Pinski changed:
What|Removed |Added
Blocks||53947
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.5
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114011
--- Comment #2 from Andrew Pinski ---
Note a patch for this is one line added to the c_common_reswords array that is
defined in c-common.cc but would definitely need many testcases to test it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114011
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114011
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111749
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #9 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #8)
> So, do we need to define those and std::unreachable (); in their bodies or
> something similar?
Though, cmath probably can't #include , so
#ifdef _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #8 from Jakub Jelinek ---
So, do we need to define those and std::unreachable (); in their bodies or
something similar?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #6 from Andrew Pinski ---
I know cppreference is not the standard exactly but it does have the following
about nexttoward:
However, an invocation of std::nexttoward is ill-formed if the argument
corresponding to from has extended flo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89224
--- Comment #15 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #14)
> Causes a few regressions though:
> FAIL: g++.dg/cpp0x/constexpr-53094-1.C -std=c++14 (internal compiler error:
> in cxx_eval_array_reference, at cp/constexpr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #5 from Jakub Jelinek ---
If you want a function with 2 arguments of the same type, that is
std::nextafter.
In C, nexttoward{f,,l} has first argument of float, double and long double, so
the last one is always long double.
Now, https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #4 from Joseph S. Myers ---
I don't know what's expected for C++, but for C, TS 18661-3 and C23 don't have
versions of nexttoward for _FloatN or _FloatNx (recall that the second argument
of nexttoward has type long double independent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89224
--- Comment #14 from Andrew Pinski ---
Causes a few regressions though:
FAIL: g++.dg/cpp0x/constexpr-53094-1.C -std=c++14 (internal compiler error: in
cxx_eval_array_reference, at cp/constexpr.cc:4458)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114026
Gaius Mulley changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114026
Bug ID: 114026
Summary: incorrect location during for loop type check
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114025
Bug ID: 114025
Summary: Seeming missing frange based optimizations
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024
--- Comment #1 from Steve Kargl ---
On Tue, Feb 20, 2024 at 09:42:21PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024
>
> allocate (xx, source = cmp%re)
>
>
> gfcx -c 0093/0093_0130.f90
> 0093/00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024
Bug ID: 114024
Summary: ICE allocate statement with source=cmp%re and z an
array
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89224
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114023
Bug ID: 114023
Summary: complex part%ref of complex named constant array
cannot be used in an initialization expression.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89224
--- Comment #12 from Andrew Pinski ---
>- type = build_qualified_type (TREE_TYPE (type), TYPE_QUALS (type));
That part is missing it seems.
Let me see if I can fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114022
Bug ID: 114022
Summary: ICE with a complex part%ref and nested structure
constructor of complex array.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114001
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114021
Bug ID: 114021
Summary: ICE with allocation of scalar pointer entity where
SOURCE=f() with f() returning a pointer
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114020
Bug ID: 114020
Summary: ENTRY and procedure pointer leads to ICE
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114019
Bug ID: 114019
Summary: allocation with source of deferred character length
entity
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114012
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Ever confirme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-02-20
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #2 from Andrew Pinski ---
So if godbolt uses an older version of glibc for x86_64 then report it to them
not us.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #1 from Andrew Pinski ---
This depends on the version of glibc to include the c version of these
functions. So this is most likely just an artifact of not having a new enough
glibc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105658
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103
Peter Bergner changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105658
--- Comment #1 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:14ba8d5b87acd5f91ab8b8c02165a0fd53dcc2f2
commit r14-9086-g14ba8d5b87acd5f91ab8b8c02165a0fd53dcc2f2
Author: Peter Hill
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103
--- Comment #8 from GCC Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:81e5f276c59897077ffe38202849c93e9c580c41
commit r14-9085-g81e5f276c59897077ffe38202849c93e9c580c41
Author: Peter Bergner
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
Bug ID: 114018
Summary: std::nexttoward is not implemented for C++23-FP-Types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
-master/bin/riscv64-unknown-linux-gnu-g++ --version
riscv64-unknown-linux-gnu-g++ (g61ab046a327) 14.0.1 20240220 (experimental)
./riscv-gcc-master/bin/riscv64-unknown-linux-gnu-g++ -dM -E -march=rv64gcv - <
/dev/null | grep riscv_v_intrin
#define __riscv_v_intrinsic 11
O compression algorithms: zlib zstd
gcc version 14.0.1 20240220 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112922
--- Comment #2 from Richard Sandiford ---
I don't remember there being a deliberate bug fix in that patch,
but there were some others later. I suppose the optimistic case
is that this first went latent and then was fixed “properly”
afterwards.
0240220001758-g52490278466-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240220 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Resolution|MOVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #9 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114014
Bug ID: 114014
Summary: ICE: 'verify_type' failed: 'TYPE_CANONICAL' is not
compatible with -gbtf or -gctf on gcc.dg/gnu23-tag-1.c
Product: gcc
Version: 14.0
Status: UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114013
--- Comment #2 from Jakub Jelinek ---
And it behaves the same way even if there is
template
constexpr inline struct S var[8] = {};
instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114013
--- Comment #1 from Jakub Jelinek ---
s/16/8/, sorry for the leftover from earlier larger version.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745
--- Comment #8 from Jonathan Wakely ---
(In reply to Xi Ruoyao from comment #6)
> (In reply to Sebastian "spaetz" Spaeth from comment #5)
> > I fully understand that nobody wants to invest time into fixing this. What
> > would be nice though, is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #32 from Jonathan Wakely ---
[basic.stc.general] says global == &w is implementation-defined if global is an
invalid pointer value, not just unspecified. GCC could define it to be
unspecified, or UB, and even say "it's UB just in thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114013
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114013
Bug ID: 114013
Summary: [14 Regression] Specializations of var templates no
longer emitted since r14-8987
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Jakub Jelinek ---
> Or convince Oracle to change it (again, an ABI break).
I can try, but don't hold your breath.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Jonathan Wakely ---
> It's technically an ABI break, since void f(int8_t) would mangle differently.
> It probably wouldn't affect much in practice, but would stil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Jonathan Wakely ---
> (In reply to Jonathan Wakely from comment #1)
>> I assume that int8_t is char on Solaris, rather than signed char?
>
> This actually violate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #31 from Arthur O'Dwyer ---
Oops, I guess my reading did disagree with jwakely's in one small point:
jwakely writes--
> But since one of the pointers is an invalid pointer,
> you can't do anything with its value anyway, including
> c
1 - 100 of 178 matches
Mail list logo
