https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113994
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113996
Richard Biener changed:
What|Removed |Added
Keywords||lto
--- Comment #1 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113998
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113999
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114000
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114006
Bug ID: 114006
Summary: False positive diagnostic -Wpedantic for zero-size
arrays, most vexing parse
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114006
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61259
Andrew Pinski changed:
What|Removed |Added
CC||janschultke at googlemail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Bug ID: 114007
Summary: gcc chokes on
__has_cpp_attribute(clang::unsafe_buffer_usage)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113993
Jakub Jelinek changed:
What|Removed |Added
Attachment #57467|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Iain Sandoe changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Sandoe ---
> Is this a clang extension (handling clang::x with -std= < c23)?
I can't tell: I was waiting for the preprocessor maintainers to comment.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114008
Bug ID: 114008
Summary: Internal compiler error, segmentation fault
Product: gcc
Version: 9.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #4 from Jakub Jelinek ---
Not to mention that predefining __has_cpp_attribute in such a public header
isn't a good idea.
They should take example from xxhash which does
#ifdef __has_attribute
# define XXH_HAS_ATTRIBUTE(x) __has_attri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #5 from Iain Sandoe ---
perhaps this is also a clang regression - for Jakub's example with Xcode 15.1 :
$ clang --version
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: x86_64-apple-darwin23.3.0
master-wip-short-queue mini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500
Andrew Pinski changed:
What|Removed |Added
CC||ujszhangc at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114008
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #6 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #5)
> perhaps this is also a clang regression - for Jakub's example with Xcode
> 15.1 :
(xcode clang, that is, I did not test with upstream clang yet).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113983
--- Comment #6 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ecfcc362b7f3f796c72f3525c4e3a6dd8ab3beac
commit r14-9079-gecfcc362b7f3f796c72f3525c4e3a6dd8ab3beac
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #7 from Jakub Jelinek ---
Well, my testcase didn't have those
#ifdef __has_c_attribute
and likewise for __has_cpp_attribute guards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113331
Thomas Schwinge changed:
What|Removed |Added
Last reconfirmed||2024-02-20
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #8 from Jakub Jelinek ---
Anyway,
#ifdef __has_c_attribute
#if __has_c_attribute (clang::unsafe_buffer_usage)
int i;
#endif
#endif
#ifdef __has_cpp_attribute
#if __has_cpp_attribute (clang::unsafe_buffer_usage)
int j;
#endif
#endif
f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #9 from Jakub Jelinek ---
Ah, but they accept the version with __has_cpp_attribute only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #22 from Richard Biener ---
Ping. Jakub/Jason - we now have three open bugs because of this. The patch
in comment#12 works but Jakub doesn't like it.
Instead as far as I understand we need a flag to tell us whether there's
guarant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #10 from Iain Sandoe ---
indeed, it seems clang does not define __has_cpp_attribute for -std=c11 c
compilations, whereas GCC does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #7 from Richard Biener ---
Access trees for x (UID: 2479):
access { base = (2479)'x', offset = 0, size = 128, expr = x.d, type = long
double, reverse = 0, grp_read = 1, grp_write = 1, grp_assignment_read = 1,
grp_assignment_write = 1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113060
--- Comment #9 from Giuseppe D'Angelo ---
Thank you, I'll amend P3146 with this new information, and try and make sure
that LEWG/LWG see the updated draft (if they discuss this before the next
mailing).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #11 from Iain Sandoe ---
looking at n2176 - C18 there is no mention of __has_c*
looking at n3047 - C23 there is mention only of __has_c_attribute
OTOH, there is no prohibition in declaring __has_cpp_attribute (c.f. an actual
prohibi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #8 from Andrew Pinski ---
(In reply to Richard Biener from comment #6);
>
> and the value re-interpretation goes off. Martin - we may have dups of this
> but SRA shouldn't do this (it possibly gets confused by the x.d store)?
Yes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
--- Comment #33 from GCC Commits ---
The releases/gcc-11 branch has been updated by Alex Coplan
:
https://gcc.gnu.org/g:0b308e2f27b087049fde9fbc64e432de47868a90
commit r11-11247-g0b308e2f27b087049fde9fbc64e432de47868a90
Author: Alex Coplan
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
Alex Coplan changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009
Bug ID: 114009
Summary: Missed optimization: (!a) * a => 0 when a=(a/2)*2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
Bug ID: 114010
Summary: Unwanted effects of using SSA free lists.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113995
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #23 from Jakub Jelinek ---
Changing what types have TREE_ADDRESSABLE flag on it would cause significant
ABI changes, that is not what we can do.
Widget above does not have trivial default constructor, but has trivial copy
constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27800
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113805
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:98702303e2b0e540b25c94805ca015688f78250e
commit r14-9080-g98702303e2b0e540b25c94805ca015688f78250e
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113805
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #24 from Jakub Jelinek ---
On the #c23 testcase, actually even on i686-linux where it is passed in memory
we optimize main at -O2 -m32 -fno-strict-aliasing -fno-tree-pta (i.e. when the
code mentioned in #c12 is never called) to retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112922
Alex Coplan changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27896
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #25 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #9)
> struct Widget {
> int i;
> int a[4];
> };
> Widget *global = 0;
> Widget make2() { Widget w; w.i = 1; global = &w; return w; }
> void g() { global->i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29374
Richard Biener changed:
What|Removed |Added
Component|middle-end |rtl-optimization
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #26 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #25)
> However, [class.temporary] p3 explicitly allows the compiler to create a
> temporary object when returning a class with a trivial copy constructor and
> tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47344
Bug 47344 depends on bug 34983, which changed state.
Bug 34983 Summary: i486-linux-gnu-g++: Internal error: Killed (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34983
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34983
Richard Biener changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #27 from Richard Biener ---
(In reply to Jonathan Wakely from comment #25)
>
> Since it's unspecified, the program cannot rely on any particular behaviour.
> The 'global' pointer might point to w, or it might point to a temporary
> w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #28 from Jonathan Wakely ---
What I tried to say in comment 26 is that we're allowed to always make the
extra copy, which means that global is an invalid pointer, so the program has
UB.
I think the only flaw in that reasoning is wha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114011
Bug ID: 114011
Summary: Feature request: __goto__
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #29 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #28)
> What I tried to say in comment 26 is that we're allowed to always make the
> extra copy, which means that global is an invalid pointer, so the program
> has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35608
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2009-11-03 12:18:41 |2024-2-20
--- Comment #11 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36294
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84414
--- Comment #7 from Jonathan Wakely ---
(In reply to Richard Smith from comment #2)
> In fact, I think the *only* problem here is that the above rule does not
> allow the caller and the callee to observe the objects having the same
> address.
Wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2019-03-05 00:00:00 |2024-2-20
--- Comment #62 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39992
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2021-12-25 00:00:00 |2024-2-20
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40773
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42355
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2021-12-09 00:00:00 |2024-2-20
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54343
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
Bug 19794 depends on bug 54345, which changed state.
Bug 54345 Summary: jump threading leaks e->aux heap memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54345
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54345
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112312
--- Comment #4 from Martin Jambor ---
It seems this has been fixed in current master (which is to become gcc 14).
If my bisecting is correct, it has been fixed by r14-5628-g53ba8d669550d3 (Jan
Hubicka: inter-procedural value range propagation).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114012
Bug ID: 114012
Summary: overloaded unary operator called twice
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113996
--- Comment #2 from J.C. Moyer ---
(In reply to Richard Biener from comment #1)
> You could also try whether -fwhole-program instead of -flto reproduces the
> issue.
-fwhole-program also works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113778
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113220
Richard Sandiford changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111573
--- Comment #2 from Martin Jambor ---
I cannot see any difference at -O3 with or without -fno-early-inlining.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113971
--- Comment #3 from GCC Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:61ab046a3277c256867f596e73ce5b5ee9041a9d
commit r14-9084-g61ab046a3277c256867f596e73ce5b5ee9041a9d
Author: Iain Sandoe
Date: Sun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113971
Iain Sandoe changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #6 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745
--- Comment #7 from Iain Sandoe ---
(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 if this were really just a missed optimization an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97276
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed||2024-02-20
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987
--- Comment #5 from Marek Polacek ---
We already check !INDIRECT_TYPE_P, but here we're invoking a constructor, and
we don't check that its parameters are !INDIRECT_TYPE_P.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #30 from Arthur O'Dwyer ---
I think I understand jwakely's argument at this point, and it's consistent and
teachable. https://eel.is/c++draft/class.temporary#3.sentence-1 says:
> When an object of class type X is passed to or return
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
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=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 #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=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=114013
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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=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=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=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=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=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=113977
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Resolution|MOVED
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=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.
O compression algorithms: zlib zstd
gcc version 14.0.1 20240220 (experimental) (GCC)
-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
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
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=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
Peter Bergner changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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
1 - 100 of 178 matches
Mail list logo
